BEGIN would not help: it would indeed restart the user, but, it posts
a VMREAD, but:BEGIN would not help:
-it would indeed restart the user, but, it posts a VMREAD, but,
-as mentioned: without an "active" secondary user this becomes a CPREAD
--> catch22
The only solution is to have an active secondary user, i.e.
- logged on itself
- or having a path to IUCV *MSG
(WAKEUP (IUCVMSG, PIPE STARMSG, PROP, VM:Operator, VM Ops Manager, ..)
Untested:
/* */ Address command
'CP SET SECUSER SQLPROD *'
'WAKEUP +0 (IUCVMSG'
'CP ATTACH A93 SQLPROD 181'
'CP SEND SQLPROD ARCHIVE'
success=0
do until stop
'WAKEUP +10(IUCVMSG'
stop=1
Select
when rc=6 then say 'bye'
when rc=2 then Say 'timeout from SQLPROD'
when rc<>=5 then Say 'Unexpected rc' rc 'from WAKEUP'
otherwise
stop=0
parse pull . fromuser msg 0 . . msgID .
if fromuser<>'SQLPROD' then say fromuser':' msg
else select
when msgId='ARI0299A' then 'CP SEND SQLPROD 181'
when msgId<>'ARI0292I' then say msg
otherwise
success=1
stop=1
say msg
end
end
end
'CP SET SECUSER SQLPROD OFF'
'WAKEUP RESET'
as mentioned: a CPREAD without an "active" secondary user becomes a CPREAD
2009/5/31 Scott Rohling <[email protected]>:
> 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
> <[email protected]> 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.
>>>
>>>
>>>
>
>
--
Kris Buelens,
IBM Belgium, VM customer support
