Portal | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref

Author Message
Balu5491

New User

Joined: 01 Aug 2016
Posts: 14
Location: India

 Posted: Wed Jul 19, 2017 5:43 pm    Post subject: Wanted to calculate TRK when i have BLKSIZE Hi, The given LRECL is 80 and BLKSIZE is 800. 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. Thanks for you help in advance!

dneufarth

Active User

Joined: 27 Apr 2005
Posts: 317
Location: Inside the SPEW (Cincinnati OH USA)

 Posted: Wed Jul 19, 2017 5:58 pm    Post subject: Search the forums!
dneufarth

Active User

Joined: 27 Apr 2005
Posts: 317
Location: Inside the SPEW (Cincinnati OH USA)

 Posted: Wed Jul 19, 2017 6:04 pm    Post subject:
steve-myers

Active Member

Joined: 30 Nov 2013
Posts: 859
Location: The Universe

 Posted: Wed Jul 19, 2017 6:45 pm    Post subject: 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.
prino

Senior Member

Joined: 07 Feb 2009
Posts: 1220
Location: Vilnius, Lithuania

 Posted: Wed Jul 19, 2017 10:40 pm    Post subject: Steve, Did we already ban him? ;)
Balu5491

New User

Joined: 01 Aug 2016
Posts: 14
Location: India

Posted: Thu Jul 20, 2017 2:24 pm    Post subject:

 dneufarth wrote: Try http://ibmmainframes.com/viewtopic.php?t=55398&highlight=calculate+tracks[

Thanks dneufarth, i got it.
Balu5491

New User

Joined: 01 Aug 2016
Posts: 14
Location: India

Posted: Thu Jul 20, 2017 2:29 pm    Post subject:

 steve-myers wrote: 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.

Hi Steve,

Thanks, I could able to understand what you explained. I am new to mainframes. So I am confused with SPACE parameter.
steve-myers

Active Member

Joined: 30 Nov 2013
Posts: 859
Location: The Universe

Posted: Thu Jul 20, 2017 7:42 pm    Post subject:

 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.
Balu5491

New User

Joined: 01 Aug 2016
Posts: 14
Location: India

Posted: Wed Jul 26, 2017 2:23 pm    Post subject:

steve-myers wrote:
 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.

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.

Thanks Steve:)
Pete Wilson

Active User

Joined: 31 Dec 2009
Posts: 485
Location: London

 Posted: Mon Sep 18, 2017 2:00 pm    Post subject: 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)
Balu5491

New User

Joined: 01 Aug 2016
Posts: 14
Location: India

Posted: Tue Sep 26, 2017 9:58 pm    Post subject:

 Pete Wilson wrote: 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.

:)

Thanks!
 All times are GMT + 6 Hours
 Page 1 of 1

Search our Forum:

 Topic Author Forum Replies Posted Similar Topics Need help to convert BLKSIZE to Track... vinkum JCL & VSAM 3 Sat Nov 30, 2019 4:35 am Blksize question darioits JCL & VSAM 12 Tue Sep 10, 2019 8:32 pm calculate the record count and based ... naveensrimf DFSORT/ICETOOL 1 Tue Jan 08, 2019 11:20 pm Getting information (RECFM/LRECL/BLKS... Tim Van Holder COBOL Programming 3 Wed Mar 14, 2018 2:10 pm Allocate dataset withour BLKSIZE Susanta CLIST & REXX 2 Thu Sep 22, 2016 11:51 am

 © 2003-2020 IBM MAINFRAME Software Support Division
 Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us