Production Support Questions

Production support interviews test whether you can keep a live CICS region healthy: reading dumps, using CEMT, handling abends and following a support process.

The winning pattern is always the same: reproduce, isolate, check the environment, fix, verify.

Abend analysis

• Q: How do you read a transaction dump? A: Note the abend code, find the PSW offset, match it to the compiler listing to get the failing statement, then check EIBRESP and nearby data areas.
• Q: Common abends in production? A: ASRA program check (often S0C7 bad numeric data), AEI0 file not open, AEY9 program not defined, AICA runaway task, ATCH DB2 attachment problem.
• Q: S0C7 data exception - how do you find the bad field? A: The dump offset points to the failing instruction; the compiler listing shows which field it references; check that field for spaces or bad signs.
• Q: What is IPCS? A: The Interactive Problem Control System - the tool used to format and read dumps on z/OS.
• Q: Abend happens only in production, not in test. First suspects? A: Data differences (bad numeric data), missing CSD entries, wrong file DSNAMEs, unbound DB2 plans.

CICS operations commands

• Q: What do you check with CEMT? A: CEMT I TRAN/PROG/FILE/TASK shows status; CEMT S PROG(name) NEWCOPY refreshes a program; CEMT S FILE OPEN opens a file.
• Q: How do you debug a live transaction? A: CEDF trans-id steps through the program; CECI tests a single CICS command interactively.
• Q: How do you find what is holding a file? A: CEMT I FILE shows open status and ENQ waits; CEMT I TASK shows what each task is waiting on.
• Q: How do you stop a hung task? A: CEMT S TASK(n) PURGE, and FORCEPURGE only as a last resort because it can leave resources in doubt.
• Q: Where do CICS error messages go? A: The CSMT transient data queue and the CICS job log - check them around the time of the failure.

Support process

• Q: Walk me through a production incident. A: Reproduce or get exact trans-id/time/input; isolate program vs environment; check recent changes (was NEWCOPY done?); fix in test first; deploy with rollback plan; confirm with the user.
• Q: A change was deployed and users report errors. What first? A: Check whether NEWCOPY/PHASEIN actually ran, whether the mapset was refreshed, and whether the DB2 plan was rebound.
• Q: When do you escalate to the systems programmer? A: Region-wide issues (SOS, max tasks reached), DB2 subsystem problems, or dumps pointing at CICS code rather than the application.
• Q: How do you handle a severity-1 outage? A: Stabilize first (rollback the change if needed), communicate status to users, then root-cause with dumps and logs.