topic Re: Translating TCPIP status codes to text via $GETMSG in Operating System - OpenVMS

Translating TCPIP status codes to text via $GETMSG

Joe Huber — Sun, 27 Aug 2006 13:38:04 GMT

This is on OpenVMS V7.3-2. The code making the relevant calls is written in Alpha BASIC V1.5-000.

I have a process running that among a number of other things keeps an eye on jobs going through a queue. Part of keeping an eye is to record the entry in a log file then remove the job (all jobs are retained).

$GETMSG is used to translate the status values coming back from $GETQUI.

Question: What do I have to include and/or link against in order to be able to translate TCPIP related status values along the lines of the following is the function that is making the $GETQUI calls?

%include "$jbcmsgdef" %from %library "sys$library:basic$starlet"
%include "$lnmdef" %from %library "sys$library:basic$starlet"
%include "$psldef" %from %library "sys$library:basic$starlet"
%include "$quidef" %from %library "sys$library:basic$starlet"
%include "$sjcdef" %from %library "sys$library:basic$starlet"
%include "$ssdef" %from %library "sys$library:basic$starlet"

As is I get an status that can't be translated into text for TCPIP related problems:

Entry JobName Username Status
----- ------- -------- ------
2373 > xxxxxx xxx xxxxxxxxxx Retained on error
%NONAME-E-NOMSG, Message number 17649ABA
Submitted 22-AUG-2006 00:03:54.38 /PRIORITY=100
/LOG=$1$DGA1500:[xxx.yyyyyyyyyy.zzz]xxxxxx_xxx_xxx.LOG;
File: _$1$DGA1500:[xxx.xxxxxxxxxx.xxxxxxxx]xxx_xxxxxx_xxx_xxx.COM;yy
Completed 22-AUG-2006 04:06:23.54 on queue ABFQUEUE

I would rather have the %TCPIP-E-FTP_NETERR, I/O error on network device in the log file.

TIA

Re: Translating TCPIP status codes to text via $GETMSG

John Gillings — Sun, 27 Aug 2006 19:40:26 GMT

Joe,

Note there's a difference between the symbols for defining the symbolic names for condition codes (for example, $SSDEF gives you definitions for SS$_NORMAL etc...) and the translation from a condition code into a message string.

The latter can be found in the message files in SYS$MESSAGE. TCPIP messages are in TCPIP$MSG.

As noted in the $GETMSG documentation, message files are searched as:

------------------------
1) All message sections linked into the currently executing image are searched for the associated information.

2) If the information is not found, the process-permanent message file is searched. (You can specify the process-permanent message file by using the SET MESSAGE command.)

3) If the information is not found, the systemwide message file is searched.

4) If the information is not found, the SS$_MSGNOTFND condition value is returned in R0 and a message in the following form is returned to the caller's buffer:
%facility-severity-NONAME, message=xxxxxxxx[hex], (facility=n, message=n[dec])
--------------------

By default, TCPIP$MSG is not found by any of these methods.

You can override the defaults with:

$ SET MESSAGE SYS$MESSAGE:TCPIP$MSG

prior to running your program. The result is $GETMSG will find that particular message. You can explicitly link TCPIP$MSG into your image with an options file:

TCPIPMSG.OPT
SYS$MESSAGE:TCPIP$MSG/SHARE

However, at run time you will need a logical name:

$ DEFINE TCPIP$MSG SYS$MESSAGE:TCPIP$MSG

You can avoid both linking and defining the logical name if you activate TCPIP$MSG at run time with LIB$FIND_IMAGE_SYMBOL.

Note this only solves the issue for TCPIP messages. Other facilities will need to be handled independently.

Re: Translating TCPIP status codes to text via $GETMSG

Joe Huber — Wed, 06 Sep 2006 16:59:33 GMT

I've been absorbed with another part of the code...

This runs as a detached process which makes the dynamic linking (as I guess it would be called) appealing. What do I specific for the symbol (argument 2)??

I have been pulling my hair out getting %LIB-E-KEYNOTFOU, key not found in tree when I make the call. I happened to modify a little stub program to call $GETMSG as follows on a whim after much anguish:

option type = explicit, constant type = integer, size = integer long

declare word msglen
declare integer this
declare string tmpstr

tmpstr = space$(255)

call sys$getmsg(392469178 by value,msglen,tmpstr,15 by value,)
print seg$(tmpStr,1,msglen)
sleep 3

call lib$find_image_symbol('TCPIP$MSG','',THIS,'SYS$MESSAGE:.EXE')
call sys$getmsg(392469178 by value,msglen,tmpstr,15 by value,)
print seg$(tmpStr,1,msglen)

$ r x
%NONAME-E-NOMSG, Message number 17649ABA
%LIB-E-KEYNOTFOU, key not found in tree
%TRACE-E-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
LIBRTL 0 0000000000070894 FFFFFFFF8089A894
LIBRTL ? ?
DEC$BASRTL 0 000000000000EE54 000000007C018E54
----- above condition handler called with exception 001582FA:
%LIB-E-KEYNOTFOU, key not found in tree
----- end of exception message
0 FFFFFFFF800A209C FFFFFFFF800A209C
LIBRTL 0 0000000000087C7C FFFFFFFF808B1C7C
LIBRTL ? ?
X X$MAIN X$MAIN 14 00000000000001DC 00000000000201DC
0 FFFFFFFF8026FED4 FFFFFFFF8026FED4
%TCPIP-E-FTP_NETERR, I/O error on network device

so it does translate the value at that point but the trace is less than desirable (or am I doing something wrong and it's translating the value in the 2nd call "by dumb luck")?

Re: Translating TCPIP status codes to text via $GETMSG

Hein van den Heuvel — Wed, 06 Sep 2006 22:33:39 GMT

>> so it does translate the value at that point but the trace is less than desirable

(unfortunately?) the Shareable Message Images do not have a (Dummy) symbol to go find.

And LIB$FIS will signal a warning when it can not find the targetted symbol (none), after mappnig the image.

So as par LIB$FIS documentation you will have to come up with a SIGNAL HANDLER and it can not be the simple LIB$SIGNAL_TO_RET. :-(.

It would be kind of nice to have a real symbol to look for in message file. The value could even be useful, perhaps the message base.

It would be kind of nice if one of those 'reserved' bits for the flag to LIB$FIS would say 'don't bother to signal, just return'

see also:

http://www.tmk.com/ftp/multinet-contributed-software/mm/deliver_pmdf.c

http://h71000.www7.hp.com/DOC/82final/5932/5932pro_018.html

Try this:

option type = explicit, constant type = integer, size = integer long, &
handle=ERROR

when ERROR use my_handler

declare word msglen
declare integer this
declare string tmpstr

tmpstr = space$(255)

call sys$getmsg(392469178 by value,msglen,tmpstr,15 by value,)
print seg$(tmpStr,1,msglen)
sleep 3

call lib$find_image_symbol('TCPIP$MSG','TCPIP$_ACPQIO',THIS,'SYS$MESSAGE:.EXE')

call sys$getmsg(392469178 by value,msglen,tmpstr,15 by value,)
print seg$(tmpStr,1,msglen)

end when

handler my_handler
print "Hello!"
continue
end handler

------

$ run tmp
%NONAME-E-NOMSG, Message number 17649ABA
Hello!
%TCPIP-E-FTP_NETERR, I/O error on network device
$ lo

hth,

Hein
HvdH Performance Consulting

Re: Translating TCPIP status codes to text via $GETMSG

John Gillings — Sun, 10 Sep 2006 18:24:42 GMT

Joe,

LIB$FIND_IMAGE_SYMBOL has a nasty habit of signalling all conditions. Apologies, I just assumed you'd know how to deal with that.

Here's a little MACRO32 routine that accepts the name of a message file by descriptor and maps it. It uses LIB$SIG_TO_RET to catch the signalled error an convert it into a return status. You can either ignore the return status and assume your file name was correct, or test it, but accept KEYNOTFOU as success.

.title mapmsgfile
.psect $data,rd,nowrt,noexe
nosym: .ASCID /NONE/
msgdir:.ASCID /SYS$MESSAGE:.EXE/

.psect $code,rd,nowrt,exe
.entry MapMsg,^m<>
MOVAL G^LIB$SIG_TO_RET,(FP)
MOVAL -(SP),R0
PUSHAB msgdir
PUSHL R0
PUSHAB nosym
PUSHAB @4(AP)
CALLS #4,G^LIB$FIND_IMAGE_SYMBOL
RET
.END

Re: Translating TCPIP status codes to text via $GETMSG

Joe Huber — Mon, 11 Sep 2006 08:53:26 GMT

MACRO32... (wow)... it's pushing 8 years since the last time I looked at any MACRO.

I am reluctant to admit it but I should have known how to catch the signal (as well as $FIND_IMAGE_SYMBOL solution). The last 6+ years I've been in a "non-technical" environment and seems as if after a while without use you start forgetting things (spend a moment commiserating).

In any event- thanks for the follow-up.
Joe