- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: RSH command exit status
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
Forums
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
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
10-03-2007 12:20 PM
10-03-2007 12:20 PM
A command like this
$ rsh /user=... /pass=...
does nicely display the condition and traceback from the remote node on the local node but only resolved into text.
I want the condition by condition code.
(Perhaps it is not included in what's returned from the remote node because the local node could be a Unix box and Unix only talks in ASCII. Still - you'd think that RSH could know who's it is talking to and furnish the condition code if OpenVMS).
Reverse lookup? Is there are a utility that will translate
%SYSTEM-F-ACCVIO, access violation
into
%XC
If no solutions then I thought I could at least return success or failure by checking for anything on sys$error. Is there an easy way to know if anything was written by RSH to sys$error? Or do I need to point it to a file and then read the file to check if it is empty or not?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2007 01:58 PM
10-03-2007 01:58 PM
SolutionGood question!
I haven't been able to work out a clean way to do this. In one case I have, the remote command should produce no output for success, so I test it like this:
$ PIPE RSH 'node'/USER='user' 'RemCmd' |-
READ SYS$PIPE result 2> nl: >nl:
$ IF $STATUS.EQS."%X1001827A" ! RMS_EOF
$ THEN
$ ! no output = success
$ ELSE
$ ! some output = failure
$ ENDIF
Not very pretty! (the "2> nl: >nl:" directs both SYS$OUTPUT and SYS$ERROR of the final pipe stage to NL: to surpress any error messages resulting from the READ)
If you wanted to determine more about the condition code, you could read and analyse the output, but remember it could be normal output from the remote command. If you want to do more than just read a line or two, pipe the output into a procedure.
Of course, if you have control of the code at the other end, you could arrange for it to output the status code as text and use something like:
$ PIPE RSH 'node'/USER='user' 'RemCmd' |-
(READ SYS$PIPE status ; -
DEFINE/JOB/NOLOG RSH_STATUS &status)
$ status=F$TRNLNM("RSH_STATUS")
(but again, this assumes no other output from the remote command).
The problem is you need a way to distinguish between the status of the RSH operation, and the status of the command executed on the remote node. Maybe something like "/STATUS=symbol" to specify the symbol into which any returned status was written?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2007 06:11 PM
10-03-2007 06:11 PM
Re: RSH command exit status
Is there a particular reason why a lot of services such as the inet services are not directly linkable from a user program (aside from the function interface not existing or not exported)?
I forgot to mention that what I'm doing is just that - an attempt at making a C wrapper for RSH - in 2 variations - one with and one without wait for completion of the command - for execution of command(line)s in general on a remote node. But as you also said - it is not pretty.
(submit/remote is an alternative to rsh but does not support most of the submit qualifiers such as for example command arguments and execution priority. But does have a function interface -sys$sndjbc.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2007 07:55 PM
10-03-2007 07:55 PM
Re: RSH command exit status
Sorry, I'm not sure why there aren't callable versions of TCPIP utilities, but it might be to do with privilege - note that several of the TCPIP images (including TCPIP$RSH) are installed with privilege. Although that can be fixed by turning tje, into system services, that takes work above and beyond just recompiling stock sources from the Unix world.
>(submit/remote is an alternative to rsh
>but does not support most of the submit
>qualifiers such as for example command
>arguments and execution priority. But does
>have a function interface -sys$sndjbc.)
See SYS$UPDATE:SUBMIT.CLD for limitations of /REMOTE
! V03-008 RRB0021 Rowland R. Bradley 19-Jun-1984
! Add the common qualifier package to both PRINT and
! SUBMIT. The qualifiers include /confirm, /exclude,
! /before, /since, /created, /modified, /expired, /backup,
! and /by_owner. Disallow /REMOTE with other qualifiers than
! the common qualifier ones.
...
disallow remote and (user or trailer or space or
setup or retain or restart or queue or
priority or passall or parameters or pages or
operator or notify or note or name
or lowercase or job_count or identify or hold
or header or form or flag or file_attributes
or feed or device or delete or copies
or characteristics or burst or attributes
or after)
why? Because the implementation of /REMOTE is really just a single bit in the RMS $CLOSE. All you do is open the remote file and close it with DISPOSE=SUBMIT. There is no mechanism for sending any of the additional job information to the remote node. To do anything more complex, the simplest way is to build your "real" SUBMIT command with all the appropriate qualifiers in a temporary procedure, copy it to the remote node, then SUBMIT/REMOTE that procedure.
Looking at your underlying issue, maybe you could look at the sources for RSH - if the "real" OpenVMS source isn't available, try a random Lunix distribution. It should give you details of the protocol, perhaps enough to write your own callable interface. The asynch version might be interesting... Evidence of the error message suggests the completion status is available, but it's not clear which end does the translation to a message.
If you're happy to use DECnet, the TASK object can be used to implement your own remote execution mechanism.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-04-2007 03:22 AM
10-04-2007 03:22 AM
Re: RSH command exit status
rsh is intended for interactive use, after all, and not scripted use.
Special-casing remote protocols for specific host-to-host operations -- FTP does this, using architected protocol extensions -- can tend to be a can of worms. Regardless, any change within the rsh/rexec is not going to happen here within your timeframe. (And all discussions of the results of vendor-private extensions ignored for now.)
As for typical implementations, this is where you see the codes from SMTP, http and other protocols. %xC, for instance, makes no sense outside of OpenVMS. Hence you see the 4xx failure codes of http, or the
How DECnet and OpenVMS operate and process condition status values is very different from that of Unix.
If you want to use this sort of thing, you'll end up either rolling your own protocol, using DECnet over IP, or using something akin to SOA and wrapping the command traffic.
One approach, for instance, is to use a web server to wrap the protocols.
For this particular case, another approach is to implement (or acquire) a package that provides distributed command scheduling and execution. Basically a distributed job scheduler, or a remote console system.
Yet another approach here is to use DECnet over IP. (Getting DECnet-Plus configured can take a little time and effort, but it gives you what you want with remote command execution and the easy ability to use DCL to read and write commands and to receive command responses. OpenVMS remote access from DCL works over IP.)
Or you pass back the status via show symbol or such at the end of the remote processing.
A classic tool that provides remote print queue processing -- the sort of approach that you could look at for implementing your own remote batch processing -- is the DQS package.
FWIW, tools such as rsh, telnet and SET HOST have always been semi-hairy and semi-risky solutions to remote command execution. Error processing tends to be the wrinkle.
If you want to see what you're basing your strategy on here, here's a baseline RFC:
http://tools.ietf.org/html/rfc1282
IIRC, rsh uses two of these rlogin streams, one for error and one for normal output.
Probably far more detail than what you wanted...