Thanks Alan. I have found a way to use SMSG, so I have circumvented a design "feature".
So it is documented. That does not alter the fact that the treatment of the MSG traffic seems to be somewhat inconsistent. If the id has a logon console, the messages are sent to the *MSG trap, regardless of whether there is a SECUSER. If the id is disconnected, the messages are trapped if there is no SECUSER or there is one that does not happen to be logged on, but are sent to the SECUSER if there is one who is logged on. To me, this violates the Principle of Least Astonishment. Is there some good reason why it works like this? It would be more consistent if the things that are set to be trapped by IUCV or SMSG were treated the same in all cases. After all, if it is OK for the machine to process the messages in most cases, why is it not OK in this one instance? I understand, and now share, your grudge. This is one of those things that may be BAD, but has been around for so long that it probably can't be fixed without upsetting a lot of users. (For the uninitiated, BAD is an acronym for Broken As Designed.) Has there been a replacement assigned to take over the Ombudsman role since Lyn Hadley held the post. Speaking of Lyn, has anyone heard from him recently? Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Tuesday, August 19, 2008 2:59 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: SECUSER > > On Tuesday, 08/19/2008 at 05:22 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > I have a service machine the runs with MSG set to IUCV. If > I enter the > command > > "SET SECUSER svcid *", messages are displayed on my console rather > > than > being > > sent to the IUCV handler. The messages do not get displayed on the > console if > > I log on to the id; why should they be reflected to the SECUSER > > console > and not > > the IUCV handler? Is the behavior documented anywhere? I > did not see > > it > under > > either SET SECUSER or SET MSG IUCV. Looking at SCIF doesn't > seem too > > productive, either. > > Ah, one of the Great Schisms. See the 3rd from the last > paragraph in the description of *MSG in the CP Programming > Services book: > > "If a virtual machine has both a valid path to *MSG and a > functioning secondary user, incoming messages (except for > SMSGs, which are not console > messages) are directed to the secondary user instead of the > IUCV *MSG path to the primary user." > > You can't use SCIF to monitor the behavior of a user > connected to *MSG. I don't recall if SET OBSERVER has the > same effect or not. > > And in case you're confused, VM/SP and VM/XA handled this > differently. > VM/SP handled this the Right and Proper Way. VM/XA did it > the Horrible and Evil Way. I still hold a grudge. > > Alan Altmark > z/VM Development > IBM Endicott >
