, since
the beginning of time.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John
McKown
Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL
Actually call flow is like below:
Enterprise Cobol - Assembler V2 (566896201
Hi Bill,
Actually call flow is like below:
Enterprise Cobol - Assembler V2 (566896201)
- High Level Assembler (569623400)
- OS/VS Cobol (5740CB103)
- Enterprise Cobol (5655G5300)
There are about 20 different program calls which are Assembler V2
Mürsel Ta#351;g#305;n wrote:
Hi Bill,
Actually call flow is like below:
Enterprise Cobol - Assembler V2 (566896201)
- High Level Assembler (569623400)
- OS/VS Cobol (5740CB103)
- Enterprise Cobol (5655G5300)
There are about 20 different program
On Thu, 23 Oct 2008 16:20:11 +0300, Mürsel Ta#351;g#305;n [EMAIL PROTECTED]
wrote:
Hi Bill,
Actually call flow is like below:
Enterprise Cobol - Assembler V2 (566896201)
- High Level Assembler (569623400)
- OS/VS Cobol (5740CB103)
- Enterprise
After talking to another co-worker, 2 more things come to mind:
1. If the OS/VS COBOL program is the one that opened the file and did not
close it, the COBOL library routines will NOT automatically close the file when
the application terminates. The COBOL library routines will only
Simple answer. LE used to clean up after sloppy Cobol programs which
failed to close all opened files... without making a fuss. VSCobol or
very latest Cobol, no difference, any and all Cobol programs which end and
leave files open. At some point, we hit it at OS390 2.10, LE stopped doing
On Wed, 22 Oct 2008 09:53:11 -0700, John Mattson wrote:
Simple answer. LE used to clean up after sloppy Cobol programs which
failed to close all opened files... without making a fuss. VSCobol or
very latest Cobol, no difference, any and all Cobol programs which end and
leave files open. At some
:17 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL
On Fri, 17 Oct 2008 11:04:51 -0500, Chase, John [EMAIL PROTECTED] wrote:
When we remove CEE.SCEERUN joblib statement from the JCL, the job
abends with C03:
IKJ56641I SYSTEM ABEND CODE C03 REASON
[mailto:[EMAIL PROTECTED] On Behalf
Of Rick Arellanes
Sent: Monday, October 20, 2008 8:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL
In the case of normal COBOL termination (e.g., GOBACK from main, STOP RUN,
etc.) or abnormal COBOL termination (e.g., abend
: Re: C03 abend when omitting CEE.SCEERUN from JCL
On Fri, 17 Oct 2008 10:20:44 -0500, Roach, Dennis
[EMAIL PROTECTED] wrote:
The cause could be ANY duplicate module in SCEERUN that is in LPA or ahead
of SCEERUN in linklist that gets invoked, directly or indirectly, by the
executing program
List [mailto:[EMAIL PROTECTED] On Behalf
Of Mark Zelden
Sent: Friday, October 17, 2008 7:17 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL
On Fri, 17 Oct 2008 11:04:51 -0500, Chase, John [EMAIL PROTECTED] wrote:
When we remove CEE.SCEERUN joblib statement
In the case of normal COBOL termination (e.g., GOBACK from main, STOP RUN,
etc.) or abnormal COBOL termination (e.g., abend with TRAP(ON) in effect),
COBOL will attempt to close any files that were left open and the C03 abend
will be avoided. However, if an assembler program dynamically loads a
A guess:
You may have something in front of SCEERUN on your either LNKLST or LPA
that overrides SCEERUN...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET
Further to that thought, you should also check for MLPAs or dynamic LPA
updates (via SETPROG).
Bill
On Fri, 17 Oct 2008 10:26:31 -0400, Jakubek, Jan [EMAIL PROTECTED] wrote:
A guess:
You may have something in front of SCEERUN on your either LNKLST or LPA
that overrides SCEERUN...
And ... MXI LPD * displays what's in the current, in VStorage, active
LPA...
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Big Iron
Sent: October 17, 2008 10:57 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C03 abend when omitting CEE.SCEERUN
The cause could be ANY duplicate module in SCEERUN that is in LPA or ahead of
SCEERUN in linklist that gets invoked, directly or indirectly, by the
executing program.
And ... MXI LPD * displays what's in the current, in VStorage, active LPA...
Further to that thought, you should also check
On Fri, 17 Oct 2008 10:20:44 -0500, Roach, Dennis
[EMAIL PROTECTED] wrote:
The cause could be ANY duplicate module in SCEERUN that is in LPA or ahead
of SCEERUN in linklist that gets invoked, directly or indirectly, by the
executing program.
And ... MXI LPD * displays what's in the current, in
On Fri, 17 Oct 2008 10:47:49 -0500, John McKown wrote:
I find duplicates using DDLIST in ISPF. On any command line, enter DDLIST.
Then enter LINKLIST to add the current LNKLST to the display. Then enter
ONLY LINKLIST to exclude all other allocations. Then enter DUPLICATES to see
what is
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of John McKown
On Fri, 17 Oct 2008 10:20:44 -0500, Roach, Dennis wrote:
The cause could be ANY duplicate module in SCEERUN that is in LPA or
ahead
of SCEERUN in linklist that gets invoked, directly or indirectly, by
On Fri, 17 Oct 2008 10:47:49 -0500, John McKown [EMAIL PROTECTED] wrote:
I find duplicates using DDLIST in ISPF. On any command line, enter DDLIST.
Then enter LINKLIST to add the current LNKLST to the display. Then enter
ONLY LINKLIST to exclude all other allocations. Then enter DUPLICATES to see
On Fri, 17 Oct 2008 11:04:51 -0500, Chase, John [EMAIL PROTECTED] wrote:
When we remove CEE.SCEERUN joblib statement from the JCL, the job
abends with C03:
IKJ56641I SYSTEM ABEND CODE C03 REASON CODE 0004
Note the message ID: It's a TSO message. Leads me to believe more
needs to be
21 matches
Mail list logo
