|
View previous topic :: View next topic
|
| Author |
Message |
vyasricha
New User
Joined: 17 Mar 2008
Posts: 27
Location: banaglore
|
|
|
|
Hi,
I am trying to allocate the new dataset , expecting to have 500k records in file.
I am giving the allocation parameter as :
DISP=(NEW,CATLG,DELETE),SPACE=(TRK,(45,45),RLSE)
and my job ran fine with 434797 no of records . But is this will be sufficient to store 500k records ?
I know it will allocate 56664*45 = 2549880 ( primary )
56664*16*45 = 40798080 (secondary)
but this is the no of bytes it can store means 43347960
and as it is allocating the record with length of 49 so no of records= 884652.2449
Please clarify is my understanding is correct . |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
SPACE 101 for students and freshers
I assume that the RECFM=FB
27998 is the optimum BLKSIZE for a DASD dataset
INT(27998 / 49) = 571 - number of records per block
571 * 2 = 1142 records per track
I think the rest of the calculation is simple enough for you to complete  |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
I know it will allocate 56664*45 = 2549880 ( primary )
56664*16*45 = 40798080 (secondary)
but this is the no of bytes it can store means 43347960
and as it is allocating the record with length of 49 so no of records= 884652.2449
Please clarify is my understanding is correct . |
You are ABSOLUTELY WRONG. 56664 is the theoretical maximum number of bytes per track on a 3390 device. The actual maximum possible number of bytes to use is 55996, although it depends upon the block size and can go as low as 1892 bytes per track if the block size is 22 or less bytes. Furthermore, your calculations ignore record boundaries as well as track boundaries -- neither of which is physically possible (you cannot put 1/3 of a record on one track and 2/3 of that record on another track -- at least not easily).
Assuming SMS-managed data sets (or half-track blocking otherwise), the block size based on LRECL of 49 will be 27979. This means 571 records per block and 1142 records per track. 500,000 records will require 438 tracks (500000 divided by 1142 is 437 and a fraction -- and when calculating space, you ignore the fraction and add 1 to the integer since you cannot allocate a part of a track).
Using SPACE=(TRK,(45,45),RLSE) on such a data set means that most of the time it will run fine, but every now and then it will abend with a space issue. This is because the system only guarantees you will get the primary space allocation of 45 tracks on a disk volume. When your job attempts to acquire the other 393 tracks, 45 at a time, if the disk volume doesn't have the space available -- abend. You would be wise to increase the primary from 45 to at least 438. You might also consider allocating in cylinders instead of tracks, or even use the allocation in terms of the number of records instead of tracks. |
|
| Back to top |
|
|
vyasricha
New User
Joined: 17 Mar 2008
Posts: 27
Location: banaglore
|
|
|
|
Thanks for the information , i was aware about the theoretical maximum numbers only. Could you please share a document / link where i can gain more knowledge on this.
Is this will be okey if i give - (trk,(438,438),rlse) ? will it work ? as i tried giving trk,(45,45) and it fine working in development region with 434797
no of records, but not working fine in production ? |
|
| Back to top |
|
|
vyasricha
New User
Joined: 17 Mar 2008
Posts: 27
Location: banaglore
|
|
|
|
Could you guide me in how to calculate the no of records in tracks from no of records in blocks ? as i have RECORD LENGTH = 43
BLOCK SIZE = 27993 , how to calculate no of tracks for n no of records ? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
As has been explained, no-one can say that what you want to do will work. If there is not enough space on the volume for the secondary extents that you require, your job can fail.
Better, as has been said, to define the primary with enough space (plus a bit for expansion) and then you even know if you data is growing faster than expected when it goes into secondary allocation. If you rely on all the secondary extents, bear in mind you can loose a couple if the primary has to go to multiple extents.
Better to define in cylinders than tracks for anything bigger than (tracks per cylinder) tracks. Can help avoid fragmentation of the disk, even the access time a little, a 15 track extent may occupy parts of two cylinders wheras a cylinder won't - Robert, expa(r)t, I was told this a long time ago is it true? I know, google is my friend, link at the top of the page... |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| vyasricha wrote: |
Could you guide me in how to calculate the no of records in tracks from no of records in blocks ? as i have RECORD LENGTH = 43
BLOCK SIZE = 27993 , how to calculate no of tracks for n no of records ? |
For fixed length, divide the magic number by record-length. Ignore the fractional part. Multiply (integer part, therefore) by record-length.
571.286 -> 571 -> 27979.
For variable, leave as 27993. You won't know beforehand how many records in any given block. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Google is your friend. Google GX26-4577 and you will find the 3390 Direct Access Storage Reference Summary which tells you everything you (almost) need to know about 3390 drives. In particular, Table 1 of this document tells you how many physical blocks fit into a track for the various block sizes. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
| Back to top |
|
|
vyasricha
New User
Joined: 17 Mar 2008
Posts: 27
Location: banaglore
|
|
|
|
Hi,
i have gone through the link and it says that 1 trk - 56664 for 3390 device. but with reference to the reply :
"56664 is the theoretical maximum number of bytes per track on a 3390 device. The actual maximum possible number of bytes to use is 55996"
Please let me know how to proceed. i have RECORD LENGTH = 43
BLOCK SIZE = 27993 and no of records expected is 500k so what space parameter should i give ? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
I posted the link to different flavors of the blksize calculator,
to save some of Your time I run it for You and ...
here is the table with the capacity for different blksizes
| Code: |
blks3390 - lrecl min-blksz max-blksz blocks min_recs max-recs
blks3390 - 43 43 43 82 82 82
blks3390 - 43 86 86 78 156 156
blks3390 - 43 129 129 72 216 216
blks3390 - 43 172 172 69 276 276
blks3390 - 43 215 215 66 330 330
blks3390 - 43 258 258 61 366 366
blks3390 - 43 301 301 59 413 413
blks3390 - 43 344 344 57 456 456
blks3390 - 43 387 387 55 495 495
blks3390 - 43 430 430 52 520 520
blks3390 - 43 473 473 50 550 550
blks3390 - 43 516 516 49 588 588
blks3390 - 43 559 559 46 598 598
blks3390 - 43 602 602 45 630 630
blks3390 - 43 645 645 44 660 660
blks3390 - 43 688 688 43 688 688
blks3390 - 43 731 731 41 697 697
blks3390 - 43 774 774 40 720 720
blks3390 - 43 817 817 39 741 741
blks3390 - 43 860 860 37 740 740
blks3390 - 43 903 946 36 756 792
blks3390 - 43 989 989 34 782 782
blks3390 - 43 1032 1075 33 792 825
blks3390 - 43 1118 1118 32 832 832
blks3390 - 43 1161 1161 31 837 837
blks3390 - 43 1204 1247 30 840 870
blks3390 - 43 1290 1290 29 870 870
blks3390 - 43 1333 1376 28 868 896
blks3390 - 43 1419 1462 27 891 918
blks3390 - 43 1505 1548 26 910 936
blks3390 - 43 1591 1634 25 925 950
blks3390 - 43 1677 1720 24 936 960
blks3390 - 43 1763 1849 23 943 989
blks3390 - 43 1892 1935 22 968 990
blks3390 - 43 1978 2064 21 966 1008
blks3390 - 43 2107 2193 20 980 1020
blks3390 - 43 2236 2365 19 988 1045
blks3390 - 43 2408 2537 18 1008 1062
blks3390 - 43 2580 2709 17 1020 1071
blks3390 - 43 2752 2924 16 1024 1088
blks3390 - 43 2967 3139 15 1035 1095
blks3390 - 43 3182 3440 14 1036 1120
blks3390 - 43 3483 3741 13 1053 1131
blks3390 - 43 3784 4128 12 1056 1152
blks3390 - 43 4171 4558 11 1067 1166
blks3390 - 43 4601 5031 10 1070 1170
blks3390 - 43 5074 5719 9 1062 1197
blks3390 - 43 5762 6493 8 1072 1208
blks3390 - 43 6536 7525 7 1064 1225
blks3390 - 43 7568 8901 6 1056 1242
blks3390 - 43 8944 10793 5 1040 1255
blks3390 - 43 10836 13674 4 1008 1272
blks3390 - 43 13717 18447 3 957 1287
blks3390 - 43 18490 27993 2 860 1302
|
after that it should be quite easy to carry on the elementary math
<number of records> / 1302 ==> number of tracks needed
( at optimum blksize ) |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| expat wrote: |
SPACE 101 for students and freshers
I assume that the RECFM=FB
27998 is the optimum BLKSIZE for a DASD dataset
INT(27998 / 49) = 571 - number of records per block
571 * 2 = 1142 records per track
I think the rest of the calculation is simple enough for you to complete |
Obviously not |
|
| Back to top |
|
|
|
|
