Dealing with SB37 abend in Endevor processors

Products

• Endevor

Issue/Introduction

During execution of an endevor processor, the executed program might raise a SB37 abend due to lack of space in an output dataset.

 

This article describes how to address this situation

Environment

Release : 18.0

Resolution

First step would be to identify the output dataset where the SB37 abend arose. Doing that requires:

• The processor source statements
• The Endevor execution report written to C1MSGS1 DD
• The JESMSGLG output from the job

The processor source statements are normally displayed as part of C1MSGS1 report. However, this might be disabled onsite by option NO_PROC_PRINT= in the optional features table (ENCOPTBL). In this case, it is possible to force the print of the processor statements for a particular job by adding a DD statement to the JCL:

//EN$PPRT DD SYSOUT=*

Message IEC030I in JESMSGLG mentions the ddname and the dataset name that experienced the SB37 abend. For example:

 10.18.49 JOB09326  IEC030I B37-04,IFG0554A,XUSERID1,NDVRBAT,SYSPRINT,C41F,DWK415, 775
    775             SYS22308.T101754.RA000.XUSERID1.COBLIST.H01

The C1MSGS1 report shows the name of the processor step that raised the SB37 abend. For example:

           10:17:55  C1X0012I  STEP COBOL INVOKING PROGRAM IGYCRCTL
           10:17:55  C1X0013I  PARM=ARCH(12),OPT(0),APOST,C,BUF(12288),,RENT,DATA(31),TRUNC(BIN),
           10:18:49  C1X0011S  STEP COBOL PROGRAM IGYCRCTL ABENDED, CODE=SB37

The processor source statements describe how the dataset is allocated (if allocated by the processor) and how it is used in the abending step. For example:

                     C1G0249I  //INIT  EXEC  PGM=BC1PDSIN,MAXRC=0
                     C1G0249I  //C1INIT01   DD  DSN=&&COBLIST,DISP=(,PASS,DELETE),
                     C1G0249I  //               UNIT=&WRKUNIT,SPACE=(CYL,(100,10),RLSE),
                     C1G0249I  //               DCB=(RECFM=FBA,LRECL=121,BLKSIZE=3630,DSORG=PS)
....
                     C1G0249I  //COBOL    EXEC PGM=IGYCRCTL,COND=(4,LT),MAXRC=4,REGION=0M,
                     C1G0249I  // PARM=(&PARMCBM1,&PARMCBM2)
                     C1G0249I  //STEPLIB  DD DSN=&CBMCOMP,DISP=SHR
                     C1G0249I  //SYSPRINT DD DSN=&&COBLIST,DISP=(OLD,PASS)

Next step is to determine whether the dataset has been allocated with the requested space so that the SB37 abend is legitimate.

If the dataset is a permanent one, this may be done by examining the space allocated to the dataset after the SB37 abend. In the above example, if the dataset has 16 extents and a total of 250 cylinders (a primary extent of 100 cylinders plus 15 10-cylinders secondary extensions), the dataset has reached its maximum requested capacity so the SB37 abend is legitimate.

If the dataset is a temporary one (as in the above example), it will be deleted so it will not be possible to check its allocation after the abend. In this case, it is still possible to temporarily change the processor so that it copies the temporary dataset over a permanent one (with the same DCB attributes and allocated space) to be analyzed after the SB37 abend.

One way or the other, if the dataset has NOT allocated all the space requested before raising the SB37 abend, it means that the SB37 abend is NOT legitimate because EITHER

• The volume was out of space so that the dataset could not allocate all the space requested
• The volume was fragmented so that not enough free contiguous storage could be allocated
• System policies have reduced the amount of space assigned to the dataset

If the abend is a legitimate one, the solution is to increase the space allocated to the dataset

Otherwise this is an issue for the site storage administrator and increasing the space allocated to the dataset will hardly resolve the issue.