SSH from VMS: return codes

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi all,

I have this script on Unix...

$ cat .bin/
echo "$1"
exit "$1"

Yes, that's right, it echoes a number to stdout and exits the script
with that same number.  I'm using this to test the return code you get
when calling the above from VMS.

I'm calling the above from VMS like so
 VMSprompt> ssh user@unixbox ./ 1
...for example, to return

It seems VMS doesn't like the concept of ZERO - 1 means 'good' in VMS
land. You can report the return code in VMS like so:
write sys$output  $status
...shows return-code in HEX
write sys$output  $severity
...shows return-code in decimal (or is it octal? read on). Here's an
example of the return code passed back by the script, and the values
reported by $status & $severity...

Return   $severity   $status
0        1           %X00000001
1        1           %X00000001
2        2           %X00000002
3        3           %X00000003  (script hangs here?)
4        4           %X00000004
5        5           %X00000005
6        6           %X00000006
7        7           %X00000007
8        0           %X00000008  looks like $severity reset to 0 ?!
9        1           %X00000009
10       2           %X0000000A
11       3           %X0000000B
12       4           %X0000000C
13       5           %X0000000D
14       6           %X0000000E
15       7           %X0000000F
16       0           %X00000010  ...and $severity back to 0.

Has anyone out there figured how to get the 'true' return code from a
unix sheel script like this?  I know we could grab some stdout and
process this, but there's got to be a better way!?


Re: SSH from VMS: return codes

OK, here's the solution I've gone with.

VMS reliably reports return codes from 1 upwards, but 0 is reported as
a 1. So, I've ensured that any script on Unix called by a VMS system
will never use 1 as a return code. The Unix scripts will still use 0,
so that other unix scripts can get a proper unix-style 'success' code.
But when zero is returned to VMS, it will get reported as a 1.
However, the VMS system knows I'll never report 1 for anything else,
so it can safely interpret 1 as 'success'. I just bumped all my return
codes up by 1...

Example return codes now used by my Unix script...
4 - File not found
3 - File still being written to locally
2 - failed to get/push file (check logs for details)
1 - Do NOT use. Confused with return-code 0 on VMS
0 - transferred file successfully   (reported as 1 on VMS)

RE: SSH from VMS: return codes

Quoted text here. Click to load it

    The severity is merely the lower three bits of the return code.  I'm
not sure why VMS is treating zero differently.  It's entirely possible that
it's trying to be user-friendly (for the VMS user), though, and assuming it
needs to translate the zero return code from Unix/Linux meaning normal
completion into the equivalent under VMS, which is one, as you've observed.

Quoted text here. Click to load it

                                         |    Systems Specialist: CBE,MSE
         Michael T. Davis (Mike)         | Departmental Networking/Computing |     The Ohio State University
                                         |     197 Watts, (614) 292-6928

Re: SSH from VMS: return codes

Quoted text here. Click to load it

For VMS odd values are successful, even values are not.
In reality, the low 3 bits signify error/success (1 = success, 2 = error, 3
= informational, 4 = fatal error), and the remaining bits identify the
facility and message that corresponds to the error.
The translation of 0 to 1 may be part of Unix C compatibility.

RFC 4254 specifies that status value may returned, but does not specify any
meaning for the status values.

Signal values are well defined by the RFC, but status values are not.

Richard Whalen
Process Software

Site Timeline