It may more sense for you to determine the number of tracks and then simply multiply by maximum track capacity of 56664 (for 3390 devices). Do you have a copy of GX26-4577-03 (or later)?
Lennie -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Joseph Reichman Sent: 30 June 2026 16:14 To: [email protected] Subject: Re: Net bytes per track Since I would rather high mean I want max possible I multiply if it’s cyl by 15 for secondery by 16 And then by 56664 it’s impossible to use more than allocated Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Lennie Bradshaw <[email protected]> Sent: Tuesday, 30 June 2026 11:10:34 To: [email protected] <[email protected]> Subject: Re: Net bytes per track Also, some data sets can have variable block sizes. They can also have RECFM=U like load libraries, so that the block sizes are not predictable. I think the binder uses 32K blocks and then fills the track with shorter blocks. Lennie -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Michael Oujesky Sent: 30 June 2026 15:46 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 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 >B‚‡GG3¢ò÷W&ÆFVfVç6Ræ6öÒ÷c2õõö‡GG3¢ð/www.ibm.com/docs/en/zos/3.2.0?topi > > c=instructions-performing-track-calculations-trkcalc-macro__;!!JJZmG > > cL > > PLA!f8gIQp2WmnK5aJpNmmtG4m8kLdObQsseimGBKGffYscn-nyU3MS1l3Ja7JSZEZ7c > > 6P >”[XÕ“VŽNPMÓYUÎS“ZÑÌÜÖ[^™ÖL€g$ > > > > 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 AM Joseph Reichman < > > [email protected]> wrote: > > > > > Would anyone know how to get the net bytes per track for a 3390 > > > > > H]™H™Y[ˆ\Ú[™È]@pe ddname,buffer,devtab > > > > > B‚âv†W&R'VffW"—232 byte output field > > > > > ]]ÙY\ÈÛˆÛÛZ[™È˜XÀk with the overhead of 58,864 > > > > > H[šÈH™]@s 56,664 > > > > > HÛÝ[ZÙHÈÙ]]šYÝ\™H›Ùܘ@mmatically instead of hard >ˆÛÙ[™Â‚—@Ð €ø4(ø€øPhanks > > > > > KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK@--------------------------- >ˆKH›ÜˆP“KSPRSˆÝXœØÜšX€e / signoff / archive access instructions, > > Ù[™[X@il to [email protected] with the message: INFO > > IBM-MAIN > > > > > > > -------------------------------------------------------------------- > > -- >›ÜˆP“KSPRSˆÝXœÀcribe / 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
