This column originally appeared on TechTarget's Expert Answer Center as a post in Robert Crawford's blog. Robert served as the on-demand expert on the Expert Answer Center for two weeks in January to February 2006, during which he was available to quickly >answer questions on CICS application performance and design, as well as to write daily blog entries. Keep an eye on the Expert Answer Center for topics that could help your IT shop.
The CICS Transaction Gateway (CTG) provides a simple interface to get messages from a Java client to a CICS program. Between the client and server program is the CTG server. The CTG server can run as a standalone started task or under WebSphere. Either way, the CTG server receives and sends TCP/IP messages from the client while using CICS' External Control Interface (EXCI) to communicate with CICS. EXCI has a published interface with an API documented in its own manual on the CICS shelf. Also documented in the manual is user-replaceable module (URM) DFHXCURM.
EXCI calls DFHXCURM every time it needs to open a new "pipe" to a CICS (allocate_pipe command) or during a retryable error. DFHXCURM's parameter list contains, among other things, information about why it was called, the address of the target CICS name (if specified), the user ID making the request and the target program name. When returning from an allocate pipe call DFHXCURM may override the target CICS name. EXCI drives DFHXCURM for retryable errors so the URM can keep track of a region's status.
An important point to remember is that DFHXCURM can control message routing during allocate pipe commands only. Once a pipe is established, DFHXCURM won't be invoked again unless EXCI encounters a retryable error communicating with that CICS.
Also note that before last year an address space could have a maximum of 100 pipes. A PTF (whose number I don't have at hand) increased the limit to 250. If you're hitting the EXCI pipe limit you must increase the number of CTGs. Fortunately, with port sharing you can have several CTGs listening to the same port and your clients won't have to change.
Since CTG calls DFHXCURM by way of EXCI, you may use it to direct where new pipes go. This doesn't work so well in a development system where one CTG may have to talk to several different regions, depending on where the application programmers want to test. In this case, DFHXCURM may only want to keep track of where the pipes are going and write a warning to the console when approaching the EXCI pipe limit.
DFHXCURM makes a better routing tool in production. In production the clients shouldn't specify a target CICS. Instead, you can use DFHXCURM to route the incoming message to an application owning region (AOR) or, my favorite, a listening region (LR). Again, it's important to realize that DFHXCURM won't be called after EXCI establishes the pipe. In production DFHXCURM can send a warning message when it approaches the EXCI pipe limit that may trigger automation by bringing up a new CTG.
It's nice to be able to use DFHXCURM to control pipe allocation, but its abilities are limited. As a future enhancement I'd suggest IBM provide another EXCI exit or URM that would be called for every message going over a pipe. Thus this program could work just like the CICS routing URM's used for remote programs and transactions.