IMS status GE: Segment not found

What it means

Every DL/I call sets a two-byte status code in the database PCB. GE is the not-found code. The call was valid and IMS ran it, but there was no segment occurrence that met the search arguments. Most programs expect GE and test for it, much as a Db2 program tests for SQLCODE +100.

GU and GHU return GE when no segment matches the SSAs. GNP and GHNP return GE when there are no more matching segments under the established parent, which is how a GNP loop knows it has finished with one parent. GN and GHN return GE for a qualified call that can't be satisfied. An unqualified GN that runs off the end of the database gets GB instead, and IBM's GB entry lists the cases where a GN gets GE rather than GB. ISRT returns GE when IMS can't find a parent segment named in the SSAs, so it has nowhere to put the new segment. Programs that use EXEC DLI get the same condition on GET and ISRT commands.

GE is a normal condition when the program is asking whether something exists. It's an error only when the program was sure the segment was there. Don't assume your position in the database is unchanged after a GE. If the next call depends on position, set it again with a GU.

Common causes

• The key really isn't in the database. The customer, account or order was never added, or it was deleted.
• The SSA holds the wrong value. The comparative value must be exactly as long as the field in the DBD, so a key moved in without leading zeros, with trailing junk, or as display digits for a packed field won't match anything.
• A GNP loop has read every child under the current parent. This is the normal end of the loop, not a failure.
• An ISRT names a parent key that doesn't exist, so IMS can't place the new segment under it.
• The SSA still holds a value from the previous pass through a loop, or it was built for a different segment.
• The program runs against a test copy of the database that lacks the data production has.
• Restart logic after a checkpoint repositions with a GU on a key that has since been deleted, or that was the last occurrence of its type.

How to find the problem

1. Display the database PCB right after the call. The segment level and segment name feedback fields show how far down the hierarchy DL/I got, and the key feedback area shows the concatenated key it reached. Compare that with the SSA that failed.
2. Display every SSA in hex just before the call. Check the segment name, the field name, the relational operator and the value. The value must match the field's length and format in the DBD.
3. For an ISRT, issue a GU with only the parent SSAs. If that GU also gets GE, the parent is missing.
4. Check the data itself with your shop's IMS browse or edit tool, using the key from the SSA.
5. If the program works in production but not in test, compare the test database contents and the PSB and DBD the test job uses.

How to fix it

• Treat GE as an expected result. Test the status code after every call and branch on spaces, GE and anything else separately.
• Build SSA values with the exact length and data type of the DBD field. Pad numeric keys with leading zeros and character keys with trailing blanks.
• End a GNP loop on GE and move on to the next parent with a GN or GU.
• Before an ISRT, make sure each parent exists, or insert the parents first.
• After an unexpected GE in a sequential pass, set position again with a GU before carrying on.
• In restart logic, reposition on a key you know still exists, or handle GE as "start from the next key".

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