CICSbeginner

Common EXEC CICS Commands Overview

Build fluency with the everyday EXEC CICS command vocabulary for terminal I/O, file access, and program control.

Beyond understanding CICS concepts abstractly, interviews frequently test raw command fluency — can you actually write the EXEC CICS statements for common tasks without hesitation? This topic is essentially a working vocabulary check: SEND/RECEIVE for terminal I/O, READ/WRITE/REWRITE/DELETE for file access, LINK/XCTL for program control, and ASKTIME/FORMATTIME for date-time handling are the bread-and-butter commands every CICS program uses constantly.

These core EXEC CICS commands are like the basic verbs of a language you need before you can hold any real conversation — SEND/RECEIVE are 'speak' and 'listen,' READ/WRITE/REWRITE/DELETE are 'look up,' 'add,' 'correct,' and 'remove' in a shared filing system, and LINK/XCTL are 'delegate and wait for them to finish' versus 'hand off the whole conversation and step away.'

Key Concepts

1
EXEC CICS SEND and RECEIVE (and their MAP-suffixed variants, SEND MAP and RECEIVE MAP) handle terminal output and input respectively — plain SEND/RECEIVE work with unformatted text, while SEND MAP/RECEIVE MAP work through BMS-defined screens. File access commands mirror COBOL's own I/O verbs conceptually but operate through CICS's file control against VSAM (or DB2-backed) resources defined in the CICS resource definitions rather than a COBOL SELECT/ASSIGN: READ retrieves a record by key (RIDFLD), WRITE adds a new record, REWRITE updates one already read for update, and DELETE removes one.
2
LINK and XCTL both transfer control to another program, but with an important difference: LINK is like a subroutine call — control returns to the calling program after the linked program finishes — while XCTL fully transfers control and never returns to the calling program (similar in spirit to a tail call). Choosing between them is itself a common interview question, since picking XCTL when you actually needed control to return afterward is a real design bug.
3
A baseline interview expectation is being able to sketch, from memory, the general shape of these commands (including RESP for error checking) for a simple read-a-record-and-display-it scenario, since fluency here is what everything more advanced (pseudo-conversational design, error handling, COMMAREA) is built on top of.