CEE3501S: The module was not found
CEE3501S means Language Environment tried to load a module that a program asked for, such as a dynamically called subprogram or a DLL, and couldn't find it in the libraries searched. The message names the module, and the step usually ends with an S806 or a U4038 abend.
Other names for this code
Also written as CEE3501, CEE3501S module not found, CEE3501S S806, CEE3501S U4038, The module was not found, CEE3501S libpython.
What it means
Many programs load other code while they run. A COBOL program does a dynamic CALL, a C or C++ program loads a DLL, and a program in z/OS UNIX loads a shared library such as a .so file. Language Environment asks the system to find and load that module. If the load fails, it writes CEE3501S with the module name.
The S suffix marks a severe error. If the program has nothing in place to handle the failure, the thread ends. Depending on the environment and how the load failed, the step ends with a system abend 806 (module not found) or with user abend U4038. When the system load fails, CSV003I in the job log usually names the module too.
Where the system looks depends on the environment. Batch jobs search STEPLIB or JOBLIB, then the LPA and the link list. CICS regions load programs from the DFHRPL concatenation. Programs in z/OS UNIX look for .so files in the directories in LIBPATH.
Look at the module name in the message first. A real name points to a search-path problem. A name made of odd characters means the program passed garbage as the name. IBM APAR PH08337 describes an Enterprise COBOL 6.1 compiler defect that did exactly that in programs with CALL statements and declaratives or secondary entry points.
Common causes
- The library that holds the module is missing from STEPLIB or JOBLIB in batch, or from DFHRPL in CICS.
- The module name is misspelled, or the variable used for a dynamic CALL holds the wrong name.
- The variable holding the module name was overwritten or never set, so the message shows a garbled name.
- In CICS, a product feature needs runtime DLLs in DFHRPL. IBM's CICS web services security note lists IXM4C54, IOSTREAM and C128N, from the XML toolkit, C++ runtime and SCEERUN libraries.
- A z/OS UNIX program can't find a shared library because LIBPATH doesn't include its directory, as seen with libpython3.9.so in Python-based tools.
- Software built for a newer runtime level asks for a module the system doesn't have. Broadcom documents this for Zowe with Node.js 18, where CEE3501S named module CRTEQCXS.
How to find the problem
- Read the module name in the CEE3501S message in SYSOUT, CEEMSG or the CICS CESE queue.
- Look for CSV003I and an S806 in the JES job log. They confirm which name the system searched for.
- Check the STEPLIB, JOBLIB or DFHRPL concatenation in the JCL listing, and check that the module is a member of one of those libraries.
- If the name is garbled, look at the CALL statement and the field that holds the name, and check whether a storage overlay or compiler defect is involved.
- For z/OS UNIX, display LIBPATH in the environment the program runs in and check that the library is in one of those directories.
How to fix it
- Add the library that holds the module to STEPLIB, JOBLIB or DFHRPL, or copy the module into a library already searched.
- Correct the module name in the program or in the data that supplies it.
- Code ON EXCEPTION on COBOL dynamic CALL statements so the program can report a missing module and end cleanly.
- For a garbled name from Enterprise COBOL 6.1, check whether the PTF for APAR PH08337 is installed.
- For z/OS UNIX, add the library's directory to LIBPATH, or use the software level the product supports.
What it looks like
CSV003I REQUESTED MODULE PAYCALC2 NOT FOUND CEE3501S The module PAYCALC2 was not found. IEF450I PAYRUN01 STEP020 - ABEND=S806 U0000 REASON=00000004
IBM documentation
IBM documentation: CEE3501S. Use the documentation for your installed release.
Related codes
Questions
What is the difference between CEE3501S and S806?
S806 is the system abend for a load module that wasn't found. CEE3501S is the Language Environment message that names the module it tried to load. You often see both for the same failure.
Why does CEE3501S show a strange module name?
The program passed a name that wasn't set or was overwritten. Check the field used on the CALL, and for Enterprise COBOL 6.1, the fix for APAR PH08337.
Where does CICS look for the module?
In the DFHRPL concatenation of the CICS region's JCL, and in any dynamic program libraries the region has defined.