To use the extended status SSI, a caller must first choose the type of data to request. Job level data with or without SYSOUT level data can be requested. If only job level data is requested, one output element is created for each job. When SYSOUT data is requested, one output element is created for each job with output and one element for each piece of SYSOUT. For example, a job with four pieces of SYSOUT that matched all selection criteria would return one job level data element and four SYSOUT level data elements.

Next, the caller must decide what filters to use to select which data elements are returned. A filter is an attribute that a job or SYSOUT must possess to be returned by the interface. Filters are either at the job or SYSOUT level. Use of filters is not dependent on the type of data being requested. If only job level data is being requested and a SYSOUT filter is specified, then only jobs that have SYSOUT which passes the SYSOUT filter will be returned. Only one job level data element per matching job is returned.

A typical filter has some value associated with it, such as JOBNAME with value of TOMW. However, some filters do not have values associated with them, such as jobs that are held. If no filters are applied, the extended status function call returns information on all jobs or all SYSOUT. Because the number of jobs and SYSOUT in the system can be great, it is recommended that if information on all jobs or SYSOUT is not required, a filter be specified to limit the returned data.

This is preferable to requesting information on all jobs and then selecting for processing only those data elements for jobs owned by PAULAK or ZOOT.

When information is obtained through multiple calls, it is the caller's responsibility to eliminate duplicate data. The extended status SSI makes no checks on subsequent calls to ensure information for the same job is not returned multiple times. In a JES2 environment, if the SSI is broadcast to all subsystems, JES2 suppresses replies from secondary JES2s in the same MAS as a subsystem that has already replied.

For JES2 subsystems, information returned through this SSI is obtained from a local copy of JES2's work queues. As such, it might not reflect the current state of a job or SYSOUT element. The information can be as much as a few seconds old. If your application must have the most current job status, then use some other interface (such as operator commands) to obtain the information.

For JES3 subsystems, information returned through this SSI is obtained from work queues on the JES3 global. As such, the information reflects the current status of the job or SYSOUT at the time of the request.

The order of information returned is dependent on the filters requested and the subsystem responding. The only ordering that can be assumed is that as subsystems add data to the output area, that information is added to the beginning of the output area. For example, in a series of two calls, the results from the second call will appear on the chain of output areas before the results of the first call. Similarly, if the call is broadcast to all subsystems, the output of the primary subsystem appears after the output of any secondary subsystems.

The status request does not provide a way to freeze the job and data set status in the system. Other SAPI applications, JES writers, networking writers, and operators may change the state of any job or data set received in the status response. In general, the bigger the time lag between the status request and the use of the information, the bigger the chance that either some other function may have processed the data set or that a new output may have arrived.

The response to an extended status request will include data elements for jobs and sysout which match the original request, chained from the STATJOBF or STATJOBF_64 field in IAZSSST (STAT).