v Select a target region by supplying a netname (any value set in the
DYRNETNM field of the communications area is ignored). The target must be
specified by its CICS system identifier (sysid).
v Change the remote transaction name passed to the target region. (Any value
set in the DYRTRAN field of the communications area is ignored.)
v Change the initial program associated with a routed request. (Any value set
in the DYRLPROG field of the communications area is ignored).
v Choose that the request is not to be queued if there are no MRO sessions to
the target region. (The DYRQUEUE field of the communications area is
always set to 'Y'.)
v Modify the routed application’s communications area. (The routing program is
not passed the address of the routed application’s communications area in
field DYRACMAA.)
v Pass the dispatch priority of the transaction to the target region. (The
DYRRTPRI field of the communications area is always set to 'N'.)
These restrictions are documented more fully in the descriptions of the relevant
fields in the DFHDYPDS communications area.
Distributed routing of BTS activities
This section describes how to use a distributed routing program to dynamically
route CICS business transaction services (BTS) processes and activities. It
assumes that you have read the introduction to the distributed routing of BTS
processes and activities in the
CICS Business Transaction Services
manual.
Which BTS activities can be dynamically routed?
Not all activations of BTS processes and activities can be routed.
Processes and activities that are activated asynchronously with the requestor—by
means of a RUN ASYNCHRONOUS command—can be routed either dynamically
or statically.
Processes and activities that are activated synchronously with the requestor—by
means of a RUN SYNCHRONOUS or LINK command—are always run locally. They
cannot be routed,
neither dynamically nor statically
. A RUN SYNCHRONOUS or
LINK command issued against an activity whose associated transaction is defined
as DYNAMIC(YES), or as residing on a remote region, results in the activity being
run locally.
Thus, to be eligible for dynamic routing:
1. A BTS process or activity must be run asynchronously with the requestor, by
means of a RUN ASYNCHRONOUS command.
2. The TRANSACTION definition for the transaction associated with the process or
activity must specify DYNAMIC(YES).
“Daisy-chaining” is not supported. That is, once a BTS activity has been routed to a
target region it cannot be re-routed from the target to a third region, even though its
associated transaction is defined as DYNAMIC(YES).
differences from the dynamic routing interface
Chapter 17. Writing a distributed routing program 577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|