Q
Problem solve Get help with specific problems with your technologies, process and projects.

What to look out for when migrating from CICS 4.1 to TS 2.2?

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.

This was last published in September 2002

Dig Deeper on IBM system z and mainframe systems

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchWindowsServer

SearchServerVirtualization

SearchCloudComputing

Close