If it's a straight copy via virtual storage do you really have to read the whole data set into virtual storage? There's probably a law of diminishing returns. After all QSAM and BSAM max out in effectiveness in a few hundred KB (obviously limited by the access method but presumably inspired by, inter alia, diminishing returns).
From: IBM Mainframe Discussion List <[email protected]> on behalf of Joseph Reichman <[email protected]> Date: Tuesday, 30 June 2026 at 02:43 To: [email protected] <[email protected]> Subject: [EXTERNAL] Re: Net bytes per track I’m just looking for a ball park figure of the number of bytes in the dataset as I want to read the records into virtual memory copy it over to a new dataset So my objective really is how much storage am I looking at for length parameter on a storage obtain Thanks On Mon, Jun 29, 2026 at 9:40 PM Michael Watkins < [email protected]> wrote: > If you're just trying to prevent the B37-04 ABEND, let me recommend > 'SPACE=(CYL,(274,273),RLSE),UNIT=(SYSDA,59)'. If the DSNTYPE=BASIC, there > is a 4369-cylinder limit on z/OS data sets. 274 + (15 x 273) = 4369, These > are the smallest primary and secondary allocations that will allow you to > use 4369 cylinders on each volume. z/OS data sets cannot span more than 59 > volumes, although I think the default is still 5 unless overridden with the > DATACLAS. > > As for determining the size of the data set, knowing how many bytes of > data you're packing onto a track and then examining the number of cylinders > used in ISPF option 3.4, can give you a good approximation of the amount of > data currently stored. Od course, if you've ABENDed with an SB37-04, all of > the data did not make it to disk. > > > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Joseph Reichman > Sent: Monday, June 29, 2026 8:28 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. > > Thanks I begging to have a better understanding > > I’m really trying figure out how many bytes in a dataset > > So by looking at dcbblksi its 32000 its a variable blocked. Record If the > dataset got a b37 then all the space is used > > Up is there a programitclly way of determine the size of the dataset ? > > Thanks > > Get Outlook for iOS< > https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!JJZmGcLPLA!epaDRLe5xvuHQCHi2VN8_s_Qbkyd2Ty1wZmMTlncwEuxx9okMOzOi27oJDcBvleebVP3oaCwoT3fRs56Q0AL_BYXii3iNcRRIBH4PJiS11LX$ > > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf > of Michael Watkins <[email protected]> > Sent: Monday, 29 June 2026 21:19:54 > To: [email protected] <[email protected]> > Subject: Re: Net bytes per track > > Yes, 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 > > > > https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/3.2.0?topi > > c=instructions-performing-track-calculations-trkcalc-macro__;!!JJZmGcL > > PLA!f8gIQp2WmnK5aJpNmmtG4m8kLdObQsseimGBKGffYscn-nyU3MS1l3Ja7JSZEZ7c6P > > NPHimcV6MZ8a9Bu7MdeT39NLAkG2Cp0zXCYmzdsY2g$ > > > > Unless you are using EXCP the hardware track capacity is irrelevant, > > the access method used will determine 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 > > > > > > I have been using devtype ddname,buffer,devtab > > > > > > > > > Where buffer is a 32 byte output field > > > > > > But it keeps on coming back with the overhead of 58,864 > > > > > > I think the net is 56,664 > > > > > > I would like to get that figure programmatically instead of hard > > > coding > > it > > > > > > Thanks > > > > > > -------------------------------------------------------------------- > > > -- 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
