I wouldn't say that placing LINKs in execs/control files is that much
easier that updating the CP directory. Additionally: the directory is
the "natural place" to define virtual machine configurations. Not that
I'm entirely against other solutions if they make life much easier...
I also performed a test (I was right once and wrong once).
* CP SET CPCONIO IUCV is indeed required to trap SCIF messages (OK
by default if you use PROP, VM:Operator, Operations Manager or alike).
* COMMAND SPOOL CONSOLE START doesn't help to catch device problems
(LINK/MDISK/DEDICATE/...)
The definiton
USER EREP EREP 0008192K 0016384K FGBC
* ENVIRONMENTAL RECORDING AND EDITING AND PRINTING
INCLUDE GENERCMS
ACCOUNT EREP C/O-8541
COMMAND SPOOL CON START TO KRIS
IUCV *LOGREC
CONSOLE 0009 3215 T KRIS OBS
LINK MAINT 0201 0201 RR
MDISK 0191 3390 228 2 VTE001 MR
MDISK 1111 3390 228 2 NODISK MR
*DVHOPT LNK0 LOG1 RCM1 SMS0 NPW1 LNGAMENG PWC19920601 CRCD[
The resulting console created by COMMAND:SPOOL ...
File (none) (none) from EREP at VMKBBR01 Format is CONSOLE.
* * * Top of File * * *
z/VM 5.3 - 20 Jun 2008 - rsu703
HCPCRC8064I Recording data retrieval has been started; reco
HCPRET8056I RECORDING RETRIEVAL DISK 88% FULL
COMMAND ACCEPTED
* * * End of File * * *
With WAKEUP:
tstrex
TSTREX allows you to interactively execute REXX instructions -
each instruction string is executed when you hit Enter.
environment = CMS
Go on - try a few...
To end : "PF3" to dump vars: REXDUMP or DUMP v1 v2 vn or DUMP v.
"PF15" or EXTRACT /xedit-settings
'WAKEUP +0(IUCVMSG'
R(2); <TSTREX> .........................................................
cp set CPCONIO IUCV
cp xautolog erep
do until rc<>5;'WAKEUP +00:05(IUCVMSG QUIET';end
'PIPE STACK!CONS'
*CP KRIS EREP : COMMAND ACCEPTED
*CP KRIS EREP : HCPRET8056I RECORDING RETRIEVAL DISK 88% FULL
*CP KRIS EREP : HCPCRC8064I Recording data retrieval has been
started; recording *LOGREC for userid EREP.
*CP KRIS EREP : z/VM 5.3 - 20 Jun 2008 - rsu703
*CP KRIS HCPCLS6056I XAUTOLOG information for EREP: The IPL
command is verified by the IPL command processor.
*CP KRIS AUTO LOGON *** EREP USERS = 7
*CP KRIS EREP : HCPLNM108E EREP 1111 not linked; volid NODISK
not mounted
*CP KRIS Command accepted
*MSG RACFVM ICH70001I EREP LAST ACCESS AT 13:29:42 ON TUESDAY,
MARCH 2 2010
R; <TSTREX>
...................................................................
2010/3/2 Tony Thigpen <t...@vse2pdf.com <mailto:t...@vse2pdf.com>>
Mikes suggestion is what I use. I place all LINK commands for VSE
disks in an exec on the shared 191 disk.
This is an easy solution to your problem and it makes maintenance of
the VSE dasd much easier. No longer will you need to modify the
directory to add a new VSE volume. Just link WR to the VSE 191
shared disk and change it.
I would suggest the same for VCTCAs and such. Keep changes to the
directory to the minimum.
Tony Thigpen
-----Original Message -----
From: Mike Walter
Sent: 03/01/2010 03:55 PM
Mike,
Along those lines, would it be feasible to move the CP Directory
LINK statements for each guest into a CMS file where the shared
PROFILE EXEC resides?
There could be one file for "COMMVSE CMDS" containing LINK
commands that every VSE guest issues.
Then a separate file for each guest that has "special needs"
(let's not "go there" regarding comments about how all VSE
guests have "special needs: - it's not Friday yet!). ;-)
For example:
"VSE1 CMDS" contains only LINK (and/or other!) commands required
by that server.
"VSE2 CMDS" contains only LINK (and/or other!) commands required
by that server.
And so on...
The common PROFILE EXEC would issue: address CMS 'STATE COMMVSE
CMDS *'
If rc<>0 then ... report that a critical file is missing and do
whatever is required...
address CMS 'STATE' userid() 'CMDS *'
If rc<>0 (and for those servers where the missing file is
critical) ... report that a critical file is missing and do
whatever is required...
Else ... read the "userid() CMDS *" file, executing each
command, reporting non-zero return codes as required.
No PROP or other PROP-like facility would be required.
Just a thought since you seemed to want to avoid PROP ...
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Horlick, Michael" <michael.horl...@cgi.com
<mailto:michael.horl...@cgi.com>>
Sent by: "The IBM z/VM Operating System"
<IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU>>
03/01/2010 02:42 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU
<mailto:IBMVM@LISTSERV.UARK.EDU>>
To
IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU>
cc
Subject
Re: Trapping output right after LOGON
Hello Doug,
I do have a shared PROFILE EXEC that sets up the environment
before the IPL of z/VSE in each of the VSE users. Changing the
exec to validate that each machine has the minidisks it requires
is more prone to error then having CP tell me that something is
amiss at LOGON time. Thanks, Mike Horlick
Conseiller
CGI Gestion Intégrée des Technologies
1350 Boul. René-Lévesque Ouest
Montréal, Qc, H3G 1T4
From: The IBM z/VM Operating System
[mailto:IBMVM@LISTSERV.UARK.EDU
<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of Doug Shupe
Sent: March 1, 2010 3:28 PM
To: IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: Trapping output right after LOGON
Mike,
You could have one or many of your VSE guests IPL CMS in the
directory and have them all point to a shared RR 191 mini disk.
Then customize a PROFILE EXEC to do the CP 'whatever' and then,
determine what to really IPL based on USERID. Sorry its not
REXX, old stuff.
PROFILE EXEC:
&TRACE
CP SP CONSOLE START * DROPBUF &BUFNO MAKEBUF &BUFNO = &RC
EXECIO * CP ( MARGINS 1 8 STRING QUERY USERID &IF &RC NE 0
&CALL -ERROR &RC &READ STRING &ME &IF &ME EQ VSEID &GOTO
-VSEID CP MSG OP USER &ME ATTEMPTED TO USE SHAREIPL. NOT
DEFINED. &GOTO -EXIT -VSEID EXEC VSEID &ME &GOTO -EXIT -ERROR
&RC = &1 &READ STRING &LERROR &TYPE &0 PROBLEM OCCURED TRYING
INQUIRY ON USERID. &TYPE &0 &LERROR &EXIT &RC -EXIT &EXIT 999
====================
VSEID EXEC: &TRACE ALL &ME = &1 CP SET RUN ON *
************************************* * >>>
CAUTION <<< * THE FOLLOWING COMMAND HAS X'15' * *
>>> CAUTION <<< * BETWEEN THE WORDS GUEST AND IPL.
* * >>> CAUTION <<< * ISSUE THE 'SET HEX ON'
COMMAND * * >>> CAUTION <<< * BEFORE CHANGING
THIS LINE. * *
*************************************
* EACH COMMAND MUST BE FOLLOWED BY A X'15'.
* * TO ACCOMPLISH THIS;
* * 1). SET HEX ON
* * 2). KEY THE COMMANDS(LEAVING 2
SPACES BETWEEN EACH) ON 1 LINE* * 3). BRING THE LINE JUST
KEYED TO THE CURRENT LINE. * * 4). CH
/X'4040'/X'15'/1 N (N = THE NUMBER OF COMMANDS) * *
5). FILE *
* CP TERM CONM 3270 BRE GUEST"IPL 1A6 CLEAR * CP TERM CONM
3270 BRE GUEST"IPL 1A7 CLEAR LOADPARM ....T * CP TERM CONM 3270
BRE GUEST"IPL 1A7 CLEAR LOADPARM ..... CP MSG OP IPL FAILED FOR
&ME RC= &RC EXIT &RC
==================
Regards, Doug ----- Original Message ----- From: Horlick,
Michael To: IBMVM@LISTSERV.UARK.EDU
<mailto:IBMVM@LISTSERV.UARK.EDU> Sent: Monday, March 01, 2010 14:52
Subject: Re: Trapping output right after LOGON
What do you mean by « Changing LINK to COMMAND LINK may help,
that's for sure. I have MDISK statements for my VSE minidisks.
Also, we run VM:Operator and not PROP. One of the guys in our
automation group set up VM:Operator and I wonder if he knows how
to handle output right from an XAUTOLOG of a virtual machine.
Mike Horlick
Conseiller
CGI Gestion Intégrée des Technologies
1350 Boul. René-Lévesque Ouest
Montréal, Qc, H3G 1T4
From: The IBM z/VM Operating System
[mailto:IBMVM@LISTSERV.UARK.EDU
<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of Kris Buelens
Sent: March 1, 2010 2:00 PM
To: IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: Trapping output right after LOGON
Mike, I think I tried COMMAND SPOOL CONS START but COMMANDs
seem to be executed after the devices are set up, hence too late
to catch problems with MDISK statements.
Changing LINK to COMMAND LINK may help, that's for sure.
2010/3/1 Mike Walter <mike.wal...@hewitt.com
<mailto:mike.wal...@hewitt.com>>
Look up the directory "COMMAND" statement in the CP Planning and
Administration manual.
E.g. In the CP Directory entry for each VM userid for which you
want the
virtual console started as the VM is constructed the line:
COMMAND SPOOL CONSOLE START
Only CP commands may be entered into the CP Directory for users.
You may
specify any CP command argument. More details in the manual.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Horlick, Michael" <michael.horl...@cgi.com
<mailto:michael.horl...@cgi.com>>
Sent by: "The IBM z/VM Operating System"
<IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU>>
03/01/2010 12:41 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU
<mailto:IBMVM@LISTSERV.UARK.EDU>>
To
IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU>
cc
Subject
Trapping output right after LOGON
Greetings,
I would like to trap all the CP console output from a virtual
machine from
its initial XAUTOLOG/LOGON. I have several z/VSE machines which are
XAUTOLOGed on by the operator. Reason? In rare instances, maybe
a pack is
not attached to the system which contains some minidisks used by
these
machines. I know there could be a message such as:
HCPLNM108E MIKE A194 not linked; volid XT160D not mounted
For a test I have changed a virtual machine CONSOLE statement in its
directory to CONSOLE 009 T MIKE OBS and I get all messages after
the user
logs on. I would like to programmatically trap these messages from a
disconnected service machine so that it can be detected. Tried
WAKEUP but
no luck.
Suggestions?
Mike Horlick
Conseiller
CGI Gestion Intégrée des Technologies
1350 Boul. René-Lévesque Ouest
Montréal, Qc, H3G 1T4
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.
--
Kris Buelens,
IBM Belgium, VM customer support
