Articles

COBOL Interview Questions: Data Layout, Packed Decimals, and File Status Errors

Practice COBOL interview questions with byte layouts, COMP-3 decoding, arithmetic limits, and operation-specific file-status failure traces.

A COBOL interview can turn on four bytes. An amount looks correct in a printed report, yet the same record produces a data exception after a copybook change. Or a program keeps processing after a failed read and writes yesterday’s record as though it were today’s. Both failures require more than remembering the names of COBOL divisions.

For COBOL interview questions, establish the byte layout, numeric interpretation and exact failing I/O operation before proposing a fix. PIC describes a value’s shape; USAGE helps determine its representation. Keep the operation and access method beside the status code; the number alone does not identify the repair.

This guide uses IBM Enterprise COBOL for z/OS documentation and original exercises. It does not claim that these prompts came from candidates or that they occur at a particular employer.

What do PIC and USAGE tell you?

Official facts: IBM identifies DISPLAY numeric items as external zoned decimal, COMP-3 or PACKED-DECIMAL as internal decimal, and BINARY, COMP, COMP-4 and COMP-5 as binary usages. The numeric picture symbols include 9, S, V and P, with specific rules for their placement. IBM data categories and PICTURE rules.

For an interview, translate a declaration into three separate answers: logical range, stored bytes and conversion rules. PIC S9(5)V99 describes a signed value with five integer and two fractional digits. The V marks an implied decimal position; it is not a decimal-point character stored between the digits.

Do not count S as another digit. The sign’s physical representation depends on usage and applicable sign clauses. Likewise, a numeric-edited field intended for display is not interchangeable with an arithmetic numeric field simply because both can print a currency amount.

State your compiler and platform assumptions before calculating storage. Binary sizes, compiler options, alignment and external encoding deserve explicit treatment when the record crosses a language or machine boundary. A correct answer for this IBM copybook is not a universal serialization rule for every COBOL implementation.

Decode a thirteen-byte record

Original exercise: a fixed record uses IBM z/OS conventions, single-byte EBCDIC code page 037 for the text fields, no alignment padding, and these declarations:

01 PAYMENT-REC.
   05 ACCOUNT-ID  PIC X(5).
   05 AMOUNT      PIC S9(5)V99 COMP-3.
   05 QUANTITY    PIC 9(3) DISPLAY.
   05 ACTIVE-FLAG PIC X.

The packed field needs four bytes: seven digit nibbles plus one sign nibble occupy eight half-bytes. IBM’s programming guide describes two decimal digits per byte except for the final digit-and-sign byte. For this example, that gives ceil((7 + 1) / 2) = 4. IBM Enterprise COBOL 6.5 Programming Guide.

Field	Zero-based byte offsets	Original example bytes	Interpretation
ACCOUNT-ID	0–4	C1 F1 F0 F4 F2	A1042 under cp037
AMOUNT	5–8	00 12 34 5C	+123.45
QUANTITY	9–11	F0 F0 F7	007 as DISPLAY digits
ACTIVE-FLAG	12	E8	Y under cp037

Say the total aloud: five plus four plus three plus one equals thirteen bytes. The offsets are zero-based, whereas tools and copybook discussions may use one-based positions. Identify which convention you are using before pointing to “position five.”

This layout gives you a useful debugging hypothesis. If a producer changes ACCOUNT-ID from five to six bytes while the receiver keeps the old copybook, every later field begins one byte too early for the receiver. The apparent packed-decimal error may therefore be a record-version mismatch rather than faulty arithmetic.

Ask for the producer copybook, receiver copybook, actual record length and a hex dump of the same failing record. A report printing 123.45 cannot tell you whether the source held packed bytes, DISPLAY digits or a converted binary value.

What does COMP-3 store?

Take 00 12 34 5C apart one nibble at a time. The seven digit positions form 0012345; the final C is the chosen positive sign. Applying the two implied fractional positions gives 123.45. Changing the final nibble to D in this exercise gives -123.45; it does not change the digit sequence or scale.

Official scope: IBM’s sign processing depends on NUMPROC, and preferred signs are not the full set of all accepted representations under every option. The worked decoder uses the deliberately narrow C/D sign convention, rather than asserting that every other sign nibble is universally invalid. IBM programming guide, sign representation.

A packed decimal is not a little-endian binary integer. It is also not an ASCII string that can be decoded by a normal text codec. A transfer utility that translates the entire record as text can damage the packed field while leaving text fields apparently readable.

Original control: replace one digit nibble with A. Our strict teaching decoder rejects it before arithmetic because that position no longer contains a decimal digit. This local check demonstrates an input contract; it does not predict the precise Language Environment exception or compiler-generated path on a mainframe.

When asked how to export the record, propose field-aware conversion: decode text with the agreed code page, decode packed values with the copybook’s scale and sign contract, and emit an explicit external schema. Keep the original bytes available for reconciliation if the conversion rejects a record.

Does REDEFINES convert the bytes?

Official fact: REDEFINES provides another description of the same storage. Changing the description’s usage does not convert the existing contents. IBM’s example shows how the same bytes produce different values under different interpretations. IBM REDEFINES considerations.

Read REDEFINES as another view of the same stored bytes; it does not allocate a converted copy. If you redefine the packed amount as four text characters, those characters do not become “123.45.” If you write through one view, you change what the other view will subsequently see.

A group move deserves the same caution. Official fact: For an alphanumeric group move, the subordinate fields are not individually converted according to their numeric usages. IBM group-move rules. Copying bytes into a structurally different group can preserve the wrong representation beautifully.

Original exercise: the sending group contains the four-byte packed amount. The receiving group expects seven DISPLAY digits. A whole-group copy can preserve every byte and still leave the receiver reading the wrong amount. A field-level numeric move into a suitable receiving numeric item, followed by explicit external formatting where needed, gives you a reviewable conversion boundary.

Check both copybook versions before changing arithmetic: the same address can expose different fields to the two modules.

In an interview, distinguish “the storage overlaps” from “the declarations are equivalent.” If two modules use different copybook versions over the same shared area, agreement on the pointer address does not establish agreement on the fields.

How should arithmetic overflow be handled?

Original exercise: a receiver is PIC S9(3)V99 COMP-3, so its declared magnitude limit is 999.99. Adding 0.01 to 999.99 produces 1000.00, which exceeds that receiver’s range. More bytes in a temporary work field can help intermediate calculation, but the final receiver still needs a deliberate range decision.

A fragment of the intended approach is:

ADD ADJUSTMENT TO TOTAL
    ON SIZE ERROR
        SET REJECT-TRANSACTION TO TRUE
    NOT ON SIZE ERROR
        SET ACCEPT-TRANSACTION TO TRUE
END-ADD

The flags, input validation and program context must be defined in actual code. Rejection should prevent the later file update; setting an error flag while continuing to write is not a complete recovery path.

Official facts: IBM distinguishes final-result size errors from intermediate arithmetic precision and documents overflow and division-by-zero handling. Its guidance also calls out TRAP(ON) for the relevant fixed-point and decimal-overflow behavior. Floating-point exponent overflow has different handling. IBM SIZE ERROR phrases, arithmetic-error handling.

Do not answer an invalid packed-data question only with ON SIZE ERROR. An invalid representation and a mathematically valid result that does not fit the receiver are different failures. Development-time numeric checking can help expose bad data; confirm the active compiler options rather than assuming checks exist in every build. IBM NUMCHECK.

Rounding needs a business rule too. Determine whether a calculation rounds into the final receiver, truncates excess fractional positions or rejects precision loss. State the expected value for a half-cent case before claiming that the result is correct.

What evidence makes a file-status answer useful?

Capture the file name, operation, open mode, organization, access mode, key bytes and status immediately after the operation. A later successful call can replace the evidence you needed. A generic “file error” log is rarely enough to explain whether you should reject one record, stop the job or repair allocation.

Official facts: IBM recommends checking the status key after each VSAM I/O request, especially OPEN and CLOSE. FILE STATUS, INVALID KEY and AT END are among the mechanisms for handling failures; COBOL does not automatically repair a failed operation for you. IBM handling errors in VSAM files.

Use the access layer’s own contract. Enterprise COBOL file-status values are not interchangeable with JCL return codes, Db2 SQLCODEs or CICS RESP values. For indexed or relative file operations, duplicate-key and missing-record conditions have distinct meanings; allocation and attribute mismatches belong to a different diagnosis. IBM Enterprise COBOL 6.5 Migration Guide.

For a nonoptional missing file opened for input, IBM documents status 35. Inconsistent organization, key or record attributes can produce 39. Optional-file handling and VSAMOPENFS affect interpretation, so “all successful opens return 00” is too broad. IBM opening a VSAM file.

Trace a failed read without reusing stale data

Original exercise: the program successfully reads account A1042, then requests account A9999 and receives a not-found outcome. The prior record buffer must not become the new account’s input merely because it still contains plausible fields. Treat the result as unavailable unless the new read succeeded under the applicable contract.

Write the business branch before the recovery action: a required account stops this transaction; an optional lookup may take a documented fallback. Retrying a deterministic missing key with the same bytes does not create a record. First verify that the key was encoded, padded and selected correctly.

For sequential input, reaching the end is a normal loop termination when the contract expects it. Do not emit another output record after AT END. Conversely, an unexpected early end can indicate a truncated input batch, so compare the final accepted, rejected and read counts with the batch’s expected control totals.

The saved Python controls use cp037 text decoding, a strict seven-digit C/D packed decoder and Decimal arithmetic to check the constructed record and receiver boundary. They do not compile the COBOL fragment or exercise VSAM. This separation lets you present useful evidence without pretending that a portable decoder validates a proprietary runtime.

Practice COBOL interview questions with concrete contracts

Question	Practice focus
Parse JSON Accounts into Typed Python Objects and Prepare Features	Validate incoming field types before conversion
Check Whether a String Is a Signed Decimal Number Without Exponent Notation	Separate string syntax from packed representation
Add Two Signed Decimal Character Arrays	Carry sign and scale through arithmetic
Implement precise string-based decimal addition	Preserve exact decimal arithmetic without binary floats
Build a Transaction CSV Cleaning Pipeline	Reject malformed rows and reconcile accepted totals

Start with Check Whether a String Is a Signed Decimal Number Without Exponent Notation, then explain why a valid decimal string still needs an explicit conversion into a packed field.

For your next COBOL interview answer, take one failing record from declared shape to bytes to interpreted value to operation outcome. Explain the branch that prevents a rejected record from producing a successful business update.

Sources and Further Reading

Research checked October 5, 2026. Original exercises are not candidate reports; compiler and file-system execution were not performed.