date:20190528

I posted 3-4 links from varying sources all saying the same thing. Banks, 
insurance, big retail all use the mainframe for approximately 3 major reasons, 
one of which is security. Then Ray wants to show me some controlled experiment 
that is nothing but a lab event that he can’t show to have ever occurred in 
real life. No thanks.

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 6:22 PM, zMan  wrote:

So...you make statements and don't back them up, and when offered
coutner-examples, refuse to view them?

Plonk.

On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Demos remind me of this joke.
> http://www.jokes.net/heavenandhell.htm
> I’ve seen my share of demos that make claims or promises that simply never
> occur.
> Thanks Ray, I’ll pass.
>

--
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: Fwd: Just how secure are mainframes? | Trevor Eddolls

I backed them up weeks ago. Try to catch up.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 6:22 PM, zMan  wrote:

So...you make statements and don't back them up, and when offered
coutner-examples, refuse to view them?

Plonk.

On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Demos remind me of this joke.
> http://www.jokes.net/heavenandhell.htm
> I’ve seen my share of demos that make claims or promises that simply never
> occur.
> Thanks Ray, I’ll pass.
>

--
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: ISPF and newer COBOL keywords

2019-05-28 Thread Frank Swarbrick

Thanks Tim.  Just received a private email from Sri with this same information. 
 Will have to ask about getting it applied.

From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Tuesday, May 28, 2019 7:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF and newer COBOL keywords

A quick update: Mike Stayton alerted me that ISPF was updated about 12
months ago with HILITE-related support for Enterprise COBOL through and
including Enterprise COBOL 6.2. Please refer to the PTF(s) for APAR
OA55117.

It'd be great to read reports of experiences with this ISPF update.

Thanks, Mike.

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

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

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

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Thank you for the explanation.  I can see that proxy access to other userid's 
would need tight control, like a production job scheduler product has, but even 
so wouldn't the FTP server itself receive a failure if it tries to submit a job 
sent to it with invalid credentials?  Or does the job just disappear, as could 
happen (depending on various exit behaviors and your own ESM authority) if you 
TSO SUBMIT a job with a userid other than your own?

I can also see that there are lots of levels to actually effective security.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 5:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

FTP JES access relies on the credentials of the userid under which the FTP 
server is running. Under normal circumstances the user would need to provide a 
userid and password on his job card. If the FTP server has proxy access to 
other userids then it needs to be tightly controlled. 
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Shmuel,

Were you asking me or Ray?  For myself, I have no opinion to express about the 
security of web infrastructure.  ATM that is beyond my level of knowledge and 
expertise.

I was speaking only to the vulnerability (or not) of FTP JES access from an 
application programmer's perspective.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Peter - That is a good question. I think there may be several ways to explain 
this:

  * When I explain code vulnerabilities to z/OS assembler developers I
tell them: It is not good enough for the code to work as designed -
it must have no unintended consequences.If an installation
implements FTP JES support in such a way that it allows both
legitimate users (ex - IBM z/OS and CICS Explorer Eclipse base
products) and illegitimate users to use it then there may be a
vulnerability in the FTP JES implementation. For example, if an
external user could run a job submitted via FTP JES to list the
payroll file or the ESM database but that is not the installations
intended use of the FTP JES support then I would suggest that this
would be a vulnerability.
  * If an exploit was developed to exfiltrate the payroll file or the
ESM database and FTP JES was part of the path the exploit used then
one should review the FTP JES implementation to see how controls can
be tightened to eliminate or reduce the "unintended consequences".
You would of course also look at the other parts of the exploit and
do the same.

Which option you use is usually dictated by whether you are looking for 
problems that may not have occurred yet (1st option) or you are trying to 
figure out what happened (2nd option).

The use of FTP JES option is not by itself a vulnerability. But it can be if 
not properly configured (including the ESM controls). It is also somet

Re: CTC (FCTC) usage

2019-05-28 Thread Jesse 1 Robinson

I'm not sure what Tony T. means. We have only FICON CTC throughout the 
enterprise. All of our JES2 NJE connections use them. There was no 
configuration change when we moved from ESCON to FICON. 

Maybe BSC? We abandoned that protocol decades ago.  

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Thigpen
Sent: Tuesday, May 28, 2019 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CTC (FCTC) usage

FYI, JES2/NJE does not support FICON CTC connections. They only support 
ESCON/BASIC CTC connections, which you don't have on a z14.

Tony Thigpen

Munif Sadek wrote on 5/28/19 10:40 AM:
> we are getting new z14 and time to revisit our CTC configuration.
> 
> Is there a complete documentation on FICON CTC implementation and its 
> potential usage / configuration for various subsystems e.g. VTAM, TCP/IP, 
> GRS, NJE, XCF etc . we are single CPC SYSPLEX environment and just exploring 
> where all CTCs can be used.
> 
> Currently we us it only for VTAM (TRL) and IP.
> 
> regards
> Munif

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread zMan

So...you make statements and don't back them up, and when offered
coutner-examples, refuse to view them?

Plonk.

On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Demos remind me of this joke.
> http://www.jokes.net/heavenandhell.htm
> I’ve seen my share of demos that make claims or promises that simply never
> occur.
> Thanks Ray, I’ll pass.
>

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

Re: CTC (FCTC) usage

2019-05-28 Thread Tony Thigpen

FYI, JES2/NJE does not support FICON CTC connections. They only support 
ESCON/BASIC CTC connections, which you don't have on a z14.


Tony Thigpen

Munif Sadek wrote on 5/28/19 10:40 AM:

we are getting new z14 and time to revisit our CTC configuration.

Is there a complete documentation on FICON CTC implementation and its potential 
usage / configuration for various subsystems e.g. VTAM, TCP/IP, GRS, NJE, XCF 
etc . we are single CPC SYSPLEX environment and just exploring where all CTCs 
can be used.

Currently we us it only for VTAM (TRL) and IP.

regards
Munif

--
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: Fwd: Just how secure are mainframes? | Trevor Eddolls

FTP JES access relies on the credentials of the userid under which the FTP 
server is running. Under normal circumstances the user would need to provide a 
userid and password on his job card. If the FTP server has proxy access to 
other userids then it needs to be tightly controlled. 

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

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Shmuel,

Were you asking me or Ray?  For myself, I have no opinion to express about the 
security of web infrastructure.  ATM that is beyond my level of knowledge and 
expertise.

I was speaking only to the vulnerability (or not) of FTP JES access from an 
application programmer's perspective.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Peter - That is a good question. I think there may be several ways to explain 
this:

  * When I explain code vulnerabilities to z/OS assembler developers I
tell them: It is not good enough for the code to work as designed -
it must have no unintended consequences.If an installation
implements FTP JES support in such a way that it allows both
legitimate users (ex - IBM z/OS and CICS Explorer Eclipse base
products) and illegitimate users to use it then there may be a
vulnerability in the FTP JES implementation. For example, if an
external user could run a job submitted via FTP JES to list the
payroll file or the ESM database but that is not the installations
intended use of the FTP JES support then I would suggest that this
would be a vulnerability.
  * If an exploit was developed to exfiltrate the payroll file or the
ESM database and FTP JES was part of the path the exploit used then
one should review the FTP JES implementation to see how controls can
be tightened to eliminate or reduce the "unintended consequences".
You would of course also look at the other parts of the exploit and
do the same.

Which option you use is usually dictated by whether you are looking for 
problems that may not have occurred yet (1st option) or you are trying to 
figure out what happened (2nd option).

The use of FTP JES option is not by itself a vulnerability. But it can be if 
not properly configured (including the ESM controls). It is also something the 
other platforms understand and will take advantage of if not properly 
controlled for unintended consequences.

/IOW, how is FTP JES submission any different from TSO SUBMIT? /Functionally, 
they both do the same thing. What I think is different is that FTP JES may be 
done from environments outside the scope and control of a z/OS system. Those 
environments may not be as secure as z/OS.
//

On 5/28/2019 12:46 PM, Farley, Peter x23353 wrote:
> Ray,
>
> PMFJI here, but as a regular application programmer (not a sysprog) I do not 
> understand how the FTP JES option allowed is a configuration vulnerability.
>
> Isn't the FTP JES option one of the ways that the IBM z/OS and CICS Explorer 
> Eclipse-based products (and maybe other ISV Eclipse GUI's) provide to let you 
> submit

Re: Just how secure are mainframes? | Trevor Eddolls

> There are tools to enforce user authentication.

How is that  relevant to making selected files available to the general public? 
You can't authenticate someone you've never heard of.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 28, 2019 5:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Just how secure are mainframes? | Trevor Eddolls

On Tue, 28 May 2019 20:41:50 +, Seymour J Metz wrote:

>What if you have a business need to make files available to the general 
>public? Do you really believe that the web infrastructure is any more secure 
>than FTP, or even as secure?
>
There are tools to enforce user authentication.  E-Commerce relies on
these.  Of course, they are only secure as the care taken in deployment.

RACF profiles can help enormously (UACC=READ for HTTPD/FTPD).

Does CGIWrap help?

http://secure-web.cisco.com/1_X3m_rKmNkg9Z_swcraQ6GVLfsGW2xWgDRf2MYlBQZpEUAWG1qOZLDLzI2dI7swz32GFDWl7BOgRcb3Qwc3_7cvPV2b3Bf833bujON9NDtdOXr8FWdLBvn3ubxNl8u8fF7UOGjuGMLyZ5_wDrt_Uep2wnYTZi2YO8LzTc_S8up228Dr7htVDKwQWPKyEMRKQeE8JINJoPCMh5G6w_YP2MnMlZ1MkbzOC9eKah9gm19cxWZOV4O6Is-YvDfubffvEibizdJM_KuyOzZWcASigYhHOtQKUeBgF_fqT9xyRtM-Ly51WV9U1sC7u3akrRB9_hDtXugxWYe4k6ZVwlNvxNfGAlH_g0yvDUj8oDjWbV3u2Rxn14yxzZbU2rNQfaOA3ZLkIjNSS6RglRv0gBqXdWpMdnxPY3ZAxBp7rA5ybrzbamWMW9Idfsfcn3QFreyV4/http%3A%2F%2Fcgiwrap.sourceforge.net%2Fintro.html

-- gil

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

2019-05-28 Thread Kurt Quackenbush


On 5/28/2019 12:04 PM, Styles, Andy , ITS zPlatform Services wrote:


I've snipped a fair bit of this, but (and I've manually added quoting, so 
apologies if it breaks):


Were any of these PTFs also received in the prior RECEIVE ORDER?  And Were they 
applied and
accepted, perhaps purging them from the global zone prior to the latest RECEIVE 
ORDER?  Were
they assigned the RSU1903 sourceid in the first, second, or both RECEIVEs?


We definitely did not have the second set of fixes in the global zone prior to 
the second RECEIVE; given I specified RECOMMENDED both times, I (naïvely 
perhaps) assumed I'd get the latest RSU. This is where this question has arisen 
from - how did I get more fixes tagged with RSU1903 with a second RECEIVE 
RECOMMENDED, after the RSU publish date?



Did you really get more PTFs assigned RSU1903 the second time?  Or did 
you simply get more PTFs?  Let me explain:


For the IBM server, when you run RECEIVE ORDER with 
CONTENT(RECOMMENDED), you get back PTFs identified with a Recommended 
Service Update SOURCEID (RSUyymm) *AND* PTFs that resolve critical 
problems (HIPER or PE).  PTFs get assigned RSUyynn only once a month, 
but HIPER and PE fixing PTFs can get assigned every day.


Therefore, I fully expect your second RECEIVE ORDER would obtain HIPER 
or PE fixing PTFs that were not yet available, or not yet assigned HIPER 
or PE, during your first RECEIVE ORDER.


If only HIPER or PRP sourceids were assigned during the second RECEIVE 
ORDER, and you saw no new RSU1903 sourceids being assigned, then I 
suggest the server is processing correctly.


However, if you saw any RSU1903 sourceids being assigned during the 
second RECEIVE ORDER, then perhaps the server's behavior requires 
further analysis.  If this is the case, a PMR may be warranted, but 
you're going to have to provide proof, as in the SMP/E output for both jobs.



This last question about when/if RSU1903 was assigned is the important one, but 
I fear you
may not know the answer without the SMPRPT output for the RECEIVEs.


I have some stored job output, but I can't guarantee that I have ALL output, so 
I don't know if it'll be enough, or whether it contains what we're looking for. 
Fantastic as it is to get support this way, are we moving into PMR territory?

Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

Re: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread Paul Gilmartin

On Tue, 28 May 2019 20:41:50 +, Seymour J Metz wrote:

>What if you have a business need to make files available to the general 
>public? Do you really believe that the web infrastructure is any more secure 
>than FTP, or even as secure?
> 
There are tools to enforce user authentication.  E-Commerce relies on
these.  Of course, they are only secure as the care taken in deployment.

RACF profiles can help enormously (UACC=READ for HTTPD/FTPD).

Does CGIWrap help?
http://cgiwrap.sourceforge.net/intro.html

-- gil

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Shmuel,

Were you asking me or Ray?  For myself, I have no opinion to express about the 
security of web infrastructure.  ATM that is beyond my level of knowledge and 
expertise.

I was speaking only to the vulnerability (or not) of FTP JES access from an 
application programmer's perspective.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Peter - That is a good question. I think there may be several ways to explain 
this:

  * When I explain code vulnerabilities to z/OS assembler developers I
tell them: It is not good enough for the code to work as designed -
it must have no unintended consequences.If an installation
implements FTP JES support in such a way that it allows both
legitimate users (ex - IBM z/OS and CICS Explorer Eclipse base
products) and illegitimate users to use it then there may be a
vulnerability in the FTP JES implementation. For example, if an
external user could run a job submitted via FTP JES to list the
payroll file or the ESM database but that is not the installations
intended use of the FTP JES support then I would suggest that this
would be a vulnerability.
  * If an exploit was developed to exfiltrate the payroll file or the
ESM database and FTP JES was part of the path the exploit used then
one should review the FTP JES implementation to see how controls can
be tightened to eliminate or reduce the "unintended consequences".
You would of course also look at the other parts of the exploit and
do the same.

Which option you use is usually dictated by whether you are looking for 
problems that may not have occurred yet (1st option) or you are trying to 
figure out what happened (2nd option).

The use of FTP JES option is not by itself a vulnerability. But it can be if 
not properly configured (including the ESM controls). It is also something the 
other platforms understand and will take advantage of if not properly 
controlled for unintended consequences.

/IOW, how is FTP JES submission any different from TSO SUBMIT? /Functionally, 
they both do the same thing. What I think is different is that FTP JES may be 
done from environments outside the scope and control of a z/OS system. Those 
environments may not be as secure as z/OS.
//

On 5/28/2019 12:46 PM, Farley, Peter x23353 wrote:
> Ray,
>
> PMFJI here, but as a regular application programmer (not a sysprog) I do not 
> understand how the FTP JES option allowed is a configuration vulnerability.
>
> Isn't the FTP JES option one of the ways that the IBM z/OS and CICS Explorer 
> Eclipse-based products (and maybe other ISV Eclipse GUI's) provide to let you 
> submit and review the results of compile and program test and bundle 
> transmission jobs?   If my FTP submitted jobs must have my userid+1 as the 
> job name and my userid access is properly controlled by the ESM, how is that 
> vulnerable?
>
> IOW, how is FTP JES submission any different from TSO SUBMIT?
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ray Overby
> Sent: Tuesday, May 28, 2019 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> This discu

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?

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

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Peter - That is a good question. I think there may be several ways to
explain this:

  * When I explain code vulnerabilities to z/OS assembler developers I
tell them: It is not good enough for the code to work as designed -
it must have no unintended consequences.If an installation
implements FTP JES support in such a way that it allows both
legitimate users (ex - IBM z/OS and CICS Explorer Eclipse base
products) and illegitimate users to use it then there may be a
vulnerability in the FTP JES implementation. For example, if an
external user could run a job submitted via FTP JES to list the
payroll file or the ESM database but that is not the installations
intended use of the FTP JES support then I would suggest that this
would be a vulnerability.
  * If an exploit was developed to exfiltrate the payroll file or the
ESM database and FTP JES was part of the path the exploit used then
one should review the FTP JES implementation to see how controls can
be tightened to eliminate or reduce the "unintended consequences".
You would of course also look at the other parts of the exploit and
do the same.

Which option you use is usually dictated by whether you are looking for
problems that may not have occurred yet (1st option) or you are trying
to figure out what happened (2nd option).

The use of FTP JES option is not by itself a vulnerability. But it can
be if not properly configured (including the ESM controls). It is also
something the other platforms understand and will take advantage of if
not properly controlled for unintended consequences.

/IOW, how is FTP JES submission any different from TSO SUBMIT? /Functionally, 
they both do the same thing. What I think is different is that FTP JES may be 
done from environments outside the scope and control of a z/OS system. Those 
environments may not be as secure as z/OS.
//

On 5/28/2019 12:46 PM, Farley, Peter x23353 wrote:
> Ray,
>
> PMFJI here, but as a regular application programmer (not a sysprog) I do not 
> understand how the FTP JES option allowed is a configuration vulnerability.
>
> Isn't the FTP JES option one of the ways that the IBM z/OS and CICS Explorer 
> Eclipse-based products (and maybe other ISV Eclipse GUI's) provide to let you 
> submit and review the results of compile and program test and bundle 
> transmission jobs?   If my FTP submitted jobs must have my userid+1 as the 
> job name and my userid access is properly controlled by the ESM, how is that 
> vulnerable?
>
> IOW, how is FTP JES submission any different from TSO SUBMIT?
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Ray Overby
> Sent: Tuesday, May 28, 2019 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> This discussion on mainframe vulnerabilities has unfortunately broken down. I 
> have been talking to mainframe people about vulnerabilities for the last 12 
> years. I have talked with people just like Bill Johnson. My discussions went 
> just like this discussion did. The problem (as I saw
> it) was that discussing a “mainframe vulnerability” is too ambiguous.
> The discussion needs to be more specific. This led to categorizing 
> vulnerabilities. When the vulnerabilities were categorized (which also 
> defined their capabilities BUT does not allow the hacker to gener

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Why do you think that FTP is any more of a security issue than a web server 
that allows downloading the same files? In either case you need appropriate 
security controls.

Actually, there are far more security issues with the WWW infrastructure than 
there ever were with FTP.


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


From: IBM Mainframe Discussion List  on behalf of 
ITschak Mugzach 
Sent: Tuesday, May 28, 2019 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Ftp in general is a bad idea. Data should have a single, well protected
copy.  ibm moves to REST APIs (zosmf, but can be used natively). Again,
they need to be protected.

ITschak

בתאריך יום ג׳, 28 במאי 2019, 21:51, מאת John McKown ‏<
john.archie.mck...@gmail.com>:

> On Tue, May 28, 2019 at 12:46 PM Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote:
>
> > Ray,
> >
> > PMFJI here, but as a regular application programmer (not a sysprog) I do
> > not understand how the FTP JES option allowed is a configuration
> > vulnerability.
> >
> > Isn't the FTP JES option one of the ways that the IBM z/OS and CICS
> > Explorer Eclipse-based products (and maybe other ISV Eclipse GUI's)
> provide
> > to let you submit and review the results of compile and program test and
> > bundle transmission jobs?   If my FTP submitted jobs must have my
> userid+1
> > as the job name and my userid access is properly controlled by the ESM,
> how
> > is that vulnerable?
> >
> > IOW, how is FTP JES submission any different from TSO SUBMIT?
> >
> > Peter
> >
>
>
> I was wondering the same thing. The only thing that comes to mind is that
> more non-z/OS people know how to use ftp than tn3270. And using tn3270 to
> get to TSO to use SUBMIT requires the RACF ID to have a TSO segment. So, in
> effect, you can stop non-TSO people, who need to upload or download data,
> from submitting jobs. Assuming that such people know how to code JCL and
> issue the correct SITE command to submit to JES rather than upload into a
> data set / UNIX file.
>
> --
> This is clearly another case of too many mad scientists, and not enough
> hunchbacks.
>
>
> Maranatha! <><
> John McKown
>
> --
> 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

A real stumper of a problem

2019-05-28 Thread Mike Schwab

https://steeleweed.com/2018/08/19/interview-test/
A real stumper of a problem.

-- 
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: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Peter - That is a good question. I think there may be several ways to 
explain this:

  * When I explain code vulnerabilities to z/OS assembler developers I
tell them: It is not good enough for the code to work as designed -
it must have no unintended consequences.If an installation
implements FTP JES support in such a way that it allows both
legitimate users (ex - IBM z/OS and CICS Explorer Eclipse base
products) and illegitimate users to use it then there may be a
vulnerability in the FTP JES implementation. For example, if an
external user could run a job submitted via FTP JES to list the
payroll file or the ESM database but that is not the installations
intended use of the FTP JES support then I would suggest that this
would be a vulnerability.
  * If an exploit was developed to exfiltrate the payroll file or the
ESM database and FTP JES was part of the path the exploit used then
one should review the FTP JES implementation to see how controls can
be tightened to eliminate or reduce the "unintended consequences".
You would of course also look at the other parts of the exploit and
do the same.

Which option you use is usually dictated by whether you are looking for 
problems that may not have occurred yet (1st option) or you are trying 
to figure out what happened (2nd option).

The use of FTP JES option is not by itself a vulnerability. But it can 
be if not properly configured (including the ESM controls). It is also 
something the other platforms understand and will take advantage of if 
not properly controlled for unintended consequences.

/IOW, how is FTP JES submission any different from TSO SUBMIT? /Functionally, 
they both do the same thing. What I think is different is that FTP JES may be 
done from environments outside the scope and control of a z/OS system. Those 
environments may not be as secure as z/OS.
//

On 5/28/2019 12:46 PM, Farley, Peter x23353 wrote:
> Ray,
>
> PMFJI here, but as a regular application programmer (not a sysprog) I do not 
> understand how the FTP JES option allowed is a configuration vulnerability.
>
> Isn't the FTP JES option one of the ways that the IBM z/OS and CICS Explorer 
> Eclipse-based products (and maybe other ISV Eclipse GUI's) provide to let you 
> submit and review the results of compile and program test and bundle 
> transmission jobs?   If my FTP submitted jobs must have my userid+1 as the 
> job name and my userid access is properly controlled by the ESM, how is that 
> vulnerable?
>
> IOW, how is FTP JES submission any different from TSO SUBMIT?
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Ray Overby
> Sent: Tuesday, May 28, 2019 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> This discussion on mainframe vulnerabilities has unfortunately broken down. I 
> have been talking to mainframe people about vulnerabilities for the last 12 
> years. I have talked with people just like Bill Johnson. My discussions went 
> just like this discussion did. The problem (as I saw
> it) was that discussing a “mainframe vulnerability” is too ambiguous.
> The discussion needs to be more specific. This led to categorizing 
> vulnerabilities. When the vulnerabilities were categorized (which also 
> defined their capabilities BUT does not allow the hacker to generate an
> exploit) the discussions evolved to the point that not only did the mainframe 
> people better understand the vulnerabilities and their associated risk but 
> also allowed C level, managers, Auditors, Security, Pen testers, and Risk 
> people to understand and participate in the vulnerability discussions.
>
> For example, you can classify mainframe vulnerabilities based upon their 
> source – configuration or code based. Classifying the vulnerability 
> eliminates amb

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Ftp in general is a bad idea. Data should have a single, well protected
copy.  ibm moves to REST APIs (zosmf, but can be used natively). Again,
they need to be protected.

ITschak

בתאריך יום ג׳, 28 במאי 2019, 21:51, מאת John McKown ‏<
john.archie.mck...@gmail.com>:

> On Tue, May 28, 2019 at 12:46 PM Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote:
>
> > Ray,
> >
> > PMFJI here, but as a regular application programmer (not a sysprog) I do
> > not understand how the FTP JES option allowed is a configuration
> > vulnerability.
> >
> > Isn't the FTP JES option one of the ways that the IBM z/OS and CICS
> > Explorer Eclipse-based products (and maybe other ISV Eclipse GUI's)
> provide
> > to let you submit and review the results of compile and program test and
> > bundle transmission jobs?   If my FTP submitted jobs must have my
> userid+1
> > as the job name and my userid access is properly controlled by the ESM,
> how
> > is that vulnerable?
> >
> > IOW, how is FTP JES submission any different from TSO SUBMIT?
> >
> > Peter
> >
>
>
> I was wondering the same thing. The only thing that comes to mind is that
> more non-z/OS people know how to use ftp than tn3270. And using tn3270 to
> get to TSO to use SUBMIT requires the RACF ID to have a TSO segment. So, in
> effect, you can stop non-TSO people, who need to upload or download data,
> from submitting jobs. Assuming that such people know how to code JCL and
> issue the correct SITE command to submit to JES rather than upload into a
> data set / UNIX file.
>
> --
> This is clearly another case of too many mad scientists, and not enough
> hunchbacks.
>
>
> Maranatha! <><
> John McKown
>
> --
> 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: How to delete and allocate files in bpxbatch

I am getting most of this information here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa500/tso.htm

On Tue, May 28, 2019 at 1:55 PM Billy Ashton  wrote:

> Hi John, yes (sorry), I should have mentioned this is in a shell script. A
> couple more questions, if you don't mind:
> 1. Can I force the RC to become zero if the delete fails (there is an
> occasion where the process runs to create the file new the first time in
> the month)?
> 2. Can I specify SMS parameters  (data class, storage class) on that
> allocate when I run in batch JCL mode?
>
> Thanks!
> B
>
> On Tue, May 28, 2019 at 2:46 PM John McKown 
> wrote:
>
> > On Tue, May 28, 2019 at 12:44 PM Billy Ashton 
> > wrote:
> >
> > > Does anyone have a sample of Bpxbatch commands to delete a z/OS flat
> > file,
> > > and then to allocate it anew? I am trying to work out some processing,
> > and
> > > this would be in the middle of a set of commands. I would hate to break
> > > this up into three job steps, just to insert the delete/allocate in the
> > > middle (I am using the file earlier in the script).
> > >
> >
> > If I am understanding you, you basically want a way to delete & allocate
> a
> > z/OS "flat file" (physical sequential) in a /bin/sh shell script. I am
> > assuming you want a "regular" script, and not a REXX script. I did this
> on
> > a UNIX shell prompt, via ssh.
> >
> > $ file /bin/tso
> > /bin/tso:   z/OS Unix executable (amode=31)
> > $ tso "del 'junk'"
> > del 'junk'
> > IDC3012I ENTRY JUNK NOT FOUND+
> > IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42
> > IDC0551I ** ENTRY JUNK NOT DELETED
> > IDC0014I LASTCC=8
> > RC(8)
> > $ tso 'alloc ddn(x) dsn(junk.junk) lrecl(80) blksize(0) space(10,2) cyl
> >  recfm(f b) new catalog'
> > alloc ddn(x) dsn(junk.junk) lrecl(80) blksize(0) space(10,2) cyl  recfm(f
> > b) new catalog
> > $ tso 'del junk.junk'
> > del junk.junk
> > IDC0550I ENTRY (A) TSH009.JUNK.JUNK DELETED
> >
> >
> > >
> > > Thank you all!
> > > Billy
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> >
> > --
> > This is clearly another case of too many mad scientists, and not enough
> > hunchbacks.
> >
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > 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
>


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


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: How to delete and allocate files in bpxbatch

On Tue, May 28, 2019 at 1:55 PM Billy Ashton  wrote:

> Hi John, yes (sorry), I should have mentioned this is in a shell script. A
> couple more questions, if you don't mind:
> 1. Can I force the RC to become zero if the delete fails (there is an
> occasion where the process runs to create the file new the first time in
> the month)?
>

Why care about the RC from the "tso" command? It only sets the $? shell
variable temporarily. Unless you are using "set -e" to abort the script on
an error. In that case, do something like:

set +e # turn off abort on error
tso "del 'some.dsn'" #might set $? to 8 if it doesn't exist
: # The colon command does nothing (IEFBR14) but sets $? to 0
set -e # turn on abort on error

> 2. Can I specify SMS parameters  (data class, storage class) on that
> allocate when I run in batch JCL mode?
>

I don't think that there is any difference in what you can do via BPXBATCH
versus an interactive UNIX shell, other than interacting with the user of
course {grin}.

You can include anything on the ALLOCATE that you can in TSO. Oh, the "tso"
command is like any other UNIX command. It usually runs in a separate
address space. So there is no need to do a TSO FREE command after the
ALLOCATE because that address space terminate and the DSN is automatically
freed. (OK, the BPXAS address space doesn't really terminate, but it goes
through the equivalent of JOB termination in an initiator because BPXAS is
an initiator (IEFIIC) with a special PARM=.

>
> Thanks!
> B
>

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

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: How to delete and allocate files in bpxbatch

2019-05-28 Thread Billy Ashton

Hi John, yes (sorry), I should have mentioned this is in a shell script. A
couple more questions, if you don't mind:
1. Can I force the RC to become zero if the delete fails (there is an
occasion where the process runs to create the file new the first time in
the month)?
2. Can I specify SMS parameters  (data class, storage class) on that
allocate when I run in batch JCL mode?

Thanks!
B

On Tue, May 28, 2019 at 2:46 PM John McKown 
wrote:

> On Tue, May 28, 2019 at 12:44 PM Billy Ashton 
> wrote:
>
> > Does anyone have a sample of Bpxbatch commands to delete a z/OS flat
> file,
> > and then to allocate it anew? I am trying to work out some processing,
> and
> > this would be in the middle of a set of commands. I would hate to break
> > this up into three job steps, just to insert the delete/allocate in the
> > middle (I am using the file earlier in the script).
> >
>
> If I am understanding you, you basically want a way to delete & allocate a
> z/OS "flat file" (physical sequential) in a /bin/sh shell script. I am
> assuming you want a "regular" script, and not a REXX script. I did this on
> a UNIX shell prompt, via ssh.
>
> $ file /bin/tso
> /bin/tso:   z/OS Unix executable (amode=31)
> $ tso "del 'junk'"
> del 'junk'
> IDC3012I ENTRY JUNK NOT FOUND+
> IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42
> IDC0551I ** ENTRY JUNK NOT DELETED
> IDC0014I LASTCC=8
> RC(8)
> $ tso 'alloc ddn(x) dsn(junk.junk) lrecl(80) blksize(0) space(10,2) cyl
>  recfm(f b) new catalog'
> alloc ddn(x) dsn(junk.junk) lrecl(80) blksize(0) space(10,2) cyl  recfm(f
> b) new catalog
> $ tso 'del junk.junk'
> del junk.junk
> IDC0550I ENTRY (A) TSH009.JUNK.JUNK DELETED
>
>
> >
> > Thank you all!
> > Billy
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> This is clearly another case of too many mad scientists, and not enough
> hunchbacks.
>
>
> Maranatha! <><
> John McKown
>
> --
> 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: Fwd: Just how secure are mainframes? | Trevor Eddolls

On Tue, May 28, 2019 at 12:46 PM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Ray,
>
> PMFJI here, but as a regular application programmer (not a sysprog) I do
> not understand how the FTP JES option allowed is a configuration
> vulnerability.
>
> Isn't the FTP JES option one of the ways that the IBM z/OS and CICS
> Explorer Eclipse-based products (and maybe other ISV Eclipse GUI's) provide
> to let you submit and review the results of compile and program test and
> bundle transmission jobs?   If my FTP submitted jobs must have my userid+1
> as the job name and my userid access is properly controlled by the ESM, how
> is that vulnerable?
>
> IOW, how is FTP JES submission any different from TSO SUBMIT?
>
> Peter
>

I was wondering the same thing. The only thing that comes to mind is that
more non-z/OS people know how to use ftp than tn3270. And using tn3270 to
get to TSO to use SUBMIT requires the RACF ID to have a TSO segment. So, in
effect, you can stop non-TSO people, who need to upload or download data,
from submitting jobs. Assuming that such people know how to code JCL and
issue the correct SITE command to submit to JES rather than upload into a
data set / UNIX file.

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

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: How to delete and allocate files in bpxbatch

On Tue, May 28, 2019 at 12:44 PM Billy Ashton 
wrote:

> Does anyone have a sample of Bpxbatch commands to delete a z/OS flat file,
> and then to allocate it anew? I am trying to work out some processing, and
> this would be in the middle of a set of commands. I would hate to break
> this up into three job steps, just to insert the delete/allocate in the
> middle (I am using the file earlier in the script).
>

If I am understanding you, you basically want a way to delete & allocate a
z/OS "flat file" (physical sequential) in a /bin/sh shell script. I am
assuming you want a "regular" script, and not a REXX script. I did this on
a UNIX shell prompt, via ssh.

$ file /bin/tso
/bin/tso:   z/OS Unix executable (amode=31)
$ tso "del 'junk'"
del 'junk'
IDC3012I ENTRY JUNK NOT FOUND+
IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42
IDC0551I ** ENTRY JUNK NOT DELETED
IDC0014I LASTCC=8
RC(8)
$ tso 'alloc ddn(x) dsn(junk.junk) lrecl(80) blksize(0) space(10,2) cyl
 recfm(f b) new catalog'
alloc ddn(x) dsn(junk.junk) lrecl(80) blksize(0) space(10,2) cyl  recfm(f
b) new catalog
$ tso 'del junk.junk'
del junk.junk
IDC0550I ENTRY (A) TSH009.JUNK.JUNK DELETED


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


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


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: Fwd: Just how secure are mainframes? | Trevor Eddolls

Peter - That is a good question. I think there may be several ways to 
explain this:


 * When I explain code vulnerabilities to z/OS assembler developers I
   tell them: It is not good enough for the code to work as designed -
   it must have no unintended consequences.If an installation
   implements FTP JES support in such a way that it allows both
   legitimate users (ex - IBM z/OS and CICS Explorer Eclipse base
   products) and illegitimate users to use it then there may be a
   vulnerability in the FTP JES implementation. For example, if an
   external user could run a job submitted via FTP JES to list the
   payroll file or the ESM database but that is not the installations
   intended use of the FTP JES support then I would suggest that this
   would be a vulnerability.
 * If an exploit was developed to exfiltrate the payroll file or the
   ESM database and FTP JES was part of the path the exploit used then
   one should review the FTP JES implementation to see how controls can
   be tightened to eliminate or reduce the "unintended consequences".
   You would of course also look at the other parts of the exploit and
   do the same.

Which option you use is usually dictated by whether you are looking for 
problems that may not have occurred yet (1st option) or you are trying 
to figure out what happened (2nd option).


The use of FTP JES option is not by itself a vulnerability. But it can 
be if not properly configured (including the ESM controls). It is also 
something the other platforms understand and will take advantage of if 
not properly controlled for unintended consequences.


/IOW, how is FTP JES submission any different from TSO SUBMIT? /Functionally, 
they both do the same thing. What I think is different is that FTP JES may be 
done from environments outside the scope and control of a z/OS system. Those 
environments may not be as secure as z/OS.
//


On 5/28/2019 12:46 PM, Farley, Peter x23353 wrote:

Ray,

PMFJI here, but as a regular application programmer (not a sysprog) I do not 
understand how the FTP JES option allowed is a configuration vulnerability.

Isn't the FTP JES option one of the ways that the IBM z/OS and CICS Explorer 
Eclipse-based products (and maybe other ISV Eclipse GUI's) provide to let you 
submit and review the results of compile and program test and bundle 
transmission jobs?   If my FTP submitted jobs must have my userid+1 as the job 
name and my userid access is properly controlled by the ESM, how is that 
vulnerable?

IOW, how is FTP JES submission any different from TSO SUBMIT?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken down. I 
have been talking to mainframe people about vulnerabilities for the last 12 
years. I have talked with people just like Bill Johnson. My discussions went 
just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing 
vulnerabilities. When the vulnerabilities were categorized (which also defined 
their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the mainframe 
people better understand the vulnerabilities and their associated risk but also 
allowed C level, managers, Auditors, Security, Pen testers, and Risk people to 
understand and participate in the vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their source 
– configuration or code based. Classifying the vulnerability eliminates 
ambiguities that are inherent when you don’t classify. It is these ambiguities 
that can cause the discussion to break down.  For example, how would the 
discussion have changed if the vulnerabilities under discussion were classified 
as follows:

-Configuration based vulnerabilities

   * APF authorized data sets not adequately protected
   * SMP/E data sets not adequately protected
   * FTP anonymous allowed
   * FTP JES option allowed
   * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

   * Storage alteration
   * Trap door
   * System Instability


--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


-

Re: RSUs

2019-05-28 Thread Gibney, Dave

My experience is that the RSU doesn't et to RECEIVEORDER until one day after I 
get the email that the new service level is available

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Styles, Andy (ITS zPlatform Services)
> Sent: Tuesday, May 28, 2019 9:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSUs
> 
> Classification: Public
> Hi Kurt,
> 
> I've snipped a fair bit of this, but (and I've manually added quoting, so
> apologies if it breaks):
> 
> > Were any of these PTFs also received in the prior RECEIVE ORDER?  And
> > Were they applied and accepted, perhaps purging them from the global
> > zone prior to the latest RECEIVE ORDER?  Were they assigned the RSU1903
> sourceid in the first, second, or both RECEIVEs?
> 
> We definitely did not have the second set of fixes in the global zone prior to
> the second RECEIVE; given I specified RECOMMENDED both times, I (naïvely
> perhaps) assumed I'd get the latest RSU. This is where this question has
> arisen from - how did I get more fixes tagged with RSU1903 with a second
> RECEIVE RECOMMENDED, after the RSU publish date?
> 
> > This last question about when/if RSU1903 was assigned is the important
> > one, but I fear you may not know the answer without the SMPRPT output
> for the RECEIVEs.
> 
> I have some stored job output, but I can't guarantee that I have ALL output,
> so I don't know if it'll be enough, or whether it contains what we're looking
> for. Fantastic as it is to get support this way, are we moving into PMR
> territory?
> 
> --
> Andy Styles
> z/Series System Programmer
> 
> 
> Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ.
> Registered in Scotland no. SC95000. Telephone: 0131 225 4555.
> 
> 
> 
> Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN.
> Registered in England and Wales no. 2065. Telephone 0207626 1500.
> 
> 
> 
> Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ.
> Registered in Scotland no. SC327000. Telephone: 03457 801 801.
> 
> 
> 
> Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street,
> London EC2V 7HN. Registered in England and Wales no. 10399850.
> 
> 
> 
> Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc
> are authorised by the Prudential Regulation Authority and regulated by the
> Financial Conduct Authority and Prudential Regulation Authority.
> 
> 
> 
> Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-
> owned subsidiary of Lloyds Bank Corporate Markets plc.  Lloyds Bank
> Corporate Markets Wertpapierhandelsbank GmbH has its registered office at
> Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is
> registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank
> Corporate Markets Wertpapierhandelsbank GmbH is supervised by the
> Bundesanstalt für Finanzdienstleistungsaufsicht.
> 
> 
> 
> Halifax is a division of Bank of Scotland plc.
> 
> 
> 
> HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in
> Scotland no. SC218813.
> 
> 
> 
> This e-mail (including any attachments) is private and confidential and may
> contain privileged material. If you have received this e-mail in error, please
> notify the sender and delete it (including any attachments) immediately. You
> must not copy, distribute, disclose or use any of the information in it or any
> attachments. Telephone calls may be monitored or recorded.
> 
> 
> --
> 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: Fwd: Just how secure are mainframes? | Trevor Eddolls

Ray,

PMFJI here, but as a regular application programmer (not a sysprog) I do not 
understand how the FTP JES option allowed is a configuration vulnerability.

Isn't the FTP JES option one of the ways that the IBM z/OS and CICS Explorer 
Eclipse-based products (and maybe other ISV Eclipse GUI's) provide to let you 
submit and review the results of compile and program test and bundle 
transmission jobs?   If my FTP submitted jobs must have my userid+1 as the job 
name and my userid access is properly controlled by the ESM, how is that 
vulnerable?

IOW, how is FTP JES submission any different from TSO SUBMIT?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken down. I 
have been talking to mainframe people about vulnerabilities for the last 12 
years. I have talked with people just like Bill Johnson. My discussions went 
just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous. 
The discussion needs to be more specific. This led to categorizing 
vulnerabilities. When the vulnerabilities were categorized (which also defined 
their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the mainframe 
people better understand the vulnerabilities and their associated risk but also 
allowed C level, managers, Auditors, Security, Pen testers, and Risk people to 
understand and participate in the vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their source 
– configuration or code based. Classifying the vulnerability eliminates 
ambiguities that are inherent when you don’t classify. It is these ambiguities 
that can cause the discussion to break down.  For example, how would the 
discussion have changed if the vulnerabilities under discussion were classified 
as follows:

-Configuration based vulnerabilities

  * APF authorized data sets not adequately protected
  * SMP/E data sets not adequately protected
  * FTP anonymous allowed
  * FTP JES option allowed
  * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

  * Storage alteration
  * Trap door
  * System Instability


--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

How to delete and allocate files in bpxbatch

2019-05-28 Thread Billy Ashton

Does anyone have a sample of Bpxbatch commands to delete a z/OS flat file,
and then to allocate it anew? I am trying to work out some processing, and
this would be in the middle of a set of commands. I would hate to break
this up into three job steps, just to insert the delete/allocate in the
middle (I am using the file earlier in the script).

Thank you all!
Billy

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Demos remind me of this joke.
http://www.jokes.net/heavenandhell.htm 
I’ve seen my share of demos that make claims or promises that simply never 
occur.
Thanks Ray, I’ll pass.



Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 1:20 PM, Ray Overby  wrote:

Bill - I am not interested in selling you anything. I will just demo an 
exploit of a code vulnerability. That's it.

On 5/28/2019 12:09 PM, Bill Johnson wrote:
> lol, oh it’s a demo and you sell something to fix the hole right? But, it has 
> never been exploited in the real world.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 1:06 PM, Ray Overby  wrote:
>
> Bill - I assure you the silliness is all on your part. ;-)
>
> /Show me a link to your third scenario successfully implemented? /My company 
> does not publicly disclose z/OS code vulnerabilities that it finds in z/OS, 
> ISV and installation code. I would be happy to demo one of the 
> vulnerabilities for you with a Webex. Please email ray.ove...@krisecurity.com 
> and I will set up an exploit demo for you.
>
> //Or is this some sort of “could happen” if the stars aligned and you
> had a dozen unlikely things happen all at the same time?/ /Nope. This is the 
> real deal Bill. The demo (and any questions) should take less than 30 minutes 
> of your time.
> //
>
>
> On 5/28/2019 11:29 AM, Bill Johnson wrote:
>> Pure silliness now. As this topic always becomes.
>> I never said or insinuated the platform was immune.
>> In shops I’ve worked, very few had access to add to the APF list. Security 
>> and Audit often questioned additions. Most additions were software libs from 
>> 2-3 vendors whose libraries were also tightly controlled.
>> Show me a link to your third scenario successfully implemented? Or is this 
>> some sort of “could happen” if the stars aligned and you had a dozen 
>> unlikely things happen all at the same time?
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Tuesday, May 28, 2019, 11:44 AM, Ray Overby  wrote:
>>
>> This discussion on mainframe vulnerabilities has unfortunately broken
>> down. I have been talking to mainframe people about vulnerabilities for
>> the last 12 years. I have talked with people just like Bill Johnson. My
>> discussions went just like this discussion did. The problem (as I saw
>> it) was that discussing a “mainframe vulnerability” is too ambiguous.
>> The discussion needs to be more specific. This led to categorizing
>> vulnerabilities. When the vulnerabilities were categorized (which also
>> defined their capabilities BUT does not allow the hacker to generate an
>> exploit) the discussions evolved to the point that not only did the
>> mainframe people better understand the vulnerabilities and their
>> associated risk but also allowed C level, managers, Auditors, Security,
>> Pen testers, and Risk people to understand and participate in the
>> vulnerability discussions.
>>
>> For example, you can classify mainframe vulnerabilities based upon their
>> source – configuration or code based. Classifying the vulnerability
>> eliminates ambiguities that are inherent when you don’t classify. It is
>> these ambiguities that can cause the discussion to break down.  For
>> example, how would the discussion have changed if the vulnerabilities
>> under discussion were classified as follows:
>>
>> -Configuration based vulnerabilities
>>
>>      * APF authorized data sets not adequately protected
>>      * SMP/E data sets not adequately protected
>>      * FTP anonymous allowed
>>      * FTP JES option allowed
>>      * Outgoing TCPIP traffic not protected
>>
>> -Code based vulnerabilities
>>
>>      * Storage alteration
>>      * Trap door
>>      * System Instability
>>
>> To better focus the discussion perhaps the following questions should be
>> discussed:
>>
>> Q for Bill Johnson – Are you saying that the mainframe is immune from
>> any type of vulnerabilities (Code and Configuration based)?
>>
>> Q for Bill Johnson - Do you consider a configuration based vulnerability
>> (APF authorized data set not adequately protected) as a hack if it is
>> exploited?
>>
>> Q for Bill Johnson – Do you consider a code based vulnerability (storage
>> alteration that allows dynamic elevation of ESM or z/OS authorities by
>> any user of z/OS) as a hack if it is exploited?
>>
>>
>> On 5/28/2019 9:23 AM, Bill Johnson wrote:
>>> And you sell security services. What do I expect you to say?
>>> Not everything I provided was IBM.
>>>
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
>>> wrote:
>>>
>>> These Are IBM docs. What you expect them to say?
>>>
>>> ITschak
>>>
>>> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
>>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>>>
 On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

> If you either didn’t read or didn’t comprehend the posts I provided, I
 cannot help you.

 As I wrote, I read all of the references t

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Bill - I am not interested in selling you anything. I will just demo an 
exploit of a code vulnerability. That's it.


On 5/28/2019 12:09 PM, Bill Johnson wrote:

lol, oh it’s a demo and you sell something to fix the hole right? But, it has 
never been exploited in the real world.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 1:06 PM, Ray Overby  wrote:

Bill - I assure you the silliness is all on your part. ;-)

/Show me a link to your third scenario successfully implemented? /My company 
does not publicly disclose z/OS code vulnerabilities that it finds in z/OS, ISV 
and installation code. I would be happy to demo one of the vulnerabilities for 
you with a Webex. Please email ray.ove...@krisecurity.com and I will set up an 
exploit demo for you.

//Or is this some sort of “could happen” if the stars aligned and you
had a dozen unlikely things happen all at the same time?/ /Nope. This is the 
real deal Bill. The demo (and any questions) should take less than 30 minutes 
of your time.
//


On 5/28/2019 11:29 AM, Bill Johnson wrote:

Pure silliness now. As this topic always becomes.
I never said or insinuated the platform was immune.
In shops I’ve worked, very few had access to add to the APF list. Security and 
Audit often questioned additions. Most additions were software libs from 2-3 
vendors whose libraries were also tightly controlled.
Show me a link to your third scenario successfully implemented? Or is this some 
sort of “could happen” if the stars aligned and you had a dozen unlikely things 
happen all at the same time?


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 11:44 AM, Ray Overby  wrote:

This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down.  For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:

-Configuration based vulnerabilities

     * APF authorized data sets not adequately protected
     * SMP/E data sets not adequately protected
     * FTP anonymous allowed
     * FTP JES option allowed
     * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

     * Storage alteration
     * Trap door
     * System Instability

To better focus the discussion perhaps the following questions should be
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?


On 5/28/2019 9:23 AM, Bill Johnson wrote:

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:


On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:


If you either didn’t read or didn’t comprehend the posts I provided, I

cannot help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

--
Tom Marchant


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <

000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:


Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely

and

stay on it and spend tens of millions for it. I’ve already provided

numerous

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

lol, oh it’s a demo and you sell something to fix the hole right? But, it has 
never been exploited in the real world.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 1:06 PM, Ray Overby  wrote:

Bill - I assure you the silliness is all on your part. ;-)

/Show me a link to your third scenario successfully implemented? /My company 
does not publicly disclose z/OS code vulnerabilities that it finds in z/OS, ISV 
and installation code. I would be happy to demo one of the vulnerabilities for 
you with a Webex. Please email ray.ove...@krisecurity.com and I will set up an 
exploit demo for you.

//Or is this some sort of “could happen” if the stars aligned and you 
had a dozen unlikely things happen all at the same time?/ /Nope. This is the 
real deal Bill. The demo (and any questions) should take less than 30 minutes 
of your time.
//


On 5/28/2019 11:29 AM, Bill Johnson wrote:
> Pure silliness now. As this topic always becomes.
> I never said or insinuated the platform was immune.
> In shops I’ve worked, very few had access to add to the APF list. Security 
> and Audit often questioned additions. Most additions were software libs from 
> 2-3 vendors whose libraries were also tightly controlled.
> Show me a link to your third scenario successfully implemented? Or is this 
> some sort of “could happen” if the stars aligned and you had a dozen unlikely 
> things happen all at the same time?
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 11:44 AM, Ray Overby  wrote:
>
> This discussion on mainframe vulnerabilities has unfortunately broken
> down. I have been talking to mainframe people about vulnerabilities for
> the last 12 years. I have talked with people just like Bill Johnson. My
> discussions went just like this discussion did. The problem (as I saw
> it) was that discussing a “mainframe vulnerability” is too ambiguous.
> The discussion needs to be more specific. This led to categorizing
> vulnerabilities. When the vulnerabilities were categorized (which also
> defined their capabilities BUT does not allow the hacker to generate an
> exploit) the discussions evolved to the point that not only did the
> mainframe people better understand the vulnerabilities and their
> associated risk but also allowed C level, managers, Auditors, Security,
> Pen testers, and Risk people to understand and participate in the
> vulnerability discussions.
>
> For example, you can classify mainframe vulnerabilities based upon their
> source – configuration or code based. Classifying the vulnerability
> eliminates ambiguities that are inherent when you don’t classify. It is
> these ambiguities that can cause the discussion to break down.  For
> example, how would the discussion have changed if the vulnerabilities
> under discussion were classified as follows:
>
> -Configuration based vulnerabilities
>
>    * APF authorized data sets not adequately protected
>    * SMP/E data sets not adequately protected
>    * FTP anonymous allowed
>    * FTP JES option allowed
>    * Outgoing TCPIP traffic not protected
>
> -Code based vulnerabilities
>
>    * Storage alteration
>    * Trap door
>    * System Instability
>
> To better focus the discussion perhaps the following questions should be
> discussed:
>
> Q for Bill Johnson – Are you saying that the mainframe is immune from
> any type of vulnerabilities (Code and Configuration based)?
>
> Q for Bill Johnson - Do you consider a configuration based vulnerability
> (APF authorized data set not adequately protected) as a hack if it is
> exploited?
>
> Q for Bill Johnson – Do you consider a code based vulnerability (storage
> alteration that allows dynamic elevation of ESM or z/OS authorities by
> any user of z/OS) as a hack if it is exploited?
>
>
> On 5/28/2019 9:23 AM, Bill Johnson wrote:
>> And you sell security services. What do I expect you to say?
>> Not everything I provided was IBM.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
>> wrote:
>>
>> These Are IBM docs. What you expect them to say?
>>
>> ITschak
>>
>> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>>
>>> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>>>
 If you either didn’t read or didn’t comprehend the posts I provided, I
>>> cannot help you.
>>>
>>> As I wrote, I read all of the references that you posted.
>>> Yes, I understood them.
>>> You misrepresented what they said.
>>> Now your response is to insult me. That is pathetic.
>>>
>>> --
>>> Tom Marchant
>>>
 Sent from Yahoo Mail for iPhone


 On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
>>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
 On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:

> Mainframes are by design far more secure. For good reason. The exposure
> is catastrophic potentially. It’s one of the main reasons why banks rely
>>> and
> stay

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Bill - I assure you the silliness is all on your part. ;-)

/Show me a link to your third scenario successfully implemented? /My company
does not publicly disclose z/OS code vulnerabilities that it finds in z/OS, ISV
and installation code. I would be happy to demo one of the vulnerabilities for
you with a Webex. Please email ray.ove...@krisecurity.com and I will set up an
exploit demo for you.

//Or is this some sort of “could happen” if the stars aligned and you
had a dozen unlikely things happen all at the same time?/ /Nope. This is the real deal Bill. The demo (and any questions) should take less than 30 minutes of your time.

On 5/28/2019 11:29 AM, Bill Johnson wrote:

Pure silliness now. As this topic always becomes.
I never said or insinuated the platform was immune.
In shops I’ve worked, very few had access to add to the APF list. Security and
Audit often questioned additions. Most additions were software libs from 2-3
vendors whose libraries were also tightly controlled.
Show me a link to your third scenario successfully implemented? Or is this some
sort of “could happen” if the stars aligned and you had a dozen unlikely things
happen all at the same time?

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 11:44 AM, Ray Overby wrote:

This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down. For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:

-Configuration based vulnerabilities

* APF authorized data sets not adequately protected
* SMP/E data sets not adequately protected
* FTP anonymous allowed
* FTP JES option allowed
* Outgoing TCPIP traffic not protected

-Code based vulnerabilities

* Storage alteration
* Trap door
* System Instability

To better focus the discussion perhaps the following questions should be
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?

On 5/28/2019 9:23 AM, Bill Johnson wrote:

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

If you either didn’t read or didn’t comprehend the posts I provided, I

cannot help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

--
Tom Marchant

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <

000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:

Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely

and

stay on it and spend tens of millions for it. I’ve already provided

numerous

links referencing it.

You have provided pitifully little to support your claim that the

security of

mainframes is the reason banks and others stay with them. I have read
all of the references that you posted, and most of them list the

POTENTIAL

to secure them as ONE of the reasons why people use mainframes for
mission-critical data, but not the main reason.

You have over-stated

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Radoslav,

"Claiming that z/OS has flaws as other systems is the same as claiming bank
is vulnerable to burglars as houses" I am sure you've heard of mettdown an
Spectre. IBM CPU have same issues as any other cpu in market -(

ITschak

On Tue, May 28, 2019 at 7:53 PM R.S.  wrote:

> W dniu 2019-05-28 o 16:31, ITschak Mugzach pisze:
> > Bill,
> >
> > I agree that z/os has the potential to be a secure system, however people
> > configure it. What i do is to show you at real time, the delta between
> > actual and required state if hundreds of security controls. Just to make
> > z/os safe as it should.
> >
> > Most people here think the same. Z/is has the potential, my, and other
> > people , experience shows it does improve it.
>
> Now we're home. People, not platform.
> However we discuss about platform, not people.
> I understand and fully support that your company or Ray's company have
> valuable things to do, but this is related to people, not platform. You
> don't fix the platform, you fix people's mistakes.
>
> Claiming that z/OS has flaws as other systems is the same as claiming
> bank is vulnerable to burglars as houses. While both are vulnerable at
> some extent, the sentence is untrue, because the extent is different and
> the difference is significant.
> In other words no system is 100% immune, but some systems are less
> immune than others. And again: the difference is significant.
>
>
> BTW: The above remains me C2 classification for Windows NT server. One
> of the conditions was the server may not be connected to the network. ;-)
>
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2018 r. wynosi 169.248.488 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169,248,488 as at 1 January 2018.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: Binder control statements and `ld'

2019-05-28 Thread Pew, Curtis G

On May 27, 2019, at 6:48 AM, Binyamin Dissen 
mailto:bdis...@dissensoftware.com>> wrote:

Or you can have a module consisting of PUNCH statements.


I thought I had tried that once and it hadn’t worked, but I just tried it again 
and it worked. Thanks.


--
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread R.S.


W dniu 2019-05-28 o 16:31, ITschak Mugzach pisze:

Bill,

I agree that z/os has the potential to be a secure system, however people
configure it. What i do is to show you at real time, the delta between
actual and required state if hundreds of security controls. Just to make
z/os safe as it should.

Most people here think the same. Z/is has the potential, my, and other
people , experience shows it does improve it.


Now we're home. People, not platform.
However we discuss about platform, not people.
I understand and fully support that your company or Ray's company have 
valuable things to do, but this is related to people, not platform. You 
don't fix the platform, you fix people's mistakes.


Claiming that z/OS has flaws as other systems is the same as claiming 
bank is vulnerable to burglars as houses. While both are vulnerable at 
some extent, the sentence is untrue, because the extent is different and 
the difference is significant.
In other words no system is 100% immune, but some systems are less 
immune than others. And again: the difference is significant.



BTW: The above remains me C2 classification for Windows NT server. One 
of the conditions was the server may not be connected to the network. ;-)


Regards
--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: SDSF API question -- why only REXX & Java?

The Sun is hot. ADDRESS LINKMVS is not relevant to the REXX support in SDSF, 
which does something that ADDRESS LINKMVS does not address. Until such time as 
COBOL supports associative arrays that a subroutine can update, those 
facilities will not be available from COBOL.

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

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, May 26, 2019 4:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF API question -- why only REXX & Java?

On Sun, 26 May 2019 18:53:43 +, Seymour J Metz wrote:

>You call SDSF from REXX in a special environment that allows returning REXX 
>variables. There is no equivalent in any other supported language. I don't 
>know what IBM did for Java.
>
ADDRESS LINKMVS supports bidirectional transfer of values via
parameters.  The Rexx caller must supply the names.  See the
ICSF examples in SAMPLIB and their long parameter lists.  The
same should work for Assembler and thus COBOL, etc.

-- gil

--
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: Fwd: Just how secure are mainframes? | Trevor Eddolls

It's prudent to periodically review and re-evaluate everything. If the access 
for a server is consistently wrong then there is a serious problem with the 
process and I would expect it to surface on other servers. If *any* type of 
configuration error keeps happening over time then management is asleep at the 
switch.  Once is happenstance, twice is coincidence but three times is enemy 
action.


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


From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Tuesday, May 28, 2019 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Excellent suggestions for vulnerability categories.

If an exploit uses anonymous FTP wouldn't Anonymous FTP be considered
vulnerable in its current configuration? If not what would you consider
the vulnerability to be? Anonymous FTP + ESM? or ESM? or?

The remediation might be to remove the option of Anonymous FTP OR it
might be to tighten down the security for the files that are available
to the FTP id. Would it be prudent to review or re-evaluate the choice
of Anonymous FTP as part of the remediation process? Maybe? Probably?
Also, what happens if this type of vulnerability keeps happening over
time? Once is just a mistake, but an on-going re-occurring problem may
prompt a re-evaluation of Anonymous FTP.

On 5/28/2019 10:52 AM, Seymour J Metz wrote:
> What about personnel-based vulnerabilities, e.g.,
>
>  Social engineering
>  Writing down passwords
>  insider attacks
>
> Anonymous FTP is not a vulnerability per se; what is a vulnerability is 
> giving an FTP more access than is appropriate for its role. An anonymous FTP 
> server should run under a userid that only has access to those datasets that 
> should be publicly readable.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Ray Overby 
> Sent: Tuesday, May 28, 2019 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> This discussion on mainframe vulnerabilities has unfortunately broken
> down. I have been talking to mainframe people about vulnerabilities for
> the last 12 years. I have talked with people just like Bill Johnson. My
> discussions went just like this discussion did. The problem (as I saw
> it) was that discussing a “mainframe vulnerability” is too ambiguous.
> The discussion needs to be more specific. This led to categorizing
> vulnerabilities. When the vulnerabilities were categorized (which also
> defined their capabilities BUT does not allow the hacker to generate an
> exploit) the discussions evolved to the point that not only did the
> mainframe people better understand the vulnerabilities and their
> associated risk but also allowed C level, managers, Auditors, Security,
> Pen testers, and Risk people to understand and participate in the
> vulnerability discussions.
>
> For example, you can classify mainframe vulnerabilities based upon their
> source – configuration or code based. Classifying the vulnerability
> eliminates ambiguities that are inherent when you don’t classify. It is
> these ambiguities that can cause the discussion to break down.  For
> example, how would the discussion have changed if the vulnerabilities
> under discussion were classified as follows:
>
> -Configuration based vulnerabilities
>
>* APF authorized data sets not adequately protected
>* SMP/E data sets not adequately protected
>* FTP anonymous allowed
>* FTP JES option allowed
>* Outgoing TCPIP traffic not protected
>
> -Code based vulnerabilities
>
>* Storage alteration
>* Trap door
>* System Instability
>
> To better focus the discussion perhaps the following questions should be
> discussed:
>
> Q for Bill Johnson – Are you saying that the mainframe is immune from
> any type of vulnerabilities (Code and Configuration based)?
>
> Q for Bill Johnson - Do you consider a configuration based vulnerability
> (APF authorized data set not adequately protected) as a hack if it is
> exploited?
>
> Q for Bill Johnson – Do you consider a code based vulnerability (storage
> alteration that allows dynamic elevation of ESM or z/OS authorities by
> any user of z/OS) as a hack if it is exploited?
>
>
> On 5/28/2019 9:23 AM, Bill Johnson wrote:
>> And you sell security services. What do I expect you to say?
>> Not everything I provided was IBM.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
>> wrote:
>>
>> These Are IBM docs. What you expect them to say?
>>
>> ITschak
>>
>> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>>
>>> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>>>
 If you either didn’t read or didn’t comprehend the posts I pr

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

05F0
0A0C


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


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Monday, May 27, 2019 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

[Default] On 27 May 2019 09:05:47 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>Mainframes are by design far more secure. For good reason. The exposure is 
>catastrophic potentially. It’s one of the main reasons why banks rely and stay 
>on it and spend tens of millions for it. I’ve already provided numerous links 
>referencing it. Add in my criminal justice knowledge along with my computer 
>science degree and 40 years of experience in IT and security. But don’t let me 
>dispel your beliefs.
>
Hopefully the mainframe is more secure than in the era that had at
least one university had a CRASH command that would take down the
system because so many students were finding ways to crash the system.
There are ways to secure all files and other resources but are they
used and access kept current?  The problem is keeping the system
secure while allowing people to do useful work.  The IBM mainframe has
the base facilities but are they used and considered usable?

Can someone access the system after leaving the organization?  Are
test files well secured?  Are those who have access to the system well
vetted?  Are the applications designed in a secure manner?  Is all
data entering a given computer system checked on that system even if
that data is coming from a PC or other entry device using screens
supplied by the mainframe system? On things like web servers which are
cross platform, Apache for example, is there a process in place to
keep up to date with the fixes which are also cross platform?  What is
the policy for applying integrity APARs?  If the IBM tools provided
are awkward to use, is the organization willing to spend the money for
3rd party tools to ease the burden and simplify the implementation of
the organization's policies?

The question is more not how secure a system can be made but rather
how secure the organization is willing to make it.  Is the security
implemented in a way that doesn't cause people to try finding ways of
gaming it in order to do their jobs?

Clark Morris
>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
> wrote:
>
>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>apples and spiders.
>
>Are there fewer mainframe 'hacks'? Yep.  There are also exponentially fewer 
>mainframes than Windows / Android / Mac / IOS / Linux. Like - a few thousand 
>mainframes compared to 2.5 BILLION users of Windows/Linux/Mac/Android & IOS 
>combined.  That is somewhere between 250,000 - 500,000x more installs of those 
>OS's.  And they are freely available for literally anyone to poke at.
>
>What you're arguing "Because Windows gets hacked daily, and mainframes are 
>never in the news as have being hacked - means that mainframes are more secure 
>.. more 'hack-proof'"  Is like saying that:
>
>-- Homes in Toronto are more hurricane-proof because fewer of them are 
>destroyed than in Key West.
>OR
>-- Babies are better drivers than their parents, because their parents get in 
>accidents every day.
>OR
>-- People in Greenland are less susceptible to cancer because fewer people die 
>of it than do in the US.
>
>For years people thought Macs were less susceptible to viruses than their 
>Windows counterparts... because?  They never read about Mac hacks.  The 
>reality?  There were way fewer Macs.  Now?  Still much less marketshare than 
>Windows, but lots of Mac hacks/malware out there because they have more than 
>doubled their market share in 6-8 years.
>
>Mainframe hardware / software is built by humans for humans (BHFH?) and will 
>thus always have vulnerabilities and misconfigurations because we all make 
>mistakes.  Mainframe is decidedly just as hackable - by any definition of that 
>word.
>
>Cheers,
>
>Chad
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Pure silliness now. As this topic always becomes.
I never said or insinuated the platform was immune.
In shops I’ve worked, very few had access to add to the APF list. Security and 
Audit often questioned additions. Most additions were software libs from 2-3 
vendors whose libraries were also tightly controlled.
Show me a link to your third scenario successfully implemented? Or is this some 
sort of “could happen” if the stars aligned and you had a dozen unlikely things 
happen all at the same time?

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 11:44 AM, Ray Overby  wrote:

This discussion on mainframe vulnerabilities has unfortunately broken 
down. I have been talking to mainframe people about vulnerabilities for 
the last 12 years. I have talked with people just like Bill Johnson. My 
discussions went just like this discussion did. The problem (as I saw 
it) was that discussing a “mainframe vulnerability” is too ambiguous. 
The discussion needs to be more specific. This led to categorizing 
vulnerabilities. When the vulnerabilities were categorized (which also 
defined their capabilities BUT does not allow the hacker to generate an 
exploit) the discussions evolved to the point that not only did the 
mainframe people better understand the vulnerabilities and their 
associated risk but also allowed C level, managers, Auditors, Security, 
Pen testers, and Risk people to understand and participate in the 
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their 
source – configuration or code based. Classifying the vulnerability 
eliminates ambiguities that are inherent when you don’t classify. It is 
these ambiguities that can cause the discussion to break down.  For 
example, how would the discussion have changed if the vulnerabilities 
under discussion were classified as follows:

-Configuration based vulnerabilities

  * APF authorized data sets not adequately protected
  * SMP/E data sets not adequately protected
  * FTP anonymous allowed
  * FTP JES option allowed
  * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

  * Storage alteration
  * Trap door
  * System Instability

To better focus the discussion perhaps the following questions should be 
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from 
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability 
(APF authorized data set not adequately protected) as a hack if it is 
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage 
alteration that allows dynamic elevation of ESM or z/OS authorities by 
any user of z/OS) as a hack if it is exploited?

On 5/28/2019 9:23 AM, Bill Johnson wrote:
> And you sell security services. What do I expect you to say?
> Not everything I provided was IBM.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
> wrote:
>
> These Are IBM docs. What you expect them to say?
>
> ITschak
>
> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>
>> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>>
>>> If you either didn’t read or didn’t comprehend the posts I provided, I
>> cannot help you.
>>
>> As I wrote, I read all of the references that you posted.
>> Yes, I understood them.
>> You misrepresented what they said.
>> Now your response is to insult me. That is pathetic.
>>
>> --
>> Tom Marchant
>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>>> On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>>>
 Mainframes are by design far more secure. For good reason. The exposure
 is catastrophic potentially. It’s one of the main reasons why banks rely
>> and
 stay on it and spend tens of millions for it. I’ve already provided
>> numerous
 links referencing it.
>>> You have provided pitifully little to support your claim that the
>> security of
>>> mainframes is the reason banks and others stay with them. I have read
>>> all of the references that you posted, and most of them list the
>> POTENTIAL
>>> to secure them as ONE of the reasons why people use mainframes for
>>> mission-critical data, but not the main reason.
>>>
>>> You have over-stated your case.
>>>
 Add in my criminal justice knowledge along with my computer science
 degree and 40 years of experience in IT and security. But don’t let me
 dispel your beliefs.
>>> So I shoulodn't question you because you are the expert?
>>> I call BS.
>>>
>>> --
>>> Tom Marchant
>>>
 Sent from Yahoo Mail for iPhone

 On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
>> mainfr...@bigendiansmalls.com> wrote:
 At the risk of re-kicking the already dead horse:  Bill, you're
>> comparing apples and spiders.
>>>

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls


Excellent suggestions for vulnerability categories.

If an exploit uses anonymous FTP wouldn't Anonymous FTP be considered 
vulnerable in its current configuration? If not what would you consider 
the vulnerability to be? Anonymous FTP + ESM? or ESM? or?


The remediation might be to remove the option of Anonymous FTP OR it 
might be to tighten down the security for the files that are available 
to the FTP id. Would it be prudent to review or re-evaluate the choice 
of Anonymous FTP as part of the remediation process? Maybe? Probably?  
Also, what happens if this type of vulnerability keeps happening over 
time? Once is just a mistake, but an on-going re-occurring problem may 
prompt a re-evaluation of Anonymous FTP.


On 5/28/2019 10:52 AM, Seymour J Metz wrote:

What about personnel-based vulnerabilities, e.g.,

 Social engineering
 Writing down passwords
 insider attacks

Anonymous FTP is not a vulnerability per se; what is a vulnerability is giving 
an FTP more access than is appropriate for its role. An anonymous FTP server 
should run under a userid that only has access to those datasets that should be 
publicly readable.

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


From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Tuesday, May 28, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down.  For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:

-Configuration based vulnerabilities

   * APF authorized data sets not adequately protected
   * SMP/E data sets not adequately protected
   * FTP anonymous allowed
   * FTP JES option allowed
   * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

   * Storage alteration
   * Trap door
   * System Instability

To better focus the discussion perhaps the following questions should be
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?


On 5/28/2019 9:23 AM, Bill Johnson wrote:

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:


On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:


If you either didn’t read or didn’t comprehend the posts I provided, I

cannot help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

--
Tom Marchant


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <

000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:


Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely

and

stay on it and spend tens of millions for it. I’ve already provided

numerous

links referencing it.

You have provided pitifully little to support your claim that the

security of

mainframes is the reason banks and others stay with them. I have read
all of the references that you posted, and most

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

No, it's cracking or social engineering as the case may be. Any meaningful 
discussion of security at a specific site must include at least physical 
security, software security, configuration security and personnel security.


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


From: IBM Mainframe Discussion List  on behalf of 
Lennie Dymoke-Bradshaw 
Sent: Tuesday, May 28, 2019 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In addition to defining what is "security" we need to define what we mean by 
"hacking". In my previous career at IBM I was asked this many times. At that 
time I preferred to talk of an "attack" on the mainframe, and then determine 
the susceptibility of the system to that attack.

However, I came up with some situations which could be examined to try and get 
people to define what they mean by "hacking" in this context. The questions I 
asked were the following. I suspect different folks will come up with different 
answers for some of these questions.  You will soon see, as well where the 
fault/blame/responsibility for security lies for each of these situations. 
Anyway, here are the questions I used.

1. If I use a colleague's userid and password without his knowledge, is this 
hacking? Have I hacked the mainframe?

2. If I trick a mainframe user into divulging his password, and then use this 
to access data, is this hacking? Have I hacked the mainframe?

3. If I use access I have been given in a manner which it was not designed to 
be used for (e.g. access to a break-glass userid for recovery), and so gain 
access to private data, am I hacking? Have I hacked the mainframe?

4. If I am a systems programmer and have legitimate UPDATE access to an APF 
authorised library, and use it to gain RACF SPECIAL, is this hacking? Have I 
hacked the mainframe?

5. If I have a basic userid on a z/OS system, and then discover that I can make 
use of unprotected CSA storage created by a badly coded 3rd party product which 
uses it for inter-address space communications, and I use this to gain access 
to data I would not normally have access to, is this hacking? Have I hacked the 
mainframe?

6. If I discover a bad z/OS configuration option has been used (e.g. IDCAMS in 
AUTHTSF), and I exploit it to gain access in key zero and then grant my userid 
RACF SPECIAL, am I hacking? Have I hacked the mainframe?

7. If I gain access to a DB2 userid because its password is hard-coded on a 
distributed server, and then use it to gain access to DB2 on z/OS, am I 
hacking? Have I hacked the mainframe?

8. If I discover a z/OS integrity exposure, which should be covered by the z/OS 
Statement of Integrity, and then make use of it, instead of reporting it to IBM 
to be resolved, am I hacking? Have I hacked the mainframe?

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
Web:  
http://secure-web.cisco.com/1qBkHi2vmFs6-X53Nw2_sH7T7jDbg-Ujkxfe0Vki7Yg4el9KCs4fJYYIV2N3d7wCg_7J9HwEStXR83_oa6cB_JRnAi1wFDWZzJFQYcGL-yDULCweDAOKvBJ-CDlpzHNf-qzURM83Y3JHhGi0FccxlMFCQpIVM-pRxphGKFq0oOAKFgWogoAxwGdt3OfTQlNeKS9qG0rzq_b5JtqrBNcfLzpFsJhUseexehN94sMG57UO3_I0XGQAYcc_4HhcZBr5e2BQXoNDIV00cY9reX97B7hl9OQ_klG1Ptpaz4qVsBXmppPmTX2p6-QB4ggzysfzL7OuLEbmUjITCFAmDO52uMkVWeoishHu_ldf6xf74azsk_ptgsy9ikTrgSWdY6W-6/http%3A%2F%2Fwww.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: 28 May 2019 08:13
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Fwd: Just how secure are mainframes? | Trevor Eddolls

Well, it seems 'security' needs to be defined here.
Probably like in my answer to Bill: difficulty * result.

You are secure enough if you can prevent a hacker to steal $100,= by delaying 
him for 1 hour.
You are not if you can delay him for only one hour to steal a million.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: 28 May, 2019 9:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze:
> > At the risk of re-kicking the already dead horse:  Bill, you're
> comparing apples and spiders.
> >
> > Are there fewer mainframe 'hacks'? Yep.  There are also
> > exponentially
> fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a
> few thousand mainframes compared to 2.5 BILLION users of
> Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> 250,000 - 500,000x more installs of those OS's.  And they are freely
> available for literally anyone to poke at.
> >
> > What you're arguing "Because Windows gets hacked daily, and
> > mainframes
> are never in the news as have being hacked - means that mainframes are
> more secure .. more 'hack-proof'"  Is like saying that:
>

Re: RSUs

2019-05-28 Thread Styles, Andy (ITS zPlatform Services)

Classification: Public
Hi Kurt, 

I've snipped a fair bit of this, but (and I've manually added quoting, so 
apologies if it breaks): 

> Were any of these PTFs also received in the prior RECEIVE ORDER?  And Were 
> they applied and
> accepted, perhaps purging them from the global zone prior to the latest 
> RECEIVE ORDER?  Were
> they assigned the RSU1903 sourceid in the first, second, or both RECEIVEs?

We definitely did not have the second set of fixes in the global zone prior to 
the second RECEIVE; given I specified RECOMMENDED both times, I (naïvely 
perhaps) assumed I'd get the latest RSU. This is where this question has arisen 
from - how did I get more fixes tagged with RSU1903 with a second RECEIVE 
RECOMMENDED, after the RSU publish date?

> This last question about when/if RSU1903 was assigned is the important one, 
> but I fear you
> may not know the answer without the SMPRPT output for the RECEIVEs.

I have some stored job output, but I can't guarantee that I have ALL output, so 
I don't know if it'll be enough, or whether it contains what we're looking for. 
Fantastic as it is to get support this way, are we moving into PMR territory?

-- 
Andy Styles
z/Series System Programmer


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.



Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.



Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801. 



Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London 
EC2V 7HN. Registered in England and Wales no. 10399850.



Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are 
authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and Prudential Regulation Authority.



Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned 
subsidiary of Lloyds Bank Corporate Markets plc.  Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 
6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht 
Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für 
Finanzdienstleistungsaufsicht.



Halifax is a division of Bank of Scotland plc.



HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.



This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.


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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What about personnel-based vulnerabilities, e.g.,

Social engineering
Writing down passwords
insider attacks

Anonymous FTP is not a vulnerability per se; what is a vulnerability is giving 
an FTP more access than is appropriate for its role. An anonymous FTP server 
should run under a userid that only has access to those datasets that should be 
publicly readable.

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

From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Tuesday, May 28, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down.  For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:

-Configuration based vulnerabilities

  * APF authorized data sets not adequately protected
  * SMP/E data sets not adequately protected
  * FTP anonymous allowed
  * FTP JES option allowed
  * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

  * Storage alteration
  * Trap door
  * System Instability

To better focus the discussion perhaps the following questions should be
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?

On 5/28/2019 9:23 AM, Bill Johnson wrote:
> And you sell security services. What do I expect you to say?
> Not everything I provided was IBM.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
> wrote:
>
> These Are IBM docs. What you expect them to say?
>
> ITschak
>
> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>
>> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>>
>>> If you either didn’t read or didn’t comprehend the posts I provided, I
>> cannot help you.
>>
>> As I wrote, I read all of the references that you posted.
>> Yes, I understood them.
>> You misrepresented what they said.
>> Now your response is to insult me. That is pathetic.
>>
>> --
>> Tom Marchant
>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>>> On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>>>
 Mainframes are by design far more secure. For good reason. The exposure
 is catastrophic potentially. It’s one of the main reasons why banks rely
>> and
 stay on it and spend tens of millions for it. I’ve already provided
>> numerous
 links referencing it.
>>> You have provided pitifully little to support your claim that the
>> security of
>>> mainframes is the reason banks and others stay with them. I have read
>>> all of the references that you posted, and most of them list the
>> POTENTIAL
>>> to secure them as ONE of the reasons why people use mainframes for
>>> mission-critical data, but not the main reason.
>>>
>>> You have over-stated your case.
>>>
 Add in my criminal justice knowledge along with my computer science
 degree and 40 years of experience in IT and security. But don’t let me
 dispel your beliefs.
>>> So I shoulodn't question you because you are the expert?
>>> I call BS.
>>>
>>> --
>>> Tom Marchant
>>>
 Sent from Yahoo Mail for iPhone

 On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
>> mainfr...@bigendiansmalls.com> wrote:
 At the risk of re-kicking the already dead

Re: CTC (FCTC) usage [EXTERNAL]

2019-05-28 Thread Feller, Paul

Munif, there is some doc related to how to setup a CTC environment.  If you are 
looking on the IBM hardware website for the z14 you should find a manual on CTC 
configuration.  At our shop the real users of CTCs is XCF and VTAM.  Those are 
the only tasks that have CTC device addresses defined to them.  Things like GRS 
(and others) can use XCF for communications.  Tasks like JES or CICS can use IP 
(OSAs or Hipersockets) or VTAM for communications. 

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Parwez Hamid
Sent: Tuesday, May 28, 2019 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CTC (FCTC) usage [EXTERNAL]

Doc is dated (URL below). There are other Ficon related Redbooks also


https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redbooks.ibm.com_abstracts_redp0158.html-3FOpen&d=DwIFAg&c=9g4MJkl2VjLjS6R4ei18BA&r=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc&m=4WJzQWDiI8d5zZowlLjNdf96s-wyQUHsbAPqXvG_c6o&s=sa5ZCwwyqGFHvy4uEMJgyP24P9F0WXLEZaRWAnQNEwM&e=

Get Outlook for 
Android


From: IBM Mainframe Discussion List  on behalf of 
Munif Sadek 
Sent: Tuesday, May 28, 2019 3:40:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CTC (FCTC) usage

we are getting new z14 and time to revisit our CTC configuration.

Is there a complete documentation on FICON CTC implementation and its potential 
usage / configuration for various subsystems e.g. VTAM, TCP/IP, GRS, NJE, XCF 
etc . we are single CPC SYSPLEX environment and just exploring where all CTCs 
can be used.

Currently we us it only for VTAM (TRL) and IP.

regards
Munif

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

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

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

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken 
down. I have been talking to mainframe people about vulnerabilities for 
the last 12 years. I have talked with people just like Bill Johnson. My 
discussions went just like this discussion did. The problem (as I saw 
it) was that discussing a “mainframe vulnerability” is too ambiguous. 
The discussion needs to be more specific. This led to categorizing 
vulnerabilities. When the vulnerabilities were categorized (which also 
defined their capabilities BUT does not allow the hacker to generate an 
exploit) the discussions evolved to the point that not only did the 
mainframe people better understand the vulnerabilities and their 
associated risk but also allowed C level, managers, Auditors, Security, 
Pen testers, and Risk people to understand and participate in the 
vulnerability discussions.


For example, you can classify mainframe vulnerabilities based upon their 
source – configuration or code based. Classifying the vulnerability 
eliminates ambiguities that are inherent when you don’t classify. It is 
these ambiguities that can cause the discussion to break down.  For 
example, how would the discussion have changed if the vulnerabilities 
under discussion were classified as follows:


-Configuration based vulnerabilities

 * APF authorized data sets not adequately protected
 * SMP/E data sets not adequately protected
 * FTP anonymous allowed
 * FTP JES option allowed
 * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

 * Storage alteration
 * Trap door
 * System Instability

To better focus the discussion perhaps the following questions should be 
discussed:


Q for Bill Johnson – Are you saying that the mainframe is immune from 
any type of vulnerabilities (Code and Configuration based)?


Q for Bill Johnson - Do you consider a configuration based vulnerability 
(APF authorized data set not adequately protected) as a hack if it is 
exploited?


Q for Bill Johnson – Do you consider a code based vulnerability (storage 
alteration that allows dynamic elevation of ESM or z/OS authorities by 
any user of z/OS) as a hack if it is exploited?



On 5/28/2019 9:23 AM, Bill Johnson wrote:

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:


On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:


If you either didn’t read or didn’t comprehend the posts I provided, I

cannot help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

--
Tom Marchant


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <

000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:


Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely

and

stay on it and spend tens of millions for it. I’ve already provided

numerous

links referencing it.

You have provided pitifully little to support your claim that the

security of

mainframes is the reason banks and others stay with them. I have read
all of the references that you posted, and most of them list the

POTENTIAL

to secure them as ONE of the reasons why people use mainframes for
mission-critical data, but not the main reason.

You have over-stated your case.


Add in my criminal justice knowledge along with my computer science
degree and 40 years of experience in IT and security. But don’t let me
dispel your beliefs.

So I shoulodn't question you because you are the expert?
I call BS.

--
Tom Marchant


Sent from Yahoo Mail for iPhone


On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <

mainfr...@bigendiansmalls.com> wrote:

At the risk of re-kicking the already dead horse:  Bill, you're

comparing apples and spiders.

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

On Tue, May 28, 2019 at 10:27 AM Mike Schwab 
wrote:

> Yet many more people still break into homes vs banks despite low yield
> because of the low odds of being cot and the low penalty if you are
> caught.
>
>
"low penalty" in Texas is not necessarily true. I someone were to break
into my boss' house, he'd have to call the coroner to take the body to the
morgue. And that is totally legal in Texas. As for me, anyone with any
taste would know that my stuff isn't worth stealing. Most things I have are
around 20+ years old, excepting my gaming system & cheap laptop.

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


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: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread Mike Schwab

Yet many more people still break into homes vs banks despite low yield
because of the low odds of being cot and the low penalty if you are
caught.

On Tue, May 28, 2019 at 2:09 AM Vernooij, Kees (ITOP NM) - KLM
 wrote:
>
> Then 'real reason' should be: the 'ease of breaking in' multiplied by 'the 
> result of breaking in', both weighed by personal weight factors.
> That is why some still try to break in banks.
>
> Kees.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Bill Johnson
> > Sent: 27 May, 2019 18:20
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> >
> > Your analogies are similar to claiming houses are broken into more than
> > banks because there are more of them. Whereas the real reason is the ease
> > of breaking in.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud
> >  wrote:
> >
> > At the risk of re-kicking the already dead horse:  Bill, you're comparing
> > apples and spiders.
> >
> > Are there fewer mainframe 'hacks'? Yep.  There are also exponentially
> > fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a few
> > thousand mainframes compared to 2.5 BILLION users of
> > Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> > 250,000 - 500,000x more installs of those OS's.  And they are freely
> > available for literally anyone to poke at.
> >
> > What you're arguing "Because Windows gets hacked daily, and mainframes are
> > never in the news as have being hacked - means that mainframes are more
> > secure .. more 'hack-proof'"  Is like saying that:
> >
> > -- Homes in Toronto are more hurricane-proof because fewer of them are
> > destroyed than in Key West.
> > OR
> > -- Babies are better drivers than their parents, because their parents get
> > in accidents every day.
> > OR
> > -- People in Greenland are less susceptible to cancer because fewer people
> > die of it than do in the US.
> >
> > For years people thought Macs were less susceptible to viruses than their
> > Windows counterparts... because?  They never read about Mac hacks.  The
> > reality?  There were way fewer Macs.  Now?  Still much less marketshare
> > than Windows, but lots of Mac hacks/malware out there because they have
> > more than doubled their market share in 6-8 years.
> >
> > Mainframe hardware / software is built by humans for humans (BHFH?) and
> > will thus always have vulnerabilities and misconfigurations because we all
> > make mistakes.  Mainframe is decidedly just as hackable - by any
> > definition of that word.
> >
> > Cheers,
> >
> > Chad
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
> employees shall not be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
> Airlines) is registered in Amstelveen, The Netherlands, with registered 
> number 33014286
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
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: CTC (FCTC) usage

2019-05-28 Thread Parwez Hamid

Doc is dated (URL below). There are other Ficon related Redbooks also


http://www.redbooks.ibm.com/abstracts/redp0158.html?Open

Get Outlook for Android


From: IBM Mainframe Discussion List  on behalf of 
Munif Sadek 
Sent: Tuesday, May 28, 2019 3:40:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CTC (FCTC) usage

we are getting new z14 and time to revisit our CTC configuration.

Is there a complete documentation on FICON CTC implementation and its potential 
usage / configuration for various subsystems e.g. VTAM, TCP/IP, GRS, NJE, XCF 
etc . we are single CPC SYSPLEX environment and just exploring where all CTCs 
can be used.

Currently we us it only for VTAM (TRL) and IP.

regards
Munif

--
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: Fwd: Just how secure are mainframes? | Trevor Eddolls

I agree, the biggest exposure is the people who don’t take security seriously. 
But, z/OS is inherently more secure than other platforms because of the design. 
In the bank and insurance company I worked for, security was paramount. Because 
of the data we handled. Banking records are as critical as data gets. So too 
were health insurance data. Other companies I worked, manufacturing for 
example, security was not taken as seriously. And, I’ve worked for companies 
that replaced the mainframe as well. 


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:31 AM, ITschak Mugzach  wrote:

Bill,

I agree that z/os has the potential to be a secure system, however people
configure it. What i do is to show you at real time, the delta between
actual and required state if hundreds of security controls. Just to make
z/os safe as it should.

Most people here think the same. Z/is has the potential, my, and other
people , experience shows it does improve it.

ITschak

ITschak

בתאריך יום ג׳, 28 במאי 2019, 17:23, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> And you sell security services. What do I expect you to say?
> Not everything I provided was IBM.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach 
> wrote:
>
> These Are IBM docs. What you expect them to say?
>
> ITschak
>
> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>
> > On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
> >
> > >If you either didn’t read or didn’t comprehend the posts I provided, I
> > cannot help you.
> >
> > As I wrote, I read all of the references that you posted.
> > Yes, I understood them.
> > You misrepresented what they said.
> > Now your response is to insult me. That is pathetic.
> >
> > --
> > Tom Marchant
> >
> > >
> > >Sent from Yahoo Mail for iPhone
> > >
> > >
> > >On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
> > 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > >On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
> > >
> > >>Mainframes are by design far more secure. For good reason. The exposure
> > >>is catastrophic potentially. It’s one of the main reasons why banks
> rely
> > and
> > >>stay on it and spend tens of millions for it. I’ve already provided
> > numerous
> > >>links referencing it.
> > >
> > >You have provided pitifully little to support your claim that the
> > security of
> > >mainframes is the reason banks and others stay with them. I have read
> > >all of the references that you posted, and most of them list the
> > POTENTIAL
> > >to secure them as ONE of the reasons why people use mainframes for
> > >mission-critical data, but not the main reason.
> > >
> > >You have over-stated your case.
> > >
> > >>Add in my criminal justice knowledge along with my computer science
> > >>degree and 40 years of experience in IT and security. But don’t let me
> > >>dispel your beliefs.
> > >
> > >So I shoulodn't question you because you are the expert?
> > >I call BS.
> > >
> > >--
> > >Tom Marchant
> > >
> > >>
> > >>Sent from Yahoo Mail for iPhone
> > >>
> > >>
> > >>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
> > mainfr...@bigendiansmalls.com> wrote:
> > >>
> > >>At the risk of re-kicking the already dead horse:  Bill, you're
> > comparing apples and spiders.
> > >
> > >--
> > >For IBM-MAIN subscribe / signoff / archive access instructions,
> > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > >
> > >
> > >--
> > >For IBM-MAIN subscribe / signoff / archive access instructions,
> > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

CTC (FCTC) usage

2019-05-28 Thread Munif Sadek

we are getting new z14 and time to revisit our CTC configuration.

Is there a complete documentation on FICON CTC implementation and its potential 
usage / configuration for various subsystems e.g. VTAM, TCP/IP, GRS, NJE, XCF 
etc . we are single CPC SYSPLEX environment and just exploring where all CTCs 
can be used.

Currently we us it only for VTAM (TRL) and IP.

regards
Munif

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Bill,

I agree that z/os has the potential to be a secure system, however people
configure it. What i do is to show you at real time, the delta between
actual and required state if hundreds of security controls. Just to make
z/os safe as it should.

Most people here think the same. Z/is has the potential, my, and other
people , experience shows it does improve it.

ITschak

ITschak

בתאריך יום ג׳, 28 במאי 2019, 17:23, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> And you sell security services. What do I expect you to say?
> Not everything I provided was IBM.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach 
> wrote:
>
> These Are IBM docs. What you expect them to say?
>
> ITschak
>
> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>
> > On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
> >
> > >If you either didn’t read or didn’t comprehend the posts I provided, I
> > cannot help you.
> >
> > As I wrote, I read all of the references that you posted.
> > Yes, I understood them.
> > You misrepresented what they said.
> > Now your response is to insult me. That is pathetic.
> >
> > --
> > Tom Marchant
> >
> > >
> > >Sent from Yahoo Mail for iPhone
> > >
> > >
> > >On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
> > 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > >On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
> > >
> > >>Mainframes are by design far more secure. For good reason. The exposure
> > >>is catastrophic potentially. It’s one of the main reasons why banks
> rely
> > and
> > >>stay on it and spend tens of millions for it. I’ve already provided
> > numerous
> > >>links referencing it.
> > >
> > >You have provided pitifully little to support your claim that the
> > security of
> > >mainframes is the reason banks and others stay with them. I have read
> > >all of the references that you posted, and most of them list the
> > POTENTIAL
> > >to secure them as ONE of the reasons why people use mainframes for
> > >mission-critical data, but not the main reason.
> > >
> > >You have over-stated your case.
> > >
> > >>Add in my criminal justice knowledge along with my computer science
> > >>degree and 40 years of experience in IT and security. But don’t let me
> > >>dispel your beliefs.
> > >
> > >So I shoulodn't question you because you are the expert?
> > >I call BS.
> > >
> > >--
> > >Tom Marchant
> > >
> > >>
> > >>Sent from Yahoo Mail for iPhone
> > >>
> > >>
> > >>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
> > mainfr...@bigendiansmalls.com> wrote:
> > >>
> > >>At the risk of re-kicking the already dead horse:  Bill, you're
> > comparing apples and spiders.
> > >
> > >--
> > >For IBM-MAIN subscribe / signoff / archive access instructions,
> > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > >
> > >
> > >--
> > >For IBM-MAIN subscribe / signoff / archive access instructions,
> > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:

> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>
> >If you either didn’t read or didn’t comprehend the posts I provided, I
> cannot help you.
>
> As I wrote, I read all of the references that you posted.
> Yes, I understood them.
> You misrepresented what they said.
> Now your response is to insult me. That is pathetic.
>
> --
> Tom Marchant
>
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
> >
> >>Mainframes are by design far more secure. For good reason. The exposure
> >>is catastrophic potentially. It’s one of the main reasons why banks rely
> and
> >>stay on it and spend tens of millions for it. I’ve already provided
> numerous
> >>links referencing it.
> >
> >You have provided pitifully little to support your claim that the
> security of
> >mainframes is the reason banks and others stay with them. I have read
> >all of the references that you posted, and most of them list the
> POTENTIAL
> >to secure them as ONE of the reasons why people use mainframes for
> >mission-critical data, but not the main reason.
> >
> >You have over-stated your case.
> >
> >>Add in my criminal justice knowledge along with my computer science
> >>degree and 40 years of experience in IT and security. But don’t let me
> >>dispel your beliefs.
> >
> >So I shoulodn't question you because you are the expert?
> >I call BS.
> >
> >--
> >Tom Marchant
> >
> >>
> >>Sent from Yahoo Mail for iPhone
> >>
> >>
> >>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
> mainfr...@bigendiansmalls.com> wrote:
> >>
> >>At the risk of re-kicking the already dead horse:  Bill, you're
> comparing apples and spiders.
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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



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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:

> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>
> >If you either didn’t read or didn’t comprehend the posts I provided, I
> cannot help you.
>
> As I wrote, I read all of the references that you posted.
> Yes, I understood them.
> You misrepresented what they said.
> Now your response is to insult me. That is pathetic.
>
> --
> Tom Marchant
>
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
> >
> >>Mainframes are by design far more secure. For good reason. The exposure
> >>is catastrophic potentially. It’s one of the main reasons why banks rely
> and
> >>stay on it and spend tens of millions for it. I’ve already provided
> numerous
> >>links referencing it.
> >
> >You have provided pitifully little to support your claim that the
> security of
> >mainframes is the reason banks and others stay with them. I have read
> >all of the references that you posted, and most of them list the
> POTENTIAL
> >to secure them as ONE of the reasons why people use mainframes for
> >mission-critical data, but not the main reason.
> >
> >You have over-stated your case.
> >
> >>Add in my criminal justice knowledge along with my computer science
> >>degree and 40 years of experience in IT and security. But don’t let me
> >>dispel your beliefs.
> >
> >So I shoulodn't question you because you are the expert?
> >I call BS.
> >
> >--
> >Tom Marchant
> >
> >>
> >>Sent from Yahoo Mail for iPhone
> >>
> >>
> >>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
> mainfr...@bigendiansmalls.com> wrote:
> >>
> >>At the risk of re-kicking the already dead horse:  Bill, you're
> comparing apples and spiders.
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Ones, not zones.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:54 AM, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

>If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
>help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>
>>Mainframes are by design far more secure. For good reason. The exposure 
>>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>>stay on it and spend tens of millions for it. I’ve already provided numerous 
>>links referencing it.
>
>You have provided pitifully little to support your claim that the security of 
>mainframes is the reason banks and others stay with them. I have read 
>all of the references that you posted, and most of them list the POTENTIAL 
>to secure them as ONE of the reasons why people use mainframes for 
>mission-critical data, but not the main reason.
>
>You have over-stated your case.
>
>>Add in my criminal justice knowledge along with my computer science 
>>degree and 40 years of experience in IT and security. But don’t let me 
>>dispel your beliefs.
>
>So I shoulodn't question you because you are the expert?
>I call BS.
>
>-- 
>Tom Marchant
>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
>> wrote:
>>
>>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>>apples and spiders.  
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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



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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

It’s an absolute fact security is one of the main reasons the mainframe is 
still used in industries that require the best security. You can google it and 
see numerous links. I worked at a bank and can verify. Also at an insurance 
company. I also have extensive criminal justice training as well. Whether it’s 
initial security keeping bad actors out of the platform or the speed with big 
data that enables the analysis of transactions to recognize fraudulent zones.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:54 AM, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

>If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
>help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>
>>Mainframes are by design far more secure. For good reason. The exposure 
>>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>>stay on it and spend tens of millions for it. I’ve already provided numerous 
>>links referencing it.
>
>You have provided pitifully little to support your claim that the security of 
>mainframes is the reason banks and others stay with them. I have read 
>all of the references that you posted, and most of them list the POTENTIAL 
>to secure them as ONE of the reasons why people use mainframes for 
>mission-critical data, but not the main reason.
>
>You have over-stated your case.
>
>>Add in my criminal justice knowledge along with my computer science 
>>degree and 40 years of experience in IT and security. But don’t let me 
>>dispel your beliefs.
>
>So I shoulodn't question you because you are the expert?
>I call BS.
>
>-- 
>Tom Marchant
>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
>> wrote:
>>
>>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>>apples and spiders.  
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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



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

Re: RSUs

2019-05-28 Thread Kurt Quackenbush


On 5/24/2019 11:24 AM, Styles, Andy , ITS zPlatform Services wrote:


I have the SMPGLOG (GLOBAL log), but not the jobs. I'm reluctant to post a 
large amount of SMPLOG output here, but here (hopefully relevant) snippets:

RECEIVE
   ORDER(ORDERSERVER(ORDRINFO)
 CONTENT(RECOMMENDED)
 CLIENT(CLNTINFO)
   )
  .

ORDER ORD00018 HAS BEEN SENT TO THE SERVER AT 
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/.

ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00018-05April2019-08.45.34.407 FOR 
RECEIVE PROCESSING.


Unfortunately the SMPLOG doesn't show us the ASSIGN statements and 
SOURCEIDs that were processed, which is what I was hoping to see in your 
output.



We then received a bunch of PTFs as a result - I can list them if you wish. 
Now, yesterday I noticed that I didn't specify a target zone here. There are 
two target zones in the GLOBAL zone - the previous iteration of this process, 
and a clone of it (which is the one RSU1903 was eventually applied to), so we 
can look across multiple target zones to see if/where a PTF is applied.

When I re-did the RECEIVE ORDER, I added FORTGTZONE, though to me, that should 
have made no difference.


Hmmm... probably FORTGTZONE is not interesting here, but depending on 
other activity in your global and target zones, I wouldn't completely 
rule it out as a factor.



I then ended up with this:

RECEIVE
   ORDER(ORDERSERVER(ORDRINFO)
 CONTENT(RECOMMENDED)
 CLIENT(CLNTINFO)
 FORTGTZONES(TGTD)
   )
  .

ORDER ORD00020 HAS BEEN SENT TO THE SERVER AT 
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/.

ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00020-22May2019-17.19.02.141 FOR 
RECEIVE PROCESSING.

And then received the following fixes:

SYSMOD ENTRY UA98295 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98305 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98317 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98340 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98341 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98707 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98723 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98804 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98845 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98920 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98954 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98965 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99018 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99029 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99050 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99059 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99094 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99149 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99208 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99224 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99278 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99283 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99306 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI60691 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61245 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61642 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61783 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62355 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62458 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62648 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI63041 WAS STORED IN THE GLOBAL ZONE.


Were any of these PTFs also received in the prior RECEIVE ORDER?  And 
Were they applied and accepted, perhaps purging them from the global 
zone prior to the latest RECEIVE ORDER?  Were they assigned the RSU1903 
sourceid in the first, second, or both RECEIVEs?


This last question about when/if RSU1903 was assigned is the important 
one, but I fear you may not know the answer without the SMPRPT output 
for the RECEIVEs.



Now, looking back through the log, I can also see quite a few messages like 
this:

MCS UA98840 WAS DELETED FROM THE SMPPTS LIBRARY.
MCS UA98840 WAS DELETED FROM THE SMPPTS1 LIBRARY.
MCS ENTRY UA98840 WAS STORED IN THE SMPPTS LIBRARY.
SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE.
RECEIVE PROCESSING WAS SUCCESSFUL FOR SYSMOD UA98840.

Which confuses me (not difficult) - why is it already in the SMPPTS dataset? 
Nonetheless, I didn't do a REJECT of anything first, so it was RECEIVEd ok.


The "MCS WAS DELETED..." messages are simply SMP/E making sure there are 
no duplicate PTF members across your SMPPTS and SMPPTS1 data sets.  You 
can ignore these messages.


Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Did you ever work at a bank? I doubt it.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:54 AM, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

>If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
>help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>
>>Mainframes are by design far more secure. For good reason. The exposure 
>>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>>stay on it and spend tens of millions for it. I’ve already provided numerous 
>>links referencing it.
>
>You have provided pitifully little to support your claim that the security of 
>mainframes is the reason banks and others stay with them. I have read 
>all of the references that you posted, and most of them list the POTENTIAL 
>to secure them as ONE of the reasons why people use mainframes for 
>mission-critical data, but not the main reason.
>
>You have over-stated your case.
>
>>Add in my criminal justice knowledge along with my computer science 
>>degree and 40 years of experience in IT and security. But don’t let me 
>>dispel your beliefs.
>
>So I shoulodn't question you because you are the expert?
>I call BS.
>
>-- 
>Tom Marchant
>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
>> wrote:
>>
>>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>>apples and spiders.  
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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



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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread Tom Marchant

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

>If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
>help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>
>>Mainframes are by design far more secure. For good reason. The exposure 
>>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>>stay on it and spend tens of millions for it. I’ve already provided numerous 
>>links referencing it.
>
>You have provided pitifully little to support your claim that the security of 
>mainframes is the reason banks and others stay with them. I have read 
>all of the references that you posted, and most of them list the POTENTIAL 
>to secure them as ONE of the reasons why people use mainframes for 
>mission-critical data, but not the main reason.
>
>You have over-stated your case.
>
>>Add in my criminal justice knowledge along with my computer science 
>>degree and 40 years of experience in IT and security. But don’t let me 
>>dispel your beliefs.
>
>So I shoulodn't question you because you are the expert?
>I call BS.
>
>-- 
>Tom Marchant
>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
>> wrote:
>>
>>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>>apples and spiders.  
>
>--
>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: Fwd: Just how secure are mainframes? | Trevor Eddolls

Exactly 


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:38 AM, Vernooij, Kees (ITOP NM) - KLM 
 wrote:

I would say that, at least for situations 1 to 8, you have gained unintended 
access to the mainframe via an access door that was (too) poorly protected. 
In these cases the mainframe was not the weak point, but the people (again) 
that set up the protection.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lennie Dymoke-Bradshaw
> Sent: 28 May, 2019 15:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> 
> In addition to defining what is "security" we need to define what we mean
> by "hacking". In my previous career at IBM I was asked this many times. At
> that time I preferred to talk of an "attack" on the mainframe, and then
> determine the susceptibility of the system to that attack.
> 
> However, I came up with some situations which could be examined to try and
> get people to define what they mean by "hacking" in this context. The
> questions I asked were the following. I suspect different folks will come
> up with different answers for some of these questions.  You will soon see,
> as well where the fault/blame/responsibility for security lies for each of
> these situations. Anyway, here are the questions I used.
> 
> 1. If I use a colleague's userid and password without his knowledge, is
> this hacking? Have I hacked the mainframe?
> 
> 2. If I trick a mainframe user into divulging his password, and then use
> this to access data, is this hacking? Have I hacked the mainframe?
> 
> 3. If I use access I have been given in a manner which it was not designed
> to be used for (e.g. access to a break-glass userid for recovery), and so
> gain access to private data, am I hacking? Have I hacked the mainframe?
> 
> 4. If I am a systems programmer and have legitimate UPDATE access to an
> APF authorised library, and use it to gain RACF SPECIAL, is this hacking?
> Have I hacked the mainframe?
> 
> 5. If I have a basic userid on a z/OS system, and then discover that I can
> make use of unprotected CSA storage created by a badly coded 3rd party
> product which uses it for inter-address space communications, and I use
> this to gain access to data I would not normally have access to, is this
> hacking? Have I hacked the mainframe?
> 
> 6. If I discover a bad z/OS configuration option has been used (e.g.
> IDCAMS in AUTHTSF), and I exploit it to gain access in key zero and then
> grant my userid RACF SPECIAL, am I hacking? Have I hacked the mainframe?
> 
> 7. If I gain access to a DB2 userid because its password is hard-coded on
> a distributed server, and then use it to gain access to DB2 on z/OS, am I
> hacking? Have I hacked the mainframe?
> 
> 8. If I discover a z/OS integrity exposure, which should be covered by the
> z/OS Statement of Integrity, and then make use of it, instead of reporting
> it to IBM to be resolved, am I hacking? Have I hacked the mainframe?
> 
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: 28 May 2019 08:13
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Fwd: Just how secure are mainframes? | Trevor
> Eddolls
> 
> Well, it seems 'security' needs to be defined here.
> Probably like in my answer to Bill: difficulty * result.
> 
> You are secure enough if you can prevent a hacker to steal $100,= by
> delaying him for 1 hour.
> You are not if you can delay him for only one hour to steal a million.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of R.S.
> > Sent: 28 May, 2019 9:00
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> >
> > W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze:
> > > At the risk of re-kicking the already dead horse:  Bill, you're
> > comparing apples and spiders.
> > >
> > > Are there fewer mainframe 'hacks'? Yep.  There are also
> > > exponentially
> > fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a
> > few thousand mainframes compared to 2.5 BILLION users of
> > Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> > 250,000 - 500,000x more installs of those OS's.  And they are freely
> > available for literally anyone to poke at.
> > >
> > > What you're arguing "Because Windows gets hacked daily, and
> > > mainframes
> > are never in the news as have being hacked - means that mainframes are
> > more secure .. more 'hack-proof'"  Is like saying that:
> > >
> > > -- Homes in Toronto are more hurricane-proof because fewer of them
> > > are
> > destroyed than in Key West.
> > > OR
> > > -- Babies are bette

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

I would say that, at least for situations 1 to 8, you have gained unintended 
access to the mainframe via an access door that was (too) poorly protected. 
In these cases the mainframe was not the weak point, but the people (again) 
that set up the protection.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lennie Dymoke-Bradshaw
> Sent: 28 May, 2019 15:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> 
> In addition to defining what is "security" we need to define what we mean
> by "hacking". In my previous career at IBM I was asked this many times. At
> that time I preferred to talk of an "attack" on the mainframe, and then
> determine the susceptibility of the system to that attack.
> 
> However, I came up with some situations which could be examined to try and
> get people to define what they mean by "hacking" in this context. The
> questions I asked were the following. I suspect different folks will come
> up with different answers for some of these questions.  You will soon see,
> as well where the fault/blame/responsibility for security lies for each of
> these situations. Anyway, here are the questions I used.
> 
> 1. If I use a colleague's userid and password without his knowledge, is
> this hacking? Have I hacked the mainframe?
> 
> 2. If I trick a mainframe user into divulging his password, and then use
> this to access data, is this hacking? Have I hacked the mainframe?
> 
> 3. If I use access I have been given in a manner which it was not designed
> to be used for (e.g. access to a break-glass userid for recovery), and so
> gain access to private data, am I hacking? Have I hacked the mainframe?
> 
> 4. If I am a systems programmer and have legitimate UPDATE access to an
> APF authorised library, and use it to gain RACF SPECIAL, is this hacking?
> Have I hacked the mainframe?
> 
> 5. If I have a basic userid on a z/OS system, and then discover that I can
> make use of unprotected CSA storage created by a badly coded 3rd party
> product which uses it for inter-address space communications, and I use
> this to gain access to data I would not normally have access to, is this
> hacking? Have I hacked the mainframe?
> 
> 6. If I discover a bad z/OS configuration option has been used (e.g.
> IDCAMS in AUTHTSF), and I exploit it to gain access in key zero and then
> grant my userid RACF SPECIAL, am I hacking? Have I hacked the mainframe?
> 
> 7. If I gain access to a DB2 userid because its password is hard-coded on
> a distributed server, and then use it to gain access to DB2 on z/OS, am I
> hacking? Have I hacked the mainframe?
> 
> 8. If I discover a z/OS integrity exposure, which should be covered by the
> z/OS Statement of Integrity, and then make use of it, instead of reporting
> it to IBM to be resolved, am I hacking? Have I hacked the mainframe?
> 
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: 28 May 2019 08:13
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Fwd: Just how secure are mainframes? | Trevor
> Eddolls
> 
> Well, it seems 'security' needs to be defined here.
> Probably like in my answer to Bill: difficulty * result.
> 
> You are secure enough if you can prevent a hacker to steal $100,= by
> delaying him for 1 hour.
> You are not if you can delay him for only one hour to steal a million.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of R.S.
> > Sent: 28 May, 2019 9:00
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> >
> > W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze:
> > > At the risk of re-kicking the already dead horse:  Bill, you're
> > comparing apples and spiders.
> > >
> > > Are there fewer mainframe 'hacks'? Yep.  There are also
> > > exponentially
> > fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a
> > few thousand mainframes compared to 2.5 BILLION users of
> > Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> > 250,000 - 500,000x more installs of those OS's.  And they are freely
> > available for literally anyone to poke at.
> > >
> > > What you're arguing "Because Windows gets hacked daily, and
> > > mainframes
> > are never in the news as have being hacked - means that mainframes are
> > more secure .. more 'hack-proof'"  Is like saying that:
> > >
> > > -- Homes in Toronto are more hurricane-proof because fewer of them
> > > are
> > destroyed than in Key West.
> > > OR
> > > -- Babies are better drivers than their parents, because their
> > > parents
> > get in accidents every day.
> > > OR
> > > -- People in Gre

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
help you.

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:

>Mainframes are by design far more secure. For good reason. The exposure 
>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>stay on it and spend tens of millions for it. I’ve already provided numerous 
>links referencing it.

You have provided pitifully little to support your claim that the security of 
mainframes is the reason banks and others stay with them. I have read 
all of the references that you posted, and most of them list the POTENTIAL 
to secure them as ONE of the reasons why people use mainframes for 
mission-critical data, but not the main reason.

You have over-stated your case.

>Add in my criminal justice knowledge along with my computer science 
>degree and 40 years of experience in IT and security. But don’t let me 
>dispel your beliefs.

So I shoulodn't question you because you are the expert?
I call BS.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
> wrote:
>
>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>apples and spiders.  

--
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: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread Tom Marchant

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:

>Mainframes are by design far more secure. For good reason. The exposure 
>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>stay on it and spend tens of millions for it. I’ve already provided numerous 
>links referencing it.

You have provided pitifully little to support your claim that the security of 
mainframes is the reason banks and others stay with them. I have read 
all of the references that you posted, and most of them list the POTENTIAL 
to secure them as ONE of the reasons why people use mainframes for 
mission-critical data, but not the main reason.

You have over-stated your case.

>Add in my criminal justice knowledge along with my computer science 
>degree and 40 years of experience in IT and security. But don’t let me 
>dispel your beliefs.

So I shoulodn't question you because you are the expert?
I call BS.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
> wrote:
>
>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>apples and spiders.  

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread Lennie Dymoke-Bradshaw

In addition to defining what is "security" we need to define what we mean by 
"hacking". In my previous career at IBM I was asked this many times. At that 
time I preferred to talk of an "attack" on the mainframe, and then determine 
the susceptibility of the system to that attack.

However, I came up with some situations which could be examined to try and get 
people to define what they mean by "hacking" in this context. The questions I 
asked were the following. I suspect different folks will come up with different 
answers for some of these questions.  You will soon see, as well where the 
fault/blame/responsibility for security lies for each of these situations. 
Anyway, here are the questions I used.

1. If I use a colleague's userid and password without his knowledge, is this 
hacking? Have I hacked the mainframe?

2. If I trick a mainframe user into divulging his password, and then use this 
to access data, is this hacking? Have I hacked the mainframe?

3. If I use access I have been given in a manner which it was not designed to 
be used for (e.g. access to a break-glass userid for recovery), and so gain 
access to private data, am I hacking? Have I hacked the mainframe?

4. If I am a systems programmer and have legitimate UPDATE access to an APF 
authorised library, and use it to gain RACF SPECIAL, is this hacking? Have I 
hacked the mainframe?

5. If I have a basic userid on a z/OS system, and then discover that I can make 
use of unprotected CSA storage created by a badly coded 3rd party product which 
uses it for inter-address space communications, and I use this to gain access 
to data I would not normally have access to, is this hacking? Have I hacked the 
mainframe?

6. If I discover a bad z/OS configuration option has been used (e.g. IDCAMS in 
AUTHTSF), and I exploit it to gain access in key zero and then grant my userid 
RACF SPECIAL, am I hacking? Have I hacked the mainframe?

7. If I gain access to a DB2 userid because its password is hard-coded on a 
distributed server, and then use it to gain access to DB2 on z/OS, am I 
hacking? Have I hacked the mainframe?

8. If I discover a z/OS integrity exposure, which should be covered by the z/OS 
Statement of Integrity, and then make use of it, instead of reporting it to IBM 
to be resolved, am I hacking? Have I hacked the mainframe?

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: 28 May 2019 08:13
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Fwd: Just how secure are mainframes? | Trevor Eddolls

Well, it seems 'security' needs to be defined here.
Probably like in my answer to Bill: difficulty * result.

You are secure enough if you can prevent a hacker to steal $100,= by delaying 
him for 1 hour.
You are not if you can delay him for only one hour to steal a million.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of R.S.
> Sent: 28 May, 2019 9:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> 
> W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze:
> > At the risk of re-kicking the already dead horse:  Bill, you're
> comparing apples and spiders.
> >
> > Are there fewer mainframe 'hacks'? Yep.  There are also 
> > exponentially
> fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a 
> few thousand mainframes compared to 2.5 BILLION users of 
> Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> 250,000 - 500,000x more installs of those OS's.  And they are freely 
> available for literally anyone to poke at.
> >
> > What you're arguing "Because Windows gets hacked daily, and 
> > mainframes
> are never in the news as have being hacked - means that mainframes are 
> more secure .. more 'hack-proof'"  Is like saying that:
> >
> > -- Homes in Toronto are more hurricane-proof because fewer of them 
> > are
> destroyed than in Key West.
> > OR
> > -- Babies are better drivers than their parents, because their 
> > parents
> get in accidents every day.
> > OR
> > -- People in Greenland are less susceptible to cancer because fewer
> people die of it than do in the US.
> >
> > For years people thought Macs were less susceptible to viruses than
> their Windows counterparts... because?  They never read about Mac hacks.
> The reality?  There were way fewer Macs.  Now?  Still much less 
> marketshare than Windows, but lots of Mac hacks/malware out there 
> because they have more than doubled their market share in 6-8 years.
> 
> You criticize demagoguery using demagoguery.
> It's not that mainframe were not hacked just because nobody tried. Or 
> to few hackers tried.
> And not every adult is equally good driver.
> A solid safe can be opened, but carton box ca be open

Re: ISPF and newer COBOL keywords

2019-05-28 Thread Timothy Sipples

A quick update: Mike Stayton alerted me that ISPF was updated about 12
months ago with HILITE-related support for Enterprise COBOL through and
including Enterprise COBOL 6.2. Please refer to the PTF(s) for APAR
OA55117.

It'd be great to read reports of experiences with this ISPF update.

Thanks, Mike.


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


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

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

Re: ISPF temporary files

2019-05-28 Thread Jordi Bornay

Hi Gadi,

an example


SG
WHEN (&MGMTCLAS EQ TS*) 
 SET &STORGRP = 'SGVJTS'
-
SC
FILTLIST FTS  INCLUDE( xx.ISPF.** )

WHEN (&FTS) 
 DO 
  SET &STORCLAS = 'CRWS'
  EXIT  
 END  

WHEN (&DSTYPEEQ   'TEMP') 
 DO   
  SET &STORCLAS = 'CRWS'  
  EXIT
 END  

..ETC   

-
MC
FILTLIST FTS   INCLUDE( xxx.ISPF.**)
 WHEN (&FTS)/**/   
  DO/**/   
   SELECT   /**/   
WHEN (&DSNEQ &FTS00NLNL)/* CON MC TS00NLNL.   */   
 DO /* BACKUP   =0 COPIAS */   
  SET &MGMTCLAS = 'TS00NLNL'/* EXPIR.   =  NOLIMIT*/   
  EXIT  /* NIVEL-0  =  NOLIMIT*/   
 END/**/   
WHEN (&DSNEQ &FTS02A5NL)/* CON MC TS02A5NL.   */   
 DO /* BACKUP   =2 COPIAS */   
  SET &MGMTCLAS = 'TS02A5NL'/* EXPIR.   =  150 DIAS   */   
  EXIT  /* NIVEL-0  =  NOLIMIT*/   
 END/**/   
WHEN (&DSNEQ &FTS02A510)/* CON MC TS02A510.   */   
 DO /* BACKUP   =2 COPIAS */   
  SET &MGMTCLAS = 'TS02A510'/* EXPIR.   =  150 DIAS   */   
  EXIT  /* NIVEL-0  =   10 DIAS   */   
 END/**/   
WHEN (&DSORG  EQ 'PO')  /* CON MC TS03NL33.   */   
 DO /* BACKUP   =3 COPIAS */   
  SET &MGMTCLAS = 'TS03NL33'/* EXPIR.   =  NOLIMIT*/   
  EXIT  /* NIVEL-0  =   33 DIAS   */   
 END/**/   
WHEN (&DSNEQ &FTS0007NL)/* CON MC TS0007NL.   */   
 DO /* BACKUP   =0 COPIAS */   
  SET &MGMTCLAS = 'TS0007NL'/* EXPIR.   =7 DIAS   */   
  EXIT  /* NIVEL-0  =  NOLIMIT*/   
 END/**/   
WHEN (&DSNEQ &FTS014003)/* CON MC TS014003.   */   
 DO /* BACKUP   =1 COPIAS */   
  SET &MGMTCLAS = 'TS014003'/* EXPIR.   =   40 DIAS   */   
  EXIT  /* NIVEL-0  =3 DIAS   */   
 END/**/   

... etc, etc

Jordi Bornay

T-Systems Iberia
A Deutsche Telekom Group Company
Cloud & Infraestructure Services - Delivery Shared Infraestructure
MSY Storage & Backup Administration




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

Re: ISPF temporary files

2019-05-28 Thread David Spiegel

Hi Gadi,
You can modify ISPF settings via ISPCCONF:
Set USE_PDFCUNIT_FOR_TEMP_ISPF_DATA_SETS to Yes
and
PDF_DEFAULT_UNIT to the (fake or real) UNIT that your ACS Routine will key on 
(e.g. ISPFTEMP).

In your ACS Routine:

IF &UNIT = 'ISPFTEMP'

   THEN DO
   SET &STORCLAS = 'ISPFTDSN'
   /* WRITE 'Temporary ISPF Storage' */
   EXIT
END

Hatzlachah!

Regards,
David


On 2019-05-28 04:31, Gadi Ben-Avi wrote:

Hi,
How do I tell ISPF where to define its temporary files, for example 
USERID.ISP46056.SPFTEMP0.CNTL?

Thanks

Gadi


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

2019-05-28 Thread Kurt Quackenbush


On 5/24/2019 10:19 AM, Jousma, David wrote:

Bob,  I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER 
Process first uploads an inventory to IBM.  Then the order process only sends 
you what you don’t have.


In my opinion a more complete answer is not necessary.  Your posts 
describe the processing of SMP/E RECEIVE ORDER well, thank you Dave.


If Bob still has questions or comments, please restate and clarify them.

Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

Re: ISPF temporary files

By DDNAME or DSNAME pattern.

Kees


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gadi Ben-Avi
> Sent: 28 May, 2019 13:52
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPF temporary files
> 
> They are SMS managed, but they are going to the wrong storage group.
> How do I identify these files in an ACS routing?
> 
> Gadi
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Tuesday, May 28, 2019 2:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPF temporary files
> 
> Well, if you are not SMS managed yet... I'd get SMS managed ASAP.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Brian Fraser
> > Sent: 28 May, 2019 12:34
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: ISPF temporary files
> >
> > If they are not SMS managed I'd make them SMS managed.
> >
> > Brian
> >
> > On Tue, 28 May 2019 at 16:37, Vernooij, Kees (ITOP NM) - KLM <
> > kees.verno...@klm.com> wrote:
> >
> > > I would do it in the ACS routines, if they are SMS managed.
> > >
> > > Kees.
> > >
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On
> > > > Behalf Of Gadi Ben-Avi
> > > > Sent: 28 May, 2019 10:31
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: ISPF temporary files
> > > >
> > > > Hi,
> > > > How do I tell ISPF where to define its temporary files, for
> > > > example USERID.ISP46056.SPFTEMP0.CNTL?
> > > >
> > > > Thanks
> > > >
> > > > Gadi
> > > >
> > > >
> > > > --
> > > >  For IBM-MAIN subscribe / signoff / archive access
> > > > instructions, send email to lists...@listserv.ua.edu with the
> > > > message: INFO IBM-MAIN
> > > 
> > > For information, services and offers, please visit our web site:
> > > http://www.klm.com. This e-mail and any attachment may contain
> > > confidential and privileged material intended for the addressee
> > > only. If you are not the addressee, you are notified that no part of
> > > the e-mail
> > or
> > > any attachment may be disclosed, copied or distributed, and that any
> > other
> > > action related to this e-mail or attachment is strictly prohibited,
> > > and
> > may
> > > be unlawful. If you have received this e-mail by error, please
> > > notify
> > the
> > > sender immediately by return e-mail, and delete this message.
> > >
> > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
> > > and/or
> > its
> > > employees shall not be liable for the incorrect or incomplete
> > transmission
> > > of this e-mail or any attachments, nor responsible for any delay in
> > receipt.
> > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > > Dutch
> > > Airlines) is registered in Amstelveen, The Netherlands, with
> > > registered number 33014286
> > > 
> > >
> > > 
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and
> may be unlawful. If you have received this e-mail by error, please notify
> the sender immediately by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --

Re: ISPF temporary files

2019-05-28 Thread Gadi Ben-Avi

They are SMS managed, but they are going to the wrong storage group.
How do I identify these files in an ACS routing?

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Tuesday, May 28, 2019 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF temporary files

Well, if you are not SMS managed yet... I'd get SMS managed ASAP.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Brian Fraser
> Sent: 28 May, 2019 12:34
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPF temporary files
> 
> If they are not SMS managed I'd make them SMS managed.
> 
> Brian
> 
> On Tue, 28 May 2019 at 16:37, Vernooij, Kees (ITOP NM) - KLM < 
> kees.verno...@klm.com> wrote:
> 
> > I would do it in the ACS routines, if they are SMS managed.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of Gadi Ben-Avi
> > > Sent: 28 May, 2019 10:31
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: ISPF temporary files
> > >
> > > Hi,
> > > How do I tell ISPF where to define its temporary files, for 
> > > example USERID.ISP46056.SPFTEMP0.CNTL?
> > >
> > > Thanks
> > >
> > > Gadi
> > >
> > >
> > > --
> > >  For IBM-MAIN subscribe / signoff / archive access 
> > > instructions, send email to lists...@listserv.ua.edu with the 
> > > message: INFO IBM-MAIN
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain 
> > confidential and privileged material intended for the addressee 
> > only. If you are not the addressee, you are notified that no part of 
> > the e-mail
> or
> > any attachment may be disclosed, copied or distributed, and that any
> other
> > action related to this e-mail or attachment is strictly prohibited, 
> > and
> may
> > be unlawful. If you have received this e-mail by error, please 
> > notify
> the
> > sender immediately by return e-mail, and delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries 
> > and/or
> its
> > employees shall not be liable for the incorrect or incomplete
> transmission
> > of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> > Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with 
> > registered number 33014286
> > 
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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



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

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

Re: ISPF temporary files

Well, if you are not SMS managed yet... I'd get SMS managed ASAP.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Fraser
> Sent: 28 May, 2019 12:34
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPF temporary files
> 
> If they are not SMS managed I'd make them SMS managed.
> 
> Brian
> 
> On Tue, 28 May 2019 at 16:37, Vernooij, Kees (ITOP NM) - KLM <
> kees.verno...@klm.com> wrote:
> 
> > I would do it in the ACS routines, if they are SMS managed.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of Gadi Ben-Avi
> > > Sent: 28 May, 2019 10:31
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: ISPF temporary files
> > >
> > > Hi,
> > > How do I tell ISPF where to define its temporary files, for example
> > > USERID.ISP46056.SPFTEMP0.CNTL?
> > >
> > > Thanks
> > >
> > > Gadi
> > >
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only. If
> > you are not the addressee, you are notified that no part of the e-mail
> or
> > any attachment may be disclosed, copied or distributed, and that any
> other
> > action related to this e-mail or attachment is strictly prohibited, and
> may
> > be unlawful. If you have received this e-mail by error, please notify
> the
> > sender immediately by return e-mail, and delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> its
> > employees shall not be liable for the incorrect or incomplete
> transmission
> > of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with registered
> > number 33014286
> > 
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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



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

Re: ISPF temporary files

2019-05-28 Thread Brian Fraser

If they are not SMS managed I'd make them SMS managed.

Brian

On Tue, 28 May 2019 at 16:37, Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:

> I would do it in the ACS routines, if they are SMS managed.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Gadi Ben-Avi
> > Sent: 28 May, 2019 10:31
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: ISPF temporary files
> >
> > Hi,
> > How do I tell ISPF where to define its temporary files, for example
> > USERID.ISP46056.SPFTEMP0.CNTL?
> >
> > Thanks
> >
> > Gadi
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: ISPF temporary files

I would do it in the ACS routines, if they are SMS managed.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gadi Ben-Avi
> Sent: 28 May, 2019 10:31
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ISPF temporary files
> 
> Hi,
> How do I tell ISPF where to define its temporary files, for example
> USERID.ISP46056.SPFTEMP0.CNTL?
> 
> Thanks
> 
> Gadi
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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


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

ISPF temporary files

2019-05-28 Thread Gadi Ben-Avi

Hi,
How do I tell ISPF where to define its temporary files, for example 
USERID.ISP46056.SPFTEMP0.CNTL?

Thanks

Gadi


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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Well, it seems 'security' needs to be defined here.
Probably like in my answer to Bill: difficulty * result.

You are secure enough if you can prevent a hacker to steal $100,= by delaying 
him for 1 hour.
You are not if you can delay him for only one hour to steal a million.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: 28 May, 2019 9:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> 
> W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze:
> > At the risk of re-kicking the already dead horse:  Bill, you're
> comparing apples and spiders.
> >
> > Are there fewer mainframe 'hacks'? Yep.  There are also exponentially
> fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a few
> thousand mainframes compared to 2.5 BILLION users of
> Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> 250,000 - 500,000x more installs of those OS's.  And they are freely
> available for literally anyone to poke at.
> >
> > What you're arguing "Because Windows gets hacked daily, and mainframes
> are never in the news as have being hacked - means that mainframes are
> more secure .. more 'hack-proof'"  Is like saying that:
> >
> > -- Homes in Toronto are more hurricane-proof because fewer of them are
> destroyed than in Key West.
> > OR
> > -- Babies are better drivers than their parents, because their parents
> get in accidents every day.
> > OR
> > -- People in Greenland are less susceptible to cancer because fewer
> people die of it than do in the US.
> >
> > For years people thought Macs were less susceptible to viruses than
> their Windows counterparts... because?  They never read about Mac hacks.
> The reality?  There were way fewer Macs.  Now?  Still much less
> marketshare than Windows, but lots of Mac hacks/malware out there because
> they have more than doubled their market share in 6-8 years.
> 
> You criticize demagoguery using demagoguery.
> It's not that mainframe were not hacked just because nobody tried. Or to
> few hackers tried.
> And not every adult is equally good driver.
> A solid safe can be opened, but carton box ca be opened more easily.
> Even if there are much more carton boxes than safes.
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> ==
> 
> Jeśli nie jesteś adresatem tej wiadomości:
> 
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
> 
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
> Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS
> 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości)
> według stanu na 01.01.2018 r. wynosi 169.248.488 złotych.
> 
> If you are not the addressee of this message:
> 
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
> 
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169,248,488 as at 1 January 2018.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be l

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls