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
>
>
> IEW2541S 471A MEMBER CUA625 IDENTIFIED BY DDNAME JOBLIB WITH
> CONCATENATION
>
> NUMBER 1 CONTAINS A BLOCK OF SIZE 32760 WHICH IS LONGER THAN
> THE
>
> DATA SET BLKSIZE.
>
> IDI0010E IEWBIND error INCLUDE CUA625 rc=83000507
>
> IDI0002I Module CUA625, program CUA625, offset X'7712': Abend U3003
>
> is invoked under PGM=IKJEFT01 by the statement
>
> DSN SYSTEM(DB04)
> RUN PROG (CUA625) -
> PLAN (CUA625P) -
> PARM ('10Open_WO_Cntr~ CSV+
> GO2NTFTP01 40026 ')
>
> So the job could not possibly run without executing program CUA625 every
> time. Even though his block size exceeded the PDS value, it escaped
> attention.
>
> For completeness, below is a summary of the JOBLIB concatenation. As I
> said, lots of (fixable) problems, but none of them triggered FA until the
> SQL error.
>
>
> LOALIB1
> Defined BLKSIZE 19069
> Several members exceed that, largest being 32,760
>
> LOALIB2
> Defined BLKSIZE 32760
> Several members have naming errors such as-but not limited to-ALIAS. No
> BLKSIZE errors by StarTool
>
> LOALIB3
> Defined BLKSIZE 19069
> Several members exceed that, largest being 32,760
> CUF040 gets ABEND106-0F loading CUF040
>
> LOALIB4
> Defined BLKSIZE 27999 (!!!)
> PDS is empty
>
> LOALIB5
> PDSE (Library)
> Defined BLKSIZE is 27999 (!!!)
> OLDYNAM2 gets ABEND706-04 loading OLDYNAM2
> No BLKSIZE errors reported by StarTool
>
>
> .
> .
> 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<mailto:robin...@sce.com>
>
>
> ----------------------------------------------------------------------
> 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
