Alain,
The VM:Operator "primitive" command to cause the script to wait for a
given period and/or number of messages is:
"PROCESS WAIT [seconds|* [messages|1] ]
The 'TEST' before 'PROCESS WAIT' prevents an error if a nonzero return
code is issued - which is likely, as the number of messages returned in
the stack is the return code (or '24' for a 'PROCESS WAIT' parameter
error).
Because they are VM:Operator "primitive" commands (not CP, CMS, etc.
commands), VM:Operator primitives must be executed from the rexx 'VMOPER'
addressing environment (VMOPER is the default addressing environment for
scripts with filetype VMOPER).
For example:
/* TEST EXEC */
trace i
address COMMAND
say time() ' envir='address()
'TEST PROCESS WAIT 5'
say time()', rc='rc
address VMOPER
say time() ' envir='address()
'TEST PROCESS WAIT 5'
say time()', rc='rc
Exit 0
And the trace results:
4 *-* address COMMAND
5 *-* say time() ' envir='address
>F> "09:17:08"
>L> " envir="
>O> "09:17:08 envir="
>F> "COMMAND"
>O> "09:17:08 envir=COMMAND"
09:17:08 envir=COMMAND
6 *-* 'TEST PROCESS WAIT 5'
>L> "TEST PROCESS WAIT 5"
+++ RC(-3) +++
7 *-* say time()', rc='rc
>F> "09:17:08"
>L> ", rc="
>O> "09:17:08, rc="
>V> "-3"
>O> "09:17:08, rc=-3"
09:17:08, rc=-3
9 *-* address VMOPER
11 *-* say time() ' envir='address
>F> "09:17:08"
>L> " envir="
>O> "09:17:08 envir="
>F> "VMOPER"
>O> "09:17:08 envir=VMOPER"
09:17:08 envir=VMOPER
12 *-* 'TEST PROCESS WAIT 5'
>L> "TEST PROCESS WAIT 5"
13 *-* say time()', rc='rc
>F> "09:17:13"
>L> ", rc="
>O> "09:17:13, rc="
>V> "0"
>O> "09:17:13, rc=0"
09:17:13, rc=0
14 *-* Exit 0
Note the 5 second delay between the messages at 09:17:08 and 09:17:13.
See the VM:Operator Programming Guide for more details. And... welcome to
the use of VM:Operator macros! Great stuff.
Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.
"Kris Buelens" <kris.buel...@gmail.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
03/08/2011 04:41 AM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: RACFVM: ICH520I
You should better not place a CP SLEEP in VM:Operator scripts: it will
make the whole VM operator go to wait, and when many message arrive for
VM:operator while it waits, CP's IUCV queue could get full and CP will
then throw them at the console, instead of presenting them to IUCV, where
VM:Operator will find them. With other words: the extra messages are lost
for VM:Operator's automation.
Better is the code a REXX script in a file with type VMOPER, and then you
can code "TEST WAIT" (if I remember well), that will put only that script
in a wait state. Maybe the keyword to start a VMOPER differs from the
keyword to start an EXEC. SPAWN comes in my mind. It's all a long time
ago that I played with VM:Oper automatisation.
2011/3/8 Alain Benveniste <a.benveni...@free.fr>
Kris
You are right
ICH520i appears before a CST and a RPI message.
If i execute my vmoperator script on the last standard message format, It
works.
If I put a sleep in my script and execute it as soon as ich520i appears,
it works.
I think to open a pmr for this.
Alain
er well)
Le 8 mars 2011 à 08:38, Kris Buelens <kris.buel...@gmail.com> a écrit :
Alan, people using the VM:Operator software have it normally installed in
the "System Operator", so it is started before RACF comes up. He,ce it is
indeed tempting to use a RACF message to start automated startup using
VM:Operator "scripts".
2011/3/8 Alan Altmark <alan_altm...@us.ibm.com>
On Monday, 03/07/2011 at 11:10 EST, Alain Benveniste
<a.benveni...@free.fr> wrote:
> ICH520I RACF xxxxx IS ACTIVE.
> Explanation:
> RACF release xxxxx has been successfully initialized.
>
> I removed xautolog autolog2 from raciplxi and I asked VM:Operator to
autolog
> VMSERV* users prior to xautolog autolog2 when the message ICH520I is
met.
> I got a HCP6525E External Security Manager is unavailable.
> ICH520I seems to lie ! :)
It is in there so that we can catch people trying to cheat RACF and
AUTOLOG2. The only virtual machines that are permitted to start prior to
RACF are the SYSTEM_USERIDs from SYSTEM CONFIG (e.g. OPEREREP, OPERATOR,
etc.). They run with their CP-given permissions until RACF is up.
AUTOLOG2 should start VM:Operator, which can then bring up the rest of the
system.
If you want something a little "cleaner":
1. Put SYSTEM_USERIDS STARTUP RACFVM in SYSTEM CONFIG
2. Change RACIPLXI EXEC to autolog AUTOLOG1.
Alan Altmark
z/VM and Linux on System z Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott
--
Kris Buelens,
IBM Belgium, VM customer support
--
Kris Buelens,
IBM Belgium, VM customer support
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. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
