[Info-vax] scp or sftp: file is "raw", needs to be parsed - possible to work around that?

[Volker Halle]

The problems is apparently not seen when using SCP between OpenVMS systems.

When trying to SCP such a big file to a Linux system, the following messages are shown:
...
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:396: Source file is "raw", and it needs to be parsed.
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:3196: Received SSH_FXP_STAT
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:3271: Statting file `/DUA1300/GOOGLE/xxxxxx.bck'

and there it 'hangs' reading the whole file for determining the record count and data bytes...

$ ANAL/RMS/UPDATE does not help on an OpenVMS backup saveset, as it only updates the file length hints for VAR and VFC files and only on ODS-5 volumes.

IF SCP would really check just the file length hints, when receiving a SSH_FXP_STAT command, patching the file header could be a workaround.

$ DUMP/HEADER/BLOCK=COUNT=0 file shows (example for variable length .TXT file):
...
    File length hints
        Record count:                     1340                                 <<< quadword at offset %X8C in file header
        Data byte count:                  48756                              <<< quadword at offset %X94 in file header

The DISKBLOCK Freeware utility could be used to patch these 2 fields in the file header:
        Record count = number of backup records/blocks in the saveset
        Data byte count = Record count  times  backup  block size

The SPLIT.C code example (see above) has been successfully tested on an OpenVMS Backup savest, which could be successfully split into smaller files and re-combined afterwards. BACKUP/LIST on the re-combined new saveset worked fine.

Volker.