System abend

S106: Program fetch failed

An S106 abend means z/OS found the program in a library but couldn't load it into storage. Reason 0C means there wasn't enough storage. Reason 0F means an I/O error while reading the module, often because the library changed while the job was using it.

Also written as 106, S106-0C, S106-0F, abend 106, system abend 106, 106-0C, 106-0F.

What it means

When a job step starts a program, or a program calls another one with a dynamic CALL, LINK, LOAD or XCTL, z/OS does two things. It finds the module in a library, and then program fetch reads it into storage and adjusts its addresses for where it landed. S106 means the first part worked and the second didn't. If the module can't be found at all, the abend is S806 instead.

The reason code appears on the IEF450I line and in the symptom dump. These are the ones you'll see most.

  • 106-0C means fetch couldn't get the storage it needed. Usually there was no room left in the region for the module itself. Less often it was the small control blocks fetch builds for the I/O, and a fetch reason code in register 4 tells the two apart.
  • 106-0F means an I/O error that fetch couldn't recover from while reading the module. Most often the library changed while the job was using it. It was compressed or went into a new extent, so the directory information the job holds no longer matches what is on disk.
  • 106-0D means fetch found a record type it doesn't recognize in the module, and 106-0E means it found an address that points somewhere it shouldn't. Usually the module is damaged, or it wasn't built or copied correctly. One exception is 106-0E with fetch reason 20, which typically means another job extended the library while this job had it open.

Common causes

  • The REGION for the step is too small for a large program, or for all the modules the program loads (106-0C).
  • Someone compressed a load library with IEBCOPY while jobs were running programs from it (106-0F).
  • A link list library took a new extent or was compressed, and LLA wasn't refreshed, so the system still works from the old directory information.
  • The load module was copied with a utility that doesn't understand load modules, such as IEBGENER, which breaks its internal structure.
  • A real I/O error on the disk that holds the library.

How to find the problem

  1. Get the reason code from IEF450I or the IEA995I symptom dump.
  2. Look for fetch messages in the job log. IEW4000I says a fetch failed because there wasn't enough storage. Other IEW40xxI messages, such as IEW4005I, name the module, the DD name it came from and a more detailed fetch reason.
  3. Look for CSV031I as well. It says the system couldn't read the library a module was in, and gives a return code, a reason code and the DD name.
  4. For 106-0F, find out whether anyone compressed, copied into or extended the library around the time of the failure.
  5. For 106-0C, check the REGION on the JOB or EXEC statement. Steps that load several large modules often need more than the site default.

How to fix it

  • For 106-0C, raise REGION on the EXEC or JOB statement, or code REGION=0M if your site allows it. If the region is already large, look for a program that obtains storage and never frees it. If the fetch reason shows the shortage was in fetch's own control blocks rather than the module, IBM suggests trying a smaller REGION, which leaves more room for system storage below the line.
  • For 106-0F, rerun the job. If the library changed under it, the rerun usually works. To stop it coming back, don't compress load libraries while they are in use, or move them to PDSEs, which never need compressing.
  • If the library is managed by LLA, ask a systems programmer to refresh LLA after changes, with F LLA,REFRESH or an UPDATE. A link list library that has gone into new extents needs a new link list set to be activated, or an IPL, before programs in those extents can be fetched.
  • If the module is damaged, link-edit it again, or copy it with IEBCOPY or DFSMSdss, which handle load modules correctly.

What it looks like

IEW4000I FETCH FOR MODULE INVCALC FROM DDNAME STEPLIB FAILED BECAUSE INSUFFICIENT STORAGE WAS AVAILABLE.
IEA995I SYMPTOM DUMP OUTPUT
  SYSTEM COMPLETION CODE=106  REASON CODE=0000000C
IEF450I INVRUN02 STEP030 - ABEND=S106 U0000 REASON=0000000C

Questions

What is the difference between S106 and S806?

S806 means the program wasn't found in any library the system searched. S106 means it was found but couldn't be loaded, because of storage, a damaged module, or a library that changed under the job.

Why did S106-0F go away when we reran the job?

Because the library had changed while the first run was using it. The rerun read the current directory and found the module where it really is now.

Can REGION cause an S106?

Yes, that is reason 0C. The program, or a module it loads, didn't fit in the storage left in the region. Raising REGION usually fixes it.