Well, if this was StackOverflow, I'd vote this answer up. Also, I think the U3003 may be what instigated the problem, as opposed to being one FA issued.
sas On Thu, May 2, 2019 at 4:41 AM Greg Price <[email protected]> wrote: > On 2019-05-02 9:51 AM, Jesse 1 Robinson wrote: > > This is almost nutty enough to be a weekend post, but it's a live > production environment, so here goes. We have a prod job (batch Db2) that > has run daily for years. Suddenly on 14 April it started abending with this > message from Fault Analyzer: > > > > 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 > > > > So this is all absolutely true. The module*is* 32760 while the PDS*is* > 19069-the ancient 3350 track size that was fairly standard for load > libraries in the Dark Ages. So what's the mystery? How on earth did the 13 > April and*all previous* runs work OK? > > Here's my theory... > > So you have this set up all ticking over nicely, and it works for years. > > And then one day the application has a problem (an abend?) which causes > Fault Analyzer to wake up and think: "I better look into this!" > > So then FA decides to make some Binder API calls to get the low-down on > this application program, and it is this I/O which does not work > properly because of the block size in the data set label being smaller > than an actual block in the program. > > Of course, program fetch does not care about such niceties because he > makes his own channel programs with numbers from control information and > therefore ignores DCB attributes in the VTOC entry. > > So, no application problems means that the block size mismatch is not > exposed. Application problems means that the automatic application > problem looker-at-er tries to do "normal" I/O to the library which > exposes the block size mismatch. > > Cheers, > Greg > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
