How to find out which message libraries are attached to your process?

[Kortlandt]

HiYa,

Recently I was looking into a LPD printing problem, and I found a "%NONAME-E-NOMSG, Message number 0764A072". So I "SET MESSAGE SYS$MESSAGE:TCPIP$MSG.EXE", and the message appeared.

But how can one find out which libraries are "set", and what is "set" by default?

SET MESSAGE or SHOW MESSAGE won't do the trick, maybe look for open (message) files attached to your process? And the defaults are the open message libraries files not attached to a process?

Thnx,
Bob Kortlandt

[labadie_1]

You can see with

pipe sh dev/fil sys$sysdevice | sea sys$pipe sysmsg

the message files opened by the processes on your system, but I am not sure there is a way to link a process and the "associated" message file.

[H.Becker]

The shown pipe command may be suffcient for you. If you look for the process ID, you will see the message file(s). At DCL level, there should be at most one file per process. If the process is running an image, then the pipe command may show more than one message file. Then you may want to use SDA.

This message file is a process permanent process section.

SDA> show proc/proc

and the first section shown should be the message file, if there is any.

[John Gillings]

Bob,

This is another missing piece of DCL. However, although symmetry would suggest there should be a way to see which message file is currently set, it wouldn't be terribly useful (which is probably why it's never been implemented). As Gerard and Helmut have suggested, there are some round about (and privileged) ways to figure it out. Note that DCL only has ONE message file. SET MESSAGE replaces the existing one with the new one. The default is SYS$MESSAGE:SYSMSG. User mode programs can have as many as resources allow. They can be seen as global sections from SDA or DEBUG.

What IS useful is a mechanism for finding the text of a particular message which interprets as NONAME/NOMSG using whatever message file you're currently attached to.

The usual trick is to walk through SYS$MESSAGE, testing your code against any message files found until you get what looks like a reasonable translation. I've attached my version of MSGTXT.COM. There are lots of other implementations, essentially the same.

[Murali L.R.]

Hi,
One more COM procedure example.
http://wwwvms.mppmu.mpg.de/util_root/com/FIND_MESSAGE.COM

This procedure scans the specified message files trying to translate a VMS status value.

Regards,
Murali