Filter
Top Products
For information about writing an XPCERES global user exit program, see The
XPCERES global user exit.
If a required resource is unavailable on the target region, but the XPCERES exit is
unavailable or disabled (or is enabled but does not set the UERCRESU return
code), the client program receives an error response.
Invoking the dynamic routing program at end of routed requests
If you want your dynamic routing program to be invoked again when the routed
request has completed, you must set the DYROPTER field in the communications
area to 'Y' before returning control to CICS. You might want to do this, for example,
if you are keeping a count of the number of link requests currently executing on a
particular CICS region.
If you have set DYROPTER to 'Y', and the linked program abends, the dynamic
routing program is invoked to notify it of the abend.
Modifying the application’s input communications area
Sometimes you may want to modify the routed application’s communications area.
For example, if your routing program changes the name of the remote program, it
may also need to change the input communications area passed to the program.
Field DYRACMAA of the routing program’s communications area enables you to do
this; it is a pointer to the application’s communications area (or null, if no
communications area was specified on the LINK command).
See also “Modifying the application’s containers” on page 607.
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.
See also “Modifying the application’s containers” on page 607.
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 API
restrictions for distributed program link, in 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 "Daisy-chaining" of DPL requests, in the
CICS Intercommunication Guide.
602 Customization Guide