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)
>
> ---
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
]
>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
t;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) i
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
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
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
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
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
: 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
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
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.
d 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/20
: 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 poi
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
urity 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 &q
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
>>
>>T
ported 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 copi
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
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,
artin
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 progra
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
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
x 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
he 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, Ju
.
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
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
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
o: 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
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"
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
>>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
--
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
[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
>>>
>>>
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.
--
P
>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
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
>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
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
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
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 statem
>>>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
[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
>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
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(
>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
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
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
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
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
50 matches
Mail list logo