Re: Net bytes per track

Mike Schwab Wed, 01 Jul 2026 14:42:14 -0700

Read the block.
  Return records to input routine.
  Move to the storage location.
Process records.
Write record
  If record length exceeds free space in block write the block gets empty block.
  Moves record to the block.


On Wed, Jul 1, 2026 at 10:10 AM Joseph Reichman
<[email protected]> wrote:
>
> 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



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