Wednesday, April 18, 2007
Review: CICS and DB2
Literature discusses a “conflict of interest” between design objectives in DB2 systems and CICS online transactions. One reason is pseudo-conversational code. A CICS program ends, and DB2 DROPS any tables that were being used. Without some kind of tedious programmatic intervention, cursor positioning or other processing would be lost.
Murach (CICS for the COBOL Programmer, 2001) suggests a number of strategies. One possibility, if the DB2 resource requirements are great, is to code in conversational architecture, with one DB2 query and one long browse.
In pseudo conversational mode, a program can store data on a VSAM file or, more likely, a temp storage queue between executions. Then a separate query is made between executions, with enough information to indicate how far the user got in any one execution. Or one long query could be made at the beginning of the first execution with all of the data stored in a VSAM file or storage queue and then browsed with conventional CICS commands.
In my own experience, none of this was done. Legacy data was replicated to a mid-tier and processed from that, although sometimes Legacy data was accessed with DB2 direct connect. The tedium of respecting pseudo-conversational discipline in mainframe application environments (and programmers will find this antiquated) may help explain why more and more companies are turning to more modern layered OOP models for managing user sessions, often over the Internet or in large consolidated customer service centers.