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 <[email protected]> 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 <[email protected]> >> 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 [email protected] with the message: INFO IBM-MAIN > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
