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
BGG3¢ò÷W&ÆFVfVç6Ræ6öÒ÷c2õõöGG3¢ð/www.ibm.com/docs/en/zos/3.2.0?topi
> c=instructions-performing-track-calculations-trkcalc-macro__;!!JJZmGcL
> PLA!f8gIQp2WmnK5aJpNmmtG4m8kLdObQsseimGBKGffYscn-nyU3MS1l3Ja7JSZEZ7c6P
[XÕVNPMÓYUÎSZÑÌÜÖ[^ÖLg$
>
> 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]HY[\Ú[È]@pe ddname,buffer,devtab
> >
> BâvW&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ÜPKSPRSÝXØÜXe / signoff / archive access instructions,
> Ù[[X@il to [email protected] with the message: INFO
> IBM-MAIN
> >
>
> ----------------------------------------------------------------------
ÜPKSPRSÝ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
