JCL

The most common cause of an S422 abend is that you're trying to rerun a job with a dataset with a DISP of (NEW,CATLG) and it already exists in the catalog. Reviewing the console.log or the joblog for the failing job will usually reveal a message which indicates which FILE is the culprit.

This error commonly means that your file is not present in the directories set by the CAS_BATCH_PATH environment variable and/or the directories referenced by the STEPLIB in your JCL job step.

Note: You can set CAS_BATCH_PATH as an environment variable or, more commonly, via the JES Program Path field on the ESCWA JES tab.

To resolve this, follow these steps:

Be sure that a .dll (Windows) or .so (UNIX) file exists in one of the referenced directories.
Note: For files on Linux/UNIX platforms, be sure that the file name before the file extension is in upper case. For example, a program named PROG1 would be in a file named PROG1.so.
Determine if the program is executing from CAS_BATCH_PATH (default) or from STEPLIB(s). For STEPLIB(s), the search order is the directories specified in the STEPLIB(s) first, followed by the directories set by the CAS_BATCH_PATH environment variable. Be sure that you have a file of the proper naming convention present in an appropriate directory.
On Linux/UNIX platforms in particular, be sure that any created .so files are in the proper format. To do this, you can issue the file PROG1.so command, where PROG1.so is changed to be your shared object, and it is in the same directory. The output varies from operating system to operating system, but you can compare against a known good working shared object for any differences.
(Another gotcha is if you've created a 32 bit Server, but 64 bit shared objects or vice versa)
Be sure that your shared objects are of the same bitism as the server; for example, using a 32-bit server with 64-bit shared objects or vice versa.

If your problem is not resolved after following these steps, then it could be that dependant .so or .dll files are not being found, or a similar issue. The easiest way to identify these issues is to add the following COBOL RTS CTF traces:

#pgmsearch
#pgmload
#fsys

And then recreate the problem, The output shows which .so or .dll files were searched for, and the directories accessed to find them. If a missing .so or .dll file is identified, the tracing for the load specifies the file name. For example:

16:36:04.793 MF.RTS 251 3 : 8 "ZZZIWCS.so" "ZZZIWCS.so: undefined symbol: TRCIWWR"
16:36:04.793 MF.RTS 6 1 : 81 16387 "idamjrm" "MVS_JOB_STEP_RESOURCE_MGR"

To find the meaning of the numbers in bold, use a text editor to open the MF.RTS.xml file located in $COBDIR\etc\mftrace\annotations/opt/microfocus/EnterpriseDeveloper\etc\mftrace\annotations. Once open, find the line showing an event ID of the same first number For example:

<Event Id="251" Description="Program Load Error">

Then find the line with the argument case index that matches the second number. For example:

<ArgumentCase Index="0" Value="8" Description="Error (DLL_LOAD_FAIL)"/>

This example shows that a DLL load failed for the shared object ZZZIWCS.so with the reason specified in the original message: undefined symbol: TRCIWWR

A U4038 abend occurs when an unhandled ERROR condition is triggered within an Open PL/I program. This happens with an ON ERROR unit is missing from the program. When an ON ERROR unit is present in the program, the return code is typically 0, meaning that the program handled the abend properly.

Note: Other conditions such as CONVERSION, KEY, and RECORD are escalated to ERROR when no ON unit is present to handle them.

Common causes for this issue are:

Using huge AUTOMATIC variables with a small stack size, or without setting the COBMAINSTACK environment variable.
Note: On Windows platforms, use link.exe to tweak the settings of your cassi.exe to achieve a change; for example, command set it to 8MB:
```
LINK /EDIT /STACK:8000000,8000000 cassi.exe
```
Attempting to access an invalid memory address.
Accessing a FILE that has not been compiled in one routine with the -defext compiler directive

In this problem as originally reported, the code caused a U4038 abend in a JCL job stream when attempting to execute the following statement:

 WRITE FILE(LEGUPT) FROM (LOADREC);

Where LEGUPT and LOADREC were declared as:

DCL LEGUPDT FILE RECORD OUTPUT ENV(VB RECSIZE(804));
 DCL LOADREC CHAR(800) VARYING;

Investigation of the failure via the ONCODE() value in the ON ERROR unit showed an ONCODE() value of 99150, indicating that a RECORD condition had been raised. This did not appear to be possible because only 331 bytes were being written to this file.

Further investigation uncovered three salient facts:

"Overlays" of structures were being used on the LOADREC variable with a FIXED BIN(15) as the first structure element.
The program was compiled with the -bigendian directive.
The LENGTH for the CHAR VARYING variable was manually determined by making assignments into the FIXED BIN(15) fields in the overlay.

A PLI CHAR VARYING consists of a two-byte LL in platform native format (in this case, little endian format) followed by an area that is long enough to contain the longest possible string. Because the overlay redefined the CHAR VARYING and a provided a default for FIXED BIN(xx) data types of BIGENDIAN, the assignment of 331 resulted in a length of 19201 (x'4B01') being passed into the PL/I Runtime System. This immediately triggered an ON RECORD condition because 19201 bytes cannot be written to a file defined as having a maximum LRECL of 804.

Solution: Add the NATIVE attribute to the structures used to overlay the CHAR VARYING, which makes them LITTLEENDIAN. For example:

DCL 1 SCARLEG UNALIGNED BASED(P_SCARLEG),                             
     2 RECLEN  FIXED BIN(15) NATIVE,  /* RECORD LENGTH            */   
              ...
              ...

DCL 1 OTEXT  UNALIGNED  BASED(P_TEXT),                               
        2 TEXTLEN      FIXED BIN(15) NATIVE,  
            ...
            ...

If you experience this form of message the "eyecatcher" that should help you identify the problem is the "FILE=" w/o any other information. This is typically indicative of a PL/I Program which is OPEN(ing), READ(ing), or WRITE(ing) to a file from a proc where the code was not compiled with -DEFEXT. (SYSPRINT, SYSIN, SYSOUT are special FILES which do not require the source to be compiled with -defext - it does not hurt if -defext is used when accessing SYSPRINT,SYSIN,SYSOUT).

Below are examples a valid UNDEFINEDFILE message when compiled with -defext vs the same example when compiled w/o -defext. (The customer's failure to properly compile with -defext can manifest itself in a wide variety of issues such as traps, etc as the file control blocks are not allocated and the memory being used is undefined)

Sample Joblog snippet with valid UNDEFINEDFILE message: (-defext was used)

 *MSG ONCODE 99140: The UNDEFINEDFILE condition was raised because a 
DD statement was not used in (FILE=MYFILE)

Invalid UNDEFINEDFILE message: (-defext was not used)

*MSG ONCODE 99140: The UNDEFINEDFILE condition was raised because a 
DD statement was not used in (FILE=)