HCPxxxNNNNs HCPxxx is the module (not subsystem) that caused the message to be issued. It's just a locator beacon to make IBM developers' lives easier. NNNN means the same thing, without regard to module name. It is true that each module is part of a loosely-defined subsystem, but don't get too hung up on it.
The severity code (s) determines your next steps. A = Action required D = Decision (I think this is no longer used) E = Error I = Information R = Response S = Severe error T = Terminating error W (CP) = Disabled wait state (HELP HCP1010W) W (other) = Warning Other trivia.... While the module name is usually irrelevant, there is one case where it's important: QUERY <device-number> HCPQDV040E Device 1000 does not exist HCPQVD040E Device 1000 does not exist Note the oh-so-subtle difference in the module names: QDV versus QVD. QDV is all about REAL devices. QVD tells you about VIRTUAL devices. Sometimes I don't realize that privilege class is playing games with my mind, but I look at the module name and the light goes on in my head, quickly followed by the phrase, "Duh." Regards, Alan Alan Altmark IBM Senior z/VM Engineer 1 607 321 7556 (Mobile) [email protected] > -----Original Message----- > From: Linux on 390 Port <[email protected]> On Behalf Of Rick > Troth > Sent: Friday, March 17, 2023 9:37 AM > To: [email protected] > Subject: [EXTERNAL] Re: [LINUX-390] CMS-like 'xmitmsg' for Linux (or Unix > or MacOS or maybe even Windoze) > > 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: mark > > The 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 [email protected] with the message: INFO LINUX-390 > or > > visit > > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > > > -- > -- R; <>< > > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX- > 390 or visit > http://www2.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
