On Sat, May 30, 2009 at 1:31 AM, Alan Altmark alan_altm...@us.ibm.com 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
On Fri, 29 May 2009 21:41:52 -0500, Mike Walter mike.wal...@hewitt.com
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
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
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
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
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
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
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
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
