|
View previous topic :: View next topic
|
| Author |
Message |
mikayag
New User
Joined: 10 Mar 2005
Posts: 16
|
|
|
|
I coded a program such that a new subroutine will be used (say PROGRAM1 calling subroutine SUBPROG2 instead of SUBPROG1). The JCL/program combo was workng fine in the development even if we tested it with several data.
When we deployed the new program PROGRAM1 (this time caling SUBPROG2), the JCL encountered ABEND S722 on the step where it was calling PROGRAM1 . Further analysis to the SDSF showed a "NO ACTIVE MODULE FOUND" on the step where it was calling the new program. Note that PROGRAM1 has no BIND since this is not a DB2 module. I checked the versions of the called subroutine SUBPROG2, it appeared that the GENERATE date on the COBOL does not match that of the BIND. Could it be possible that this is caused by mismatched BIND? I know S722 has something to do with the LINES and OUTLIM but increasing them did not help.
Pls help |
|
| Back to top |
|
 |
mikayag
New User
Joined: 10 Mar 2005
Posts: 16
|
|
|
|
| mikayag wrote: |
I coded a program such that a new subroutine will be used (say PROGRAM1 calling subroutine SUBPROG2 instead of SUBPROG1). The JCL/program combo was workng fine in the development even if we tested it with several data.
When we deployed the new program PROGRAM1 (this time caling SUBPROG2), the JCL encountered ABEND S722 on the step where it was calling PROGRAM1 . Further analysis to the SDSF showed a "NO ACTIVE MODULE FOUND" on the step where it was calling the new program. Note that PROGRAM1 has no BIND since this is not a DB2 module. I checked the versions of the called subroutine SUBPROG2, it appeared that the GENERATE date on the COBOL does not match that of the BIND. Could it be possible that this is caused by mismatched BIND? I know S722 has something to do with the LINES and OUTLIM but increasing them did not help.
Pls help |
When we backed out the newly deployed module, the JCL went through without any abend |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| What was being printed/punched that exceeded the bytes/cards/lines limit? Was it expected? |
|
| Back to top |
|
|
mikayag
New User
Joined: 10 Mar 2005
Posts: 16
|
|
|
|
Yes. It was not supposed to change the number of lines printed. It's just the subroutine that was changed. When we backed out the changes to the old subroutine, the job run successfully
| William Thompson wrote: |
| What was being printed/punched that exceeded the bytes/cards/lines limit? Was it expected? |
|
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| mikayag wrote: |
| Yes. It was not supposed to change the number of lines printed. It's just the subroutine that was changed. When we backed out the changes to the old subroutine, the job run successfully |
OK, what was the question of your original post? |
|
| Back to top |
|
|
mikayag
New User
Joined: 10 Mar 2005
Posts: 16
|
|
|
|
Could it be possible that this is caused by mismatched BIND?
| William Thompson wrote: |
| mikayag wrote: |
| Yes. It was not supposed to change the number of lines printed. It's just the subroutine that was changed. When we backed out the changes to the old subroutine, the job run successfully |
OK, what was the question of your original post? |
|
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| mikayag wrote: |
| Could it be possible that this is caused by mismatched BIND? |
Anything is possible, but why not nail down the cause directly?
What was being printed/punched that exceeded the bytes/cards/lines limit? Was the extra output expected? |
|
| Back to top |
|
|
|
|
