GIM38201E and GIM31901I
Hi I am apply RSU for our zOS system. I am receiving a error message GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. Does it mean the PTF UI46897 applied should be restored and modify its MCS to add UI34556 as its PRE ? Is my understanding correct? Could someone please shed light on ? zOS 2.2 Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
Hi Peter, - Modifying vendor-supplied MCS is NEVER a good idea. - The messages means that you are trying to APPLY a lower-level PTF than is currently APPLYd. (Do you really want to back-level your software?) It would be helpful to supply your entire //SMPCNTL when asking questions of this nature. That is, there is not enough context to decipher what you're attempting. Regards, David On 2019-08-25 03:21, Peter wrote: > Hi > > I am apply RSU for our zOS system. I am receiving a error message > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > Does it mean the PTF UI46897 applied should be restored and modify its MCS > to add UI34556 as its PRE ? > > Is my understanding correct? > > Could someone please shed light on ? > > zOS 2.2 > > Peter > > -- > 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: GIM38201E and GIM31901I
Here is the control statement : SMPCNTL DD * SET BDY TZONE . APPLY CHECK GROUPEXTEND BYPASS((HOLDSYSTEM)) RETRY(YES) . On Sun, 25 Aug, 2019, 4:30 PM David Spiegel, wrote: > Hi Peter, > - Modifying vendor-supplied MCS is NEVER a good idea. > - The messages means that you are trying to APPLY a lower-level PTF than > is currently APPLYd. > (Do you really want to back-level your software?) > It would be helpful to supply your entire //SMPCNTL when asking > questions of this nature. > That is, there is not enough context to decipher what you're attempting. > > Regards, > David > > On 2019-08-25 03:21, Peter wrote: > > Hi > > > > I am apply RSU for our zOS system. I am receiving a error message > > > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD > UI34556 > > > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > > > Does it mean the PTF UI46897 applied should be restored and modify its > MCS > > to add UI34556 as its PRE ? > > > > Is my understanding correct? > > > > Could someone please shed light on ? > > > > zOS 2.2 > > > > Peter > > > > -- > > 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: GIM38201E and GIM31901I
When I have these types of issues, I go back to the vendor to find out what is needed to resolve the issue. This could be something in the way they coded the SMP/e fixes or in the way I am trying to apply maintenance. I do not do anything fancy with maintenance. If you could post your SMP/e control cards - there might be something we see in the way they are coded. I usually do a APPLY CHECK Bypass(HOLDSYS) S(x y z) . >From what I have seen over the years, this usually will work. And I will tend to use the SMP/e panels in ISPF to build my JCL. Saves a lot of time in building the jobs. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Peter > Sent: Sunday, August 25, 2019 12:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: GIM38201E and GIM31901I > > Hi > > I am apply RSU for our zOS system. I am receiving a error message > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > Does it mean the PTF UI46897 applied should be restored and modify its MCS to > add UI34556 as its PRE ? > > Is my understanding correct? > > Could someone please shed light on ? > > zOS 2.2 > > Peter > -- 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(&commands,&fc);
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: GIM38201E and GIM31901I
Hi Peter, Remove the RETRY(YES). This will stop SMP/e from APPLYing "old" PTFs. Regards, David On 2019-08-25 09:53, Peter wrote: > Here is the control statement : > > SMPCNTL DD * > SET BDY TZONE . > APPLY CHECK > GROUPEXTEND > BYPASS((HOLDSYSTEM)) > RETRY(YES) > . > > > On Sun, 25 Aug, 2019, 4:30 PM David Spiegel, > wrote: > >> Hi Peter, >> - Modifying vendor-supplied MCS is NEVER a good idea. >> - The messages means that you are trying to APPLY a lower-level PTF than >> is currently APPLYd. >> (Do you really want to back-level your software?) >> It would be helpful to supply your entire //SMPCNTL when asking >> questions of this nature. >> That is, there is not enough context to decipher what you're attempting. >> >> Regards, >> David >> >> On 2019-08-25 03:21, Peter wrote: >>> Hi >>> >>> I am apply RSU for our zOS system. I am receiving a error message >>> >>> GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD >> UI34556 >>> GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. >>> UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. >>> >>> GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. >>> >>> Does it mean the PTF UI46897 applied should be restored and modify its >> MCS >>> to add UI34556 as its PRE ? >>> >>> Is my understanding correct? >>> >>> Could someone please shed light on ? >>> >>> zOS 2.2 >>> >>> Peter >>> >>> -- >>> 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
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(&commands,&fc);
>
> 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: GIM38201E and GIM31901I
Hi Lizette, GROUPEXTEND (abbreviation GEXT) should always be coded. Regards, David On 2019-08-25 09:56, Lizette Koehler wrote: > When I have these types of issues, I go back to the vendor to find out what > is needed to resolve the issue. This could be something in the way they > coded the SMP/e fixes or in the way I am trying to apply maintenance. > > I do not do anything fancy with maintenance. > > If you could post your SMP/e control cards - there might be something we see > in the way they are coded. > > I usually do a > >APPLY CHECK Bypass(HOLDSYS) S(x y z) . > > >From what I have seen over the years, this usually will work. > > And I will tend to use the SMP/e panels in ISPF to build my JCL. Saves a lot > of time in building the jobs. > > Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Peter >> Sent: Sunday, August 25, 2019 12:21 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: GIM38201E and GIM31901I >> >> Hi >> >> I am apply RSU for our zOS system. I am receiving a error message >> >> GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 >> >> GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. >> UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. >> >> GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. >> >> Does it mean the PTF UI46897 applied should be restored and modify its MCS to >> add UI34556 as its PRE ? >> >> Is my understanding correct? >> >> Could someone please shed light on ? >> >> zOS 2.2 >> >> Peter >> > -- > 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: GIM38201E and GIM31901I
David I think RETRY(YES) is to recover from space abends. >From the manual RETRY indicates whether SMP/E should try to recover from out-of-space errors for utilities it calls. YES indicates that SMP/E should try to recover and retry the utility if a RETRYDDN list is available in the OPTIONS entry that is in effect. RETRY(YES) is the default. If retry processing does not reclaim sufficient space and input to the utility was batched (copy or link-edit utility only), SMP/E debatches the input and retries the utility for each member separately. If this final attempt fails, the resulting x37 abend is treated as an unacceptable utility return code. In this case, processing continues for SYSMODs containing eligible updates to other libraries, but processing fails for SYSMODs containing unprocessed elements for the out-of-space library (and it fails for any SYSMODs that are dependent on the failed SYSMODs). For guidance on setting up the desired retry processing, see SMP/E for z/OS User's Guide. For more information about OPTIONS entries, see SMP/E for z/OS Reference. If there is no RETRYDDN list, SMP/E does not try to recover from out-of-space errors, even if you specify YES. NO indicates that SMP/E should not try to recover from the error. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > David Spiegel > Sent: Sunday, August 25, 2019 7:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: GIM38201E and GIM31901I > > Hi Peter, > Remove the RETRY(YES). > This will stop SMP/e from APPLYing "old" PTFs. > > Regards, > David > > On 2019-08-25 09:53, Peter wrote: > > Here is the control statement : > > > > SMPCNTL DD * > > SET BDY TZONE . > > APPLY CHECK > > GROUPEXTEND > > BYPASS((HOLDSYSTEM)) > > RETRY(YES) > > . > > > > > > On Sun, 25 Aug, 2019, 4:30 PM David Spiegel, > > wrote: > > > >> Hi Peter, > >> - Modifying vendor-supplied MCS is NEVER a good idea. > >> - The messages means that you are trying to APPLY a lower-level PTF > >> than is currently APPLYd. > >> (Do you really want to back-level your software?) It would be helpful > >> to supply your entire //SMPCNTL when asking questions of this nature. > >> That is, there is not enough context to decipher what you're attempting. > >> > >> Regards, > >> David > >> > >> On 2019-08-25 03:21, Peter wrote: > >>> Hi > >>> > >>> I am apply RSU for our zOS system. I am receiving a error message > >>> > >>> GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD > >> UI34556 > >>> GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > >>> UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > >>> > >>> GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > >>> > >>> Does it mean the PTF UI46897 applied should be restored and modify > >>> its > >> MCS > >>> to add UI34556 as its PRE ? > >>> > >>> Is my understanding correct? > >>> > >>> Could someone please shed light on ? > >>> > >>> zOS 2.2 > >>> > >>> Peter > >>> > >>> > >>> -- 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: GIM38201E and GIM31901I
Hi Lizette, I misspoke. You're right. Regards, David On 2019-08-25 10:04, Lizette Koehler wrote: > David > > I think RETRY(YES) is to recover from space abends. > > >From the manual > > RETRY > indicates whether SMP/E should try to recover from out-of-space errors > for utilities it calls. > > YES > indicates that SMP/E should try to recover and retry the utility if > a RETRYDDN list is available in the OPTIONS entry that is in effect. > RETRY(YES) is the default. > > If retry processing does not reclaim sufficient space and input to > the utility was batched (copy or link-edit utility only), SMP/E debatches the > input and retries the utility for each member separately. If this final > attempt fails, the resulting x37 abend is treated as an unacceptable utility > return code. In this case, processing continues for SYSMODs containing > eligible updates to other libraries, but processing fails for SYSMODs > containing unprocessed elements for the out-of-space library (and it fails > for any SYSMODs that are dependent on the failed SYSMODs). For guidance on > setting up the desired retry processing, see SMP/E for z/OS User's Guide. For > more information about OPTIONS entries, see SMP/E for z/OS Reference. > > If there is no RETRYDDN list, SMP/E does not try to recover from > out-of-space errors, even if you specify YES. > NO > indicates that SMP/E should not try to recover from the error. > > > Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> David Spiegel >> Sent: Sunday, August 25, 2019 7:01 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: GIM38201E and GIM31901I >> >> Hi Peter, >> Remove the RETRY(YES). >> This will stop SMP/e from APPLYing "old" PTFs. >> >> Regards, >> David >> >> On 2019-08-25 09:53, Peter wrote: >>> Here is the control statement : >>> >>> SMPCNTL DD * >>> SET BDY TZONE . >>> APPLY CHECK >>> GROUPEXTEND >>> BYPASS((HOLDSYSTEM)) >>> RETRY(YES) >>> . >>> >>> >>> On Sun, 25 Aug, 2019, 4:30 PM David Spiegel, >>> wrote: >>> Hi Peter, - Modifying vendor-supplied MCS is NEVER a good idea. - The messages means that you are trying to APPLY a lower-level PTF than is currently APPLYd. (Do you really want to back-level your software?) It would be helpful to supply your entire //SMPCNTL when asking questions of this nature. That is, there is not enough context to decipher what you're attempting. Regards, David On 2019-08-25 03:21, Peter wrote: > Hi > > I am apply RSU for our zOS system. I am receiving a error message > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > Does it mean the PTF UI46897 applied should be restored and modify > its MCS > to add UI34556 as its PRE ? > > Is my understanding correct? > > Could someone please shed light on ? > > zOS 2.2 > > Peter > > > -- 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 > . > -- 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(&commands,&fc);
>
> 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: GIM38201E and GIM31901I
This situation is 'normal' if a vendor-supplied sysmod hits a module that was last updated by an installation usermod. In this case, module EZBTCRDF was last updated by UI46897, which by all appearances is a PTF, not a usermod. So the question is, why does SMPE not recognize the history of EZBTCRDF? RETRY, as previously noted, should not be involved. I suggest looking at UI46897 to determine why SMPE does not understand its role here. Something went wrong sometime in the past...Hold the phone. I finally did what should always be done first: Googled 'ibm UI46897'. Found this hit: https://www-01.ibm.com/support/docview.wss?uid=isg3T1010412 "During the second APPLY the following week, PTFs containing the same parts as those that got missed when the spool filled up were hit by PTFs at a higher level resulting in the MODID errors being seen... Perform an APPLY REDO of all of the PTFs affected by the spool filling up. Then, re-do all of the applies that were done since the time that the spool filled up. Afterwards, a listing of all SYSMODs should show no PTFs are in ERRor status." . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Sunday, August 25, 2019 12:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):GIM38201E and GIM31901I Hi I am apply RSU for our zOS system. I am receiving a error message GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. Does it mean the PTF UI46897 applied should be restored and modify its MCS to add UI34556 as its PRE ? Is my understanding correct? Could someone please shed light on ? zOS 2.2 Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TSO USERS program which also displays ACTIVE jobs
Hi Folks, Thanks to all who have helped me so far (especially Frank). I am trying to locate original source code for a program I have that displays TSO USERS, and also TSO ACTIVE jobs. I only have a disassembly, and it is a somewhat complex program. From looking at the IKJPARMs in it, I could tell that it was written at Standard and Poor's located at 55 Water Street in New York City. Dated before 1980 or so. If anybody has the source for this program (TSO command) I would appreciate them emailing it to me. It is so old, that whatever company where it was written (I guess S&P), probably won't mind. I think I saw it for the first time, at the Federal Reserve Bank of New York in the early 80's. Many thanks, if you can help. All the best of everything to all of you. Sincerely, Sam sbgo...@cbttape.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TSO USERS program which also displays ACTIVE jobs
Hi Folks, Just to let you know about this program. The ACTIVE part does not work on XA systems and above, without some tweaking, because the CSCB control block (mapped by the IEECHAIN macro) was moved above the 16M line, and that is what contains most of the information about currently active jobs. I have fixed the disassembly so it works on z/OS, and I have put the modified disassembled source on File 300 of the Updates page of www.cbttape.org (member USERS). It's just nicer when you have REAL source, and you can change things without worrying about displacements. Thanks again, in advance, for any help you can give me. All the best Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ICSF CSN ALET-qualified callable services
Q: Anyone know if there is SCOPE= requirement for data spaces intended to be used by some of the ICSF CSN* callable services? I've checked several of the docs in the crypto services library and haven't found much if any detail on the subject. Thanks much, Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
CM Poncelet wrote: >PGP allows sending encrypted emails/data to multiple recipients, where >each recipient has a different private key, and this works AOK (but no >idea how). Trivial: the actual payload is encrypted with a random symmetric key. Then THAT key is encrypted with the public key of each recipient, and the package sent contains a copy for each recipient. So in pseudo-crypto(!), if the data is being sent to Phil, Charles, and CM, the package contains: This is for Phil: < copy of key K, encrypted with Phil's public key and possibly sender's private key> This is for Charles: < copy of key K, encrypted with Charles's public key and possibly sender's private key> This is for CM: < copy of key K, encrypted with CM's public key and possibly sender's private key> Make sense? ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Very clever. You really want to use symmetric encryption anyway for significant amounts of data because public key is slow. Better to encrypt with a random (relatively short) secret key, and then encrypt that with public key. That's how TLS (SSL) does things. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Sunday, August 25, 2019 6:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key CM Poncelet wrote: >PGP allows sending encrypted emails/data to multiple recipients, where >each recipient has a different private key, and this works AOK (but no >idea how). Trivial: the actual payload is encrypted with a random symmetric key. Then THAT key is encrypted with the public key of each recipient, and the package sent contains a copy for each recipient. So in pseudo-crypto(!), if the data is being sent to Phil, Charles, and CM, the package contains: This is for Phil: < copy of key K, encrypted with Phil's public key and possibly sender's private key> This is for Charles: < copy of key K, encrypted with Charles's public key and possibly sender's private key> This is for CM: < copy of key K, encrypted with CM's public key and possibly sender's private key> Make sense? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Possibly - but probably not "encrypted with ... possibly sender's private key" On 26/08/2019 02:17, Phil Smith III wrote: > CM Poncelet wrote: > >> PGP allows sending encrypted emails/data to multiple recipients, where >> each recipient has a different private key, and this works AOK (but no >> idea how). > > > Trivial: the actual payload is encrypted with a random symmetric key. Then > THAT key is encrypted with the public key of each > recipient, and the package sent contains a copy for each recipient. So in > pseudo-crypto(!), if the data is being sent to Phil, > Charles, and CM, the package contains: > > > > This is for Phil: < copy of key K, encrypted with Phil's public key and > possibly sender's private key> > > This is for Charles: < copy of key K, encrypted with Charles's public key and > possibly sender's private key> > > This is for CM: < copy of key K, encrypted with CM's public key and possibly > sender's private key> > > > > > > Make sense? > > > > ...phsiii > > > -- > 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: GIM38201E and GIM31901I
On 8/25/2019 3:21 AM, Peter wrote: Hi I am apply RSU for our zOS system. I am receiving a error message GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. Does it mean the PTF UI46897 applied should be restored and modify its MCS to add UI34556 as its PRE ? Is my understanding correct? Could someone please shed light on ? zOS 2.2 Peter Peter, You should open a PMR immediately with IBM to report a packaging error. They're rare, but they do happen. IBM will be able to tell you pretty quickly if it's a packaging error, or if you had an error in your SMP/E that caused this. Be sure to NEVER, NEVER, NEVER use BYPASS(ID). Good luck, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF PUZZLE
All, Could it be that the EOF mark on the file is a DADSM function outside of the control of the program, and that is why there is no SMF record from an unopened, empty data set? Ron RON HAWKINS Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) m+61 400029610| t: +1 4085625415 | f: +1 4087912585 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Sunday, 25 August 2019 16:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMF PUZZLE Could it be as simple as having been created on one lpar (not the one you are processing hte records of) but deleted on the LPAR you are looking at the records of? Brian -- 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
CLASS parm for EXEC statement?
Dear all, I am running JES2 (z/OS 2.2) in my parallel sysplex environment. Is there any utility-trick so to submit a job in SYSA (using job CLASS=A) but a stepXY in this job to be executed in SYSB? I would like to prevent from submitting a separate job to SYSB (jobclass=B) including stepXY. As far as I know there is a limitation in job class so all steps to be executed in the same system. kind regards Konstantinos Zafiropoulos -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
