No. See my previous reply to an earlier email in this thread. -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of David Spiegel Sent: Friday, May 3, 2019 5:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Crazy concatenation mystery
Hi Greg, If someone uses BLKSIZE=32760, isn't it true that only one physical block fits on a (emulated) 3390 track, thereby definitely wasting (2*27998)-32760=23236 bytes per track (regardless of any Program Binder considerations)? Thanks and regards, David On 2019-05-03 03:41, Greg Price wrote: > On 2019-05-03 12:15 PM, David Spiegel wrote: >> Steve said: "... but the received wisdom is that all load libraries >> should have blksize=32K-8. ..." >> >> For optimal space usage, however, the BLKSIZE should be 27998 (i.e. >> half-track blocking). > > You might think that, but for load modules, you have to realize that > in-between the text blocks (which could be 27998 bytes long in your > scenario) there are RLD and/or CTL records which means that no single > track could contain 2 full-sized text blocks. > > Because of the "random" sizes of CSECTs and RLD usage (where "random" > means not really knowable at load library data set creation time) it > is not possible to know the best block size to use to minimize the > disk space used by a set of programs without doing some sort of > analysis on the load modules to be housed in that library. > > I mention CSECT because once a text block has some data to the end of > a section, the next section will not be started in that block unless > the whole section will fit in that block. That is why you see short > text blocks even though there is plenty more object text that follows on. > > And even though the linkage editor may make good use of remaining > track space, what happens when the blocks a shifted around by a data > set copy or a compress? > > So, it may be that BLKSIZE=32760 really is the best advice. At least > you could reasonably hope to minimize the amount of disk space wasted > on inter-block gaps. (Of course, inter-block gaps may well be > emulated away these days, but they still exist for 3390 CKD accounting > purposes.) > > And as for PDSE program object libraries - how about this? > > If the BLKSIZE value doesn't matter in terms of how programs are > stored in the PDSE and fetched at run time, what about using > BLKSIZE=4096 for PDSE load libraries? > > Why? Because if you browse a program object in a PDSE and scroll > right, you will notice that all of the blocks end at column 4096. So > to read that member you have acquired 32760-byte buffers when > 4096-byte buffers would have sufficed. > :) > > In practice, 32760 for all program libraries is probably the best > choice to remove any block size hassles even if occasionally it causes > more storage to be used. After all, I keep hearing that storage is cheap. > > Just my thoughts, of course... > > Cheers, > Greg > > ---------------------------------------------------------------------- > 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 ::DISCLAIMER:: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
