CICS Scenario-Based Questions

Interviewers love scenario questions because they test real debugging skill, not memory. Each question below describes a production situation and the answer shows the reasoning.

Practice answering out loud: state the symptom, the most likely cause, and the exact command or check you would run.

Abend scenarios

• Q: Users report ASRA abend on the inquiry transaction. What do you do? A: ASRA is a program check, usually S0C7 data exception. Get the dump, find the offset in the compiler listing, and look for a non-numeric value moved to a numeric field.
• Q: The update transaction abends with AEI0 on a file READ. Cause? A: AEI0 means the file was not open or not enabled. Run CEMT I FILE(name) and open it; check the FILE definition.
• Q: Typing the trans-id gives AEY9. What is wrong? A: The program behind the transaction is not defined or is disabled. Define it with CEDA and NEWCOPY the program.
• Q: Transaction abends with AICA. A: Runaway task - a loop with no terminal I/O, for example a browse loop that never ends. Find the loop and add a proper exit condition.
• Q: ATCH abend after a DB2 call. What happened? A: The DB2 attachment or plan has a problem - check -805/-818/-904 SQL codes and whether the plan is bound.

Functional scenarios

• Q: The map displays, but everything the user typed is lost on the next screen. Why? A: The MDT was never set, or the program used MAPONLY on RECEIVE. Use DATAONLY correctly and make sure FSET/FRSET handling sets the MDT.
• Q: The second user waits forever on an update screen. What is happening? A: The first task holds the record with READ UPDATE. Shorten the update window and handle the locked response with a retry message.
• Q: COMMAREA data is garbage on the second screen. Why? A: The first RETURN did not pass the COMMAREA, or LENGTH was wrong. EIBCALEN = 0 on entry means no COMMAREA arrived.
• Q: A record updated by program A is invisible to program B. A: Program A has not issued SYNCPOINT, so the change is uncommitted. Commit before RETURNing to the terminal.
• Q: The browse shows the same record twice. What is the bug? A: READNEXT was issued without STARTBR positioning, or the RIDFLD key was modified inside the loop.

Performance and deadlock scenarios

• Q: The transaction is fast for one user but slow under load. Where do you look? A: Locks held across terminal I/O, conversational tasks hogging storage, or a file browse scanning too many records. Make it pseudo-conversational and commit early.
• Q: DB2 returns -911 during the update transaction. How do you handle it? A: Deadlock or timeout. Roll back with SYNCPOINT ROLLBACK and retry the unit of work a few times before showing an error.
• Q: The region is short on storage (SOS). What could the program be doing? A: GETMAIN without FREEMAIN in a loop, or huge TS queues never deleted. Free what you get and delete scratch data.
• Q: Users complain the screen takes 10 seconds to appear. How do you diagnose? A: Use CEDF to time each EXEC call, check for file I/O inside loops, and verify DB2 access paths with EXPLAIN.