🚀 go-pugleaf

Hello world!

I got VMS (5.4 & 5.5) to transfer binary files over a modem line. But on the
receiving part, VMS changes the record format to an inacceptable one.
A disk save set formerly
	Record format:      Fixed length 32256 byte records
	Record attributes:  None
is converted to
	Record format:      Stream_LF
	Record attributes:  Carriage return carriage control
All else is the same.

This effect yields by both ZMODEM and
two versions of KERMIT. Unfortunately I couldn't get the
BLISS-Version running, there is a BLISS-Compiler missing
and the uuencoded Version of the .EXE-file was corrupt.
Nevertheless, ZMODEM is said to get better throughput than
Kermit (actually, I got about 150 CPS using ZMODEM and 60 CPS
using Kermit).

DIFF as well as CONVERT complain they
can't handle the transferred files giving a RMS error message.
A self-written "diff", comparing both
files byte-by-byte using open(2) and read(2) tells me, both files
are exactly the same. BACKUP doesn't accept the transferred file as
a save set.

Then I found a DCL-Prozedure (it's called KERMIT_VMSBACKUP_RESTORER.COM or
something similar) on NRLVAX.NRL.ARMY.MIL which should
correct this problem, i.e. save set's should be readable after a
transfer. Still, they are not. This is the log of it's run given
32528, which is the default /BLOCK_SIZE of BACKUP, as the third parameter:

  BLOCK_SIZE = "32528"

Ready to process SAVE_SET BACK.SET
SAVE_SET BACK.SET PROCESSING BEGINNING
   5-NOV-1992 16:51:21
%COPY-S-COPIED, SYS$USER:[SCHMIDTAT.TMP]BACK.SET;3 copied to SYS$USER:[SCHMIDTAT
.TMP]BACK_NEU.SET;1 (126 blocks)
%COPY-I-OVERLAY, SYS$USER:[SCHMIDTAT.TMP]BACK_NEU.SET;1992 being overwritten
%COPY-W-INCOMPAT, SYS$USER:[SCHMIDTAT.TMP]BACK_NEU.SET;1991 (input) and SYS$USER
:[SCHMIDTAT.TMP]BACK_NEU.SET;1992 (output) have incompatible attributes
%COPY-E-WRITEERR, error writing SYS$USER:[SCHMIDTAT.TMP]BACK_NEU.SET;1992
-RMS-F-RSZ, invalid record size
%COPY-W-NOTCMPLT, SYS$USER:[SCHMIDTAT.TMP]BACK_NEU.SET;1991 not completely copie
d

The most curious thing is that VMS _is_ able to run an
.EXE-file, which is of 
	Record format:      Stream_LF
	Record attributes:  Carriage return carriage control
But I won't rely on this, who knows, how the next versions of
VMS will handle this. Furthermore, other programs and utilities
presumably can't handle converted files (RALLY? RDB?).

My questions:
1. How do I get ZMODEM (or Kermit, if this is, what you can
   answer) to _not_ converting the file type? Is such a version
   available somewhere on the InterNet? 
2. How do I restore the record type of the
   received file? CREATE/FDL doesn't work, due to a RMS-error
   (something about to big record or buffer size)
   I already tried writing a quick hack using open(2) and
   write(2), which opens an existing target file of correct
   record type (just like the mentioned DCL-Procedure did),
   but write(2) seems to be interpreted by VMS
   somehow and the same error as using DIFF or CONVERT showed
   up.

Please email answers directly to me, as I am reading this group
only frequently.

Thanks for your help,
-- 
Torge

-----------------------------------------------------------------------------
Torge  Schmidt,  FB  10   Informatik,    Uni  Oldenburg,    D-2900  Oldenburg
Privat  : Stadskanaal 3,  D-2804 Lilienthal,  04298/55 33 (Anrufbeantworter!)
InterNet: Torge.Schmidt@arbi.informatik.uni-oldenburg.de IRC/Nightfall: Moram
-----------------------------------------------------------------------------
A signature ny is a projection from a set I into the set N.