Session 1078

CICS Attachment Facilities for

WebSphere MQ and DB2

John Tilling
CICS Technical Planning & Strategy
IBM UK Labs Hursley Park
Tilling@uk.ibm.com

Friday 29th February 2008

Abstract & Agenda

CICS, MQ and DB2 have always benefited from good integration. The CICS-MQ
adapter, the CICS-MQ Trigger Monitor and the CICS-MQ Bridge are now
included in CICS Transaction Server V3.2 following the approach for inclusion of
the CICS/DB2 adapter in CICS Transaction Server V1. This session will look at
the changed capabilities to the CICS-MQ functions now that they are included in
CICS, give an insight into further updates and requirement areas and provide an
summary and comparison to the CICS-DB2 2 adapter.
Agenda
• The CICS-MQ Adapter
• The CICS-MQ Trigger Monitor
• The CICS-MQ Bridge
• Integration changes in CICS Transaction Server V3.2
• CICS-DB2 Attach summary
• CICS-MQ wishlist
Session 1078 © 2008 IBM Corporation 2
CICS-MQ Interfaces

• CICS Transaction Server V3.2 now supplies the following:

• CICS-MQ Adapter
• MQ trigger monitor for CICS
• MQ bridge (includes the DPL bridge and link 3270 bridge)

• In CICS TS V3.2 CICS-MQ Adapter is enhanced to use OTE

• The CICS-MQ TRUE is enabled as OPENAPI 3
• MQ API commands from CICS applications are threadsafe
• Reduced TCB switching for threadsafe applications – same as for DB2
• CICS Level2 and Level 3 will service CICS shipped components

• Websphere MQ will continue to ship the above components for use with CICS TS
3.1 and below
• Until such time that all releases of CICS TS prior to CICS TS 3.2 are out of service
• Limited enhancements over time. No OTE support.
• Will functionally stabilize
• MQ Level2 and Level3 will continue to service MQ shipped components

Session 1078 © 2008 IBM Corporation 3

Components transferred from WebSphere® MQ: The components to connect CICS and WebSphere
MQ for z/OS have been enhanced and are now integrated with CICS TS V3.2.

The components transferred include the CICS-MQ adapter, the CICS-MQ trigger monitor, and the CICS-
MQ bridge. The enhancements include:
• Exploitation of the CICS Open Transaction Environment (OTE). The components have been made
threadsafe, and are enabled to use CICS open TCBs. Exploitation of OTE will benefit threadsafe
applications using WebSphere MQ. For multiple WebSphere MQ requests, TCB switching can be avoided,
resulting in a saving of CPU and an increase in overall throughput, because applications can now run on
multiple open TCBs and avoid bottlenecking.
• Improved diagnostics, including use of CICS facilities for system trace, dump formatting, and messages
• Improved statistical information, including the use of connections between CICS and WebSphere MQ,
and the type and success of calls made. This information has also been made available within the
CICSPlex SM Web User Interface.

Note that the CICS-MQ adapter and CICS-MQ trigger monitor shipped in CICS TS must be used in place
of the components shipped in WebSphere MQ, and they can be used with all supported levels of
WebSphere MQ for z/OS. The CICS-MQ bridge shipped in CICS TS is for use with WebSphere MQ for
z/OS V6.0, or later. When using WebSphere MQ for z/OS V5.3.1, CICS continues to require the CICS-MQ
bridge shipped in WebSphere MQ for z/OS V5.3.1, and the WebSphere MQ PTF for APAR PK39200 must
be applied. (The CICS shipped bridge code will detect that WebSphere MQ for z/OS V5.3.1 is being used
and will transfer control to the WMQ shipped bridge). See also the statement Components transferred from
WebSphere MQ in the Compatibility section.
 What is the CICS-MQ Adapter ?
WebSphere MQ
CICS Transaction Server V3.2 Queue manager

Application
API Stub CKTI
Task-initiator
4
Sync Point
Task Related
Message Manager
User Exit
Task
Management
CKQC
Termination Connection Manager
Control Transaction

Session 1078 © 2008 IBM Corporation 4

WebSphere MQ software and CICS Transaction Server run at separate address spaces within IBM
OS/390® or IBM z/OS systems, and they communicate using components provided by both products.
CICS Transaction Server has a task related user exit (TRUE) interface that allows it to forward executed
information to another subsystem.The CICS-MQ Adapter is a set of components that you can run within a
CICS region — to allow it to create a connection through a TRUE interface to a queue manager. It also
allows application programs running within CICS Transaction Server to use the connection to send and
receive messages.

A CICS region can use a single adapter to connect to one queue manager. And several CICS regions can
share a workload through a common queue manager. The adapter provides CICS Transaction Server with
a control transaction, or CKQC, to start, stop and customize the interface between CICS Transaction
Server and the queue manager. You can run this transaction from a program list table (PLT) program
during the initialization of the CICS region or from a 3270 terminal once the region has started.

A task-initiator transaction, or CKTI, can monitor a specific message queue across the connection to the
queue manager. Several CKTI commands can monitor a set of queues, although no more than one
instance can be used with a particular queue from within a single CICS region. Each instance of CKTI is
defined, started and stopped using the CKQC adapter-controller transaction. When one or more messages
arrive in a message queue to meet a particular trigger condition, the CKTI transaction detects this event.
You can configure the CKTI to start a separate named CICS transaction to process the message(s) on this
queue. Having started a new instance of this named transaction, CKTI then continues to monitor the queue
for other trigger events. The named transaction started by CKTI is, in effect, the same as the one described
in the first scenario. The transaction contains the stub, which allows it to access the CICS adapter through
the TRUE interface and typically contains commands to retrieve one or more messages from the queue. It
may also contain instructions to put messages onto other queues or carry out any of the functions
supported by standard CICS APIs.
 CICS-MQ Adapter Considerations
The CICS adapter connects a CICS subsystem to an WMQ queue manager
•Enables CICS application programs to use the MQI
•Provides for control and management of the adapter & queue manager connection
Managing Connectivity
• CICS can be enabled to connect to MQ automatically
• A CICS system connects to only5 one queue manager at a time
• CICS and WebSphere MQ are independent
• Independently started and stopped
• Connections can be establish or terminated at any time
In addition to providing access to the MQI calls, the adapter provides:
• A trigger monitor (or task initiator) program that can start programs
automatically when certain trigger conditions on a queue are met. The
trigger monitor shipped will work with all supported releases of Websphere
MQ
• An API-crossing exit that can be invoked before and after each MQI call.

Session 1078 © 2008 IBM Corporation 5

In a CICSPlex environment each CICS address space has its own attachment to the queue manager
subsystem.
 CICS-MQ Adapter - MQI SUPPORT
For MQI support, CSQCSTUB the API stub program is linkedited with the
application
Application Transaction Integrity :
• Syncpointing under control of CICS recovery manager is supported.
Application Security : 6
• WebSphere MQ resource level checking via an ESM such as RACF.

Application Availability, Reliability and Recovery

• automatic reconnection after a queue manager termination
• automatic resource resynchronization after a restart.
• alert monitor for response to unscheduled events

Session 1078 © 2008 IBM Corporation 6

When CICS is connected to WebSphere MQ and the queue manager terminates, the CICS
adapter tries to issue a connect request ten seconds after the stoppage has been detected.
This request uses the same connect parameters that were used in the previous connect
request. If the queue manager has not been restarted within the ten seconds, the connect
request is deferred until the queue manager is restarted later.

An example of an unscheduled event is the shut down of the queue manager.

 CICS–MQ Adapter – Control Functions

The CKQC transaction provides control for the CICS adapter connections
• Panel or command line interface
Control Capabilities to:
• Start or stop a connection to a queue manager.
• Display the current status of a connection and the statistics associated
with that connection.
• Modify the current connection. 7
• reset the connection statistics
• enable or disable the API-crossing exit.
• Start or stop an instance of the Trigger monitor CKTI.
• Display details of the current instances of CKTI.
• Display details of the CICS tasks currently using the adapter.

Session 1078 © 2008 IBM Corporation 7

(Note: Statistics are now subject to reset via standard CICS stats mechanisms as well)
CICS-MQ Adapter – CKAM Alert Monitor (DFHMQMON)

The alert monitor transaction, CKAM, handles unscheduled events known as pending
events that occur as a result of connect requests to instances of WebSphere MQ.

It uses the same SSSC establish_exit interface as the CICS-DB2 attach

There are two kinds of pending events:

• 8 connect to WebSphere MQ before the queue

1. Deferred connection If CICS tries to
manager is started, a pending event called a deferred connection is activated. When the
queue manager is started, a connection request is issued by the CICS adapter.

• 2. Termination notification When a connection is successfully made to WebSphere

MQ, a pending event called termination notification is created. This pending event
expires when:

• The queue manager issues a quiesce request on the connection.

• The queue manager shuts down with MODE(FORCE) or terminates abnormally.
• The connection is shut down from the CKQC

Session 1078 © 2008 IBM Corporation 8

 Starting the CICS-MQ Adapter

1. MQCONN SIT parameter to start the adapter automatically

The INITPARM parameter sets the default connection parameters.

INITPARM=(DFHMQPRM=’SN=CSQ1,IQ=CICS01.INITQ’)
Where:
SN The subsystem name. This must be the name of a queue manager.
IQ The name of the default initiation queue.

2. PLTPI / application program 9

• May override INITPARMS
• Links to the adapter connect program CSQCQCON with required parameters

EXEC CICS LINK PROGRAM(’CSQCQCON’) COMMAREA(CONNPL)

LENGTH(length of CONNPL)

3. The CKQC transaction

• adapter control panels enable control and monitoring of connections between WebSphere MQ and
CICS.
• Allows connections to be stopped with quiesce or force options

Session 1078 © 2008 IBM Corporation 9

If IQ init parm is blank, and you do not specify an initiation queue name by any other method, an instance
of CKTI is not started when the CICS adapter connects to the queue manager.

A typical use of PLTPI programs is for overriding the INITPARM settings if your CICS adapter initiation
queue name is too long to be supported via the INITPARM statement.

CKQC
From the initial panel, you first select an item from the menu bar at the top of the panel, and then select an
action from one of the pull-down menus. In the displayed panel or secondary window, you can then type
new values in the fields, as required.
 CICS-MQ Trigger monitor CKTI

• Task initiator CKTI is a CICS transaction that starts a CICS transaction when a
WMQ trigger message is read.
• A Trigger message may arise from a message put to
• a specific initiation queue.
• an application message queue, if the trigger conditions are met.

• The queue manager then writes a message,

10 containing user-defined data,
known as a trigger message, to the initiation queue that has been specified for
that message queue.

• CKTI can monitor a single initiation queue

• retrieves the trigger messages on arrival.
• CKTI starts another CICS transaction, (specified using the DEFINE PROCESS command),
• reads the message from the application message queue and then processes it.
• The process must be named on the application queue definition,
• There can be many CKTI instances.

Session 1078 © 2008 IBM Corporation 10

 The MQ trigger monitor for CICS

CICS Transaction Server V3.2 WebSphere MQ

Initiation Queues
Exec CICS Start Transid CKTI
CKTI
Task-initiator Trigger
Message
Task-initiator MQTM
11 Message
Network
Structure Queue
Application Exec CICS Manager Transport
API Stub Retrieve RTRANSID

Trigger
Task Related Condition
MQI User Exit

Application Queues

Session 1078 © 2008 IBM Corporation 11

You need to start one instance of CKTI for each initiation queue. CKTI passes the MQTM structure of the
trigger message to the program that it starts by EXEC CICS START TRANSID. The started program gets
this information by using the EXEC CICS RETRIEVE command. A program can use the EXEC CICS
RETRIEVE command with the RTRANSID option to determine how the program was started; if the value
returned is CKTI, the program was started by the CICS-WebSphere MQ trigger monitor.
The CICS-MQ DPL Bridge

• The Bridge monitor is constantly browsing the request queue

• All the MQI calls required are within the bridge monitor and not exposed to the
application.
• recognises a “Start UOW” message

• Message formats can vary depending on the nature of the application :

• All start with a block of data called an MQMD header.
• This field contains control information12used by the monitoring transaction like the
message format type, along with optional information, such as a reply-queue
identifier and a user ID.
• The information that follows the MQMD field can simply be the name of the application
program to run within CICS, with the option to include data that the program can receive
as its COMMAREA.

• Other control information may be in a MQCIH header

• must follow the MQMD field.
• The bridge transaction can set some of the MQCIH fields in any response message for
use by the client application when the request has been serviced

• CICS shipped bridge will work with MQ V6 and higher

• CICS shipped bridge will XCTL to MQ shipped bridge if MQ V531

Session 1078 © 2008 IBM Corporation 12

The CICS MQ DPL Bridge

• The bridge can be used by a CICS program that is invoked using the EXEC
CICS LINK command.
• It must conform to the DPL subset of the CICS API, that is, it must not use
CICS terminal or syncpoint facilities.
• Other control information may be in a MQCIH header
• unit-of-work information for a sequence of DPL requests
13

Session 1078 © 2008 IBM Corporation 13

 The CICS-MQ DPL Bridge

CICS Transaction Server V3.2 WebSphere MQ

Bridge MQGETbrowse request

Monitor
Request Queue
Exec CICS
Start Transaction
Business Link 14 MQGET request
DPL Bridge
Logic
Transaction MQPUT request Transmission Queue
Program Return

Network
Queue
Manager Transport

Session 1078 © 2008 IBM Corporation 14

The following takes each step in turn, and explains what takes place:
1. A message, with a request to run a CICS program, is put on the request queue.
2. The bridge monitor task, which is constantly browsing the queue, recognizes that a ‘start unit of work’ message is waiting
(CorrelId=MQCI_NEW_SESSION).
3. Relevant authentication checks are made, and a CICS DPL bridge task is started with the appropriate authority, with a particular
userid (depending on the options used to start the bridge monitor).
4. The CICS DPL bridge task removes the message from the request queue.
5. The CICS DPL bridge task builds a COMMAREA from the data in the message and issues an EXEC CICS LINK for the program
requested in the message.
6. The program returns the response in the COMMAREA used by the request.
7. The CICS DPL bridge task reads the COMMAREA, creates a message, and puts it on the reply-to queue specified in the request
message. All response messages (normal and error, requests and replies) are put to the reply-to queue with default context.
8. The user transaction ends or requests more input. If this is the last flow in the pseudo conversation the transaction ends. If it is
not the last message, the transaction waits until the next message is received or the specified timeout interval expires. A unit of work
can be just a single user program, or it can be multiple user programs.

There is no limit to the number of messages you can send to make up a unit of work. In this scenario, a unit of work made up of
many messages works in the same way, with the exception that the bridge task waits for the next request message in the final step
unless it is the last message in the unit of work.
You must start a bridge-monitoring transaction (CKBR) to look for messages arriving on a particular queue. Several monitoring
transactions can run concurrently to manage a set of queues in this way. When the message arrives, the monitoring transaction
detects it and starts a bridge DPL transaction to process the message. The monitoring transaction continues to look for other
messages arriving on the queue. You can set up the bridge DPL transaction to run requests using a system user ID or the user ID of
the requester.
The DPL bridge task reads the message from the queue. From within the message, the task finds the name of a CICS application
program, any input data it requires and, optionally, the name of a message queue to send a response to. Next, the DPL bridge
transaction sets up a COMMAREA containing the input data and links to the named program, returning any output COMMAREA to
the reply queue after the program has ended. The WebSphere MQ client application can use this mechanism either synchronously
or asynchronously. It can wait for a response by monitoring a particular queue, or it may send a message and continue processing
other transactions or even terminate without waiting for CICS Transaction Server to process the request. If the client runs on the
same system as CICS Transaction Server, it can monitor the transmission queue for a response. If it is remote to CICS Transaction
Server, the client can use WebSphere MQ to route the response message from the transmission queue to one defined to its local
queue manager.
Each DPL request executes in isolation, and no state is preserved in CICS to tie up a series of requests that a client might make.
So, if the client calls CICS Transaction Server more than once, each piece of work is treated separately because the server doesn’t
retain any information to tie them together. The WebSphere MQ monitoring transaction and DPL bridge transaction run within the
same CICS region. The program targeted by the DPL request can be made eligible for routing to another CICS region. All to help
balance the workload more effectively.
The CICS MQ 3270 Bridge

• The Bridge can be used by a CICS transaction designed to run

on a 3270 terminal.
• can use BMS or TC commands.
• Can be conversational or part of a pseudoconversation.
• Permitted to issue syncpoints.
15
• Other control information may be in a MQCIH header
• pseudo-conversational controls needed when running a 3270 application.

Session 1078 © 2008 IBM Corporation 15

 The CICS-MQ 3270 Bridge

CICS Transaction Server V3.2 WebSphere MQ

Bridge MQGETbrowse request

Monitor
Request Queue
Exec CICS
Start Transaction
16 MQGET request
Bridge
Transaction MQPUT request Transmission Queue

Receive
3270
Bridge Exit Network
Send Queue
Transaction Manager Transport

Session 1078 © 2008 IBM Corporation 16

The CICS-MQ 3270 Bridge enables you to wrap terminal oriented that were controlled by 3270-connected
terminals with WebSphere MQ messages, without having to rewrite,recompile, or re-link them.

The following takes each step in turn, and explains what takes place:
1. A message, with a request to run a CICS transaction, is put on the request queue.
2. The CICS-MQ bridge monitor task, which is constantly browsing the queue, recognizes that a ‘start unit
of work’ message is waiting (CorrelId=MQCI_NEW_SESSION).
3. Relevant authentication checks are made, and a CICS 3270 bridge task is started with the appropriate
authority, with a particular userid (depending on the options used to start the bridge monitor).
4. The CICS-MQ bridge removes the message from the queue and changes task to run a user transaction.
5. Vectors in the message provide data to answer all terminal-related input EXEC CICS requests in the
transaction.
6. Terminal-related output EXEC CICS requests result in output vectors being built.
7. The CICS-MQ bridge builds all the output vectors into a single message and puts this on the reply-to
queue.
8. The CICS 3270 bridge task ends. If this is the last flow in the transaction then the transaction ends, if it is
not the last message, the transaction waits until the next message is received or the specified timeout
interval expires.
 CICS-MQ CICS TS V3.2 Integration –
name changes
• Transferred modules are renamed from CSQCxxxx to DFHMQxxx
• Exceptions:
• API crossing exit CSQCAPX.
• Source supplied as CSQCAPX unchanged in SDFHSAMP

• API stub is DFHMQSTB but with alias CSQCSTUB and all other aliases currently
supported, eg CSQCGET, CSQCPUT…..
17
• Stub is shipped in SDFHLOAD and SDFHAUTH
• No recompile and no re-linkedit of applications is required

• CICS-MQ TRUE is renamed from CSQCTRUE to DFHMQTRU

• However TRUE has same entryname of MQM
• DFHRMCAL TO=MQM will work unchanged
• EXTRACT EXIT PROGRAM(CSQCTRUE) ENTRYNAME(MQM) commands work
• At runtime CICS substitutes DFHMQTRU as the program name

• INQUIRE EXITPROGRAM(CSQCTRUE) ENTRYNAME(MQM) commands work

• At runtime CICS substitutes DFHMQTRU as the program name

Session 1078 © 2008 IBM Corporation 17

 CICS-MQ CICS TS V3.2 Integration –
name changes

• CICS supplies adapter, trigger monitor & bridge definitions in CSD group
DFHMQ
• DFHMQ group is part of list DFHLIST
• Program names will be DFHMQxxx apart from crossing exit, stub aliases and aliases for
those programs that can be EXEC CICS LINKed to by user applications
• CKxx transaction names remain the same but refer to DFHMQxxx programs
18
• Users will need to remove existing groups CSQCAT1 and CSQCKB
containing CSQCxxxx definitions from the CSD (unless they are sharing
the CSD)
• Websphere MQ are shipping PK39200 on V531 and PK42616 on V6 to disallow use of
MQ shipped Attach with CICS TS 3.2 and above.
• Produces message CSQC330E. A Technote is already provided on the subject

• A CICS TS 3.2 CSD can be shared by lower level releases

• Users should edit group CSQCAT1 & remove TDQUEUE CKQQ
• CKQQ is now provided in group DFHDCTG
• Groups CSQCAT1 and CSQCKB can then be installed on lower level releases
• Overrides definitions in group DFHMQ

Session 1078 © 2008 IBM Corporation 18

CICS-MQ CICS TS V3.2 Integration –
name changes
• Messages are renamed. CICS Message Domain used.
• CSQCxxx become DFHMQxxx but the number will be retained
• Eg CSQC409I will become DFHMQ409I
• Terminal end user and TDQ messages are NLS enabled as for other CICS components
• Kanj and Simplified Chinese versions shipped
• CKQQ TD destination kept for connection/disconnect msgs
• New CMQM TD destination (indirect to CSSL) provided in group DFHDCTG

• Existing NLS Mapsets supported 19

• WMQ ships English, uppercase English, Kanji & Simplied Chinese versions of mapset used
by CKQC transaction. (CICS normally ships only english mapsets)
• CICS TS 3.2 ships the above four variants
• Uppercase english used when NATLANGINUSE = E and MSGCASE=UPPER

• Qxxx abend codes renamed AMQx

• Documented in CICS InfoCenter

• CICS-MQ documentation ported over from WMQ Infocenter

• New CICS Integration with WebSphere MQ plugin to Infocenter
• Information tailored to CICS TS 3.2 shipped components

Session 1078 © 2008 IBM Corporation 19

 CICS-MQ CICS TS V3.2 Integration –
Statistics and Monitoring

• MQCONN Global statistics supplied via DFH0STAT and DFHSTUP

• CICS DSECT is DFHMQGDS
• CPSM Base table is MQCONN
• CPSM WUI views provided

• CICS Monitoring - Performance Class Data

• Two new fields in DFHDATA group 20
• WMQREQCT (count) – Total number of MQ requests
• WMQGETWT (clock and count) MQ GETWAIT wait time
• Records CICS dispatcher wait identified as MqSeries GETWAIT
• NB. MqSeries TASKSWCH wait will nolonger occur as TRUE uses L8 open TCBs

• Existing group DFHRMI (activated via RMI=YES in MCT) is unaffected

• Already contains RMIMQM – The total elapsed time spent in the CICS RMI for WebSphere MQ requests
• RMIMQM is a subset of total elapsed time spent in the RMI for all TRUEs (RMITIME in DFHTASK group)

Session 1078 © 2008 IBM Corporation 20

 CICS-MQ CICS TS V3.2 Integration –
name changes

• TRACE
• EXEC CICS ENTER TRACENUM previously used
• Required master and user trace flags to be on for non exception traces

• Components changed to use CICS Trace domain

• Exception traces issued non-conditionally
• Non exception traces controlled via Level 1 and Level 2 CETR component flags
• 21 the other side of the RMI
RI (RMI) component flags for Attach modules operating
• New RA (Resource Manager Adapter) component flag for all other non RMI modules
• Support added to CETR, SET TRACETYPE & STNTRRA , SPCTRRA in the SIT
• CICS-DB2 and CICS-DBCTL changed to use RA rather than FC
• BR component flags used for the MQ bridge

• Improved trace content – eg trace content of control blocks

• DUMP
• CICS dump domain services used.
• CICS IPCS verbexit enhanced
• New MQ keyword to dump out CICS-MQ Attach control blocks
• Formatting very similar to that provided for CICS-DB2 Attach

Session 1078 © 2008 IBM Corporation 21

 CICS-MQ : Migration

• To migrate to CICS TS 3.2 and use MQ, ensure:

• CSD groups CSQCAT1 and CSQCKB are NOT installed, and that CSD group DFHMQ is
installed. Likewise for CPSM BAS ensure old definitions are not installed.

• The following WebSphere MQ libraries are AFTER CICS libraries in the CICS STEPLIB and
DFHRPL concatenations. 22
• SCSQANLx * (where x is the language letter of your national language)
• SCSQCICS *
• SCSQLOAD
• SCSQAUTH

* The SCSQANLx and SCSQCICS libraries are only required if you wish to run the WebSphere MQ supplied samples, or
you are running WebSphere MQ V531 and wish to use the WebSphere MQ Bridge. Otherwise they can be removed from
the CICS JCL.

• INITPARM system initialization table (SIT) override is changed from:

INITPARM=(CSQCPARM='SN=xxxx,TN=yyy,IQ=zzzzz')
to
INITPARM=(DFHMQPRM='SN=xxxx,IQ=zzzzz')

Session 1078 © 2008 IBM Corporation 22

CICS-MQ Migration…

• For WMQ V5.3.1 apply apars PK39200 and PK59405

• PK39200 polices use of the correct adapter. Required for MQ bridge to operate
• PK59405 fixes a data conversion problem. Requires CICS apar PK58227

• For WMQ V6 apply apars PK42616 and PK59397

• PK42616 polices use of the correct 23
adapter.
• PK59397 fixes data conversion problem. Requires CICS apar PK58227

Session 1078 © 2008 IBM Corporation 23

 CICS-DB2 enhancements in CICS TS V1

• CICS–DB2 Attach shipped with CICS and restructured

• Supports all serviced levels of DB2
• 22 requirements satisfied

• Full RDO support for RCT including CPSM BAS

• Includes transaction wildcarding,
24dynamic change
• CEMT , EXEC CICS INQUIRE & SET support

• Improvements to attachment startup and shutdown

• Improved thread handling
• Improved FFDC, improved messaging
• Enhanced Debugging aids
• Enhanced CICS-DB2 statistics

Session 1078 © 2008 IBM Corporation 24

 CICS–DB2 Enhancements in CICS TS V2

• CICS-DB2 Attach exploits OTE to reduce TCB switching

• CICS-DB2 Attach supports group attach with DB2 V7

• Support for the DB2 V7 JDBC 2.0 driver and DB2 V7 and V8 JDBC
Universal Driver. Now also DB2 9 driver
25
• CICS-DB2 Attach with DB2 V6 upwards exploits an RMI
enhancement to allow purge across the RMI

• SPI enhancement - INQUIRE DB2TRAN reports plan or

planexitname

• CICS TS 2.3 support for enhanced restart-light function in DB2 V8

and above

Session 1078 © 2008 IBM Corporation 25

 OTE exploitation across the adapters

• CICS-DB2 Attach, CICS-MQ Attach, Comms Server Sockets (with

OTE=YES) all use L8 TCBs
• An Application using all three will use one L8 TCB

• In CICS TS 3.2 with the File Control Threadsafe enablement PTF

interleaving FC with DB2 or MQ26 will not cause TCB switching for
threadsafe applications.

Session 1078 © 2008 IBM Corporation 26

 Tilling’s CICS-MQ wishlist
(based on existing customer requirements)

• Need to ensure any new MQ API is supported by CICS shipped attaches

• CICS-MQ Group Attach

• Provide ability to connect to any member of QSG
• Would have same resync problems as DB2 (no peer recovery).
• Would NOT provide ability to connect to more than one queue manager at a time
27
• Trigger enhancements
• to be be able to automatically start trigger monitors for multiple initiation queues.
• On CICS restart, ensure all trigger monitors are restarted.
• To be able to specify a Transid other than CKTI
• To be able to specify which userid the trigger monitor runs under
• To be able to specify the userid under which the triggered application runs
• To provide a better way of stopping trigger monitors

• DPL Bridge should exploit Channels & containers

• Any more? Please submit a requirement

Session 1078 © 2008 IBM Corporation 27

Note the above enhancements are the subject of various customer requirements submitted to IBM. They
are no commitments to provide this functionaility at this time, but could form the basis of enhancements of
over a number of future releases.