Might I humbly suggest going through the attached process before twiddling
any bits? Getting doc for IBM is always a good idea so that hung users
don't make a reappearance. Each time one appears, shoot the problem so we
don't have to shoot the users. Even if it might be a good idea to shoot
some users! ;-)
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
READ: HUNGUSER HELPME
When a userid becomes hung in a LOGOFF/FORCE PENDING state, the following
alternatives may be tried -- some require more than class "G" privs:
- If you have the time, simply waiting 15 minutes for CP to perform
housecleaning chores might free the userid, completing the LOGOFF
or FORCE.
- Use the public domain utility "TRACK" to determine if the userid is
awaiting completion of an I/O to a particular unresponsive device.
Use the commands:
TRACK hungid DEV CLASS * IO PENDing
TRACK hungid DEV CLASS * IO ACTIVE
Nota bene: As of 23 Feb 2006 TRACK can be obtained from:
http://vm.marist.edu/track/code.html
- Before attempting anything that actually changes the hung userid,
if you can (consider communication time-outs which may occur that
could affect other users) before muddying the waters, get a current
system dump for IBM to diagnose later. From a privclass "A' user:
CP QUERY DUMP (then ensure that it is going to disk)
Then: CP WNG ALL This system may be non-responsive for a few minutes
while diagnostic information is obtained.
Then: CP SNAPDUMP
- Sometimes a simple message frees up the "hungid" without further ado.
From a privclass A, B, or C userid, issue:
CP WNG hungid Hello
- If the ID was awaiting I/O to a terminal, simply connecting from a
working terminal may free the ID. From a free terminal, issue:
CP LOGON hungid HERE
- For users logged on via TELNET terminals, issue:
NETSTAT TELNET
Find the matching tn3270 connection, and issue:
NETSTAT DROP conn_num
- "CPHX" is reported to cancel pending CP commands: ATTACH, LOCATE,
LOCATEVM, and VARY ONLINE|OFFLINE (see HELP for more detail).
From a privclass "A" userid, issue:
CP CPHX hungid
- If TRACK (above) showed an active I/O which cannot be remedied
(e.g. by making a tape drive "Ready"), the I/O may be able to be
cancelled. From a privclass "A" userid, issue:
CP HALT rdev
Due to queued I/Os or recalcitrant devices, HALT may need to be issued
repeatedly until the following message is received:
Halt was not initiated to tape nnnn because the device as not active
- If nothing freed the hung user, open a Problem Management Report (PMR)
with IBM, and provide the SNAPDUMP for analysis.
.cm Last updated 2007/01/04 mrw
"Hooker, Don" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <[email protected]>
09/10/2007 04:38 PM
Please respond to
"The IBM z/VM Operating System" <[email protected]>
To
[email protected]
cc
Subject
"Ghost" users on z/VM 5.2
It's been *so* long since I've seen users stuck in "Logoff/Force
Pending" state for any length of time that I thought it had been fixed.
We have a z/VSE guest stuck in that state since Sunday.
Anybody else seen this on current levels of z/VM?
Many years ago when it was a more frequent problem, I wrote an assembler
program that massaged some bits in the (then) VMBLOCK to free it up. I
did not take some things into account at the time, so sometimes it
worked, but then othertimes... <expletive deleted>
Does anybody have any current tricks to free up a user in this state
(short of VM IPL).
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient
is strictly prohibited.
