- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- VMS Message files (.MSG) and Shareable images
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-27-2009 07:42 PM
тАО04-27-2009 07:42 PM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-27-2009 08:31 PM
тАО04-27-2009 08:31 PM
SolutionYour 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-27-2009 09:00 PM
тАО04-27-2009 09:00 PM
Re: VMS Message files (.MSG) and Shareable images
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-27-2009 10:28 PM
тАО04-27-2009 10:28 PM
Re: VMS Message files (.MSG) and Shareable images
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-28-2009 10:56 PM
тАО04-28-2009 10:56 PM
Re: VMS Message files (.MSG) and Shareable images
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2009 10:33 PM
тАО05-05-2009 10:33 PM
Re: VMS Message files (.MSG) and Shareable images
* 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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2009 11:36 PM
тАО05-05-2009 11:36 PM
Re: VMS Message files (.MSG) and Shareable images
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