i was just getting ready to say this same thing. The 3390 reference shows that for a 3120 byte block, only 15 blocks fit on a track, with a 16% space waste.
Your best bet is to use TRKCALC... https://www.ibm.com/docs/en/zos/2.4.0?topic=instructions-performing-track-calculations-trkcalc-macro Joe On Thu, Nov 24, 2022 at 11:25 AM Joel C. Ewing <jce.ebe...@cox.net> wrote: > Subtracting the logical blocksize from either of those capacity numbers > as you describe will not give correct results for blocks per track. The > only accurate way to determine how many blocks will fit on a 3390 track > is to use the formulas from the 3390 Reference Summary (mentioned in > previous post) to compute the number of 34-byte cells required to write > the block and see if enough of the 1729 cells in the track remain. For > fixed-sized blocks of length requiring "x" cells, the number of blocks > per track would be floor(1729/x) . > > Alternatively, there is a table in the 3390 Reference Summary on page > 12 showing the minimum and maximum block sizes vs number of blocks per > track. It only has 86 rows (a blocksize of 1 byte only gets you 86 > usable bytes per track!), so you could store the Min, Max, and Records > columns of that entire table in a program and look up any blocksize to > see which which row min/max includes that blocksize and extract the > blocks/track from the Records row of the table. > > If your object is to report how much resource the datasets are > consuming, then tracks allocated makes the most sense. > > If your object is to report how much useful data is in the dataset, then > the blocksize becomes potentially useful. If you can get the > last-track-used you can compute the number of actual blocks in the > dataset within an accuracy of blocks-per-track - 1. > > The actual useful data per track vs best-case usage might also be useful > if a sub-optimal blocksize has been chosen. > > Joel C Ewing > > On 11/24/22 10:14, John Gateley wrote: > > The reason for asking the question about bytes on a track is that I am > writing programs to report on all disk datasets. > > The first program looks at all on-line disk packs and extracts all > format 1, 3, 8 and 9 DSCBs while also providing a summary of space > available/used on each disk (similar to VTOC on CBT file 112). > > The second program produces information for all datasets. If the > secondary allocation is in blocks then that means the primary was also and > I want to output the allocation like this BLK(00060,00020). > > To do this I subtract the block size from 56664 repeatedly until the > remainder is less than the block size which gives me the number of blocks > in a track, multiply this by the primary allocation in tracks should give > me the figure I want. > > Except it doesn't. > > > > For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my > program BLK(00072,00020). > > With a blocksize of 3120 there are 18 blocks per track and 4 tracks are > in use. 3 of them must be full so that gives 54 blocks meaning there are > only 6 on the final track. > > > > The dataset is not extended format, PDSE, HFS or VSAM so I think I need > to look at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many > blocks would fit, I get 7 not 6. > > > > Alternatively, if I use 55996 I get 17 blocks per track meaning there > are 9 on the last track and I get 7. > > > > I'm obviously missing something, and I am hoping someone can tell me > what? > > > > DS1DSNAM DSN1.SRCLIB.DATA > > DS1FMTID 1 > > DS1DSSN DB2C06 > > DS1VOLSQ 0001 > > DS1CREDT 78003A > > DS1EXPDT 000000 > > DS1NOEPV 01 > > DS1NOBDB 00 > > DS1FLAG1 00 > > DS1SYSCD IBMOSVS2 > > DS1REFD 7A0148 > > DS1SMSFG 80 > > DS1SCXTF 80 > > DS1SCXTV 0FA0 4000 > > DS1DSORG 0200 > > DS1RECFM 90 > > DS1OPTCD 00 > > DS1BLKL 0C30 > > DS1LRECL 0050 > > DS1KEYL 00 > > DS1RKP 0000 > > DS1DSIND 80 > > DS1SCAL1 50 > > DS1SCAL3 000014 > > DS1LSTAR 000015 > > DS1TRBAL 7E0A 32266 > > DS1TTTHI 00 > > DS1EXT1 0100000C000B000C000E > > DS1EXT2 00000000000000000000 > > DS1EXT3 00000000000000000000 > > DS1PTRDS 0000000000 > > > > Data Set Name . . . . : DSN1.SRCLIB.DATA > > > > General Data Current Allocation > > Management class . . : Allocated blocks . : 60 > > Storage class . . . : Allocated extents . : 1 > > Volume serial . . . : DB2C06 Maximum dir. blocks : 20 > > Device type . . . . : 3390 > > Data class . . . . . : > > Organization . . . : PO Current Utilization > > Record format . . . : FB Used blocks . . . . : 7 > > Record length . . . : 80 Used extents . . . : 1 > > Block size . . . . : 3120 Used dir. blocks . : 1 > > 1st extent blocks . : 60 Number of members . : 0 > > Secondary blocks . : 20 > > Data set name type : PDS Dates > > Data set encryption : NO Creation date . . . : 2020/02/27 > > Referenced date . . : 2022/11/24 > > Expiration date . . : ***None*** > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Joel C. Ewing > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
