This page needs a newer browser to run its tools. You can still read everything here.

COBOL Module 14

CICS online programs (concepts with local business-logic tests) interview questions

Interview questions on CICS online programs (concepts with local business-logic tests).

8 questions: 3 warm-ups and 5 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

Fresher to mid

In CICS, what is the difference between a transaction and a task?

Answered in the lesson CICS transactions and pseudo-conversational design
Fresher to mid

Why does a pseudo-conversational COBOL program test EIBCALEN before it does anything else?

Answered in the lesson CICS transactions and pseudo-conversational design
Fresher to mid

In CICS, when do you use LINK, and when XCTL?

Answered in the lesson CICS commands, BMS maps and error handling

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Mid to senior

An update transaction reads an account record for update, sends it to the screen and waits for the teller to type the change. Every lunchtime some branch screens freeze for minutes. Explain why, and redesign it so that two tellers still cannot overwrite each other's change.
What it tests

Conversational against pseudo-conversational design, what a waiting task holds, and keeping updates safe when no lock can be held between screens.

First step

Find what the waiting task holds. The record read for update stays locked until the task ends or commits, so every other task that needs it waits behind a teller who has gone to lunch. Then end the task after the screen, and plan how the next task will tell whether the record changed in between.
Follow-ups
- How does the second task know that the record changed after the first task read it?
- What does the teller see when it did?
- How would you test the conflict without CICS?
From the lesson CICS transactions and pseudo-conversational design
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
Pro pass · 1 week₹79$2.99
30 days₹179$5.99
1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a licence key
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Senior to staff

A pseudo-conversational inquiry must now carry a statement page of about 40 KB between tasks, and three programs share its 11-byte COMMAREA layout. What breaks, what are your options, and how do you change all three without an outage?
What it tests

The COMMAREA's limits, channels and containers against other places for state, and changing an interface that several programs share.

First step

Compare the size with the limits: a RETURN accepts at most 32,763 bytes, and IBM advises staying under 24 KB, so 40 KB cannot travel in the COMMAREA. Then list every program that reads the layout, because each one must change with it.
Follow-ups
- How does each program know whether a task brought a COMMAREA or a channel while the change rolls out?
- Why not a temporary storage queue named after the terminal?
- How do you test the new layout before it reaches production?
From the lesson CICS transactions and pseudo-conversational design
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

An old update program issues HANDLE CONDITION NOTFND(NO-ACCOUNT) at its start. After a change adds a READ of a branch file, a missing branch record shows tellers "No account with this number". Explain why, and how you move the program to RESP without changing what already works.
What it tests

The scope of HANDLE CONDITION, handling outcomes inline with RESP, and changing the error handling of legacy code under tests.

First step

List every command that can raise NOTFND after the HANDLE CONDITION: it applies for the whole program, so the new READ of the branch file jumps to the same label as the account READ. Before changing anything, write one test case for each command's NOTFND, run against stubs, so that the move can be proved.
Follow-ups
- Why not add a second HANDLE CONDITION just before the branch READ?
- What must every command with RESP test besides NORMAL and NOTFND?
- How do you prove that the account READ behaves as before?
From the lesson CICS commands, BMS maps and error handling
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Tellers see "Mobile number changed", yet some numbers were never changed on the file. Every command in the program codes RESP. What is the likely cause, how do you prove it without a CICS region, and what stops it coming back?
What it tests

What coding RESP makes the program responsible for, fakes that answer as CICS does, and test cases that check the file as well as the reply.

First step

Start from what coding RESP changes: a condition no longer ends the task, so every outcome comes back to the program. List the commands of the update in order and, for each one, the outcomes the program tests. Any outcome that is set but never tested before the reply is chosen is a suspect.
Follow-ups
- Why did CICS not end the task?
- What must a fake answer for a REWRITE when nothing is held?
- Which check of the test driver catches it, and which one would miss it?
From the lesson CICS commands, BMS maps and error handling
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Senior to staff

A transfer program debits one account and credits another. After abends, an audit finds debits without credits. Where can a transfer be split, what does CICS back out and what not, and how do you design the program so that a half-done transfer is never committed?
What it tests

Units of work, SYNCPOINT, recoverable resources and backout, and ending a task on purpose so that money stays consistent.

First step

Mark every point where the transfer's task could end or commit: after each READ and REWRITE, at any SYNCPOINT and at the end of the task. For each point, write down what CICS would keep and what it would restore, and check how the account file is defined to CICS.
Follow-ups
- What should the program do when the READ of the second account returns NOTFND?
- Where does HANDLE ABEND help, and where does it not?
- How do you prove the design without waiting for an abend in production?
From the lesson CICS commands, BMS maps and error handling
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes

All COBOL interview questions · The COBOL track

Warm-up questions

In CICS, what is the difference between a transaction and a task?

Why does a pseudo-conversational COBOL program test EIBCALEN before it does anything else?

In CICS, when do you use LINK, and when XCTL?

Questions with model answers

An update transaction reads an account record for update, sends it to the screen and waits for the teller to type the change. Every lunchtime some branch screens freeze for minutes. Explain why, and redesign it so that two tellers still cannot overwrite each other's change.

A pseudo-conversational inquiry must now carry a statement page of about 40 KB between tasks, and three programs share its 11-byte COMMAREA layout. What breaks, what are your options, and how do you change all three without an outage?

An old update program issues HANDLE CONDITION NOTFND(NO-ACCOUNT) at its start. After a change adds a READ of a branch file, a missing branch record shows tellers "No account with this number". Explain why, and how you move the program to RESP without changing what already works.

Tellers see "Mobile number changed", yet some numbers were never changed on the file. Every command in the program codes RESP. What is the likely cause, how do you prove it without a CICS region, and what stops it coming back?

A transfer program debits one account and credits another. After abends, an audit finds debits without credits. Where can a transfer be split, what does CICS back out and what not, and how do you design the program so that a half-done transfer is never committed?