Yup, depending on how well the blocks compress.
Michael
At 05:21 PM 6/30/2026, Michael Watkins wrote:
I also notice that the LRECL is 32720 and the
records (FB) do not appear spanned. Can there be
more than one 32720-byte record in this 56,632-byte physical block?
-----Original Message-----
From: IBM Mainframe Discussion List
<[email protected]> On Behalf Of Michael Watkins
Sent: Tuesday, June 30, 2026 5:18 PM
To: [email protected]
Subject: Re: Net bytes per track
CAUTION: This email originated from outside of
the Texas Comptroller's email system.
DO NOT click links or open attachments unless
you expect them from the sender and know the content is safe.
Sure, since the 1970s VSAM physical records have
not corresponed 1-to-1 with the CI-size.
Probably other access methods, too. That's just the one I'm keenly aware of.
The URL you cite directs me to a section of
'DFSMS Using Data Sets'. For z/OS V3.2
(SC23-6855-70), this is p.386, 'Characteristics
of compressed format data sets'. However, the
table with the SMF report file is from another source. It has this line:
ID DSORG RECFM LRECL BLKSIZE SMF14CIS SMF14CMPTYPE
14 PS FB 80
32720 56632 3:ZEDC
'SMF14CIS' is a field found within the SMF Type
14 record that indicates the physical block size
of an extended format data set. 56632 plus the
32 bytes appended for extended formatting is
56664, the track size. Since creating these is '
Nothing complex. Merely create the dataset with
SMS compression. Allocation and the SAM access
method takes care of the details', what
allocation parameters are used to specify this
extended format data set whose physical record
consumes the entire track with no inter-record gaps?
-----Original Message-----
From: IBM Mainframe Discussion List
<[email protected]> On Behalf Of Michael Oujesky
Sent: Tuesday, June 30, 2026 4:38 PM
To: [email protected]
Subject: Re: Net bytes per track
CAUTION: This email originated from outside of
the Texas Comptroller's email system.
DO NOT click links or open attachments unless
you expect them from the sender and know the content is safe.
Please see:
<https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/3.2.0?topic=sets-characteristics-compressed-format-data__;!!JJZmGcLPLA!dfwGSymF-DPi6jbNV2JZPFANiX3GmcW3d-5nqWl679R_NRKSC_KL9t8J-StNr50aZ7fgZYLeeHPxyd5NWuJ-rTXdccGouSwF$
>Characteristics of compressed format data sets
- IBM Documentation The data format for a
compressed format data set consists of physical
blocks whose length has no correlation to the
logical block size of the data set in the DCB,
DCBE, and the data set label. The actual
physical block size is calculated by the system
and is never returned to the user.
However, the system maintains the user's block
boundaries when the data set is created so that
the system can return the original user blocks
to the user when the data set is read.
SMF report of such files:
ID DSORG RECFM LRECL BLKSIZE SMF14CIS SMF14CMPTYPE
14 PS VBS 32760 32760 27966 2:TAILORED
14 PS VB 4096 32760 27966 2:TAILORED
14 PS FB 80 32720 56632 3:ZEDC
14 PS FB 32752 32752 27966 1:GENERIC
Michael
At 11:30 AM 6/30/2026, Michael Watkins wrote:
>Please either expalin how to allocate an 'SMS compressed file with
>super-blocks that write full tracks of data' or point to some IBM
>documentation that explains this.
>
>I assume from the context of your previous remarks that 'full tracks of
>data' means there are no inter-record gaps within the blocks; a
>BLKSIZE=56664, essentially.
>
>I'm not assuming your previous comments don't make sense. Despite
>decades of mainframe infrastructure experience, I've never heard of
>this, but I certainly don't know everything.
>
>-----Original Message-----
>From: IBM Mainframe Discussion List
><[email protected]> On Behalf Of Michael Oujesky
>Sent: Tuesday, June 30, 2026 11:18 AM
>To: [email protected]
>Subject: Re: Net bytes per track
>
>Nothing complex. Merely create the dataset with SMS compression.
>Allocation and the SAM access method takes care of the details.
>
>Check you 14/15 SMF records for the actual physical size of blocks on
>DASD. 14/15 still have BLKSIZE, but is is now logical and not
>physical.
>
>Michael
>
>At 10:49 AM 6/30/2026, Michael Watkins wrote:
> >Clear as mud. How do I define a data set using full tracks of
> >super-blocks using zEDC compression? Of course, a DATACLAS specifying
> >zEDC compression will have to be assigned, but what allocation
> >parameters will use 'super-blocks'?
> >
> >If it's too many words to explain, please just point to a manual or
> >red book that documents this.
> >
> >
> >-----Original Message-----
> >From: IBM Mainframe Discussion List
> ><[email protected]> On Behalf Of Michael Oujesky
> >Sent: Tuesday, June 30, 2026 10:28 AM
> >To: [email protected]
> >Subject: Re: Net bytes per track
> >
> >
> >Any SMS compressed data set.
> >
> >Michael
> >
> >
> >At 10:13 AM 6/30/2026, Michael Watkins wrote:
> > >I'll bite. '[DF]SMS compressed files super-block and write full
> > >tracks of data'? What file type, accessible through any standard
> > >z/OS access method, can use 'full track super-blocks'? Please explain.
> > >
> > >-----Original Message-----
> > >From: IBM Mainframe Discussion List <[email protected]> On
> > >Behalf Of Michael Oujesky
> > >Sent: Tuesday, June 30, 2026 9:46 AM
> > >To: [email protected]
> > >Subject: Re: Net bytes per track
> > >
> > >
> > >Not quite correct. SMS compressed files super-block and write full
> > >tracks of data. BLKSIZE becomes logical (i.e. the buffer size of
> > >data used between the applcation and the SAM access method.
> > >
> > >See SMF14CIS in the 14/15 SMF record for the actual physical size
> > >on the track.
> > >
> > >Michael
> > >
> > >At 08:19 PM 6/29/2026, Michael Watkins wrote:
> > > >Content-Transfer-Encoding: base64Yes, 56664 bytes per track on a
> > > >3390, but the maximum z/OS BLKSIZE is 32,760 bytes and only one
> > > >block will fit on a track.
> > > >
> > > >To maximize the amount of data on a track, half-track blocking is
> > > >typically used. There is a 668-byte inter-record gap on a native
> > > >3390 (platters on a spindle), which has been replicated on RAIDed
> > > >FBA devices in modern DASD architecture. This means there is a
> > > >maximum half-track BLKSIZE of 27998 bytes since 668+(2x27998)=56664.
> > > >
> > > >For a data set with 80-byte records, this means half-track
> > > >blocking means a 27920-byte BLKSIZE since 349 x 80 = 27920 and
> > > >there isn't room in
> > > >27998 for the 350th 80-byte record.
> > > >
> > > >Also keep in mind that z/OS will append 32 bytes onto each block
> > > >when DSNTYPE=EXTENDED is specified, meaning less space for data
> > > >records is available.
> > > >
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: IBM Mainframe Discussion List <[email protected]> On
> > > >Behalf Of Joseph Reichman
> > > >Sent: Monday, June 29, 2026 8:01 PM
> > > >To: [email protected]
> > > >Subject: Re: Net bytes per track
> > > >
> > > >CAUTION: This email originated from outside of the Texas
> > > >Comptroller's email system.
> > > >DO NOT click links or open attachments unless you expect them
> > > >from the sender and know the content is safe.
> > > >
> > > >I keep on seeing from AI 56,664 bytes per tack for 3390 pack how
> > > >is that determined
> > > >
> > > >
> > > >Joe Reichman
> > > >
> > > >On Mon, Jun 29, 2026 at 8:58âEUR¯PM Attila Fogarasi <
> > > >[email protected]> wrote:
> > > >
> > > > > The net bytes (i.e. longest record you can write to that
> > > > > track) varies by access method as
there is overhead (control bytes).
> > > > > TRKCALC is provided to compute the largest record which can
> > > > > fit on a track (using EXCP), see
> > > >https://urldefense.com/v3/__http://www.ibm.com/docs/en/zos/3.2.0?
> > > >to
> > > > >
> > > > > Unless you are using EXCP the hardware track capacity is
> > > > > irrelevant,
> > > >HXØÙ\ÜÈY]Ù\ÙYÚ[]@rmine the actual bytes per track (and
> > > > > varies by BLKSIZE).
> > > > >
> > > > > On Tue, Jun 30, 2026 at 10:35âEUR¯AM Joseph Reichman <
> > > > > [email protected]> wrote:
> > > > >
> > > > > > Would anyone know how to get the net bytes per track for a
> > > > > > 3390
> > > > > >
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
