Re: Suppluing software to run on unsupported OS was Re: LE strikes again

[Mike Schwab]

Some people haven't bought a z800 or higher.

On Wed, Jul 19, 2017 at 10:23 PM, Charles Mills <charl...@mcn.org> wrote:
> ARCH(4) is 390 mode!
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Beaver
> Sent: Wednesday, July 19, 2017 6:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Suppluing software to run on unsupported OS was Re: LE strikes
> again
>
> Tim, you may have to go to ARCH(4)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Suppluing software to run on unsupported OS was Re: LE strikes again

[Charles Mills]

ARCH(4) is 390 mode!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Wednesday, July 19, 2017 6:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suppluing software to run on unsupported OS was Re: LE strikes
again

Tim, you may have to go to ARCH(4) 

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

Re: Suppluing software to run on unsupported OS was Re: LE strikes again

[Steve Beaver]

Tim, you may have to go to ARCH(4) 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Wednesday, July 19, 2017 8:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Suppluing software to run on unsupported OS was Re: LE strikes
again

[Default] On 17 Jul 2017 00:21:14 -0700, in bit.listserv.ibm-main
abend...@gmail.com (Robin Atwood) wrote:

>Thanks for the pointer. But I suppose I should build at ARCH(5) which 
>is the lowest common denominator to deal with any other customers who 
>refuse to upgrade!
If your product assumes user connection to the Internet, is safe to from a
company liability point of view to distribute and support it for running on
unsupported systems.

Clark Morris 
>
>Robin
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Timothy Sipples
>Sent: 16 July 2017 12:14
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LE strikes again
>
>Robin Atwood wrote:
>>I had sent the customer a version of the product compiled with XL/C at
>>ARCH(7) but that was not low enough! It looks like ARCH(5) is necessary.
>
>Not quite. On a z890 (or z990) machine ARCH(6) or lower is necessary. 
>ARCH
>(5) or lower is necessary on z800 and z900 machines.
>
>---
>-
>
>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
>
>--
>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

Suppluing software to run on unsupported OS was Re: LE strikes again

[Clark Morris]

[Default] On 17 Jul 2017 00:21:14 -0700, in bit.listserv.ibm-main
abend...@gmail.com (Robin Atwood) wrote:

>Thanks for the pointer. But I suppose I should build at ARCH(5) which is the
>lowest common denominator to deal 
>with any other customers who refuse to upgrade!
If your product assumes user connection to the Internet, is safe to
from a company liability point of view to distribute and support it
for running on unsupported systems.

Clark Morris 
>
>Robin
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Timothy Sipples
>Sent: 16 July 2017 12:14
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LE strikes again
>
>Robin Atwood wrote:
>>I had sent the customer a version of the product compiled with XL/C at
>>ARCH(7) but that was not low enough! It looks like ARCH(5) is necessary.
>
>Not quite. On a z890 (or z990) machine ARCH(6) or lower is necessary. ARCH
>(5) or lower is necessary on z800 and z900 machines.
>
>
>
>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
>
>--
>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

[Brian Westerman]

I have to disagree, over the last 3 years only 5 sites were government related, 
and 2 were universities.

Brian

--
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 have a lot less experience than you do but where I see back-level software is

- Government sites, where the procurement process is complex and the cycle is 
long. 
- Certain national cultures that are very conservative
- Sites that are in the eighth year of a three-year plan to get off the 
mainframe

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Monday, July 17, 2017 7:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Running unsupported is dangerous was Re: AW: Re: LE strikes again

I sort of "specialize" in upgrading sites that have put off an upgrade to a 
more current OS for (quite) a while and I can tell you from experience with 
over 100 of these sites that there are LOTs of reasons for them being at that 
old release, and all (well, the vast majority any way) of them are not that 
they were lazy or stupid in any way.  

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

[John McKown]

On Mon, Jul 17, 2017 at 9:39 PM, Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> I sort of "specialize" in upgrading sites that have put off an upgrade to
> a more current OS for (quite) a while and I can tell you from experience
> with over 100 of these sites that there are LOTs of reasons for them being
> at that old release, and all (well, the vast majority any way) of them are
> not that they were lazy or stupid in any way.
>
> Sometimes (about 35% if the time) it was actually the external vendors
> that are the major contributor that kept them from being able to upgrade.
> How, you might ask?  Well, lets suppose have been using Adabas for 12 years
> and are paying $120K a year to SAG to run their software, and they made you
> an offer back in 2005 or so (when they (SAG) needed cash) that if you paid
> $600K in a one time charge, you would be able to run Adabas and Com-Plete
> and several other pieces of their suite "forever", don't laugh, I have seen
> the contracts.
>

​We have such contracts (old) with Compuware and BMC. We are still on a
z9BC with z/OS 1.12. Until about 2 months ago, this made complete sense
because the company had decided to "cloud-source" most of our processing.
That was recently cancelled due to "problems" with the vendor (unnamed) not
"getting it right" in all this time. Which resulted in increasing customer
complaints. First to us, then to various state "Board of Insurance"
department. That put a stick in a soft spot and got high level attention
fast. So now we are trying to undo the work of 2 years in a few months (by
Oct 1). But that costs money (increasing MSUs). And we are still desiring
"cost containment".  Things would be a bit less uncertain if the U.S.
Congress would just "do something" on healthcare - even if it is saying the
ACA is being kept as is. Can't plan a business when the rules might be
changed next week.



-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

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

[Timothy Sipples]

Of course that's up to you, but for every ARCH step you decrement you're
leaving compiler optimizations behind on the cutting room floor. For
example, if you're shipping an ARCH(5) build (z900/z800 compatible) to a
customer that can run ARCH(11) (z13/z13s), you're leaving about a decade
and a half of compiler optimizations and associated performance
improvements behind.

You can recover *some* of those compiler optimizations if you use the TUNE
parameter appropriately.

How much these optimizations matter depends on the nature and real world
usage of your product.


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

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

[Brian Westerman]

I sort of "specialize" in upgrading sites that have put off an upgrade to a 
more current OS for (quite) a while and I can tell you from experience with 
over 100 of these sites that there are LOTs of reasons for them being at that 
old release, and all (well, the vast majority any way) of them are not that 
they were lazy or stupid in any way.  

Sometimes (about 35% if the time) it was actually the external vendors that are 
the major contributor that kept them from being able to upgrade.  How, you 
might ask?  Well, lets suppose have been using Adabas for 12 years and are 
paying $120K a year to SAG to run their software, and they made you an offer 
back in 2005 or so (when they (SAG) needed cash) that if you paid $600K in a 
one time charge, you would be able to run Adabas and Com-Plete and several 
other pieces of their suite "forever", don't laugh, I have seen the contracts.  

Then you find out a couple years down the line, that SAG will let you upgrade 
to new "releases" but not the "new" version(s).  Well, actually they will, but 
there is a cost, and that cost might be $165k per year.  You are upset, you 
argue with SAG for a year (or two) and then decide that you just won't deal 
with a company who acts like that.  Unfortunately, you can't very well take on 
a 25 man-year project to convert to DB/2 and CICS, (which won't save you any 
money anyway), so you just stick with your old Adabas V7 and the old z/OS V1.4 
that runs it quite nicely.  (this is a true scenario at several sites by the 
way).  You decide, the software works fine and does what you need (for now), so 
you "settle" for it.

Then 8 to 12 years later, you are told by IBM that you just can't run the old 
mainframe hardware you have been running for 10 years any more, and they offer 
to make you a sweet deal on a z13s that will save you money on their (IBM's) 
software, plus they can kneecap the box so that it's EXACTLY the same speed as 
the old z/800.  SAG has nothing to say about it, (actually they do, but the 
contract is on your side in this case) because you are running less than the 
total MSU's that you originally licensed, but to get to the z13s, you have to 
get off z/os 1.4.  That's where I come in, and upgrade them to z/OS 1.13 (the 
highest level the z-series box they are running supported and the lowest level 
the z13s supported, and make the existing Adabas (Version 7 by the way) work on 
it.  Then I move them to the z13s and upgrade z/OS once more to V2.  Again 
keeping Adabas and all of it's products (Com-Plete, etc.) all exactly as they 
were (plus a few minor fixes to support the new underlying software).

The only thing that made them "need" to upgrade was the z13s, not that the 
existing software needed them to.  They were just as happy to use z/OS 1.4.  It 
was doing everything they needed and were basically (while way outdated) 
content.  

I don't see them as wrong to have been okay with the old OS and vendor 
software.  I didn't even mention that Compuware and 4 other vendors that this 
site used (two of which no longer even existed), also had similar "one time 
charge" deals that, while it didn't add up to the same amount of money, was 
still substantial), deals.

This is not even a one time thing, this same EXACT scenario (same general 
hardware, same general OS software levels (basically, two of them were 1.5) and 
generally the same vendors) has happened 4 separate sites in the past 2 years.  
One moved to a z114 one to a bc12 and 2 to z13s's. 

Other reasons vary for the other sites that I have helped, but it's almost 
always some variation on lack of a good motivating factor to get them to move 
"forward" combined with several "good" reasons for NOT moving forward.  In only 
a handful (maybe 3) of the over 100 sites was the reason a lack of expertise or 
ability to perform the work to stay "current".  The problem becomes, after a 
certain point, (that they don't feel until it's long past), there is no longer 
a "easy" path to move forward. 

Some of the sites have the "hardware" reason, in that the hardware they bought 
can't go any higher, and they can't afford to acquire a new box for a while, 
and when they can afford it, they are too far back to perform the conversion, 
or at least they think so, because the "conventional IBM wisdom", (which was 
never true by the way) was that you can't jump more than two z/OS releases at a 
time.  First of all, IBM never really said that, and secondly, it's just plain 
silly.  That was enough though to stop people from converting when they thought 
they were staring at not one, not two, but possibly as many as 4 conversions, 
back to back.  Sadly, even though IBM knows it's not true about jumping no more 
than one release, they didn't come forward with that information, (and actually 
fought me on it in many client meetings once I had the conversion contract(s)) 
in time to help anyone.

Also, you would probably be surprised (maybe not) to find that there are 

Re: LE strikes again

[Robin Atwood]

Thanks for the pointer. But I suppose I should build at ARCH(5) which is the
lowest common denominator to deal 
with any other customers who refuse to upgrade!

Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Timothy Sipples
Sent: 16 July 2017 12:14
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE strikes again

Robin Atwood wrote:
>I had sent the customer a version of the product compiled with XL/C at
>ARCH(7) but that was not low enough! It looks like ARCH(5) is necessary.

Not quite. On a z890 (or z990) machine ARCH(6) or lower is necessary. ARCH
(5) or lower is necessary on z800 and z900 machines.



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

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

[Timothy Sipples]

Scott Ford wrote:
>But from a application point of view, if the application is using AT/TLS
>and there are Pagent protection policies for PORTS/IP addresses and the
>application is using encryption, where's the risk ???

There's plenty of risk when running an unsupported, unpatched release. Even
leaving that important point aside, you're assuming a fact not in evidence.
z/OS 1.4 didn't have AT-TLS. AT-TLS debuted in z/OS 1.7:

https://www.ibm.com/common/ssi/rep_ca/7/897/ENUS205-167/ENUS205-167.PDF

Notably, z/OS 1.4 was Generally Available on September 27, 2002. TLS 1.1
was not even defined until April, 2006 (RFC 4346), never mind TLS 1.2 (RFC
5246 in August, 2008, and RFC 6176 in March, 2011).

FYI, the PCI Council requires an absolute minimum of TLS 1.1 (if configured
according to NIST Special Publication 800-52 Revision 1) to comply with
their Data Security Standard (DSS) Version 3.1.

A lot has happened in the past decade and a half, never mind what's soon to
happen. The "soon to happen" is also important. You simply cannot defend
yourself if you're cut off from vendor supplies of security patches or if
you don't follow a reasonable preventive maintenance program.


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

Re: LE strikes again

[Timothy Sipples]

Robin Atwood wrote:
>I had sent the customer a version of the product compiled with XL/C at
>ARCH(7) but that was not low enough! It looks like ARCH(5) is necessary.

Not quite. On a z890 (or z990) machine ARCH(6) or lower is necessary. ARCH
(5) or lower is necessary on z800 and z900 machines.


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

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

[Anne & Lynn Wheeler]

charl...@mcn.org (Charles Mills) writes:
> DoS of course = denial of service, which is a large basket. I think it
> sometimes means any sort of "bring the system down or make it
> ineffective" attack, but usually I think it refers to repeatedly
> starting a TCP session and not completing it so as to tie up resources
> and make real connections impossible.
>
> https://en.wikipedia.org/wiki/Denial-of-service_attack

re:
http://www.garlic.com/~lynn/2017g.html#74 Running unsupported is dangerous was 
Re: AW: Re: LE strikes again
http://www.garlic.com/~lynn/2017g.html#75 Running unsupported is dangerous was 
Re: AW: Re: LE strikes again
http://www.garlic.com/~lynn/2017g.html#80 Running unsupported is dangerous was 
Re: AW: Re: LE strikes again

June 17th 1995, the internet facing servers for the largest online
service provider started crashing. they brought in lots of experts to
look at the problem ... and finally one of their people flew out to
silicon valley and bought me a hamburger after work. I ate the burger
while he described the problem ... and then I gave him a Q fix that
stopped the crashing (that he installed that night). I then tried to get
vendors to address the problem but found no interest. Almost exactly a
year later there was lots of publicity about service provider in
Manhatten started crashing ...  and all of a sudden vendors started
bragging on fast they reacted.

One of the issues was that there appeared to be two different groups
... those writting the code and those writting the specs ... some
particular DOS were because small gaps between what some of the code did
and what some of the specs said ... and didn't have people that did
detailed study/understanding of both.

Until he passed, the internet standards editor would let me help with
the periodic STD1 ... he also sponsored my talk at ISI/USC why internet
wasn't (yet) business critical dataprocessing

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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 am not a TCP stack expert nor a DoS expert but I don't think of encryption 
and DoS as having much to do with each other.

DoS of course = denial of service, which is a large basket. I think it 
sometimes means any sort of "bring the system down or make it ineffective" 
attack, but usually I think it refers to repeatedly starting a TCP session and 
not completing it so as to tie up resources and make real connections 
impossible.

https://en.wikipedia.org/wiki/Denial-of-service_attack

I believe the z/OS stack used to be quite vulnerable, relying on perimeter 
devices to protect it, but I think that is no longer true.

I think Pagent may be relevant, and perhaps AT/TLS, but not encryption per se.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Saturday, July 15, 2017 8:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Running unsupported is dangerous was Re: AW: Re: LE strikes again

As a vendor i have been receiving questions about DoS attacks on z/OS ..
I understand the idea / concept of perimeter defense , i was a Network Engineer 
in a pass life.
But from a application point of view, if the application is using AT/TLS and 
there are Pagent protection policies for PORTS/IP addresses and the application 
is using encryption, where's the risk ???

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

[Anne & Lynn Wheeler]

idfli...@gmail.com (scott Ford) writes:
> As a vendor i have been receiving questions about DoS attacks on z/OS ..
> I understand the idea / concept of perimeter defense , i was a Network
> Engineer in a pass life.
> But from a application point of view, if the application is using AT/TLS
> and there are Pagent protection policies for PORTS/IP addresses and the
> application is using encryption, where's the risk ???

We had worked with some number of Oracle people supporting cluster
scaleup for our HA/CMP IBM product. We then left IBM and two of the
Oracle people from this Jan1992 Ellison meeting
http://www.garlic.com/~lynn/95.html#13

left Oracle and were at small client/server startup responsible for
"commerce server". We were brought in as consultants because they wanted
to do payment transactions on their server; the startup had also
invented this technology they called "SSL" they wanted to use; the
result is now frequently called "electronic commerce".  I had absolute
authority over server to payment network gateway but could only make
recommendations about the browser to server, some of which were almost
immediately violated, which continue to account for some number of
vulnerabilities that continue to this day. Several of the attacks have
to do with faking certificates and not recognizing the problem (enabling
things like MITM-attacks). I use to pontificate about how vulnerable
spoofing certificates were (do trust certificates from other entities)
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

Don't know how much control that installations use for AT/TLS
certificates.

One of the early "electronic commerce" vulnerabilities was increasing
number of commerce servers moving from flat files to RDBMS based
implementations. RDBMS maintenance was much more difficult and
time-consuming. For maintenance, servers would be taken offline, some
security relaxed, maintenance performed ... and then because RDBMS
maintenance more often overran window, there was mad rush to get back
online and not all of the security were turned back on.

Then apparently for having done "electronic commerce", we get pulled
into X9 financial standards meetings to help write some number of
financial standards.  I did a financial standard and secure chip. This
was in the same era as chip started ... which had lots of
vulnerabilities and took on the order of 8seconds with direct connect
power. I did chip w/o any of the vulnerabilities. Then the transit
industry asked me if the chip could also do transaction in the transit
turnstyle time limits (100milliseconds) using only contactless (RF)
power (w/o compromise any integrity). There was a large pilot of
chip in the US around the turn of the century during its "Yes Card"
period ... old cartes 2002 trip report (gone 404 but lives on at the
wayback machine) ... at the end of report, it is almost as easy to
counterfeit chip as magstripe.
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

At 2003 ATM Integrity Task Force meeting, Federal LEO gave "Yes Card"
presentation prompting somebody in the audience to exclaim that they
managed to spend billions of dollars to prove that chips were as
vulnerable as magstripe. In the wake of the "Yes Card" problems, all
evidence of the large US pilot appeared to evaporate and it was
speculated that it would be a long time before it was tried in the US
again.

some more discussion in this recent (facebook) IBM Retirees post
https://www.facebook.com/groups/62822320855/permalink/10155349644130856/

trivia: CEO of one of the cyber companies that participated in the booth
at annual, world-wide retail banking BAI show, had previously been head
of POK mainframe and then Boca PC:
http://www.garlic.com/~lynn/99.html#217
http://www.garlic.com/~lynn/99.html#224

Also did pilot code for both RADIUS and KERBEROS authentication ...
some past posts
http://www.garlic.com/~lynn/subpubkey.html#radius
and
http://www.garlic.com/~lynn/subpubkey.html#kerberos

bunch of security patents
http://www.garlic.com/~lynn/x959.html#aads

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

[scott Ford]

As a vendor i have been receiving questions about DoS attacks on z/OS ..
I understand the idea / concept of perimeter defense , i was a Network
Engineer in a pass life.
But from a application point of view, if the application is using AT/TLS
and there are Pagent protection policies for PORTS/IP addresses and the
application is using encryption, where's the risk ???

Scott

On Wed, Jul 12, 2017 at 11:09 PM, Anne & Lynn Wheeler <l...@garlic.com>
wrote:

> 000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes:
> > 8x11mm Minox camera?  I suppose physical security can interdict that.
> > https://en.wikipedia.org/wiki/Minox#Technical_details_of_
> Minox_8.C3.9711_cameras
>
> re:
> http://www.garlic.com/~lynn/2017g.html#74 Running unsupported is
> dangerous was Re: AW: Re: LE strikes again
>
> also in the wake of the company's "pentagon papers" type event, they
> retrofitted all company copier machines with serial number identifier on
> the underside of the glass, that would show up on all pages
> copied. example from this copied document over a decade later
> http://www.garlic.com/~lynn/grayft84.pdf
>
> trivia: not long after I graduated and joined the science center, the
> company got a new CSO ... as common in that era, had previously been at
> government agency & familiar with physical security (at one time head of
> presidential detail). I got tagged to run around with him for a time
> ... to talk about computer security.
>
> more trivia: I found my wifes father's WW2 status reports (from europe)
> at National Archives. They had been declassified but never "marked". The
> NA "reading room" required that cameras had to be registered (including
> serial number) and given permit and I had to have declassification tag
> that appeared in every image that I took.
> http://www.garlic.com/~lynn/dectag.jpg
>
> part of one of his reports
> http://www.garlic.com/~lynn/2010i.html#82
>
> --
> virtualization experience starting Jan1968, online at home since Mar1970
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

TRAP(OFF) in the PARM parameter did the trick, the 0C1 is caused by a CLFI
instruction which is obviously not
supported by a z850. I had sent the customer a version of the product
compiled with XL/C at ARCH(7) but that was 
not low enough! It looks like ARCH(5) is necessary.

Thanks to everyone who helped.
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: 12 July 2017 01:32
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. 
 

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

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

[Anne & Lynn Wheeler]

000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes:
> 8x11mm Minox camera?  I suppose physical security can interdict that.
> https://en.wikipedia.org/wiki/Minox#Technical_details_of_Minox_8.C3.9711_cameras

re:
http://www.garlic.com/~lynn/2017g.html#74 Running unsupported is dangerous was 
Re: AW: Re: LE strikes again

also in the wake of the company's "pentagon papers" type event, they
retrofitted all company copier machines with serial number identifier on
the underside of the glass, that would show up on all pages
copied. example from this copied document over a decade later
http://www.garlic.com/~lynn/grayft84.pdf

trivia: not long after I graduated and joined the science center, the
company got a new CSO ... as common in that era, had previously been at
government agency & familiar with physical security (at one time head of
presidential detail). I got tagged to run around with him for a time
... to talk about computer security.

more trivia: I found my wifes father's WW2 status reports (from europe)
at National Archives. They had been declassified but never "marked". The
NA "reading room" required that cameras had to be registered (including
serial number) and given permit and I had to have declassification tag
that appeared in every image that I took.
http://www.garlic.com/~lynn/dectag.jpg

part of one of his reports
http://www.garlic.com/~lynn/2010i.html#82

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

[Paul Gilmartin]

On Wed, 12 Jul 2017 18:58:44 -0700, Anne & Lynn Wheeler wrote:
>
>... all FS documents were softcopy and could only be read
>from specially connected 3270 terminals (no file copy, printing, etc,
>before ibm/pc and things like screen scraping). some FS refs
>http://www.garlic.com/~lynn/submain.html#futuresys
> 
8x11mm Minox camera?  I suppose physical security can interdict that.

https://en.wikipedia.org/wiki/Minox#Technical_details_of_Minox_8.C3.9711_cameras

-- gil

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

[Anne & Lynn Wheeler]

charl...@mcn.org (Charles Mills) writes:
> Frankly, in the beginnings of computing, including in DOS and OS/360,
> there was often an assumption that all users -- at least all "real"
> (TSO and development, as opposed to CICS or application) users -- were
> trusted. There was a lot of your gun, your bullet, your foot. The
> assumption was that the threat of dismissal was a sufficient limit on
> misbehavior.

well there is this ... going back around 50yrs
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

cambridge science center ...
http://www.garlic.com/~lynn/subtopic.html#545tech

was running its cp/67 service, allowing both other IBM locations to use
it as well as non-employees (students, professors, etc) from
universities (mit, harvard, bu) in cambridge area.

science center had also ported apl\360 to cp67/cms for cms\apl ...
expanding workspace size (from typical 16kbytes) to virtual memory size
(required redoing apl storage management for virtual memory demand paged
environment) and adding APIs to system facilities (like file read/write)
... significantly enabling real-world applications.

One of the remote internal users was business planners at Armonk hdqtrs
who loaded the most valuable corporate assets on the cambridge system
for doing business modeling in cms\apl (and it was expected that all
such information was protected from non-authorized users ... including
students around the boston/cambridge area using the system.

note before 370 virtual memory was announced ... a document somehow
leaked to an industry publication ... which resulted in something like a
"pentagon papers" event for the corporation. For the Future System
project, they attempted a countermeasure with a significantly enhanced
vm370 system where all FS documents were softcopy and could only be read
from specially connected 3270 terminals (no file copy, printing, etc,
before ibm/pc and things like screen scraping). some FS refs
http://www.garlic.com/~lynn/submain.html#futuresys

For the initial morph of CP67 to VM370, they simplified and/or dropped
a bunch of features. During the FS period I continued to work on
360/370 stuff (even when 370 efforts were being shutdown) and would
even periodically ridicule the FS efforts. Some old email about
eventually getting around to migrating from CP67 to VM370
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

I had some weekend test time at datacenter with one of these FS "secure"
vm370 systems. I was in Friday afternoon to make sure everything was
setup for my use. They couldn't resist claiming that their system was so
secure that even if I was left alone in the machine room all weekend, I
wouldn't be able to do anything. So one of the few times I took the
bait. I asked them to disable all access from outside the machine room,
and then from the front panel I changed one byte in storage ... which
disabled all security measures. I suggested if they were serious, they
had to secure/protect all machine facilities (including front panel).

trivia: during the FS period, 370 efforts were being shutdown (lack of
370 offerings during the FS period is credited with giving clone
processor makers market foothold). Then when FS finally implodes, there
is mad rush to get products back into the 370 pipeline ... including
kicking of quick efforts for 3033 and 3081. some refs:
http://www.jfsowa.com/computer/memo125.htm

this also contributes to decision for picking up various bits
(from CSC/VM mentioned in above email) for release to customers.


-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Frankly, in the beginnings of computing, including in DOS and OS/360, there was 
often an assumption that all users -- at least all "real" (TSO and development, 
as opposed to CICS or application) users -- were trusted. There was a lot of 
your gun, your bullet, your foot. The assumption was that the threat of 
dismissal was a sufficient limit on misbehavior.

We are seeing a continual plugging of the resulting holes, on this platform and 
on others.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, July 12, 2017 4:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Running unsupported is dangerous was Re: AW: Re: LE strikes again



I think it was a philosophical blunder early in OS, to presume that a caller 
could always be relied on to validate arguments, so called programs largely 
didn't make the effort.  "Trust in Allah, but tie your camel."

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

[Paul Gilmartin]

On Wed, 12 Jul 2017 18:38:39 -0400, Tony Harminc wrote:

>On 12 July 2017 at 12:21, Charles Mills wrote:
>
>> It's not the malware you know about that should worry you the most. The
>> phrase "zero day exploit" comes to mind.
>
>With something as old as z/OS 1.4 it's not even just zero-days. There
>are several well known gaping holes in z/OS that have been fixed by
>IBM in recent releases. In many cases these fixes are quietly issued
>as "security" with no detail, but in others it's virtually impossible
>to describe changed behaviour necessitated by the fix without at the
>same time giving away the vulnerability. For example (and discussed
>here at some length), until recently it was possible for anyone to use
>the UNIX execmvs() service to invoke a module in an authorized state
>and pass a PARM string of arbitrary length. So any AC(1) module in
>linklist (at least) could be attacked this way, and there is no
>shortage of them that are vulnerable. Has this been fixed in z/OS 1.4?
>It's not impossible that IBM pushed it back, with all it's required
>new infrastructure, but I doubt it.
>
I think it was a philosophical blunder early in OS, to presume that
a caller could always be relied on to validate arguments, so called
programs largely didn't make the effort.  "Trust in Allah, but tie
your camel."

Worse, in my view, is that SMP/E has an integrity flaw,  irreparable
withour revoking facilities documented as supported.  For this,
IBM's recourse since 2010 has been to restrict use of SMP/E to
programmers in a RACF-privileged class.  At that time, IBM
provided no details of the exposure.  Subsequently, the SMP/E
Ref. has provided a clearer explanation.

IBM has always cautioned that in a CMS MDFS filemode *0 can
not be trusted for security.  Over 3 decades ago, the CMS Users
guide reinforced the warning by providing details of the vulnerability.
More recently, the warning remains but the details have been
removed.  This protects users too foolhardy to respect the caution
from intruders too naive to exploit the flaw.

I am not an advocate of security by obscurity.  Publicizing a flaw
is excellent incentive to upgrade.

-- gil

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

[Tony Harminc]

On 12 July 2017 at 12:21, Charles Mills  wrote:

> It's not the malware you know about that should worry you the most. The
> phrase "zero day exploit" comes to mind.

With something as old as z/OS 1.4 it's not even just zero-days. There
are several well known gaping holes in z/OS that have been fixed by
IBM in recent releases. In many cases these fixes are quietly issued
as "security" with no detail, but in others it's virtually impossible
to describe changed behaviour necessitated by the fix without at the
same time giving away the vulnerability. For example (and discussed
here at some length), until recently it was possible for anyone to use
the UNIX execmvs() service to invoke a module in an authorized state
and pass a PARM string of arbitrary length. So any AC(1) module in
linklist (at least) could be attacked this way, and there is no
shortage of them that are vulnerable. Has this been fixed in z/OS 1.4?
It's not impossible that IBM pushed it back, with all it's required
new infrastructure, but I doubt it.

Tony H.

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

[Jim Stefanik]

I'll throw in a bit of "extra" behind this:

Anyone who works in security almost certainly has heard of Metasploit.  If not, 
Google it - it's pretty much a framework that puts known attacks into an 
easy-to-use platform for pentesting (or illicit activities if one decided to 
use it for such things).  For ages, it was said "the mainframe is safe"...then 
the Logica & Nordia breaches happened, proving that 0-days exist on the 
mainframe.  This, combined with people doing hacker-con talks on the subject, 
building modules into to Metaspoit, and developing other pentesting tools, 
means that now if you're sitting on an unpatched box and not deploying PTF's 
very quickly, some skiddy can come by and send your banking DB into oblivion 
without a huge amount of effort.

If you're interested in stuff like this, check out the con talks that Phil 
Young and Chad Rikansrud have given on this stuff. (see here this playlist of 
videos: 
https://www.youtube.com/watch?v=5Ra4Ehmifh4=7=PLBVy6TfEpKmEL56fb5AnZCM8pXXFfJS0n
 )

I'm personally putting together a talk demoing WannaCry successfully being run 
on my z800 within Linux (Linux on z + WINE = bad idea)

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Itschak Mugzach <imugz...@gmail.com>
Sent: Wednesday, July 12, 2017 13:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Running unsupported is dangerous was Re: AW: Re: LE strikes again

Just my two cents... there are many reasons why a supported and updated version 
is important, and why mainframe is just an other (big, complex) server in the 
computer room.

Linux on z: servers that were located in DMZ, now running on z usually without 
fw ("because it slows communication").
I also involved in a case where client error destroyed a large complex database 
while the user used unsupported version. IBM refused to support them (ibm 
Israel did support). At the end, I had to unload parts of the database, 
correlate them and delete destroyed ones.

Software should be one step behind last ptf and red alerts should be inserted 
immediately.



נשלח מה-iPad שלי

‫ב-12 ביולי 2017, בשעה 19:21, ‏‏Charles Mills ‏<charl...@mcn.org> כתב/ה:‬

> It's not Windows versus z/OS. Whether it is number of instances or number of
> viruses or number of mentions in airline magazines, that battle was over a
> long time ago.
>
> "Windows has more viruses than z/OS" is not a substitute for being
> up-to-date with support and patches. "But Windows is much worse" will not
> get your data or your money or your ATM network back.
>
> I work for a z/OS security software vendor. We had a prospect tell us they
> were not going to buy our product because "they had a lot of Windows systems
> and only one z/OS system, so they were not focusing on z/OS." Do you see the
> logical flaw there?
>
> It's not the malware you know about that should worry you the most. The
> phrase "zero day exploit" comes to mind.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Wednesday, July 12, 2017 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Running unsupported is dangerous was Re: AW: Re: LE strikes
> again
>
> W dniu 2017-07-12 o 15:53, Charles Mills pisze:
>>> I know some malware for Win10, but I cannot remind any for z/OS 1.4...
>> Partially because most of the community has a policy of publicizing
>> vulnerabilities, but z/OS does not. The fact that you do not know of
>> any malware for z/OS 1.whatever does not mean that it does not exist.
>>
>> Or expanding on Timothy's point, if you were developing malware, you
>> would have an interesting decision which of the two operating systems to
> target.
>> Windows is high number of instances/low value each -- kind of the
>> WalMart shopping of malware opportunities. z/OS is low number of
>> instances/high value each -- kind of the Tiffany of malware
>> opportunities. With Windows you would take a shotgun approach: "how
>> many machines can I infect, and hope to make some money off of a
>> percentage?" so naturally some number of your targets would end up
>> discovered and publicized. With z/OS, you would take a very targeted
> approach: "what one machine can I break into and steal a lot?"
>> Whether you were successful or not, there might not end up being any
>> publicity.
>>
>> Phrasing it differently, for Windows you would develop "malware" --
>> mass market malware, that would end up with a name and publicity
>> (named by the anti-malware folks, not the authors). For z/OS, you
>> would develop a specific targeted attack. 

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

[Itschak Mugzach]

Just my two cents... there are many reasons why a supported and updated version 
is important, and why mainframe is just an other (big, complex) server in the 
computer room.

Linux on z: servers that were located in DMZ, now running on z usually without 
fw ("because it slows communication").
I also involved in a case where client error destroyed a large complex database 
while the user used unsupported version. IBM refused to support them (ibm 
Israel did support). At the end, I had to unload parts of the database, 
correlate them and delete destroyed ones.

Software should be one step behind last ptf and red alerts should be inserted 
immediately.



נשלח מה-iPad שלי

‫ב-12 ביולי 2017, בשעה 19:21, ‏‏Charles Mills ‏<charl...@mcn.org> כתב/ה:‬

> It's not Windows versus z/OS. Whether it is number of instances or number of
> viruses or number of mentions in airline magazines, that battle was over a
> long time ago.
> 
> "Windows has more viruses than z/OS" is not a substitute for being
> up-to-date with support and patches. "But Windows is much worse" will not
> get your data or your money or your ATM network back.
> 
> I work for a z/OS security software vendor. We had a prospect tell us they
> were not going to buy our product because "they had a lot of Windows systems
> and only one z/OS system, so they were not focusing on z/OS." Do you see the
> logical flaw there?
> 
> It's not the malware you know about that should worry you the most. The
> phrase "zero day exploit" comes to mind.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Wednesday, July 12, 2017 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Running unsupported is dangerous was Re: AW: Re: LE strikes
> again
> 
> W dniu 2017-07-12 o 15:53, Charles Mills pisze:
>>> I know some malware for Win10, but I cannot remind any for z/OS 1.4...
>> Partially because most of the community has a policy of publicizing 
>> vulnerabilities, but z/OS does not. The fact that you do not know of 
>> any malware for z/OS 1.whatever does not mean that it does not exist.
>> 
>> Or expanding on Timothy's point, if you were developing malware, you 
>> would have an interesting decision which of the two operating systems to
> target.
>> Windows is high number of instances/low value each -- kind of the 
>> WalMart shopping of malware opportunities. z/OS is low number of 
>> instances/high value each -- kind of the Tiffany of malware 
>> opportunities. With Windows you would take a shotgun approach: "how 
>> many machines can I infect, and hope to make some money off of a 
>> percentage?" so naturally some number of your targets would end up 
>> discovered and publicized. With z/OS, you would take a very targeted
> approach: "what one machine can I break into and steal a lot?"
>> Whether you were successful or not, there might not end up being any 
>> publicity.
>> 
>> Phrasing it differently, for Windows you would develop "malware" -- 
>> mass market malware, that would end up with a name and publicity 
>> (named by the anti-malware folks, not the authors). For z/OS, you 
>> would develop a specific targeted attack. It might be an "approach," 
>> not a "malware package," and might not end up with a name (other than 
>> "XYZ Bank's ATMs were down for the third day in a row ..." or "ABC 
>> Airlines experienced a massive outage yesterday ...").
>> 
>> The absence of evidence is not the evidence of absence.
> 
> True, but ...I still rely more on z/OS 1.4 than on Windows 10. In case of
> Win10 I have proofs of evidence - it is a little bit more than lack of
> proofs.
> BTW: z/OS is quite old (including previous names) - how many viruses are
> known for this system? Yes, I know, the absence of evidence is not the
> evidence of absence - however it's 50+ years of the absence!
> 
> 
> Last, but not least: I'm NOT saying that running unsupported (and not
> patched) system is something good. Even for zOS family.
> However keeping very important data in Windows system is also not good idea,
> is 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: Running unsupported is dangerous was Re: AW: Re: LE strikes again

[Charles Mills]

It's not Windows versus z/OS. Whether it is number of instances or number of
viruses or number of mentions in airline magazines, that battle was over a
long time ago.

"Windows has more viruses than z/OS" is not a substitute for being
up-to-date with support and patches. "But Windows is much worse" will not
get your data or your money or your ATM network back.

I work for a z/OS security software vendor. We had a prospect tell us they
were not going to buy our product because "they had a lot of Windows systems
and only one z/OS system, so they were not focusing on z/OS." Do you see the
logical flaw there?

It's not the malware you know about that should worry you the most. The
phrase "zero day exploit" comes to mind.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Wednesday, July 12, 2017 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Running unsupported is dangerous was Re: AW: Re: LE strikes
again

W dniu 2017-07-12 o 15:53, Charles Mills pisze:
>> I know some malware for Win10, but I cannot remind any for z/OS 1.4...
> Partially because most of the community has a policy of publicizing 
> vulnerabilities, but z/OS does not. The fact that you do not know of 
> any malware for z/OS 1.whatever does not mean that it does not exist.
>
> Or expanding on Timothy's point, if you were developing malware, you 
> would have an interesting decision which of the two operating systems to
target.
> Windows is high number of instances/low value each -- kind of the 
> WalMart shopping of malware opportunities. z/OS is low number of 
> instances/high value each -- kind of the Tiffany of malware 
> opportunities. With Windows you would take a shotgun approach: "how 
> many machines can I infect, and hope to make some money off of a 
> percentage?" so naturally some number of your targets would end up 
> discovered and publicized. With z/OS, you would take a very targeted
approach: "what one machine can I break into and steal a lot?"
> Whether you were successful or not, there might not end up being any 
> publicity.
>
> Phrasing it differently, for Windows you would develop "malware" -- 
> mass market malware, that would end up with a name and publicity 
> (named by the anti-malware folks, not the authors). For z/OS, you 
> would develop a specific targeted attack. It might be an "approach," 
> not a "malware package," and might not end up with a name (other than 
> "XYZ Bank's ATMs were down for the third day in a row ..." or "ABC 
> Airlines experienced a massive outage yesterday ...").
>
> The absence of evidence is not the evidence of absence.

True, but ...I still rely more on z/OS 1.4 than on Windows 10. In case of
Win10 I have proofs of evidence - it is a little bit more than lack of
proofs.
BTW: z/OS is quite old (including previous names) - how many viruses are
known for this system? Yes, I know, the absence of evidence is not the
evidence of absence - however it's 50+ years of the absence!


Last, but not least: I'm NOT saying that running unsupported (and not
patched) system is something good. Even for zOS family.
However keeping very important data in Windows system is also not good idea,
is it?

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

[R.S.]

W dniu 2017-07-12 o 15:53, Charles Mills pisze:

I know some malware for Win10, but I cannot remind any for z/OS 1.4...

Partially because most of the community has a policy of publicizing
vulnerabilities, but z/OS does not. The fact that you do not know of any
malware for z/OS 1.whatever does not mean that it does not exist.

Or expanding on Timothy's point, if you were developing malware, you would
have an interesting decision which of the two operating systems to target.
Windows is high number of instances/low value each -- kind of the WalMart
shopping of malware opportunities. z/OS is low number of instances/high
value each -- kind of the Tiffany of malware opportunities. With Windows you
would take a shotgun approach: "how many machines can I infect, and hope to
make some money off of a percentage?" so naturally some number of your
targets would end up discovered and publicized. With z/OS, you would take a
very targeted approach: "what one machine can I break into and steal a lot?"
Whether you were successful or not, there might not end up being any
publicity.

Phrasing it differently, for Windows you would develop "malware" -- mass
market malware, that would end up with a name and publicity (named by the
anti-malware folks, not the authors). For z/OS, you would develop a specific
targeted attack. It might be an "approach," not a "malware package," and
might not end up with a name (other than "XYZ Bank's ATMs were down for the
third day in a row ..." or "ABC Airlines experienced a massive outage
yesterday ...").

The absence of evidence is not the evidence of absence.


True, but ...I still rely more on z/OS 1.4 than on Windows 10. In case 
of Win10 I have proofs of evidence - it is a little bit more than lack 
of proofs.
BTW: z/OS is quite old (including previous names) - how many viruses are 
known for this system? Yes, I know, the absence of evidence is not the 
evidence of absence - however it's 50+ years of the absence!



Last, but not least: I'm NOT saying that running unsupported (and not 
patched) system is something good. Even for zOS family.
However keeping very important data in Windows system is also not good 
idea, is it?


Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

[Ray Overby]

One would assume that the older z/OS system is important to the 
installation. That the data on the system is important, who can review 
and update the data is important, as well as the system's availability.


Key Resources, Inc has direct knowledge of vulnerabilities on older, 
non-supported z/OS releases (such as z/OS 1.4) that when exploited can 
comprise all data as well as the system itself. These vulnerabilities 
are exploitable regardless of any ESM (RACF|ACF2|TSS) or z/OS controls 
the installation may have in place. Neither z/OS nor your ESM can 
identify these vulnerabilities, tell you when they have been exploited, 
provide accurate forensic evidence of activities performed after an 
exploit, or stop the exploiter from doing what they wish. KRI recommends 
that you migrate to the latest supported releases ASAP AND to stay 
current on maintenance including INTEGRITY vulnerabilities.




On 7/12/2017 3:25 AM, R.S. wrote:

W dniu 2017-07-12 o 08:40, Timothy Sipples pisze:

Clark Morris wrote:

Running 1.4 on any system that isn't isolated is the equivalent
of running Windows XP.
I think Charles Mills provided some interesting, useful follow-up 
remarks.
I wholeheartedly agree that sole reliance on "perimeter" defense no 
longer
makes sense, if it ever did. Risk assessments and comparisons are 
tricky,

but let me expand on Charles's remarks a bit. In my view, the risks of
being backlevel are probably greater than Clark's analogy suggests.

Windows XP (final Service Pack) reached Microsoft's End of Support on 
April

8, 2014, except for certain variants (point of sale/embedded variants,
mainly). z/OS 1.4 can beat that, by several years. z/OS 1.4 reached 
its End

of Service date on March 31, 2007. For perspective, that date was before
Apple's first iPhone shipped. That's over a decade of security 
improvements

and patches that just aren't available for z/OS 1.4. That's a lot!


IMHO even z/OS 1.4 is worth more trust than i.e. Windows 10
I know some malware for Win10, but I cannot remind any for z/OS 1.4...





--
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 know some malware for Win10, but I cannot remind any for z/OS 1.4...

Partially because most of the community has a policy of publicizing
vulnerabilities, but z/OS does not. The fact that you do not know of any
malware for z/OS 1.whatever does not mean that it does not exist.

Or expanding on Timothy's point, if you were developing malware, you would
have an interesting decision which of the two operating systems to target.
Windows is high number of instances/low value each -- kind of the WalMart
shopping of malware opportunities. z/OS is low number of instances/high
value each -- kind of the Tiffany of malware opportunities. With Windows you
would take a shotgun approach: "how many machines can I infect, and hope to
make some money off of a percentage?" so naturally some number of your
targets would end up discovered and publicized. With z/OS, you would take a
very targeted approach: "what one machine can I break into and steal a lot?"
Whether you were successful or not, there might not end up being any
publicity.

Phrasing it differently, for Windows you would develop "malware" -- mass
market malware, that would end up with a name and publicity (named by the
anti-malware folks, not the authors). For z/OS, you would develop a specific
targeted attack. It might be an "approach," not a "malware package," and
might not end up with a name (other than "XYZ Bank's ATMs were down for the
third day in a row ..." or "ABC Airlines experienced a massive outage
yesterday ...").

The absence of evidence is not the evidence of absence.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Wednesday, July 12, 2017 1:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Running unsupported is dangerous was Re: AW: Re: LE strikes
again

W dniu 2017-07-12 o 08:40, Timothy Sipples pisze:
> Clark Morris wrote:
>> Running 1.4 on any system that isn't isolated is the equivalent of 
>> running Windows XP.
> I think Charles Mills provided some interesting, useful follow-up remarks.
> I wholeheartedly agree that sole reliance on "perimeter" defense no 
> longer makes sense, if it ever did. Risk assessments and comparisons 
> are tricky, but let me expand on Charles's remarks a bit. In my view, 
> the risks of being backlevel are probably greater than Clark's analogy
suggests.
>
> Windows XP (final Service Pack) reached Microsoft's End of Support on 
> April 8, 2014, except for certain variants (point of sale/embedded 
> variants, mainly). z/OS 1.4 can beat that, by several years. z/OS 1.4 
> reached its End of Service date on March 31, 2007. For perspective, 
> that date was before Apple's first iPhone shipped. That's over a 
> decade of security improvements and patches that just aren't available for
z/OS 1.4. That's a lot!

IMHO even z/OS 1.4 is worth more trust than i.e. Windows 10 I know some
malware for Win10, but I cannot remind any for z/OS 1.4...

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

[R.S.]

W dniu 2017-07-12 o 08:40, Timothy Sipples pisze:

Clark Morris wrote:

Running 1.4 on any system that isn't isolated is the equivalent
of running Windows XP.

I think Charles Mills provided some interesting, useful follow-up remarks.
I wholeheartedly agree that sole reliance on "perimeter" defense no longer
makes sense, if it ever did. Risk assessments and comparisons are tricky,
but let me expand on Charles's remarks a bit. In my view, the risks of
being backlevel are probably greater than Clark's analogy suggests.

Windows XP (final Service Pack) reached Microsoft's End of Support on April
8, 2014, except for certain variants (point of sale/embedded variants,
mainly). z/OS 1.4 can beat that, by several years. z/OS 1.4 reached its End
of Service date on March 31, 2007. For perspective, that date was before
Apple's first iPhone shipped. That's over a decade of security improvements
and patches that just aren't available for z/OS 1.4. That's a lot!


IMHO even z/OS 1.4 is worth more trust than i.e. Windows 10
I know some malware for Win10, but I cannot remind any for z/OS 1.4...


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

[Timothy Sipples]

Clark Morris wrote:
>Running 1.4 on any system that isn't isolated is the equivalent
>of running Windows XP.

I think Charles Mills provided some interesting, useful follow-up remarks.
I wholeheartedly agree that sole reliance on "perimeter" defense no longer
makes sense, if it ever did. Risk assessments and comparisons are tricky,
but let me expand on Charles's remarks a bit. In my view, the risks of
being backlevel are probably greater than Clark's analogy suggests.

Windows XP (final Service Pack) reached Microsoft's End of Support on April
8, 2014, except for certain variants (point of sale/embedded variants,
mainly). z/OS 1.4 can beat that, by several years. z/OS 1.4 reached its End
of Service date on March 31, 2007. For perspective, that date was before
Apple's first iPhone shipped. That's over a decade of security improvements
and patches that just aren't available for z/OS 1.4. That's a lot!

Another problem is that z/OS is almost always handling an organization's
core data, including most of its most sensitive data. "Slightly important"
data like financial account balances/transactions, personnel and payroll
files, work orders, shipments, inventories, price files, reservations, and
medical insurance records, as examples. And usually that's across a broad
swath of enterprise data, in multiple domains for multiple applications.
Windows XP may or may not be doing that, and may or may not have such broad
based data access.

It's an interesting question whether a vendor, such as a tools vendor, has
a responsibility to inform a client of these risks, or at least the nature
of these risks. I'd vote yes, that any/every vendor should provide at least
a brief caution/reminder when attempting to support a client that is no
longer receiving security updates or has not applied available HIPER
updates at least "reasonably" expeditiously.


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

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

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

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

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

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

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

AW: Re: LE strikes again

[Peter Hunkeler]

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

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

[Clark Morris]

[Default] On 10 Jul 2017 12:31:53 -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 Morris
>-- 
>Peter Hunkeler 

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

[Peter Hunkeler]

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

Re: LE strikes again

[Lizette Koehler]

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.ceea50
0/ceedd.htm



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Monday, July 10, 2017 7:54 AM
> 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

AW: Re: LE strikes again

[Peter Hunkeler]

>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

Re: LE strikes again

[Norbert Friemel]

On Mon, 10 Jul 2017 14:49:10 +0200, Peter Hunkeler wrote:

>
>Have the customer add a DD statement for CEEOPTS and add TRAP(OFF) as sysin 
>data to that.This will turn off LE's ESTAE and ESPIE routines, so you should 
>get a dump of the original problem.
>

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

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

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

Norbert Friemel

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

We tried that and it didn't make any difference. Using the IPCS LEDATA exit
with CEEDUMP tells us there there is no LE environment, which is strange
since the main module is XL/C.

Thanks
Robin

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

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


Have the customer add a DD statement for CEEOPTS and add TRAP(OFF) as sysin
data to that.This will turn off LE's ESTAE and ESPIE routines, so you should
get a dump of the original problem.

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

Don-
Thanks for that, will do. 

Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: 10 July 2017 18:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE strikes again

IPCS needs to be run with a MIGLIB from z/OS 1.4. IBM seems to be reluctant
to just provide these, so if you haven't saved one, you need to have the
customer run systrace and send you the output.

In article <00c401d2f96e$84910120$8db30360$@gmail.com> you 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? 
>  
> Thanks
> Robin

--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

[Don Poitras]

IPCS needs to be run with a MIGLIB from z/OS 1.4. IBM seems to be
reluctant to just provide these, so if you haven't saved one, you
need to have the customer run systrace and send you the output.

In article <00c401d2f96e$84910120$8db30360$@gmail.com> you 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? 
>  
> Thanks
> Robin

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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