I am having problem with SB37. I need some help as this is happening in our production and as a support it has been very bad week for me.
I have a job where in step S020, the file is getting created with TRK(10,5) and in S050, the file is being sorted out to a &&TEMP dataset with space allocation of TRK(10,5). It abends in S050 with SB37. I changed to TRK(50,20) and rerun the job and ended okay. This was 1st and 2nd day.
Later I change to CYL(5,2) in both step and it abend again in S050 with SB37 again. To solve it, I change to CYL(10,5) and it ended okay on 3rd day.
There are a lot of extents happening when I use TRK(10,5) initially which prompt me to change to CYL(5,2) thinking it is big enough already after discussng with seniors.
The time I allocated TRK(10,5) the dataset actually took 1701 tracks as the final allocation. The number of records are over 340,000. LRECL is 214, BLOCKSIZE is 21400.
The time I allocated CYL(5,2) the dataset actually took 114 cylinders as the final allocation. The number of records are over 340,000. LRECL is 214, BLOCKSIZE is 21400.
Problem is why it is happening like that. The JCL having sortwork also, is it because sort work not enough or the space allocation in the primary and secondary not enough.
Everyone suggesting different solutions, some telling maybe the time the job running there are many other job running as well, no space in volumes. So maybe rerun after sometime without changing anything might solve the problem also.
Seeing the allocation, I feel, we should allocation bigger primary and secondary, but on day 1 & day 2 when it work with TRK(50,20) and on day 3 with CYL(5,2) it doesn't work. I need to increase to CYL(10,5).
I also put the same space allocation in step S020 and S050 thinking since we are creating with CYL(5,2) while sorting out it should be fine with CYL(5,2). But S020 okay, and S050 abend. Is it coz &&TEMP dataset space allocation is different? Need larger space?
Joined: 20 Aug 2007 Posts: 1 Location: Angeles City
hi shanthi,
I've been working with some space allocation issues the past few days.
you can use this computation to know the space allocation used:
(number of records * LRECL of dataset) / 849960 = number of cylinders used
where: 849960 is the number of cylinders
Example:
Records : 340000
LRECL : 214
Number of cylinders used : approximately 86 cylinders
Now, you know the number of cylinders used, you may now know the space allocation you need in CYL,(1?,2?).
1? is the primary allocation and 2? is the secondary allocation.
Note that the secondary allocation is *15 at minimum then add the primary allocation and that will give you the total allocation you're going to use.
Example: CYL,(20,10)
(10*15) + 20 = 170 cylinders
The 170 cylinders would give you an allowance for future growth of the records, but it doesn't mean that it might not occur again. What i'm trying to suggest is atleast a long term fix.
Please let me know if i gave you incorrect information.
Thanx a lot for your reply. Problem is my seniors are not receptive to the idea of increasing the size, they are worried if we allocate the primary too big, it will abend also if cant find the necessary space. But I found somewhere, if for eg: we allocate CYL(150,50), if the max it can allocate is 100 for primary, then it will allocate that much and wont abend with SB37.
But am receptive to changes and for my info, would like to learn the correct way to estimate the space.
I dont get this part :
where: 849960 is the number of cylinders
is this fixed by system or nething like that?
I also read somewhere that the maximum extent it can give for secondary is 16 and not 15 as you mention here.
Can I use the Current Allocation (Allocated cylinders + Allocated extents ) info from the input dataset (which when I type S at the left side or use file aid I can see) to estimate the space needed? Coz as I mention before in step S020, the input to S050 is created with allocation CYL(5,2) but it extent until the following :
03.28.38 JOB17820 SVM4874I INCREASED SPACE FROM 2 CYLS TO 18
Which when I calc (2*16) + 5 = 37 cyclinders, but the info in file aid is showing as 114 cyl and 20 extents.
Last Friday, I have allocate at S020 as CYL(5,2) and at S050 as CYL(10,5) and luckily the abend didn't happen again.
In S020 :
03.28.31 JOB05514 SVM4874I INCREASED SPACE FROM 2 CYLS TO 18
In S050 :
03.33.03 JOB05514 SVM4874I INCREASED SPACE FROM 5 CYLS TO 25
This is the number of records :
WER054I RCD IN 341413, OUT 341413
If I use the following way :
Example: CYL,(10,5)
(5*5) + 10 = 35 cylinders but in file aid showing allocated cylinders as 114. I dont seem to get it how?
Thank you for any replies.
Christopher Dayrit wrote:
hi shanthi,
I've been working with some space allocation issues the past few days.
you can use this computation to know the space allocation used:
(number of records * LRECL of dataset) / 849960 = number of cylinders used
where: 849960 is the number of cylinders
Example:
Records : 340000
LRECL : 214
Number of cylinders used : approximately 86 cylinders
Now, you know the number of cylinders used, you may now know the space allocation you need in CYL,(1?,2?).
1? is the primary allocation and 2? is the secondary allocation.
Note that the secondary allocation is *15 at minimum then add the primary allocation and that will give you the total allocation you're going to use.
Example: CYL,(20,10)
(10*15) + 20 = 170 cylinders
The 170 cylinders would give you an allowance for future growth of the records, but it doesn't mean that it might not occur again. What i'm trying to suggest is atleast a long term fix.
Please let me know if i gave you incorrect information.
As rightly said, we can quote as many cylinders as we may think would be optimal, but MVS allocates only to available extent. Also it is a good practice to involve RLSE parameter as this would really be beneficial to our system's space usage.
First of all, the SB37 has 3 Return-Codes, like SB37-Rc.
These are 04/08/0C. So have a closer look at your abend and the meaning of the Rc.
Also, when defining a huge primary space, keep in mind, that this space is needed in one piece. And if the file gets a multiple-volume-file, the next volume also needs this prim-space at one piece on the disk.
Don't worry about some Seniors. mostly these ones are very curlish with space-allocs. As prakash271082 wrote, use the RLSE parameter to release not used space.
Also you have to checkout, that there are disks, which can provide you with the the needed prim-space during runtime. Some companies always have some dedicated disks for huge temporary files.
And yes, normaly the max extent for secondary is 15.
When you have a good idea about how many tracks/cylinders/blocks will
be required by the output dataset, and it will be consistent from day
to day, then use a large primary, and small secondary allocation. When
you have no control over the number of records, use small primary and
large secondary allocations. This will reduce the chances of ABENDS. For
example, SPACE=(CYL,(10,1)) initially reserves 10 cylinders, with a
maximum possible allocation of 25 cylinders. Specifying SPACE=(CYL,(1,3)) allows for a maximum of 46 cylinders, while not occupying space unless it's necessary.
Your Example: CYL,(10,5)
So, this means normaly 10cyl primary and 5cyl*15 (75) secondary on disk-one and if multi-volume, then next 10 cyls at disk-two and perhaps also some extents.
Thank you for all the reply. I have increased the space to CYL(20,10) as of now. The problem not happening anymore and I can see the number of extents has reduced. It is encouraged for us to use CYL compared to TRK for all the JCLs and PROCs, since I am changing this particular step, I have also change all other steps to use CYL. But I don't really see much improvement on the execution time. Maybe there are some other stuff which impacts, like how many other jobs are running concurrently.
As for one of the question here, in our joblog this is what I can see when the abend happens :
03.34.12 JOB17820 SVM4000I <jobname>, P010.S050, SORTOUT, ATTEMPTING
SPACVOLA FOR SYS07250.T032707.RA000.<jobname>.<ds name>.H01,WH1020, 16
03.34.12 JOB17820 SVM4500I RECOVERY TERMINATED: NO VOLUMES AVAILABLE
FOR SPACVOLA
03.34.12 JOB17820 IEC030I B37-04,IFG0554A,<jobname>,S050,SORTOUT,9D1A,
WH1020,SYS07250.T032707.RA000.<jobname>.<ds name>.H01,
03.34.12 JOB17820 +WER999A PCCI076D,P010 ,S050 - UNSUCCESSFUL
SORT B37 S REASON=00000004
"Also, when defining a huge primary space, keep in mind, that this space is needed in one piece. And if the file gets a multiple-volume-file, the next volume also needs this prim-space at one piece on the disk. "
I was told if the space not available, it will just allocate wat is available when it is primary. For secondary, it will keep extent until it satisfies. Our system has been changed to SMS managed recently.
Yes, we are using RLSE.
Regarding the maximum extent, some docs telling it is 16, some telling 15. Please clarify.
I already find out the reason behind 849960.
1 CYL = 15 tracks
1 track = 56,665 bytes
So 1 CYL = 849,975 bytes
I guess it depends on the system again whether its 849,960 or 849,975.
This is yesterday's situation :
Data Set Information
Command ===>
Data Set Name . . . . : <ds name>
General Data Current Allocation
Management class . . : STNDRD Allocated cylinders : 115
Storage class . . . : STNDRD Allocated extents . : 10
Volume serial . . . : PH10FL
Device type . . . . : 3390
Data class . . . . . : STNDRD Current Utilization
Organization . . . : PS Used cylinders . . : 115
Record format . . . : FB Used extents . . . : 10
Record length . . . : 214
Block size . . . . : 21400
1st extent cylinders: 20
Secondary cylinders : 10
Data set name type : SMS Compressible : NO
Creation date . . . : 2007/09/13 Referenced date . . : 2007/09/13
Expiration date . . : ***None***
This one with CYL(20,10) at S020 when the file was created.
02.41.15 JOB05581 SVM4000I <jobname>, S020, <ds name>, ATTEMPTING SPACSECI FOR PCC
02.41.15 JOB05581 SVM4874I INCREASED SPACE FROM 10 CYLS TO 20
02.52.03 JOB05581 SVM4000I <jobname>, S020, <ds name>, ATTEMPTING SPACSECI FOR PCC
02.52.03 JOB05581 SVM4874I INCREASED SPACE FROM 10 CYLS TO 30
This one with CYL(20,10) at S050 when the file is sort out.
02.55.27 JOB05581 SVM4000I <job name>, S050, <temp ds name>, ATTEMPTING SPACSECI FOR SY
02.55.27 JOB05581 SVM4874I INCREASED SPACE FROM 10 CYLS TO 20
02.55.29 JOB05581 SVM4000I <jobname>, S050, <temp ds name>, ATTEMPTING SPACSECI FOR SY
02.55.29 JOB05581 SVM4874I INCREASED SPACE FROM 10 CYLS TO 30
====== NEW PAGE ========
1 SYNCSORT FOR Z/OS 1.2.1.0R U.S. PATENTS: 4210961, 5117495 (C) 2005 SYNCS
SYNCSORT FOR ZOS R1.2 z/OS 1.7.0
PRODUCT LICENSED FOR CPU SERIAL NUMBER 1AB7C, MODEL 2064 212 LICE
SYSIN :
SORT FIELDS=(4,7,CH,A,3,1,CH,A,14,13,BI,A)
WER108I SORTIN : RECFM=FB ; LRECL= 214; BLKSIZE= 21400
WER110I SORTOUT : RECFM=FB ; LRECL= 214; BLKSIZE= 21400
WER045C END SORT PHASE
WER418I DATASPACE(S) AND/OR ZSPACE USED
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
WER246I FILESIZE 73,295,428 BYTES
WER054I RCD IN 342502, OUT 342502
WER072I EQUALS IN EFFECT
WER169I RELEASE 1.2 BATCH 0454 TPF LEVEL 1.0
WER052I END SYNCSORT - <job name>,P010,S050,DIAG=EE00,F9C1,C239,2C5F,B7D7,49CA,
I still need to find out, is there any difference, when the ds is a temp dataset in terms of how space is calculated.
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
First thing I would do is to change that &temp file to a file with a DISP of (new,catlg,catlg). Then you can look at it. I would also take a look at your sortwrks - how many are you allocating? I would also code the RLSE parm on the output file and sortwrks.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
there is also the RLSE parm that you can use, so that you can allocate as much as you would need for a max situation and when you use less, the system will free up what has been allocated and not used.
and as expat mentioned, why are you not allowing the system to allocate blocksize, etc? Then it does not matter which dasd type you are using. Sort is pretty good at allocating the proper output DCB parms. Suggest that you read a little in the DFSORT manuals about output file definitions and allow the sophistication of DFSORT to make up for you lack of knowledge.
Knowing when to allow the system to assign default values and having to provide specific DCB parms due to old, unsophisticated legacy applications requirements is the difference between rookies and 'seniors'.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
I see you are using SYNCSORT and not DFSORT. Even though Frank may disagree, SYNCSORT has enough sophistication to allocate enough output space. you can always contact Alisa from SYNCSORT and obtain manuals which will guide you.
There is no reason to ever have output allocation problems with either product. But, you do have to educate yourself about the product to take advantage of the products sophistication.
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
As Dick has pointed out, and this is one of my pet subjects, unless a program must have a specific BLKSIZE for its datasets, let the system determine the correct blocksize for a dataset.
This code will work for ANY DASD type on the mainframe.
As of now, I have other task on hand (programming) so I have no more time to look at this to improve its performance further as someone said 'I am not the space manager' so better not to waste time on it.
The JCL, having RLSE. And yes the BLKSIZE is one thing which I couldn't digest. I have been practising using BLKSIZE = 0 for all the JCLs which I am creating, but since this is done some 10 years back I guess...i need to provide so many reasons if I need to change anything...
Is it better to use BLKSIZE = 0, so that the system will calculate the best required or do I need to use something like expat suggested?
Someone did suggest to increase the sortwork, but before I give it a try, by increasing the &&temp, the problem solved so I didn't manage to get to try it.
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
BLKSIZE=0 is best. I always used at least 3 sortwrks. I do not like &&temp files especially if you have a job scheduler - they don't like them either. If you catlg the file, and the step is successful, then it will still be there if the job goes out 5-10-20 steps into the jobstream. Put a step at the end of your jobstream with COND=(0,NE) to delete any files that you won't need.
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
First of all, you should talk to someone in tech services - perhaps you have a disk space manager. From the name of the file, it appears to be a file containing data for the year 2007. It looks like someone should have made this file a gdg that is created each time the job is run. Then you would not need contiguous space on a disk. When you needed all of the data, you could just bring in all generations.
