This is not exactly what was requested by OP, but the PDS command and its
program product heir StarTool will produce member stats with the VERIFY
subcommand. See sample output below for a whole member list scan. VERIFY can
also be used on a single member. I don't know of any way to display every block
of every member. Sounds like TMI to me. ;-)
As for why not '32,767' for maximum blocksize, I've never heard a cogent
explanation for the original choice, but the justification for leaving it at
32,760 is self-evident: a huge amount of work ($$$) all over the OS in order to
gain 7 bytes out of 32K. A miserable ROI.
VERIFY :
PDS111I 2,061 physical blocks were input
PDS112I 32,760 characters in the largest physical block
PDS113I 1,464 characters per average physical block
PDS114I 0 tracks could be regained by compressing this data set
PDS115I 137 members were checked
PDS130I The following is a track usage map of the data set
PDS130I DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
PDS130I XXXXXXXXXXXXXXXXXXXXXXXXXL.
PDS118I 52 members RMODE24; size is 1,294K
PDS119I 76 members RMODEANY; size is 2,171K
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Paul Gilmartin
Sent: Wednesday, September 02, 2015 4:54 AM
To: [email protected]
Subject: Re: how to know the length and blocksize of each member in dataset
On Wed, 2 Sep 2015 07:32:15 -0400, John Eells wrote:
>[email protected] wrote:
><snip>
>> Mind you, max blocksize is 32768, but that info is useless. AMBLIST can
>> *probably* help you, but ...
>
>The maximum block size for z/OS is actually 32760. (We have to reserve
>space for those pesky RDWs and BDWs.)
>
No, the block size counts the BDW and RDWs, so the longest data portion is
32752.
The count in a CCW allows up to 65535. Originally, a smaller value was chosen
because the s/360 hardware has no direct support for unsigned halfword
arithmetic. It could have been done, SMOP, but with added code at a time when
storage was precious. And using more than 32 Kib for a buffer was likewise
unthinkable.
Why not 32767? The best explanation I've gotten here is that the access method
requires a few overhead bytes with each buffer, and there is (was?) a desire to
obtain buffer storage page-aligned.
Bad History. Otherwise, full track on a 3390 would be practical.
And 32768 is reserved for LRECL=X.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
