DFSORT is giving SB37 repeatedly

Question

When I am sorting a Variable length file, the job is abending with SB37 repeatedly. Even when I increased the SPACE parameter values, still the job is abending.

Can anyone please help me in knowing what could be the reason for this..?

Below is the JCL I have been trying.

//STEP01   EXEC PGM=SORT
//SORTIN    DD DSN=<Input DSN>,DISP=SHR   [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
//             DCB=(RECFM=V,LRECL=32756,DSORG=PS)
//SYSIN     DD *
  SORT FIELDS=(1,15,CH,A)
  SUM FIELDS=NONE
/*
//SYSOUT    DD  SYSOUT=*

Answer 1

Since you intend to get rid of trailing blanks and only deal with a maximum data-length of 246, you should do it all in the SORT.

//STEP01   EXEC PGM=SORT
//SORTIN    DD DSN=<Input DSN>,DISP=SHR
//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE)
//SYSIN     DD *
  INREC BUILD=(1,4,5,246)
  SORT FIELDS=(5,246,CH,A)
  SUM FIELDS=NONE
  OUTFIL VLTRIM=C' '
//SYSOUT    DD  SYSOUT=*

Note that I have removed the DCB information from SORTOUT. SORT will take care of that, and you confuse and increase maintenance by including it on SORTOUT (or any DD from OUTFIL) in a SORT step.

In the INREC, a new record is made from the input, which is 250 bytes long (four bytes of RDW and 246 bytes of data). The RDW and data are mentioned separately, so that it is clear to the next person along that you know what you are doing (and perhaps you really want 250 bytes of data anyway?).

In this way, all the data you do not want does not go into the SORT itself, massively reducing your workspace requirements, reducing CPU time, and elapsed time.

Unless your data has an actual key (in position 5 for a length of 11) you are potentially treating non-duplicate data as duplicate. In case you don't have a key, the SORT now sorts on the the data. There is no longer even a remote need to sort on the RDW, as all the RDWs will contain the record-length of 250 (in binary) in the first two bytes due to the BUILD on INREC.

The SUM FIELDS=NONE will now de-duplicate on the 246 bytes of data.

In OUTFIL, VLTRIM=C' ' is used to remove any trailing spaces that happen to be left.

Being concerned that you are unsure of your actual record-lengths, I'd run something like this:

  INREC BUILD=(1,4,1,2) 

  SORT FIELDS=(5,2,BI,A) 

  OUTREC OVERLAY=(5:5,2,BI,EDIT=(IIIIT),10:18X)

  OUTFIL NODETAIL, 
         REMOVECC, 
         HEADER2=('RECLENS PRESENT ON FILE'), 
         SECTIONS=(5,5, 
             TRAILER3=(5,5)), 
         TRAILER1=('MIN/MAX ', 
             MIN=(5,5,ZD,EDIT=(IIIIT)), 
             ' ', 
             MAX=(5,5,ZD,EDIT=(IIIIT))) 

This will produce a simple file, showing you all your record-lengths, and showing the minimum/maximum on the last page.

INREC is used to make records containing the (binary) record-length only. These are then SORTed. OUTREC expands the binary record-length to five printable digits with leading zeros suppressed. OUTFIL reporting features are used: detail lines are suppressed, no print control codes are included, a header is printed at the top of each "page", a control-break is established on the formatted record-length, and the record-length is printed when the break occurs. At the end, the minimum and maximum values are printed.

If you create the input for this with a SORT step consisting of this:

OPTION COPY OUTFIL VLTRIM=C' '

Then you will get a report of the record-lengths of your file once the trailing blanks are ignored, and can be confident (for that example of data) that what you know of the specification matches the data.

Answer 2

Try the below, the SB37 could be because the sort work DDs don't get enought space when allocated dynamically.

/STEP01   EXEC PGM=SORT
//SORTIN    DD DSN=<Input DSN>,DISP=SHR   [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
//             DCB=(RECFM=V,LRECL=32756,DSORG=PS)
//SORTWK01 DD  UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK02 DD  UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK03 DD  UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK04 DD  UNIT=SYSDA,SPACE=(CYL,(500,10))
//SYSIN     DD *
  SORT FIELDS=(1,15,CH,A)
  SUM FIELDS=NONE
/*
//SYSOUT    DD  SYSOUT=*

Answer 3

It has been awhile since I've worked on a mainframe, but if memory serves a B37 can occur for two basic reasons:

1) Disk space for an initial allocation is not available

2) Disk space for a secondary allocation is not available

Your JCL statement:

//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
//             DCB=(RECFM=V,LRECL=32756,DSORG=PS)

Is asking for 1200 initial cylinders. This seems like a lot of space, try something like:

//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(12,240),RLSE),
//             DCB=(RECFM=V,LRECL=32756,DSORG=PS)

This should get you a primary allocation and then 240 cylinders for each of the secondary allocations, if necessary.

Also, look up the exact description of SB37, it should describe when the problem is due to NO space for primary allocation versus no space for a secondary allocation.

Answer 4

Here is the JCL , I modified. And it is working.

Even, here also the record length (LRECL) of input dataset is 32756.

//STEP01   EXEC PGM=SORT
//SORTIN    DD DSN=<Input DSN>,DISP=SHR   [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
//             DCB=(RECFM=V,LRECL=500,DSORG=PS)
//SYSIN     DD *
  SORT FIELDS=(1,15,CH,A)
  SUM FIELDS=NONE
/*
//SYSOUT    DD  SYSOUT=*