Re: S0C4 XL C Compiler
Since hello world worked, most user's probably aren't experiencing this problem. At this point, you just need to wait for IBM to create a fix or circumvention. Good luck. Jon. On Tuesday, August 27, 2019, 05:34:27 AM PDT, Joseph Reichman wrote: Yes worked > On Aug 26, 2019, at 10:14 PM, Jon Perryman wrote: > > Did you compile the hello world example and it abended? I can't believe this > won't compile. IBM does QA so it's hard to believe the commonly used features > fail with this abend. > CEETEST and DLL are used less. The abend is probably occurring for one of > these. > You can just wait for IBM since they could recreate your problem. > Jon. > > On Monday, August 26, 2019, 05:34:42 PM PDT, Joseph Reichman > wrote: > > I tried amode 31 and got an abend I did take some of the includes out I am > surprised I came up with it how many shops use XL C they should abending as > well > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
It's not the complexity of your code that matters, it's the complexity of the
code in the compiler.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Joseph Reichman
Sent: Tuesday, August 27, 2019 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
I have question
If you saw my code it wasn’t complicated a call to debug tool a call to DLL
I would imagine this must of happened to some company using XL C
> On Aug 27, 2019, at 11:25 AM, Seymour J Metz wrote:
>
> I've been programming for over half a century, and one thing that I can
> assure you of is that until you dig into the code you don't have a clue how
> easy the fix will be. Things that you thought would be trivial turn out to be
> intractable and things that you thought were difficult turn out to be trivial.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf of
> Joseph Reichman
> Sent: Monday, August 26, 2019 7:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> Jon
>
> You are right on I saw those messages from the compiler
> I tried to take out a number statements and still got it
>
> I opened a PMR with IBM they said they were able to recreate the problem and
> would get back to me wednesday
>
> I would think this would take 5 minutes to fix
>
> I saw some free C compilers E.G. GCCMVS wonder if they have a debugger
> probably cannt run AMODE64
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Jon Perryman
> Sent: Monday, August 26, 2019 7:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> You never mentioned this this was a compile time abend. I assumed it was a
> run time abend.
>
> Compile the hello world to make sure it's not a general compiler problem.
>
> Add statements gradually. When it starts abending, that should be the
> statement causing the problem.
>
> I suspect a header is causing the problem. Maybe something as simple as a
> macro calling it's self.
>
> Jon.On Monday, August 26, 2019, 05:48:21 AM PDT, Allan Staller
> wrote:
>
> I would suggest hard coding (at least) a 150M or greater region. This
> optimizer code is about 120M.
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Joseph Reichman
> Sent: Saturday, August 24, 2019 8:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> REGION=0M I Think that's the max
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Charles Mills
> Sent: Saturday, August 24, 2019 9:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> Try increasing the region.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Saturday, August 24, 2019 6:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: S0C4 XL C Compiler
>
>
>
> Simple little program cannt believe it
>
>
>
>#include
>
>#include
>
>#include
>
>#include
>
>#include
>
>#include
>
>#pragma map(__ceetest,"CEETEST")
>
>#pragma linkage(CEETEST,OS_NOSTACK)
>
> main( int argc, char* argv[])
>
>{
>
>typedef int (DLL_FN)(char *)
>
>dllhandle* dllHandle;
>
> DLL_FN* fn;
>
>_VSTRING commands;
>
> _FEEDBACK fc;
>
>
> CEETEST(,);
>
> dllHandle = dllload("SYSADATA");
>
> fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
>
> fn("SYSADATA");
>
> return;
>
> }
>
>
>
>CEE3204S The system detected a protection exception (System Completion
> Code=0C4).
>
> From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
> at statement 729 at compile unit offset
>
> +0510 at entry offset +0510 at address 21DEB1B8.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
Re: S0C4 XL C Compiler
I have question
If you saw my code it wasn’t complicated a call to debug tool a call to DLL
I would imagine this must of happened to some company using XL C
> On Aug 27, 2019, at 11:25 AM, Seymour J Metz wrote:
>
> I've been programming for over half a century, and one thing that I can
> assure you of is that until you dig into the code you don't have a clue how
> easy the fix will be. Things that you thought would be trivial turn out to be
> intractable and things that you thought were difficult turn out to be trivial.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf of
> Joseph Reichman
> Sent: Monday, August 26, 2019 7:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> Jon
>
> You are right on I saw those messages from the compiler
> I tried to take out a number statements and still got it
>
> I opened a PMR with IBM they said they were able to recreate the problem and
> would get back to me wednesday
>
> I would think this would take 5 minutes to fix
>
> I saw some free C compilers E.G. GCCMVS wonder if they have a debugger
> probably cannt run AMODE64
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Jon Perryman
> Sent: Monday, August 26, 2019 7:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> You never mentioned this this was a compile time abend. I assumed it was a
> run time abend.
>
> Compile the hello world to make sure it's not a general compiler problem.
>
> Add statements gradually. When it starts abending, that should be the
> statement causing the problem.
>
> I suspect a header is causing the problem. Maybe something as simple as a
> macro calling it's self.
>
> Jon.On Monday, August 26, 2019, 05:48:21 AM PDT, Allan Staller
> wrote:
>
> I would suggest hard coding (at least) a 150M or greater region. This
> optimizer code is about 120M.
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Joseph Reichman
> Sent: Saturday, August 24, 2019 8:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> REGION=0M I Think that's the max
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Charles Mills
> Sent: Saturday, August 24, 2019 9:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> Try increasing the region.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Saturday, August 24, 2019 6:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: S0C4 XL C Compiler
>
>
>
> Simple little program cannt believe it
>
>
>
>#include
>
>#include
>
>#include
>
>#include
>
>#include
>
>#include
>
>#pragma map(__ceetest,"CEETEST")
>
>#pragma linkage(CEETEST,OS_NOSTACK)
>
> main( int argc, char* argv[])
>
>{
>
>typedef int (DLL_FN)(char *)
>
>dllhandle* dllHandle;
>
> DLL_FN* fn;
>
>_VSTRING commands;
>
> _FEEDBACK fc;
>
>
> CEETEST(,);
>
> dllHandle = dllload("SYSADATA");
>
> fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
>
> fn("SYSADATA");
>
> return;
>
> }
>
>
>
>CEE3204S The system detected a protection exception (System Completion
> Code=0C4).
>
> From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
> at statement 729 at compile unit offset
>
> +0510 at entry offset +0510 at address 21DEB1B8.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> --
Re: S0C4 XL C Compiler
I've been programming for over half a century, and one thing that I can assure
you of is that until you dig into the code you don't have a clue how easy the
fix will be. Things that you thought would be trivial turn out to be
intractable and things that you thought were difficult turn out to be trivial.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Joseph Reichman
Sent: Monday, August 26, 2019 7:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Jon
You are right on I saw those messages from the compiler
I tried to take out a number statements and still got it
I opened a PMR with IBM they said they were able to recreate the problem and
would get back to me wednesday
I would think this would take 5 minutes to fix
I saw some free C compilers E.G. GCCMVS wonder if they have a debugger probably
cannt run AMODE64
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Monday, August 26, 2019 7:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
You never mentioned this this was a compile time abend. I assumed it was a run
time abend.
Compile the hello world to make sure it's not a general compiler problem.
Add statements gradually. When it starts abending, that should be the statement
causing the problem.
I suspect a header is causing the problem. Maybe something as simple as a macro
calling it's self.
Jon.On Monday, August 26, 2019, 05:48:21 AM PDT, Allan Staller
wrote:
I would suggest hard coding (at least) a 150M or greater region. This
optimizer code is about 120M.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Saturday, August 24, 2019 8:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
REGION=0M I Think that's the max
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Saturday, August 24, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of
Re: S0C4 XL C Compiler
Yes worked > On Aug 26, 2019, at 10:14 PM, Jon Perryman wrote: > > Did you compile the hello world example and it abended? I can't believe this > won't compile. IBM does QA so it's hard to believe the commonly used features > fail with this abend. > CEETEST and DLL are used less. The abend is probably occurring for one of > these. > You can just wait for IBM since they could recreate your problem. > Jon. > >On Monday, August 26, 2019, 05:34:42 PM PDT, Joseph Reichman > wrote: > > I tried amode 31 and got an abend I did take some of the includes out I am > surprised I came up with it how many shops use XL C they should abending as > well > > >> On Aug 26, 2019, at 8:29 PM, Jon Perryman wrote: >> >> Finding the compile time problem could take some time. If it's a missing >> ifdef or looping macro, then it will be an easy fix but more difficult to >> find because it will be in an include.. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
Did you compile the hello world example and it abended? I can't believe this won't compile. IBM does QA so it's hard to believe the commonly used features fail with this abend. CEETEST and DLL are used less. The abend is probably occurring for one of these. You can just wait for IBM since they could recreate your problem. Jon. On Monday, August 26, 2019, 05:34:42 PM PDT, Joseph Reichman wrote: I tried amode 31 and got an abend I did take some of the includes out I am surprised I came up with it how many shops use XL C they should abending as well > On Aug 26, 2019, at 8:29 PM, Jon Perryman wrote: > > Finding the compile time problem could take some time. If it's a missing > ifdef or looping macro, then it will be an easy fix but more difficult to > find because it will be in an include.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
On 2019-08-27 7:14 AM, Joseph Reichman wrote: I opened a PMR with IBM they said they were able to recreate the problem and would get back to me wednesday I would think this would take 5 minutes to fix It might take them 5 minutes to fix the bug but the whole process of getting it tested, built (FIXTEST) and sent to a customer may take a little bit longer. I do some Level 3 support work on IBM products so I can relate to that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
I only situation I can think of where I could raise a SEV 1 for a compiler ABEND is if it always abended. In my experience I haven't found a compiler abend yet that I couldn't work around. On 2019-08-27 12:03 AM, Charles Mills wrote: Drifting off-topic here but when I owned a company with a roomful of developers it used to annoy me that "CICS is down and all our clerks are dead in the water" was worthy of a Sev 1 in IBM's mind but "the C compiler is down and all our programmers are dead in the water" was not. "That's a development issue, not a production issue." I'm sorry, but what we DO here -- our production as it were -- is development. We produce software products. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Monday, August 26, 2019 5:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C4 XL C Compiler A Sev 1 PMR? They're quite rare and usually used for important stuff like "DB2 is hosed and I can't run production work" :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
I tried amode 31 and got an abend I did take some of the includes out I am surprised I came up with it how many shops use XL C they should abending as well > On Aug 26, 2019, at 8:29 PM, Jon Perryman wrote: > > Finding the compile time problem could take some time. If it's a missing > ifdef or looping macro, then it will be an easy fix but more difficult to > find because it will be in an include.. > > This is a compiler abend. MAIN does not have anything obvious missing to > cause a compiler abend so the problem is most likely in an include. That's > why I said try hello world program. > > I seriously doubt you need more than 2GB (AMODE 31 region=0M). Do you really > believe you have an AMODE64 problem? You could try compiling a standard C > debugger with IBM C. I don't believe GCCMVS is amode64 compatible yet but I > could be wrong. Someone is working on it at this time but I would be leary of > his assumptions. > > Jon. > >On Monday, August 26, 2019, 04:14:54 PM PDT, Joseph Reichman > wrote: > > Jon > > You are right on I saw those messages from the compiler > I tried to take out a number statements and still got it > > I opened a PMR with IBM they said they were able to recreate the problem and > would get back to me wednesday > > I would think this would take 5 minutes to fix > > I saw some free C compilers E.G. GCCMVS wonder if they have a debugger > probably cannt run AMODE64 > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Jon Perryman > Sent: Monday, August 26, 2019 7:09 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S0C4 XL C Compiler > > You never mentioned this this was a compile time abend. I assumed it was a > run time abend. > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
Finding the compile time problem could take some time. If it's a missing ifdef or looping macro, then it will be an easy fix but more difficult to find because it will be in an include.. This is a compiler abend. MAIN does not have anything obvious missing to cause a compiler abend so the problem is most likely in an include. That's why I said try hello world program. I seriously doubt you need more than 2GB (AMODE 31 region=0M). Do you really believe you have an AMODE64 problem? You could try compiling a standard C debugger with IBM C. I don't believe GCCMVS is amode64 compatible yet but I could be wrong. Someone is working on it at this time but I would be leary of his assumptions. Jon. On Monday, August 26, 2019, 04:14:54 PM PDT, Joseph Reichman wrote: Jon You are right on I saw those messages from the compiler I tried to take out a number statements and still got it I opened a PMR with IBM they said they were able to recreate the problem and would get back to me wednesday I would think this would take 5 minutes to fix I saw some free C compilers E.G. GCCMVS wonder if they have a debugger probably cannt run AMODE64 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Monday, August 26, 2019 7:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C4 XL C Compiler You never mentioned this this was a compile time abend. I assumed it was a run time abend. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
Jon
You are right on I saw those messages from the compiler
I tried to take out a number statements and still got it
I opened a PMR with IBM they said they were able to recreate the problem and
would get back to me wednesday
I would think this would take 5 minutes to fix
I saw some free C compilers E.G. GCCMVS wonder if they have a debugger probably
cannt run AMODE64
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Monday, August 26, 2019 7:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
You never mentioned this this was a compile time abend. I assumed it was a run
time abend.
Compile the hello world to make sure it's not a general compiler problem.
Add statements gradually. When it starts abending, that should be the statement
causing the problem.
I suspect a header is causing the problem. Maybe something as simple as a macro
calling it's self.
Jon.On Monday, August 26, 2019, 05:48:21 AM PDT, Allan Staller
wrote:
I would suggest hard coding (at least) a 150M or greater region. This
optimizer code is about 120M.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Saturday, August 24, 2019 8:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
REGION=0M I Think that's the max
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Saturday, August 24, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of HCL is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any email and/or attachments, please check them for
viruses and other defects.
--
---
Re: S0C4 XL C Compiler
You never mentioned this this was a compile time abend. I assumed it was a run
time abend.
Compile the hello world to make sure it's not a general compiler problem.
Add statements gradually. When it starts abending, that should be the statement
causing the problem.
I suspect a header is causing the problem. Maybe something as simple as a macro
calling it's self.
Jon.On Monday, August 26, 2019, 05:48:21 AM PDT, Allan Staller
wrote:
I would suggest hard coding (at least) a 150M or greater region. This
optimizer code is about 120M.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Saturday, August 24, 2019 8:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
REGION=0M I Think that's the max
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Saturday, August 24, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of HCL is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any email and/or attachments, please check them for
viruses and other defects.
--
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
Drifting off-topic here but when I owned a company with a roomful of developers it used to annoy me that "CICS is down and all our clerks are dead in the water" was worthy of a Sev 1 in IBM's mind but "the C compiler is down and all our programmers are dead in the water" was not. "That's a development issue, not a production issue." I'm sorry, but what we DO here -- our production as it were -- is development. We produce software products. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Monday, August 26, 2019 5:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C4 XL C Compiler A Sev 1 PMR? They're quite rare and usually used for important stuff like "DB2 is hosed and I can't run production work" :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
They told me they would get back to me today
> On Aug 26, 2019, at 8:51 AM, David Crayford wrote:
>
> A Sev 1 PMR? They're quite rare and usually used for important stuff like
> "DB2 is hosed and I can't run production work" :)
>
> On 2019-08-25 10:29 PM, Joseph Reichman wrote:
>> JUST CODED region=1000M same abend opened up SEV 1 PMR with IBM but I told
>> them they could wait till Monday
>>
>>
>> thanks
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of
>> Lizette Koehler
>> Sent: Sunday, August 25, 2019 10:03 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: S0C4 XL C Compiler
>>
>> Sometimes 0M or 0G will cause problems with RTM. You might want to try a
>> real larger number like 512M or 1000M
>>
>> If there is no below the line storage available for recovery then 0M can
>> cause some really strange occurrences.
>>
>> What does your virtual storage look like when your job ends?
>>
>> Lizette
>>
>>
>>> -----Original Message-
>>> From: IBM Mainframe Discussion List On
>>> Behalf Of Charles Mills
>>> Sent: Sunday, August 25, 2019 6:58 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: S0C4 XL C Compiler
>>>
>>> REGION=0G will give you a thousand times more.
>>>
>>> Seriously, I had one of these the other day. I ran a C++ compile --
>>> not with my usual JCL -- and got a S0C4. Like you, I went "I can't
>>> believe this!" I tried something simple and the problem went away --
>>> don't recall what it was that I did, so thought perhaps it was that I
>>> had increased the region. The problem was so out of left field and so
>>> quickly fixed that I do not recall the circumstances. Was within the
>>> last month, so perhaps some recent maintenance broke the compiler.
>>>
>>> Charles
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Joseph Reichman
>>> Sent: Saturday, August 24, 2019 6:40 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: S0C4 XL C Compiler
>>>
>>> REGION=0M I Think that's the max
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List On
>>> Behalf Of Charles Mills
>>> Sent: Saturday, August 24, 2019 9:36 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: S0C4 XL C Compiler
>>>
>>> Try increasing the region.
>>>
>>> Charles
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Joseph Reichman
>>> Sent: Saturday, August 24, 2019 6:27 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: S0C4 XL C Compiler
>>>
>>>
>>>
>>> Simple little program cannt believe it
>>>
>>>
>>>
>>> #include
>>>
>>> #include
>>>
>>> #include
>>>
>>> #include
>>>
>>> #include
>>>
>>> #include
>>>
>>> #pragma map(__ceetest,"CEETEST")
>>>
>>> #pragma linkage(CEETEST,OS_NOSTACK)
>>>
>>> main( int argc, char* argv[])
>>>
>>> {
>>>
>>> typedef int (DLL_FN)(char *)
>>>
>>> dllhandle* dllHandle;
>>>
>>> DLL_FN* fn;
>>>
>>> _VSTRING commands;
>>>
>>> _FEEDBACK fc;
>>>
>>>
>>> CEETEST(,);
>>>
>>> dllHandle = dllload("SYSADATA");
>>>
>>> fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
>>>
>>> fn("SYSADATA");
>>>
>>> return;
>>>
>>> }
>>>
>>>
>>>
>>> CEE3204S The system detected a protection exception (System
>>> Completion Code=0C4).
>>>
>>> From entry point
>>> dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
>>> at statement 729 at compile unit offset
>>>
>>> +0510 at entry offset +0510 at address 21DEB1B8.
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email
>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
I did 0M 1000M all same results
> On Aug 26, 2019, at 8:47 AM, Allan Staller wrote:
>
> I would suggest hard coding (at least) a 150M or greater region. This
> optimizer code is about 120M.
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Joseph Reichman
> Sent: Saturday, August 24, 2019 8:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> REGION=0M I Think that's the max
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Charles Mills
> Sent: Saturday, August 24, 2019 9:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> Try increasing the region.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Saturday, August 24, 2019 6:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: S0C4 XL C Compiler
>
>
>
> Simple little program cannt believe it
>
>
>
> #include
>
> #include
>
> #include
>
> #include
>
> #include
>
> #include
>
> #pragma map(__ceetest,"CEETEST")
>
> #pragma linkage(CEETEST,OS_NOSTACK)
>
> main( int argc, char* argv[])
>
> {
>
> typedef int (DLL_FN)(char *)
>
> dllhandle* dllHandle;
>
> DLL_FN* fn;
>
> _VSTRING commands;
>
> _FEEDBACK fc;
>
>
> CEETEST(,);
>
> dllHandle = dllload("SYSADATA");
>
> fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
>
> fn("SYSADATA");
>
> return;
>
> }
>
>
>
>CEE3204S The system detected a protection exception (System Completion
> Code=0C4).
>
> From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
> at statement 729 at compile unit offset
>
> +0510 at entry offset +0510 at address 21DEB1B8.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> --
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses
> in transmission. The e mail and its contents (with or without referred
> errors) shall therefore not attach any liability on the originator or HCL or
> its affiliates. Views or opinions, if any, presented in this email are solely
> those of the author and may not necessarily reflect the views or opinions of
> HCL or its affiliates. Any form of reproduction, dissemination, copying,
> disclosure, modification, distribution and / or publication of this message
> without the prior written consent of authorized representative of HCL is
> strictly prohibited. If you have received this email in error please delete
> it and notify the sender immediately. Before opening any email and/or
> attachments, please check them for viruses and other defects.
> --
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
A Sev 1 PMR? They're quite rare and usually used for important stuff
like "DB2 is hosed and I can't run production work" :)
On 2019-08-25 10:29 PM, Joseph Reichman wrote:
JUST CODED region=1000M same abend opened up SEV 1 PMR with IBM but I told
them they could wait till Monday
thanks
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: Sunday, August 25, 2019 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Sometimes 0M or 0G will cause problems with RTM. You might want to try a
real larger number like 512M or 1000M
If there is no below the line storage available for recovery then 0M can
cause some really strange occurrences.
What does your virtual storage look like when your job ends?
Lizette
-Original Message-
From: IBM Mainframe Discussion List On
Behalf Of Charles Mills
Sent: Sunday, August 25, 2019 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
REGION=0G will give you a thousand times more.
Seriously, I had one of these the other day. I ran a C++ compile --
not with my usual JCL -- and got a S0C4. Like you, I went "I can't
believe this!" I tried something simple and the problem went away --
don't recall what it was that I did, so thought perhaps it was that I
had increased the region. The problem was so out of left field and so
quickly fixed that I do not recall the circumstances. Was within the
last month, so perhaps some recent maintenance broke the compiler.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
REGION=0M I Think that's the max
-Original Message-
From: IBM Mainframe Discussion List On
Behalf Of Charles Mills
Sent: Saturday, August 24, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System
Completion Code=0C4).
From entry point
dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
I would suggest hard coding (at least) a 150M or greater region. This optimizer
code is about 120M.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Saturday, August 24, 2019 8:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
REGION=0M I Think that's the max
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Saturday, August 24, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of HCL is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any email and/or attachments, please check them for
viruses and other defects.
--
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
JUST CODED region=1000M same abend opened up SEV 1 PMR with IBM but I told
them they could wait till Monday
thanks
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: Sunday, August 25, 2019 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Sometimes 0M or 0G will cause problems with RTM. You might want to try a
real larger number like 512M or 1000M
If there is no below the line storage available for recovery then 0M can
cause some really strange occurrences.
What does your virtual storage look like when your job ends?
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Charles Mills
> Sent: Sunday, August 25, 2019 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> REGION=0G will give you a thousand times more.
>
> Seriously, I had one of these the other day. I ran a C++ compile --
> not with my usual JCL -- and got a S0C4. Like you, I went "I can't
> believe this!" I tried something simple and the problem went away --
> don't recall what it was that I did, so thought perhaps it was that I
> had increased the region. The problem was so out of left field and so
> quickly fixed that I do not recall the circumstances. Was within the
> last month, so perhaps some recent maintenance broke the compiler.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Joseph Reichman
> Sent: Saturday, August 24, 2019 6:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> REGION=0M I Think that's the max
>
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Charles Mills
> Sent: Saturday, August 24, 2019 9:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> Try increasing the region.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Joseph Reichman
> Sent: Saturday, August 24, 2019 6:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: S0C4 XL C Compiler
>
>
>
> Simple little program cannt believe it
>
>
>
> #include
>
> #include
>
> #include
>
> #include
>
> #include
>
> #include
>
> #pragma map(__ceetest,"CEETEST")
>
> #pragma linkage(CEETEST,OS_NOSTACK)
>
> main( int argc, char* argv[])
>
> {
>
> typedef int (DLL_FN)(char *)
>
> dllhandle* dllHandle;
>
> DLL_FN* fn;
>
> _VSTRING commands;
>
> _FEEDBACK fc;
>
>
> CEETEST(,);
>
> dllHandle = dllload("SYSADATA");
>
> fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
>
> fn("SYSADATA");
>
> return;
>
> }
>
>
>
> CEE3204S The system detected a protection exception (System
> Completion Code=0C4).
>
> From entry point
> dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
> at statement 729 at compile unit offset
>
> +0510 at entry offset +0510 at address 21DEB1B8.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
Sometimes 0M or 0G will cause problems with RTM. You might want to try a real
larger number like 512M or 1000M
If there is no below the line storage available for recovery then 0M can cause
some really strange occurrences.
What does your virtual storage look like when your job ends?
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Charles Mills
> Sent: Sunday, August 25, 2019 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> REGION=0G will give you a thousand times more.
>
> Seriously, I had one of these the other day. I ran a C++ compile -- not with
> my usual JCL -- and got a S0C4. Like you, I went "I can't believe this!" I
> tried something simple and the problem went away -- don't recall what it was
> that I did, so thought perhaps it was that I had increased the region. The
> problem was so out of left field and so quickly fixed that I do not recall
> the circumstances. Was within the last month, so perhaps some recent
> maintenance broke the compiler.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Saturday, August 24, 2019 6:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> REGION=0M I Think that's the max
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Charles Mills
> Sent: Saturday, August 24, 2019 9:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 XL C Compiler
>
> Try increasing the region.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Saturday, August 24, 2019 6:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: S0C4 XL C Compiler
>
>
>
> Simple little program cannt believe it
>
>
>
> #include
>
> #include
>
> #include
>
> #include
>
> #include
>
> #include
>
> #pragma map(__ceetest,"CEETEST")
>
> #pragma linkage(CEETEST,OS_NOSTACK)
>
> main( int argc, char* argv[])
>
> {
>
> typedef int (DLL_FN)(char *)
>
> dllhandle* dllHandle;
>
> DLL_FN* fn;
>
> _VSTRING commands;
>
> _FEEDBACK fc;
>
>
> CEETEST(,);
>
> dllHandle = dllload("SYSADATA");
>
> fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
>
> fn("SYSADATA");
>
> return;
>
> }
>
>
>
> CEE3204S The system detected a protection exception (System Completion
> Code=0C4).
>
> From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
> at statement 729 at compile unit offset
>
> +0510 at entry offset +0510 at address 21DEB1B8.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
REGION=0G will give you a thousand times more.
Seriously, I had one of these the other day. I ran a C++ compile -- not with
my usual JCL -- and got a S0C4. Like you, I went "I can't believe this!" I
tried something simple and the problem went away -- don't recall what it was
that I did, so thought perhaps it was that I had increased the region. The
problem was so out of left field and so quickly fixed that I do not recall
the circumstances. Was within the last month, so perhaps some recent
maintenance broke the compiler.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
REGION=0M I Think that's the max
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Saturday, August 24, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
I'm guessing that not setting commands is causing your problem.
Jon
On Saturday, August 24, 2019, 06:27:05 PM PDT, Joseph Reichman
wrote:
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
Opened a pmr with IBM
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Saturday, August 24, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
REGION=0M I Think that's the max
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Saturday, August 24, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 XL C Compiler
Try increasing the region.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Saturday, August 24, 2019 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4 XL C Compiler
Simple little program cannt believe it
#include
#include
#include
#include
#include
#include
#pragma map(__ceetest,"CEETEST")
#pragma linkage(CEETEST,OS_NOSTACK)
main( int argc, char* argv[])
{
typedef int (DLL_FN)(char *)
dllhandle* dllHandle;
DLL_FN* fn;
_VSTRING commands;
_FEEDBACK fc;
CEETEST(,);
dllHandle = dllload("SYSADATA");
fn = (DLL_FN*) (dllqueryfn(dllHandle, "opendata"));
fn("SYSADATA");
return;
}
CEE3204S The system detected a protection exception (System Completion
Code=0C4).
From entry point dtFuncDeclarator::BeginNestedFunc(sFuncSymbol*)
at statement 729 at compile unit offset
+0510 at entry offset +0510 at address 21DEB1B8.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
