In Mainframe, while working on batch jobs, you may get errors. Batch jobs need JCL to submit it. I have added here JCL errors and resolutions for ready use.
Here’re frequently occur JCL errors and their resolutions.
1). Error in JCL due to blank in the parameter
If this step is executed:
+---------------------------------------------------------------+ | //STEP1 EXEC PGM=CREATE | | //OUT DD DSN=&&TEMP,DISP=(,PASS), | | // SPACE=(TRK,(10,5),RLSE),UNIT=SYSDA,?VOL=SER=PACK12, | | // DCB=(RECFM=FB,LRECL=100,BLKSIZE=6000) | +--------------------------------------------------------------+
The data set may not be written on the volume intended. JCL assumes that anything following a blank in the parameter field is a comment and ignores the item.
// SPACE=(TRK,(10,5),RLSE),UNIT=SYSDA, VOL=SER=PACK12,
Blank here tells JCL that what follows on the line is a comment. The system ignores the VOL=SER=PACK12. You wouldn’t get a JCLerror, and you might not notice that the data set was not written on the volume you wanted. The system sees the statement as:
You can’t end a JCL statement with a comma. A comma indicates a continua-tion, and so you get a JCL error.
If a JCL syntax error is encountered anywhere in the JCL, none of the steps in the job is executed. When you have a JCL error, the following message is printed on the first page of your output:
JOB FAILED – JCL ERROR
2). Space errors in JCL
Some errors occur during the execution of a job. If you request more disk space than is available, the current step isn’t executed and you get the JCL ERROR message, but previous steps could have executed.
Here is some JCL:
+----------------------------------------------+ | //RUN#1 JOB (2215,15),'TEST',CLASS=A,TIME=1 | | //STEP1 EXEC PGM=CREATE | | //OUT DD DSN=Y2222.TEST.DATA,DISP=(NEW,CATLG), | | // UNIT=SYSDA,VOL=SER=PACK10,SPACE=(TRK,(10,5)) | | //STEP2 EXEC PGM=COMPUTE | | //OUT DD DSN=Y2222.TEST.DATA,DISP=OLD | +-------------------------------------------------+
If STEP2 ABENDs because you didn’t allow enough TIME on the JOB statement, and you resubmit the job as is, you will get a JCL error. The following occurs:
- STEP1 creates the data set and catalogs it.
- STEP2 ABENDs, but the data set is not deleted.
If you resubmit the job, STEP1 tries to allocate the data set again, but it already exists. You get this JCL error message:
JOB FAILED - JCL ERROR
ALLOC - DUPLICATE NAME ON DIRECT ACCESS VOLUME
There are, of course, many solutions to the problem:
- Change the DISP in STEP1 to DISP=(NEW,PASS). Then if STEP2 ABENDs, the data set is deleted.
- Change the DISP in STEP2 to DISP=(OLD,KEEP,DELETE) to delete the
data set if the step ABENDs.
- Change the DISP in STEP1 to DISP=(OLD,PASS) when you rerun.
- Don’t execute STEP1 when you rerun.
3). And so on. Duplicate data set names will always be a problem. The following is typical:
- You submit a job and a step ABENDs.
- You correct what was wrong but forget that a data set was created,
and the job fails because of duplicate names on the volume.
- You change your JCL to solve the duplicate name problem but make a
mistake in changing the JCL and get a JCL error.
This will be a constant frustration and you will just have to be careful. The compilers, linkage editors, utilities, and most programs issue a condition code at the end of each step. You should examine this code in your output listing for each step to determine if errors occurred. A typical message for a step will read:
stepname - STEP WAS EXECUTED - COND CODE n
By convention, the values for the condition codes (COND CODE n) have the following meanings:
> 0 No errors or warnings. > 4 Warnings, but execution should be successful. > 8 Errors; execution likely to fail. > 12 Severe errors; execution of a compiled or link edited program impossible. > 16 Most severe error; execution cannot continue. The compiler or link editor stops processing.
But if a step ABENDs, you get this message at the start of the job:
IEF450I jobname stepname – ABEND Snnn U0000
Then you don’t get a condition code for the step that ABENDs. You get this message instead:
IEF472I jobname stepname – COMPLETION CODE – SYSTEM=nnn USER=0000
The nnn is a number that identifies the cause of the error.
The U0000 is a user ABEND code that appears if the program, rather than the system, issued an ABEND instruction. Programs can be written to do this, but few are.
4). Let’s dissect an error message:
IEF450I jobname stepname – ABEND Snnn U0000
IEF450I: The error message number. You can look this up in the VS2
System Messages manual to get an explanation of the error message.
//stepname EXEC ...
Snnn: The system error number. This is what you really want. You can look this number up in yet another manual, VS2 System Codes.
U0000: The user ABEND code, which is rare.
Let’s look at the most common system codes, starting with:
- 222 – Means the computer operator cancelled your job. A reason for this code might be that you asked for a tape volume that can’t be found.
- 322 – Means you needed more CPU time than requested for your job. You must increase the TIME parameter, assuming your job did not go into an endless loop.
- 804, – Not enough virtual storage was provided for a job step. You 80A must increase the REGION parameter.
- 806 – System couldn’t find the program you requested. You probably named a wrong program with the PGM parameter on the EXEC
5). For each of the codes below, you must allocate more space.
- B14 – Not enough directory space in partitioned data set.
- B37 – More space needed and all 16 extents used for a sequential dataset.
- D37 – More space needed and no secondary allocation is specified.
- E37 – More space needed and all 16 extents used for a partitioned dataset.
Other System common codes:
013 – Invalid open. Means that the system tried to open a data set, but couldn’t because something is wrong. Typical causes are:
- You named a partitioned data set member that doesn’t exist.
- The BLKSIZE is not a multiple of the LRECL (or some other inconsistency in the DCB sub-parameters).
- You tried to open the printer as a partitioned data set.
- The data set was already open.
0C1 – Invalid instructions. This could be caused by a wild branch into the data area of a program or clobbering the instruction part of your program by overwriting it with data.
0C7 – Invalid data. Usually caused by using a data area that was not initialized, by invalid alignment of data, or by packed decimal data being clobbered.
There are two manuals you’ll need to use to look up error messages:
VS2 System Codes. This manual describes just the completion codes issued by the operating system. (It has only about 150 pages.)
VS2 System Messages. This manual describes the error messages, such as IEA153I or IHJ007I. It has close to 1000 pages.
The best approach is to learn to recognise a few of the most common and look up the rest.
One final item. If you wish a hexadecimal storage dump in the event a job step ABENDs, you include one of the three following DD statements:
//SYSUDUMP DD SYSOUT=A
(Prints the program area, contents of registers, and gives a traceback of subroutines called.)
//SYSABEND DD SYSOUT=A
(Same as SYSUDUMP, but also prints the system nucleus. Don’t use unless you need the nucleus–and you almost never will. Produces a lot of paper.)
//SYSMDUMP DD DISP=(NEW,CATLG),DSN=...
(Same information as SYSABEND, but dump isn’t formatted for printing. Used to store dumps in a data set to be processed by an application program.)