Re: CMS-like 'xmitmsg' for Linux (or Unix or MacOS or maybe even Windoze)
On 3/17/23 11:56, Alan Altmark wrote: 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 Some of these, especially of those which are common with CMS, bear a strong correlation to SYSLOG levels. That's handy. Really very handy. From the "xmitmsgx" project ... /* MSGLEVEL_DEBUG LOG_DEBUG 7 debug-level messages, not used here */ #define MSGLEVEL_INFO 'I' /* LOG_INFO 6 informational */ #define MSGLEVEL_REPLY 'R' /* LOG_NOTICE 5 normal but significant condition, ATTENTION */ #define MSGLEVEL_WARNING 'W' /* LOG_WARNING 4 warning conditions */ #define MSGLEVEL_ERROR 'E' /* LOG_ERR 3 error conditions */ #define MSGLEVEL_SEVERE 'S' /* LOG_CRIT 2 critical conditions */ #define MSGLEVEL_TERMINAL 'T' /* LOG_ALERT 1 action must be taken immediately */ /* MSGLEVEL_EMERG LOG_EMERG 0 reserved */ SYSLOG Is a whole nutha topic, but a couple of the functions in the "xmitmsgx" project will optionally log the message in addition to printing it. -- -- 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
Re: CMS-like 'xmitmsg' for Linux (or Unix or MacOS or maybe even Windoze)
On 3/17/23 7:36 AM, Rick Troth wrote: This reply got longer than I expected. That happens. (Which 'vmcp' on my system gobbled up, returning the usual 1 for shell norms.) I feel like there should be a way to capture the 40 and pass it further out. 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. I was thinking that you could do similar using `echo` et al. 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! Now I understand why this is more portable ~> thus better than simple `echo` et al. Thank you for highlighting the localization by changing swapping out the messages file with one in the local language. -- Grant. . . . unix || die -- 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
Re: CMS-like 'xmitmsg' for Linux (or Unix or MacOS or maybe even Windoze)
On 3/17/23 8:36 AM, Rob van der Heij wrote: Just have someone come up with the idea to use a SHA1 rather than a cryptic message identifier, and they will embrace it. You'd better use SHA256 or something else newer than SHA1 lest you take flack for and old SHA. It will take them also a few decades before users insist on having online help for kernel parameters and device drivers, rather than separate text files on kernel.org I've always found that the files you're referencing on kernel.org are also included in each kernel release. So if you've got the full kernel source for the kernel that you're running, you also have said text files locally. -- Grant. . . . unix || die -- 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
Re: CMS-like 'xmitmsg' for Linux (or Unix or MacOS or maybe even Windoze)
HCPxxxs 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. 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 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) alan_altm...@us.ibm.com > -Original Message- > From: Linux on 390 Port On Behalf Of Rick > Troth > Sent: Friday, March 17, 2023 9:37 AM > To: LINUX-390@VM.MARIST.EDU > 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 > > I should get ... > > HCPDTV040E Device does not exist > > (Because I don't have a device at address .) 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
Re: CMS-like 'xmitmsg' for Linux (or Unix or MacOS or maybe even Windoze)
On Fri, 17 Mar 2023 at 14:45, Neale Ferguson wrote: > I believe in the early 2000s the Linux on 390 developers in Böblingen > attempted to provide a similar mechanism for the kernel but it wasn't well > received by the rest of the community. It's a pity but with so many hands > involved with so many device drivers it was going to be a hard sell. > It's interesting that the Linux world did it for the man pages. With some infrastructure, you could even hide the message identifier from being shown, but still have "man" able to retrieve the proper information. Just have someone come up with the idea to use a SHA1 rather than a cryptic message identifier, and they will embrace it. The kernel and device drivers are a bit different because you don't have man pages there. It will take them also a few decades before users insist on having online help for kernel parameters and device drivers, rather than separate text files on kernel.org Rob -- 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
Re: CMS-like 'xmitmsg' for Linux (or Unix or MacOS or maybe even Windoze)
I believe in the early 2000s the Linux on 390 developers in Böblingen attempted to provide a similar mechanism for the kernel but it wasn't well received by the rest of the community. It's a pity but with so many hands involved with so many device drivers it was going to be a hard sell. Original message From: Rick Troth Date: 17/3/23 23:36 (GMT+10:00) To: LINUX-390@VM.MARIST.EDU Subject: 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 I should get ... HCPDTV040E Device does not exist (Because I don't have a device at address .) 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 lists...@vm.marist.edu with the message: INFO LINUX-390 > or visit >
Re: 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 I should get ... HCPDTV040E Device does not exist (Because I don't have a device at address .) 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 lists...@vm.marist.edu 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 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
Re: CMS-like 'xmitmsg' for Linux (or Unix or MacOS or maybe even Windoze)
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. Mark Post -- 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
