End-to-End CICS Project

A real CICS project goes from requirement to production in clear phases: analysis, design, BMS maps, coding, testing and deployment.

Knowing the full lifecycle is what separates a coder from a developer in interviews and on the job.

Phases of a real CICS project

• Requirement: write the program overview - trans-id, overview, input/output specs, processing specs (like the CUSTMNT1 customer maintenance example).
• Design: build the event/response chart - every user action (Enter, PF keys) and the program's response - then a structure chart of modules.
• BMS maps: design the key map and data map screens, field attributes, then code the DFHMSD/DFHMDI/DFHMDF macros and assemble the mapset.
• Coding: write the pseudo-conversational COBOL program with the CICS translator, following the shop's naming standards.
• Testing: unit test with CEDF and CECI, then system testing, then user acceptance testing with real business data.
• Deployment: define PROGRAM, TRANSACTION, MAPSET and FILE entries in the CSD and install them in the production region.

CSD definitions needed for deployment

• PROGRAM definition for every COBOL program: name, LANGUAGE(COBOL), STATUS(ENABLED).
• TRANSACTION definition mapping each trans-id to its program.
• MAPSET definition for each BMS mapset used by the screens.
• FILE definitions for every VSAM file with the correct DSNAME.
• After any program change, run CEMT SET PROGRAM(...) NEWCOPY or PHASEIN so CICS picks up the new load module.
• Example:-
  
  CEDA DEFINE PROGRAM(BKINQ) GROUP(BANKGRP) LANGUAGE(COBOL) STATUS(ENABLED) CEDA DEFINE TRANSACTION(BKIN) GROUP(BANKGRP) PROGRAM(BKINQ) CEDA DEFINE MAPSET(INQSET) GROUP(BANKGRP) CEDA INSTALL GROUP(BANKGRP)

Testing a CICS program

• CEDF: step through the program line by line and watch each EXEC CICS call execute with its RESP code.
• CECI: test a single CICS command interactively, for example a file READ, before coding it.
• Read transaction dumps with IPCS; check EIBRESP and the failing offset to find the bad command.
• Test the unhappy paths: file not found, invalid input, PF3 mid-transaction, and DB2 deadlock.
• Regression test the full menu flow after every change - one screen fix often breaks another screen.