What are some items I should consider or look out for during my conversion from CICS 4.1 to CICS TS 2.2?
A simple question with a load of implications! The 1st thing to say is that it's not worth going via 1.3.
The main thing to note is that for non-java programs (ie: most of traditional CICS applications) there are not any great implications in getting upto CICS TS 2.2 as this release is mostly concerned with Java Support. Other things have been enhanced, but there are no great peturbations involved........
......apart from the Logger........
The major change that you will have to address (in 1.3 & 2.2) is that we now use MVS logger functions to do journalling. The user comunity thinks that this is a big change, and who am I to challenge that? However, once you have worked out what is going on, I think that the major challenge is getting the offline and administrative processes sorted for a secure control of updates. There are loads of docs available on getting the logger running, and Guide/Share have some excellent info for consultation. The only advice I can give is get the sizings right: too small and problems will result!
There is a change in the behavour of the XC SIGNON command: in 2.2 it will not alter the identity of a current executing terminal-attached transaction. It will only affect the next tranasction initiated at the terminal.
The LE runtime is required (well, almost) in 2.2 so ensure that you are using uptodate runtimes provided within LE libraries. OS/VS COBOL programs will run unchanged and as is. VS COBOL II programs may alter behavour depending upon LE options (eg: the STORAGE option defines whether or not Getmained storage is X'00'ed or not: your application program may be assuming it is, but LE is leaving it dirty). One may want to embark upon an upgrading exercise from these older COBOLs to the current versions (and you can then use the Integrated Translater on them).
You will also want to use the DB2 v7.1 Group Attach facility, to give improved activity on a DB2 region abend. There are also performance benefits available to DB2 applications which are structured so that they can take advantage of running under non-QR TCBs.
GLUEs and TRUEs will need attention, as they can be executed on other TCBs than the QR. This means that multiprocessing and multi-accessing can be going on. You should ensure that all GLUEs, TRUEs, and URMs are coded in such a manner that they do not assume that they are the only thing running and so can access/set areas without protection. As an example of this, I have come across a rather nifty user-supplied TRUE that does storage management for a task which seems to break this multi-processing rule. The best thing is alsways to use GLUE ENQ/DEQ facilitities, or implement using ECBs with a multitude of CS intructions.
Dig Deeper on IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs? Continue Reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology. Continue Reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible? Continue Reading