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
