CICS Issues
Submitted by admin on Sat, 2004-08-07 07:17.
- With the "Oracle Access Manager for CICS" product you can write 3GL (eg COBOL, C, etc.) applications that execute from CICS.
- SQL*Forms V2.3 and V3.0 can execute from CICS but Oracle de-support SQL*Forms on MVS effective from 1 January 1998.
- Transaction synchronization can be controlled by CICS (EXEC CICS SYNCPOINT). This means that multiple data sources like DB/2, IMS, as well as Oracle on MVS and non-MVS platforms can be updated or rolled back as a single transaction.
- Oracle Access Manager for CICS replaces CICS-Attach. With Access Manager it is no longer required to have an Oracle database on MVS.
- SQL*Forms is conversational and thus uses lots of memory. CICS V4 is better optimized to run conversational transactions than its predecessors because it manages memory better.
- Use MPMTCB=NO (in the thread definition table) for pseudo-conversational transactions if there is less than 70 concurrently active users in one CICS.
- Always use MPMTCB=YES for conversational transactions written in SQL*Forms or PRO*Cobol.
- Setting PROTECT=NO will use more CPU for thread creation but saves memory and can prevent SOS (Short on Storage).
- Use LE/370 (IBM's Language Environment) for user exits. It will move 11K per user from the UDSA to the EUDSA above the line.
- Use the CICS phase-in facility to introduce new or updated programs. Newcopy will not work if a program is in service.
- Before Oracle 7.1 you had to compile SQL*Forms user exits with the DBMS=V6 precompiler option.
- Oracle claims CICS ATTACH 2.1 is +-20% faster than its predecessors (V7 mode).
- CICS generally thrashes when 90+% (sometimes even at 70%) of a single CPU is busy (DFHKCP is single threaded).
- CICS should have higher priority than the database (MPM).
- Use products like TMON and OMEGAMON to gather transaction statistics.
»
- Login to post comments