In CICS there are many ways to share data across transactions/tasks. One of them is by using TS queues. In comparison to ordinary storage TS queues are able to be shared across many CICS regions. So if you have a CICS transaction running on many different CICS regions and it will be a good idea for this transaction to share data between the different CICS regions it is possible to use a TS queue for this purpose.

Actually there are two kinds of TS queues which can be shared across CICS regions. One of them is the socalled remote TS queue where the TS queue is residing on one CICS region called the owner. All the other CICS regions which are connected to the owner can access the TS queue. Unfortunately this is an expensive solution performancewise and if the owner CICS region abends it is just too bad. On the other hand you are able to backup such a queue on disk (A socalled auxiliary TS queue). The other kind of TS queue is a shared TS queue which is available only in storage. Storage for such a TS queue is allocated in a Coupling Facility (CF) and therefore it does not disappear when a certain CICS region abends. If the CF abends all your MVS systems in the sysplex dies and consequently all your CICS regions dies. The CICS regions who wants to share a shared TS queue does not need to be connected. They just need to be connected to the CF.

All of the above may sound pretty complicated so let me give you some practical advise instead. Log on to a CICS system where you have access to both the CEMT and CECI transactions (typically a test CICS). Execute a CEMT I TSM command. Now you will receive a list of all definitions related to shared TS queues. Those with a pool parameter connected are the interesting ones. Definitions containing the pool parameter also have a prefix parameter. If you create a TS queue with a name starting with one of the listed prefixes your TS queue automatically becomes a shared TS queue. It is as easy as that. You must of course ensure that the production CICS regions have the same definition otherwise your sharing will only work in your test environment.

When you have found a suitable prefix you can test it using CECI. Execute a CECI WRITEQ TS QN(<prefix>MYTSQ) FROM('Hello there') on one of the CICS regions in test. Then log on to another test CICS region and execute a CECI READQ TS QN(<prefix>MYTSQ) ITEM(1). Please check the INTO parameter. Hopefully it now contains the text 'Hello there'. Now try the same CECI READQ on a third test CICS and look at the contents of the INTO parameter. I think it is brilliant. This experiment only works as described if the TS queue <prefix>MYTSQ does not already exist. If the CICS regions are not properly set up for using shared TS queues or your installation does not run in a SYSPLEX it does not work either.

If you are used to use CEMT I TSQ for locating and probably deleting TS queues the sad news is that shared TS queues does not appear when using CEMT I TSQ. So please remember to clean up after your experiments by using a CECI DELETEQ TS QN(<prefix>MYTSQ). When you create your shared TS queue application you must carefully consider how you populate it (If you do it at the same time from different parallel running tasks you may end up with jammed data) and how you clean it up. If you put a lot of data into it and do not clean it up the data will fill up in the CF. Then there is a huge risk that some angry systems programmer will contact you especially if this happens in the production environment.