<quote> You 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). </quote *NO* The binder and LE (as well as IIRC IEBCOPY) are smart enough to "fill the track" with "short blocks" when RECFM=U. i.e. The track would contain 2 blocks. (Block1 @ 32760 (32K-8)) and a "short block" of TRKLEN - Block1 - Inter block gap -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of David Spiegel Sent: Thursday, May 2, 2019 9:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Crazy concatenation mystery Hi Steve, You 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). Regards, David On 2019-05-02 21:57, Steve Smith wrote: > Well, Greg Price explained why the blksize issue doesn't arise in > normal execution. > > In addition, PDSEs don't really have a blksize; that is faked up on > the fly when BPAM or something similar is used. Program Fetch uses > something like DIV or paging I/O to load program objects. For classic > PDS, the blksize is "real", but again Program Fetch doesn't use access > methods, and doesn't care what size the blocks are. > > It's a little late in the day, but the received wisdom is that all > load libraries should have blksize=32K-8. That predates PDSE by > decades. The old linkage-editor was smart enough to fill tracks up > with whatever block size would fit. As long as it wasn't artificially > restricted to something less than the max. RECFM=U does not work like FB. > > btw, why are you running FA? Has it ever done anything useful for you? > > sas > > > > On Thu, May 2, 2019 at 8:42 PM Attila Fogarasi <fogar...@gmail.com> wrote: > >> The Binder is not invoked by Db2 when executing your application >> program -- hence no error message and successful execution. Fault >> Analyzer is invoking the Binder to get debugging info about the load >> module as part of its processing for the prior problem. Other >> debugging tools handle this more elegantly but FA chooses to just >> confuse you with the irrelevant cascaded error which has no bearing on the >> defect it is trying to report. >> Quick fix is to turn off Fault Analyzer as these "invalid" load >> module block sizes are perfectly valid for execution or even for use >> with the Binder with the right environment. For better or worse the >> Binder defaults to using 32760 (maximum device supported blksize) >> whenever possible, unless directed otherwise. >> >> On Fri, May 3, 2019 at 8:43 AM Jesse 1 Robinson >> <jesse1.robin...@sce.com> >> wrote: >> >>> Thanks to the many contributions to this thread, I think we have it >>> (mostly) figured out. The key was identifying what changed on 14 April. >> No >>> module changes. No JCL changes. But of course something happened >>> that I didn't mention earlier because 'it could not be the cause'. >>> What happened on the 14th was an error in the data that caused an >>> SQL duplicate record condition, or 811. That led to a U3003 abend, >>> which woke up Fault >> Analyzer >>> *for the first time*. Upon awakening, he looked around and saw the >> invalid >>> module block sizes and complained about them. For literally years FA >>> had never peeped because there had never been an actual abend. Why >>> did fetch not bellyache about BLKSIZE? I have no idea. The module >>> named in the >> message > ---------------------------------------------------------------------- > 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
