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.
>>
>>
>>
>>
>

Reply via email to