IMS Connect directs messages between
its distributed clients and IMS resources. It does this by
passing request messages to the IMS data store specified in the
IRM header and receiving response messages that are returned to the originating TCP/IP client. OTMA
workload routing in IMS Connect Extensions is the process where OTMA
routing rules are defined that dynamically alter the incoming target IMS data store specified in an IRM message to route it to one or more IMS data stores selected from a list of candidates. If desired, you can also
specify additional qualifying rules that route certain transaction codes to a different list of
target IMS data stores.
OTMA rules-based routing works in the following ways:
- The data store ID in the IRM message (IRM_IMSDestId) is used to find a matching OTMA routing
rule
- Rules are matched in IMS Connect Extensions based on the value
supplied in the IRM_IMSDestId field of the incoming message. Because the field simply contains a
string, the data store ID does not have to be a physical data store defined to the IMS Connect system. Instead, it can be a generic value that might represent
some workload grouping such as an application, business group, or cost center. IMS Connect Extensions locates the OTMA routing rule whose key field (Original
Datastore) matches that generic string (IRM_IMSDestId) specified in the message. IMS Connect Extensions processes the routing rule and replaces the generic
original destination ID with a real IMS data store name
selected from the list of data stores referenced by the OTMA routing rule.
- OTMA routing lists are used to define the list of candidate IMS data stores
- For each type of IRM received by IMS Connect, you can
specify a target OTMA routing list and an optional fallback OTMA routing list. Messages are routed
to IMS data stores in the target OTMA routing list first. The
fallback list contains data stores that can be used if the data stores in the target list are
unavailable.
You can specify different OTMA routing lists for each message type. For example, you
could configure one list of candidates for transactional (send-receive) messages and another list of
candidates for asynchronous messages.
- OTMA routing rules can be fine-tuned by adding conditions for particular transactions
- To do this, you have a
master
OTMA routing rule for each destination ID, and specify
additional qualifying rules that route certain transaction codes to a different list of target data
stores. If you specify a qualifying rule
without a matching master rule in the repository, an implied routing rule will be generated
internally at run time.
- IMS Connect Extensions checks for the name of the active OTMA routing
plan
- Only one OTMA routing plan can be active on a system at a time. Routing rules that are assigned
to other routing plans are not considered.
A routing rule that is not assigned to a routing
plan will always be in effect, except when it is overridden by a routing rule that contains a more
specific message matching condition.
- Define sets of rules for all systems, or develop customized rules for each
- IMS Connect Extensions allows for a lot of flexibility in how you
implement routing rules. The simplest configuration is to implement the same set of rules across all
your systems. Alternatively you can implement a different set of rules for each group of systems or
even for a single system. Finally, you can combine these methods. For example, you can create an
All systems
rule but then override the routing behavior for a particular message type on a
given system.You can also have one master rule for a given DestID, as well as
optional rules that specify different target IMS data stores
for a specified list of transaction codes.
Specific rules take precedence over more general
rules. That is:
- A qualifying rule will override an explicit or implicit
master
rule.
- A rule that is specific to an IMS Connect system will
override a rule with the same condition and message type that is specified for a group or for all
systems.
- A rule specified for a group will override a rule that applies to all systems.
- Use CEXCTLIN control options to set the default routing behavior for an IMS Connect
- The control input data set allows you to set several behaviors for OTMA routing. The input data
set is specified through an optional CEXCTLIN DD statement in the IMS Connect startup job. These options take effect when IMS Connect Extensions restarts. Use these options to control the behavior of
IMS Connect Extensions when an IMS
data store is experiencing a flood condition, when there are no valid IMS data store destinations, and when IMS Connect Extensions receives a message that does not match any of its current
routing rules.