Developing CA Gen WebSphere MQ Applications › z/OS WebSphere Support for Distributed Processing Servers › z/OS CICS: The TDC

z/OS CICS: The TDC

The Transaction Dispatcher for CICS (TDC) is a CICS application provided by CA Gen, and is the second method of invoking a CICS DPS application. The TDC also makes use of the trigger monitor from IBM, but the TDC is designated as the processing application associated with the local queue.

The TDC acts as a surrogate for inbound messages. When triggered, it reads the WebSphere MQ queue and spawns the appropriate CA Gen server manager, based on the content of the inbound message. The TDC passes the message to the server manager either in CICS temporary storage or as a record in a VSAM file. When the server manager begins processing, the runtime detects initiation through the TDC and reads the message without directly accessing the MQS. The server manager posts the reply message through the runtime. For an illustration, see DPC-to-DPS Flow Using TDC in the appendix “Flow Diagrams.”

The TDC allows multiple CICS CA Gen server managers to share the same WebSphere MQ application queue. Additionally, the TDC ensures that a single trigger event causes complete processing of the associated application queue, thus emptying the queue. If you only use a trigger monitor without the TDC (see DPC-to-DPS Flow Using a z/OS CICS Trigger Monitor) it is possible that the trigger rules will not always create a trigger event, which could leave request messages in the queue awaiting processing.

If the TDC detects that the WebSphere MQ queue depth rose above a set level, the TDC spawns additional copies of itself, processing the current WebSphere MQ queue in parallel. These copies are considered child processes of the TDC, inheriting their parameters from the original process. These child processes can not spawn additional instances of themselves. The TIRMQTDX user exit allows you to set the queue depth and number of allowed child processes.

Another option available with the TDC is transaction level security. Without the TDC, the security context of the target DPS application is derived from the user context associated with the trigger monitor. With the TDC, there are alternate implementations for obtaining the user ID, through the user exit TIRMQTDX. Among its tasks, TIRMQTDX controls which security context should be in effect when starting the target DPS application. The exit directs the TDC to start the DPS application in one of the following three ways:

• Use the user ID associated with the started TDC (this is the default behavior, and is the same as in a non-TDC implementation).
• Use the user ID context extracted from the inbound request message. The TDC obtains the inbound request message from the designated application queue prior to invoking the target DPS application. The exposure to the request message allows the TDC to extract the user ID from the message and use it when starting the DPS application.
• Use a user ID value that is provided through the TIRMQTDX user exit.

For more information about the TDC, see the appendix “Flow Diagrams.”