Totally 8 records can be written in a block, if i have 1000 records to write in a target file, how can i calculate the TRK needed.
I could assume if i give LRECL and RECFM, system will take the optimized block size. But i wanted to know how we could calculate TRK having LRECL and BLKSIZE.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
1000 / 8 = 125
What's so hard about that?
The harder question is determining the number of records that can fit on a track, and that's the real question you may have.
This is actually far more difficult. It depends on the exact method the disk device and the control unit that operates the device uses to format a track.
At one level it's much easier now that IBM just has the 3390 disk (in various models). When I started in the 1960s there were numerous disk devices, and each had a different track capacity. Many shops had three or more different disk types. The shop where I started using System/360 in 1968 had 3: the 2301 (which us peons could not use), the 2311 and the 2314.
In actual fact, you can get 39 800 byte records on one track of a 3390, so your calculation should be
1000 / 39 = 25.64102564102564
according to my trusty Windoze calculator. The 39, by the way, comes from a moderately hard to find table in Using IBM 3390 in an MVS Environment. Since 25.64.. is a fraction, you really use 26.
The harder question is determining the number of records that can fit on a track, and that's the real question you may have.
This is actually far more difficult. It depends on the exact method the disk device and the control unit that operates the device uses to format a track.
At one level it's much easier now that IBM just has the 3390 disk (in various models). When I started in the 1960s there were numerous disk devices, and each had a different track capacity. Many shops had three or more different disk types. The shop where I started using System/360 in 1968 had 3: the 2301 (which us peons could not use), the 2311 and the 2314.
In actual fact, you can get 39 800 byte records on one track of a 3390, so your calculation should be
1000 / 39 = 25.64102564102564
according to my trusty Windoze calculator. The 39, by the way, comes from a moderately hard to find table in Using IBM 3390 in an MVS Environment. Since 25.64.. is a fraction, you really use 26.
Hi Steve,
Thanks, I could able to understand what you explained. I am new to mainframes. So I am confused with SPACE parameter.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Balu5491 wrote:
... I am new to mainframes. So I am confused with SPACE parameter.
This is not something to be embarrassed about. I've been working with OS/360 and its descendants for almost 50 years, and I get SPACE wrong all too often.
Early DASD was too small to bother with suballocating it. Arguably, System/360 DASD was a 3rd generation of DASD, and it was probably still too small to be worth suballocating, though the sizes were getting bigger.
My guess is the designers didn't think about the issues hard enough. The idea of variable record sizes was new (and pretty much unique to System/360 DASD), so the file idea later developed with *nix would not have been acceptable, though at least parts of the idea had been floated around several years earlier and rejected because the computer systems were too slow.
One idea that was current in the middle 1960s when much of this was developed is that some work should be offloaded from the main CPU, so I think some of the thinking was the SPACE parameter was engineered to support offloading work to the channel (a small computer, itself) and the device controller (another small computer). The lead designer of the 2841 device controller used for most of the early System/360 DASD regarded the System/360 Model 30, the low end computer of the System/360 line, as nothing more than a programmed channel!
*nix proponents look at the SPACE parameter, and laugh at its foolishness. I think they are both right as it is one of the biggest ways to go wrong in managing storage space, and wrong, because *nix type space management is a performance hog. Long time readers of my posts often note my disdain for PDSE. I grant its storage management benefits, but the tradeoff is its poor performance relative to PDS, and some of that is PDSE uses *nix file management techniques in the storage space assigned to the data set.
... I am new to mainframes. So I am confused with SPACE parameter.
This is not something to be embarrassed about. I've been working with OS/360 and its descendants for almost 50 years, and I get SPACE wrong all too often.
Early DASD was too small to bother with suballocating it. Arguably, System/360 DASD was a 3rd generation of DASD, and it was probably still too small to be worth suballocating, though the sizes were getting bigger.
My guess is the designers didn't think about the issues hard enough. The idea of variable record sizes was new (and pretty much unique to System/360 DASD), so the file idea later developed with *nix would not have been acceptable, though at least parts of the idea had been floated around several years earlier and rejected because the computer systems were too slow.
One idea that was current in the middle 1960s when much of this was developed is that some work should be offloaded from the main CPU, so I think some of the thinking was the SPACE parameter was engineered to support offloading work to the channel (a small computer, itself) and the device controller (another small computer). The lead designer of the 2841 device controller used for most of the early System/360 DASD regarded the System/360 Model 30, the low end computer of the System/360 line, as nothing more than a programmed channel!
*nix proponents look at the SPACE parameter, and laugh at its foolishness. I think they are both right as it is one of the biggest ways to go wrong in managing storage space, and wrong, because *nix type space management is a performance hog. Long time readers of my posts often note my disdain for PDSE. I grant its storage management benefits, but the tradeoff is its poor performance relative to PDS, and some of that is PDSE uses *nix file management techniques in the storage space assigned to the data set.
As a fresher, i am learning..
I feel happy to get to know all these details, nowhere i can learn all these as precise like this from exerts other than discussion forms like this.
These days you should not be concerned about TRK or CYL allocation and instead use the methods base on numbers of records, and the system calculates the numbers of TRKS/CYLS for you regardless of the DASD geometry.
e.g.
In JCL this requests enough space for 1000 x 80 bye records Primary and same for Secondary space. This is by virtue of the AVGREC parameter that can be specified as U (unit), K (thousand's) or M (millions).
// SPACE=(80,(1,1),RLSE),AVGREC=K
Also if you speak to your Storage people they can probably suggest a DATACLAS that will provide the appropriate amount of space. You may be able to choose the DATACLAS by coding it in the JCL, or they may be automatically assigning it to your dataset based on the name for example.
If you can access the ISMF application you can view all the available DATACLAS's and decide what is appropriate.
In IDCAMS you request the same space requirement in KILOBYTES or MEGABYTES in combination with your RECORDSIZE parameter.
KILOBYTES(8000) RECORDSIZE(80 80)
or
MEGABYTES(8) RECORDSIZE(80 80)
These days you should not be concerned about TRK or CYL allocation and instead use the methods base on numbers of records, and the system calculates the numbers of TRKS/CYLS for you regardless of the DASD geometry.
e.g.
In JCL this requests enough space for 1000 x 80 bye records Primary and same for Secondary space. This is by virtue of the AVGREC parameter that can be specified as U (unit), K (thousand's) or M (millions).
// SPACE=(80,(1,1),RLSE),AVGREC=K
Also if you speak to your Storage people they can probably suggest a DATACLAS that will provide the appropriate amount of space. You may be able to choose the DATACLAS by coding it in the JCL, or they may be automatically assigning it to your dataset based on the name for example.
If you can access the ISMF application you can view all the available DATACLAS's and decide what is appropriate.
In IDCAMS you request the same space requirement in KILOBYTES or MEGABYTES in combination with your RECORDSIZE parameter.
KILOBYTES(8000) RECORDSIZE(80 80)
or
MEGABYTES(8) RECORDSIZE(80 80)
Hi Pete,
Thanks for the details, these are the additional details I need to note down.
The data class will be automatically assigned in my case.
I just wanted to have some understanding about this allocations, that is all.
