SMF NJE SYSOUT

This section discusses NJE routed SYSOUT. NJE routed SYSOUT can originate from any other node defined to an NJE network.
micsrm140
The originating node can be as physically close as another spool defined within the same physical processor, or as distant as a data center on the other side of the Earth. For information on SYSOUT created and printed within the same MVS node, see SMF Local and Remote SYSOUT.
NJE SYSOUT in your BATSPL file is characterized by observations with a SPLMASK of '...WPx' where:
...
indicates the absence of execution records
W
indicates the presence of one or more SMF type 6 output writer records
P
indicates the presence of an SMF type 26 non- execution node purge record
x
can have a value of 'H' or '.' indicating the presence or absence of the Job Account Derivation Hold (BATSFH) file observation
You can easily identify BATSPL observations representing NJE SYSOUT by examining the value of the NJE SYSOUT Record Count (SPLNJESR) data element. SPLNJESR has a value of one when the BATSPL observation represents NJE SYSOUT. Note that SPLNJESR is not a comprehensive count of NJE routed SYSOUT. When NJE routed SYSOUT records are associated with the execution records from the originating job, SPLNJESR is not set. SPLNJESR simply indicates that the execution records from the originating job were not present when
MICS
created the BATSPL observation.
Providing accountability for NJE routed SYSOUT is complex and the solutions depend on how you configure
MICS
and where the SYSOUT originated.
The following sections explore the accounting problems and solutions for NJE routed SYSOUT accountability.

NJE SYSOUT and
MICS
Configurations

This section discusses how to maximize accountability for NJE routed SYSOUT where the SYSOUT both originates and prints at MVS nodes whose SMF files are input to a single
MICS
unit.
SYSOUT originating from non-MVS nodes, such as VM, is discussed in the next section. SYSOUT originating at an MVS node and routed to a non-MVS node for printing does not produce SMF records, and is therefore not captured or processed by this
MICS
product.
The easiest way to maximize accountability for NJE routed SYSOUT is to ensure that all SMF data from all the various interconnected MVS nodes is fed into a single
MICS
unit. This will ensure that the
MICS
unit will always encounter the execution records for the activity that produced the print.
NJE Network: Two Different MVS Nodes Feeding One
MICS
Unit
MVS MVS NODE A NODE B +-------------+ +----------------------+ | JES SPOOL | | JES SPOOL | | +------+ | | +------+ +------+ | | | SYSA | |<- NJE ->| | SYSB | | SYSC | | | +---|--+ | | +---|--+ +---|--+ | +-------|-----+ +------|---------|-----+ | | | | SMF +---------+ SMF | SMF | +---->|
MICS
|<-----+---------+ | UNIT | +---------+
NJE
SYSOUT where
MICS
processes the execution records
Even when all SMF data from MVS nodes involved in NJE SYSOUT transmission is fed into a single
MICS
unit, there are two problems that complicate the association of the execution records with the SYSOUT records.
The most common problem occurs because
MICS
discards the suspended records for a job when the SMF type 26 execution node purge record is encountered. Any NJE-routed SYSOUT printed after the execution node record is written and processed by
MICS
will not be associated with the execution records from the job.
The solution to this accountability problem is to activate the Job Account Derivation Hold (BATSFH) file. The BATSFH file is described in the BATSFH - Job Account Derivation Hold File section. To activate the file, use the SFHLIMIT option statement as discussed in the SFHLIMIT Statement section. The BATSFH file contains the accounting fields used by your account code exit routine (ACCTRTE). An observation is written to the BATSFH file when
MICS
is about to discard the execution records for the job. The BATSFH observations are available for a site-specified number of daily update cycles to provide accountability for NJE-routed SYSOUT.
The second problem involves the timing of SMF dumps. In the NJE network shown above, consider the case where SMF is dumped on SYSA. Immediately after SMF dumping is completed, a job runs on SYSA and transmits SYSOUT to SYSB via NJE. The SYSOUT immediately prints at SYSB and then SMF is dumped at SYSB.
In this scenario,
MICS
will encounter the SMF type 6 output writer record(s) and SMF type 26 non-execution node purge record before it encounters the execution records for the creating job. Because SMF was dumped at SYSA before the job execution that created the SYSOUT,
MICS
will not encounter the job's execution until the next daily update cycle. The SMF type 6 records from SYSB will not have the job information available to set ACCTNOx account codes in your account code exit routine.
The solution to this problem is to specify a NOSUSPENDNJE option statement. The SUSPENDNJE/NOSUSPENDNJE statement is fully discussed in the SUSPENDNJE/NOSUSPENDNJE Statements section. When
MICS
encounters NJE SYSOUT records for the first time and the NOSUSPENDNJE option is in effect, the NJE SYSOUT SMF records are immediately suspended for one update cycle without writing any BATSPL observations. This allows an additional daily update cycle for the execution records from the creating job to be dumped and processed by
MICS
.
NJE SYSOUT
where
MICS
only processes the SYSOUT
records
Accountability is limited for NJE SYSOUT originating from an MVS node that is not included in the SMF input files because the
MICS
unit processing the NJE SYSOUT records will never encounter the execution records from the creating job. The accounting options for this configuration are discussed in the next section.

NJE SYSOUT from Non-MVS Sources (VM)

This section discusses how to provide accountability for NJE-routed SYSOUT where the SYSOUT originates from:
  • A non-MVS source, such as VM
    NJE Network: SYSOUT Originating from a Non-MVS Node
VM MVS NODE A NODE B +-------------+ +----------------------+ | RSCS SPOOL | | JES SPOOL | | +------+ | | +------+ +------+ | | | SYS1 | |<-- NJE -->| | SYSB | | SYSC | | | +------+ | | +---|--+ +---|--+ | +-------------+ +------|---------|-----+ | | +-------+ | SMF | |
MICS
| <-------+----+----+ | UNIT | +-------+
  • An MVS node whose SMF data is not input into the same
    MICS
    unit that processes the NJE SYSOUT SMF data.
    NJE Network: SYSOUT Originating from Two Different MVS Nodes Going to Two Different
    MICS
    Units
MVS MVS NODE A NODE B +-------------+ +----------------------+ | JES SPOOL | | JES SPOOL | | +------+ | | +------+ +------+ | | | SYSA | |<-- NJE -->| | SYSB | | SYSC | | | +---|--+ | | +---|--+ +---|--+ | +-------|-----+ +------|---------|-----+ | | | | SMF +-------+ | SMF | +-------+ +---->|
MICS
| +----+----+-->|
MICS
| | UNIT | | UNIT | | A | | B | +-------+ +-------+
NJE SYSOUT records in both of these configurations have the same accountability problems. In the VM to MVS example, the only SMF records produced are the SMF type 6 and 26 records written when the VM-originating SYSOUT is printed. The MVS to MVS example is similar. A job running on SYSA will generate execution records processed by
MICS
UNIT A. Any SYSOUT transmitted for printing to NODE B will produce SMF type 6 and 26 records processed by
MICS
UNIT B.
Most account code exit routines rely on information found in the execution records produced for a job. In both NJE SYSOUT cases described above, the execution records will never be available to the
MICS
unit that processes the NJE SYSOUT records.
SYSOUT transmitted between NJE nodes consists of two logical parts, the SYSOUT data sets and the NJE header record. The NJE header record contains the information required by the receiving node to ensure correct processing of the SYSOUT data set. It also contains fields useful for assigning ownership to the SYSOUT. Some of these fields are written to the SMF type 26 purge record created when the NJE-routed SYSOUT data sets are printed.
Using the network account number
One field, the Network Account Number (JOBNETAC), is available if specified at the originating node. NJE SYSOUT originating from an MVS node would use a /*NETACCT JCL statement to specify the network account number. NJE SYSOUT originating from VM would require that RSCS populate the network account number prior to NJE transmission.
The network account number is found in the SMF type 26 record. It is important, therefore, to avoid writing BATSPL observations from NJE-routed SYSOUT until the purge record is written. The purge record is only written when all SYSOUT data sets for a given job are printed or purged. When NJE- routed SYSOUT consists of two or more SYSOUT data sets,
MICS
will encounter a "lone" writer record when some, but not all, of the SYSOUT data sets are printed prior to SMF dumping. "Lone" writer records are discussed in the "Lone" Writer Records section. Use the SPLLIMIT option statement to delay writing BATSPL observations from "lone" SYSOUT. The SPLLIMIT option statement is fully discussed in the SPLLIMIT Statement section.
The sample global account code exit routine (ACCTRTE) in the ACCTRTE - Global Account Code Exit Routine section shows an example of using the JOBNETAC data element for NJE SYSOUT account code setting. In general, any field in the SMF type 26 purge record may be used for assigning accountability for NJE-routed SYSOUT.