|
View previous topic :: View next topic
|
| Author |
Message |
M Lee Klein
New User
Joined: 08 Feb 2022
Posts: 39
Location: USA
|
|
|
|
I'm a database admin trying to figure out why files changes are not showing up when a COBOL program is executed. The error is
IGZ0201W A file attribute mismatch was detected. File ABCD-INPUT-FILE in program SX23F812 had a record length of 440 and the file specified in the ASSIGN clause had a record length of 520.
The program and the file both show the 520 so I'm wondering if some address space or buffer needs flushing.
I'm not familiar with COBOL as my experience is mostly Natural.
Any tips for getting the new program to get picked up? |
|
| Back to top |
|
 |
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2186
Location: USA
|
|
|
|
| M Lee Klein wrote: |
I'm a database admin trying to figure out why files changes are not showing up when a COBOL program is executed. The error is
IGZ0201W A file attribute mismatch was detected. File ABCD-INPUT-FILE in program SX23F812 had a record length of 440 and the file specified in the ASSIGN clause had a record length of 520.
The program and the file both show the 520 so I'm wondering if some address space or buffer needs flushing.
I'm not familiar with COBOL as my experience is mostly Natural.
Any tips for getting the new program to get picked up? |
Do you know that after any "update to COBOL program" it needs to be:
1) compiled (and optionally pre-compiled)
2) combined into a load module (and optionally BINDed to work with DB2)
3) the library with the updated load module needs to be available at job run time
Did you check that all those conditions are met? |
|
| Back to top |
|
|
M Lee Klein
New User
Joined: 08 Feb 2022
Posts: 39
Location: USA
|
|
|
|
| The developer ran their usual compile. Bind wasn't necessary as it was Adabas. #3 I presume was true but I will very that for my next step. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3083
Location: NYC,USA
|
|
|
|
| How about checking the JCL or a proc as to what is being used ? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8701
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
IGZ0201W A file attribute mismatch was detected. File ABCD-INPUT-FILE in program SX23F812 had a record length of 440 and the file specified in the ASSIGN clause had a record length of 520.
The program and the file both show the 520 so I'm wondering if some address space or buffer needs flushing. |
You are being told that the FD in the program SX23F812 has a total length of 440 while the physical data set has an LRECL of 520. There are a number of possible reasons for this:
- you are using an old copy of the program
- you are using an old copy of a copybook in the program
- you have a hard-coded FD in the program that has not been updated
- etc
Saying the program and the file both show the 520 is an error -- the program is telling you the length is 440. No buffer space or address space flush will fix this. Only finding out why the program is telling you the length is 440 will allow you to correct the error. |
|
| Back to top |
|
|
M Lee Klein
New User
Joined: 08 Feb 2022
Posts: 39
Location: USA
|
|
|
|
Is it possible that the old compiled code is executing instead of the new? How can the developer make a change to the program to show its the new version that is getting the mismatch error?
We do have an assembler router program that is executed upon every Cobol code. I'm wondering if it keeps the old code in cache or something.
I'm not a mainframe programmer so do not understand address space and buffers. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8701
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Is it possible that the old compiled code is executing instead of the new? How can the developer make a change to the program to show its the new version that is getting the mismatch error? |
Yes, it is very possible that the old compiled code is executing. z/OS uses special DD statements of JOBLIB and STEPLIB to point to the load library (or libraries) from which to pull the code (code can also be located in the LINKLIB which is a set of system load libraries that are always available). If the new compile is stored in a different load library from where the job gets the load module, then the old compile will be used. The developer should put some form of DISPLAY at the start of the program to identify the level of code, which simplifies figuring out which version is being executed. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2186
Location: USA
|
|
|
|
| M Lee Klein wrote: |
We do have an assembler router program that is executed upon every Cobol code. I'm wondering if it keeps the old code in cache or something. |
No, and No - to both questions.
The load module is looked for by its name in the standard order:
1) checking the (concatenated) libraries from //STEPLIB DD
2) checking the (concatenated) libraries from //JOBLIB DD
3) checking the system's LINKPACK area (The link pack area (LPA) contains all the common reentrant modules that are shared by the system.)
4) checking the series of system's LINKLIST libraries.
LINKLIST data sets are defined in SYS1.PARMLIB(PROGxx) by default. LPA data sets are defined in SYS1.PARMLIB(LPALSTxx). |
|
| Back to top |
|
|
|
|
