z/OS doesn't emulate 3390's, the disk technology does. It also does so, for good reason, because the biggest issue with DASD is differing geometries. That would affect space allocation and the blocksizes that can be used.
Since there is no performance penalty for emulating a 3390, there is zero incentive for anyone to represent their disks as anything except a 3390. Adam -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Friday, May 19, 2017 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDB (system determined Blksize) 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
