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
