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 [email protected] with the message: INFO IBM-MAIN
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
