- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- SITE command AT&T claims, FTP command coming from ...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-11-2014 08:02 AM
09-11-2014 08:02 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-11-2014 03:27 PM
09-11-2014 03:27 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-11-2014 06:23 PM
09-11-2014 06:23 PM
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"
$
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-14-2014 08:26 AM
09-14-2014 08:26 AM
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?