Space abend SB37 and Space parameter.

[Rahmat Ali]

Hi,

For a sortout dataset, defined as below, we are constantly getting the SB37:

Code: Select all

//STEP01.SORTOUT DD DSN=xxxx.abcd.CBB.SORTOUT(+1),     
//             DISP=(,CATLG,DELETE),                               
//             DATACLAS=xxxx,                                  
//             SPACE=(4068,(500,500),RLSE),                        
//             VOL=(,,,6)                                          

The DSLIST information for this from a test job is this:

Code: Select all

General Data                           Current Allocation                
 Management class . . : MCGXN1          Allocated blocks  . : 52         
 Storage class  . . . : SCMAY           Allocated extents . : 1          
  Volume serial . . . : F0A1B6 +                                         
  Device type . . . . : 3390                                             
 Data class . . . . . : DCDHDCEX                                         
  Organization  . . . : PS             Current Utilization               
  Record format . . . : FB              Used blocks . . . . : 52         
  Record length . . . : 4068            Used extents  . . . : 1          
  Block size  . . . . : 24408                                            
  1st extent blocks . : 52                                               
  Secondary blocks  . : 500            Dates                             
  Data set name type  : EXTENDED        Creation date . . . : 2014/09/09 
  SMS Compressible. . : NO              Referenced date . . : 2014/09/09 
                                        Expiration date . . : ***None*** 

My question is -- as we've code SPACE=(4068,(500,500),RLSE) - will that play some role in the abend?

And what is the best way to avoid the space abend?

The sort step for which the SORTOUT is shown - uses SORT FIELDS=COPY for 35- SORTIN files.

[nicc]

My question is -- as we've code SPACE=(4068,(500,500),RLSE) - will that play some role in the abend?

Yes

And what is the best way to avoid the space abend?

By specifying enough space.

4068 is your lrecl - I believe you should have your blocksize here but I could be wrong. I usually code in TRK (CYL for really big datasets). Get hold of the card that says how many blocks of the blocksize of your dataet can be held on a track - 2 by the look of it. Determine how many records there are in a block. Divide that into the number of records in your dataset (round up to next integer), divide by 2 to get the number of tracks (round up agian) and divide that by 15 to get the number of cylinders (if required). Code your space requirements using those figures.

[Rahmat Ali]

4068 is LRECL but even if it by chance same as LRECL and coded this way, system will treat it as BLKSIZE and not LRECL, right??

We have a dataclass coded for this sortout so will NOT that take care about the space thing itself?

For example, if this data set has 1,000,000 records - what is the best SPACE I can code for it?

[nicc]

For example, if this data set has 1,000,000 records - what is the best SPACE I can code for it?

I gave you the steps for doing the calculation yourself so do it. As it is stated the question is meaningless as you do net specify the LRECL. Is it 1 million records of 1 byte each (1 million bytes) or 1 million records of 1000 bytes each (1000 million bytes). The latter will take up approximately 1000 times more space.

There are plenty of references on the net - try entering "mvs space calculation" in your search engine.

[Rahmat Ali]

Based on the inputs from you nic and with some reading, I do it this way: on 3390-n device forhalf trac blocking, I can have 55,996/2=27,998 blocksize.

To calculate the most efficient blocksize to used:
bestblocksize = INTEGER(half-track-blocksize/LRECL)*LRECL

In my case the lrecl is 4068, so the best blocksize will be

Integer(27,998/500) is 6

6 multiplied by lrecl(4068) gives 24408, which is the optimum blksize.

So, on a 3390, the best blocksize for a sequential file of record length 4068 is 24408.This will allow 6 records per block, or 12 records per track, or 180 records per cylinder.

Since the volume of records I have is 100,000, cylinders= int(100,000/180 = 555.55) = rounded to 555

So I can allocate the primary space as 555 cylinders. Now the secondary space allocation is 20% of primary space
which in this case is 555 * 0.2 = 111.

So I can code : SPACE=(CYL,(555,111),RLSE). Is this correct?

[nicc]

Yes (without double checking your arithmetic!). If your file is definitely that size. But, I would probably code either 600,100 or 500,100 just to have nice round figures - 15 * 500 is easier than 15 * 555 for mental arithmetic!

[Rahmat Ali]

Thanks. But the confusion still persists.

As I showed in my first post the SPACE in use in production Job is SPACE=(4068,(500,500),RLSE) and it works well most of the time. But recently we got SB37 because the file got 300K records compared to usual 50K. I'm not sure if I code SPACE=(CYL,(600,100),RLSE), will that save us from future SB37 abends?

[Robert Sample]

If you are looking for a permanent and total solution for your SB37 abends, there is no such thing. You can always get SB37 because you don't know how much data will be in the data set. However, changing from block allocation to cylinder allocation gives you much more space so the odds of an SB37 ABEND go down quite a bit.

[Rahmat Ali]

We got another abend for the same job today again and the file has got 3 Million records! For these many records I need

Since the volume of records I have is 3,000,000, cylinders= int(3,000,000/180 = 16666.66) = rounded to 16,666

Is this really true???

[Rahmat Ali]

Thanks Robert. I think I'm already facing that situation... any comments on that, please.

[nicc]

Go see whoever and ask them why so many records and what is the max that you should expect. That amount of "growth" so suddenly seems fishy - has something changed? Have they got the budget for that amount of dasd? You may prefer to shove the dataset onto tape.

[Robert Sample]

A rough way to check: 4000 bytes per record time 3 million records is 12 gigabytes. Since a 3390-3 holds 2.8 GB and has 3,335 cylinders you would need 5 3390 mod 3 devices to hold 12 GB of data and 5 times 3335 is 16675 so the rough check validates your numbers (close enough at least). Note that depending upon which release of z/OS your site runs, you may be limited to 65535 tracks per device (4369 cylinders) and hence will need at least 4 complete disk volumes.

Considering the wide variation in size, I STRONGLY recommend you work with your site storage group to develop a solution. If you are using SMS, for example, the storage pool your data set is assigned to might not have 4-5 empty volumes when you need them. The storage group at your site can help with planning for such events as well as sizing for the most common record count.