Re: SECUSER and SEND problem
The only thing is: according to his console -- the ARCHIVE command sent via SEND appears to work - which would indicate the guest was either in VM READ - or more likely - a RUNNING state. Since 'ARCHIVE' is now in control and issuing messages, etc -- I'm thinking the solution lies within ARCHIVE somewhere.. But - I would certainly be interested to see what happens if a BEGIN is sent as you suggest -- the result could give more clues.. Scott On Sat, May 30, 2009 at 6:23 PM, carlos martinez < carlosmarti...@optonline.net> wrote: > If this condition is consistent the resolution may be as simple as PUSHing > a "B" (BEGIN) into the Stack therefore when it goes into CPREAD or VMREAD. > it will pull the B out of the stacker. > What may be happing is that there is something already left over in the > stacker that may be causing it to go into CPREAD or VMREAD after executing > your EXEC. (or maybe before?) > I hope this helps I have had problems like this before and always found > some leftover line or junk in the stacker causing my EXEC to terminate in > VMREAD or CPREAD mode. > >> I run a series of commands from a CMS user with priv class A to automate >> my DB/2 for VM database archives. Here is the EXEC: >> >> 'CP ATT A91 SQLPROD 181' >> 'CP SET SECUSER SQLPROD *' >> 'CP SEND SQLPROD ARCHIVE' >> 'CP SLEEP 10 SEC' >> 'CP SEND SQLPROD 181' >> 'CP SLEEP 60 SEC' >> 'CP SLEEP 60 SEC' >> 'CP SLEEP 60 SEC' >> 'CP SLEEP 60 SEC' >> 'CP SLEEP 60 SEC' >> 'CP SLEEP 60 SEC' >> 'CP SLEEP 60 SEC' >> > PUSH 'b" maybe somewhere here? > >> 'CP DET A91 SQLPROD' >> 'CP SET SECUSER SQLPROD OFF' >> >> >> SQLPROD is running disconnected, and once the ARCHIVE command is >> processed, it goes into a VM READ waiting for the operator to >> enter the CUU for the tape drive. >> >> As long as the user running this is logged on, it works fine. >> >> However, if the user is running disconnected, SQLPROD interpets >> the ARCHIVE command correctly, but then seems to be in a CP read >> instead of a VM read, and it gives an error on the 181 response. >> >> The SQL console log is posted at the end. Once I log on to SQLPROD >> and press enter, it give me the ARI message and re-prompts me to >> enter the CUU of the tape drive, which I then key in and it works >> fine. >> >> Is this the way SECUSER and SEND is supposed to work, or should it >> be the same regardless of whether or not the user issuing the commands is >> connected? >> >> Thanks. >> >> Ed Zell >> Illinois Mutual Life >> (309) 636-0107 >> >> >> >> TAPE 0A93 ATTACHED TO SQLPROD 0181 HCPCFX6768I Your >> SECUSER set to EONBKUP by EONBKUP. ARI0065I Operator command processing >> is complete.ARI2008I Archive is about to be started. >> ARI0293I Archive is starting.ARI0239I External >> labeling of this archive is: Type: database >> archive Timestamp: 05-30-09 16:13:51 >> ARI0299A Ready archive output volume. Enter the CUU. HCPCMD001E >> Unknown CP command: 181 z/VM Version 4 Release 4.0, >> Service Level 0501 (32-bit), built on IBM Virtualization Technology >> There is no logmsg data FILES: >> NO RDR, 0001 PRT, NO PUN RECONNECTED AT 16:16:34 CDT >> SATURDAY 05/30/09 >> ARI0297A Response to archive prompt is not valid.ARI0239I >> External labeling of this archive is: Type: >> database archive Timestamp: 05-30-09 16:13:51 >> ARI0299A Ready archive output volume. Enter the CUU. 181 >> ARI0292I Archive is >> completed. HCPCFX6768I Your SECUSER set to SQLCONS by >> EONBKUP.. >> >> >> CONFIDENTIALITY: This e-mail (including any attachments) may contain >> confidential, proprietary and privileged information, and unauthorized >> disclosure or use is prohibited. If you receive this e-mail in error, >> notify the sender and delete this e-mail from your system. >> >> >> >> >
Re: SECUSER and SEND problem
If this condition is consistent the resolution may be as simple as PUSHing a "B" (BEGIN) into the Stack therefore when it goes into CPREAD or VMREAD. it will pull the B out of the stacker. What may be happing is that there is something already left over in the stacker that may be causing it to go into CPREAD or VMREAD after executing your EXEC. (or maybe before?) I hope this helps I have had problems like this before and always found some leftover line or junk in the stacker causing my EXEC to terminate in VMREAD or CPREAD mode. I run a series of commands from a CMS user with priv class A to automate my DB/2 for VM database archives. Here is the EXEC: 'CP ATT A91 SQLPROD 181' 'CP SET SECUSER SQLPROD *' 'CP SEND SQLPROD ARCHIVE' 'CP SLEEP 10 SEC' 'CP SEND SQLPROD 181' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' PUSH 'b" maybe somewhere here? 'CP DET A91 SQLPROD' 'CP SET SECUSER SQLPROD OFF' SQLPROD is running disconnected, and once the ARCHIVE command is processed, it goes into a VM READ waiting for the operator to enter the CUU for the tape drive. As long as the user running this is logged on, it works fine. However, if the user is running disconnected, SQLPROD interpets the ARCHIVE command correctly, but then seems to be in a CP read instead of a VM read, and it gives an error on the 181 response. The SQL console log is posted at the end. Once I log on to SQLPROD and press enter, it give me the ARI message and re-prompts me to enter the CUU of the tape drive, which I then key in and it works fine. Is this the way SECUSER and SEND is supposed to work, or should it be the same regardless of whether or not the user issuing the commands is connected? Thanks. Ed Zell Illinois Mutual Life (309) 636-0107 TAPE 0A93 ATTACHED TO SQLPROD 0181 HCPCFX6768I Your SECUSER set to EONBKUP by EONBKUP. ARI0065I Operator command processing is complete. ARI2008I Archive is about to be started. ARI0293I Archive is starting. ARI0239I External labeling of this archive is: Type: database archive Timestamp: 05-30-09 16:13:51 ARI0299A Ready archive output volume. Enter the CUU. HCPCMD001E Unknown CP command: 181 z/VM Version 4 Release 4.0, Service Level 0501 (32-bit), built on IBM Virtualization Technology There is no logmsg data FILES: NO RDR, 0001 PRT, NO PUN RECONNECTED AT 16:16:34 CDT SATURDAY 05/30/09 ARI0297A Response to archive prompt is not valid. ARI0239I External labeling of this archive is: Type: database archive Timestamp: 05-30-09 16:13:51 ARI0299A Ready archive output volume. Enter the CUU. 181 ARI0292I Archive is completed. HCPCFX6768I Your SECUSER set to SQLCONS by EONBKUP. . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: SECUSER and SEND problem
The CP SEND should work, and, if SQLPROD has a secondary user defined, a VM READ should remain a VM READ. Only without a secondary user a VM READ posted by a disconnected user becomes a CP READ. (my former customer used similar CP sends to manage DB2 servers) Maybe a short SLEEP after the SET SECUSER? P.S. you can also code CP SLEEP 8 MIN instead of 8 times 60 SEC Oh yes, I just remember something: when the secondary user itself is disconnected, the primary user acts as if it didn't have a secondary user. Unless the secondary user has an active path to IUCV *MSG. So, insert 'WAKEUP +0 (IUCVMSG' before the SET SECUSER, and 'WAKEUP RESET' when done. But, as you start using WAKEUP, your REXX code could even analyze the messages sent by SQLPROD and act accordingly, replacing the fixed CP SLEEP wait times. Do do so, code a loop: 'WAKEUP +nn (IUCVMSG' if rc=6 then ... user pressed enter... maybe leave if rc=2 then ... no message from anyone in the last nn minutes if rc=5 then ... you got a message, use PARSE PULL to get it. 2009/5/31 Ed Zell : > I run a series of commands from a CMS user with priv class A > to automate my DB/2 for VM database archives. Here is the EXEC: > > 'CP ATT A91 SQLPROD 181' > 'CP SET SECUSER SQLPROD *' > 'CP SEND SQLPROD ARCHIVE' > 'CP SLEEP 10 SEC' > 'CP SEND SQLPROD 181' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP DET A91 SQLPROD' > 'CP SET SECUSER SQLPROD OFF' > > > SQLPROD is running disconnected, and once the ARCHIVE command is > processed, it goes into a VM READ waiting for the operator to > enter the CUU for the tape drive. > > As long as the user running this is logged on, it works fine. > > However, if the user is running disconnected, SQLPROD interpets > the ARCHIVE command correctly, but then seems to be in a CP read > instead of a VM read, and it gives an error on the 181 response. > > The SQL console log is posted at the end. Once I log on to SQLPROD > and press enter, it give me the ARI message and re-prompts me to > enter the CUU of the tape drive, which I then key in and it works > fine. > > Is this the way SECUSER and SEND is supposed to work, or should it > be the same regardless of whether or not the user issuing the > commands is connected? > > Thanks. > > Ed Zell > Illinois Mutual Life > (309) 636-0107 > > > > TAPE 0A93 ATTACHED TO SQLPROD 0181 > HCPCFX6768I Your SECUSER set to EONBKUP by EONBKUP. > ARI0065I Operator command processing is complete. > ARI2008I Archive is about to be started. > ARI0293I Archive is starting. > ARI0239I External labeling of this archive is: > Type: database archive > Timestamp: 05-30-09 16:13:51 > ARI0299A Ready archive output volume. Enter the CUU. > HCPCMD001E Unknown CP command: 181 > z/VM Version 4 Release 4.0, Service Level 0501 (32-bit), > built on IBM Virtualization Technology > There is no logmsg data > FILES: NO RDR, 0001 PRT, NO PUN > RECONNECTED AT 16:16:34 CDT SATURDAY 05/30/09 > > ARI0297A Response to archive prompt is not valid. > ARI0239I External labeling of this archive is: > Type: database archive > Timestamp: 05-30-09 16:13:51 > ARI0299A Ready archive output volume. Enter the CUU. > 181 > ARI0292I Archive is completed. > HCPCFX6768I Your SECUSER set to SQLCONS by EONBKUP. > . > > > CONFIDENTIALITY: This e-mail (including any attachments) may contain > confidential, proprietary and privileged information, and unauthorized > disclosure or use is prohibited. If you receive this e-mail in error, notify > the sender and delete this e-mail from your system. > -- Kris Buelens, IBM Belgium, VM customer support
Re: SECUSER and SEND problem
Is it as simple as needing a "cp set run on"? Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Saturday, May 30, 2009 3:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] SECUSER and SEND problem Strange - I would expect the SEND SQLPROD ARCHIVE to result in a HCP150A USER SQLPROD HAS ISSUED A VM READ. Since you didn't get that, I assume the VM READ wasn't issued.. Is it possible the ARCHIVE code knows whether it's disconnected or not and acts differently? Scott On Sat, May 30, 2009 at 4:15 PM, Ed Zell wrote: I run a series of commands from a CMS user with priv class A to automate my DB/2 for VM database archives. Here is the EXEC: 'CP ATT A91 SQLPROD 181' 'CP SET SECUSER SQLPROD *' 'CP SEND SQLPROD ARCHIVE' 'CP SLEEP 10 SEC' 'CP SEND SQLPROD 181' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP DET A91 SQLPROD' 'CP SET SECUSER SQLPROD OFF' SQLPROD is running disconnected, and once the ARCHIVE command is processed, it goes into a VM READ waiting for the operator to enter the CUU for the tape drive. As long as the user running this is logged on, it works fine. However, if the user is running disconnected, SQLPROD interpets the ARCHIVE command correctly, but then seems to be in a CP read instead of a VM read, and it gives an error on the 181 response. The SQL console log is posted at the end. Once I log on to SQLPROD and press enter, it give me the ARI message and re-prompts me to enter the CUU of the tape drive, which I then key in and it works fine. Is this the way SECUSER and SEND is supposed to work, or should it be the same regardless of whether or not the user issuing the commands is connected? Thanks. Ed Zell Illinois Mutual Life (309) 636-0107 TAPE 0A93 ATTACHED TO SQLPROD 0181 HCPCFX6768I Your SECUSER set to EONBKUP by EONBKUP. ARI0065I Operator command processing is complete. ARI2008I Archive is about to be started. ARI0293I Archive is starting. ARI0239I External labeling of this archive is: Type: database archive Timestamp: 05-30-09 16:13:51 ARI0299A Ready archive output volume. Enter the CUU. HCPCMD001E Unknown CP command: 181 z/VM Version 4 Release 4.0, Service Level 0501 (32-bit), built on IBM Virtualization Technology There is no logmsg data FILES: NO RDR, 0001 PRT, NO PUN RECONNECTED AT 16:16:34 CDT SATURDAY 05/30/09 ARI0297A Response to archive prompt is not valid. ARI0239I External labeling of this archive is: Type: database archive Timestamp: 05-30-09 16:13:51 ARI0299A Ready archive output volume. Enter the CUU. 181 ARI0292I Archive is completed. HCPCFX6768I Your SECUSER set to SQLCONS by EONBKUP. . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: SECUSER and SEND problem
Strange - I would expect the SEND SQLPROD ARCHIVE to result in a HCP150A USER SQLPROD HAS ISSUED A VM READ. Since you didn't get that, I assume the VM READ wasn't issued.. Is it possible the ARCHIVE code knows whether it's disconnected or not and acts differently? Scott On Sat, May 30, 2009 at 4:15 PM, Ed Zell wrote: > I run a series of commands from a CMS user with priv class A > to automate my DB/2 for VM database archives. Here is the EXEC: > > 'CP ATT A91 SQLPROD 181' > 'CP SET SECUSER SQLPROD *' > 'CP SEND SQLPROD ARCHIVE' > 'CP SLEEP 10 SEC' > 'CP SEND SQLPROD 181' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP SLEEP 60 SEC' > 'CP DET A91 SQLPROD' > 'CP SET SECUSER SQLPROD OFF' > > > SQLPROD is running disconnected, and once the ARCHIVE command is > processed, it goes into a VM READ waiting for the operator to > enter the CUU for the tape drive. > > As long as the user running this is logged on, it works fine. > > However, if the user is running disconnected, SQLPROD interpets > the ARCHIVE command correctly, but then seems to be in a CP read > instead of a VM read, and it gives an error on the 181 response. > > The SQL console log is posted at the end. Once I log on to SQLPROD > and press enter, it give me the ARI message and re-prompts me to > enter the CUU of the tape drive, which I then key in and it works > fine. > > Is this the way SECUSER and SEND is supposed to work, or should it > be the same regardless of whether or not the user issuing the > commands is connected? > > Thanks. > > Ed Zell > Illinois Mutual Life > (309) 636-0107 > > > > TAPE 0A93 ATTACHED TO SQLPROD 0181 > HCPCFX6768I Your SECUSER set to EONBKUP by EONBKUP. > ARI0065I Operator command processing is complete. > ARI2008I Archive is about to be started. > ARI0293I Archive is starting. > ARI0239I External labeling of this archive is: > Type: database archive > Timestamp: 05-30-09 16:13:51 > ARI0299A Ready archive output volume. Enter the CUU. > HCPCMD001E Unknown CP command: 181 > z/VM Version 4 Release 4.0, Service Level 0501 (32-bit), > built on IBM Virtualization Technology > There is no logmsg data > FILES: NO RDR, 0001 PRT, NO PUN > RECONNECTED AT 16:16:34 CDT SATURDAY 05/30/09 > > ARI0297A Response to archive prompt is not valid. > ARI0239I External labeling of this archive is: > Type: database archive > Timestamp: 05-30-09 16:13:51 > ARI0299A Ready archive output volume. Enter the CUU. > 181 > ARI0292I Archive is completed. > HCPCFX6768I Your SECUSER set to SQLCONS by EONBKUP. > . > > > CONFIDENTIALITY: This e-mail (including any attachments) may contain > confidential, proprietary and privileged information, and unauthorized > disclosure or use is prohibited. If you receive this e-mail in error, > notify the sender and delete this e-mail from your system. >
SECUSER and SEND problem
I run a series of commands from a CMS user with priv class A to automate my DB/2 for VM database archives. Here is the EXEC: 'CP ATT A91 SQLPROD 181' 'CP SET SECUSER SQLPROD *' 'CP SEND SQLPROD ARCHIVE' 'CP SLEEP 10 SEC' 'CP SEND SQLPROD 181' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP SLEEP 60 SEC' 'CP DET A91 SQLPROD' 'CP SET SECUSER SQLPROD OFF' SQLPROD is running disconnected, and once the ARCHIVE command is processed, it goes into a VM READ waiting for the operator to enter the CUU for the tape drive. As long as the user running this is logged on, it works fine. However, if the user is running disconnected, SQLPROD interpets the ARCHIVE command correctly, but then seems to be in a CP read instead of a VM read, and it gives an error on the 181 response. The SQL console log is posted at the end. Once I log on to SQLPROD and press enter, it give me the ARI message and re-prompts me to enter the CUU of the tape drive, which I then key in and it works fine. Is this the way SECUSER and SEND is supposed to work, or should it be the same regardless of whether or not the user issuing the commands is connected? Thanks. Ed Zell Illinois Mutual Life (309) 636-0107 TAPE 0A93 ATTACHED TO SQLPROD 0181 HCPCFX6768I Your SECUSER set to EONBKUP by EONBKUP. ARI0065I Operator command processing is complete. ARI2008I Archive is about to be started. ARI0293I Archive is starting. ARI0239I External labeling of this archive is: Type: database archive Timestamp: 05-30-09 16:13:51 ARI0299A Ready archive output volume. Enter the CUU. HCPCMD001E Unknown CP command: 181 z/VM Version 4 Release 4.0, Service Level 0501 (32-bit), built on IBM Virtualization Technology There is no logmsg data FILES: NO RDR, 0001 PRT, NO PUN RECONNECTED AT 16:16:34 CDT SATURDAY 05/30/09 ARI0297A Response to archive prompt is not valid. ARI0239I External labeling of this archive is: Type: database archive Timestamp: 05-30-09 16:13:51 ARI0299A Ready archive output volume. Enter the CUU. 181 ARI0292I Archive is completed. HCPCFX6768I Your SECUSER set to SQLCONS by EONBKUP. . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: radar interfering with computer gear
Walter wrote:
When examined after each failure, the core (yes, real core) memory was
always wiped clean. That computer (and its tech) was housed in a metal
box (IIRC, about 6'x10', 8' high) which was transportable on the back of a
2 1/2 ton ("6-by") truck, or by helicopter> It was located about 15 feet
from another similar box with all the radar gear inside, and large radar
dish on the top. After a few days of random core wipes, someone noticed
that the core wipe only happened when the door to the computer hut was
momentarily opened as the radar dish swept past. While aimed much higher,
there was enough residual power from the dish to wipe the computer's core
memory clean. Memory was reloaded (back on track now) from dependable
paper tape.
old thread about Mt. Umunhum interfering with (stanford) SAIL computer:
http://www.garlic.com/~lynn/aadsm25.htm#25
the referenced URL has gone 404
http://www-db.stanford.edu/pub/voy/museum/pictures/AIlab/SailFarewell.html
but is here:
http://infolab.stanford.edu/pub/voy/museum/pictures/AIlab/SailFarewell.html
from above:
I got proper air conditioning a short time later, but unfortunately
developed a bad case of hiccups that struck regularly at 12 second
intervals. My assistants spent a number of days trying to find the
cause of this mysterious malady without success. As luck would have
it, somebody brought a portable radio into my room one day and noticed
that it was emitting a "Bzz" at regular intervals -- in fact, at the
same moment that I hicced. Further investigation revealed that the
high-powered air defense radar atop Mt. Umunhum, about 20 miles away,
was causing some of my transistors to act as radio receivers. We
solved this problem by improving my grounding.
... snip ...
for other drift ... later posts in the previously mentioned ibm-main thread
http://www.garlic.com/~lynn/2009h.html#42 Book on Poughkeepsie
http://www.garlic.com/~lynn/2009h.html#44 Book on Poughkeepsie
http://www.garlic.com/~lynn/2009h.html#47 Book on Poughkeepsie
http://www.garlic.com/~lynn/2009h.html#48 Book on Poughkeepsie
http://www.garlic.com/~lynn/2009h.html#55 Book on Poughkeepsie
http://www.garlic.com/~lynn/2009h.html#56 Punched Card Combinations
http://www.garlic.com/~lynn/2009h.html#61 Punched Card Combinations
http://www.garlic.com/~lynn/2009h.html#62 Book on Poughkeepsie
and a recent, separate virtual machine thread in a.f.c:
http://www.garlic.com/~lynn/2009h.html#59 Operating Systems for Virtual Machines
http://www.garlic.com/~lynn/2009h.html#63 Operating Systems for Virtual Machines
http://www.garlic.com/~lynn/2009h.html#64 Operating Systems for Virtual Machines
http://www.garlic.com/~lynn/2009h.html#65 Operating Systems for Virtual Machines
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Re: Any idea? Dirmaint error by detach 123 disk(540RES)
On Fri, 29 May 2009 21:41:52 -0500, Mike Walter wrote: >>Atheletic Training Department >"Atheletic"? It is unfortunate that you're not located next door to the English Department. ;-) They keep them(English) as far away from me as possible, the complete oth er end of campus. (not that it's that big of a campus) In fact, I have to go through the Psychology Department to get there. > >And yes, I make more than my own fair share of typos. - but it's still F riday. > >Mike Walter >Hewitt Associates > /ahw
Re: Any idea? Dirmaint error by detach 123 disk(540RES)
On Sat, May 30, 2009 at 1:31 AM, Alan Altmark 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
