ssh

[Eric_369]

Hello,
I am trying to copy data files using scp/sftp to another I64 host and keep getting the following error:

<<
xxx_xxxxxxx.dat | 61kB | 7.7 kB/s | ETA: 00:00:03 | 68%tcpip$ssh_scp2.exe: warning: xxx_xxxxxxx.dat (src): got)


%TCPIP-E-SSH_FC_ERROR, undetermined error within sshfilecopy
>>

I was reading in the documentation that I can only send files of the following type:

<<
File transfer is limited to OpenVMS files with the following record formats (as displayed by the DIRECTORY/FULL command):
STREAM_LF
Fixed-length 512-byte records
>>

Is this true? If so, who in the world can limit all secure file transfers to meet such ridiculous criteria on an OpenVMS system?

Eric

[Arch_Muthiah]

Eric,

Are you trying transfer from OpenVMS/I64 to OpenVMS/I64?.

There is a restriction in OpenVMS 8.2/I64 only on large file transfer.

You may need to adjust memory parameters (WSDEF, WSQUO, WSEXTENT,and PGFLQUO) to accommodate the memory requirements of the file copy client and server. The exact value depends on system resources and virtual memory configuration.

Archunan

[Steven Schweda]

It's very likely true, as this is software
devleoped on UNIX-like systems for use on
UNIX-like systems, and these file formats are
the ones which most closely map onto the UNIX
stream-of-bytes file model. Such programs
may be useful tools when interacting with a
UNIX-like system. Who in the world expects
such programs to cope with file systems as
feature-rich as the ones on VMS?

Various other schemes are possible, including
use of a VPN, explicit PGP or GnuPG
encryption, pre-/post-processing the file(s)
using Zip/UnZip, and so on. Knowing only
that you don't approve of one particular
solution is not much help in choosing a
suitable alternative.

[Richard Whalen]

I don't know the cause of your scp/sftp copy error.

As for the limitations of the scp/sftp implementation in TCP/IP Services, that is due to the version of the SFTP protocol that the software implements. Prior to version 4 of the protocol the only access defined was binary (stream of bytes) access. Version 4 adds text mode access; versions 5 and 6 refine the protocol to reduce the problems with dealing with dis-similar systems.

Most implementations are still version 3.

SCP2/SFTP come from the Unix world and have many characteristics of an application designed for that world without thinking about how it could work with dis-similar systems.

[Eric_369]

Steven,

<<
Who in the world expects
such programs to cope with file systems as
feature-rich as the ones on VMS?
>>

I guess someone who finds these (scp/sftp) applications on the OpenVMS platform!
I suppose on a platform as feature rich as the OpenVMS platform one would expect to find a simple method of transfering those feature rich files securely, without having to go throught the tortures of the condemned (pc), while maintaining fdl integrity!


<<
Knowing only
that you don't approve of one particular
solution is not much help in choosing a
suitable alternative.
>>

Now that is a stretch! I approve of the method; not however, of the utilities' extent. If I can only copy files with 512 byte records to other hosts with scp/sftp why in the world would anyone boast of these applications as solutions? They are more of a hinderance than a solution. A solution would be an application that could be used to tranfer any type of file securely between hosts. Maybe a secure file transfer protocal that is truly secure "FTP", emphasis on FTP. I guess we have different interpretations for the word "solution." You can interpret this as sarcasm! Instead of calling these applications 'sftp' and 'scp' they should call them 'sftp512 and 'scp512.' The question is, who will write sftp1, sftp2, sftp3', ..., sftpn; and scp1, scp2, scp3, ..., scpn' where 'n' stands for record length of the file. If regular old FTP worked like that it wouldn't be around for as long as it has. Hopefully we all understand the implications.
Anyway, I'm done with the sarcastic remarks. Please forgive my diatribe, I couldn't resist :)

Is it true, definitively, that only files w/512 byte records can be transfered between OpenVMS hosts using scp/sftp? If so is there a zip application which I might find, for OpenVMS, whereby I can password protect the zip files I'm transfering while maintaining the fdl format?

Thanks for bearing with me!

Eric

[Steven Schweda]

> If I can only copy files with 512 byte
> records to other hosts with scp/sftp why
> in the world would anyone boast of these
> applications as solutions? [...]

Hammers may make very poor screwdrivers, but
that does not make them useless tools.

> Is it true, definitively, [...]

You distrust the documentation _and_ your
own experience (and plausible explanations)?

The usual Info-ZIP Zip/UnZip programs have
some built-in encryption features ("Zip -e"
and "UnZip -P" are the critical options, I
believe), but I have no experience with them,
and I don't know much about the encryption
quality (although it could be swell).

One could also use "Zip -V" (or even BACKUP,
with some extra fooling around) to ensure RMS
attribute preservation, then move the archive
(a fixed-512 file) using scp/sftp, and unpack
the result at the other end.

You could probably do something with separate
FDL files, too, but that sounds to me like
too much work

If you need Zip/UnZip with large-file (>2GB)
capability, let me know.