The SID (SYSTEM ID) of the TYPE 26 RECORD is the system on which the job PURGED, and in a JES2 MAS, whichever system happened to have the checkpoint record (I think that is what it is called) will write the purge record. A very common experience, to find the purge record on a system different than where the job executed (SYSEXEC). I think it may also be, often, the system on which the last output was processed, as that precedes the PURGE event, but that is NOT a guarantee. Also, SYSEXEC will ONLY be NON-BLANK in the type 26 record that was created on the execution system when the job terminated. All other purge records for a job will have SYSEXEC blank.
Barry >From ADOC26J2 in the MXG Source Library: TYPE26J2: JES2 Purge Record The TYPE26J2 data set contains one observation for each type 26 written by JES2. A type 26 SMF record is written when all SYSOUT for a job is processed at this node, when a job is purged by the operator-issued purge ($P) command, or when a job is transmitted from one node to another by NJE (either for execution at the next node or for printing SYSOUT at that node). Multiple purge records can occur for the same job in an NJE environment. The purge record that describes the actual execution phase of the job (as opposed to NJE transmit or receive actions for input or SYSOUT processing) has a non-blank value for the SYSEXEC variable. At each node where a purge record is created, the SMF record is written on the system where the purge event occurred, which is not necessarily the system on which the job executed. That is why it is extremely important if you have multiple systems at a node, the SMF data from all systems at that node must be processed together to construct the composite PDB.JOBS, since the job can be read in, converted, executed, printed, and purged on different systems within a node. In addition to "normal" purge records, the JES2 Spool Transfer program creates additional job purge records. If a job which is still in the execution queue after it has been executed (eg., a job which encountered a DSENQ conflict that was canceled and requeued, or any job processed by the MVS Throughput Manager product) is spool transfered and reloaded, two purge records will be created (one at offload, one after real execution) and both contain non-blank values for SYSEXEC. A non-blank SYSEXEC separated the "real" purge record (for PDB.JOBS) from the multiple NJE purge records (into PDB.NJEPURGE). If two (or more) purge records with non-blank SYSEXEC are found in the same BUILDPDB run, duplicate observations in PDB.JOBS were built. The use of just SYSEXEC to identify "real" purge records is insufficient. MXG circumvents this absence of only one "real" purge record in BUILDPDB, even if multiple are found, and puts the "unwanted" purge record created at offload by JES2 Spool Transfer program (DEVNAME, Transmit Device Name beginning with OFF) into the PDB.NJEPURGE data set. If your site does not use Spool Transfer, you have no exposure. TYPE26J2 contains the starting time stamp and duration of a job on each JES2 processor (reader, converter, execution, output, and purge), as well as the system identification of the CPU where each JES2 event occurred. It is the source of JES2 priorities when the job was read in, executed, and printed, and the only source of I/O counts processed to the spool on behalf of the job or session. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Regan Sent: Thursday, June 26, 2014 6:32 AM To: [email protected] Subject: Re: SMF record that records a job being submitted from one system but executing on a different with the same JES2PLEX? Okay, I've dumped the SMF26 records from this development system, to be called X2. From looking at these four SMF26 fields that Barry referred to, some of the records have system X1 listed in all four fields, even though the SID field says X2. Since we use zOSEM here I wonder if behind the scenes it tricked JES2 into thinking the job was actually submitted from X1 instead of X2? I noticed that in one record's field, SMF26NAM (Programmer's Name), it was described as a "PRODUCTION" job. Thanks, Mark Regan <>< ________________________________ From: Barry Merrill <[email protected]> To: [email protected] Sent: Wednesday, June 25, 2014 11:51 AM Subject: Re: SMF record that records a job being submitted from one system but executing on a different with the same JES2PLEX? TYPE26 records contain four SYSTEM fields, SYSREAD $EBCDIC4. /*SMF26RID*/ SYSCVRT $EBCDIC4. /*SMF26CID*/ SYSEXEC $EBCDIC4. /*SMF26XID*/ SYSOUTP $EBCDIC4. /*SMF26OID*/ And Job Class SMF26WJC $EBCDIC8. /*JOB*CLASS*/ But only Throughput Manager records contain SYSTEM AFFINITY information, I think. Barry Merrill Herbert W. “Barry” Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229 [email protected] http://www.mxg.com - FAQ has Most Answers [email protected] – invoices/PO/Payment [email protected] – technical tel: 214 351 1966 - expect slow reply, use email fax: 214 350 3694 – prefer email, still works -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Regan Sent: Wednesday, June 25, 2014 10:23 AM To: [email protected] Subject: SMF record that records a job being submitted from one system but executing on a different with the same JES2PLEX? We have a JES2Plex/JES2MAS that has three LPARS in it, two prod and one dev. Later this year the development LPAR will be moving to a different sysplex that only supports development work. What I want to find out is if anyone submits jobs from this dev LPAR, but either codes a Class that is only on, on prod or codes a SYSAFF to force it to run on prod that way. Thanks, Mark Regan <>< ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
