|
Thanks Alexei, I received an explanation from IBM, everything is said in APAR SA77534. They added a description of the reason code 18 to the message description in the next release (V4R4), and I'm on V4R3. pytel@us.ibm.com wrote: > > from LNR7801 message description: > ... The reason codes are as follows: > ... > 18 - The format of the external file definition. > ... > ... Recovery: > ... > For reason code 18, recompile any programs in the run unit that > contain an > external file definition for this file, and were compiled for a target > release lower than V4R2M0. > > Best regards > Alexei Pytel > > Vanja Jovic <vanja@ecn.ab.ca> on 10/06/99 12:12:45 AM > > Please respond to MIDRANGE-L@midrange.com > > To: midrange-l@midrange.com > cc: > Subject: ILE COBOL - Consistency check problem > > Hi all you ILE COBOL, export/import and OS version control gurus. > > I have a problem that starts to drive me crazy (slowly, but fast > enough). > > Here is the story: > Program A consists of COBOL modules A1, A2, A3, A4 and A5, created under > V3R7M0. A1 is PEP for program A and calls other modules. These modules > share a lot of > EXTERNAL data, among others 9 files. That works (used to work) fine. > > Now here is a trouble: > Modules A1, A2 and A3 are changed and recompiled under V4R3M0 and > program A is > recreated (CRTPGM) using newly created modules A1, A2, A3, and old, > unchanged > versions of A4 and A5 (we do keep our modules with programs, don't ask > why we > don't use UPDPGM). Now, when A1 calls A4, we get "Consistency check on > file" > for all 9 files (err. description attached), reason code 18 (yes, > eighteen). > > Firstly, modules were created in the same environment (e.g. none of > files > changed since first creation of modules and program, not to mention 9 of > them). > > For a last few days I was trying to find any single difference in file > definition or file usage between old and newly created versions of > modules. I > also checked all reasons for this type of error as they are listed in > ILE > COBOL/400 Reference, 2.5.2.1 Considerations for External files as well > as all > 17 possible reasons listed in the description for message LNR7801 (note > that > there are 17 different codes, but I got reason code 18). Nope. > > This problem is easily solved recompiling module A4 and recreating (or > updating) a program. But, we have a very rich ILE environment and I'd > like to know exact > reason for it. Same problem occurred few more times (caught in testing) > and I'd > hate an idea of recompiling everything created under V3. > > Now, I'm starting to think that there is something in V4R3 that won't > work > with V3R7. Especially because compiler under V4 can't create template > for V3, and > command CRTCBLMOD would let you put V3R7M0 as target release. > > Any ideas???? > > Vanja Jovic, > Canada > > Message ID . . . . . . . . . : LNR7801 > Message file . . . . . . . . : QLNRMSG > Library . . . . . . . . . : QSYS > > Message . . . . : Consistency check on file &7, reason code &1. > Cause . . . . . : The definition for external file &7 in COBOL program > &5 in > program object &3 in library &4 does not match the current definition > of > that file in use in the run-unit. The reason code identifies which > item > does > not match the current definition. The reason codes are as follows: > 01 - The record format level identifiers > 02 - The name specified on the ASSIGN TO clause > 03 - The ORGANIZATION or ACCESS mode > 04 - The OPTIONAL phrase > 05 - The external data item specified for the RELATIVE KEY phrase > 06 - The location of the record key within the associated record > 07 - The value for the maximum size of the block > 08 - The values for the maximum or minimum number of characters on > the > RECORD clause > 09 - The character set specified on the CODE-SET clause > 10 - The value specified for the DUPLICATES phrase > 11 - One or more of the values specified for the LINAGE clause > 12 - The specification of the attribute for the ASSIGN clause > 13 - The specification for the COMMITMENT CONTROL clause > 14 - The specification for the *DUPKEYCHK or the *INZDLT compile > time > option > 15 - The record blocking/deblocking information > 16 - No further information > 17 - The specification of the CCSID parameter for the CRTCBLMOD or > CRTBNDCBL CL commands. > Recovery . . . : > For reason code 01, recompile the program. > For reason code 14, recompile the program and specify the same > compile > time options as specified for other compilation units containing > definitions > of the external file. > For reason code 15, change the programs that use the external file > to > ensure that blocking/deblocking on the file will be performed > consistently > within those programs. > For reason code 17, recompile the program and specify the same CCSID > parameter value as specified for other compilation units containing > definitions of the external file. > For all other reason codes, change the definition of the external > file so > that it matches all other definitions of the same external file used > in the > run-unit. > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.