VMS Message files (.MSG) and Shareable images

[Jeremy Begg]

Hi,

I am writing an application on OpenVMS V8.3 (Alpha and IA64). The application has an API which is supplied as a shareable image (APISHR.EXE). There is also a server program (SERVER.EXE) and a client program (CLIENT.EXE). Both client and server are linked against APISHR.

My application source code includes a VMS message definition (.MSG) file which is compiled using the MESSAGE Utility and the resulting object file is inserted into an object library. I also have definition files in C and Pascal which define compile-time constants equal to the values of the various messages. For example, in Pascal:

CONST APPL__SUCCESS = 143753225;

So far so good, all modules compile and link without errors.

The problem is that the object file produced from the message library isn't being used anywhere, and doesn't get included into any of the three images. The message status values are all defined as compile-time constants so the compilers don't generate any external references and the linker doesn't need to resolve them. This causes a problem when the code goes to report an error using any of the standard routines such as LIB$SIGNAL, SYS$GETMSG or SYS$PUTMSG. It also means the Debugger can't do "EXAM/COND ...", e.g.

DBG> exam/cond scan_result
CLIENT\CLIENT\CMD___SCAN\SCAN_RESULT: %NONAME-W-NOMSG, Message number 08919F48
DBG>

So I'm wondering how to expose the information contained in the compiled message file. I would like to have this made available as part of the APISHR image. Is it as simple as including the message values in the linker options file for linking APISHR, e.g.

SYMBOL_VECTOR=( -
APPL_ROUTINE1=PROCEDURE, -
APPL_ROUTINE2=PROCEDURE, -
APPL__SUCCESS=DATA, -
APPL__FAILURE=DATA)

where 'APPL_ROUTINE1' and 'APPL_ROUTINE2' are two public routines for the API, and 'APPL__SUCCESS' and 'APPL__FAILURE' are two error messages.

Or do I need to do it some other way?
(I'm wondering if I need to use message pointer files, and if so, how would a program which uses the API link against them.)

Thanks,
Jeremy Begg

[John Gillings · Accepted solution]

Hi Jeremy,

Your condition codes can be declared as data entries in the symbol vector. If you want the symbols to be visible, you'll have to declare them regardless of directly linking against your message object, or using pointer files.

When you tie the messages into a shareable or executable image, there is no simple way to translate a code into a message. If you use a message image and pointer, you can use SET MESSAGE and F$MESSAGE to perform the translation.

The way OpenVMS utilities usually do it is "self contained" utilities, like compilers link their messages directly. APIs, like SORTSHR, use pointer files, and export the symbols. SORTSHR is a good example (use FAKE_RTL to generate a sample symbol vector)

Using message pointers isn't something you need to set in concrete, as it's transparent to any images that link against your API. On the other hand, you might run into problems if you combine exported global symbols with included compile time constants. You may want to consider changing the include files to contain external references, rather than constant values.

[Jeremy Begg]

Thanks John, you've confirmed my suspicions.

The definition files used by my C and Pascal code are generated by SDL, i.e.

$ message/sdl api.msg
$ sdl/language=pascal=apimsg.pas api.sdl

so changing them to generate external references instead of constants isn't so easy (unless there's a MESSAGE/SDL option I don't know about).

Jeremy

[Jeremy Begg]

After a little testing I've decided to structure things so that there is a message pointer object file which gets linked into the shareable image, and the message file itself is linked as a second shareable image.

I found that there was no need to make universal symbols for my message values, which is somewhat of a relief as otherwise the SYMBOL_VECTOR statement in my linker options file would become very difficult to manage.

[Richard J Maher]

Hi Jeremy,

FWIW, we ship an object library (t3$object) that can be linked against by the user code.

Directory of ELF OBJECT library SYS$COMMON:[SYSLIB]T3$OBJECT.OLB;2 on 29-APR-2009 15:43:14
Creation date: 5-FEB-2009 20:01:11 Creator: Librarian I01-42
Revision date: 6-FEB-2009 02:29:06 Library format: 6.0
Number of modules: 2 Max. key length: 1024
Other entries: 62 Preallocated index blocks: 213
Recoverable deleted blocks: 0 Total index blocks used: 8
Max. Number history records: 20 Library history records: 2

T3$MSG
T3$SYMBOLS

For an example of a build procedure that links against it, see: -
http://manson.vistech.net/t3$examples/build_uars.com

(or BUILD_FLEX_DEMO.COM in the same area, for one that also links in Rdb)

If after reading http://manson.vistech.net/t3$examples/tier3_031.pdf you're thinking "Gee life would be much easier if this was bundled with VMS!" then be aware that I spoke to several people in VMS about it coming up to 10 years ago. Please be advised that your/your-customer's requirement simply do not exist and BridgeWorks, WSIT, Forte, DCE/RPC, ONC/RPC, or COM is really what you're looking for :-(

Cheers Richard Maher

PS. If you'd rather not re-invent the wheel then please send me an e-mail.

[Willem Grooters]

IIRC, I circumvented this problem this way:

* Compile the message file, creating a listing file
* process the listing to create a file to be included (or, in case of pascal, inherited) in any other source

but I'll have to dig the archives to find more information.

[Jeremy Begg]

Hi Willem,

The problem is not the message symbol values, it's the actual error message text. I suppose your listing could provide the text into each module which requires it, but (without having seen what your method is!) it seems a little clumsy.

Anyway I'm happy with the solution I arrived at.

Regards,
Jeremy Begg