IMS status code GE — segment not found

DL/I could not find a segment that matches the call. It is a normal outcome for many programs, and a bug only when the program did not expect it.

What happened

An IMS program issued a DL/I call such as GU, GN, GNP or ISRT. IMS did not abend. It put GE in the status code field of the DB PCB and returned control. If the program does not test that field, it may carry on with stale data in its I/O area, or stop with its own error message.

Program trace written by the application (illustrative)Illustrative example

MPCUST01 CALL=GU  SEG=CUSTROOT SSA=(CUSTNO  =C0001234) STATUS=GE
MPCUST01 CALL=GN  SEG=ORDER    SSA=(ORDDATE >=20260101) STATUS=GE
MPCUST01 CUSTOMER C0001234 NOT ON FILE - RECORD SKIPPED

What it means

GE tells you that IMS searched and found no segment that satisfies the segment search arguments (SSAs) you supplied. What that means in practice depends on the call:

GU — no segment in the database matches the qualification, for example no root with that key.
GN — no further matching occurrence exists. A program that keeps issuing GN for a child type gets GE once it has read the last one.
GNP — the SSAs for levels above the established parent cannot be satisfied from the current position; IMS leaves position unchanged.
ISRT — at least one parent named in the SSAs does not exist, so IMS has nowhere to insert the new segment. The segment level number in the DB PCB shows how far down the path IMS got.

Do not confuse GE with GB. GB means a GN reached the end of the database (or the end of a DEDB range set with SETR). IBM documents that an unqualified GN, or a qualified GN without a maximum key that returns no data, gives GB rather than GE. A qualified GN with an upper-bound key can return GE even when the segment exists further on, because IMS meets a higher key first.

Typical causes

The key really is not in the database — a new customer, a deleted record, or test data that was never loaded.
The SSA key field is built badly: wrong length, trailing spaces vs low-values, packed vs display, wrong field name.
The relational operator is wrong (= when >= was intended, or the reverse).
The program lost position: a GN or GNP after an earlier call that failed or changed position.
An ISRT of a child segment before the parent was inserted, or with a parent key that does not match.

Symptoms

No abend; the program finishes with missing output, wrong counts, or its own 'not found' message.
If the program ignores the status, the I/O area still holds the previous segment, so you see duplicated or misplaced data.
Some programs treat any non-expected status as fatal and issue a user abend; the GE is then in their diagnostic display.

Where to look

The program's own trace or error display — good programs show call, segment, SSA and status.
The DB PCB mask: status code, segment level number, segment name feedback and key feedback area.
The PSB (PCB SENSEG statements) and DBD for segment names, key fields and lengths.
The job log in SDSF for any user abend the program raised afterwards.

How to diagnose

Record the call function, the SSA text exactly as passed (in hex if needed) and the status code.
Check the key field length and format against the DBD field definition.
Confirm the key really exists, using a query tool or a test GU with the same key.
For GN/GNP, trace the earlier calls: where was position established, and did any of them fail?
For ISRT, read the segment level number in the PCB to see which parent level is missing.

How to fix

If the 'not found' is a legitimate business case, handle it explicitly: test for GE after each call and take the documented path (skip, report, or insert). If it is a bug, correct the SSA (field name, operator, key layout) or the call order, so that parents are inserted before children and position is re-established with a GU before a GN loop.