Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
Wanted to calculate TRK when i have BLKSIZE

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
Balu5491

New User


Joined: 01 Aug 2016
Posts: 6
Location: India

PostPosted: Wed Jul 19, 2017 5:43 pm    Post subject: Wanted to calculate TRK when i have BLKSIZE
Reply with quote

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!
Back to top
View user's profile Send private message

dneufarth

Active User


Joined: 27 Apr 2005
Posts: 256
Location: Cincinnati OH USA

PostPosted: Wed Jul 19, 2017 5:58 pm    Post subject:
Reply with quote

Search the forums!
Back to top
View user's profile Send private message
dneufarth

Active User


Joined: 27 Apr 2005
Posts: 256
Location: Cincinnati OH USA

PostPosted: Wed Jul 19, 2017 6:04 pm    Post subject:
Reply with quote

Try http://ibmmainframes.com/viewtopic.php?t=55398&highlight=calculate+tracks[
Back to top
View user's profile Send private message
steve-myers

Active Member


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

PostPosted: Wed Jul 19, 2017 6:45 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
prino

Senior Member


Joined: 07 Feb 2009
Posts: 1072
Location: Oostende, Belgium

PostPosted: Wed Jul 19, 2017 10:40 pm    Post subject:
Reply with quote

Steve,

Did we already ban him? ;)
Back to top
View user's profile Send private message
Balu5491

New User


Joined: 01 Aug 2016
Posts: 6
Location: India

PostPosted: Thu Jul 20, 2017 2:24 pm    Post subject:
Reply with quote

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



Thanks dneufarth, i got it.
Back to top
View user's profile Send private message
Balu5491

New User


Joined: 01 Aug 2016
Posts: 6
Location: India

PostPosted: Thu Jul 20, 2017 2:29 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
steve-myers

Active Member


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

PostPosted: Thu Jul 20, 2017 7:42 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Balu5491

New User


Joined: 01 Aug 2016
Posts: 6
Location: India

PostPosted: Wed Jul 26, 2017 2:23 pm    Post subject:
Reply with quote

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:)
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 445
Location: London

PostPosted: Mon Sep 18, 2017 2:00 pm    Post subject:
Reply with quote

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)
Back to top
View user's profile Send private message
Balu5491

New User


Joined: 01 Aug 2016
Posts: 6
Location: India

PostPosted: Tue Sep 26, 2017 9:58 pm    Post subject:
Reply with quote

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!
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Allocate dataset withour BLKSIZE Susanta CLIST & REXX 2 Thu Sep 22, 2016 11:51 am
No new posts How to calculate an specific transact... lind sh CICS 2 Tue Sep 13, 2016 9:20 pm
No new posts Calculate a timeframe with DFsort Gerd Hofmans DFSORT/ICETOOL 6 Thu Jan 14, 2016 5:30 pm
No new posts Wanted to whether SQL query can be bu... arunbai6 DB2 2 Fri Oct 31, 2014 5:43 am
No new posts Calculate Keylen parameter provided i... kratos86 IMS DB/DC 5 Wed Aug 27, 2014 1:19 am

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us