RSH command exit status

[Claus Olesen]

Anyone know of a way to get the completion status of the command executed using RSH on an OpenVMS system?

A command like this
$ rsh /user=... /pass=... "mcr accvio.exe"

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?

[John Gillings · Accepted solution]

Claus,

Good 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?

[Claus Olesen]

Thanks, John.

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.)

[John Gillings]

Claus,

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.

[Hoff]

Unless there's a status returned within the protocol (eg: a 404 returned via http), the OpenVMS concept of an exit status just isn't something typically returned from a remote invocation.

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...