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

[jbriggs444 at gmail.com]

On Apr 28, 11:34 pm, Sumir <sumirme... at gmail.com> wrote:
> On Apr 28, 12:56 pm, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
>
>
>
>
>
> > Sumir wrote:
> > > Is it possible to force the end-of-filemarker, so that it is read
> > > differently (using say set/file/attrib or something similar)
>
> > There is no magical solution to fix the brokenfile. FromVMS'spoint of
> > view, all of the data prior to the end offileis perfectly valid andVMSdoesn't know where you would want the end offileto really be.
>
> > You could write a utility that scans thefileand figures out where the
> > last real byte is, and then use an RMS call to update where the ened offileshould really be. (forget what the system call incantation is to
> > update the FAB).
>
> > In terms of the SCPfiletransfer you used, do you recall what options
> > you used at both ends ?
>
> > did you use binary transfer at both ends ? Did you specify /VMSwhen
> > sending it to theunixsytem ?
>
> > As a recall, when afiletransfer utiity (such as Kermit) wants to send
> > a "rich"VMSfilewith all its attributes, it sends a small bock ahead
> > of the data , that block contains variousfilesettings (record format
> > etc etc).  If this is store on the remote system and sent back to theVMSsystem, then the receivingVMSsystem will use that block to set the
> > samefileattributes as the originalfile.
>
> > Such a process allows the transmission of indexed files in a way that
> > thefilecan be recreated on anortherVMSsystem (as opposed to sending
> > the data as a sequentialfileand build a new indexfilefrom scratch on
> > the remote system).
>
> > One possibility is that the sending process sent some 140 bytes ofVMS
> > information ahead of thefile, the receivingUnixsystem realised this
> > wasVMSrelated junk and discarded it, but forgot to not count that data
> > towards thefilesize.
>
> > One thing you could try is to set the originalfile'sattributes to
> > something very odd (such as RFM=FIX,LRL-387) (fixed length, record
> > length = 387) and then transfer thefileback and forth and see if it
> > recreated with the same attributes.
>
> I tried out this....
>
> var = F$FILE(FILE1,"FFB")
> set file/attribute=(FFB:'var) FILE2
>
> this way i was able to make the eof byte same for both the files, and
> then the diff does not show up the extra nulls. I guess this would
> solve out the problem.

This is indeed an adequate fix in this case.  In the general case
there are _two_ fields that need to be updated: EBK and FFB.

EBK is the end-of-file block.  This is, if I recall correctly, the
block where the next not-yet-filled-in byte of the file would be
placed.  So in an empty file, EBK=1 and FFB=0

FFB is the first free byte.  It is the byte within the EBK where the
next byte of data would go.

F$FILE_ATTRIBUTES("<file>", "EOF") returns the value of EBK.  But only
if FFB is non-zero.  When FFB is zero, the returned value for EOF is
one less than EBK.

For the general case, the required fixup is along the lines of:

$! fixup.com -- P1 = file with correct length, P2 = file that needs
truncation
$ EOF = F$FILE_ATTRIBUTES(P1,"EOF")
$ FFB = F$FILE_ATTRIBUTES(P1,"FFB")
$ EBK = EOF
$ IF FFB .EQ. 0 THEN EBK = EOF - 1
$ SET FILE 'P2 /ATTR=(EBK:'EBK,FFB:'FFB)
$ EXIT