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
