# SAG Com-plete & Natural access to MQSeries and/or CICS/MQ **URL:** \ **Category:** Forum\ **Tags:** Adabas-Natural, Natural, Natural-Related-Products, Com-plete\ **Created:** [October 14, 2015, 3:20pm UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404 "2015-10-14T15:20:45Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Allen\_Schmutzler](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/allen_schmutzler/32/1155_2.png) [@Allen\_Schmutzler](https://techcommunity.softwareag.com/u/Allen_Schmutzler)\ **Post date:** [October 14, 2015, 3:20pm UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/1 "2015-10-14T15:20:45Z")
My client is trying to use Com-Plete OLTP to access IBM MQSeries and is running into multi-threaded concurrency issues with the MQ Batch adapter. They assembled a set of MQSeries assembler stubs that call the various MQ APIs which they then call from their Natural code. The problem is when the workload reaches a point that two MQ calls try to use the MQ connection at the same time they get MQ reason codes 2009/2219 indicating that the connection is already in use or there maybe some issue with the connection/handle. We are looking at other options for making MQ API calls, such as thru a CICS/MQ interface that does support multiple threads and are wondering if there is any Com-plete/Natural interfaces for making connections to CICS. ---
**Author:** ![zarchasmpgmr](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/zarchasmpgmr/32/126_2.png) [@zarchasmpgmr](https://techcommunity.softwareag.com/u/zarchasmpgmr)\ **Post date:** [October 15, 2015, 1:26am UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/2 "2015-10-15T01:26:10Z")
Warning: answer tainted by it being a long time since I worked deeply with Complete. Usually when I have seen these types of issues in the past with Complete, it’s because the control blocks used by the service (not just limited to WMQ) were in thread storage, and the blocks were relocated to a different thread. A lot of the connection tokens are actually the addresses of data items in the control blocks, thus if the blocks are moved, the fields don’t pass the basic sanity checks, and errors are reported. (Or, worse, sometimes it goes boom.) A long time ago, Complete didn’t intercept GETMAIN/STORAGE OBTAIN requests above subpool 127. I have exploited this in the past by getting storage from subpool 230, which is private (but requires authorization). Since then, subpools 129-132 were added. These subpools are owned by the job step TCB, not the TCB of the issuer of the request. Subpools 131-132 do not require authorization by problem state programs, which is very nice If you can exercise control, or modify source of the stubs, you may be able to get storage out of subpool 131, which would allow the control blocks to relocate but the targets of the fields to not relocate. Again, it’s been a long time since I dealt with Complete at a deep level. But hopefully this can open up the discussion, and people can correct my old thinking, or this can give you something to play with. Also, maybe we can brainstorm ideas that would minimize having to bring in an additional address space and making things more inefficient. ---
**Author:** ![Steffen\_Kuhnert](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@Steffen\_Kuhnert](https://techcommunity.softwareag.com/u/Steffen_Kuhnert)\ **Post date:** [October 15, 2015, 11:45am UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/3 "2015-10-15T11:45:36Z")
Hello Allen, the MQ Batch adapter probably hooks into the TCB, but Complete normally does TCB pooling. This means, more than one Natural session may run on the same TCB, and also the same Natural session may run one transaction on one TCB and the next transaction on a different TCB. I can think of two possible ways to get it to work: 1) Set sysparm RESOURCE-MANAGER=YES This will have Complete switch user contexts when sessions switch TCBs. It’s a must when you talk to DB2 from Complete, maybe it works for MQ as well. 1. If (1) doesn’t work, then try to avoid TCB pooling: - In the TASK-GROUP sysparm, allocate enough TCBs for the number of users you’re expecting in Complete, and - In ULIB turn on “OS task affinity” for your Natural transaction(s). Please, let us know if either one works or not. Steffen Kuhnert Complete Development ---
**Author:** ![zarchasmpgmr](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/zarchasmpgmr/32/126_2.png) [@zarchasmpgmr](https://techcommunity.softwareag.com/u/zarchasmpgmr)\ **Post date:** [October 15, 2015, 5:13pm UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/4 "2015-10-15T17:13:12Z")
Hallo Steffen, wie geht’s? > [@Steffen Kuhnert](#): > > 1. > > Set sysparm RESOURCE-MANAGER=YES > This will have Complete switch user contexts when sessions switch TCBs. It’s a must when you talk to DB2 from Complete, maybe it works for MQ as well. The MQ interface was taken from DB2, in fact, they share what’s called the ERLY code. This should work. ---
**Author:** ![Allen\_Schmutzler](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/allen_schmutzler/32/1155_2.png) [@Allen\_Schmutzler](https://techcommunity.softwareag.com/u/Allen_Schmutzler)\ **Post date:** [October 16, 2015, 2:24am UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/5 "2015-10-16T02:24:49Z")
Thanks… we have the client’s SAG client engineer contacting his SAG/Complete engineer and they will discuss with SAG developers and the client’s Complete system admin’s to see if this configuration change is possible to do in their test environments and see if they can recreate this issue. I am not sure I follow the comment about the MQ/DB2 ERLY code… they are different LPA modules… though the IEFSSNxx subsystem entries have very similar formats. ---
**Author:** ![zarchasmpgmr](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/zarchasmpgmr/32/126_2.png) [@zarchasmpgmr](https://techcommunity.softwareag.com/u/zarchasmpgmr)\ **Post date:** [October 16, 2015, 2:43am UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/6 "2015-10-16T02:43:37Z")
When MQ was first developed, they “borrowed” a lot of the subsystem infrastructure (the “ERLY” code) from DB2 (which was across the hall in the IBM Toronto office at the time). There are a lot of similarities in how DB2 and WMQ requests are handled internally. One usually finds that if one encounters strange system issues with one, the same or very similar solution will fix the same problem with the other ---
**Author:** ![Allen\_Schmutzler](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/allen_schmutzler/32/1155_2.png) [@Allen\_Schmutzler](https://techcommunity.softwareag.com/u/Allen_Schmutzler)\ **Post date:** [October 22, 2015, 3:48pm UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/7 "2015-10-22T15:48:01Z")
They had already set the RESOURCE-MANAGER=YES enabled in their Com-Plete sysparms, so that was not the issue nor the answer. ---
**Author:** ![Allen\_Schmutzler](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/allen_schmutzler/32/1155_2.png) [@Allen\_Schmutzler](https://techcommunity.softwareag.com/u/Allen_Schmutzler)\ **Post date:** [November 12, 2015, 2:39am UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/8 "2015-11-12T02:39:49Z")
I have one more item to pursue… whether the Com-plete Natural user programs that make the MQ API calls would or should be linked with the MQ RRS Batch adapter stubs (CSQBRRSI or CSQBRSTB) to see if the application would behave better if it was relinked with RRS stubs that could handle mult-tasking or threading. for this Com-plete MQ TCP/context switching to work. The following “quote” in cyan/blue is a response I had gotten from an IBM MQ developer… but at the time I did not know how Com-plete handled TCB/context switching with the sysparm RESOURCE MANAGER=YES. Does anyone know if Com-Plete also handles the IBM RRS context switching too? [color=blue] > [@](#): > > Linking with the RRS stub does allow a batch connection to switch between different TCBs. This is because the MQ thread, and all the associated unit of recovery information, is associated with the RRS context, and not tied to the TCB. However, the function to set the required context is not available to normal batch applications; it is usually used by WLM or application servers, and it requires careful management. > > Even if this were available, it would not give them some kind of thread or connection management for free, it just allows a sophisticated thread management system to move its threads–along with the RRS context–between TCBs, and still do MQ calls. Each TCB can only be doing one MQI call at a time, and the application will have still to manage that serialisation (beyond MQs integrity protection, which is what is currently causing the failure return codes). > > As has been mentioned earlier, the recommended way of doing this is to use a complete transaction management system, such as CICS, where each of CICS and MQ understands the others threading model, and all the thread management is handled in an efficient way. I would strongly suggest this approach. > > I don’t know enough about the details of the application threading model or serialisation to give a best recommendation for a roll-your-own approach. (Note, if they are using USS threads (pthread\_create), this should already work–but they do need to remember to clean-up (MQDISC) before thread termination if using “mediumweight” threads). > > Assuming this is not case, and they are doing some RYO form of multithreading, the simple approach would be something like: have a pool of TCBs to do MQ work. When a thread starts doing MQ work, it is allocated a TCB from that pool for it’s exclusive use. When it does an MQ call, it switches to that TCB (for example by using pause-release services) to do the actual MQ work (and the TCB that it was running under can be used for another thread in the meantime). When it is done, it does the appropriate level of clean-up, and returns the MQ TCB to the pool for reuse by another (or the same thread). The most simple implementation would do an MQCONN when it gets and MQ TCB, and an MQDISC when it gives it back, but a more sophisticated implementation could cache the connection and MQOPEN object handles for reuse by the next thread, and just commit the unit of work. [/color] ---
**Author:** ![Steffen\_Kuhnert](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@Steffen\_Kuhnert](https://techcommunity.softwareag.com/u/Steffen_Kuhnert)\ **Post date:** [November 12, 2015, 8:31am UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/9 "2015-11-12T08:31:17Z")
RRS Begin\_Context, Switch\_Context, etc. is what RESOURCE MANAGER=YES does, so using the RRS stubs definitly sounds like a good idea. Complete does have a WLM interface, just add sysparm WLM-SUBSYSTEM-TYPE=COMP if you want to try this. ---
**Author:** ![Allen\_Schmutzler](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/allen_schmutzler/32/1155_2.png) [@Allen\_Schmutzler](https://techcommunity.softwareag.com/u/Allen_Schmutzler)\ **Post date:** [November 12, 2015, 1:47pm UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/10 "2015-11-12T13:47:42Z")
Thanks for the quick reply… one more question…there is a Com-plete sysparm for DB2…quoted from the System Programmer documentation. Does there need to be a similar SERVER definition, except for MQ? That would have the MQ SSID… and then of course the appropriate MQ load-libraries concatenated to the COMPLIB? Is this a ndw feature/function… something that could be added fairly easily to Com-plete? [color=darkblue] > [@](#): > > The DB2 Interface > > The Com-plete/DB2 interface uses the Resource Recovery Services attachment facility (RRSAF) of DB2. Since RRSAF, differently from CAF, allows the running of more than one DB2 connection per TCB, allocation of a separate task group with one TCB per user is no longer necessary. > > All DB2 related processing for a given user runs under control of the same TCB as his application (usually, Natural). > > The DB2 load-library (DSNLOAD) must be concatenated to the COMPLIB load library chain, because all relevant modules will be loaded dynamically. > > During startup, Com-plete attempts to connect to DB2 using an RRSAF IDENTIFY call. If the DB2 subsystem does not accept connections, Com-plete waits for a notification from DB2 and connects when this notification arrives. When DB2 notifies Com-plete about DB2 termination, Com-plete terminates all users’ DB2 sessions, issues a TERMINATE IDENTIFY call for the master (or “watchdog”) connection, and waits for a reconnect notification from DB2. > Initialization > > The DB2 interface is initialized using the following SYSPARM definitions: > > SERVER=(DB2,TLINDB2,ssid,plan) > > where: > ssid The DB2 subsystem ID for the RRSAF IDENTIFY call. [/color] ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [April 2, 2021, 3:34pm UTC](https://techcommunity.softwareag.com/t/sag-com-plete-natural-access-to-mqseries-and-or-cics-mq/184404/11 "2021-04-02T15:34:25Z")