Re: Migration off Mainframe to other platform

[Anne & Lynn Wheeler]

Tom Longfellow  writes:
> Let the pedantry begin:  Superdome, Xeon, Rack servers, Blades, etc.
> For this discussion they are all the same:  A separately maintained set 
> of many  boxes (with some virtualization to extend their reach)  versus 
> the Great Satan, called MAINFRAME.
> I have been in places where the P7 platform came in a big monolithic box 
> that had three times the memory and 'activated' CPU cores.  Looked a lot 
> like the classic CMOS mainframe to me from the outside.

trivia: Itanium architecture was in large part done by long time IBMer
who went to HP in the early 80s (originally working on "snake", HP's
risc processors). One of the last thing he did at IBM was retrofit
subset of 370/XA access registers to 3033 as dual-address space mode.
Itanium was suppose to be wide-spread next generation 64bit "server"
machine.  When AMD did 64bit I86 ... which was taking over the market
instead ... Intel also moved to 64bit I86. XEON is (supposedly) 64bit
I86 with RAS features borrowed from Itanium.

SCI was fiber optic protocol adapted for a number of things ...
including channel I/O ... but also a scalable (64-port) multiprocessor
memory interface. Sequent (& Data General) used it for 256-way server
with 64 four I486 chip boards (ibm later buys sequent).

Convex does a 128-way "snake" ... SCI with 64 two processor "HP snake"
chip boards. HP then buys Convex. An engineer that had been at Cray,
then IBM Kingston engineer, then IBM Austin RS6000 is hired
by HP to do superdome ... sort of a less expensive convex machine.

After leaving IBM, we did some consulting for both Sequent and Convex.
Then the guy doing superdome tries to talk us into joining him. At the
time we were doing some work for major payment card processor and HP had
bought one of major point-of-sale terminal companies. The former CEO of
the point-of-sale terminal company and the guy doing superdome both
report to the same HP executives ... and we have to have meetings with
all of them for different reasons.

all of these mostly predate ibm cmos highend mainframes.

While still at IBM, in 1988 I had been asked to help LLNL standardize
some serial stuff they have that quickly becomes fibre channel standard,
including some stuff I had worked with in 1980 for channel extender.
Later some POK channel engineers become involved and define a heavy
weight protocol that radically reduces the native throuput that
is eventually released as FICON.

latest peak I/O benchmark that I've found is z196 getting 2M IOPS with
104 FICON (running over 104 fibre standard). At about the same time a
fibre channel was announced for e5-2600 claiming over million IOPS (two
such have higher throughput than 104 FICON). There is reference to TCW
for zHPF that is little like what I did in 1980, but it only claims 30%
improvement (say 70 FICON instead of 104).

e5-2600v1 in the time-frame of z196 had between 400-530BIPS (depending
on model) compared to 80-way z196 rated at 50BIPS.

Since then there have been 101 ec12 at 75BIPS and 141 Z13 at 100BIPS,
and e5-2600 v2, v3, and v4 ... with v4 somewhere around 1500BIPS.

before IBM sold off its I86 server business it had announced an
high-density e5-2600 rack with something like 64 e5-2600 blades ... or
around 3500 BIPs for v1 e5-2600 and nearly 10,000 BIPS for v4 (something
like equivalent of 100 z13).

the large megadatacenters with hundreds of thousands of blades ...  have
done an enormous amount of automation, a typical megadatacenter run by
staff of 80-120 people.  However, the enormous optimization in blade
cost, blade operation, automation, etc ... by the large megadatacenters
likely contributed to IBM selling off its i86 server business.

part of z196 performance claims (compared to z10) is the introduction of
memory latency compensation features (out of order execution, branch
prediction, etc) that have been in many of these other chip platforms
for decades; with further improvements for ec12 and z13 ... although

z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
z9, 54 processors, 18BIPS (333MIPS/proc), July2005
z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012

early z13 specs said 30% more performance than ec12 (100BIPS) with 40%
more processors (or 710MIPS/processors??) ... some current z13 specs
says 40% more performance (w/40% more processors, so maybe same
MIPS/proc).

-- 
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: Ransomware on Mainframe application ?

[Paul Gilmartin]

On Mon, 15 May 2017 10:32:50 -0700, Anne & Lynn Wheeler wrote:
>...
>
>predating morris worm
>https://en.wikipedia.org/wiki/Morris_worm
>
>by nearly year, was xmas exec (email) on bitnet (this fora originated on
>corporate sponsored university bitnet).
>https://en.wikipedia.org/wiki/BITNET
>https://en.wikipedia.org/wiki/Christmas_Tree_EXEC
>
Which seems still to be available by following links from there.

But it's designed not to work after 1987.

But Y2K may have reactivated it.

-- gil

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

Re: Effect of SET PROG=xx

[Tom Conley]

On 5/15/2017 7:25 PM, Charles Mills wrote:

This is the world's dumbest question if you're a sysprog but I'm a developer
with nearly zero sysprog experience.

Whenever in the past that I have taken a quick look at SET PROG=(xx,yy) I
assumed that PROGxx + PROGyy in the parmlib concatenation *totally replaced*
the contents of whatever PROGaa and PROGbb had been specified in IEASYSxx at
IPL.

But as I read the documentation now I get the impression instead that SET
PROG=(xx,yy) causes PROGxx and PROGyy to be processed essentially as scripts
each line of which incrementally modifies whatever is already in effect. In
other words, if I entered SET PROG=ZZ and PROGZZ was devoid of statements
other than comments then the system would be left unchanged, regardless of
what had been in PROGaa and PROGbb at IPL. If PROGZZ contained one APF ADD
statement, then that DSN would get added to the APF list, much as if I had
entered SETPROG APF,ADD,DSN=...; and every other system parameter would be
left unchanged.

Is my latter impression more correct?



There are no dumb questions, only dumb developers. ;-)  SET PROG is 
additive, and yes, if you only have one line that is an APF ADD DSN, 
then it will add only that dataset.  If you add and delete lines from 
your PROG00 member (assuming you start your system with that) which 
contains only APF ADD statements, then the ADDs will be added, but the 
ADD statements you removed will still be in APFLIST.  To remove any 
datasets from APFLIST, you have to issue an explicit APF DEL with SET 
PROG, or SETPROG APF,DEL.


Regards,
Tom Conley

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

Re: Effect of SET PROG=xx

[Charles Mills]

E3 88 81 95 92 40 A8 96 A4 5A

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, May 15, 2017 4:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Effect of SET PROG=xx

On Mon, May 15, 2017 at 6:26 PM, Charles Mills  wrote:

​You are correct. What you have in the PROGnn member is an "update" to 
whatever. Anything which is not changed is left as it was. I do your APF ADD 
type operation as my normal (via SET PROG=nn and not SETPROG
APF,ADD,...) Why? Because if it is correct, I can simply edit the production 
PROGnn member and copy in the one which worked.

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

Re: Cyber attack

[Jesse 1 Robinson]

I got one over the weekend with a name I don't recognize. Did not open or 
pursue because I was suspicious. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Monday, May 15, 2017 4:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Cyber attack

I have been seen a lot of emails for what appears to be DocuSign and I have 
been killing them when I seen them


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

Re: Cyber attack

[Steve Smith]

Well, I've been getting about daily emails from them for a while.  After
verifying that htere wasn't any spoofing going on, I replied to say I had
no prior contact, no interest, and please bugger off (I'm not British, but
that sounds cool (and not nearly as vulgar to Americans as its 4-letter
equivalent)).  I actually got what appeared to be a reply from a humanoid
of some type that was just trying to do her job (she had some feminine
name, I don't remember what), albeit without engaging any higher function
(if any) in her pretty little head.

Didn't help.  Added sender to poop-list.  That did.

sas

On Mon, May 15, 2017 at 7:24 PM, Steve Beaver  wrote:

> I have been seen a lot of emails for what appears to be DocuSign and I
> have been killing them when I seen them
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: Effect of SET PROG=xx

[John McKown]

On Mon, May 15, 2017 at 6:26 PM, Charles Mills  wrote:

> This is the world's dumbest question if you're a sysprog but I'm a
> developer
> with nearly zero sysprog experience.
>
> Whenever in the past that I have taken a quick look at SET PROG=(xx,yy) I
> assumed that PROGxx + PROGyy in the parmlib concatenation *totally
> replaced*
> the contents of whatever PROGaa and PROGbb had been specified in IEASYSxx
> at
> IPL.
>
> But as I read the documentation now I get the impression instead that SET
> PROG=(xx,yy) causes PROGxx and PROGyy to be processed essentially as
> scripts
> each line of which incrementally modifies whatever is already in effect. In
> other words, if I entered SET PROG=ZZ and PROGZZ was devoid of statements
> other than comments then the system would be left unchanged, regardless of
> what had been in PROGaa and PROGbb at IPL. If PROGZZ contained one APF ADD
> statement, then that DSN would get added to the APF list, much as if I had
> entered SETPROG APF,ADD,DSN=...; and every other system parameter would be
> left unchanged.
>
> Is my latter impression more correct?
>
> (And yes, I'm contemplating playing with a sandbox system, not a production
> system. I get that this is serious stuff. That's why I'm asking.)
>
> Thanks,
>
> Charles
>
>
​You are correct. What you have in the PROGnn member is an "update" to
whatever. Anything which is not changed is left as it was. I do your APF
ADD type operation as my normal (via SET PROG=nn and not SETPROG
APF,ADD,...) Why? Because if it is correct, I can simply edit the
production PROGnn member and copy in the one which worked.


-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

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

Effect of SET PROG=xx

[Charles Mills]

This is the world's dumbest question if you're a sysprog but I'm a developer
with nearly zero sysprog experience.

Whenever in the past that I have taken a quick look at SET PROG=(xx,yy) I
assumed that PROGxx + PROGyy in the parmlib concatenation *totally replaced*
the contents of whatever PROGaa and PROGbb had been specified in IEASYSxx at
IPL.

But as I read the documentation now I get the impression instead that SET
PROG=(xx,yy) causes PROGxx and PROGyy to be processed essentially as scripts
each line of which incrementally modifies whatever is already in effect. In
other words, if I entered SET PROG=ZZ and PROGZZ was devoid of statements
other than comments then the system would be left unchanged, regardless of
what had been in PROGaa and PROGbb at IPL. If PROGZZ contained one APF ADD
statement, then that DSN would get added to the APF list, much as if I had
entered SETPROG APF,ADD,DSN=...; and every other system parameter would be
left unchanged.

Is my latter impression more correct?

(And yes, I'm contemplating playing with a sandbox system, not a production
system. I get that this is serious stuff. That's why I'm asking.)

Thanks,

Charles 

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

Cyber attack

[Steve Beaver]

I have been seen a lot of emails for what appears to be DocuSign and I have 
been killing them when I seen them

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

Re: Ransomware on Mainframe application ?

[Anne & Lynn Wheeler]

mainfr...@bigendiansmalls.com (Chad Rikansrud) writes:
> As Charles pointed out - the hypothetical attack is about just taking
> over the privileged user's PC and launching from there.

when corporations first started using VPN software over internet into
corporate sites ... we pointed out trivial attack to take over the PC
via the internet connection ... and then from the PC, tunnel through the
VPN connection into corporate dataprocessing.

in IBM Retirees facebook discussion, there has been a lot about recent
news articles on buffett unloading IBM:

Buffett cuts stake in IBM and shares slide
https://phys.org/news/2017-05-buffett-stake-ibm.html
Not Just Buffett: IBM Unit Sells IBM, Wells Fargo
http://www.barrons.com/articles/not-just-buffett-ibm-unit-sells-ibm-wells-fargo-1494590407

But Buffett has also waded in on cybersecurity

Warren Buffett's cybersecurity wake-up call -- are we listening?
http://thehill.com/blogs/pundits-blog/technology/333026-warren-buffetts-cybersecurity-wake-up-call-are-we-listening

recent post about this predates Buffett recent reference going back more
than 20yrs
http://www.garlic.ccom/~lynn/2017e.html#85 Time to sack the cheif of computing 
in the NHS

includes reference to conference that Tandem/Compaq & Atalla (ATM
machine crypto company that Tandem had bought) put on for me ... really
long winded posting from Jan1999:
http://www.garlic.com/~lynn/aepay3.htm#riskm

I have prototype secure chip (strong authentication for both sessions
and transactions) demos/booth at world wide retail banking show Dec1999:
http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week

trivia: the CEO of one of the security companies that participated in
both the conference and the BAI demo ... had at one time been head of
mainframe POK.

recent posts
http://www.garlic.com/~lynn/2017e.html#90 Ransomware on Mainframe application ?
http://www.garlic.com/~lynn/2017e.html#91 Ransomware on Mainframe application ?
http://www.garlic.com/~lynn/2017e.html#92 Check out New Wave of Ransom Threats 
Seen in Unprecedented Attack - Bloomberg

-- 
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: Check out New Wave of Ransom Threats Seen in Unprecedented Attack - Bloomberg

[Anne & Lynn Wheeler]

000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes:
> Anyone can take anyone to court. That's not the question. As [a] Civil
> Procedure professor said, "You can sue the Bishop of Boston for
> bastardy. But can you collect?"  (Origin obscure.)

when I first moved to boston area and joined the ibm science center, a
parish north of boston was about to sue the cardinal, they had a bond
for something like $26M for building new catholic high school. As soon
as it was built, cardinal sells off the new high school and keeps the
money (leaving the parish still on the hook for the $26M bond). The
parish was about to sue the cardinal for the money, when the cardinal
has late night, backroom (described as cigar smoke filled) session with
the legislature ... which passes special law allowing cardinal to keep
the money (and immune from civil liability). It was explained to me that
such things go on in the boston area all the time.

recent posts mentioning ransoms:
http://www.garlic.com/~lynn/2017e.html#84 Time to sack the chief of computing 
in the NHS?
http://www.garlic.com/~lynn/2017e.html#90 Ransomware on Mainframe application ?
http://www.garlic.com/~lynn/2017e.html#91 Ransomware on Mainframe application ?

-- 
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: Ransomware on Mainframe application ?

[Chad Rikansrud]

Hi Mike,

It's the second link here:

https://www.bigendiansmalls.com/share2017/

As Charles pointed out - the hypothetical attack is about just taking over the 
privileged user's PC and launching from there. 

Happy to discuss if you want to email me offline.

Chad

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

FW: [WEBINAR] WannaCry Ransomware - Correct Link

[Nims,Alva John (Al)]

Let’s see how well this survives going through the list server, but I received 
this today.

If anyone would like this forwarded in HTML format, please email me directly at:

ajn...@ufl.edu

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

From: IBM Security [mailto:market...@emm.ibmmail.com]
Sent: Monday, May 15, 2017 4:10 PM
To: Nims,Alva John (Al)
Subject: [WEBINAR] WannaCry Ransomware - Correct Link




Register for our live webinar.

View in 
Browser








[IBM 
Security]



Register Now 
→







[http://link-em-us.unicaondemand.com/frontend/assets?accountId=256=ec_163466_149487820_=706589=jpg]




How to Protect Against
the WannaCry Ransomeware Attack
Tuesday, May 16th



|

11:00 AM ET

The WannaCry Ransomware Attack is the biggest coordinated cyberattack of its 
kind, impacting numerous organizations including several of the world’s most 
critical healthcare and telecommunications systems. WannaCry has infected 
hundreds of thousands of endpoints spanning more than 100 countries; bringing 
essential businesses to a halt.

Organizations around the world need to understand the elements of these attacks 
and be prepared to quickly address the potential for copy-cat attacks.












Register for the Live 
Webinar



[Watch 
Demo]



Join Diana Kelley, IBM Executive Security 
Advisor,
 for a deep look into WannaCry, where our experts will help you understand the 
anatomy of the ransomware attack, and what you can do immediately to protect 
your organization.



REGISTER NOW 
→




























Any Questions?



Call us at: 1-800-426-9990 or Email us: 
secur...@ibm.com




























CONNECT WITH US:



[Facebook]



[YouTube]



[Blog]



[LinkedIn]



[Twitter]





© Copyright IBM Corporation 2017. All rights reserved. IBM, the IBM logo, and 
ibm.com are trademarks of International Business Machines Corp., registered in 
many jurisdictions worldwide. Other product and service names might be 
trademarks of IBM or other companies. A current list of IBM trademarks is 
available on the web at “Copyright and trademark information” at 
www.ibm.com/legal/copytrade.shtml.




If you'd like IBM to refrain from sending you similar e-mails in the future, 
please Click 
Here.
You may also mail a written request to IBM US at:

IBM Corporation, 11501 Burnet Rd, Bldg 904 3B-000, Austin, TX 78758









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

Re: Ransomware on Mainframe application ?

[Mike Schwab]

Here is some lengthy video interviews with him.
https://www.google.ca/search?q=big+endian+smalls=1

On Mon, May 15, 2017 at 3:13 PM, Charles Mills  wrote:
> I don't see it on the SHARE site and I am not sure what is private and what 
> is public in any event. Also much of what he showed was live so it would not 
> survive in a PDF.
>
> Chad is on this list as @Bigendian Smalls. Perhaps he will jump in. I BCC'ed 
> his real e-mail address.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Ward, Mike S
> Sent: Monday, May 15, 2017 12:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ransomware on Mainframe application ?
>
> Do you have a link to the Share presentation?
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Charles Mills
> Sent: Monday, May 15, 2017 10:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ransomware on Mainframe application ?
>
> No, but Chad Rikansrud did a presentation on the possibility of mainframe 
> ransomware at SHARE San Jose that was positively chilling.
>
> He demonstrated (independent of each other) five building blocks that would 
> be all someone would need to lock up a mainframe. "Two things that mainframes 
> do really well: encryption and fast disk I/O." Consider the implications if 
> your primary backup is real-time replication ...
>
> But, you say, mainframes don't have people clicking on links in e-mail. No, 
> but system programmers with privileged access have PCs and click on links in 
> e-mail.
>
> --
> 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: Check out New Wave of Ransom Threats Seen in Unprecedented Attack - Bloomberg

[Paul Gilmartin]

On Mon, 15 May 2017 14:53:27 -0500, Mike Schwab wrote:

>And the attack was based on NSA knowledge they kept hidden for years.
>Hope they get their ass sued off.
>
Anyone can take anyone to court. That's not the question. As [a] Civil Procedure
professor said, "You can sue the Bishop of Boston for bastardy. But can you 
collect?"
(Origin obscure.)

Would it be better if NSA had released the information before the
vulnerable software was end-of-service?

(Well, yes, if they had notified the vendor in time to create a patch.)

>On Mon, May 15, 2017 at 3:33 AM, Edward Finnell wrote:
>> _New  Wave of Ransom Threats Seen in Unprecedented Attack - Bloomberg_
>> (https://www.bloomberg.com/news/articles/2017-05-14/hospitals-gain-control-in-ran
>> som-hack-more-attacks-may-come)
>> https://www.bloomberg.com/news/articles/2017-05-14/hospitals-gain-control-in-ransom-hack-more-attacks-may-come
>>
(URL repaired.  Ed F. tends to break them.)

-- gil

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

Re: Check out New Wave of Ransom Threats Seen in Unprecedented Attack - Bloomberg

[Charles Mills]

Spy agencies tend to keep things secret ...

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Monday, May 15, 2017 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Check out New Wave of Ransom Threats Seen in Unprecedented Attack 
- Bloomberg

And the attack was based on NSA knowledge they kept hidden for years.
Hope they get their ass sued off.

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

Re: Ransomware on Mainframe application ?

[Charles Mills]

I don't see it on the SHARE site and I am not sure what is private and what is 
public in any event. Also much of what he showed was live so it would not 
survive in a PDF.

Chad is on this list as @Bigendian Smalls. Perhaps he will jump in. I BCC'ed 
his real e-mail address.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ward, Mike S
Sent: Monday, May 15, 2017 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ransomware on Mainframe application ?

Do you have a link to the Share presentation?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, May 15, 2017 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ransomware on Mainframe application ?

No, but Chad Rikansrud did a presentation on the possibility of mainframe 
ransomware at SHARE San Jose that was positively chilling.

He demonstrated (independent of each other) five building blocks that would be 
all someone would need to lock up a mainframe. "Two things that mainframes do 
really well: encryption and fast disk I/O." Consider the implications if your 
primary backup is real-time replication ...

But, you say, mainframes don't have people clicking on links in e-mail. No, but 
system programmers with privileged access have PCs and click on links in e-mail.

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

Re: Check out New Wave of Ransom Threats Seen in Unprecedented Attack - Bloomberg

[Mike Schwab]

And the attack was based on NSA knowledge they kept hidden for years.
Hope they get their ass sued off.

On Mon, May 15, 2017 at 3:33 AM, Edward Finnell
<000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> _New  Wave of Ransom Threats Seen in Unprecedented Attack - Bloomberg_
> (https://www.bloomberg.com/news/articles/2017-05-14/hospitals-gain-control-in-ran
> som-hack-more-attacks-may-come)
>
> --
> 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: Ransomware on Mainframe application ?

[Ward, Mike S]

Do you have a link to the Share presentation?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, May 15, 2017 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ransomware on Mainframe application ?

No, but Chad Rikansrud did a presentation on the possibility of mainframe 
ransomware at SHARE San Jose that was positively chilling.

He demonstrated (independent of each other) five building blocks that would be 
all someone would need to lock up a mainframe. "Two things that mainframes do 
really well: encryption and fast disk I/O." Consider the implications if your 
primary backup is real-time replication ...

But, you say, mainframes don't have people clicking on links in e-mail. No, but 
system programmers with privileged access have PCs and click on links in e-mail.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Monday, May 15, 2017 12:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ransomware on Mainframe application ?

Hi

Just curious if recent ransomware attack has capability to infect any 
applications running on Mainframe ?

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: AUTOIPL SADUMP LOADPARM flag value

[Jesse 1 Robinson]

Ah yes, I remember seeing that advice during our latest GDPS upgrade. Unless 
(again) I'm missing something, that statement in its short form is misleading. 
In practice, we mirror (XRC, not PPRC) from one data center to another. GDPS 
runs in the remote data center to 'pull' data from production. The GDPS 'K 
system' runs there but does not perform any IPLs except to bring up DR systems 
for the first time. That's not what AUTOIPL impacts anyway until after DR IPL, 
by which time GDPS is totally out of the picture. 

I'm dimly aware that GDPS can be set up differently for other purposes. In our 
case, I cannot imagine how GDPS would even know about AUTOIPL, much less be 
inconvenienced by it.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bruce Hewson
Sent: Sunday, May 14, 2017 9:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: AUTOIPL SADUMP LOADPARM flag value

Hello Skip,

GDPS-PPRC - doesn't like any IPL activity that is not performed via the GDPS 
panels.

extract from:-

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieag300/wsat.htm

Note:
AutoIPL is not appropriate in a GDPS® environment.


Regards
Bruce


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

Re: Ransomware on Mainframe application ?

[Anne & Lynn Wheeler]

trivia from long ago and far away, gone 404, but lives on
at the way back machine:
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

I didn't learn about them until much later. As undergraduate did lots of
work on IBM software and I would even get requests from IBM for
enhancements ... in retrospect, some of the requests may have originated
from these guys.

ibmmain post from march about learning that there were three kinds of
crypto around the mid-80s.
http://www.garlic.com/~lynn/2017c.html#69 ComputerWorld Says: Cobol plays major 
role in U.S. government breaches
also referenced in this more recent post
http://www.garlic.com/~lynn/2017e.html#58 A flaw in the design; The Internet's 
founders saw its promise but didn't foresee users attacking one another

-- 
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: Ransomware on Mainframe application ?

[Anne & Lynn Wheeler]

000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes:
> A recurrent question in these fora is, "How can I make links appearing
> in documents viewed in a mainframe editor active?"  Cbttape.org
> probably has an answer.  Or an ISV.
>
> Many years ago, when the risks of TCP/IP were first suspected (the
> perceived hazard then was information theft), someone suggested
> hereabouts that only authorized data administrators should be allowed
> use of TCP/IP.  No, was the counter, people with such authority should
> be forbidden TCP/IP, which shoulc be allowed only to users with weak,
> harmless IDs and no access to sensitive data.
>
> Years ago, at the height of the Good Times virus hoax, the
> conventional and correct wisdom was that viruses spread only by floppy
> disks, not by email.  Microsoft and others jumped in to fill that
> void.

predating morris worm
https://en.wikipedia.org/wiki/Morris_worm

by nearly year, was xmas exec (email) on bitnet (this fora originated on
corporate sponsored university bitnet).
https://en.wikipedia.org/wiki/BITNET
https://en.wikipedia.org/wiki/Christmas_Tree_EXEC

we had looked at problem before that ... but people wanted to do things
like that anyway.

recent thread
http://www.garlic.com/~lynn/2017e.html#47 A flaw in the design; The Internet's 
founders saw its promise but didn't foresee users attacking one another
http://www.garlic.com/~lynn/2017e.html#49 A flaw in the design; The Internet's 
founders saw its promise but didn't foresee users attacking one another
http://www.garlic.com/~lynn/2017e.html#50 A flaw in the design; The Internet's 
founders saw its promise but didn't foresee users attacking one another
http://www.garlic.com/~lynn/2017e.html#56 A flaw in the design; The Internet's 
founders saw its promise but didn't foresee users attacking one another
http://www.garlic.com/~lynn/2017e.html#59 A flaw in the design; The Internet's 
founders saw its promise but didn't foresee users attacking one another
http://www.garlic.com/~lynn/2017e.html#83 Time to sack the chief of computing 
in the NHS?
http://www.garlic.com/~lynn/2017e.html#85 Time to sack the chief of computing 
in the NHS?

at 1996 Moscone MDC, all the banners said "internet" but the constant
refrain in all the sessions was "preserve your investment". The issue
was that a paradigm of automatic executed scripts included in data files
had grown on on small, private, safe, business lans ...  and was being
extended to the wild anarchy of the internet w/o any additional
countermeasures.

Until he passes, the Internet RFC standards editor use to let me help
with STD1. He also sponsored my talk on Why the internet isn't business
critical dataprocessing for ISI and USC computer security graduate
students (in part based on the compensating procedures I had to do for
"electronic commerce"). recent reference
http://www.galric.com/~lynn/2017e.html#11 The Geniuses that Anticipated the 
Idea of the Internet
http://www.galric.com/~lynn/2017e.html#14 The Geniuses that Anticipated the 
Idea of the Internet

Shortly after graduation and joining the science center had (also)
ported APL\360 to CP/67-CMS for CMS\APL ... redoing memory management
for large virtual memory, demand paged environment, also adding API to
system services (like file i/o), opening APL to doing real world
applications.  One of the early users on CMS\APL on the science center
system were the business planners in Armonk hdqtrs, loading the most
valuable corporate data ... detailed customer information, and doing
business models. The science center also had a lot of non-employee
users, including staff and students from universities in the boston area
(mit, bu, etc). As a result, we had to demonstrate a very high level of
integrity and security.

A couple years later, IBM had hired former gov. employee as CSO (at one
time had been head of presidential detail) and I got assigned to run
around with him ... talking about computer security (and learning a
little about physical security).

-- 
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: ATTACH with RSAPF=YES

[Mike Shaw]

On 5/15/2017 12:45 PM, Greg Dyck wrote:

On 5/15/2017 11:27 AM, Paul Gilmartin wrote:

What does the TSO TMP use to accomplish this?


Extreme care ;-)

It has been a while, but my memory is that the TMP stops all of the
tasks above (or is that below?) it in the task tree and then passes the
request to a special jobstep task (with it's own JSCB) to execute the
command.

Regards,
Greg


Greg is correct; IKJEFT02 and its subtasks are STATUS STOP'ed, and a new 
parallel (sister) task is attached to invoke anything needing APF 
authorization. The TSO/E TSOEXEC command exists to do just that.


Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

Re: ATTACH with RSAPF=YES

[Greg Dyck]

On 5/15/2017 11:27 AM, Paul Gilmartin wrote:

What does the TSO TMP use to accomplish this?


Extreme care ;-)

It has been a while, but my memory is that the TMP stops all of the 
tasks above (or is that below?) it in the task tree and then passes the 
request to a special jobstep task (with it's own JSCB) to execute the 
command.


Regards,
Greg

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

Re: Ransomware on Mainframe application ?

[Paul Gilmartin]

On Mon, 15 May 2017 08:35:18 -0700, Charles Mills wrote:
>
>But, you say, mainframes don't have people clicking on links in e-mail. No, 
>but system programmers with privileged access have PCs and click on links in 
>e-mail.
> 
A recurrent question in these fora is, "How can I make links appearing in 
documents
viewed in a mainframe editor active?"  Cbttape.org probably has an answer.  Or 
an ISV.

Many years ago, when the risks of TCP/IP were first suspected (the perceived 
hazard
then was information theft), someone suggested hereabouts that only authorized
data administrators should be allowed use of TCP/IP.  No, was the counter, 
people
with such authority should be forbidden TCP/IP, which shoulc be allowed only to
users with weak, harmless IDs and no access to sensitive data.

Years ago, at the height of the Good Times virus hoax, the conventional and 
correct
wisdom was that viruses spread only by floppy disks, not by email.  Microsoft 
and
others jumped in to fill that void.

-- gil

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

Re: Ransomware on Mainframe application ?

[Tony Harminc]

On 15 May 2017 at 03:48, Edward Finnell <
000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> The 'wannacry' exploits security holes in Windows that have been there
> forever. M$ released patches for Win7 and Win10(not sure about 8 and 9).
> These
> were exposed by wikileaks dump of some NSA tricks to backdoor PC's and
> networks.
>

It wasn't Wikileaks; they show at least some sense of responsibility in
what they disclose. This was the so-called Shadow Brokers - the guys with
the weirdly fake Russian English who last year purported to be auctioning
NSA material, and then recently published the key to the encrypted data
they had previously published, and which was widely mirrored already.

https://www.schneier.com/blog/archives/2017/05/who_is_publishi.html

Schneier thinks it's the Russians, but who of us without clearances (or
maybe even with) really knows...

Tony H.

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

Re: ATTACH with RSAPF=YES

[Paul Gilmartin]

On Mon, 15 May 2017 10:28:37 -0400, Steve Smith wrote:

>RSAPF probably shouldn't even be documented.  AFAIK, it's only purpose is
>to allow the system to support unauthorized tasks and jobs, and is used
>only with the creation of a new job-step task.  And there is no
>communication between the initiator task and the user task.
> 
What does the TSO TMP use to accomplish this?

(Topic drift:  What's the difference between INTRDR and TSOINRDR?)

>Authorized programs aren't allowed to invoke unauthorized code for a very
>good reason.  Trying to circumvent that in any way compromises your system
>integrity.  That said, running bad authorized code does as well, so caveat
>emptor.
> 
A couple contributors have suggested fork().  A similar option is BPX1EXM.
But all such facilities introduce complexities in communication between
parent and child processes.

-- gil

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

'Hidden Figures' Physicist Katherine Johnson Will Deliver Hampton University Commencement Address

[David Boyes]

If anyone's going to be in Hampton in May, here's a chance to hear one of the 
real figures behind the 'Hidden Figures' movie speak.  

https://amp-timeinc-net.cdn.ampproject.org/c/amp.timeinc.net/essence/news/hidden-figures-katherine-johnson-hampton-commencement?source=dam

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

Re: ATTACH with RSAPF=YES

[Jesse 1 Robinson]

At a long-gone bank, we ran IBM's check processing application CPCS, which 
needed to run APF authorized. This meant that any program called by CPCS needed 
to come from an APF library. For whatever reason, CPCS invoked standard 
utilities such as DFSORT, which meant that those libraries also had to be APF 
just so the programs could be called by CPCS. 

We learned at some point about the possibility of flipping JSCBAUTH to tweak 
the APF mode. But CPCS was a multitasking application that was doing lots of 
things concurrently. There is only one JSCBAUTH flag. If turned it off for, 
say, SORT processing, we would very likely kill some other subtask that needed 
APF on. We decided that was pretty much impossible to manage. So everything 
that ran within CPCS came from an APF library. Note that individual programs do 
not need APF=1, but the library needs to be in APF list. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Monday, May 15, 2017 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: ATTACH with RSAPF=YES

RSAPF probably shouldn't even be documented.  AFAIK, it's only purpose is to 
allow the system to support unauthorized tasks and jobs, and is used only with 
the creation of a new job-step task.  And there is no communication between the 
initiator task and the user task.

Authorized programs aren't allowed to invoke unauthorized code for a very good 
reason.  Trying to circumvent that in any way compromises your system 
integrity.  That said, running bad authorized code does as well, so caveat 
emptor.

sas

On Mon, May 15, 2017 at 10:16 AM, Walt Farrell 
wrote:

> On Mon, 15 May 2017 15:18:38 +0700, Robin Atwood 
> wrote:
>
> >We have a requirement to attach user modules from an unauthorised 
> >library and execute them from an STC which
> >
> >runs APF authorised. Calling ATTACH with RSAPF=YES seems to do 
> >exactly
> what
> >I want ...
>
> It _can_ do what you want, Robin, but as others have said it is very 
> risky to do this, and very complex to do it safely. Basically, what 
> you're trying will only work safely if your STC is designed properly 
> to allow it. At a minimum, I believe that means making sure that none 
> of your STC code runs in key 8 or uses key 8 storage. It would need to 
> start from the beginning in a system key, specified by the Program 
> Properties Table in PARMLIB. You could then, possibly, invoke the 
> non-APF code safely as long as you run it in key 8.
>
> But the question then becomes what do you expect the non-APF code to 
> do, and how do you expect to communicate with it.
>
> It really would be better and safer, in my opinion, to find another 
> solution. This might possibly involve using multiple address spaces 
> (via UNIX fork()) as John McKown suggested. But we would really need 
> to know a lot more information about your STC, and the non-APF code, 
> to be able to provide the best advice.
>
> (It is very unlikely, in my experience, that your current STC is 
> designed to allow you to do this safely. A major redesign and 
> reimplementation of the STC would probably be required if you haven't 
> been thinking about this from the very beginning of its development.)
>
> --
> Walt


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

Re: Ransomware on Mainframe application ?

[Charles Mills]

No, but Chad Rikansrud did a presentation on the possibility of mainframe 
ransomware at SHARE San Jose that was positively chilling.

He demonstrated (independent of each other) five building blocks that would be 
all someone would need to lock up a mainframe. "Two things that mainframes do 
really well: encryption and fast disk I/O." Consider the implications if your 
primary backup is real-time replication ...

But, you say, mainframes don't have people clicking on links in e-mail. No, but 
system programmers with privileged access have PCs and click on links in e-mail.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Monday, May 15, 2017 12:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ransomware on Mainframe application ?

Hi

Just curious if recent ransomware attack has capability to infect any 
applications running on Mainframe ?

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

Re: AW: Re: job output into dataset

[Lizette Koehler]

A $S with nothing else is to Start JES2 Processing.  Please review the JES2 
Commands manual for what it does. 

If you are not the system programmer, you need to work with that team at your 
shop.  When you change the STC Class in the JES2 INIT DECK, it is changed for 
ALL STCs.  This could impact space in your SPOOL and CKPT dataset for JES2.

If you have a Sandbox to work in, you will need to work with the commands and 
see how each works.

The JES2 COMMANDS manual can be helpful when learning new functions in JES2.

The JES2 INIT and TUNING Reference can be helpful when learning new functions.

Working with your z/OS System programmer can be helpful when setting up new 
functions.


Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of venkat kulkarni
> Sent: Sunday, May 14, 2017 9:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AW: Re: job output into dataset
> 
> Hello Lizette,
> 
> So, After modifying STC job class JES2 Log parameter with spin, i will have
> to use $S command to start this process.
> 
> Please suggest, as I have not used this before.
> 
> Thanks
> 
> On 14-May-2017 3:09 PM, "venkat kulkarni" 
> wrote:
> 
> > 1) Finally, we wanted all STC JES DD to be spin off at morning 9 AM daily.
> >
> > 2) So, I set my STC Job class to
> >
> >
> >
> > RESPONSE=TST1
> >
> >   $HASP837 JOBCLASS(STC)
> >
> >   $HASP837 JOBCLASS(STC)   AUTH=(ALL),BLP=YES,COMMAND=EXECUTE,
> >
> >   $HASP837 CONDPURG=YES,DSENQSHR=ALLOW,
> >
> >   $HASP837 IEFUJP=YES,IEFUSO=YES,JESLOG=(SPIN,
> >
> >   $HASP837 +0:15),LOG=YES,MSGLEVEL=(1,1),
> >
> >   $HASP837 MSGCLASS=Z,OUTDISP=(HOLD,HOLD),
> >
> >   $HASP837 OUTPUT=YES,PERFORM=000,PROCLIB=00,
> >
> >   $HASP837 QAFF=(ANY),REGION=0004M,SWA=BELOW,
> >
> >   $HASP837 TIME=(000120,00),TYPE26=YES,
> >
> >   $HASP837 TYPE6=YES
> >
> >
> >
> >
> >
> > 3) My MSGCLASS Z is set to
> >
> >
> >
> > RESPONSE=TST1
> >
> >  $HASP842 OUTCLASS(Z)
> >
> >  $HASP842 OUTCLASS(Z)  OUTPUT=PRINT,BLNKTRNC=YES,
> >
> >  $HASP842  OUTDISP=(PURGE,HOLD),TRKCELL=NO
> >
> >
> >
> >
> >
> > 3) After all this above changes, I restarted my one of the STC task ,
> > IMS address space to test and result is
> >
> >
> >
> > a) I am able to spin JES DD manually by using "W" command or by using
> > /$T JQ(IMS12IMS),SPIN,DDNAME=JESMSGLG command and I can see output in
> > held queue.
> >
> > b) But if you look at changes, I made above in my JESLOG parameter in
> > STC class to start spin in every 15 min, it’s not starting. I am not
> > able to find root cause of this issue now.
> >
> >
> >
> > I want to know that what more I am missing to start this automated
> > SPIN working for my all STC task
> >
> > On 12-May-2017 5:05 PM, "venkat kulkarni" 
> > wrote:
> >
> >> Thanks and I made all these suggested changes in stc class jes
> >> parmlib member.
> >> But to take this in effect, do I need to restart the address space or
> >> it will pick up these new value automatically after changing stc
> >> class using $T command.
> >>

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

Re: ATTACH with RSAPF=YES

[Steve Smith]

RSAPF probably shouldn't even be documented.  AFAIK, it's only purpose is
to allow the system to support unauthorized tasks and jobs, and is used
only with the creation of a new job-step task.  And there is no
communication between the initiator task and the user task.

Authorized programs aren't allowed to invoke unauthorized code for a very
good reason.  Trying to circumvent that in any way compromises your system
integrity.  That said, running bad authorized code does as well, so caveat
emptor.

sas

On Mon, May 15, 2017 at 10:16 AM, Walt Farrell 
wrote:

> On Mon, 15 May 2017 15:18:38 +0700, Robin Atwood 
> wrote:
>
> >We have a requirement to attach user modules from an unauthorised library
> >and execute them from an STC which
> >
> >runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly
> what
> >I want ...
>
> It _can_ do what you want, Robin, but as others have said it is very risky
> to do this, and very complex to do it safely. Basically, what you're trying
> will only work safely if your STC is designed properly to allow it. At a
> minimum, I believe that means making sure that none of your STC code runs
> in key 8 or uses key 8 storage. It would need to start from the beginning
> in a system key, specified by the Program Properties Table in PARMLIB. You
> could then, possibly, invoke the non-APF code safely as long as you run it
> in key 8.
>
> But the question then becomes what do you expect the non-APF code to do,
> and how do you expect to communicate with it.
>
> It really would be better and safer, in my opinion, to find another
> solution. This might possibly involve using multiple address spaces (via
> UNIX fork()) as John McKown suggested. But we would really need to know a
> lot more information about your STC, and the non-APF code, to be able to
> provide the best advice.
>
> (It is very unlikely, in my experience, that your current STC is designed
> to allow you to do this safely. A major redesign and reimplementation of
> the STC would probably be required if you haven't been thinking about this
> from the very beginning of its development.)
>
> --
> Walt
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: ATTACH with RSAPF=YES

[Walt Farrell]

On Mon, 15 May 2017 15:18:38 +0700, Robin Atwood  wrote:

>We have a requirement to attach user modules from an unauthorised library
>and execute them from an STC which
>
>runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
>I want ...

It _can_ do what you want, Robin, but as others have said it is very risky to 
do this, and very complex to do it safely. Basically, what you're trying will 
only work safely if your STC is designed properly to allow it. At a minimum, I 
believe that means making sure that none of your STC code runs in key 8 or uses 
key 8 storage. It would need to start from the beginning in a system key, 
specified by the Program Properties Table in PARMLIB. You could then, possibly, 
invoke the non-APF code safely as long as you run it in key 8.

But the question then becomes what do you expect the non-APF code to do, and 
how do you expect to communicate with it.

It really would be better and safer, in my opinion, to find another solution. 
This might possibly involve using multiple address spaces (via UNIX fork()) as 
John McKown suggested. But we would really need to know a lot more information 
about your STC, and the non-APF code, to be able to provide the best advice.

(It is very unlikely, in my experience, that your current STC is designed to 
allow you to do this safely. A major redesign and reimplementation of the STC 
would probably be required if you haven't been thinking about this from the 
very beginning of its development.)

-- 
Walt

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

Re: ATTACH with RSAPF=YES

[Binyamin Dissen]

Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.

Of course, your authorized key8 storage will be subject to change by the
unauthorized task, thus your authorized code must not use Key8 storage.

(1) and (2) are not exclusive, as your authorized task would need to remain in
supervisor state after resetting APF (assuming you still need APF services).
If you no longer need APF services, simply reset APF do MODESET PROB and the
garden variety ATTACH(X)

Why do you want to run unauthorized code from this STC? What is the business
case?

On Mon, 15 May 2017 15:18:38 +0700 Robin Atwood  wrote:

:>We have a requirement to attach user modules from an unauthorised library
:>and execute them from an STC which
:>
:>runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
:>I want but every time I try it
:>
:>I get abend S306-0C, "authorised program attaching module from an
:>unauthorized library". The ATTACH macro
:>
:>description states:
:>
:> 
:>
:>RSAPF=YES when these conditions are met: 
:>
:>. The caller is running in supervisor state, system key (0-7),
:>or both
:>
:>. The caller is running non-APF authorized
:>
:>. The subtask is attached in the problem program state and with
:>a nonsystem key.
:>
:> 
:>
:>Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
:>and adding SM=PROB,KEY=PROP 
:>
:>to the ATTACH but it made no difference. I seem to be missing something
:>fairly massive here! Can anyone shed 
:>
:>some light on this?
:>
:> 
:>
:>Thanks
:>
:>Robin
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: TCPIP IP inbound/outbound connection filtering?

[Jousma, David]

Thanks Mike.  We do have z/OSMF active mostly for the use of the new 
configuration assistant.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Wawiorko
Sent: Monday, May 15, 2017 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCPIP IP inbound/outbound connection filtering?

Yes - you can do all that in z/OS with an IPSEC filter policy.

You need a way of automatically using the correct policy in PAGENT - DR Test or 
Live. One way is to use a system symbol ultimately picked up from the LOADPARM.

These days, realistically, you need zOSMF Communications Server Configuration 
Assistant. You can edit filter policy files manually if they are very simple. 
If they get complex you'll soon need Configuration Assistant.

Then configure PAGENT and the IP stack to use IPSECURITY.

Mike Wawiorko

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: 15 May 2017 14:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TCPIP IP inbound/outbound connection filtering?

All,

Sorry if this is an over-simplistic question, coming from a z/OS guy that 
doesn't have a lot of IP depth of knowledge.   We recently had our annual site 
Disaster test, which for us is done locally, at one of our own datacenters.   
Data is replicated, and we simply IPL one of our systems onto the PPRC'd data 
with some highlevel config changes to IP/VTAM so that the system can exist on 
our PROD network.   We do take some of what I consider rudimentary measures to 
avoid "data leakage" from the disaster environment to the prod environment in 
terms of TWS, FTP, MQ, etc.

At my prior employer, we had a similar process, but the DR system(s) were all 
placed onto their own D/R VLAN to with no access off of it.  I'd love to get to 
that point here, but at least for now that is not a possibility.

What I want to explore is whether or not, we can take steps at the IP stack 
level to maybe initially disallow ALL outbound connections, and then 
secondarily, even conditionally allow outbound connections to a known list of 
"disaster recovery" nodes elsewhere in the network?   Can this be done in Comm 
Mgr?   Our annual DR test encompasses many non-mainframe servers too.  I don't 
want to create an administrative nightmare either.   If I were to describe what 
I'd like in non-mainframe terms, it would like the firewall on my MAC, popping 
up a prompt for new outbound connections on the console, with the ability to 
respond yes/no to allow.   Like I said, sorry, if I am over-simplifying, just 
looking to add some safeguards to help avoid a problem that occurred.

Thanks, Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail and any 
attachments are confidential and intended solely for the addressee and may also 
be privileged or exempt from disclosure under applicable law. If you are not 
the addressee, or have received this e-mail in error, please notify the sender 
immediately, delete it from your system and do not copy, disclose or otherwise 
act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. 

Re: TCPIP IP inbound/outbound connection filtering?

[Mike Wawiorko]

Yes - you can do all that in z/OS with an IPSEC filter policy.

You need a way of automatically using the correct policy in PAGENT - DR Test or 
Live. One way is to use a system symbol ultimately picked up from the LOADPARM.

These days, realistically, you need zOSMF Communications Server Configuration 
Assistant. You can edit filter policy files manually if they are very simple. 
If they get complex you'll soon need Configuration Assistant.

Then configure PAGENT and the IP stack to use IPSECURITY.

Mike Wawiorko

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: 15 May 2017 14:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TCPIP IP inbound/outbound connection filtering?

All,

Sorry if this is an over-simplistic question, coming from a z/OS guy that 
doesn't have a lot of IP depth of knowledge.   We recently had our annual site 
Disaster test, which for us is done locally, at one of our own datacenters.   
Data is replicated, and we simply IPL one of our systems onto the PPRC'd data 
with some highlevel config changes to IP/VTAM so that the system can exist on 
our PROD network.   We do take some of what I consider rudimentary measures to 
avoid "data leakage" from the disaster environment to the prod environment in 
terms of TWS, FTP, MQ, etc.

At my prior employer, we had a similar process, but the DR system(s) were all 
placed onto their own D/R VLAN to with no access off of it.  I'd love to get to 
that point here, but at least for now that is not a possibility.

What I want to explore is whether or not, we can take steps at the IP stack 
level to maybe initially disallow ALL outbound connections, and then 
secondarily, even conditionally allow outbound connections to a known list of 
"disaster recovery" nodes elsewhere in the network?   Can this be done in Comm 
Mgr?   Our annual DR test encompasses many non-mainframe servers too.  I don't 
want to create an administrative nightmare either.   If I were to describe what 
I'd like in non-mainframe terms, it would like the firewall on my MAC, popping 
up a prompt for new outbound connections on the console, with the ability to 
respond yes/no to allow.   Like I said, sorry, if I am over-simplifying, just 
looking to add some safeguards to help avoid a problem that occurred.

Thanks, Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

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

TCPIP IP inbound/outbound connection filtering?

[Jousma, David]

All,

Sorry if this is an over-simplistic question, coming from a z/OS guy that 
doesn't have a lot of IP depth of knowledge.   We recently had our annual site 
Disaster test, which for us is done locally, at one of our own datacenters.   
Data is replicated, and we simply IPL one of our systems onto the PPRC'd data 
with some highlevel config changes to IP/VTAM so that the system can exist on 
our PROD network.   We do take some of what I consider rudimentary measures to 
avoid "data leakage" from the disaster environment to the prod environment in 
terms of TWS, FTP, MQ, etc.

At my prior employer, we had a similar process, but the DR system(s) were all 
placed onto their own D/R VLAN to with no access off of it.  I'd love to get to 
that point here, but at least for now that is not a possibility.

What I want to explore is whether or not, we can take steps at the IP stack 
level to maybe initially disallow ALL outbound connections, and then 
secondarily, even conditionally allow outbound connections to a known list of 
"disaster recovery" nodes elsewhere in the network?   Can this be done in Comm 
Mgr?   Our annual DR test encompasses many non-mainframe servers too.  I don't 
want to create an administrative nightmare either.   If I were to describe what 
I'd like in non-mainframe terms, it would like the firewall on my MAC, popping 
up a prompt for new outbound connections on the console, with the ability to 
respond yes/no to allow.   Like I said, sorry, if I am over-simplifying, just 
looking to add some safeguards to help avoid a problem that occurred.

Thanks, Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: ATTACH with RSAPF=YES

[John McKown]

On Mon, May 15, 2017 at 7:30 AM, Greg Dyck  wrote:

> Be aware that what you are attempting to do is dangerous and has the
> potential to create system integrity exposures that would allow a problem
> state program to cause a system failure.  I am not saying that it can not
> be done safely, because it can be.  But to do it safely without creating a
> system integrity exposure requires a lot more than just using RSAPF=YES on
> the ATTACH.
>
> On 5/15/2017 3:17 AM, Robin Atwood wrote:
>
>> Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET
>> MODE=SUP
>> and adding SM=PROB,KEY=PROP
>>
>> to the ATTACH but it made no difference. I seem to be missing something
>> fairly massive here! Can anyone shed some light on this?
>>
>
> ​
>
>
> Regards, Greg
>
>
​Just coming out of left field here. I don't know what the OP is trying to
accomplish (at a high level) by doing this. But in the context were I need
differing security attributes (such as APF), I would go with a UNIX fork().
Of course, if the ATTACH'd program needs to communicate with the parent
through shared memory, that complicates things a bit. But should be
possible using the z/OS shared memory API.​ Or my "marshalling" the data
and using some IPC such as pipe or, better, UNIX messages. The problem with
all this is the CPU overhead and complexity.



-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


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: ATTACH with RSAPF=YES

[Greg Dyck]

Be aware that what you are attempting to do is dangerous and has the 
potential to create system integrity exposures that would allow a 
problem state program to cause a system failure.  I am not saying that 
it can not be done safely, because it can be.  But to do it safely 
without creating a system integrity exposure requires a lot more than 
just using RSAPF=YES on the ATTACH.


On 5/15/2017 3:17 AM, Robin Atwood wrote:

Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
and adding SM=PROB,KEY=PROP

to the ATTACH but it made no difference. I seem to be missing something
fairly massive here! Can anyone shed some light on this?


You need to get into key 0 and reset JSCBAUTH prior to issuing the 
ATTACH in order to meet qualification #2 below for RSAPF=YES to be 
performed, and the ATTACH must then be issued in either a system key or 
supervisor state (or both)-


  RSAPF=YES when these conditions are met:
- The caller is running in supervisor state, system key (0-7), or
  both
- The caller is running non-APF authorized
- The subtask is attached in the problem program state and with a
  non-system key.

Regards, Greg

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

Re: NJE over TCPIP between z/OS running on RDT and z/OS running on Z hardware

[Alvaro Guirao Lopez]

NJE works fine.

I set up several RDTs connected between them and all with a Mainframe z890
5 years ago when I did a full migration from Mainframe to RDT for an ISV.

On Mon, May 15, 2017, 13:24 Jake Anderson  wrote:

> Hello,
>
> I have requirement to submit a from RDT and execute in z hardware to place
> some modules in z/OS running in z Hardware.
>
> Is it possible to create NJE over TCPIP definition between the two platform
> ? or else if there is a different way to approach ?
>
> Any suggestions or pointers would help me to research further and architect
> a solution.
>
> Note : Cross posted to IBM main and IBM tcpip
>
> Regards,
> Jake
>
> --
> 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

NJE over TCPIP between z/OS running on RDT and z/OS running on Z hardware

[Jake Anderson]

Hello,

I have requirement to submit a from RDT and execute in z hardware to place
some modules in z/OS running in z Hardware.

Is it possible to create NJE over TCPIP definition between the two platform
? or else if there is a different way to approach ?

Any suggestions or pointers would help me to research further and architect
a solution.

Note : Cross posted to IBM main and IBM tcpip

Regards,
Jake

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

Check out New Wave of Ransom Threats Seen in Unprecedented Attack - Bloomberg

[Edward Finnell]

_New  Wave of Ransom Threats Seen in Unprecedented Attack - Bloomberg_ 
(https://www.bloomberg.com/news/articles/2017-05-14/hospitals-gain-control-in-ran
som-hack-more-attacks-may-come)  

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

ATTACH with RSAPF=YES

[Robin Atwood]

We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which

runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
I want but every time I try it

I get abend S306-0C, "authorised program attaching module from an
unauthorized library". The ATTACH macro

description states:

 

RSAPF=YES when these conditions are met: 

. The caller is running in supervisor state, system key (0-7),
or both

. The caller is running non-APF authorized

. The subtask is attached in the problem program state and with
a nonsystem key.

 

Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
and adding SM=PROB,KEY=PROP 

to the ATTACH but it made no difference. I seem to be missing something
fairly massive here! Can anyone shed 

some light on this?

 

Thanks

Robin


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

Re: Ransomware on Mainframe application ?

[Edward Finnell]

The 'wannacry' exploits security holes in Windows that have been there  
forever. M$ released patches for Win7 and Win10(not sure about 8 and 9). These  
were exposed by wikileaks dump of some NSA tricks to backdoor PC's and  
networks.
 
I guess there is potential, but for right now I'd say the MF apps are OK,  
the end user just can't get to them with back level Windoze  software. 
 
 
In a message dated 5/15/2017 2:00:34 A.M. Central Daylight Time,  
justmainfra...@gmail.com writes:

Just  curious if recent ransomware attack has capability to infect  any
applications running on Mainframe  ?


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

Ransomware on Mainframe application ?

[Jake Anderson]

Hi

Just curious if recent ransomware attack has capability to infect any
applications running on Mainframe ?

Regards
Jake

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