Filter
Top Products
The difference is that Set results and Get results are replaced by Clean up. It is
vital that only these two sequences can happen; this means that both programs
must be coded correctly. CICS ensures that both tasks are told either that
SUSPEND and RESUME processing worked, or that it failed.
The following shows the programming steps that conform to these rules:
If both the SUSPEND and RESUME return ‘OK’, the example follows the rules for
the normal synchronization; processing finishes at Get results. If neither SUSPEND
nor RESUME returns ‘OK’, the example follows the rules for the task-purge
protocol, and processing finishes at Clean up.
For further information about SUSPEND and RESUME processing, see the
CICS
Problem Determination Guide
.
Alternative approach to task purge
The sequence described above is one method for dealing with the problem of
task purge. Using this method, task B does not know, when it is processing
the request, whether or not task A has been purged; this means that B must
take great care in its use of resources owned by A (in case A has been
purged). In some situations, this restriction may cause difficulties.
A different approach is as follows; if task A is to be purged:
1. A communicates to B that it is no longer available, thus informing B not to
use any resources owned by A.
2. A performs its own clean-up processing (including issuing the RESUME
call for the purged SUSPEND, as required by the dispatcher protocols),
and abends.
3. B performs its own clean-up processing.
The ADD_SUSPEND call
ADD_SUSPEND acquires a suspend token that can later be used to identify a
SUSPEND/RESUME pair.
Set parameters; Get parameters; Process request; Clean up
Program for Task A Program for Task B
SET PARAMETERS;
GET PARAMETERS;
RESUME B; PROCESS REQUEST;
SUSPEND A; RESUME A;
if if
RESPONSE = OK RESPONSE ¬= OK
then then
GET RESULTS; CLEAN UP
endif endif
dispatcher functions
302
CICS TS for OS/390: CICS Customization Guide