Re: Net bytes per track

Joseph Reichman Wed, 01 Jul 2026 08:10:09 -0700

This is a really difficult task as I see because of the  blocking factor

I decided the best solution is to go back to my roots in computer science


Since I am a Dinosaur that’s before OO

I mean Knuth

I am going to use a linked list

I cannt create a cell pool because each record size is different in a vb
file

I am hoping not to fragment storage

But going to give this a shot

Thank you




On Tue, Jun 30, 2026 at 9:55 PM Mike Schwab <
[email protected]> wrote:

> 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
>

----------------------------------------------------------------------
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