IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

COBOL program changes not showing up in job output


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
M Lee Klein

New User


Joined: 08 Feb 2022
Posts: 21
Location: USA

PostPosted: Fri Jun 09, 2023 1:05 am
Reply with quote

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
View user's profile Send private message
sergeyken

Senior Member


Joined: 29 Apr 2008
Posts: 1875
Location: USA

PostPosted: Fri Jun 09, 2023 7:43 pm
Reply with quote

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
View user's profile Send private message
M Lee Klein

New User


Joined: 08 Feb 2022
Posts: 21
Location: USA

PostPosted: Fri Jun 09, 2023 7:51 pm
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3013
Location: NYC,USA

PostPosted: Wed Jun 14, 2023 5:14 am
Reply with quote

How about checking the JCL or a proc as to what is being used ?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8692
Location: Dubuque, Iowa, USA

PostPosted: Wed Jun 14, 2023 6:19 pm
Reply with quote

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
View user's profile Send private message
M Lee Klein

New User


Joined: 08 Feb 2022
Posts: 21
Location: USA

PostPosted: Thu Jun 15, 2023 8:37 pm
Reply with 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?

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8692
Location: Dubuque, Iowa, USA

PostPosted: Fri Jun 16, 2023 12:34 am
Reply with quote

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
View user's profile Send private message
sergeyken

Senior Member


Joined: 29 Apr 2008
Posts: 1875
Location: USA

PostPosted: Fri Jun 16, 2023 1:06 am
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Changeman - how can we know the curr... Compuware & Other Tools 2
No new posts Joinkeys - 5 output files DFSORT/ICETOOL 7
No new posts DB2 Event passed to the Application P... DB2 1
No new posts How to pass the PARM value to my targ... COBOL Programming 4
No new posts Dynamically pass table name to a sele... DB2 2
Search our Forums:

Back to Top