Due to compression, yes there could be more than
one 32720 byte logical record in the 56632 byte
physical record. Even if they were fixed length 32720 records.
Michael
At 06:04 PM 6/30/2026, Seymour J Metz wrote:
Content-Transfer-Encoding: base64No. But not all
records are 32K in the noormal run of things.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
×¢Ö·× ×ִשְ×רָ×Öµ× ×Ö·×
× ÖµÖ£×¦Ö·× ×ִשְ×רָ×ÖµÖ× ×Ö¹Ö¥× ×ְשַ×קֵּÖר
________________________________________
From: IBM Mainframe Discussion List
<[email protected] on behalf of Michael
Watkins <[email protected]Ù[Y\Ù^K[HÌ
HPM
To: [email protected] <[email protected]>
Subject: Re: Net bytes per track
External Message: Use Caution
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]ÛZ[f 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
gapsBBBKKKKSÜYÚ[[Y\ÜØYÙKKKKKCBom: IBM
Mainframe Discussion List
<[email protected]ÛZ[ÙZXÚY[ÝZ\ÚÞCBÙ[Y\Ù^K[HÌ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$
Ú\XÝ\\ÝXÜÈÙÛÛ\\ÜÙYÜX]]HÙ]È@ 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
]IÈYX[È\H\HÈ[ter-record gaps within the blocks; a
ÔÒVOMM\ÜÀentially.
BvÒæ÷B77VÖær÷W"&Wf÷W26öÖÖVçG2Fðn't make sense. Despite
>decades of mainframe infrastructure experience, I've never heard of
\Ë]HÙ\Z@nly don't know everything.
>
>-----Original Message-----
>From: IBM Mainframe Discussion List
PKSPRSTÕÀERV.UA.EDU> 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
\ÚXØ[BС5¥¡
°4(ø4(ùÐ 10:49 AM 6/30/2026, Michael Watkins wrote:
> ÛX\\Èmud. How do I define a data set using full tracks of
> super-blocks using zEDC compressionÙÛÝ\ÙKHUPÓ@S specifying
QÈÛÛ\\ÜÚ[ÛÚ[]HÈH\ÜÚYÛ@d, but what allocation
> \[Y]\ÈÚ[\ÙH ÜÝ\\XÀcks'?
> >
> Y] ÜÈÛÈX[HÛÜÈÈ^Z[X\ÙHjust point to a manual or
> YÛÚÈ]ØÝ[Y[È@s.
> >
> BâÒÒÒÒÔ÷&væÂÖW76vRÒÒÒÒÐУâɽ´è% 4 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
BBç4Õ26ö×&W0sed data set.
> BäÖ6Vø4(øø4(øAt 10:13 AM 6/30/2026, Michael Watkins wrote:
IÛ]K ÖÑTÀMS compressed files super-block and write full
> XÀks of data'Ú][H\KXØÙ\ÜÚXHÝYÚ[HÝ[ard
ÓÔÈXØÙ\ÜÈY]ÙØ[\ÙH Ù[XÚÈÝ\\Xlocks'? Please explain.
> > BââÒÒÒÒÔ÷&væÂÖW76pe-----
ÛNPHXZ[[YH\ØÝ\ÜÚ[Û\ÝPKSPR@[email protected]ÛBâä&VÆböbÖ6VÂ÷V¦W6·Ð£â>
Ù[Y\Ù^K[HÌN
SCBâåFó¢$ÒÔÔ[email protected]
> > ÝXXÝN]]\È\XÚÀ
> >
BâàУâù9½ÐÅեѽÉÉиM5L½µIÍͤles super-block and write full
XÚÜÈÙ]KÀSIZE becomes logical (i.e. the buffer size of
]Hused between the applcation and the SAM access method.
> >
> ÙYHÓQMÒTÈ[HMÌMHÓQXÛÜÜH@ctual physical size
> ÛHXÚBâàУâù5¥ ael
BäB£Òbó#ó##bÂÖ6VÂvF¶ç2prote:
> > ÛÛ[U[Ù\Q[ÛÙ[Î\ÙMY\Ë
M bytes per track on a
33Â'WBFRÖ×VÒ¢ôõ2BLKSIZE is 32,760 bytes and only one
&Æö6²vÆÂ`it on a track.
> > BåFòÖÖ¦RFRÖ÷VçBö` data on a track, half-track blocking is
> \XØ[y used. There is a 668-byte inter-record gap on a native
> > ÌÎL
]\ÈÛHÜ[JKÚXÚ\ÈY[\icated on RAIDed
> H]XÙ\È[[Ù\TÑ\Ú@tecture. This means there is a
Ö×VÒÆb×G&6° BLKSIZE of 27998 bytes since 668+(2x27998)=56664.
> > >
> > ÜH]HÙ]Ú]X]HXÛÜË\ÈYX[s half-track
&Æö6¶ærÖVç2#s#Ö'FR$ĵ4¤Rsince 349 x 80 = 27920 and
> > \H\ÛÝÛÛH[B > >
ÎNNÜHÍLX]HXÛÜBàУââ >Also keep in
mind that z/OS will append 32 bytes onto each block
vVâE4åESÔU
DTäDTB27V6fVBÂÖVning less space for data
&V6÷&G22fÆ&àÐ > > Bââ4( > > Bââ´´´´µ=É¥¥¹
°5ÍÍ
´´´--
> > ÛNPHXZ[[YH\ØÝ\ÜÚ[Û\ÝPKSPRSLISTSERV.UA.EDU> On
> Z[ÙÜÙ\ZXÚX[B>
Ù[[Û^K[HKHCBâåFó¢$ÒÐ[email protected]
> > ÝXXÝN]]\È\rack
> Bâä4UDôã¢F2VÖÂ÷&væFVBg&öÐ outside of the Texas
6ö×G&öÆÆW"w2VÖÂ77FVÒà
DòäõB6Æ6²Ææ·2÷"÷VâGF6ÖVçG2VæÆW72ðu expect them
> ÛHHÙ[\[ÛÝÈHÛÛ[t is safe.
> Bâä¶VWöâ6VVærg&öÒSbà64 bytes per tack for 3390 pack how
> > \È]]\mined
> > BàУââù)½I¥¡µ
¸4(øø >
> > Û[Û[K]N0èUT°«ÔH][HÙØ\\Ài <
V#ffVS&#rÖFÖ&2×&WVW7DÆ7G6W'bçVæV@u> wrote:
Ð øø > The net bytes (i.e. longest record you can write to that
> > XÚÊH\Y\È@ access method as there is overhead (control bytes).
> > > ÐÐSÈ\ÈÝYYÈÛÛ\]HH\Ù\ÝXÛÜwhich can
âfBöâG&6²W6ærU5Â6VPУâ>
ÎËÝ\Y[ÙKÛÛKÝË××ÚËÝÝÝËXKÛÛKÙØÜËÀen/zos/3.2.0?
> Âââø4(øø > > Unless you are using EXCP the hardware track capacity is
> irrelevant,
99Ì9Ì8
Ü9Ì99¥µÔ&ÖæRFR0tual bytes per track (and
> f&W2'$ĵ4¤RàÐ
> > Bââ=¸QÕ°)Õ¸Ì0ÈØ
ÐÄ(Ì×UK¯AM Joseph Reichman <
âS#cCVC62ÖFÖ&2× [email protected]> wrote:
àУââøø Would anyone know how to get the net bytes per track for a
> > 33Уââøø
----------------------------------------------------------------------
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
