On Sat, May 30, 2009 at 1:31 AM, Alan Altmark <[email protected]> wrote:
> I think it would be safe to say that IBM recommends AGAINST issuing a > STORE HOST unless you are doing so at the direction of Support Centre. As > some have discovered, STORE HOST introduces an "unstable element" (the > systems programmer? };-) ) into the system, creating risk of an abend. I found Kris illustrated the problem with his approach himself the best in the follow-up note where he explained he found even a newer version of the program that probably was the one adjusted for later VM releases. Even when you have a program to issue the STORE HOST for you (and without you knowing it) that program may be wrong or not suitable in your case. Sure, we all zapped hung users out of the way. But this is last resort actions that you leave to those who can afford to risk their job for the good case. But I would expect that the 64-bit changes would have retired most of these old habits. One of the vendor applications we ran would change a bit in its VMDBK (when enabled by a configuration file option). It had class C for another reason already. When we upgraded to a next z/VM release, the program did not recognize VM/ESA and assumed we ran VM/SP. Bad things happened. I've used the dump for some time as training material for novice dump readers. The main reason we have SET PRIVCLAS is that we notice the need for this function, and don't want people to zap in memory for this. Because when auditing shows you someone modifies real memory, he could have done anything (well, I recall that when looking at this we did spot the offset in the address as likely reason for the store host). For the same reason we have many query commands and don't give anyone just class E and let them peek around in the machine (let alone that things get complicated when control blocks are paged). But then, I don't agree with Kris' view of the world that "MAINT must be allowed to do anything" In my view, *if* there is a single userid that is allowed to do anything under any circumstances (like no auditing) then use of such a userid should be very much limited to exceptional cases where normal tools don't work. Rob
