You do indeed do a pretty good job. It is just that it sometimes helps to have a titled individual press the argument.
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 7:38 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: SECUSER > > On Tuesday, 08/19/2008 at 07:25 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > > 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. > > I could understand the CONSOLE-based SCIF as having this > bizzare-o behavior, I suppose, but SET SECUSER/OBSERVER > probably would have been well-served to include an option for > the watcher to decide whether you get > a) SET SECUSER <userid> * PITA > the message instead of it going to *MSG > b) SET SECUSER <userid> * SNIFFER > an annotated message AND it goes to *MSG > c) SET SECUSER <userid> * > only messages not trapped by *MSG (as the Gods intended) > > For those times when you want different things. > > > 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.) > > I remember many heated arguments during VM/ESA 1.0 > development. I also remember losing. (I had just started by > stint in System Test.) Everyone KNOWS that the Prime > Directive should apply to SCIF. Watching a server should not > change its behavior. It makes debugging REXECD a pain. > <grump> See "Grudge". > > > Has there been a replacement assigned to take over the > Ombudsman role > since > > Lyn Hadley held the post. > > I like to think that those of us who hang out here do a > pretty good job, > even if no one has the formal title. :-) > > Alan Altmark > z/VM Development > IBM Endicott >
