Mainframe Path Start learning free
Applied12 min readLesson 3 of 3

Debugging, performance, JSON/XML and maintainable code

When a program fails, the LE messages, the CEEDUMP and the compile listing together tell you exactly which statement failed and what the data looked like. The same discipline that makes code debuggable — clear data types, small paragraphs, shared copybooks and tests — also makes it fast and safe to change.

From abend to failing statement

When a COBOL program hits a program check, LE writes a message to the job log and, depending on run-time options, a CEEDUMP. The workflow is the same every time: read the message, find the program and offset, then use the listing.

Messages from a data exception (illustrative)
CEE3207S The system detected a data exception (System Completion Code=0C7).
         From compile unit PAYCALC at entry point PAYCALC at
         compile unit offset +00000A3E at entry offset +00000A3E
         at address 1A40CA3E.
  1. Note the program (compile unit) name and the offset, here PAYCALC at +A3E.
  2. Open the listing for exactly the version of PAYCALC that ran. A listing from another compile is useless.
  3. Use the LIST or OFFSET section to find the statement covering that offset.
  4. Look at the fields that statement uses. In the CEEDUMP, find them in the program's storage section and check their contents in hex.
  5. Decide whether the code or the data is wrong. For S0C7 it is usually the data.

The CEEDUMP traceback shows the chain of calls that led to the failure, which matters when the abend is in a shared subprogram: you need to know which caller passed the bad data.

Performance-minded coding

COBOL performance problems are usually about doing unnecessary work millions of times, not about clever tricks. Habits that pay off:

JSON and XML in COBOL

Recent Enterprise COBOL releases can convert between COBOL data structures and JSON or XML directly, which is how many batch and CICS programs now feed APIs. Availability of each statement depends on your compiler version.

StatementWhat it does
JSON GENERATEBuilds JSON text from a group item; field names come from the data names unless renamed with NAME
JSON PARSEFills a group item from JSON text, matching names to fields
XML GENERATEBuilds an XML document from a group item
XML PARSEReads XML as a stream of events (start of element, content, end of element) passed to a processing procedure you write

All of these can fail on bad input or a too-small receiving field, so code ON EXCEPTION and check the result. Code pages matter: JSON and XML exchanged with other platforms are normally Unicode, while your COBOL data is usually EBCDIC. See JSON GENERATE / JSON PARSE.

Testing and maintainability

Testing layers for COBOL
Unit
One program or paragraphFiles, DB2 and CICS calls stubbedTools such as zUnit or the open-source COBOL Check
Integration
Several programs and real files or tablesRun in a test environmentFrameworks such as Galasa or site test harnesses
Regression
Compare output before and after a changeFile compare of reports and extractsEssential for compiler upgrades

Common mistakes

Using the wrong listing

Offsets only match the exact compile that produced the running load module. Retrieve the listing for the promoted version, not your latest test compile.

Fixing the callee instead of the caller

A shared routine often fails because a caller passed bad data. Read the traceback to find who called it before changing shared code.

Ignoring code pages in JSON and XML

Text that looks fine on z/OS can be garbled elsewhere. Agree the encoding with the other side and check that conversion happens exactly once.

What you will see at work

Key terms

Check your understanding.
Take this lesson's quiz and save your progress. Free.

Take the lesson quiz
← Language Environment and production compiler optionsBack to Advanced COBOL