this; it is a pointer to the application’s communications area (or null, if no
communications area was specified on the LINK command).
Monitoring the application’s output communications area
A routed application can pass information back to the dynamic transaction routing
program in its output communications area. If your dynamic routing program
chooses to be reinvoked at the end of a routed DPL request, it can examine the
output communications area (if any) pointed to by DYRACMAA.
Some processing considerations
v When invoked for program-link requests, the dynamic routing program should
restrict its use of EXEC CICS commands to those in the DPL subset. For
information about which commands constitute the DPL subset, see the
CICS
Application Programming Reference
manual.
v Although the routing program can issue any EXEC CICS command in the DPL
subset, you should consider carefully the effect of commands that alter protected
resources, because changes to those resources may be committed or backed
out inadvertently as a result of logic in the routed program.
v If you want to keep information about how link requests are routed, it must be
done in the user routing program, perhaps by writing the information to a
temporary storage queue.
v It is important to avoid creating “tangled daisychains”: for any program-link
request that is being dynamically routed, you should avoid routing back to a node
that has previously been routed from. For definitive information about the
“daisy-chaining” of DPL requests, see the
CICS Intercommunication Guide
.
v The dynamic routing program can be RMODE ANY but must be AMODE 31.
Unit of work considerations
The client program, the dynamic routing program, and possibly the server program
constitute a single unit of work. Any recoverable resources owned by the dynamic
routing program could therefore be affected by the syncpoint activity of the client
program. This means that these resources may be committed or backed out
inadvertently by the client program. If you want to avoid this, you have to define the
routing program’s resources as non-recoverable.
For information about the syncpoint activity of DPL client and server programs, see
the
CICS Intercommunication Guide
.
Parameters passed to the dynamic routing program
Figure 45 on page 563 shows all the parameters passed from DFHAPRT, the CICS
relay program, to the dynamic routing program by means of a communications
area. The communications area is mapped by the copy book DFHDYPDS, which is
in the appropriate CICS library for all the supported programming languages.
dynamic routing of DPL requests
562
CICS TS for OS/390: CICS Customization Guide
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|