IBM Z Software
This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server
For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server
We do not have any plans to provide support for CICS to connect to multiple DB2s at the same time. The requirement is rejected. I give some reasons below and how the customer might achieve what they are trying to do without this function, but using DRDA. Yes WAS can access multiple DB2, but nevertheless I believe that will involve use of DRDA.
The DB2 SSSC interface that CICS-DB2 Attach uses for the thread and system control requests for DB2 requires a coordinator TCB and then a set of subordinate thread TCBs which have to be subtasks of the coordinator TCB. In the days prior to use of OTE, the CICS-DB2 Attach created the coordinator TCB and the set of thread TCBs
With use of OTE, the CICS RO TCB is the coordinator TCB and the L8 TCBs are grand-daughters of the RO TCB, but neverthess obey the rule of being a subtask, albeit a grand-daughter rather than a daughter TCB.
It is theoretically possible (not proven) to have two separate coordinator TCBs each going to a different DB2, but then you need to be able to keep the set of L8 thread TCBs separate for each coordinator TCB. To talk to a particular DB2 you would need to use an L8 TCB for the correct coordinator. A CICS task is only allowed to have one L8 TCB. In order to implement this we would have to re-introduce TCB switching. This will greatly complicate the interface and we have no plans to do this.
For what the customer wants to achieve program 1 can issue an EXEC SQL CONNECT request to DB2A, program 2 can issue an EXEC SQL CONNECT to DB2B and program 3 can issue an EXEC SQL CONNECT to DB2C. Whichever DB2 system CICS is connect to is called the local DB2. So either the connect request connects to the local DB2 (ie this is a noop) or it uses the local DB2 as a passthrough to get to the other DB2 even if its on the same LPAR. When the program completes, the CICS-DB2 Attach cleans up the thread so it is back to its initial state.
(FYI... the DB2 JDBC Type 2 driver we use in CICS also uses this technique. For example when you get a connection using a default url, then a type 2 EXEC SQL CONNECT to the local DB2 is issued. If an explicit url is specified to a remote DB2, then a type 2 EXEC SQL CONNECT is issued to the remote DB2, using the local DB2 as a passthrough).
Each task can connect to a different DB2 independently as its handled at the thread level..
One task can even do updates to the local DB2 then connect to a remote DB2 and do updates there and then we can commit them in one UOW.
The point is we can do this because there is one local DB2 (as far as CICS is concerned, ie the one CICS is connected to). At the CICS task and thread level DB2 DRDA via the local DB2 handles the remote DB2. What we can't do is have CICS connected to two local DB2s directly even if they are on the same LPAR.