Hi Skip,
Since it is DRS that can write a dataset, not VPS, there's the wrench in that ringer. The second output statement could be used to make the second copy (in the queue) of SMPDATA1 for a JES2 external writer to pick up. I have used the JES2 external writer at times to take sysout off to tape. The book says that it will work for disk also. How about your archival system? Can you send the first copy off to it as normal and, using the second output statement, send a second copy of the SMPDATA1 off under a writer name? For example, we have CA-View. I can send a complete copy of any job I run to it and I can send it a second copy of a sysout (or the entire sysout ) by using the second output statement with a free=close on the DD statement. Then I can wait for a bit to let the archive complete and run a recall for the writer name and write it to disk. Since the copy with the writer name is unique (enough) so that the one I want is the most recent item archived under that name, I don't have to worry about coding the gereration and sequence number - it will default to the matching name that is most recently archived. HTH, Linda ----- Original Message ----- From: "Skip Robinson" <[email protected]> To: [email protected] Sent: Saturday, February 12, 2011 2:15:34 PM Subject: Re: Is there a way to have SMPE indicate if an LMOD is changed? 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 [email protected] From: Linda Mooney <[email protected]> To: [email protected] 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 <[email protected]> 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" <[email protected]> To: [email protected] 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:[email protected]] On > Behalf Of Linda Mooney > Sent: Friday, February 11, 2011 5:20 PM > To: [email protected] > 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" <[email protected]> > To: [email protected] > 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 > [email protected] > > > > From: Linda Mooney <[email protected]> > To: [email protected] > 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 <[email protected]> > > > > 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" <[email protected]> > To: [email protected] > 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 > [email protected] > > > > From: B Pothoff <[email protected]> > To: [email protected] > 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 <[email protected]> > > > > 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 [email protected] 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
