Operating System - OpenVMS
1748171 Members
3995 Online
108758 Solutions
New Discussion

SITE command AT&T claims, FTP command coming from OpenVMS TCP/IP - FTP utility to a Linux server

 
Tom Wetty
Advisor

SITE command AT&T claims, FTP command coming from OpenVMS TCP/IP - FTP utility to a Linux server

 My computer is running the following software configuration:

 

 

*  HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 2
  on an HP rx2660  (1.59GHz/12.0MB) running OpenVMS V8.4

 

*$ftp
show status
Not connected.
VMS Plus mode disabled
Mode = stream , Type = ascii, Form = non_print, Structure = file
Error level is SUCCESS
Passive is AUTO (IPv4: OFF, IPv6: ON).

I have the following questions: 

 

Does the SITE command automatically write from OpenVMS, even though my site's software configuration  has VMS Plus Mode disabled ? 

 

How come the FTP job log in OpenVMS  is not recording commands it is issuing ; or is this just AT&T's engineering attempt to send me on a wild chase ?

 

How come the very same FTP procedure will work sometimes and arbitraily abort remotely when connected to the Linux computer ?

 

I get a STATUS code of $STATUS == "%X17649BC0"   when I set $ ftpstatus=$STATUS

 

All help would be appreciated all this manual rework is killing me.

 

Procedure looks like the follwing... USERNAME AND PASSWORD is hidden...

 

$set verify
$ ftpstatus=$STATUS
$ftp
connect sapp45.vwr.com
******
******
disable parse
cd qsswip
put wms$$upl_files:zcrs_8013_20140910_09365900.seq zcrs_8013_20140910_09365900.^
rename zcrs_8013_20140910_09365900.seq  zcrs_8013_20140910_09365900.dat
dir
exit
$ show symbol $STATUS
$ rename wms$$upl_files:zcrs_8013_20140910_09365900.seq wms$$upl_files:zcrs_801^
$exit ftpstatus

 

 

3 REPLIES 3
John Gillings
Honored Contributor

Re: SITE command AT&T claims, FTP command coming from OpenVMS TCP/IP - FTP utility to a Linux s

Tom,

 

    Your status code "%X17649BC0" translates into

 

%TCPIP-W-FTP_TRANSIENT, FTP TRANSIENT return code

 

  This means something went wrong that isn't a permanent or "hard" failure. So, for example, an unreachable node would be a permanent failure. If you managed to establish a connection, but during the transfer some threshold of lost packets was exceeded, that would be a "transient" error. This suggests there may be something flakey about the network between your nodes. There may be more information in log files at either or both ends, or in the network counters at various levels of the network stack.

 

>FTP procedure will work sometimes and arbitraily abort

 

  further evidence for my guess above...

 

>FTP job log in OpenVMS  is not recording commands

 

  There are different levels of logging for FTP. It's a balance between getting useful trace information and filling disks unnecessarily. Typically the default level of logging errs on the side of conserving disk space. If you're debugging, you (or your system manager) should increase the level of logging. See the FTP documentation for the mechanisms and range of options.

 

>Does the SITE command automatically

 

  I don't understand this question, but I doubt it's relevant.

 

Taking a wild stab in the dark, my guess would be you have a duplex mismatch. This occurs when the network adapter at one end of a network cable is set to "autonegotiate" and the other end is hard set to a particular speed and duplex setting. You either need both ends "autonegotiate" or both ends to the same speed and duplex. My preferred configuration is to set everything to "autonegotiate". (in the dim and distant past there were issues with some very specific adapters having trouble negotiating speed and duplex, but unless you have steam powered systems, they have long since been resolved, unfortunately the mythology that "OpenVMS can't do autonegotiation" has persisted - about the only good thing about this is it's improved the job security of a lot of support engineers)

 

So, check ALL the cables in the network path between you and the remote system. I don't want to hear "it's been working for years!". I'm sure it has. Duplex mismatched connections WILL WORK until you start to increase the load, (like, for example, a reasonably sized FTP transfer) at which point you'll start dropping packets. This will manifest as a slower than expected transfer, FTP_TRANSIENT errors, or any of a myriad of other confusing and inconsistent symptoms.

 

A crucible of informative mistakes
Hoff
Honored Contributor

Re: SITE command AT&T claims, FTP command coming from OpenVMS TCP/IP - FTP utility to a Linux s

Given the choice, sftp — even though that doesn't have a command line option — is usually preferable.  It's certificate-based and more secure and encrypts the traffic, and it requires only one port through the firewall.

 

If you do persist in the wildly-insecure  FTP, please switch to and use COPY /FTP here, and not the FTP utility command prompt.  COPY /FTP is far easier to script.  

 

Here's an example FTP PUT command, assuming fairly complex syntax and a remote Unix file system:

 

COPY/FTP local.tmp foo.example.com"user pass"::"/path/to/file/remote.tmp" 

 

Please also don't bother to redact your login credentials when posting FTP questions, too.  Yes, please feel free to post your host, username, and password.  Either here, or pretty much anywhere you want.  Why?  Because that's exactly what you're doing when you use FTP, and anybody that can eavesdrop on your connections already has your login credentials.  FTP is wildly insecure. 

 

As for connectivity, FTP and firewalls are a longstanding conflict, and either the firewall needs to sniff the FTP traffic to open up the second connection through during the initialization of the FTP connection, or the firewall needs to trigger and open up the ephemeral port range, or the ephemeral port range (or whatever range the FTP server is using) needs to be opened.

 

This can also be a flaky network, as Mr Gillings references.  That's a trip through the logs, and — preferably — a move to COPY/FTP commands to make it easier to spot which command(s) fail.

 

FWIW, I'd be cautious around filenames with $ signs, particularly if Unix systems are involved.

 

Given FTP is also a festering pile of ancient and buggy, it can't be banished soon enough.   Given the choice, please get sftp going, punch through TCP port 22 to the remote servers, and use that where you can.

 

ps: Translating that error:

 

$ set mess sys$message:tcpip$msg.exe

$ x=f$message(%X17649BC0)

$ show symbol x

  X = "%TCPIP-W-FTP_TRANSIENT, FTP TRANSIENT return code"

$

Steven Schweda
Honored Contributor

Re: SITE command AT&T claims, FTP command coming from OpenVMS TCP/IP - FTP utility to a Linux s

> Does the SITE command automatically write from OpenVMS, [...]

   Apparently the TCPIP FTP client sends a SITE command.  Around here,
for example:

alp $ tcpip show version

  HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 5
  on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.3    

alp $ ftp
FTP> debug on
Debugging on (debug=1).
FTP> open alp-l
220-   Antinode FTP Server.  Please be nice.
220 alp.antinode.info FTP Server (Version 5.6) Ready.
Connected to alp-l.antinode.info.
Name (alp-l.antinode.info:sms):
--->  USER sms
331 Username sms requires a Password
Password:

--->  PASS
 230 User logged in.
--->  SITE +VMS+
FTP> quit
--->  QUIT
221 Goodbye.

>  even though my
>  site's software configuration  has VMS Plus Mode disabled ?

   What does that mean, exactly?

 

> How come the FTP job log in OpenVMS  is not recording commands it is
> issuing ; [...]

   I don't know.  Perhaps it records only the important ones.

>  or is this just AT&T's engineering attempt to send me on a
> wild chase ?

   Should any non-psychic know what you're talking about here?

> How come the very same FTP procedure will work sometimes and arbitraily
> abort remotely when connected to the Linux computer ?

   With my weak psychic powers, I don't know exactly what in this "FTP
procedure" is failing.  Do you?