Could your REXX step read either the SMPOUT report from the SMP/E step with SDSF
or read the SMP/E log?
Bob
Skip Robinson wrote:
We have VPS but not DRS. Let me describe the problem I'd like to solve.
GDPS is not currently orderable in ServerPac, so we install it in its own
CSI. I need a simple mechanism to compare the 'maintenance level' of the
installed (SMP/E) version and execution (DR) version. I'm satisfied with a
date/time stamp showing when GDPS was updated by any sysmod whatever. I've
written a short Rexx to insert a date/time record into a GDPS parameter
library. It doesn't matter what got modified. I just want a quick eyeball
method to verify that the execution version is current. My Rexx runs as a
second step in the APPLY job. I submit a single job stream for APPLY
CHECK, then resubmit the same job via SDSF SJ with 'CHECK' commented out,
which ensures that the real APPLY picks up exactly the same sysmods that
CHECK ran against.
Trouble is that the Rexx step cannot tell whether the preceding APPLY step
was a CHECK or a real APPLY. I don't want an update stamp on CHECK, On a
real APPLY, I can manually uncomment the Rexx step just as I comment out
'CHECK'. That's a kludge. If the Rexx step could examine the change
report, it would know whether or not to create a new time stamp. But I
also want the change report to stay with the APPLY job as a long term
record of what happened in that run. Hence the wish for both sysout and
DASD copies containing, as noted in this thread, the same data made
available to a following step in the same job.
While GDPS is my immediate motivation, it turns out that *any* product
installed and maintained in its own CSI could utilize the same mechanism.
For example, I manage StarTool in its own CSI but run it on every system
in the enterprise. The 'GDPS solution' could be used for any ISV product.
.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Linda Mooney <linda.lst...@comcast.net>
To: IBM-MAIN@bama.ua.edu
Date: 02/11/2011 06:55 PM
Subject: Re: Is there a way to have SMPE indicate if an LMOD is
changed?
Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu>
Hi Dave,
Point the sysout to two JCL output statements, one to the JES queue and
the other to JES with the class that VPS picks from and destination (or
writer, depending on how VPS is set to pick from the queue - could be
either way). VPS picks up its copy of the output from the queue for
delivery to a 'printer'. DRS presents a VTAM or TCP/IP virtual printer,
and can be coded to write a dataset to DASD. I have done many of these
setups. They work quite well.
If by cuncurrent you mean that they contain the same data, then yes they
do.
//SYSMSG OUTPUT DEFAULT=YES,JESDS=ALL,CLASS=M,FORMS=8411,FCB=8411
//REPORTS OUTPUT CLASS=M,wri ter or dest =VPSmember
//sysprint DD SYSOUT=(,),OUTPUT=(*.REPORTS,*.SYSMSG)
Since using DRS to write the dataset introduces a delay, the user would
probably have to run a follow on job to process the dataset, but on the
other hand, using a free=close and, perhaps coding a wait step would get
him past the short delay to write the dataset. I have not needed (or
wanted) to pull these datasets back into the same jobstream, so I have
never tested that.
The VPS and DRS member names can be whatever conforms to your standards.
Personally, I keep mine matched up between VPS and DRS when I am coding
both. The is also an entry to code in the VPS member to either keep or
process any carriage conntrol in original sysout. I generally use VTAM
definitions for my local stuff, and IP DRS definitions for things that
comes in from our own servers. Oh, if you want to write non-SMS
controlled GDGs, let me know, it's a bit 'special' in the setup, but it
works fine.
Linda
----- Original Message -----
From: "Dave Gibney" <gib...@wsu.edu>
To: IBM-MAIN@bama.ua.edu
Sent: Friday, February 11, 2011 5:55:08 PM
Subject: Re: Is there a way to have SMPE indicate if an LMOD is changed?
Interesting, how do you do that? I could look it up, but I don't see how
you get "concurrent".
Dave Gibney
Information Technology Services
Washington State University
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Linda Mooney
Sent: Friday, February 11, 2011 5:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Is there a way to have SMPE indicate if an LMOD is changed?
Hi Skip,
Do you have the LRS products VPS and DRS? If so, I can help you with
coding
so that you can have your sysout and dataset too.
Linda
----- Original Message -----
From: "Skip Robinson" <jo.skip.robin...@sce.com>
To: IBM-MAIN@bama.ua.edu
Sent: Friday, February 11, 2011 4:50:15 PM
Subject: Re: Is there a way to have SMPE indicate if an LMOD is changed?
I never noticed SMPDATA2 before this thread. I write SMPDATA1 to sysout,
so it would never spill anyway. I wish I could concurrently write the
same
data to both sysout (for archive purposes) AND to DASD for processing in
a
later step in the same job.
.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Linda Mooney <linda.lst...@comcast.net>
To: IBM-MAIN@bama.ua.edu
Date: 02/11/2011 04:45 PM
Subject: Re: Is there a way to have SMPE indicate if an LMOD is
changed?
Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu>
Hi Skip,
As I'm setting this up in my SMP/e environment (thank you!), I went
ahead
and looked at SMPDATA1 and SMPDATA2 in the SMP/e 3.5 Reference to
check to be sure that SMPDATA2 was also available. I set both up so
that I
will have spill processing. Pretty cool.
Thanks,
Linda
----- Original Message -----
From: "Skip Robinson" <jo.skip.robin...@sce.com>
To: IBM-MAIN@bama.ua.edu
Sent: Friday, February 11, 2011 10:03:25 AM
Subject: Re: Is there a way to have SMPE indicate if an LMOD is changed?
The CHANGEFILE was added to SMP/E (quite) a while back to satisfy a user
requirement for a machine readable record of the changes implemented
during APPLY or RESTORE. The file is only minimally formatted because
the
requirement did not ask for an elaborate report; just data sufficiently
keyworded that a user written Rexx, for example, could digest it and
take
whatever action the user deemed appropriate.
To turn on CHANGEFILE via the SMP/E dialog, do this on the 'OPTIONS
ENTRY
xxxxxxxx - GENERAL' panel:
CREATE LIBRARY ===> yes (YES or NO, default: NO) Create library CHANGE
FILE change file during APPLY and RESTORE
command processing.
Provide a DD card or DDDEF for SMPDATA1. This file could be put to disk
and
used as input for a subseqent job step.
.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: B Pothoff <bill_poth...@bmc.com>
To: IBM-MAIN@bama.ua.edu
Date: 02/11/2011 08:34 AM
Subject: Re: Is there a way to have SMPE indicate if an LMOD is
changed?
Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu>
The "changefile" records I'm referring to live in SMPDATA1 / SMPDATA2.
Specifically, it looks like the E0 element record might be what you're
looking
for. It identifies LMODs that were changed during APPLY processing, as
well
as the target DD name, which can be resolved to the target DSN with the
L0
record.
http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?
topic=/com.ibm.zos.r9.gim2000/lclcr.htm
An Element Record Type 0 (E0) is created for each element or LMOD that
changed in a target library during APPLY or RESTORE processing. The term
changed in this context refers to an element or LMOD that been deleted
or
replaced in a target library as a result of SMP/E processing. See Valid
action
types for more information.
The purpose of the E0 record is to identify the changed elements or
LMODs
in the associated target libraries identified by the L0 and L1 records.
-Bill
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
