Filter
Top Products
Batch processing
When running a batch logical unit, a point to consider is how to get the transaction
identification to CICS on the “begin data set” condition. The alternative methods are
discussed below.
The first method is for the DMH to recognize the “begin data set” condition by
interrogating the FMH and by editing the transaction ID into the input data. This
method is demonstrated in the sample message control programs DFHSPTM1 and
DFHSPTM2.
The second method of providing the transaction ID is for the DMH to concatenate
the “begin data set” chain with the first chain of the data set, using the SETEOM
macro. When you use this method, the first chain of the data set must contain the
transaction ID. Alternatively, the transaction ID could be set with the TCTTE
beforehand by means of a permanent TRANSID or by using EXEC CICS RETURN
TRANSID.
Error processing for batch logical units
During batch processing with a logical unit, there are some logical errors from which
the DMH cannot recover (for example, ‘data set overflow’ or ‘incorrect data set
name’). A transaction can be provided to handle these error conditions. If the
transaction builds the data set on the TCAM queue and ends before the data set is
transmitted, an error transaction should be created. The DMH should generate the
appropriate error message or pass the SNA sense bytes to this error transaction,
which then handles the error condition. If the transaction that builds the data set
remains active throughout the transmission of that data set to the device, then the
same transaction could be coded to recognize the error indicators passed to it from
the DMH, rather than a separate error transaction created for that purpose.
Error processing
All error conditions, other than logical errors, are handled by the DMH. The
ACF/TCAM System Programmer’s Guide
contains a discussion on the handling of
the various sense codes returned by SNA devices. The transaction is not involved
in error processing and recovery.
The TCAM application program interface
The TCAM application program interface is a portion of the TCAM message control
program (MCP). It consists of two types of control blocks, the process control block
(PCB) and the TPROCESS block.
The PCB defines the application program interface of a region in the system using
TCAM. Its purpose is to control communication and storage protection across
region boundaries. It also defines the user-written message handler (MH)
responsible for processing messages to and from the application program. Because
a PCB is required for each application program running with the MCP, one PCB is
also required to define the CICS application program.
The TPROCESS control block controls communication to and from the application
program. A separate block is required for both input and output to the application
program. A TPROCESS block is required for each input queue to CICS, and for
CICS with TCAM SNA
694
CICS TS for OS/390: CICS Customization Guide