Filter
Top Products
Figure 22 on page 456 gives an overview of the structure of the sample terminal
error program.
Entry and initialization
On entry, the sample TEP uses DFHEIENT to establish base registers and
addressability to EXEC Interface components. It obtains addressability to the
communication area passed by DFHTACP by means of an EXEC CICS ADDRESS
COMMAREA, and addressability to the EXEC interface block with an EXEC CICS
ADDRESS EIB command. It gets the address of the TACLE from the
communication area, and establishes access to the TEP tables with an EXEC CICS
LOAD. If time support has been generated, the error is time-stamped for
subsequent processing. (Current time of day is passed in the communication area.)
The first entry into the sample TEP after the system is initialized causes the TEP
tables to be initialized.
Terminal ID and error code lookup
After the general entry processing, the TEP error table is scanned for a terminal
error block (TEB) entry for the terminal associated with the error. If no matching
entry is found, a new TEB is created. If all TEBs are currently in use (if no reusable
TEBs are available), the processing is terminated and a RETURN request is issued,
giving control back to DFHTACP, where default actions are taken.
After the terminal’s TEB has been located or created, a similar scan is made of the
error status elements (ESEs) in the TEB to determine whether the type of error
currently being processed has occurred before, or if it has permanently reserved
ESE space. If an associated ESE is not found, an ESE is assigned for the error
type from a reusable ESE. If a reusable ESE does not exist, the error is accounted
for in the terminal’s common error bucket. The addresses of the appropriate control
areas (TEB and ESE) are placed in registers for use by the appropriate error
processor.
Error processor selection
User-specified message options are selected and the messages are written to a
specified transient data destination. The type of error code is used as an index to a
table to determine the address of an error processor to handle this type of error. If
the error code is invalid, or the sample TEP was not generated to process this type
of error, the address points to a routine that optionally generates an error message
and returns control to DFHTACP, where default actions are taken. If an address of a
valid error processor is obtained from the table, control is passed to that routine.
Error processing execution
The function of each error processor is to determine whether the default actions
established by DFHTACP for a given error, or the actions established by the error
processor, are to be performed. The common error bucket is processed by the
specific error processor. However, the thresholds of the common error bucket are
used in determining whether the limit has been reached. Subroutines are provided
in the sample TEP to maintain count and time threshold totals for each error
associated with a particular terminal to assist the error processor to make its
decision. Also available are subroutines for logging the status of the error and any
recovery action taken by the error processor.
You can replace any of the error processors supplied in the sample TEP with
user-written ones. Register linkage conventions, error conditions, DFHTACP default
actions, and sample TEP error processor actions are described in comments given
in the sample DFHXTEP source listing. However, sample DFHXTEP actions, in
many cases, can be altered by changing the thresholds when generating the TEP
tables.
454 Customization Guide