Re: Net bytes per track

Mike Schwab Tue, 30 Jun 2026 18:56:05 -0700

Through the 3350 there were some programs that wrote full track R0
records to get a slightly larger block.


On Tue, Jun 30, 2026 at 7:19 PM Michael Watkins
<[email protected]> wrote:
>
> I think I hear what you're saying - that a 32720-byte record might occupy far 
> few bytes when compressed and several could fit into a 56632-byte physical 
> record. I concede that SMF uses them,  but unless you're IBM, (or another 
> software vendor) you're not writing a 65632-byte physical record. This is not 
> available to someone writing a problem program.
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
> Michael Oujesky
> Sent: Tuesday, June 30, 2026 6:39 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.
>
> 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
> >https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JJZmGcLP
> >LA!ffzBLup1PnWeGv_oP4SB8byOd9J5Ff8umRy31Qljuae4YSldPom7vXRy-UxSnOzuD7LW
> >CJqoLizjwVMd0Xrb_0t1iz4A2xha$ ×¢Ö·×  ×(tm)Ö´×©Ö°×'×¨Ö¸× Öµ×oe ×-Ö·×(tm)
> >ï¿½ ÖµÖ£×¦Ö·×- ×(tm)Ö´×©Ö°×'×¨Ö¸× ÖµÖ"×oe ×oeÖ¹Ö¥×
> >×(tm)Ö°×©Ö·× ×§ÖµÖ¼Ö×¨
> >
> >
> >
> >
> >________________________________________
> >From: IBM Mainframe Discussion List
> ><[email protected] on behalf of Michael Watkins
> ><[email protected]ï¿½ï¿½[ï¿½ï¿½Y\ï¿½^Kï¿½
> >[ï¿½HÌOEï¿½ï¿½
> >ï¿½ï¿½ï¿½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
> >gapsBï¿½Bï¿½Bï¿½KKKKSÜsYï¿½[ï¿½[Y\ï¿½ï¿½Yï¿½KKKKKCBï¿½ï¿½ï¿½om: 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?topi
> >c=sets-characteristics-compressed-format-data__;!!JJZmGcLPLA!dfwGSymF-D
> >Pi6jbNV2JZPFANiX3GmcW3d-5nqWl679R_NRKSC_KL9t8J-StNr50aZ7fgZYLeeHPxyd5NW
> >uJ-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
> >ï¿½ï¿½ï¿½Vï¿½OMMï¿½ï¿½ï¿½\ï¿½ï¿½entially.
> >Bï¿½ï¿½vï¿½ï¿½ï¿½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
> >Pï¿½KSPRSï¿½Tï¿½ï¿½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È(tm)H\ï¿½ï¿½YÛ(tm)@d, but what
> >allocation
> > > \ï¿½[Y]\ï¿½ï¿½ï¿½[\ï¿½H ï¿½ï¿½\\ï¿½Xï¿½ï¿½cks'?
> > > >
> > > Yï¿½]   ï¿½ï¿½ï¿½ï¿½X[ï¿½Hï¿½Ü(tm)ï¿½ï¿½^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
> >ï¿½Bï¿½ï¿½ï¿½Bï¿½ï¿½ï¿½4ï¿½26ï¿½ï¿½&W0sed data set.
> > > Bï¿½ï¿½Ö6ï¿½Vï¿½ï¿½4(ï¿½ï¿½4(ï¿½At 10:13 AM 6/30/2026, Michael Watkins 
> > > wrote:
> >ï¿½ï¿½IÛs]Kï¿½        ï¿½Ñ-Tï¿½MS compressed files super-block and write full
> > > ï¿½ï¿½Xï¿½ks of
> > > data'ï¿½]ï¿½[H\KXï¿½ï¿½\ï¿½ï¿½Xï¿½Hï¿½ï¿½Yï¿½[ï¿½Hï¿½[ï¿½ard
> >ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Xï¿½ï¿½\ï¿½ï¿½Y]ï¿½ï¿½[ï¿½\ï¿½H   Ù 
> >[ï¿½Xï¿½ï¿½ï¿½\\ï¿½Xï¿½locks'? Please explain.
> > > > Bï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½&ï¿½vï¿½ï¿½ï¿½ï¿½W76pe-----
> >ï¿½ï¿½ï¿½ï¿½ï¿½Nï¿½Pï¿½HXZ[ï¿½ï¿½ï¿½[YH\ï¿½ï¿½\ï¿½ï¿½[Û^\ï¿½Pï¿½KSPR@N@
> >LISTSERV.UA.EDUÛfBï¿½ï¿½ï¿½&Vï¿½ï¿½bï¿½bÖ6ï¿½Vï¿½ï¿½Vï¿½W6ï¿½ï¿½Ð£ï¿½>
> >ï¿½[ï¿½ï¿½Y\ï¿½^Kï¿½[ï¿½HÌOEï¿½ï¿½Nï¿½
> >ï¿½SCBï¿½ï¿½ï¿½Fï¿½$ï¿½ï¿½Ô [email protected]
> > > > ï¿½Xï¿½ï¿½XÝ^ï¿½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ï¿½Qï¿½Mï¿½Tï¿½[ï¿½HMï¿½MHï¿½Qï¿½ï¿½Xï¿½Ü(tm)ï¿½Ü^H@ctual
> > > physical size ï¿½Û^Hï¿½XÚ>Bï¿½ï¿½ï¿½Ð£ï¿½ï¿½5ï¿½ï¿½ ael
> >ï¿½ï¿½Bï¿½ï¿½ï¿½Bï¿½ï¿½ï¿½ï¿½bï¿½#ï¿½ï¿½##bï¿½Ö6ï¿½Vï¿½vFï¿½ï¿½ï¿½2prote:
> > > > ï¿½ï¿½Û [ï¿½Uï¿½[ï¿½Ù(tm)\ï¿½Q[ï¿½ï¿½ï¿½[ï¿½Î^ï¿½\ï¿½Mï¿½Y\ï¿½
> >Mï¿½ï¿½ï¿½ bytes per track on a
> >ï¿½ï¿½33ï¿½ï¿½'WBFï¿½RÖ?ï¿½ï¿½VÒ¢ï¿½ï¿½2BLKSIZE is 32,760 bytes and
> >only one ï¿½ï¿½&ï¿½ï¿½6ï¿½vï¿½ï¿½ï¿½`it on a track.
> > > > ï¿½Bï¿½ï¿½ï¿½ï¿½Fï¿½Ö?ï¿½Ö-ï¿½RFï¿½Rï¿½ï¿½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ï¿½\È(tm)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ï¿½]Hï¿½Xï¿½Ü(tm)ï¿½\ï¿½YX[ï¿½s half-track
> >ï¿½ï¿½&ï¿½ï¿½6ï¿½ï¿½ï¿½rï¿½Vï¿½2#sï¿½#ï¿½'ï¿½FR$Äµ4ï¿½ï¿½Rsince 349 x
> >80 = 27920 and
> > > > ï¿½\ï¿½H\Û?Ý>ï¿½ï¿½H[ï¿½Bï¿½ > >
> > ï¿½ï¿½NNï¿½Ü^Hï¿½LXï¿½]Hï¿½Xï¿½Ü(tm)ï¿½Bï¿½ï¿½ï¿½ï¿½Ð£ï¿½ï¿½ >Also
> >keep in  mind that z/OS will append 32 bytes onto each block
> >ï¿½ï¿½vï¿½Vï¿½E4ï¿½Eï¿½Sï¿½Uï¿½DTï¿½DTBï¿½27V6ï¿½fï¿½VBï¿½ï¿½Vning less
> >space for data ï¿½ï¿½&V6ï¿½&G2ï¿½2fï¿½ï¿½&ï¿½ï¿½ï¿½  > > Bï¿½ï¿½ï¿½4( >
> >> Bï¿½ï¿½â´´ï¿½ï¿½ï¿½=É¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½5ï¿½ï¿½Í...ï¿½ï¿½ï¿½ï¿½ï¿½--
> > > > ï¿½ï¿½ï¿½ï¿½Nï¿½Pï¿½HXZ[ï¿½ï¿½ï¿½[YH\ï¿½ï¿½\ï¿½ï¿½[Û^\ï¿½Pï¿½KSPRS
> > > > ï¿½LISTSERV.UA.EDU> On
> > > ï¿½ï¿½ï¿½Z[ï¿½Ù^ï¿½ï¿½ï¿½\ï¿½ZXï¿½X[ï¿½Bï¿½ï¿½>
> > ï¿½ï¿½[ï¿½ï¿½[Û(tm)^Kï¿½[ï¿½Hï¿½Kï¿½ï¿½ï¿½ï¿½HCBï¿½ï¿½ï¿½ï¿½Fï¿½$ï¿½ï¿
> > ½[email protected]
> > > > ï¿½ï¿½Xï¿½ï¿½XÝ^ï¿½Nï¿½ï¿½]ï¿½]\ï¿½\ï¿½rack
> > > ï¿½ï¿½Bï¿½ï¿½ï¿½ï¿½4UDï¿½ï¿½ï¿½Fï¿½ï¿½2VÖï¿½ï¿½&ï¿½vï¿½ï¿½FVBg&ï¿½ï
> > > ¿½ outside of the Texas
> >ï¿½ï¿½6ï¿½ï¿½G&ï¿½ï¿½ï¿½W"w2VÖï¿½7ï¿½7FVï¿½ï¿½
> >ï¿½ï¿½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\Èz@ access method as there is overhead 
> > > > (control bytes).
> > >  > > ï¿½ï¿½ï¿½Sï¿½\È>ÝsYYï¿½ï¿½ï¿½\]HH\ï¿½ï¿½\Ý(tm)Xï¿½Ü(tm)which
> > > can
> >ï¿½ï¿½ï¿½fï¿½Bï¿½ï¿½G&6ï¿½ï¿½W6ï¿½ï¿½rUï¿½5ï¿½ï¿½6VPÐ£ï¿½>
> >ï¿½Î<ï¿½ï¿½\ï¿½Yï¿½[ï¿½ï¿½Kï¿½ï¿½ï¿½KÝOEï¿½ï¿½ï¿½Ú<ï¿½ï¿½ï¿½ï¿½ËsXï¿½Kï¿½ï¿½ï¿½Kï¿½ï¿½ï¿½ï¿½ï¿½en/zos/3.2.0?
> > > ï¿½ï¿½Â'ï¿½ï¿½ï¿½4(ï¿½ï¿½ > > Unless you are using EXCP the hardware
> > > track capacity is ï¿½ï¿½ irrelevant,
> >ï¿½ï¿½ï¿½ï¿½9ï¿½9ï¿½ï¿½9ï¿½8ï¿½ï¿½ï¿½9ï¿½ï¿½9ï¿½ï¿½9ï¿½ï¿½ï¿½&Öï¿½RFï¿
> >½R0tual bytes per track (and
> > > ï¿½ï¿½f&ï¿½W2'ï¿½$Äµ4ï¿½ï¿½Rï¿½ï¿½ï¿½
> > > > ï¿½ï¿½Bï¿½ï¿½ï¿½ï¿½=ï¿½ï¿½QÕ"ï¿½ï¿½)Õ¸ï¿½ï¿½0ï¿½ï¿½Ø ï¿½ÐEURï¿½(ï¿
> > > > ½×?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
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Re: Net bytes per track

Reply via email to