[Info-vax] difference in files being copied by scp from Unix to VMS

[JF Mezei]

Sumir wrote:

> Is it possible to force the end-of-file marker, so that it is read
> differently (using say set/file/attrib or something similar)

There is no magical solution to fix the broken file. From VMS's point of
view, all of the data prior to the end of file is perfectly valid and
VMS doesn't know where you would want the end of file to really be.

You could write a utility that scans the file and figures out where the
last real byte is, and then use an RMS call to update where the ened of
file should really be. (forget what the system call incantation is to
update the FAB).


In terms of the SCP file transfer you used, do you recall what options
you used at both ends ?

did you use binary transfer at both ends ? Did you specify /VMS when
sending it to the unix sytem ?

As a recall, when a file transfer utiity (such as Kermit) wants to send
a "rich" VMS file with all its attributes, it sends a small bock ahead
of the data , that block contains various file settings (record format
etc etc).  If this is store on the remote system and sent back to the
VMS system, then the receiving VMS system will use that block to set the
same file attributes as the original file.

Such a process allows the transmission of indexed files in a way that
the file can be recreated on anorther VMS system (as opposed to sending
the data as a sequential file and build a new index file from scratch on
the remote system).

One possibility is that the sending process sent some 140 bytes of VMS
information ahead of the file, the receiving Unix system realised this
was VMS related junk and discarded it, but forgot to not count that data
towards the file size.


One thing you could try is to set the original file's attributes to
something very odd (such as RFM=FIX,LRL-387) (fixed length, record
length = 387) and then transfer the file back and forth and see if it
recreated with the same attributes.