On 3/17/23 00:55, Mark Post wrote:
On 3/16/2023 9:24 PM, Rick Troth wrote:There's nothing like CMS APPLMSG and XMITMSG in Linux land.Help a guy out and explain what those things are, and what they're used for.I've never been as hardcore a z/VM or CMS guy as some others, so I've never used those and I'm not familiar with them.
That's a good question. Thanks for asking. And I apologize for throwing weird CMS stuff at the non-CMS members of the list.
This reply got longer than I expected.Y'all have seen the unique codes which prefix error messages from CP. From Linux, if I try ...
# vmcp detach 5555 I should get ... HCPDTV040E Device 5555 does not exist (Because I don't have a device at address 5555.)The "HCPDTV040E" is unique and can be found in the printed docs. It also relates to return code 40. (Which 'vmcp' on my system gobbled up, returning the usual 1 for shell norms.) The "HCP" means it came from the CP hypervisor. The "DTV" is short for "detach virtual", a subfunction within the hypervisor. The trailing "E" means it's an error. Not all IBM message codes are for errors.
I confess I don't know much about message handling in CP, but in CMS it's really slick. Those of you who have used CMS have seen similar well-formed message headers. I said I was forced to use it because at the time I was in the habit of simply doing 'echo' in shell or "Say" in Rexx or printf() In C. You get the idea.
There's a command in CMS called 'XMITMSG'. If you have a CMS account, you can do ...
xmitmsg 3 'mark' The system should respond with ... DMS???003E Invalid option: markThe question marks are because it's not intended to be driven from the command line. It doesn't have a "caller" value. It cannot figure out some subfunction for the particular invocation, which would go into that part of the message header. The "DMS" is because I took the default message repository for CMS. 3 is the message I asked for, which is normally presented for error conditions, thus the "E".
A better example would be to use 'XMITMSG' from an EXEC. (The question marks would be replaced by the name of the EXEC.) But that takes more time.
In assembler, there's a macro, APPLMSG, which provides the same function. Should be easy enough to wrap the macro in a C function, but I confess I have never done that.
When I was writing a certain VM/CMS application (that I won't even name because it would show my age), it was well received, but the community pressed hard: "Rick, you should be using the message handler". I was annoyed, but I bowed to pressure. I had to go learn how the message handler worked. Then I replaced all the "Say" statements with 'XMITMSG'. (It was a Rexx application.) I put the text originally presented via "Say" into a message source file. It worked.
Then something wonderful happened. One or two kind souls translated the message source into their own language. Suddenly, with no changes to the code, people could use this application and get responses (it's not all about errors) in their own language!
Whoop!Enumerating the messages took some time, but was not unbearable. Plus, I wanted to make my customers happy, so I soldiered on. It grew on me. Also, we commonly do this in other contexts. How many C programs pull-in mnemonics from a.h file? If best practice in C is to use mnemonics instead of numbers, then it's fair to say that better practice with message handling is to use enumerated messages (which can, in turn, have mnemonics, but that gets deep).
Anyway ... over time, I really got hooked on this and wanted to see it on other platforms. So that's the point of the original note: I wrote a tool which consumes the same format message source as CMS uses (and should eventually have at least one other, long story).
For internationalization, most people in the Unix and Linux world would turn to gettext. I know about gettext and make a point of building it when I turn the crank on my open source collection. But gettext is tied to printf() style formatting, which is risky. It's also unclear that gettext supports explicit per-language placement of variable content. I'm not slamming gettext, but it remains a debated topic.
Mark Post ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions,send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visithttp://www2.marist.edu/htbin/wlvindex?LINUX-390
-- -- R; <>< ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
OpenPGP_signature
Description: OpenPGP digital signature
