Re: CLASS parm for EXEC statement?

[Vernooij, Kees (ITOP NM) - KLM]

A job is 1 entity, which starts and runs on 1 system. 
This is not limited by or related to the jobclass of the job.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of K
> Sent: 26 August, 2019 8:56
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF PUZZLE

[Allan Staller]

Try the DAF program from the CBTTAPE FILE094.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
willie bunter
Sent: Saturday, August 24, 2019 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF PUZZLE

Good Day,
I am trying to find the user/job which created a dsn.  I run my trustworthy SMF 
job which looks for recids 05 14 15 17 18 61 62 63 64 65 66 67 68 136 139 163.  
The job showed the job which read the dsn & deleted it but it doesn't show who 
or which job created it.According to the LISTCAT the creation date of the dsn 
was Thursday Aug. 22.  I read the SMF tape for the previous week and subsequent 
days including Aug 22 & 23.
I was thinking if the dsn was created by a FTP or an UNIX upload process which 
may not be trapped by SMF Any thoughts?  Any suggestions

--
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

[Allan Staller]

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(&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
::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

[David Crayford]

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(&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


--
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

[Allan Staller]

You are trying to install a down-level PTF. Did your run an accept prior to the 
apply check?
The best time to ran an accept, is just before the next apply.

I suspect that UI46897  SUPS UI34556 (haven't checked).

Running an successful accept prior to the apply will cause UI34556 to be 
deleted from the global zone and eliminate the error.
The other choice us to exclude UI34556 from the apply. However, I suspect this 
will not be the only modid error that will be encountered.

APPLY ,.. EXLCUDE(UI34556). Check the fine manuals for syntax.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Sunday, August 25, 2019 2: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
::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

[Joseph Reichman]

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(&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
> ::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: CLASS parm for EXEC statement?

[Allan Staller]

Nope. The controls are at the JOB level. There is no way to run stepXY on any 
other LPAR.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of K
Sent: Monday, August 26, 2019 1:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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
::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

[Joseph Reichman]

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(&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
> 
> --
> 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: Local time in C on z/OS

[Dana Mitchell]

Thanks gil, perfect.  I was trying various combinations of bpxwunix and 
enviroment(TZ,xxx)  etc.
Dana

On Fri, 23 Aug 2019 14:16:12 -0500, Paul Gilmartin  wrote:
>
>Call your Rexx exec (not the one above, which is woefully ISPF-dependent)
>from .profile using command substitution, then assign and export that result.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ICSF CSN ALET-qualified callable services

[Peter Relson]

It would be very surprising if there were any limitation on the scope of a 
data space other than what the ALET itself represents.

Limitations are typically with respect to the ALET itself -- DU-AL 
(Dispatchable Unit Access List) ALET vs PASN-AL (PASN Access List) ALET vs 
a common area data space (DSPSERV with SCOPE=COMMON) ALET (which is on the 
PASN-AL), and public entry vs private entry.

-- All services that I can think of that accept ALET-qualified data accept 
an ALET for a public entry on the DU-AL. Most do not accept an ALET for a 
private entry.
-- Many services also accept a CADS on the PASN-AL.
-- Most services do not accept an ALET that is on the PASN-AL but does not 
represent a CADS.
-- Many services do not accept a CADS ALET either. If you had a real case 
for requiring that, I'd imagine that an RFE would be accepted to enhance 
to accept a CADS ALET.

I have not seen any service differentiate between the ALET for a SCOPE=ALL 
and a SCOPE=SINGLE data space.

But I suggest that you not assume that a CADS ALET is OK.

You might see documentation such as this:
Control parameters must be in the primary address space or, for AR-mode 
callers, must be in an address/data space that is addressable through a 
public entry on the caller's dispatchable unit access list (DU-AL).

Note that that wording does not say that a CADS is OK. If it is OK, and if 
we want use of a CADS to be part of the programming interface, we ought to 
clarify the doc to say so. But please do not assume. 

Peter Relson
z/OS Core Technology Design


--
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

[Phil Smith III]

CM Poncelet wrote:

>Possibly - but probably not "encrypted with ... possibly sender's

>private key" 

 

? Why do you say that? Doing so provides both security and non-repudiation. I 
may be misunderstanding your point.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

GDPS, Metro Mirror, Global Mirror

[fred glenlake]

Hi List,

I am looking for some direction on how to get up to speed with GDPS, Metro 
Mirror, Global Mirror, etc.   My site has been a single site for quite some 
time and DR tests have been go to a DR provider, lug the physical tapes along 
of the latest backups and spend a few days restoring before turning it over to 
selected users to break...ertest.

Now the light bulbs have gone off in the executive suites and they want to 
establish and second and possibly third site with replication out of state 
(200+ miles away), the whole ball of wax.   Go from zero to 200MPH right away 
and of course I have never set one of these up and made them work.

I am starting to download the IBM manuals on the stuff so I can enhance my 
insomnia reading collection, I just want to make sure I am reading up on the 
correct material as there seems to be quite a bit available.

Hence any suggestions, comments on how to get myself up to speed in a 
reasonable amount of time would be greatly appreciated.

Also if this is not the correct list for this type of question and there is 
another more appropriate list please let me know so I may ask in the 
appropriate list.

Many thanks,

Fred G.

Sent from Outlook

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

digest

[White, Andrew]

SET IBM-MAIN Digest
The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CLASS parm for EXEC statement?

[Jon Perryman]

 Class=A and class=B has nothing to do with system. The job card has a system 
affinity parameter to run that job on a specific system.

Running a step on another system is rarely the correct answer. You would be 
blocking the initiator. Additionally, resources are shared so that job is 
probably specific to that system. There's also the possibility the system is 
down at the moment. Ask yourself what you really need.

Can all the steps run on that system (sysb). If so, assign system affinity for 
the job to SYSB. 

If you need jobs run in a specific sequence, you can use a job schedule (e.g. 
OPS/MVS, CA-7 or ...).

Jon.

On Sunday, August 25, 2019, 11:55:38 PM PDT, K  wrote:  
 
 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  

--
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

[Jon Perryman]

 Exclude should not be needed. A PMR should be opened so that the problem can 
be fixed correctly.

Most often, users cause this error by specifying REDO but there are a few other 
rare causes that usually require PMR to fix the problem.

Jon.

On Monday, August 26, 2019, 05:54:33 AM PDT, Allan Staller 
 wrote:  
 
 You are trying to install a down-level PTF. Did your run an accept prior to 
the apply check?
The best time to ran an accept, is just before the next apply.

I suspect that UI46897  SUPS UI34556 (haven't checked).

Running an successful accept prior to the apply will cause UI34556 to be 
deleted from the global zone and eliminate the error.
The other choice us to exclude UI34556 from the apply. However, I suspect this 
will not be the only modid error that will be encountered.

APPLY ,..    EXLCUDE(UI34556). Check the fine manuals for syntax.

  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: 64 bit Assembler DLL app PSECT parm

[Barry Lichtenstein]

I think that's normal for the binder to not show the module information for 
your exported functions & variables, because they are being exported by the 
module currently being bound, so it's sort of superfluous.

For historical reasons the binder uppercases things.  You can either use the 
CASE=MIXED parm, or (preferable so it works regardless), put quotes around the 
symbol names on the control statements.  If you look at the SYSDEFSD produced 
by the binder, it quotes these:

  IMPORT CODE64,'SYSADATA','opendata'

On 22 Aug 2019 18:55:24 -0400 Joseph Reichman  wrote:
> Did that my problem now Is that I am getting unresolved in the Assembler 
> program which is calling my DLL,   
> the DLL exported function which is a C program

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF PUZZLE

[willie bunter]

 Roger,
I looked for SMF 118 but nothing turned up.  Thanks for the suggestion.
On Sunday, August 25, 2019, 10:45:43 a.m. UTC, Roger Lowe 
 wrote:  
 
 On Sat, 24 Aug 2019 17:29:30 +, willie bunter  
wrote:

>Good Day,
>I am trying to find the user/job which created a dsn.  I run my trustworthy 
>SMF job which looks for recids 05 14 15 17 18 61 62 63 64 65 66 67 68 136 139 
>163.  The job showed the job which read the dsn & deleted it but it doesn't 
>show who or which job created it.According to the LISTCAT the creation date of 
>the dsn was Thursday Aug. 22.  I read the SMF tape for the previous week and 
>subsequent days including Aug 22 & 23.
>I was thinking if the dsn was created by a FTP or an UNIX upload process which 
>may not be trapped by SMF
>Any thoughts?  Any suggestions
>
If you think it might have been an FTP process, you will need to check out the 
SMF 118 records.

Roger

--
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: SMF PUZZLE

[Carmen Vitullo]

was a the dataset renamed possibly? not created, if so there should be an SMF 
60-64 breadcrumb I believe to see if it was renamed from another dataset ? 





Carmen Vitullo 

- Original Message -

From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, August 26, 2019 10:50:24 AM 
Subject: Re: SMF PUZZLE 

Roger, 
I looked for SMF 118 but nothing turned up. Thanks for the suggestion. 
On Sunday, August 25, 2019, 10:45:43 a.m. UTC, Roger Lowe 
 wrote: 

On Sat, 24 Aug 2019 17:29:30 +, willie bunter  
wrote: 

>Good Day, 
>I am trying to find the user/job which created a dsn. I run my trustworthy SMF 
>job which looks for recids 05 14 15 17 18 61 62 63 64 65 66 67 68 136 139 163. 
>The job showed the job which read the dsn & deleted it but it doesn't show who 
>or which job created it.According to the LISTCAT the creation date of the dsn 
>was Thursday Aug. 22. I read the SMF tape for the previous week and subsequent 
>days including Aug 22 & 23. 
>I was thinking if the dsn was created by a FTP or an UNIX upload process which 
>may not be trapped by SMF 
>Any thoughts? Any suggestions 
> 
If you think it might have been an FTP process, you will need to check out the 
SMF 118 records. 

Roger 

-- 
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

[Charles Mills]

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: SMF PUZZLE

[Charles Mills]

Interesting hypothesis. Should be easy enough to verify.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Hawkins
Sent: Sunday, August 25, 2019 11:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Joseph Reichman]

Begin forwarded message:

> From: "Basil Kanneth" 
> Date: August 26, 2019 at 12:03:13 PM EDT
> To: Joseph Reichman 
> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
> 
> Thanks Joseph. 
> So I'll go ahead and reduce it to a Sev2 then. Let me know if you have any 
> concerns with that.
> 
> I'll follow-up by Wednesday otherwise.
> 
> Regards, 
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team
> IBM Software Group - Toronto Lab
> 
> 
> 
> From:Joseph Reichman 
> To:Basil Kanneth 
> Date:08/26/2019 11:44 AM
> Subject:[EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - 
> Compiler abend
> 
> 
> 
> No as you can have it please let me know 
> I need it to finish my project but I have other things to do 
> It’s a simple program surprised it has not come up before 
> 
> Thanks 
> 
> 
> 
> 
> On Aug 26, 2019, at 11:34 AM, Basil Kanneth  wrote:
> 
> Hi Joseph,
> 
> To provide you with an update, I was able to reproduce the system protection 
> error in my USS environment as shown below.
> I have opened an internal workitem for further investigation.
> 
> May I know the reason for this being a Sev1 issue? Is this blocking a 
> deadline of some sort?
> 
> $ xlC test.c
> ERROR CCN3485 ./test.c:11Parameter declaration list is incompatible with 
> declarator for DLL_FN.
> ERROR CCN3172 ./test.c:11Parameter type list for function DLL_FN contains 
> parameters without identifiers.
> 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 283938A8.
> FSUM3224 xlC: Fatal error in /usr/lpp/cbclib/xlc/exe/ccndrvr: signal 9 
> received.
> $
> 
> I'll follow-up by Wednesday, August 28th, 2019 otherwise.
> 
> Regards, 
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team
> IBM Software Group - Toronto Lab
> 
> 
> 
> From:Basil Kanneth/Toronto/IBM
> To:Joseph Reichman 
> Date:08/24/2019 10:35 PM
> Subject:Re: [EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - 
> Compiler abend
> 
> 
> Hi Joseph,
> 
> Thanks. Yes, I got the 3 files.
> 
> I'll have a look on Monday and update you.
> 
> Regards, 
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team
> IBM Software Group - Toronto Lab
> 
> 
> 
> 
> From:Joseph Reichman 
> To:Basil Kanneth 
> Date:08/24/2019 10:32 PM
> Subject:[EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - 
> Compiler abend
> 
> 
> 
> It’s z/os 2.3  
> 
> yeah ok you can get to it Monday 
> 
> Just let me know if you got my three files 
> 
> JCL, C code, and the abend 
> 
> Thanks 
> 
> 
> 
> 
> 
> On Aug 24, 2019, at 10:28 PM, Basil Kanneth  wrote:
> 
> Hi Joseph,
> 
> I am Basil Kanneth from the Compiler Service Team and I have received the 
> subject case.
> 
> I see that you are encountering a compile time system protection error for 
> the submitted test case. 
> 
> Can you please confirm which z/OS level you are compiling this on?
> 
> Also, I noticed that this is marked as a Sev1 issue. May I know the reason? 
> Can this be looked at during regular business hours on Monday?
> 
> Regards, 
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team
> IBM Software Group - Toronto Lab
> 
> 
> 
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF PUZZLE [EXTERNAL]

[Feller, Paul]

Well depending on how TCP/IP was setup/configured you could be cutting type 119 
records.  It was suggested in another email to download the DAF software from 
the CBT website.  I like using that software because it will search lots of 
different SMF record types to show activity related to datasets and other 
things.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of willie bunter
Sent: Monday, August 26, 2019 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF PUZZLE [EXTERNAL]

 Roger,
I looked for SMF 118 but nothing turned up.  Thanks for the suggestion.
On Sunday, August 25, 2019, 10:45:43 a.m. UTC, Roger Lowe 
 wrote:  
 
 On Sat, 24 Aug 2019 17:29:30 +, willie bunter  
wrote:

>Good Day,
>I am trying to find the user/job which created a dsn.  I run my trustworthy 
>SMF job which looks for recids 05 14 15 17 18 61 62 63 64 65 66 67 68 136 139 
>163.  The job showed the job which read the dsn & deleted it but it doesn't 
>show who or which job created it.According to the LISTCAT the creation date of 
>the dsn was Thursday Aug. 22.  I read the SMF tape for the previous week and 
>subsequent days including Aug 22 & 23.
>I was thinking if the dsn was created by a FTP or an UNIX upload 
>process which may not be trapped by SMF Any thoughts?  Any suggestions
>
If you think it might have been an FTP process, you will need to check out the 
SMF 118 records.

Roger

--
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

--
Please note:  This message originated outside your organization. Please use 
caution when opening links or attachments.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF PUZZLE

[Charles Mills]

SMF 118 and/or its preferred replacement, SMF 119, has to be enabled in *two* 
places: SMFPRMxx (just like any other SMF type) and also in the TCPIP config 
file. (And perhaps in a third place for FTP -- I'm trying to remember.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of willie bunter
Sent: Monday, August 26, 2019 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF PUZZLE

 Roger,
I looked for SMF 118 but nothing turned up.  Thanks for the suggestion.
On Sunday, August 25, 2019, 10:45:43 a.m. UTC, Roger Lowe 
 wrote:  
 
 On Sat, 24 Aug 2019 17:29:30 +, willie bunter  
wrote:

>Good Day,
>I am trying to find the user/job which created a dsn.  I run my trustworthy 
>SMF job which looks for recids 05 14 15 17 18 61 62 63 64 65 66 67 68 136 139 
>163.  The job showed the job which read the dsn & deleted it but it doesn't 
>show who or which job created it.According to the LISTCAT the creation date of 
>the dsn was Thursday Aug. 22.  I read the SMF tape for the previous week and 
>subsequent days including Aug 22 & 23.
>I was thinking if the dsn was created by a FTP or an UNIX upload process which 
>may not be trapped by SMF
>Any thoughts?  Any suggestions
>
If you think it might have been an FTP process, you will need to check out the 
SMF 118 records.

Roger

--
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: SMF PUZZLE

[Seymour J Metz]

If you are configured for an automatic EOF on new files, then Allocation writes 
the EOF before your application gets control; there is no OPEN involved.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, August 26, 2019 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF PUZZLE

Interesting hypothesis. Should be easy enough to verify.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Hawkins
Sent: Sunday, August 25, 2019 11:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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?

--
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: SMF PUZZLE

[John Kelly]

Did you try Type 42 subtype 27, VTOC update? Since you mentioned all of the
60 records, I assume the file is VSAM, surprised that there's nothing in a
69 recprd.

On Mon, Aug 26, 2019 at 12:34 PM Charles Mills  wrote:

> SMF 118 and/or its preferred replacement, SMF 119, has to be enabled in
> *two* places: SMFPRMxx (just like any other SMF type) and also in the TCPIP
> config file. (And perhaps in a third place for FTP -- I'm trying to
> remember.)
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Monday, August 26, 2019 8:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF PUZZLE
>
>  Roger,
> I looked for SMF 118 but nothing turned up.  Thanks for the suggestion.
> On Sunday, August 25, 2019, 10:45:43 a.m. UTC, Roger Lowe <
> roger_l...@bigpond.com> wrote:
>
>  On Sat, 24 Aug 2019 17:29:30 +, willie bunter 
> wrote:
>
> >Good Day,
> >I am trying to find the user/job which created a dsn.  I run my
> trustworthy SMF job which looks for recids 05 14 15 17 18 61 62 63 64 65 66
> 67 68 136 139 163.  The job showed the job which read the dsn & deleted it
> but it doesn't show who or which job created it.According to the LISTCAT
> the creation date of the dsn was Thursday Aug. 22.  I read the SMF tape for
> the previous week and subsequent days including Aug 22 & 23.
> >I was thinking if the dsn was created by a FTP or an UNIX upload process
> which may not be trapped by SMF
> >Any thoughts?  Any suggestions
> >
> If you think it might have been an FTP process, you will need to check out
> the SMF 118 records.
>
> Roger
>
> --
> 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
>


-- 
John Kelly

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: GDPS, Metro Mirror, Global Mirror

[Tom Conley]

On 8/26/2019 10:11 AM, fred glenlake wrote:

Hi List,

I am looking for some direction on how to get up to speed with GDPS, Metro 
Mirror, Global Mirror, etc.   My site has been a single site for quite some 
time and DR tests have been go to a DR provider, lug the physical tapes along 
of the latest backups and spend a few days restoring before turning it over to 
selected users to break...ertest.

Now the light bulbs have gone off in the executive suites and they want to 
establish and second and possibly third site with replication out of state 
(200+ miles away), the whole ball of wax.   Go from zero to 200MPH right away 
and of course I have never set one of these up and made them work.

I am starting to download the IBM manuals on the stuff so I can enhance my 
insomnia reading collection, I just want to make sure I am reading up on the 
correct material as there seems to be quite a bit available.

Hence any suggestions, comments on how to get myself up to speed in a 
reasonable amount of time would be greatly appreciated.

Also if this is not the correct list for this type of question and there is 
another more appropriate list please let me know so I may ask in the 
appropriate list.

Many thanks,

Fred G.



Fred,

GDPS is not just a product, it is a service sold by IBM.  IBM will 
configure, set up, and install GDPS to get you up and running, with 
periodic visits to ensure that you're up to snuff.  Your management 
needs to brace themselves, because even the smallest shops are looking 
at 7+ figures to install GDPS.  I've worked with the teams doing it. 
It's an awesome solution for recovery, with a price tag to match.


If your company is a SHARE member, the SHARE GDPS presentations have 
excellent overview information.  GDPS is based on NetView and SA/390, so 
you should read up on them as well.  Metro and Global mirror are PPRC 
and XRC based, so get familiar with them.


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: GIM38201E and GIM31901I

[Seymour J Metz]

It's been a while, but my default mode is to track down what's wrong with the 
packaging, contact the vendor and work with him to resolve it. Except in 
emergencies I don't develop my own workaround.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Sunday, August 25, 2019 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: digest

[Edward Finnell]

>send email to lists...@listserv.ua.edu  

In a message dated 8/26/2019 10:30:42 AM Central Standard Time, 
awh...@metlife.com writes:
>SET IBM-MAIN Digest

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF PUZZLE

[Seymour J Metz]

If you are configured for automatic EOF, then Allocation will write an EOF 
regardless of the program name; there's nothing special about IEFBR14 except 
for a performance tweak. There is no OPEN involved.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Saturday, August 24, 2019 5:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF PUZZLE

[Default] On 24 Aug 2019 13:41:23 -0700, in bit.listserv.ibm-main
martin_pac...@uk.ibm.com (Martin Packer) wrote:

>Allocation doesn't cause SMF 14/15 to be written. CLOSE (and therefore
>OPEN) does.

If a data set is allocated by IeFBr14 on an SMS disk, as I understand
it, it will have an EOF record as its first record.  Thus it can be
read (as a zero record file) by a subsequent program or job and
deleted thus from an SMF point of view a file can be read and deleted
without ever having been created.

Clark Morris
>
>I guess, from the original post, data is written so presumably some form
>of OPEN took place.
>
>Cheers, Martin
>
>Martin Packer
>
>zChampion, Systems Investigator & Performance Troubleshooter, IBM
>
>+44-7802-245-584
>
>email: martin_pac...@uk.ibm.com
>
>Twitter / Facebook IDs: MartinPacker
>
>Blog:
>https://secure-web.cisco.com/1jWfMC4FDTdzncrPWLkLBC97mhpriVujWYooUizSQ6hb0k9sN_oOVeg_WgS7GzM5YpYMYtZp-nnbEDiUw-EiD_OHn9QfBsrSqe_ImSMiG31ra9yfPAKUDO05uAmHYthKUHaVBrfwEeROqG-WIELMpqDHuKRv8kVKLMqhdEKAUDrpYV9DHZXZ-0OUwiNug5NoU_--dlnI8GGbV16C0r0eIpD408r2exKQiMLt9N_lvB1-DehKvsvhBCv-pNqRvUnE7KCKxVJsXSaBl4TzvUhgoawSvaqvIbVuu3koAvZ5BlDLfaLlacfawRWmzJ1QtVNtACHvb0a9SXZvdHjy_B9u1v5t5l-QIF6pOxwaepas8xdB44mVkbr0rn98BFivnfVvuwSi94lP63XxjYlwb2q5PwrF7_hhdQ30WFCftH1szu91swRPCtGtwhYIxOmYJLfy9/https%3A%2F%2Fwww.ibm.com%2Fdeveloperworks%2Fmydeveloperworks%2Fblogs%2FMartinPacker
>
>Podcast Series (With Marna Walle): 
>https://secure-web.cisco.com/1yhNrHArR0hNFGwHN0qBqalN1WcEEZiI_aRSlqBs8tumOw9lf_q4tgH_CIKjxvULkgukqhvEv6i_SPyGGT3gLSQRyV4splC5NE73vPb0WAFrSjtXrnOpXkon6CP64pGjB9Ljwt2lX7dckT8nz-ne7qQci7WWHL7FG1HWQ9UqqBaG1WmEfMYd_d49r81HzdLvkVcMrP0X1WIuVgsQiENPM5KNuKnIlUkckvt0dqjLV6r-ERIteEtdwuIxTrLiT4aWA_Gy04iLU85zhTLsQi5g8MILX6vEQ67nzVe2IEiWIQnxBXX9TnONUxqi9OZgaqN_faxWQTWH9oWnqasqa9XlteUhIt0kmnAc8CMikcnMKd2OqgpCyAgh1EUxe-iazvu3mIgeOJPT40iT0_77fxBjLJF-rHOltCE7N1OkCoyEz73Z8LMx6SjRfPHLYku3cTxh-/https%3A%2F%2Fdeveloper.ibm.com%2Ftv%2Fmpt%2F
>or
>
>https://secure-web.cisco.com/1W9EfBzfL20vS0dm4Oso2UK0eyDeYRwOuEe-o4U1w8_DiX-llP5CA4n_Zs3Yd1S9vNtL1UvCv6w5dPFkMDxS_p0UB57f4hauVw8vPCuCPt09vx2DDy3Xov42l6fSafLc96QKFEJURN0tyg3VKXnGLnnvW8q4rhePIT48WgQU2DrLE-wFj_KesthAuhbYEaEQjVrN8k0nicbrGTbEjKznyIs4RUAHWPNRUukA-sueWDq4_MUrMiFIWAj8vlzvNGjmtsn_6jFw2GS7tmdCwHXB7BNf9pag8xghXcp6YkrDw8pyym_PYTUN-F4GeI9YX-yvuUzGj7u5IOWG3Fd5jJu4Ppikdh85_V7kPjjLqpdiQWKgs9bTYLqLvfy5Sp9W2VmBA08KQAMVOazDeSyFcUBYV1A7WgNaYgWlP92w02ADvhXyo7fFZK3h87wALc014bMJt/https%3A%2F%2Fitunes.apple.com%2Fgb%2Fpodcast%2Fmainframe-performance-topics%2Fid1127943573%3Fmt%3D2
>
>
>Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
>From:   Charles Mills 
>To: IBM-MAIN@LISTSERV.UA.EDU
>Date:   24/08/2019 21:23
>Subject:Re: SMF PUZZLE
>Sent by:IBM Mainframe Discussion List 
>
>
>
>SMF only captures what you tell it to (with SMFPRMxx). Some shops, for
>example, exclude STC's from certain SMF types "to avoid a performance
>impact on CICS" or some similar reason. The whole "how to read SMFPRMxx"
>thing is beyond the scope of an e-mail. D SMF,O will give you a
>not-quite-trivial-to-parse summary.
>
>SMF 15 shows "opened for output and then closed" (for those subsystems for
>which it is configured, per the above). Harking back to the IEFBR14
>discussion here a week or so ago, I wonder if a basic "create a DSN with
>IEFBR14 DISP=(NEW,CTALG)" shows up in SMF 15 (because it does not close
>the dataset). Others may well know.
>
>Charles
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of willie bunter
>Sent: Saturday, August 24, 2019 10:30 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: SMF PUZZLE
>
>Good Day,
>I am trying to find the user/job which created a dsn.  I run my
>trustworthy SMF job which looks for recids 05 14 15 17 18 61 62 63 64 65
>66 67 68 136 139 163.  The job showed the job which read the dsn & deleted
>it but it doesn't show who or which job created it.According to the
>LISTCAT the creation date of the dsn was Thursday Aug. 22.  I read the SMF
>tape for the previous week and subsequent days including Aug 22 & 23.
>I was thinking if the dsn was created by a FTP or an UNIX upload process
>which may not be trapped by SMF
>Any thoughts?  Any suggestions
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
>Unless stated otherwise above:
>IBM United

Re: vendor distributes their private key

[Seymour J Metz]

RSA only involves two primes. See 
https://en.wikipedia.org/wiki/RSA_(cryptosystem)


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Saturday, August 24, 2019 4:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

 I vaguely recall that there was a third prime number involved in the algorithm 
that was static for RSA. Do they still have this third prime? Could it be that 
they use this to eliminate this possibility?
Jon.
On Saturday, August 24, 2019, 09:17:22 AM PDT, Mike Schwab 
 wrote:
 > Well, keys are supposed to be two large prime numbers.  Without a

> registry of which numbers have been used, it would be possible for two

> people to use the same prime number.

--
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: COW for fork() is disappearing in z/OS 2.4

[Seymour J Metz]

The listserv's web interface  *is* e-mail software. It's not uncommon for 
webmail software to be broken, softimes badly broken. Take gmail - please!

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Jerry Callen 
Sent: Friday, August 23, 2019 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COW for fork() is disappearing in z/OS 2.4

> The Percent29 at the end breaks the URL. Is your e-mail software doing that 
> automatically?

I created the post directly from the listserv's web interface - no email 
software involved. I *did* have a closing paren at the end of the URL, since I 
was in the middle of a parenthesized phrase; it seems that somehow got rolled 
into the URL.

-- Jerry

--
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: vendor distributes their private key

[Paul Gilmartin]

On Mon, 26 Aug 2019 17:42:35 +, Seymour J Metz  wrote:

>RSA only involves two primes. See 
>https://en.wikipedia.org/wiki/RSA_(cryptosystem)


From: Jon Perryman
Sent: Saturday, August 24, 2019 4:29 PM

 I vaguely recall that there was a third prime number involved in the algorithm 
that was static for RSA. Do they still have this third prime? Could it be that 
they use this to eliminate this possibility?

Are you thinking, perhaps, of Diffie-Hellman?

https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#General_overview

-- gil

--
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]

Because a sender does not need to have an own public/private key-pair,
but needs only the public keys of the recipients to send encrypted
emails to them.
 
BTW Some links if interested in putting this to the test:

[PRZ's website:]
https://philzimmermann.com/EN/findpgp/

[free GPG/PGP websites:] 
https://www.gnupg.org/
https://www.openpgp.org/
 
[email encryption software for Thunderbird:]
https://www.openpgp.org/software/enigmail/
 
[download my PGP public key (ponce...@logicintegration.com &
ponce...@bcs.org.uk) to check sending encrypted emails to me:]
http://keyserver.pgp.com/vkd/GetWelcomeScreen.event
 
HTH
 
Cheers, Chris Poncelet (retired sysprog)
 


On 26/08/2019 14:53, Phil Smith III wrote:
> CM Poncelet wrote:
>
>> Possibly - but probably not "encrypted with ... possibly sender's
>> private key" 
>  
>
> ? Why do you say that? Doing so provides both security and non-repudiation. I 
> may be misunderstanding your point.
>
>
> --
> 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: SMF PUZZLE

[Paul Gilmartin]

On 2019-08-26, at 11:13:44, Seymour J Metz wrote:
> 
> If you are configured for an automatic EOF on new files, then Allocation 
> writes the EOF before your application gets control; there is no OPEN 
> involved.
>  
I understand Allocation writes no EOF if it can't determine DSORG.
A silly convention since there is no harm in writing EOF on previously
uncommitted space, and may be much good.

Is this one of those things where SMS must be active, even though the
new data set is not SMS-controlled?

> -Original Message-
> From: Ron Hawkins
> Sent: Sunday, August 25, 2019 11:25 PM
> 
> 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?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ICSF CSN ALET-qualified callable services

[Mike Hochee]

Thank you very much Peter!


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Monday, August 26, 2019 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ICSF CSN ALET-qualified callable services

It would be very surprising if there were any limitation on the scope of a
data space other than what the ALET itself represents.

Limitations are typically with respect to the ALET itself -- DU-AL
(Dispatchable Unit Access List) ALET vs PASN-AL (PASN Access List) ALET vs
a common area data space (DSPSERV with SCOPE=COMMON) ALET (which is on the
PASN-AL), and public entry vs private entry.

-- All services that I can think of that accept ALET-qualified data accept
an ALET for a public entry on the DU-AL. Most do not accept an ALET for a
private entry.
-- Many services also accept a CADS on the PASN-AL.
-- Most services do not accept an ALET that is on the PASN-AL but does not
represent a CADS.
-- Many services do not accept a CADS ALET either. If you had a real case
for requiring that, I'd imagine that an RFE would be accepted to enhance
to accept a CADS ALET.

I have not seen any service differentiate between the ALET for a SCOPE=ALL
and a SCOPE=SINGLE data space.

But I suggest that you not assume that a CADS ALET is OK.

You might see documentation such as this:
Control parameters must be in the primary address space or, for AR-mode
callers, must be in an address/data space that is addressable through a
public entry on the caller's dispatchable unit access list (DU-AL).

Note that that wording does not say that a CADS is OK. If it is OK, and if
we want use of a CADS to be part of the programming interface, we ought to
clarify the doc to say so. But please do not assume.

Peter Relson
z/OS Core Technology Design


--
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: vendor distributes their private key

[Phil Smith III]

CM Poncelet wrote:

>Because a sender does not need to have an own public/private key-pair,

>but needs only the public keys of the recipients to send encrypted

>emails to them.

 

Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both, 
providing that non-repudiation; I guess I assumed everyone did!


--
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

[Seymour J Metz]

The proper way to provide encryption and non-repudiation is to have two key 
pairs. You sign a message using your private key. People wanting to send you 
encrypted data encrypt using your public key. So if foo wants to send bar a 
signed encrypted document, foo double encrypts it with foo's private key and 
bar's publickey.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Monday, August 26, 2019 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

CM Poncelet wrote:

>Because a sender does not need to have an own public/private key-pair,

>but needs only the public keys of the recipients to send encrypted

>emails to them.



Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both, 
providing that non-repudiation; I guess I assumed everyone did!


--
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: vendor distributes their private key

[Jon Perryman]

 I found the third RSA number that is used to eliminate collisions. I was 
talking about the exponent which is a coprime to the modulus of the primes. 
Apparently the exponent does not need to be a prime. 
wiki page - key generation - step 4 : "Choose an integer e such that 1 < e < 
λ(n) and gcd(e, λ(n)) = 1; that is, e and λ(n) are coprime.".

As long as every CA using this algorithm has a different exponent, then all 
keys are guaranteed to be unique with the CA's.
Jon.
On Monday, August 26, 2019, 10:42:44 AM PDT, Seymour J Metz 
 wrote:  
 
 RSA only involves two primes. See 
https://en.wikipedia.org/wiki/RSA_(cryptosystem)


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Saturday, August 24, 2019 4:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

 I vaguely recall that there was a third prime number involved in the algorithm 
that was static for RSA. Do they still have this third prime? Could it be that 
they use this to eliminate this possibility?
Jon.
    On Saturday, August 24, 2019, 09:17:22 AM PDT, Mike Schwab 
 wrote:
 > Well, keys are supposed to be two large prime numbers.  Without a

> registry of which numbers have been used, it would be possible for two

> people to use the same prime number.

--
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

[Jesse 1 Robinson]

I really don't think this is a packaging error; as noted by Tom Conley, those 
are exceedingly rare. If one occurs, there should be a lightning quick HOLD 
record that would show up in any APPLY attempt. The date on the 'offending' PTF 
is mid 2017; we're not looking at something hot off the press. I'm convinced 
that this is a user error, perhaps from long ago. Go ahead and open a case, but 
my money is on a past APPLY failure. This sysmod BTW is TCP/IP HIP6220, SUP in 
z/OS 2.3 by HIP6230. 

.
.
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 
Seymour J Metz
Sent: Monday, August 26, 2019 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: GIM38201E and GIM31901I

It's been a while, but my default mode is to track down what's wrong with the 
packaging, contact the vendor and work with him to resolve it. Except in 
emergencies I don't develop my own workaround.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Sunday, August 25, 2019 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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: vendor distributes their private key

[zMan]

Isn't that what was just discussed? What am I missing here?

On Mon, Aug 26, 2019 at 4:42 PM Seymour J Metz  wrote:

> The proper way to provide encryption and non-repudiation is to have two
> key pairs. You sign a message using your private key. People wanting to
> send you encrypted data encrypt using your public key. So if foo wants to
> send bar a signed encrypted document, foo double encrypts it with foo's
> private key and bar's publickey.

-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
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

[Charles Mills]

Yow! Expensive in terms of CPU time.

Wouldn't (ideally at least) foo encrypt it with a random secret key and then
send it to bar encrypted with bar's public key?

To provide non-repudiation -- to sign a document -- it is only necessary for
the sender to encrypt a hash of the message with the sender's private key.

Much cheaper than two long public key encryptions.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, August 26, 2019 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

The proper way to provide encryption and non-repudiation is to have two key
pairs. You sign a message using your private key. People wanting to send you
encrypted data encrypt using your public key. So if foo wants to send bar a
signed encrypted document, foo double encrypts it with foo's private key and
bar's publickey.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of
Phil Smith III 
Sent: Monday, August 26, 2019 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

CM Poncelet wrote:

>Because a sender does not need to have an own public/private key-pair,

>but needs only the public keys of the recipients to send encrypted

>emails to them.



Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both,
providing that non-repudiation; I guess I assumed everyone did!


--
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

Reverse map Adsadmp parms

[Shivang Sharma]

Hi all,

Is there a way to reverse engineer 
the AMDSADMP parms used to create 
the dump program from the
Sys1.pagedump dataset

Thanks.
Shivang Sharma

--
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

[Seymour J Metz]

Those alternatives also involve two pairs of keys.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, August 26, 2019 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

Yow! Expensive in terms of CPU time.

Wouldn't (ideally at least) foo encrypt it with a random secret key and then
send it to bar encrypted with bar's public key?

To provide non-repudiation -- to sign a document -- it is only necessary for
the sender to encrypt a hash of the message with the sender's private key.

Much cheaper than two long public key encryptions.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, August 26, 2019 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

The proper way to provide encryption and non-repudiation is to have two key
pairs. You sign a message using your private key. People wanting to send you
encrypted data encrypt using your public key. So if foo wants to send bar a
signed encrypted document, foo double encrypts it with foo's private key and
bar's publickey.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of
Phil Smith III 
Sent: Monday, August 26, 2019 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

CM Poncelet wrote:

>Because a sender does not need to have an own public/private key-pair,

>but needs only the public keys of the recipients to send encrypted

>emails to them.



Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both,
providing that non-repudiation; I guess I assumed everyone did!


--
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: vendor distributes their private key

[Seymour J Metz]

That depends on what Phil Smith III  meant by "Ah, ok. Reveals my ignorance of 
how PGP works. Voltage SecureMail uses both,  providing that non-repudiation; I 
guess I assumed everyone did!"



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
zMan 
Sent: Monday, August 26, 2019 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

Isn't that what was just discussed? What am I missing here?

On Mon, Aug 26, 2019 at 4:42 PM Seymour J Metz  wrote:

> The proper way to provide encryption and non-repudiation is to have two
> key pairs. You sign a message using your private key. People wanting to
> send you encrypted data encrypt using your public key. So if foo wants to
> send bar a signed encrypted document, foo double encrypts it with foo's
> private key and bar's publickey.

--
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
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

[Seymour J Metz]

I only bet on sure things. It could be a packaging error, a prior user error or 
(unlikely) an error in SMP/E. In all of those cases, however, it's best to 
consult with the vendors before doing anything that might mess things up more.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Monday, August 26, 2019 5:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GIM38201E and GIM31901I

I really don't think this is a packaging error; as noted by Tom Conley, those 
are exceedingly rare. If one occurs, there should be a lightning quick HOLD 
record that would show up in any APPLY attempt. The date on the 'offending' PTF 
is mid 2017; we're not looking at something hot off the press. I'm convinced 
that this is a user error, perhaps from long ago. Go ahead and open a case, but 
my money is on a past APPLY failure. This sysmod BTW is TCP/IP HIP6220, SUP in 
z/OS 2.3 by HIP6230.

.
.
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 
Seymour J Metz
Sent: Monday, August 26, 2019 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: GIM38201E and GIM31901I

It's been a while, but my default mode is to track down what's wrong with the 
packaging, contact the vendor and work with him to resolve it. Except in 
emergencies I don't develop my own workaround.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Sunday, August 25, 2019 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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

--
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

[Charles Mills]

But much shorter plaintext to encrypt. Around 256 or 512 bits each, rather
than whatever the length of the e-mail is.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, August 26, 2019 2:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

Those alternatives also involve two pairs of keys.

--
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

[Jon Perryman]

 Non-repudiation for the message is not guaranteed by a hash. There is more 
than 1 message that could match that hash.

Jon.

On Monday, August 26, 2019, 02:42:27 PM PDT, Charles Mills  
wrote:
 
 
 Yow! Expensive in terms of CPU time.

Wouldn't (ideally at least) foo encrypt it with a random secret key and then
send it to bar encrypted with bar's public key?

To provide non-repudiation -- to sign a document -- it is only necessary for
the sender to encrypt a hash of the message with the sender's private key.

Much cheaper than two long public key encryptions.


--
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

[Charles Mills]

https://en.wikipedia.org/wiki/Cryptographic_hash_function 
Read the third and fourth bullets.

Read the whole article, for that matter.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Perryman
Sent: Monday, August 26, 2019 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

 Non-repudiation for the message is not guaranteed by a hash. There is more 
than 1 message that could match that hash.

Jon.

--
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 Perryman]

 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(&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
::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

[Joseph Reichman]

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(&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
::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 / signo

Re: Reverse map Adsadmp parms

[Jim Mulder]

  They parms are  in a record  which is mapped by
SYS1.MODGEN(AMDSADDO).  Currently, it happens to be 
around record #1020. 

  AMDSADDO is not classified as a Programming Interface. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
08/26/2019 05:38:13 PM:

> From: "Shivang Sharma" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/26/2019 07:32 PM
> Subject: Reverse map Adsadmp parms
> Sent by: "IBM Mainframe Discussion List" 
> 
> Hi all,
> 
> Is there a way to reverse engineer 
> the AMDSADMP parms used to create 
> the dump program from the
> Sys1.pagedump dataset



--
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 Perryman]

 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

[Joseph Reichman]

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

[David Crayford]

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

[David Crayford]

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: vendor distributes their private key

[Phil Smith III]

Charles Mills wrote, re hash uniqueness:

>https://en.wikipedia.org/wiki/Cryptographic_hash_function 

>Read the third and fourth bullets.

 

Indeed. Since the odds of a hash collision with any modern hashing algorithm 
are lower than the odds of a random bit-flip, it's not
worth worrying about.


--
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 Perryman]

 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: CLASS parm for EXEC statement?

[Brian Westerman]

You could have stepa run on systemA and have a step a1 submit a job via the 
internal reader which has a /*route exq to systemB, then have that job on 
systemB submit the rest of the job that needs to run on systemA (also via 
internal reader).  

We had a product which we were in beta test back in 2005 which we were going to 
market that did this all internally, and it worked perfectly fine, but there 
wasn't much interest.  There were very few things that really needed this 
capability.  We provided several options, (wait and take up the initiator while 
the other job runs, end the job and requeue in the follow-on step when the 
second step finished, bounce the entire job back and forth, and a couple others 
I can't recall right now), but they were all for nothing because no one wanted 
to license it. 

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF PUZZLE

[Vernooij, Kees (ITOP NM) - KLM]

AFAIK, no EOF is written, but LSTAR is set to zero which is recognized by SMS 
that the dataset is empty.
EOF is data and needs a track to write on, while SMS datasets can be zero 
tracks and still read empty.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: 26 August, 2019 19:14
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF PUZZLE
> 
> If you are configured for an automatic EOF on new files, then Allocation
> writes the EOF before your application gets control; there is no OPEN
> involved.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> 
> From: IBM Mainframe Discussion List  on behalf
> of Charles Mills 
> Sent: Monday, August 26, 2019 12:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF PUZZLE
> 
> Interesting hypothesis. Should be easy enough to verify.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ron Hawkins
> Sent: Sunday, August 25, 2019 11:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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?
> 
> --
> 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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: GDPS, Metro Mirror, Global Mirror

[Timothy Sipples]

Tom Conley wrote:
>Your management needs to brace themselves, because even
>the smallest shops are looking at 7+ figures to install
>GDPS.

Which currency are you talking about there? :-)

There are various GDPS offerings, and their prices vary.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN