AW: Re: LE strikes again

[Peter Hunkeler]

>>SLIP SET,C=0C1,J=jobname,ML=1,END
>>
>>Then have them load the dump into IPCS, select option 2.2 and send you the 
>>results.
  >
 >
>I don't think you can SLIP trap an 001 program check as long as LE is running 
>with TRAP(ON,SPIE). LE's ESPIE exit will gain control before SLIP; and LE will 
>do error handling and at the end isseue SVC 0D (ABEND) with abend code S0C1.
 >
 >
>This is why the failing instruction in the symptom dump points to 0A0D, and 
>not the original failing instruction address.


It occurred to be that my statement above was not accurate. A SLIP for S0C1 
will of course also match when TRAP(ON,SPIE) is in effect, but only for the 
ABEND LE issues at the end of its error handling. Thus you will see the SVC D 
instruction as the failing instruction.


When run with TRAP(OFF), the SLIP will match on the original S0C1 that RTM 
issues (lack of any ESPIE) for the 001 program check. And this dump will show 
PSW and registers at time of the original 001 program check.


--
Peter Hunkeler

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

z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Eells
> Sent: Tuesday, July 11, 2017 4:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EAV volumes and SYSRES
> 
> Gibney, Dave wrote:
> > z/OSMF assumes access to zIIP. Otherwise, the Java CPU load on general
> CP's impacts the SCRT reports, or runs up on the cap.
> 
> 
> There is negligible idle load imposed by the z/OSMF server; it uses 
> significant
> CPU only when you do something with it.  I just checked again using RMF
> Monitor III (RMFWDM) on our current level of z/OS V2.3 code.  As I started to
> compose this note, I looked at its CPU usage, and I did so again after several
> minutes had elapsed. It hadn't budged.
> 
> I believe this has been the case since we switched to WebSphere with the
> Liberty profile some time ago. Another interesting datum is that has used
> about 20% more zIIP time than CP time since the last server start.
> 
> But, just to make sure it was actually working (hey, it's a system in z/OS
> System Test, after all!), I logged into z/OSMF.  That was not enough to make
> the numbers move, either.
> 
> So, I defined a new (fairly small, about 150 data seats) software instance to
> drive discovery by a pattern, which does a bunch of Catalog and
> CVAF/DADSM operations to locate data sets by high-level qualifier, and went
> back to check again.  It had ticked up by a bit less than two tenths of a CPU
> second total, the sum of zIIP time and CP time.  I'll grant that this is on a 
> top
> end processor, but this is still not moving the needle by much; you can barely
> see it twitch.
> 
> The heavy lifting (data movement) for Software Management is currently
> done in batch.  I have not run a side-by-side comparison of CPU consumption
> for ServerPac and z/OSMF Software Management deployment operations,
> and I don't plan to, but the former is certainly nonzero, and the latter does
> not involve a huge amount of frequent activity.
> Also, Software Management should use less resource when you model after
> previous deployments (as many likely do in ServerPac, too, by "merging
> with" a saved configuration).

Thank you for this information. It could make this barely palatable.
Still, I've not even installed z/OSMF or Liberty. Running z/OS 2.1 now. Doubt 
my installation will even exist by the time someone needs to that it beyond 2.3

> 
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
> 
> --
> 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: Running unsupported is dangerous was Re: AW: Re: LE strikes again

[Charles Mills]

I missed the first part of this thread but I would point out that the
threats to z/OS are not limited to "Internet-connected" systems.

1. Consider insider threats. Security experts disagree on the percentage of
breaches attributable to insider threats, but it is certainly not zero. I
might argue that due to the somewhat specialized knowledge required, that
mainframes are at greater risk from insiders, relative to outsiders, than
more "common" systems.

2. A machine you do not consider to be Internet-connected may be
"Internet-reachable." One trick that bad guys use is "hopping" from one
machine to another. The mainframe might not be connected to the Internet,
but it might be connected to a machine that was connected to a machine that
was connected to the Internet.

3. People make mistakes. That mainframe may well be one router or firewall
"oops" away from the Internet. How often do your security people make
firewall changes that deny someone access that they require? They yell about
it right away, don't they? When the firewall folks make an error that grants
excessive access, no one yells ...

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, July 11, 2017 6:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Running unsupported is dangerous was Re: AW: Re: LE strikes again

[Default] On 10 Jul 2017 21:58:28 -0700, in bit.listserv.ibm-main
p...@gmx.ch (Peter Hunkeler) wrote:

You can also use a JCL statement to override (if available) LE Parms.  
 
 https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.z
 os.r13.ceea500/ceedd.htm
>>> 
>>> 
>>>No, he can't because he's on z/OS 1.4. I already proposed CEEOPTS DD, and
Norbert Friemel remembered me it's not yet supported at that release. 
> >
>>From a security point of view, your customer is asking for disaster if 
>>the system has any direct or indirect connection to the Internet.  The 
>>lack of integrity fixes alone is a major exposure.
> 
>
>Clark,
>
>I'm missing how your comment is related to this thread, and especially to
my post.
 Peter. I should have changed the subject line.  When your post stated the
release being run and other posts noted the lack of support, alarm bells
rang in my head.  Running 1.4 on any system that isn't isolated is the
equivalent of running Windows XP.

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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Edward Gould]

> On Jul 11, 2017, at 6:35 AM, John Eells  wrote:
> 
> Peter Hunkeler wrote:
>> Topic change due? Possibly more opinions if people understand it is about 
>> z/OSF now.
>> 
>> 
> 
> Peter, good idea.
> 
> Everyone: IBM is headed toward using z/OSMF Software Management as the 
> installer.  Please go back to near the beginning of this thread with the old 
> topic name to catch up on the discussion thus far.
> 
> More on the SHARE website, here:
> 
> https://share.confex.com/data/handout/share/128/Session_20728_handout_10028_0.pdf
> 
John,:

Interesting but I am not convinced that this is any better than what is 
currently available. It also looks (to me) complicated and one person seems to 
have to be doing “it” from start to end, is that the case?
Slide 35(?) are you trying to show a robot can do this but not a human?

Ed

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

Running unsupported is dangerous was Re: AW: Re: LE strikes again

[Clark Morris]

[Default] On 10 Jul 2017 21:58:28 -0700, in bit.listserv.ibm-main
p...@gmx.ch (Peter Hunkeler) wrote:

You can also use a JCL statement to override (if available) LE Parms.  
 
 https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea500/ceedd.htm
   
>>> 
>>> 
>>>No, he can't because he's on z/OS 1.4. I already proposed CEEOPTS DD, and 
>>>Norbert Friemel remembered me it's not yet supported at that release. 
> >
>>From a security point of view, your customer is asking for disaster if 
>>the system has any direct or indirect connection to the Internet.  The 
>>lack of integrity fixes alone is a major exposure. 
> 
>
>Clark,
>
>I'm missing how your comment is related to this thread, and especially to my 
>post.
 Peter. I should have changed the subject line.  When your post stated
the release being run and other posts noted the lack of support, alarm
bells rang in my head.  Running 1.4 on any system that isn't isolated
is the equivalent of running Windows XP.

Clark Morris

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

Re: LE strikes again

[Robin Atwood]

There is already a SYSUDUMP statement but the customer has suppressed most
dumps. Hence the SLIP trap.

--
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: 11 July 2017 19:01
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: LE strikes again

 
>I never knew that! I will ask the customer to update the JCL to use the
PARM field. 




... and ask them to add a //SYSABEND DD SYSOUT=h DD-Statemebt, where "h" is
a HOLD class, so that you can have a look or get information from the dump.


--
Peter Hunkeler 

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

AW: Re: LE strikes again

[Peter Hunkeler]

>I never knew that! I will ask the customer to update the JCL to use the PARM 
>field.




... and ask them to add a //SYSABEND DD SYSOUT=h DD-Statemebt, where "h" is a 
HOLD class, so that you can have a look or get information from the dump.


--
Peter Hunkeler

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

z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[John Eells]

Peter Hunkeler wrote:

Topic change due? Possibly more opinions if people understand it is about z/OSF 
now.




Peter, good idea.

Everyone: IBM is headed toward using z/OSMF Software Management as the 
installer.  Please go back to near the beginning of this thread with the 
old topic name to catch up on the discussion thus far.


More on the SHARE website, here:

https://share.confex.com/data/handout/share/128/Session_20728_handout_10028_0.pdf

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: LE strikes again

[Robin Atwood]

I never knew that! I will ask the customer to update the JCL to use the PARM
field.

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: 11 July 2017 18:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: LE strikes again

 
>SLIP SET,C=0C1,J=jobname,ML=1,END 
 >
>Then have them load the dump into IPCS, select option 2.2 and send you the
results. 
 

I don't think you can SLIP trap an 001 program check as long as LE is
running with TRAP(ON,SPIE). LE's ESPIE exit will gain control before SLIP;
and LE will do error handling and at the end isseue SVC 0D /ABEND) with
abend code S0C1.


This is why the failing instruction in the symptom dump points to 0A0D, and
not the original failing instruction address.


-- 
Peter Hunkeler  



--
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: EAV volumes and SYSRES

[John Eells]

Gibney, Dave wrote:

z/OSMF assumes access to zIIP. Otherwise, the Java CPU load on general CP's 
impacts the SCRT reports, or runs up on the cap.



There is negligible idle load imposed by the z/OSMF server; it uses 
significant CPU only when you do something with it.  I just checked 
again using RMF Monitor III (RMFWDM) on our current level of z/OS V2.3 
code.  As I started to compose this note, I looked at its CPU usage, and 
I did so again after several minutes had elapsed. It hadn't budged.


I believe this has been the case since we switched to WebSphere with the 
Liberty profile some time ago. Another interesting datum is that has 
used about 20% more zIIP time than CP time since the last server start.


But, just to make sure it was actually working (hey, it's a system in 
z/OS System Test, after all!), I logged into z/OSMF.  That was not 
enough to make the numbers move, either.


So, I defined a new (fairly small, about 150 data seats) software 
instance to drive discovery by a pattern, which does a bunch of Catalog 
and CVAF/DADSM operations to locate data sets by high-level qualifier, 
and went back to check again.  It had ticked up by a bit less than two 
tenths of a CPU second total, the sum of zIIP time and CP time.  I'll 
grant that this is on a top end processor, but this is still not moving 
the needle by much; you can barely see it twitch.


The heavy lifting (data movement) for Software Management is currently 
done in batch.  I have not run a side-by-side comparison of CPU 
consumption for ServerPac and z/OSMF Software Management deployment 
operations, and I don't plan to, but the former is certainly nonzero, 
and the latter does not involve a huge amount of frequent activity. 
Also, Software Management should use less resource when you model after 
previous deployments (as many likely do in ServerPac, too, by "merging 
with" a saved configuration).


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

AW: Re: LE strikes again

[Peter Hunkeler]

>SLIP SET,C=0C1,J=jobname,ML=1,END
 >
>Then have them load the dump into IPCS, select option 2.2 and send you the 
>results.


I don't think you can SLIP trap an 001 program check as long as LE is running 
with TRAP(ON,SPIE). LE's ESPIE exit will gain control before SLIP; and LE will 
do error handling and at the end isseue SVC 0D /ABEND) with abend code S0C1.


This is why the failing instruction in the symptom dump points to 0A0D, and not 
the original failing instruction address.


--
Peter Hunkeler



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

AW: Re: EAV volumes and SYSRES

[Peter Hunkeler]

Topic change due? Possibly more opinions if people understand it is about z/OSF 
now.


--
Peter Hunkeler



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

Re: EAV volumes and SYSRES

[John Eells]

Lizette, if you could post or e-mail more detail I'd be happy to see 
what, if anything, we can do to make it more suitable for what you do.


However, as I said at SHARE, I fully expect that many people will graft 
their existing build and migration processes onto the end of the new 
installation process, just as many do for ServerPac today; here, I'll 
add that I particularly expect that early on.  You might happen to fall 
into that group.


Lizette Koehler wrote:

@John Eells

We would not consider using z/OSMF for creating SYSRES volumes or rolling out
fixes.  It does not allow for our Naming convention for Datasets to work with
it.

Our naming convention should not be usurped by any vendor to use their tools.



Lizette



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Eells
Sent: Monday, July 10, 2017 7:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EAV volumes and SYSRES

R.S. wrote:

[...]
List -

Just curious if the EAV volumes can be used for SYSRES volumes or if
there are any concerns with using them for SYSRES volumes?

If they can be used for SYSRES, any considerations with using them?



Just looking for advise.


IMHO there are few things to consider:

1. EAV consist of EAS (upper space) and traditional "track-addressable"
space. SYSRES and probably everything else can be placed below the
line of 65520 cyl, because it is regular "legacy" 3390-54 volume.


True.


2. What can be placed "above the line" (that means in EAS)? That's the
question. I would not try to place there any of operational datasets
like RACF db, logrec archive, SYS1.MANx, etc. UNLESS it is clearly
documented.


Right.  Not sure we have documented this well, though, so if you find some
missing things, please submit RCFs.


  From the other hand - SYSRES is NOT the place for operational datasets!


I certainly agree!


This is a room for target libraries. I would not worry about non-LPA
and non-LNKLST libraries and non-IPL_LNKLST (dynamically added) libraries.
And most non-executable (RECFM=U) libraries.


For this and #3, see the list I posted in response to Lizette's original
post.


3. What about ZFS and HFS? I would check it again, but IMHO all of
them can be placed in EAS.

4. What about ServerPac Installation Dialog? Does it support EAV yet?


It does not.  It likely will never do so.  We are moving in a different
direction, with z/OSMF Software Management as our installer in a few years, I
hope.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com



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




--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

GSE UK LSWG Virtual Meeting - Agenda Released

[Leanne Wilson]

The agenda has now been released for the mid-year GSE Large Systems Working 
Group event. The event will be a virtual event via webex on the 18th July 2017 
from 14:00 – 16:15 GMT.

If you wish to attend the event, please follow the registration link 
HERE

For the agenda please click HERE





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

Re: LE strikes again

[Binyamin Dissen]

SLIP SET,C=0C1,J=jobname,ML=1,END

Then have them load the dump into IPCS, select option 2.2 and send you the
results.

On Mon, 10 Jul 2017 18:20:16 +0700 Robin Atwood  wrote:

:>A customer has installed one of our products and gets an immediate 0C1 when
:>it is started. The customer is running

:>z/OS 1.4 on a z850 so when I received the dump I confidently expected the
:>PSW to be pointing at an unsupported

:>instruction; what I saw was 0A0D with R1=040C1000 in module CEEBTERM. So it
:>looks like LE trapped an 0C1 and then reissued it (TRAP(OFF) in CEEOPTS make
:>no difference). The customer suppresses all dumps, purges all STC 

:>logs at job end, so the only way I could get any kind of dump was to ask
:>them to set a SLIP trap. So why don't I get 

:>a dump of the original 0C1? Looking at the system trace produces:

:>  INVALID CONTROL BLOCK  TOB /03 AT 0181B640 = E3D6C240/01.   

:>  Invalid control block  TTCH/05 at 7F6DF000 = /00. 

:> System Trace processing is terminated.   

:>so that is also suppressed. Anyone any idea how I can help these people? 

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: LE strikes again

[Robin Atwood]

Yes, ignore my other post, PARM='TRAP(OFF)/' should work.

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: 10 July 2017 21:54
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: LE strikes again

>The CEEOPTS-DD-statement was new in z/OS 1.7 


Ooops..., I forgot about this fact. Too long ago.


Can you try the TRAP(OFF) via EXEC PARM? For C, I believe LE PARMs come
before program options in the PARM and have to end with a slash /


 -- 
Peter Hunkeler



--
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: LE strikes again

[Robin Atwood]

So PARM='/TRAP(OFF)' must be used?

--
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: 11 July 2017 02:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE strikes again

>You can also use a JCL statement to override (if available) LE Parms. 
 >
>
https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ce
ea500/ceedd.htm 


No, he can't because he's on z/OS 1.4. I already proposed CEEOPTS DD, and
Norbert Friemel remembered me it's not yet supported at that release.
-- 
Peter Hunkeler 


-- 
Peter Hunkeler 

--
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: DB2 Ver. 8.1 running on z/OS 2.1?

[Timothy Sipples]

An even better idea, Avram -- I like it. You're quite right that DB2
Version 10 CM should fit the bill here. DB2 10 is also still IBM supported,
although End of Service will be September 30, 2017.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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