This is where I was getting an S0C4-38 in ICEF64A. I think that have found the
problem. However, I cannot do anything about it due to the fact that it is, I
believe, in a OEM product which we have a perpetual license for, and so did not
renew maintenance on it. I.e. we are unsupported. It
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of William M Klein
Sent: Thursday, September 09, 2010 5:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible DFSORT problem?
John,
You don't mention whether your Enterprise COBOL
PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible DFSORT problem?
John,
You don't mention whether your Enterprise COBOL 3.4 program was compiled
with FASTSRT or not. My guess is that it was. You might try recompiling
and running it with NOFASTSRT. You said (later in the thread) that you have
John,
You don't mention whether your Enterprise COBOL 3.4 program was compiled
with FASTSRT or not. My guess is that it was. You might try recompiling
and running it with NOFASTSRT. You said (later in the thread) that you have
created a PMR, but trying with NOFASTSRT might (or might not)
We are having a problem with a COBOL internal sort. If we run the job with no
PARM=, the job abends with U4082-2. If it runs with PARM='TRAP(OFF)', it abends
with S0C4-38 in ICEF64A. The latter dump has the following indicative dump:
SYSTEM COMPLETION CODE=0C4 REASON CODE=0038
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of McKown, John
Sent: Wednesday, September 08, 2010 10:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: Possible DFSORT problem?
We are having a problem with a COBOL internal sort. If we run
On 9/8/2010 8:29 AM, McKown, John wrote:
We are having a problem with a COBOL internal sort. If we run the job with no
PARM=, the job abends with U4082-2. If it runs with PARM='TRAP(OFF)', it abends
with S0C4-38 in ICEF64A. The latter dump has the following indicative dump:
SYSTEM COMPLETION
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Farley, Peter x23353
Sent: Wednesday, September 08, 2010 9:57 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible DFSORT problem?
snip
Um, and you are running in 64-bit mode with COBOL
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Steve Comstock
Sent: Wednesday, September 08, 2010 10:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible DFSORT problem?
snip
John,
It occurs to me to ask: what version
John McKown said
Sorry - DFSORT apparently did the AMODE switch to 64, not our code.
That's perfectly possible - if the sort was using a large memory object.
Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM
+44-7802-245-584
email:
John McKown on IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote
on 09/08/2010 07:29:44 AM:
We are having a problem with a COBOL internal sort. If we run the
job with no PARM=, the job abends with U4082-2. If it runs with
PARM='TRAP(OFF)', it abends with S0C4-38 in ICEF64A.
So, do I
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Yaeger
Sent: Wednesday, September 08, 2010 11:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible DFSORT problem?
John McKown on IBM Mainframe Discussion List
IBM-MAIN
12 matches
Mail list logo
