IGZ0099C: COBOL runtime internal error

What it means

IGZ messages come from the Enterprise COBOL runtime, the part of Language Environment that supports COBOL programs while they run. Most IGZ messages describe a problem in your program or its data, such as a bad subscript or a file that won't open. IGZ0099C is different. It says the runtime checked one of its own control blocks and found it in a state that shouldn't be possible.

The message carries two pieces of information. The first is a short tag naming the check that failed, such as CLLE-GPCB or GPCB-IPCB. These are names of internal COBOL control blocks. The second is the runtime module that noticed the problem, such as IGZCEV19 or IGZ@PRC. Neither piece is meant for you to interpret. Both are what IBM support needs to match your failure to a known problem.

The C at the end of the message number marks a critical error. Language Environment treats it as a severity 4 condition, the highest level, and the run unit normally ends. In both IBM fixes described below, the message appeared while the environment was ending, after the programs had done their work.

Common causes

• A defect in the COBOL runtime that IBM has already fixed. APAR PH22676, for example, covered COBOL programs with files (FD entries) called from PL/I or another Language Environment language. Termination cleanup ran twice and ended with IGZ0099C in module IGZ@PRC.
• Calling COBOL in a way the runtime doesn't fully expect. APAR PH57918 covered a COBOL 5 or later program whose entry point was found with an assembler LOAD and then passed to CEEPIPI ADD_ENTRY. The runtime raised IGZ0099C in IGZCEV19 when the environment ended. The same programs compiled with COBOL 4.2 or earlier didn't fail.
• A program that writes over storage it doesn't own. A subscript past the end of a table, or a pointer that is wrong, can damage a runtime control block. The runtime then finds the damage later and reports it as an internal error.
• Runtime maintenance that is behind the compiler. Programs built with a newer Enterprise COBOL release can rely on fixes that are only in recent Language Environment PTFs.

How to find the problem

1. Copy the full message text from the job's SYSOUT or the CEEDUMP. You need the internal tag and the module name exactly as printed.
2. Search IBM Support for the message ID together with that tag and module name. Fixes for this message are usually titled with the same words, which makes them easy to match.
3. Note when the message appeared. If it shows up after the program finished its work, look at how the program was called and ended (CEEPIPI, calls from PL/I or C, assembler drivers). If it shows up in the middle of processing, suspect a storage overlay first.
4. Read the traceback in the CEEDUMP to see which of your programs were active, and in what order they were called.
5. Ask your systems programmer which COBOL runtime and Language Environment PTFs are installed. SMP/E can tell them whether the fix for a matching APAR is applied.

How to fix it

• If an APAR matches, have the PTF applied. Until then, use the workaround the APAR gives. For PH57918 that was to pass CEEPIPI ADD_ENTRY the program name instead of an entry point from an assembler LOAD.
• If no APAR matches, open a case with IBM. Send the full message, the CEEDUMP, the compiler release and options for the programs involved, and the runtime maintenance level.
• To rule out a storage overlay, recompile the programs in the failing path with SSRANGE and run the job again in test. A subscript or reference modification out of range then fails with its own message at the statement that caused it.

What it looks like

IGZ0099C Internal error CLLE-GPCB was detected in module IGZCEV19.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your z/OS release.