Chapter 26 Exercises: IMS Database and Transaction Management

These exercises cover IMS/DB hierarchical database concepts, DL/I call programming in COBOL, PCB/PSB definitions, segment search arguments, and IMS Transaction Manager processing. Banking and financial scenarios are used throughout.

Tier 1 — Recall

Objective: Verify recall of fundamental IMS terminology, DL/I call syntax, and hierarchical database concepts.

Exercise 1.1 — DL/I Call Functions

Match each DL/I call function code to its purpose:

Function Code Purpose
GU ?
GN ?
GHU ?
GHN ?
ISRT ?
DLET ?
REPL ?

Expected outcome: A completed table with correct one-line descriptions for all seven function codes.

Exercise 1.2 — PCB Status Codes

List the meaning of each IMS status code:

Status Code Meaning
(blank) ?
GE ?
GB ?
II ?
AI ?

Expected outcome: Five correct definitions (e.g., blank = successful call, GE = segment not found, GB = end of database, II = invalid insert, AI = integrity error or access rule violation).

Exercise 1.3 — Hierarchical Database Structure

Draw (in text form) the hierarchical structure for a banking database with the following segments:

  • CUSTOMER (root segment) — contains customer ID, name, address.
  • ACCOUNT (child of CUSTOMER) — contains account number, type, balance.
  • TRANSACTION (child of ACCOUNT) — contains transaction ID, date, amount.
  • LOAN (child of CUSTOMER) — contains loan number, principal, rate.
  • PAYMENT (child of LOAN) — contains payment date, amount.

Expected outcome: A tree diagram using indentation or ASCII art showing the parent-child relationships.

Exercise 1.4 — PSB and PCB Definitions

Explain the relationship between a PSB and PCBs. How many PCBs can a PSB contain, and what does each PCB represent?

Expected outcome: A PSB (Program Specification Block) contains one or more PCBs (Program Communication Blocks). Each PCB defines the program's view of one IMS database, including which segments the program can access and what operations (read, insert, replace, delete) are permitted. A PSB may also include a TP PCB for IMS TM message processing.

Exercise 1.5 — Segment Search Argument Syntax

Write an unqualified SSA and a qualified SSA for the ACCOUNT segment where ACCT-NO equals 1001000123.

Expected outcome:

  • Unqualified: ACCOUNT (padded to 9 bytes)
  • Qualified: ACCOUNT (ACCT-NO = 1001000123) with correct spacing and parentheses.

Exercise 1.6 — COBOL DL/I CALL Statement

Write the COBOL CALL 'CBLTDLI' statement to issue a GU (Get Unique) call against a PCB named ACCT-PCB using an I/O area named ACCT-IO-AREA and a single qualified SSA named ACCT-QUAL-SSA.

Expected outcome: A syntactically correct CALL statement with the function code, PCB pointer, I/O area, and SSA parameters in the correct order.

Exercise 1.7 — Sensitivity and PROCOPT

Explain the following PROCOPT values and when each would be used:

  1. PROCOPT=G
  2. PROCOPT=I
  3. PROCOPT=R
  4. PROCOPT=D
  5. PROCOPT=A

Expected outcome: G = Get (read only), I = Insert, R = Replace (update), D = Delete, A = All operations. Explanation of how PROCOPT restricts program access to specific operations on a segment.

Exercise 1.8 — IMS TM Message Processing

Define the following IMS Transaction Manager terms:

  1. MPP (Message Processing Program)
  2. BMP (Batch Message Processing)
  3. MFS (Message Format Service)
  4. SPA (Scratchpad Area)

Expected outcome: Four concise definitions describing each component's role in IMS online transaction processing.

Tier 2 — Comprehension

Objective: Read and interpret IMS-COBOL code and explain hierarchical database navigation.

Exercise 2.1 — Trace a GN Loop

Study the following code and answer the questions:

       CALL 'CBLTDLI' USING GU-FUNC
                             CUST-PCB
                             CUST-IO-AREA
                             CUST-QUAL-SSA.
       IF CUST-STATUS-CODE = SPACES
           PERFORM UNTIL ACCT-STATUS-CODE = 'GE'
               CALL 'CBLTDLI' USING GN-FUNC
                                     ACCT-PCB
                                     ACCT-IO-AREA
                                     ACCT-UNQUAL-SSA
               IF ACCT-STATUS-CODE = SPACES
                   DISPLAY ACCT-NUMBER ' ' ACCT-BALANCE
               END-IF
           END-PERFORM
       END-IF.
  1. What does the GU call retrieve?
  2. What does each GN call retrieve?
  3. Why does the loop check for status code 'GE'?
  4. If the customer has three accounts, how many GN calls will execute (including the one that returns 'GE')?

Expected outcome: Four correct answers demonstrating understanding of hierarchical navigation and status code handling.

Exercise 2.2 — Qualified vs. Unqualified SSA

Explain the difference in database positioning between:

       CALL 'CBLTDLI' USING GU-FUNC PCB IO-AREA
                             CUST-QUAL-SSA ACCT-QUAL-SSA.

and:

       CALL 'CBLTDLI' USING GU-FUNC PCB IO-AREA
                             CUST-QUAL-SSA ACCT-UNQUAL-SSA.

Expected outcome: The first call retrieves a specific account under a specific customer. The second retrieves the first account occurrence under the specified customer, because the unqualified SSA does not filter by any field value.

Exercise 2.3 — Understanding GHU/GHN

Why must a program issue a GHU or GHN call before issuing a REPL or DLET call? What happens if you attempt a REPL without a prior hold call?

Expected outcome: Hold calls (GHU, GHN, GHNP) establish a hold on the current segment, indicating intent to modify. Without a prior hold call, a REPL or DLET will return an 'AI' status code because IMS requires the program to declare update intent before modifying data.

Exercise 2.4 — Reading a DBD

Given the following simplified DBD definition:

DBD     NAME=BANKDB,ACCESS=HDAM
SEGM    NAME=CUSTOMER,BYTES=200,PARENT=0
FIELD   NAME=(CUSTID,SEQ,U),BYTES=10,START=1
SEGM    NAME=ACCOUNT,BYTES=100,PARENT=CUSTOMER
FIELD   NAME=(ACCTNO,SEQ,U),BYTES=10,START=1
SEGM    NAME=TRANSACT,BYTES=80,PARENT=ACCOUNT
FIELD   NAME=(TXNID,SEQ,U),BYTES=8,START=1

Answer:

  1. What is the access method?
  2. Which segment is the root?
  3. What is the maximum depth of the hierarchy?
  4. Are duplicate keys allowed for CUSTID? How do you know?

Expected outcome: (1) HDAM (Hierarchical Direct Access Method), (2) CUSTOMER, (3) three levels, (4) no duplicates — the 'U' in the FIELD definition indicates unique keys.

Exercise 2.5 — Command Codes in SSAs

Explain the effect of each command code when used in an SSA:

  1. D (path call)
  2. F (first occurrence)
  3. L (last occurrence)
  4. N (path call — do not replace this level)
  5. P (set parentage)

Expected outcome: Five descriptions showing how command codes modify the behavior of DL/I calls.

Exercise 2.6 — Multiple PCBs

A COBOL program's PSB contains three PCBs:

  1. TP PCB (for IMS TM message I/O)
  2. DB PCB for BANKDB (PROCOPT=G)
  3. DB PCB for AUDITDB (PROCOPT=A)

In the COBOL program's LINKAGE SECTION, how are these PCBs addressed? Write the relevant LINKAGE SECTION and ENTRY statement.

Expected outcome: A LINKAGE SECTION with PCB mask definitions and an ENTRY 'DLITCBL' statement showing the PCB pointers in the correct order matching the PSB definition.

Exercise 2.7 — GNP Call Behavior

Explain what the GNP (Get Next within Parent) call does and how it differs from GN (Get Next). Provide a banking scenario where GNP is the correct choice.

Expected outcome: GNP restricts navigation to dependent segments under the currently established parent, whereas GN navigates sequentially through the entire database. GNP is appropriate when retrieving all transactions for a specific account without accidentally reading transactions from other accounts.

Exercise 2.8 — Checkpoint and Restart

Explain the purpose of the CHKP (Checkpoint) call in an IMS batch program. What data is saved, and how does it relate to restart processing?

Expected outcome: The CHKP call commits all database changes made since the last checkpoint, writes a checkpoint record to the IMS log, and optionally saves application data (in extended checkpoint/restart). If the program fails, the IMS restart facility can back out uncommitted changes to the last checkpoint and the program can be restarted from that point.

Tier 3 — Application

Objective: Write correct COBOL-IMS programs to solve stated problems.

Exercise 3.1 — Retrieve Customer Information

Write a COBOL paragraph that uses a GU call to retrieve a customer segment from the BANKDB database where CUSTID = 'C000012345'. Display the customer name and address. Handle the 'GE' (not found) status code.

Expected outcome: A complete paragraph with the qualified SSA definition in WORKING-STORAGE, the CALL statement, status code checking, and DISPLAY statements.

Hint: Define the SSA as a COBOL group item with the segment name, opening parenthesis, field name, operator, value, and closing parenthesis.

Exercise 3.2 — Insert a New Account

Write the COBOL code to insert a new ACCOUNT segment under an existing CUSTOMER. The program should first issue a GU on the CUSTOMER segment to establish position, then issue an ISRT for the new ACCOUNT segment. Handle the 'II' (duplicate key) status code.

Expected outcome: Two CALL statements with proper SSAs, I/O area population, and status code handling.

Exercise 3.3 — Update Account Balance

Write a COBOL paragraph that retrieves an account using GHU (Get Hold Unique), adds a deposit amount to the balance field in the I/O area, and issues a REPL call to update the segment. Verify that both calls return a blank status code.

Expected outcome: A complete GHU-modify-REPL sequence with proper path SSAs (customer qualified, account qualified) and error handling.

Exercise 3.4 — Delete a Transaction Segment

Write the COBOL code to delete a specific TRANSACTION segment identified by transaction ID TXN00042 under account 1001000123 under customer C000012345. Use GHU with a fully qualified path call, then DLET.

Expected outcome: A GHU call with three qualified SSAs (customer, account, transaction) followed by a DLET call, with status code checking after each call.

Exercise 3.5 — Navigate All Accounts for a Customer

Write a COBOL section that retrieves a customer by ID and then iterates through all ACCOUNT segments under that customer using GNP calls. For each account, display the account number, type, and balance. Stop when GNP returns 'GE' (no more dependents under this parent).

Expected outcome: A GU for the customer followed by a GNP loop for accounts, with a complete PERFORM UNTIL loop and status code handling.

Exercise 3.6 — Path Call to Retrieve Customer and Account

Write a COBOL paragraph that uses a single GU call with the D (path) command code in the SSAs to retrieve both the CUSTOMER and ACCOUNT segments in one call. Display fields from both segments.

Expected outcome: SSA definitions with the *D command code, a single CALL with multiple I/O areas or a concatenated I/O area, and post-call field display.

Hint: In a path call with the D command code, IMS returns data for all segments in the path. Each segment's data is placed in its respective I/O area.

Exercise 3.7 — Batch Insert of Transactions from a File

Write a COBOL program fragment that reads a sequential file of transaction records and inserts each as a TRANSACTION segment under the appropriate ACCOUNT and CUSTOMER parents. Include:

  1. File I/O to read each transaction record.
  2. A GU to establish position on the parent ACCOUNT.
  3. An ISRT to add the TRANSACTION segment.
  4. A CHKP (checkpoint) call every 500 inserts.
  5. Status code handling for each DL/I call.

Expected outcome: 50-70 lines of COBOL covering the complete batch insert logic with checkpoint processing.

Exercise 3.8 — IMS TM Message Processing

Write the COBOL code for an MPP (Message Processing Program) that:

  1. Receives an input message from the IMS message queue using a GU call on the TP PCB.
  2. Parses the account number from the message.
  3. Retrieves the account balance from the BANKDB database.
  4. Constructs a response message with the balance.
  5. Sends the response using an ISRT call on the TP PCB.

Expected outcome: A complete MPP processing loop with TP PCB I/O and database PCB access, including the GU TP-PCB to receive and ISRT TP-PCB to send.

Tier 4 — Analysis

Objective: Debug IMS programs, analyze performance issues, and evaluate database design decisions.

Exercise 4.1 — Diagnose Status Code 'AI'

A COBOL-IMS program issues a REPL call and receives status code 'AI'. The preceding call in the program was a GU (not GHU). The developer is confused because the GU was successful.

  1. Explain why the 'AI' status code was returned.
  2. What is the minimum change required to fix the program?
  3. Are there any other situations that can cause 'AI'?

Expected outcome: Explanation that REPL requires a prior hold call (GHU, GHN, GHNP). Fix: change GU to GHU. Other causes: PROCOPT does not include 'R', or the segment has not been modified before REPL is issued (some IMS versions).

Exercise 4.2 — Inefficient Hierarchical Navigation

A batch program needs to process all TRANSACTION segments across all accounts for all customers. The developer wrote:

       PERFORM VARYING WS-CUST-IDX FROM 1 BY 1
           UNTIL CUST-STATUS = 'GE'
           CALL 'CBLTDLI' USING GN-FUNC CUST-PCB
                                 CUST-IO CUST-UNQUAL-SSA
           IF CUST-STATUS = SPACES
               PERFORM GET-ALL-ACCOUNTS
           END-IF
       END-PERFORM.

       GET-ALL-ACCOUNTS.
           PERFORM UNTIL ACCT-STATUS = 'GE'
               CALL 'CBLTDLI' USING GU-FUNC ACCT-PCB
                                     ACCT-IO ACCT-QUAL-SSA
               IF ACCT-STATUS = SPACES
                   PERFORM GET-ALL-TRANSACTIONS
               END-IF
           END-PERFORM.

Identify at least three problems with this approach and propose a more efficient alternative.

Expected outcome: Problems include (1) using GU inside a loop instead of GN/GNP for sequential access, (2) potential repositioning overhead from repeated GU calls, (3) the ACCT-QUAL-SSA might not be updated for each customer. Better approach: use a single sequential pass with GN and unqualified SSAs, detecting segment type changes through the PCB segment name field.

Exercise 4.3 — Database Access Method Selection

A bank is designing a new IMS database for customer accounts. The primary access pattern is direct retrieval by customer ID, but monthly batch reports require sequential processing of all customers.

Compare HDAM, HIDAM, and HISAM access methods for this use case. Recommend one and justify your choice.

Expected outcome: HDAM provides fast direct access but no sequential ordering. HIDAM provides both direct and ordered sequential access via a secondary index. HISAM is best for predominantly sequential access. Recommendation: HIDAM for the mixed workload, with explanation.

Exercise 4.4 — Secondary Index Justification

The banking database is accessed by customer ID (the root key), but a new requirement asks for lookups by Social Security Number. The DBA proposes adding a secondary index.

  1. Describe how a secondary index works in IMS.
  2. What are the performance trade-offs?
  3. What changes are needed in the application program?

Expected outcome: Explanation of the secondary index as a separate database that provides an alternate access path to the target segment. Trade-offs: faster retrieval by the indexed field but additional overhead on insert, update, and delete operations. Program changes: an additional PCB referencing the secondary index processing sequence.

Exercise 4.5 — Checkpoint Interval Analysis

A batch program processes 10 million TRANSACTION segments and issues a checkpoint every 100,000 segments. The program takes 4 hours to run.

  1. If the program fails at the 6-million mark, how long will recovery take (approximately)?
  2. If the checkpoint interval is reduced to 10,000, what are the benefits and costs?
  3. Recommend an optimal checkpoint interval and justify it.

Expected outcome: Analysis of recovery time (backout of up to 100,000 segments), discussion of checkpoint overhead vs. recovery time trade-off, and a reasoned recommendation (e.g., 5,000-50,000 segments depending on segment size and I/O cost).

Exercise 4.6 — PSB PROCOPT Security Analysis

A production banking system has a PSB where every PCB specifies PROCOPT=A (all operations). A security auditor flags this as a risk.

  1. Explain the security concern.
  2. Propose a revised PROCOPT strategy for three programs: an inquiry program, a transaction-posting program, and a maintenance program.
  3. What happens at runtime if a program attempts an operation not allowed by its PROCOPT?

Expected outcome: Concern: all programs can modify any accessible segment, violating the principle of least privilege. Revised PROCOPTs: inquiry = G, posting = GIR (get, insert, replace), maintenance = A. Unauthorized operation returns status code 'AM'.

Exercise 4.7 — Logical Relationship Analysis

Two physical databases exist:

  • CUSTDB: CUSTOMER -> ACCOUNT
  • LOANDB: LOAN -> PAYMENT

A requirement states that a CUSTOMER should be able to see its LOANs without duplicating data.

  1. Describe how an IMS logical relationship could connect these databases.
  2. What are the three types of logical relationships?
  3. What are the risks of logical relationships in high-volume environments?

Expected outcome: Explanation of a logical child pointer from CUSTOMER to LOAN, the three types (unidirectional, bidirectional virtual, bidirectional physical), and risks (pointer maintenance overhead, complexity, potential for pointer errors).

Exercise 4.8 — Dead Letter Queue Investigation

An MPP program processing ATM withdrawal requests occasionally fails to send a response message. The operations team finds messages accumulating in the dead letter queue.

  1. What are the most common causes of messages going to the dead letter queue?
  2. How would you diagnose this problem using IMS logs and traces?
  3. Propose a defensive coding strategy to prevent message loss.

Expected outcome: Causes include program abend before ISRT to TP PCB, invalid message format, and PURG call issues. Diagnosis via IMS log analysis (x'07' records), /DISPLAY TRAN output, and IMS monitor traces. Defensive coding: always issue ISRT to TP PCB in an error handler, use SPA for conversational recovery, and validate all input before database calls.

Tier 5 — Synthesis

Objective: Design complete COBOL-IMS applications for realistic banking scenarios.

Exercise 5.1 — Account Statement Batch Program

Design a COBOL-IMS batch program that produces monthly account statements for all bank customers. The program must:

  • Sequentially navigate the BANKDB hierarchy: CUSTOMER -> ACCOUNT -> TRANSACTION.
  • For each customer, produce a statement header (name, address).
  • For each account, list all transactions within the statement month.
  • Calculate and display running balances.
  • Write the statement to a print file with page breaks per customer.
  • Issue checkpoints every 1000 customers.
  • Handle all status codes with a centralized error routine.

Provide:

  1. The PSB definition (PCB sensitivity list).
  2. The WORKING-STORAGE SSA definitions.
  3. The main navigation loop (GU for first customer, GN loop for subsequent).
  4. The control-break logic for customer and account boundaries.
  5. The checkpoint and error-handling paragraphs.

Expected outcome: A comprehensive design with at least 100 lines of COBOL code fragments demonstrating mastery of IMS batch navigation patterns.

Exercise 5.2 — ATM Transaction MPP

Design an IMS TM Message Processing Program (MPP) for ATM balance inquiries and withdrawals. The program must:

  • Receive a message containing transaction type (INQ or WDR), account number, and optional amount.
  • For inquiries, retrieve and return the current balance.
  • For withdrawals, validate sufficient funds, update the balance (GHU + REPL), insert a TRANSACTION segment, and return a success/failure message.
  • Handle all DL/I status codes.
  • Implement conversational processing using a Scratchpad Area (SPA) for multi-step transactions that require PIN verification.

Provide:

  1. The input and output message layouts (MFS definitions or COBOL record layouts).
  2. The TP PCB GU (receive) and ISRT (send) logic.
  3. The database access logic for both inquiry and withdrawal.
  4. The SPA-based conversational flow for PIN verification.
  5. Error handling and rollback strategy.

Expected outcome: A complete MPP design with detailed COBOL code fragments for all transaction paths.

Exercise 5.3 — Database Reorganization Utility

Design a COBOL-IMS utility program for reorganizing the BANKDB database. The program must:

  • Unload all segments from the database in hierarchical sequence using GN calls.
  • Write each segment to a sequential file with a segment-type identifier.
  • Validate segment relationships during unload (parent must exist before child).
  • Produce a statistics report (segment counts by type, total bytes).
  • Provide a companion reload program that reads the sequential file and issues ISRT calls to rebuild the database.
  • Include checkpoint/restart logic in both unload and reload phases.

Provide:

  1. The unload program's main navigation loop.
  2. The sequential file record layout.
  3. The reload program's ISRT logic with parent positioning.
  4. The statistics report layout.
  5. The checkpoint/restart implementation for both programs.

Expected outcome: A two-program utility design with detailed code fragments for the complete unload/reload cycle.

Exercise 5.4 — Loan Payment Processing System

Design a complete loan payment processing system using IMS. The system includes:

  • A batch program that reads a payment file and applies payments to loans in the LOANDB database.
  • For each payment: retrieve the LOAN segment (GHU), calculate interest, apply payment to interest first then principal, update the LOAN segment (REPL), and insert a PAYMENT segment (ISRT).
  • If a loan is paid off, flag the LOAN segment and generate a payoff notice in a separate output file.
  • Commit every 200 payments.
  • Produce a summary report (total payments processed, total interest collected, total principal reduced, number of payoffs).

Provide:

  1. The LOANDB hierarchy and DBD outline.
  2. The PSB with appropriate PROCOPTs.
  3. The payment-processing paragraph with interest calculation.
  4. The payoff detection and notification logic.
  5. The commit and error-handling strategy.

Expected outcome: A production-quality batch processing design with financial calculation logic and complete IMS database operations.