IMS status code

IMS status AC: Hierarchic error in SSA

IMS status code AC means one of the call's SSAs is wrong for the PCB's hierarchy. The segment name isn't in the PCB, the SSAs aren't in hierarchic order, or two SSAs are for the same level.

Other names for this code

Also written as status code AC, IMS AC, DL/I status AC, AC status code, hierarchic error SSA.

What it means

A DL/I call can carry one SSA per level of the hierarchy, from the root down to the segment it wants. IMS checks the SSAs against the database PCB before it does anything. If an SSA names a segment the PCB doesn't know, or the SSAs don't follow the parent-to-child order of the hierarchy, or two SSAs describe the same level, IMS rejects the call with AC. It's a programming error. IMS rejects the call while it checks the SSAs, before it reads any segment.

AC can come back on any call that takes SSAs. That covers GU, GN and GNP and their hold forms, ISRT, REPL, DLET, and the Fast Path FLD call. Programs that use EXEC DLI get it for the same mistakes in the SEGMENT option of a GET or ISRT command. IBM lists a few rarer cases too. A GUR call returns AC if its SSA goes past the PSB or DBD level or carries a command code. A STAT call with an invalid statistics function returns AC. A Fast Path FLD call that tries to change a field used by a DEDB secondary index also gets AC.

Common causes

  • The segment name in the SSA is misspelled, or isn't padded with blanks to 8 bytes.
  • The segment exists in the DBD, but the PSB doesn't include it in this PCB with a SENSEG statement, so the program can't name it.
  • The SSAs are in the wrong order. For example, the program passes the ITEM SSA before the ORDER SSA.
  • Two SSAs name segments at the same level, usually because an SSA array was reused and an old entry was left in the parameter list.
  • The program uses the wrong PCB. If the PCB order in the entry statement doesn't match the PSB, SSAs written for one database reach the PCB for another.
  • Less often, a GUR call has an SSA with a command code or one that goes past the PSB level, or a STAT call has a bad function.

How to find the problem

  1. Display the call's parameters just before the call. Note the function, the PCB, and every SSA in the order passed.
  2. Check each SSA's segment name against the SENSEG statements for that PCB in the PSB source.
  3. Check the order of the SSAs against the hierarchy in the DBD. Each SSA should be for a segment below the one named in the SSA before it, on the same path. Leaving out a level is allowed.
  4. Check the DBD name in the PCB the call used. If it isn't the database the SSAs were written for, the PCB order is wrong.
  5. Look at the call before the failing one. IMS rejects an AC call before it reads anything, so the earlier call shows where the program was.

How to fix it

  • Correct the segment name and pad it to 8 bytes with blanks.
  • Add the segment to the PCB with a SENSEG statement, then run PSBGEN and ACBGEN for online use.
  • Pass the SSAs in hierarchic order, one per level, and pass only the ones the call needs.
  • Make the PCB list in the program's entry statement match the order in the PSB.
  • For STAT, use a valid statistics function. For GUR, remove command codes and keep the SSA within the PSB.

IBM documentation

IBM documentation: status AC. Use the documentation for your installed release.

Report a correction to WND Software.

Questions

Does AC change my position in the database?

Normally not. IMS rejects the call while it checks the SSAs, before it reads any segment. If the next call depends on position, reposition with a GU to be safe.

The segment is in the DBD. Why do I still get AC?

The program sees only the segments its PCB is sensitive to. If the PSB has no SENSEG for that segment in this PCB, IMS treats the name as unknown.

What is the difference between AC and AK?

AC is about the segment name or the order of the SSAs. AK means the segment is fine, but the field name in the qualification isn't valid for it.