Considering the many layers of emulation and fakery between application and actual recorded media these days, I highly doubt these considerations matter much at all. While it makes sense to maximize BLKSIZE, that's a low-order optimization, only worth doing because it's free.
It's rather a shame z/OS is still stuck with emulating a very obsolete disk technology. sas On Fri, May 19, 2017 at 5:21 PM, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > SDB was invented to automatically optimize two competing efficiencies: I/O > overhead and physical disk storage. To wit, the fewer I/Os the better; and > the less wasted track space the better. > > For I/O, the ideal operation is reading or writing an entire 'data > component' in one operation. For disk storage, the ideal is to occupy every > available bit on a track. > > To maximize track occupancy, one logical record per block probably > achieves maximum efficiency but is horrible in the I/O arena. For I/O > efficiency, a largest possible block that occupies that fits on a track > achieves the fewest I/Os but may result in egregious wasted space. > > For exceptional cases, you can override SDB by coding explicit blocksizes, > but that seems like a lot of work. Setting out to supplant the IBM provided > SBD algorithms with 'something smarter' seems like even more work with > questionable ROI. > > BTW I have no idea how to answer your actual question. Relying on my > college survival strategy, I'm trying to supply an interesting and maybe > even useful answer to a different question. ;-) > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: Friday, May 19, 2017 11:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: SDB (system determined Blksize) > > IBM for many years supplied a macro or subroutine called TRKCALC that can > be used for space calculations. I don't know if it's still around. GIYF. > > The actual formula used is: > > Physical records per track = 1729/(10+K+D) > > D= 9 + (DATALEN + (6x((DATALEN+6/232)) +6/) /34 > > K = 0 if non-keyed > K= 9 + (keylen + ( 6* ((keylen+6/232)) + 6) /34 (if keyed) > > > > 1) I would imagine it can , but I am baffled as to where it would be > specified. The most likely options are in the CDS, or IGDSMSxx. > 2) See # 3. > 3) SLED devices generated the recommendation for 1/2 track blocking for > the following reasons: > a) Maximizing the use of space. > b) Minimizing physical IO to the device . > > With the advent of RAID devices, the physical IO portion has much less > importance. There might be some performance IOS related overhead due to > increase number of IO requests > With the reduction in DASD prices, does the percentage of utilization > matter as much as it used to > > I have not heard of any research in this area? Is Pat Artis still active, > or has he retired? > > HTH, > > > <snip> > I have gone through a few manuals and cannot determine the answer to the > following questions. Any guidance is appreciated > > 1) Can the SDB be adjusted from half-track to another setting (quarter > or full)? > 2) Are there any new best practices for SDB that have changed in the > last 20 years? > 3) Is Half-track still considered OPTIMUM? > > Since the storage arrays are so fast, I would think that maybe full track > would not be that much of a performance impact any more. > > I have been working offlist with a couple of people with JCL and BLKSIZE > and SPACE Sizing. I am trying to figure out how to make the formula more > accurate. > When I calculate space - I use full trace blocking. However, I find when > SDB uses half-track, my math is off. > </snip> > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
