Discussion:
Problems with SCP2
(too old to reply)
Fairfield, Ken :CO IR
2007-09-26 23:00:20 UTC
Permalink
Background first:

============================================================================
====
$ mu show/vers
Process Software MultiNet V4.4 Rev A-X, hp AlphaServer GS1280 7/1300,
OpenVMS AX
P V7.3-2
$ typ multinet:multinet_version.
VERSION V4.4
REVISION A-X
DATE 30-Jan-2002
PRODUCER PSC
INSTALLED_IPAPPS YES
[...]
XREPLACED MULTINET.VUI KERNEL-UPDATE-060_A044 24-JUN-2003
XREPLACED LOADABLE_KR_SERVICES.VUI
LOADABLE_R_SERVICES-010_A04
4 24-JUN-2003
XREPLACED LOADABLE_R_SERVICES.VUI
LOADABLE_R_SERVICES-010_A044
24-JUN-2003
[...]
XREPLACED SCP-SERVER1.VUI SSH-051_A044 24-JUN-2003
XREPLACED SCP2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SFTP-SERVER2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-ADD2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-AGENT2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-KEYGEN.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-KEYGEN2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-PROBE2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-SIGNER2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD2_CONFIG_TEMPLATE.VUF SSH-051_A044
24-JUN-2003
XREPLACED SSHD_MASTER.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHLEI.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHREGEX_TXT.VUF SSH-051_A044 24-JUN-2003
XREPLACED START_SSH_COM.VUF SSH-051_A044 24-JUN-2003
[...]
============================================================================
====

We have had a process in place for the past 2-3 years using SCP2 in command
procedure to transfer files to a remote site. It failed today and I've been
(1) learning about the process and (2) trying to find where it's failing.

In the process of debugging, I create a short text file and used the command
constructed in the transfer procedure to try to push it to the remote site.
I get the following failure, where names and addresses have been changed to
protect the guilty parties:

============================================================================
====

$ typ sys$login:test.txt
Testing Health Century 2008 transfers
from Legacy Health System.
Please discard this file if found.
$ show symbol scrp
SCRP = "MU SCP2 SYS$LOGIN:TEST.TXT "***@111.444.222.555::""
$ scrp

SCP2: warning: test.txt (src): got EOF reading file (server msg:
'Encountered EO
F.')
$

============================================================================
====

However, if I make some arbitrary edit to the file, I can make the transfer
succeed (not every change, but some "magic"). With the following version
of text.txt, I get an apparently successful transfer:

$ typ sys$login:test.txt
Testing Health Century 2008 transfers from LGCY_OR.
$ scrp
test.txt | 53B | 0.1 kB/s | TOC: 00:00:01 | 100%
$

============================================================================
====

QUESTION: Is the "SCP2: warning: test.txt ..." error message a problem on
the Multinet side, or on the remote side? How do I avoid this?

Thanks, Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209

Phone: 503-415-5836, FAX: 503-415-5899, Email: ***@LHS.org



IMPORTANT NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended solely
for the entity or individual to whom it is addressed. If you are not the
intended recipient, you should contact the sender and delete the message.
Any unauthorized disclosure, copying, or distribution of this message is
strictly prohibited. Nothing in this email, including any attachment, is
intended to be a legally binding signature.
David J Dachtera
2007-09-27 00:02:18 UTC
Permalink
Post by Fairfield, Ken :CO IR
============================================================================
====
$ mu show/vers
Process Software MultiNet V4.4 Rev A-X, hp AlphaServer GS1280 7/1300,
OpenVMS AX
P V7.3-2
$ typ multinet:multinet_version.
VERSION V4.4
REVISION A-X
DATE 30-Jan-2002
PRODUCER PSC
INSTALLED_IPAPPS YES
[...]
XREPLACED MULTINET.VUI KERNEL-UPDATE-060_A044 24-JUN-2003
XREPLACED LOADABLE_KR_SERVICES.VUI
LOADABLE_R_SERVICES-010_A04
4 24-JUN-2003
XREPLACED LOADABLE_R_SERVICES.VUI
LOADABLE_R_SERVICES-010_A044
24-JUN-2003
[...]
XREPLACED SCP-SERVER1.VUI SSH-051_A044 24-JUN-2003
XREPLACED SCP2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SFTP-SERVER2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-ADD2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-AGENT2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-KEYGEN.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-KEYGEN2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-PROBE2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-SIGNER2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD2_CONFIG_TEMPLATE.VUF SSH-051_A044
24-JUN-2003
XREPLACED SSHD_MASTER.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHLEI.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHREGEX_TXT.VUF SSH-051_A044 24-JUN-2003
XREPLACED START_SSH_COM.VUF SSH-051_A044 24-JUN-2003
[...]
============================================================================
====
We have had a process in place for the past 2-3 years using SCP2 in command
procedure to transfer files to a remote site. It failed today and I've been
(1) learning about the process and (2) trying to find where it's failing.
In the process of debugging, I create a short text file and used the command
constructed in the transfer procedure to try to push it to the remote site.
I get the following failure, where names and addresses have been changed to
============================================================================
====
$ typ sys$login:test.txt
Testing Health Century 2008 transfers
from Legacy Health System.
Please discard this file if found.
$ show symbol scrp
$ scrp
'Encountered EO
F.')
$
============================================================================
====
However, if I make some arbitrary edit to the file, I can make the transfer
succeed (not every change, but some "magic"). With the following version
$ typ sys$login:test.txt
Testing Health Century 2008 transfers from LGCY_OR.
$ scrp
test.txt | 53B | 0.1 kB/s | TOC: 00:00:01 | 100%
$
============================================================================
====
QUESTION: Is the "SCP2: warning: test.txt ..." error message a problem on
the Multinet side, or on the remote side? How do I avoid this?
Any chance to see a DUMP(/BLOCK) of both files from the source node?
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Ken Connelly
2007-09-26 23:58:10 UTC
Permalink
Ken -

My view is that it's a warning and not really a problem. scp comes from
the unix world where there is no inherent distinction between types of
files (binary vs. ascii). If you look at the file on the remote end, I
think you'll find that it's just as expected (although perhaps missing
an EOF character at the end).

I encounter this warning all the time when transferring "text" files
from a VMS box to a unix machine. I have never found it to be a real
concern.

If the return code generated from the scp warning is causing a problem
with a command procedure not finishing, using an appropriate "$ on ..."
statement in the command procedure should solve that.

- ken, the other
Post by Fairfield, Ken :CO IR
============================================================================
====
$ mu show/vers
Process Software MultiNet V4.4 Rev A-X, hp AlphaServer GS1280 7/1300,
OpenVMS AX
P V7.3-2
$ typ multinet:multinet_version.
VERSION V4.4
REVISION A-X
DATE 30-Jan-2002
PRODUCER PSC
INSTALLED_IPAPPS YES
[...]
XREPLACED MULTINET.VUI KERNEL-UPDATE-060_A044 24-JUN-2003
XREPLACED LOADABLE_KR_SERVICES.VUI
LOADABLE_R_SERVICES-010_A04
4 24-JUN-2003
XREPLACED LOADABLE_R_SERVICES.VUI
LOADABLE_R_SERVICES-010_A044
24-JUN-2003
[...]
XREPLACED SCP-SERVER1.VUI SSH-051_A044 24-JUN-2003
XREPLACED SCP2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SFTP-SERVER2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-ADD2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-AGENT2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-KEYGEN.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-KEYGEN2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-PROBE2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH-SIGNER2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSH2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD2.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHD2_CONFIG_TEMPLATE.VUF SSH-051_A044
24-JUN-2003
XREPLACED SSHD_MASTER.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHLEI.VUI SSH-051_A044 24-JUN-2003
XREPLACED SSHREGEX_TXT.VUF SSH-051_A044 24-JUN-2003
XREPLACED START_SSH_COM.VUF SSH-051_A044 24-JUN-2003
[...]
============================================================================
====
We have had a process in place for the past 2-3 years using SCP2 in command
procedure to transfer files to a remote site. It failed today and I've been
(1) learning about the process and (2) trying to find where it's failing.
In the process of debugging, I create a short text file and used the command
constructed in the transfer procedure to try to push it to the remote site.
I get the following failure, where names and addresses have been changed to
============================================================================
====
$ typ sys$login:test.txt
Testing Health Century 2008 transfers
from Legacy Health System.
Please discard this file if found.
$ show symbol scrp
$ scrp
'Encountered EO
F.')
$
============================================================================
====
However, if I make some arbitrary edit to the file, I can make the transfer
succeed (not every change, but some "magic"). With the following version
$ typ sys$login:test.txt
Testing Health Century 2008 transfers from LGCY_OR.
$ scrp
test.txt | 53B | 0.1 kB/s | TOC: 00:00:01 | 100%
$
============================================================================
====
QUESTION: Is the "SCP2: warning: test.txt ..." error message a problem on
the Multinet side, or on the remote side? How do I avoid this?
Thanks, Ken
Richard Whalen
2007-09-27 12:55:27 UTC
Permalink
Post by Fairfield, Ken :CO IR
============================================================================
====
$ typ sys$login:test.txt
Testing Health Century 2008 transfers
from Legacy Health System.
Please discard this file if found.
$ show symbol scrp
$ scrp
'Encountered EO
F.')
$
You get this message because the code to get the size of the file returns an
estimate and the code that actually transfers the data expects the exact
number of bytes to be transferred. The difference in byte counts comes from
the automatic conversion of the file from a VMS file with records to
stream-lf format so that the remote side can handle it. The estimating code
always returns a value that is greater than or equal to the actual number of
bytes to be transferred.

If you add /ascii to the command, then the message should go away as the
code accepts differences in ASCII transfers. You may also want to define
the logical MULTINET_SFTP_NEWLINE_STYLE UNIX beforehand to minimize the
amount of work that needs to be done substituting different newline styles
during the transfer.
Ken Connelly
2007-09-27 13:28:04 UTC
Permalink
Post by Richard Whalen
Post by Fairfield, Ken :CO IR
============================================================================
====
$ typ sys$login:test.txt
Testing Health Century 2008 transfers
from Legacy Health System.
Please discard this file if found.
$ show symbol scrp
$ scrp
'Encountered EO
F.')
$
You get this message because the code to get the size of the file returns an
estimate and the code that actually transfers the data expects the exact
number of bytes to be transferred. The difference in byte counts comes from
the automatic conversion of the file from a VMS file with records to
stream-lf format so that the remote side can handle it. The estimating code
always returns a value that is greater than or equal to the actual number of
bytes to be transferred.
If you add /ascii to the command, then the message should go away as the
code accepts differences in ASCII transfers. You may also want to define
the logical MULTINET_SFTP_NEWLINE_STYLE UNIX beforehand to minimize the
amount of work that needs to be done substituting different newline styles
during the transfer.
Hmmm.... Even at my advanced age, there are still things to learn.
Imagine that! Thanks, Richard!!
--
- Ken
=================================================================
Ken Connelly Associate Director, Security and Systems
ITS Network Services University of Northern Iowa
email: ***@uni.edu p: (319) 273-5850 f: (319) 273-7373
Fairfield, Ken :CO IR
2007-09-27 21:06:02 UTC
Permalink
First let me say I appreciate the quick responses from everyone.
Info-Multinet is the best. :-)
Post by Richard Whalen
You get this message because the code to get the size of the file returns
an
Post by Richard Whalen
estimate and the code that actually transfers the data expects the exact
number of bytes to be transferred. The difference in byte counts comes
from
Post by Richard Whalen
the automatic conversion of the file from a VMS file with records to
stream-lf format so that the remote side can handle it. The estimating
code
Post by Richard Whalen
always returns a value that is greater than or equal to the actual number
of
Post by Richard Whalen
bytes to be transferred.
If you add /ascii to the command, then the message should go away as the
code accepts differences in ASCII transfers. You may also want to define
the logical MULTINET_SFTP_NEWLINE_STYLE UNIX beforehand to minimize the
amount of work that needs to be done substituting different newline styles
during the transfer.
I have two potential problems. As I said yesterday, I'm just in the
initial troubleshooting stages. It's not clear to me that the actual
procedure transfer ascii data. (No need to comment on that, the
process has been working correctly for quite some time.)

The first problem is that, in my re-testing today, I found that when the
"SCP2: warning: ..." message occurs, $STATUS returns an ERROR severity code:

============================================================================
==
$ sho sym scrp
SCRP = "MU SCP2 TEST.TXT "***@111.444.999.555::""
$ scrp
test.txt | 53B | 0.1 kB/s | TOC: 00:00:01 | 100%
$ sts1 = $status
$ dr test.txt

Directory DISK500:[USER]

TEST.TXT;5 1/35 26-SEP-2007
15:38:28.09
TEST.TXT;4 1/35 26-SEP-2007
15:37:41.66

Total of 2 files, 2/70 blocks.
$ dele TEST.TXT;5
$ scrp

SCP2: warning: test.txt (src): got EOF reading file (server msg:
'Encountered EO
F.')
$ sts2 = $status
$ sho sym sts%
STS1 = "%X1C1F80B1"
STS2 = "%X1C1F805A"
$
============================================================================
==

So to the extent that the code makes a valid check of $STATUS (it looks like
it does), it takes an error-exit rather than continuing with normal
processing.
That is, the SCP2 warning isn't really "ignorable".

The second problem is that this is a vendor supplied procedure that I
hesitate to change it, i.e., by adding /ascii etc., without engaging the
vendor and doing more thorough testing.

I guess I'm somewhat surprised that a "normal error" like this would return
a error-severity status. Either it's something the user can take care of,
and thus needs to handle and/or correct the error, or it's beyond the user's
control (and apparently does no harm), so the status should be successful.
This seems to fall in the latter category.

Anyway, I this is all academic for now since the problem was at the vendor's
remote site... Thanks for all the answers.

-Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209

Phone: 503-415-5836, FAX: 503-415-5899, Email: ***@LHS.org



IMPORTANT NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended solely
for the entity or individual to whom it is addressed. If you are not the
intended recipient, you should contact the sender and delete the message.
Any unauthorized disclosure, copying, or distribution of this message is
strictly prohibited. Nothing in this email, including any attachment, is
intended to be a legally binding signature.
Loading...