Re: master JCL

[Bruce Hewson]

Skip,

A long time ago I read :-

Building a Self-Documenting MVS/ESA System
by Mark S. Hahn
Reprinted with permission. ©1992 Candle Corp.

Can't see to find it via Google now, but Dave Alcock has refenrce to it:-

http://planetmvs.com/mvstips/#SELFDOC



On Wed, 29 May 2019 23:36:59 +, Jesse 1 Robinson  
wrote:

>Well, I'll be hornswoggled. With a little digging I found in 
>
>   
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/ieae200314.htm
>
>that the parm in IEASYSxx is MSTRJCL=(xx[,L]) along with the advice to 
>'use...L only for debugging purposes'. We don't seem to have 'L' on any 
>system.   
>
>.
>.
>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

I have coded my systems this way since then.

Regards
Bruce Hewson

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

[Jesse 1 Robinson]

Before we moved to parallel sysplex in the 90s, we had only a few real-hardware 
CTC devices with ragamuffin unit addresses assigned haphazardly over the years. 
With sysplex, we were advised by our top gun CE that shops with a greatly 
enlarged array of EMIF CTCs were losing control of their configuration. So we 
instituted a naming convention whereby each CTC unit address is constructed 
according to a pattern involving CEC and LPAR number. There have been some 
SHARE sessions on this as well as Redbook discussions. The thing is, if you 
want to move in this direction, you should do it from the get-go.   

.
.
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 
Parwez Hamid
Sent: Tuesday, May 28, 2019 8:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CTC (FCTC) usage

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

Re: master JCL

[Jesse 1 Robinson]

Well, I'll be hornswoggled. With a little digging I found in 

   
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/ieae200314.htm

that the parm in IEASYSxx is MSTRJCL=(xx[,L]) along with the advice to 'use...L 
only for debugging purposes'. We don't seem to have 'L' on any system.   

.
.
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 
David Spiegel
Sent: Wednesday, May 29, 2019 4:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: master JCL

Hi Skip,
This is a SYSLOG excerpt.

IEE252I MEMBER MSTJCL00 FOUND IN ADCD.Z23A.PARMLIB .
.
.
IEFJ200I MASTER SCHEDULER JCL FOR THIS IPL TAKEN FROM MEMBER MSTJCL00 OF
  PARMLIB
IEF196I 1 //MSTJCL00 JOB MSGLEVEL=(1,1),TIME=1440 IEF196I 2 //  
   EXEC PGM=IEEMB860,DPRTY=(15,15) IEF196I 3 //STCINRDR DD 
SYSOUT=(A,INTRDR) IEF196I 4 //TSOINRDR DD SYSOUT=(A,INTRDR) IEF196I 
    5 //IEFPDSI  DD DSN=USER.&SYSVER..PROCLIB,DISP=SHR
IEF196I   IEFC653I SUBSTITUTION JCL - DSN=USER.Z23A.PROCLIB, IEF196I 
DISP=SHR IEF196I 6 // DD DSN=FEU.&SYSVER..PROCLIB,DISP=SHR 
IEF196I   IEFC653I SUBSTITUTION JCL - DSN=FEU.Z23A.PROCLIB, IEF196I 
DISP=SHR IEF196I 7 // DD DSN=ADCD.&SYSVER..PROCLIB,DISP=SHR
IEF196I   IEFC653I SUBSTITUTION JCL - DSN=ADCD.Z23A.PROCLIB, IEF196I 
DISP=SHR IEF196I 8 // DD DSN=SYS1.PROCLIB,DISP=SHR IEF196I  
   9 //SYSUADS  DD DSN=SYS1.UADS,DISP=SHR IEF196I    10 //SYSLBC   DD 
DSN=SYS1.BRODCAST,DISP=SHR IEF196I    11 //IEFPARM DD 
DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3CFG1,
IEF196I   // DSN=USER.Z23A.PARMLIB IEF196I    12 //    DD 
DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3CFG1,
IEF196I   // DSN=FEU.Z23A.PARMLIB IEF196I    13 //    DD 
DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3SYS1,
IEF196I   // DSN=ADCD.Z23A.PARMLIB IEF196I    14 //    DD 
DISP=SHR, IEF196I   // DSN=SYS1.PARMLIB IEF196I   //* LOADxx 
parmlibs put in MSTRJCL concatenation IEF403I MSTJCL00 - STARTED - TIME=12.38.58

Regards,
David

On 2019-05-29 18:52, Jesse 1 Robinson wrote:
> For a reeealy lonng time MVS has supported member MSTJCLxx in 
> PARMLIB for master JCL. As for finding the content of MSTJCLxx at NIP for the 
> current IPL, I'm at a loss. Does not seem to be captured in operlog.
>
> .
> .
> 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 Pommier, Rex
> Sent: Wednesday, May 29, 2019 3:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):master JCL
>
> Hello listers,
>
> I'm apparently having a case of brain-drain.  Is there an easy way to display 
> the currently used master JCL?  I know I can look at LINKLIB and PARMLIB and 
> see what's there, but is there a way of displaying what's actually running?  
> I thought at one point in time I could see it in Omegamon or someplace.  In 
> this case, google was not my friend.  :-(  Any assistance would be greatly 
> appreciated.
>
> TIA,
>
> Rex


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

Re: master JCL

[David Spiegel]

Hi Skip,
This is a SYSLOG excerpt.

IEE252I MEMBER MSTJCL00 FOUND IN ADCD.Z23A.PARMLIB
.
.
.
IEFJ200I MASTER SCHEDULER JCL FOR THIS IPL TAKEN FROM MEMBER MSTJCL00 OF
  PARMLIB
IEF196I 1 //MSTJCL00 JOB MSGLEVEL=(1,1),TIME=1440
IEF196I 2 // EXEC PGM=IEEMB860,DPRTY=(15,15)
IEF196I 3 //STCINRDR DD SYSOUT=(A,INTRDR)
IEF196I 4 //TSOINRDR DD SYSOUT=(A,INTRDR)
IEF196I 5 //IEFPDSI  DD DSN=USER.&SYSVER..PROCLIB,DISP=SHR
IEF196I   IEFC653I SUBSTITUTION JCL - DSN=USER.Z23A.PROCLIB,
IEF196I DISP=SHR
IEF196I 6 // DD DSN=FEU.&SYSVER..PROCLIB,DISP=SHR
IEF196I   IEFC653I SUBSTITUTION JCL - DSN=FEU.Z23A.PROCLIB,
IEF196I DISP=SHR
IEF196I 7 // DD DSN=ADCD.&SYSVER..PROCLIB,DISP=SHR
IEF196I   IEFC653I SUBSTITUTION JCL - DSN=ADCD.Z23A.PROCLIB,
IEF196I DISP=SHR
IEF196I 8 // DD DSN=SYS1.PROCLIB,DISP=SHR
IEF196I 9 //SYSUADS  DD DSN=SYS1.UADS,DISP=SHR
IEF196I    10 //SYSLBC   DD DSN=SYS1.BRODCAST,DISP=SHR
IEF196I    11 //IEFPARM DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3CFG1,
IEF196I   // DSN=USER.Z23A.PARMLIB
IEF196I    12 //    DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3CFG1,
IEF196I   // DSN=FEU.Z23A.PARMLIB
IEF196I    13 //    DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3SYS1,
IEF196I   // DSN=ADCD.Z23A.PARMLIB
IEF196I    14 //    DD DISP=SHR,
IEF196I   // DSN=SYS1.PARMLIB
IEF196I   //* LOADxx parmlibs put in MSTRJCL concatenation
IEF403I MSTJCL00 - STARTED - TIME=12.38.58

Regards,
David

On 2019-05-29 18:52, Jesse 1 Robinson wrote:
> For a reeealy lonng time MVS has supported member MSTJCLxx in 
> PARMLIB for master JCL. As for finding the content of MSTJCLxx at NIP for the 
> current IPL, I'm at a loss. Does not seem to be captured in operlog.
>
> .
> .
> 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 
> Pommier, Rex
> Sent: Wednesday, May 29, 2019 3:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):master JCL
>
> Hello listers,
>
> I'm apparently having a case of brain-drain.  Is there an easy way to display 
> the currently used master JCL?  I know I can look at LINKLIB and PARMLIB and 
> see what's there, but is there a way of displaying what's actually running?  
> I thought at one point in time I could see it in Omegamon or someplace.  In 
> this case, google was not my friend.  :-(  Any assistance would be greatly 
> appreciated.
>
> TIA,
>
> Rex
>
>
> --
> 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

[Jesse 1 Robinson]

The advertised virtue of RSU is that it represents a well-defined bundle of 
fixes that have been tested together in 'many' shops. The idea of tacking on an 
RSU label to some other fix after the bundle has shipped would seem to violate 
the definition and compromise its value. I think we agree that it ought not to 
happen.   

.
.
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 
Kurt Quackenbush
Sent: Wednesday, May 29, 2019 5:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RSUs

On 5/29/2019 3:57 AM, Styles, Andy , ITS zPlatform Services wrote:

>> Did you really get more PTFs assigned RSU1903 the second time?  Or 
>> did you simply get more PTFs?  Let me explain:
> 
> I believe we received new PTFs - with RSU1903 being assigned to them at the 
> same time. That's the behaviour I'm querying - and I think you agree - once 
> IBM has announced RSU1903, there should have been no further PTFs with that 
> RSU, whether I specify RECOMMENDED or ALL.
> 
>> 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.
> 
> I understand the HIPER/PE fixes, but they surely should not be assigned 
> RSU1903 after the publish date?

Correct.

>> 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.
> 
> Well, we're coming up to another RSU date in the next few days. I can attempt 
> to repeat this, and see what happens.

Fair enough.  It will be helpful to keep track of changes to your SMP/E 
environment between your two RECEIVE ORDER jobs, and please be sure to use the 
same RECEIVE ORDER command.  For example, either use FORTGTZONES in both or not 
at all.  My preference is not at all.

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

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

Re: master JCL

[Jesse 1 Robinson]

For a reeealy lonng time MVS has supported member MSTJCLxx in 
PARMLIB for master JCL. As for finding the content of MSTJCLxx at NIP for the 
current IPL, I'm at a loss. Does not seem to be captured in operlog. 

.
.
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 
Pommier, Rex
Sent: Wednesday, May 29, 2019 3:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):master JCL

Hello listers,

I'm apparently having a case of brain-drain.  Is there an easy way to display 
the currently used master JCL?  I know I can look at LINKLIB and PARMLIB and 
see what's there, but is there a way of displaying what's actually running?  I 
thought at one point in time I could see it in Omegamon or someplace.  In this 
case, google was not my friend.  :-(  Any assistance would be greatly 
appreciated.

TIA,

Rex


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

master JCL

[Pommier, Rex]

Hello listers,

I'm apparently having a case of brain-drain.  Is there an easy way to display 
the currently used master JCL?  I know I can look at LINKLIB and PARMLIB and 
see what's there, but is there a way of displaying what's actually running?  I 
thought at one point in time I could see it in Omegamon or someplace.  In this 
case, google was not my friend.  :-(  Any assistance would be greatly 
appreciated.

TIA,

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

[Seymour J Metz]

I'm not sure, but I suspect that a job submitted via FTP with an invalid userid 
or password would just disappear. If there is no userid then it would run under 
the userid of the server, so that should not have access to anything sensitive. 
It's not rocket science, but you do have to be careful to define appropriate 
access to the server if you allow job submission.

And, yes, security requires that you have all of the pieces in place, starting 
with management buy-in.

--
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 7:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 

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

[Seymour J Metz]

I don't have enough data to estimate reliable percentages, but I have been at 
two shops where there were user SVCs for getting into key 0, without adequate 
authorization checking, and I was not permitted to remove them. In one case I 
was ordered to not point them out to an auditor. But I see that as a management 
issue rather than a platform issue.


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


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

Radoslaw,

  * I find your posts informative and helpful.
  * I think your English is very understandable
  * I respect your expertise

My initial post was an attempt to get a stalled discussion moving in a
more positive direction. I don't normally post but I felt that mainframe
vulnerability discussions are important for our industry. We, as a
group, need to be able to discuss this issue without resorting to name
calling and childish behavior.

The work that I do includes finding exploitable code based
vulnerabilities running in the wild on z/OS systems. These
vulnerabilities are on mainframe systems in many sectors, including
Financial Institutions and Government. These installations report the
vulnerabilities they find and the ISV's fix them. This is a fact.
Individuals like Bill Johnson can say that I am lying. You can say what
I am saying is FUD - however, neither of these things changes the fact
that I continue to find exploitable code vulnerabilities in z/OS. More
and more people are being exposed to this fact every day.

Based on the work I have done on mainframe code vulnerabilities, I have
concluded that there is a serious problem in our industry. The code that
runs in production in all sectors has poorly written code, that if
exploited, would compromise all data on those systems. Should I just
ignore this problem or try and do something about it? The numbers of
vulnerabilities tells me there are some fundamental problems with how
software development is being done in our industry. The lives of people,
organizations, and governments would be adversely affected if the code
vulnerabilities I have found were not reported and fixed by the vendors.
I have decided that I cannot just stand by and do nothing. The industry
needs to do better. We need to do better.

In response to "What exactly hacking scenario can provide RACF db to the
hacker?" there is a class of vulnerabilities called TRAP DOOR. A TRAP
DOOR vulnerability will branch to an address specified by an
unauthorized user (key 8 problem state not apf authorized) in an
authorized state (PSW KEY 0-7, Supervisor state, JSCBAUTH bit set). This
type of vulnerability usually exists in SVC and PC routines. The address
I pass will have code to get into PSW Key 0 (code is different depending
upon the entry environment). Once in PSW Key 0 I can a) Suppress all SMF
records to hide what I am doing b) Frontend the SAF Router to force all
AUTH and FASTAUTH calls to "allow and no log" (this is for any ESM not
just RACF) c) Copy the ESM data base to another data set d) Create a
reverse shell to send it out to an IP of my choice or e) download to
windows or mac and then attach to email or f) email directly from
mainframe. Please note that once I get to PSW KEY 0 my code is now
working as an extension of z/OS. Whatever z/OS can do my code can do.
With no forensic evidence to see what I did. Or I could create ESM
credentials for Bill Johnson or Radoslaw and let it get logged to you;-)
.  Just as a FYI about 35% of the "several hundred" code vulnerabilities
that I have found are TRAP DOOR vulnerabilities. This represents a
significant percentage of total number of vulnerabilities. This is a
statically viable example.

The following is for Bill Johnson which would have been covered in the demo:

  * The SVC or PC routine can be issued by any user on the mainframe
system.
  * The vulnerable code is executed before any SAF calls are made by the
SVC or PC routine (i.e. - ESM cannot help you)
  * The ESM's:
  o Cannot identify this vulnerable code is on the system
  o Cannot tell you when the vulnerable code is exploited
  o Cannot provide you the information to get vulnerability remediated
  * The payload code does not require an APF authorized library. The
authorization is inherited from the caller (the SVC or PC routine).
  * No extra-ordinary ESM authorities are required - any id would do
  * No extra-ordinary z/Os authorizes are required
  * Suppressing SMF is for all SMF record types not just ESM records
types (i.e. - types 14 and 15)

It would be easier for this discussion if I could just create a CVE in
the national vulnerability data base. Then I could just point you to it
and you could research this for your self. However, that is not how our
industry works. Everything is secret. I used ter

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

[Seymour J Metz]

>  A single TRAP DOOR code vulnerability pierces the veil of integrity and can 
> be used
> to compromise the mainframe. Is this a platform weakness?

An application with a trap door is an application vulnerability. If there is a 
trap door in z/OS itself then that's a platform vulnerability. I'd be willing 
to bet a substantial amount that the majority of penetrations in z/OS are 
application, configuration, personnel and process vulnerabilities rather than 
z/OS vulnerabilities.

> Would you say that the elimination of User Key Common storage is an
> example of a z/OS change to address a mainframe platform weakness

Partially.

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


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

In response to "Mistakes, lack of time, lack of control, lack of skills.
Not a platform weakness." comment: The mainframe platform, z/OS, and
ESM's all rely on integrity to function. A single TRAP DOOR code
vulnerability pierces the veil of integrity and can be used to
compromise the mainframe. Is this a platform weakness? I think so. The
platform relies on all code it runs adhering to certain rules. z/OS
could be changed to better check and enforce those rules.

Would you say that the elimination of User Key Common storage is an
example of a z/OS change to address a mainframe platform weakness? I
think so.

An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:
> That's classical FUD.
> Frightening people.
> "if an exploit", "if job reads you RACF db", "unintended consequences".
> What exactly hacking scenario can provide RACF db to the hacker?
> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user
> attribute, even UPDATE to RACF db. But it's problem of people.
> Mistakes, lack of time, lack of control, lack of skills. Not a
> platform weakness.
>
> It's typical that assurance/lock/gun salesmen tend to talk about
> risks, threats and dangers. They create a vision.
> My English is poor, but I can observe it for two of debaters here.
> It's visible. I don't like social engineering.
>

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

[Savor, Thomas (Alpharetta)]

In securing Mainframe:
 
One thing I've noticed over the years is how a Company will "hide" their 
Mainframe hardware.
The Hardware for me now is in a unmarked Building that looks like a bunker (I'm 
told).  Pretty bad that the location is in my town, however the address is NOT 
circulated.  The first installation that I worked at, it was well known where 
the data center was.  It was no issue to walk into Operations and tour new 
equipment or talk to operators.  Now, forget it.

Thanks,

Tom Savor

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

  ⚠ EXTERNAL MESSAGE – Think Before You Click



My sales favorite was knowing key functionality is vaporware, talking up 
everything the software would do some day. Then being horrified when you 
realize the 'decision makers' are eating it up.  None of them ends up in hell 
when the product doesn't work and the functionality delivery date keeps getting 
pushed forward... but, I got to work with a 3745 until 2009.

Security is no good without PEN testing and auditing from the  Security 
Technical Implementation Guide (STIG) documents.  If you haven't crossed your 
eyes and dotted your teas wait, reverse that.  Your odds of solid security 
can be greatly decreased.

No security by obscurity.
EBCDIC is not a method of encryption.
Stop people from using stupid passwords.  Ideally daily ID's have no elevated 
access, any elevated id must be checked out, activated, with a new password on 
each use.  I realize that would be messy, but if you have better password 
security(pass phrases, excluded words (months of the year, or seasons) or MFA 
going, never mind.  This isn't the paragraph you're looking for...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ray 
Overby
Sent: Wednesday, May 29, 2019 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Mistakes, lack of time, lack of control, lack of skills.
Not a platform weakness." comment: The mainframe platform, z/OS, and ESM's all 
rely on integrity to function. A single TRAP DOOR code vulnerability pierces 
the veil of integrity and can be used to compromise the mainframe. Is this a 
platform weakness? I think so. The platform relies on all code it runs adhering 
to certain rules. z/OS could be changed to better check and enforce those rules.

Would you say that the elimination of User Key Common storage is an example of 
a z/OS change to address a mainframe platform weakness? I think so.

An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:
> That's classical FUD.
> Frightening people.
> "if an exploit", "if job reads you RACF db", "unintended consequences".
> What exactly hacking scenario can provide RACF db to the hacker?
> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user 
> attribute, even UPDATE to RACF db. But it's problem of people.
> Mistakes, lack of time, lack of control, lack of skills. Not a 
> platform weakness.
>
> It's typical that assurance/lock/gun salesmen tend to talk about 
> risks, threats and dangers. They create a vision.
> My English is poor, but I can observe it for two of debaters here.
> It's visible. I don't like social engineering.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DISCLAIMER: This email and any attachments may contain confidential information 
that is intended solely for use by the intended recipient(s). If you are not 
the intended recipient, you are strictly prohibited from disclosing, copying, 
distributing or using any of the information contained in the communication. If 
you received this email in error, please contact the sender by reply email and 
immediately delete the communication.

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

[Schuffenhauer, Mark]

My sales favorite was knowing key functionality is vaporware, talking up 
everything the software would do some day. Then being horrified when you 
realize the 'decision makers' are eating it up.  None of them ends up in hell 
when the product doesn't work and the functionality delivery date keeps getting 
pushed forward... but, I got to work with a 3745 until 2009.

Security is no good without PEN testing and auditing from the  Security 
Technical Implementation Guide (STIG) documents.  If you haven't crossed your 
eyes and dotted your teas wait, reverse that.  Your odds of solid security 
can be greatly decreased.

No security by obscurity.
EBCDIC is not a method of encryption.
Stop people from using stupid passwords.  Ideally daily ID's have no elevated 
access, any elevated id must be checked out, activated, with a new password on 
each use.  I realize that would be messy, but if you have better password 
security(pass phrases, excluded words (months of the year, or seasons) or MFA 
going, never mind.  This isn't the paragraph you're looking for...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ray 
Overby
Sent: Wednesday, May 29, 2019 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Mistakes, lack of time, lack of control, lack of skills.
Not a platform weakness." comment: The mainframe platform, z/OS, and ESM's all 
rely on integrity to function. A single TRAP DOOR code vulnerability pierces 
the veil of integrity and can be used to compromise the mainframe. Is this a 
platform weakness? I think so. The platform relies on all code it runs adhering 
to certain rules. z/OS could be changed to better check and enforce those rules.

Would you say that the elimination of User Key Common storage is an example of 
a z/OS change to address a mainframe platform weakness? I think so.

An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:
> That's classical FUD.
> Frightening people.
> "if an exploit", "if job reads you RACF db", "unintended consequences".
> What exactly hacking scenario can provide RACF db to the hacker?
> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user
> attribute, even UPDATE to RACF db. But it's problem of people.
> Mistakes, lack of time, lack of control, lack of skills. Not a
> platform weakness.
>
> It's typical that assurance/lock/gun salesmen tend to talk about
> risks, threats and dangers. They create a vision.
> My English is poor, but I can observe it for two of debaters here.
> It's visible. I don't like social engineering.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DISCLAIMER: This email and any attachments may contain confidential information 
that is intended solely for use by the intended recipient(s). If you are not 
the intended recipient, you are strictly prohibited from disclosing, copying, 
distributing or using any of the information contained in the communication. If 
you received this email in error, please contact the sender by reply email and 
immediately delete the communication.

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

Re: ADRDSSU

[Nai, Dean]

That worked. Thanks









On 5/29/19, 1:53 PMEDT, "IBM Mainframe Discussion List on behalf of John 
McKown"  
wrote:

> ATTENTION:  This email has originated from outside of the organization. Do 
> not open attachments or click on links unless you recognize the sender and 
> know the content is safe.
>
>On Wed, May 29, 2019 at 12:50 PM Nai, Dean  wrote:
>
>> Hi,
>>
>>Running a DR test. Trying to restore an SMS managed dataset on a floor
>> system that isn't SMS managed. Getting message ADR709E because it's looking
>> for a storage class that doesn't exist on the floor system. Any parameters
>> needed? Any thoughts would be appreciated.
>>
>
>Perhaps BYPASSACS(*)? Or look at the floor system's ACS routines (or ask)
>after trying an "industry standard" of STORCLAS(NONSMS) in the RESTORE
>command.
>
>
>
>>
>>
>> Dean Nai
>>
>>
>>
>>
>> >
>>
>> --
>> 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: ADRDSSU

[John McKown]

On Wed, May 29, 2019 at 12:50 PM Nai, Dean  wrote:

> Hi,
>
>Running a DR test. Trying to restore an SMS managed dataset on a floor
> system that isn't SMS managed. Getting message ADR709E because it's looking
> for a storage class that doesn't exist on the floor system. Any parameters
> needed? Any thoughts would be appreciated.
>

Perhaps BYPASSACS(*)? Or look at the floor system's ACS routines (or ask)
after trying an "industry standard" of STORCLAS(NONSMS) in the RESTORE
command.



>
>
> Dean Nai
>
>
>
>
> >
>
> --
> 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: ADRDSSU

[Allan Staller]

RESTORE 
NSC NMC BPYASSACS(**)


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nai, Dean
Sent: Wednesday, May 29, 2019 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ADRDSSU

Hi,

   Running a DR test. Trying to restore an SMS managed dataset on a floor 
system that isn't SMS managed. Getting message ADR709E because it's looking for 
a storage class that doesn't exist on the floor system. Any parameters needed? 
Any thoughts would be appreciated.


Dean Nai




>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: ADRDSSU

[Lionel Dyck]

On the RESTORE you can add NMC and NSC - no management class and no storage 
class.

Hope that helps (no guarantee as I haven't tried it).


Lionel B. Dyck 
Senior Software Engineer 
21st Century Software
From the Leaders in Data Stewardship™

THIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED, OR OTHER LEGALLY 
PROTECTED INFORMATION. IF YOU ARE NOT THE INTENDED RECIPIENT (EVEN IF THE 
E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY, OR RE-TRANSMIT IT. IF 
YOU HAVE RECEIVED THIS BY MISTAKE PLEASE NOTIFY US BY RETURN E-MAIL, THEN 
DELETE. THANK YOU

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nai, Dean
Sent: Wednesday, May 29, 2019 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ADRDSSU

Hi,

   Running a DR test. Trying to restore an SMS managed dataset on a floor 
system that isn't SMS managed. Getting message ADR709E because it's looking for 
a storage class that doesn't exist on the floor system. Any parameters needed? 
Any thoughts would be appreciated. 


Dean Nai




>

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

ADRDSSU

[Nai, Dean]

Hi,

   Running a DR test. Trying to restore an SMS managed dataset on a floor 
system that isn't SMS managed. Getting message ADR709E because it's looking for 
a storage class that doesn't exist on the floor system. Any parameters needed? 
Any thoughts would be appreciated. 


Dean Nai




>

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

[Jesse 1 Robinson]

Thank you, that was my point about non-CTC links. When I started here in the 
90s, BSC links were still in use. First for NJE to VM/XA because our 
implementation did not include VTAM, and for some JES2 connections because of a 
perception that BSC was faster than SNA. A little testing dispelled the latter 
myth, and we converted all JES2 links in short order. By the time FCTC emerged, 
we were 100% SNA.

As to the simplicity of TCP/IP for NJE, I have to take exception. We are 
heavily dependent on several JES2 exits, some of which require different 
exits--different versions--for IP. We contemplated the effort required for 
conversion to IP and decided that we could not justify the project. 

.
.
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 R.S.
Sent: Wednesday, May 29, 2019 3:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CTC (FCTC) usage

NJE over BSC was obsolete 20 years ago.
However IMHO it's easier to use NJE over TCPIP than over CTC/VTAM. NJE over 
TCPIP is also not new, probably 10+ years.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2019-05-29 o 03:30, Tony Thigpen pisze:
> I am talking about JES2 controlled CTCs for NJE, not VTAM controlled 
> CTCs, which I expect you are thinking about and using. That is really 
> NJE over VTAM, just like using NJE over TCP/IP, both of which use a 
> third-party (VTAM or TCP/IP) as the actual traffic carrier. That 
> third-party carrier may allow multiple types of paths (one of which 
> *may* be a CTC), but JES2 does not know or care about the path selected.
>
> Specifically, JES2 can no longer talk directly to a CTC.
>
>
> Tony Thigpen
>
> Jesse 1 Robinson wrote on 5/28/19 7:00 PM:
>> 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: 64-bit C++ calling assembler

[Don Poitras]

I'm sure there are lots of ways to do this. I did it in C, not C++, but I
think the following would still work:

('nargs' below can't be > 8 and I obfuscated a bit, so no guarantees...)

void callhli(int hli, long nargs, ...)
{
  va_list ap; 
  int *args; 
  int i, j; 
  args = __malloc31(36); 
  va_start(ap, nargs); 
  for (i = 0; i < nargs; i++) 
  { 
j = (int) va_arg(ap, long); 
args[i] = j;
  } 
  va_end(ap); 
  args[i-1] |= 0x8000;  
  call31(hli, args); 
  free(args); 
  return;
}

CALL31
 LRR15,R1
 LRR1,R2
 LAR13,SAVEPoint R13 at a save area
 SAM31
 BASR  R14,R15
 SAM64




In article <5481683216760893.wa.prf51videotron...@listserv.ua.edu> you wrote:
> I have an assembler routine that gets called by 64-bit C++. The assembler 
> routine uses CELQPRLG and CELQEPLG and calls DSNALI. The C++ function 
> prototype has a variable number of arguments, the first being the number of 
> parameters that follow in the argument list. The C++ program passes the count 
> of 7 followed by 7 31-bit pointers. These were dumped prior to the call. I 
> forced an S0C3 at entry to the assembler routine. R01 contains a valid 64-bit 
> address. It points to a doubleword containing 7. But the 7 31-bit addresses 
> do NOT follow the value of 7. They are at +A8 from r01. I want to move the 
> pointers into 31-bit memory and call DSNALI to do a CONNECT (Hence a prior 
> post about DB2 manuals). I can't figure out what I've done wrong. There is 
> precious little doc on this and it's in the LE bookshelf, LE Programming 
> Guide for 64-bit Virtual Addressing Mode. Is there other doc somewhere else ? 
> I've looked but can't find anything.

> R01 points has 50_082FEBF8 and the 7 addresses are at 82FECA0.

>  _82FEBF8    0007   !  !
>  _82FEC00      2B0DBB88   0050   29E54920   ! ...h...&.V.. !
>  _82FEC10   0050   082FED20         ! ...& !
>  _82FEC20      297ED1C6   0050   29E55330   ! .=JF...&.V.. !
>  _82FEC30      2B1D1B60      2B0DB74A   ! ...-...?? !
>  _82FEC40      2B0DBB88      281B72A0   ! ...h !
>  _82FEC50      2B0DCD88   0050   29D29640   ! ...h...&.Ko  !
>  _82FEC60   0050   29E2EB60      25218CF0   ! ...&.S.-...0 !
>  _82FEC70      2B14D808      2B1D152A   ! ..Q. !
>  _82FEC80      2B0DBB88      281B72A0   ! ...h !
>  _82FEC90      2B0DCD88   0050   29D29640   ! ...h...&.Ko  !
>  _82FECA0      297ED0A2      297ED198   ! .=??s.=Jq !
>  _82FECB0      297ED180      297ED184   ! .=J..=Jd !
>  _82FECC0      297ED188      297ED190   ! .=Jh.=J. !
>  _82FECD0      297ED194         ! .=Jm !

> Registers at abend are :

> General purpose register values
>0-1  _297ED194  0050_082FEBF8
>2-3  _297ED0A2  _297ED198
>4-5  0050_082FD940  _
>6-7  _2B14B778  _2B1D9088
>8-9  _2B1D971E  _281B72A0
>   10-11 _2B1D9B58  0050_29E55330
>   12-13 _297ED188  _297ED184
>   14-15 _297ED180  _24D50010




> Thanks in advance, Pierre.

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


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

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

Re: FTPLOGGING not working

[Frank Swarbrick]

I asked but never got a response.  (We're running in IBM zCloud so I can't just 
stand in front of someone's desk.)


From: IBM Mainframe Discussion List  on behalf of Tim 
Hare 
Sent: Tuesday, May 28, 2019 9:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTPLOGGING not working

If you do find out what they did to resolve it, would you please post it here 
for the education of all?

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

[Frank Swarbrick]

I wondered if the keyword update would affect intrinsic functions.  Thanks 
again for the info!


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

Frank, you'll probably need the PTF(s) for APAR OA56161 in addition to APAR
OA55117. (Thank you, Alan.)

Presumably these updates will all be rolled up into z/OS 2.4, so that's
another option when available.


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: 64-bit C++ calling assembler

[Farley, Peter x23353]

31-bit pointers can be declared in C using this syntax:

char * __ptr32 ptr1;

Not sure if C++ will allow that, but if it does you can set your pointers up 
that way and pass them as 4-byte values instead of 8-byte values.  You can 
declare pointer arguments to your assembler routine in the same way.

I second John M.'s recommendation to use extern "C" for your assembler program 
declaration and the LIST compiler option to see exactly how the CALL to your 
assembler routine is bring set up.  That will tell you quite a lot of what you 
need to know.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pierre Fichaud
Sent: Wednesday, May 29, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 64-bit C++ calling assembler

I have an assembler routine that gets called by 64-bit C++. The assembler 
routine uses CELQPRLG and CELQEPLG and calls DSNALI. The C++ function prototype 
has a variable number of arguments, the first being the number of parameters 
that follow in the argument list. The C++ program passes the count of 7 
followed by 7 31-bit pointers. These were dumped prior to the call. I forced an 
S0C3 at entry to the assembler routine. R01 contains a valid 64-bit address. It 
points to a doubleword containing 7. But the 7 31-bit addresses do NOT follow 
the value of 7. They are at +A8 from r01. I want to move the pointers into 
31-bit memory and call DSNALI to do a CONNECT (Hence a prior post about DB2 
manuals). I can't figure out what I've done wrong. There is precious little doc 
on this and it's in the LE bookshelf, LE Programming Guide for 64-bit Virtual 
Addressing Mode. Is there other doc somewhere else ? I've looked but can't find 
anything.

R01 points has 50_082FEBF8 and the 7 addresses are at 82FECA0.

 _82FEBF8    0007   !  !
 _82FEC00      2B0DBB88   0050   29E54920   ! ...h...&.V.. !
 _82FEC10   0050   082FED20         ! ...& !
 _82FEC20      297ED1C6   0050   29E55330   ! .=JF...&.V.. !
 _82FEC30      2B1D1B60      2B0DB74A   ! ...-...Ä !
 _82FEC40      2B0DBB88      281B72A0   ! ...h !
 _82FEC50      2B0DCD88   0050   29D29640   ! ...h...&.Ko  !
 _82FEC60   0050   29E2EB60      25218CF0   ! ...&.S.-...0 !
 _82FEC70      2B14D808      2B1D152A   ! ..Q. !
 _82FEC80      2B0DBB88      281B72A0   ! ...h !
 _82FEC90      2B0DCD88   0050   29D29640   ! ...h...&.Ko  !
 _82FECA0      297ED0A2      297ED198   ! .=üs.=Jq !
 _82FECB0      297ED180      297ED184   ! .=J..=Jd !
 _82FECC0      297ED188      297ED190   ! .=Jh.=J. !
 _82FECD0      297ED194         ! .=Jm !

Registers at abend are :

General purpose register values
   0-1  _297ED194  0050_082FEBF8
   2-3  _297ED0A2  _297ED198
   4-5  0050_082FD940  _
   6-7  _2B14B778  _2B1D9088
   8-9  _2B1D971E  _281B72A0
  10-11 _2B1D9B58  0050_29E55330
  12-13 _297ED188  _297ED184
  14-15 _297ED180  _24D50010

Thanks in advance, Pierre.
--

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

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

[Ray Overby]

In response to "Mistakes, lack of time, lack of control, lack of skills. 
Not a platform weakness." comment: The mainframe platform, z/OS, and 
ESM's all rely on integrity to function. A single TRAP DOOR code 
vulnerability pierces the veil of integrity and can be used to 
compromise the mainframe. Is this a platform weakness? I think so. The 
platform relies on all code it runs adhering to certain rules. z/OS 
could be changed to better check and enforce those rules.


Would you say that the elimination of User Key Common storage is an 
example of a z/OS change to address a mainframe platform weakness? I 
think so.


An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:

That's classical FUD.
Frightening people.
"if an exploit", "if job reads you RACF db", "unintended consequences".
What exactly hacking scenario can provide RACF db to the hacker?
Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user 
attribute, even UPDATE to RACF db. But it's problem of people. 
Mistakes, lack of time, lack of control, lack of skills. Not a 
platform weakness.


It's typical that assurance/lock/gun salesmen tend to talk about 
risks, threats and dangers. They create a vision.
My English is poor, but I can observe it for two of debaters here. 
It's visible. I don't like social engineering.




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

Re: 64-bit C++ calling assembler

[John McKown]

When I am confused by this sort of thing, I ask the compiler to show me the
generated assembler code that it is using. Perhaps C++ is inserting some
other data in the parameter list. Also, is the HLASM routine defined with a
prototype with an extern "C" ? Something like:

extern "C" type0 myassem(int, type1, type2, type3, type4, type5, type6,
type7);

Where the "type?" names are replaced by the proper type declaration.

Just some thought. I am not a C++ programmer.



On Wed, May 29, 2019 at 9:52 AM Pierre Fichaud  wrote:

> I have an assembler routine that gets called by 64-bit C++. The assembler
> routine uses CELQPRLG and CELQEPLG and calls DSNALI. The C++ function
> prototype has a variable number of arguments, the first being the number of
> parameters that follow in the argument list. The C++ program passes the
> count of 7 followed by 7 31-bit pointers. These were dumped prior to the
> call. I forced an S0C3 at entry to the assembler routine. R01 contains a
> valid 64-bit address. It points to a doubleword containing 7. But the 7
> 31-bit addresses do NOT follow the value of 7. They are at +A8 from r01. I
> want to move the pointers into 31-bit memory and call DSNALI to do a
> CONNECT (Hence a prior post about DB2 manuals). I can't figure out what
> I've done wrong. There is precious little doc on this and it's in the LE
> bookshelf, LE Programming Guide for 64-bit Virtual Addressing Mode. Is
> there other doc somewhere else ? I've looked but can't find anything.
>
> R01 points has 50_082FEBF8 and the 7 addresses are at 82FECA0.
>
>  _82FEBF8    0007   ! 
> !
>  _82FEC00      2B0DBB88   0050   29E54920   ! ...h...&.V..
> !
>  _82FEC10   0050   082FED20         ! ...&
> !
>  _82FEC20      297ED1C6   0050   29E55330   ! .=JF...&.V..
> !
>  _82FEC30      2B1D1B60      2B0DB74A   ! ...-...Ä
> !
>  _82FEC40      2B0DBB88      281B72A0   ! ...h
> !
>  _82FEC50      2B0DCD88   0050   29D29640   ! ...h...&.Ko
> !
>  _82FEC60   0050   29E2EB60      25218CF0   ! ...&.S.-...0
> !
>  _82FEC70      2B14D808      2B1D152A   ! ..Q.
> !
>  _82FEC80      2B0DBB88      281B72A0   ! ...h
> !
>  _82FEC90      2B0DCD88   0050   29D29640   ! ...h...&.Ko
> !
>  _82FECA0      297ED0A2      297ED198   ! .=üs.=Jq
> !
>  _82FECB0      297ED180      297ED184   ! .=J..=Jd
> !
>  _82FECC0      297ED188      297ED190   ! .=Jh.=J.
> !
>  _82FECD0      297ED194         ! .=Jm
> !
>
> Registers at abend are :
>
> General purpose register values
>0-1  _297ED194  0050_082FEBF8
>2-3  _297ED0A2  _297ED198
>4-5  0050_082FD940  _
>6-7  _2B14B778  _2B1D9088
>8-9  _2B1D971E  _281B72A0
>   10-11 _2B1D9B58  0050_29E55330
>   12-13 _297ED188  _297ED184
>   14-15 _297ED180  _24D50010
>
>
>
>
> Thanks in advance, Pierre.
>
> --
> 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

[John McKown]

On Wed, May 29, 2019 at 8:38 AM Billy Ashton  wrote:

> John, thanks for all your help - this has increased my knowledge a lot
> about BPX... One last question that I could not find in the manuals or in
> Google...
>
> Part of this process is to download a file from a server. This file is
> tersed, though, and I was not able to find a way to run AMATERSE from the
> shell script (would I even want to?). The problem I had is that BPX seems
> to spawn in a different address, and the JCL step that execute it just
> completes and goes on its merry way. This causes a problem because my
> UnTerse step starts running before the BPX shell finishes.
>
> The process I have looks like this:
> 1. Allocate the untersed output file
> 2. Create sftp commands
> 3. Run BPXBATCH to do some stuff, then to sftp download the tersed file,
> and then do some more stuff
> 4. Run AMATERSE to UnTerse the file
> 5. Run application program against untersed file.
>
> The problem is that I get an EDC5061I with errno2=0xC00B0403, indicated the
> file is open somewhere else, and it appears that steps 3 and 4, above are
> running concurrently, causing the allocation error.
>

You are using sftp to download the tersed dataset? Where are you putting
it? IIRC, IBM's sftp only supports UNIX files. And it doesn't support a
binary transfer, so I am confused.

To the best of my knowledge, the BPXBATCH shell process should wait for the
sftp process to exit before doing the next command in the script. I did a
quick test and that's what my job did. But I am on z/OS 1.12. Are you
allowed to show me your BPXBATCH step (masking any secure information)?

Is the EDC5061I coming from the sftp or from the AMATERSE step? If you
could give me the entire job, again masking anything that can't be shared,
it would likely help my understanding.


>
> You have done some magical things between MVS and Unix, and I am hopeful
> you have some ideas here for keeping this all in one job. If not, however,
> then so be it.
>
> Thanks again!
> Billy
>
>
>
> On Tue, May 28, 2019 at 3:07 PM John McKown 
> wrote:
>
> > 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
> >
>
> --
> 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

64-bit C++ calling assembler

[Pierre Fichaud]

I have an assembler routine that gets called by 64-bit C++. The assembler 
routine uses CELQPRLG and CELQEPLG and calls DSNALI. The C++ function prototype 
has a variable number of arguments, the first being the number of parameters 
that follow in the argument list. The C++ program passes the count of 7 
followed by 7 31-bit pointers. These were dumped prior to the call. I forced an 
S0C3 at entry to the assembler routine. R01 contains a valid 64-bit address. It 
points to a doubleword containing 7. But the 7 31-bit addresses do NOT follow 
the value of 7. They are at +A8 from r01. I want to move the pointers into 
31-bit memory and call DSNALI to do a CONNECT (Hence a prior post about DB2 
manuals). I can't figure out what I've done wrong. There is precious little doc 
on this and it's in the LE bookshelf, LE Programming Guide for 64-bit Virtual 
Addressing Mode. Is there other doc somewhere else ? I've looked but can't find 
anything.

R01 points has 50_082FEBF8 and the 7 addresses are at 82FECA0.

 _82FEBF8    0007   !  !
 _82FEC00      2B0DBB88   0050   29E54920   ! ...h...&.V.. !
 _82FEC10   0050   082FED20         ! ...& !
 _82FEC20      297ED1C6   0050   29E55330   ! .=JF...&.V.. !
 _82FEC30      2B1D1B60      2B0DB74A   ! ...-...Ä !
 _82FEC40      2B0DBB88      281B72A0   ! ...h !
 _82FEC50      2B0DCD88   0050   29D29640   ! ...h...&.Ko  !
 _82FEC60   0050   29E2EB60      25218CF0   ! ...&.S.-...0 !
 _82FEC70      2B14D808      2B1D152A   ! ..Q. !
 _82FEC80      2B0DBB88      281B72A0   ! ...h !
 _82FEC90      2B0DCD88   0050   29D29640   ! ...h...&.Ko  !
 _82FECA0      297ED0A2      297ED198   ! .=üs.=Jq !
 _82FECB0      297ED180      297ED184   ! .=J..=Jd !
 _82FECC0      297ED188      297ED190   ! .=Jh.=J. !
 _82FECD0      297ED194         ! .=Jm !

Registers at abend are :

General purpose register values
   0-1  _297ED194  0050_082FEBF8
   2-3  _297ED0A2  _297ED198
   4-5  0050_082FD940  _
   6-7  _2B14B778  _2B1D9088
   8-9  _2B1D971E  _281B72A0
  10-11 _2B1D9B58  0050_29E55330
  12-13 _297ED188  _297ED184
  14-15 _297ED180  _24D50010




Thanks in advance, Pierre.

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

Radoslaw,

 * I find your posts informative and helpful.
 * I think your English is very understandable
 * I respect your expertise

My initial post was an attempt to get a stalled discussion moving in a 
more positive direction. I don't normally post but I felt that mainframe 
vulnerability discussions are important for our industry. We, as a 
group, need to be able to discuss this issue without resorting to name 
calling and childish behavior.


The work that I do includes finding exploitable code based 
vulnerabilities running in the wild on z/OS systems. These 
vulnerabilities are on mainframe systems in many sectors, including 
Financial Institutions and Government. These installations report the 
vulnerabilities they find and the ISV's fix them. This is a fact. 
Individuals like Bill Johnson can say that I am lying. You can say what 
I am saying is FUD - however, neither of these things changes the fact 
that I continue to find exploitable code vulnerabilities in z/OS. More 
and more people are being exposed to this fact every day.


Based on the work I have done on mainframe code vulnerabilities, I have 
concluded that there is a serious problem in our industry. The code that 
runs in production in all sectors has poorly written code, that if 
exploited, would compromise all data on those systems. Should I just 
ignore this problem or try and do something about it? The numbers of 
vulnerabilities tells me there are some fundamental problems with how 
software development is being done in our industry. The lives of people, 
organizations, and governments would be adversely affected if the code 
vulnerabilities I have found were not reported and fixed by the vendors. 
I have decided that I cannot just stand by and do nothing. The industry 
needs to do better. We need to do better.


In response to "What exactly hacking scenario can provide RACF db to the 
hacker?" there is a class of vulnerabilities called TRAP DOOR. A TRAP 
DOOR vulnerability will branch to an address specified by an 
unauthorized user (key 8 problem state not apf authorized) in an 
authorized state (PSW KEY 0-7, Supervisor state, JSCBAUTH bit set). This 
type of vulnerability usually exists in SVC and PC routines. The address 
I pass will have code to get into PSW Key 0 (code is different depending 
upon the entry environment). Once in PSW Key 0 I can a) Suppress all SMF 
records to hide what I am doing b) Frontend the SAF Router to force all 
AUTH and FASTAUTH calls to "allow and no log" (this is for any ESM not 
just RACF) c) Copy the ESM data base to another data set d) Create a 
reverse shell to send it out to an IP of my choice or e) download to 
windows or mac and then attach to email or f) email directly from 
mainframe. Please note that once I get to PSW KEY 0 my code is now 
working as an extension of z/OS. Whatever z/OS can do my code can do. 
With no forensic evidence to see what I did. Or I could create ESM 
credentials for Bill Johnson or Radoslaw and let it get logged to you;-) 
.  Just as a FYI about 35% of the "several hundred" code vulnerabilities 
that I have found are TRAP DOOR vulnerabilities. This represents a 
significant percentage of total number of vulnerabilities. This is a 
statically viable example.


The following is for Bill Johnson which would have been covered in the demo:

 * The SVC or PC routine can be issued by any user on the mainframe
   system.
 * The vulnerable code is executed before any SAF calls are made by the
   SVC or PC routine (i.e. - ESM cannot help you)
 * The ESM's:
 o Cannot identify this vulnerable code is on the system
 o Cannot tell you when the vulnerable code is exploited
 o Cannot provide you the information to get vulnerability remediated
 * The payload code does not require an APF authorized library. The
   authorization is inherited from the caller (the SVC or PC routine).
 * No extra-ordinary ESM authorities are required - any id would do
 * No extra-ordinary z/Os authorizes are required
 * Suppressing SMF is for all SMF record types not just ESM records
   types (i.e. - types 14 and 15)

It would be easier for this discussion if I could just create a CVE in 
the national vulnerability data base. Then I could just point you to it 
and you could research this for your self. However, that is not how our 
industry works. Everything is secret. I used terms like "if an exploit", 
"if job reads you RACF db", "unintended consequences" to allow 
conversation without telling everyone enough information to create an 
exploit. That is the dilemma: How can we have meaningful conversations 
about vulnerabilities without exposing too much information? My answer 
is to classify the vulnerabilities. At this point we should be able to 
have meaningful conversation about any "TRAP DOOR" vulnerabilities.


In response to "Mistakes, lack of time, lack of control, lack of skills. 
Not a platform weakness." comment: People are responsible for a TRAP 
DOOR code vulnerability as wel

Re: How to delete and allocate files in bpxbatch

[Billy Ashton]

John, thanks for all your help - this has increased my knowledge a lot
about BPX... One last question that I could not find in the manuals or in
Google...

Part of this process is to download a file from a server. This file is
tersed, though, and I was not able to find a way to run AMATERSE from the
shell script (would I even want to?). The problem I had is that BPX seems
to spawn in a different address, and the JCL step that execute it just
completes and goes on its merry way. This causes a problem because my
UnTerse step starts running before the BPX shell finishes.

The process I have looks like this:
1. Allocate the untersed output file
2. Create sftp commands
3. Run BPXBATCH to do some stuff, then to sftp download the tersed file,
and then do some more stuff
4. Run AMATERSE to UnTerse the file
5. Run application program against untersed file.

The problem is that I get an EDC5061I with errno2=0xC00B0403, indicated the
file is open somewhere else, and it appears that steps 3 and 4, above are
running concurrently, causing the allocation error.

You have done some magical things between MVS and Unix, and I am hopeful
you have some ideas here for keeping this all in one job. If not, however,
then so be it.

Thanks again!
Billy



On Tue, May 28, 2019 at 3:07 PM John McKown 
wrote:

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

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

[Carmen Vitullo]

well, here's my embarrassed face :( 

I was led to believe qradar was a tool to review security issues also, as you 
can tell I don't know the product well. I didn't want to dig into all the, 
already mentioned security issues with APF, RACF SPECIAL, UID 0,etc, but I know 
most places I worked for had standard practices and reporting facilities to 
review and correct these holes. 
one standard we use now to logon is MFA, badge, with a chip, pin # and our ID 
and password, even for on-call and working from home. 
I hear a rumor we will be moving to a MFA with 3 levels of security... UGH! 
. 



Carmen Vitullo 

- Original Message -

From: "ITschak Mugzach"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 29, 2019 8:01:48 AM 
Subject: Re: Just how secure are mainframes? | Trevor Eddolls 

Carmen, t think you are mixing event audit (siem product like qradar) with 
status which was the subject of this thread. 

Siem is good, but my experience create lot of false positive alerts. 

ITschak 

בתאריך יום ד׳, 29 במאי 2019, 15:54, מאת Carmen Vitullo ‏: 

> That's one response I can agree with ! 
> 
> 
> I didn't want to drag myself into this, I also have been working for 
> outsourcers, who's customers were very large banks, insurance companies, 
> worked for a very large defense contractor, state Government, and now back 
> in one of the largest health care insurance companies in the US, and I know 
> there are all security standards for each, some follow the same base 
> security standards and some have a higher level of standards , they are not 
> all perfect. one thing I've not head is someone quoting any standards by 
> name, for security and auditing, HITRUST is one of our standard, some 
> standards we adopted over the years because we learned where our security 
> holes where. I think we can argue till the cows come home about who's more 
> secure, I know by fact, our Micro team is up very early in the AM 3-4 times 
> a week applying security patches by the hundreds in the windows world, 
> maybe I'm a little lax but I don't see us doing this in the Z environment 
> so often. 
> we use tools to monitor and report TSS security issues, a standard tool 
> called QRADAR, it also is not perfect, but it allows the security team some 
> insight as to what security issues we all have in the enterprise, Winders, 
> AIX, Linux and Z. 
> 
> 
> 
> Carmen Vitullo 
> 
> - Original Message - 
> 
> From: "ITschak Mugzach"  
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Sent: Wednesday, May 29, 2019 7:26:10 AM 
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls 
> 
> Where is the list moderator when we need him/her. Some people here 
> completely lost their manners. 
> 
> ITschak 
> 
> בתאריך יום ד׳, 29 במאי 2019, 14:19, מאת Bill Johnson ‏< 
> 0047540adefe-dmarc-requ...@listserv.ua.edu>: 
> 
> > Nah, I’ll go back to lurking. I forgot many of you already know 
> everything. 
> > 
> > 
> > Sent from Yahoo Mail for iPhone 
> > 
> > 
> > On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. < 
> > 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: 
> > 
> > Questioning the integrity of a man with his credentials and background 
> in 
> > mainframe security for over 30+ years? Who the hell are you that I 
> should 
> > even listen to one more word from you? Better to be a fool and know it 
> than 
> > open your mouth and remove all shadow of doubt. 
> > 
> > Bill, if you can overcome your arrogance, you should probably apologize. 
> > If not, take your trolling to some other place. 
> > 
> > One final comment: If you had consulted on a "real life event" would you 
> > give explicit details of who, what, when and where to some stranger? 
> > Especially one who has questioned the comments of everyone attempting to 
> > respond on this thread? 
> > 
> > I'll entertain one more response from you before I place you in the 
> > virtual Anton Britz lookalike folder. Make it a good one. 
> > 
> > -Original Message- 
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On 
> > Behalf Of Bill Johnson 
> > Sent: Tuesday, May 28, 2019 8:26 PM 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls 
> > 
> > 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: 
> > 
> > 

Re: Just how secure are mainframes? | Trevor Eddolls

[ITschak Mugzach]

Carmen, t think  you are mixing event audit (siem product like qradar) with
status which was the subject of this thread.

Siem is good, but my experience create lot of false positive alerts.

ITschak

בתאריך יום ד׳, 29 במאי 2019, 15:54, מאת Carmen Vitullo ‏:

> That's one response I can agree with !
>
>
> I didn't want to drag myself into this, I also have been working for
> outsourcers, who's customers were very large banks, insurance companies,
> worked for a very large defense contractor, state Government, and now back
> in one of the largest health care insurance companies in the US, and I know
> there are all security standards for each, some follow the same base
> security standards and some have a higher level of standards , they are not
> all perfect. one thing I've not head is someone quoting any standards by
> name, for security and auditing, HITRUST is one of our standard, some
> standards we adopted over the years because we learned where our security
> holes where. I think we can argue till the cows come home about who's more
> secure, I know by fact, our Micro team is up very early in the AM 3-4 times
> a week applying security patches by the hundreds in the windows world,
> maybe I'm a little lax but I don't see us doing this in the Z environment
> so often.
> we use tools to monitor and report TSS security issues, a standard tool
> called QRADAR, it also is not perfect, but it allows the security team some
> insight as to what security issues we all have in the enterprise, Winders,
> AIX, Linux and Z.
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "ITschak Mugzach" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Wednesday, May 29, 2019 7:26:10 AM
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> Where is the list moderator when we need him/her. Some people here
> completely lost their manners.
>
> ITschak
>
> בתאריך יום ד׳, 29 במאי 2019, 14:19, מאת Bill Johnson ‏<
> 0047540adefe-dmarc-requ...@listserv.ua.edu>:
>
> > Nah, I’ll go back to lurking. I forgot many of you already know
> everything.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. <
> > 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Questioning the integrity of a man with his credentials and background
> in
> > mainframe security for over 30+ years? Who the hell are you that I
> should
> > even listen to one more word from you? Better to be a fool and know it
> than
> > open your mouth and remove all shadow of doubt.
> >
> > Bill, if you can overcome your arrogance, you should probably apologize.
> > If not, take your trolling to some other place.
> >
> > One final comment: If you had consulted on a "real life event" would you
> > give explicit details of who, what, when and where to some stranger?
> > Especially one who has questioned the comments of everyone attempting to
> > respond on this thread?
> >
> > I'll entertain one more response from you before I place you in the
> > virtual Anton Britz lookalike folder. Make it a good one.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of Bill Johnson
> > Sent: Tuesday, May 28, 2019 8:26 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> >
> > 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
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >
> > --

Re: RSUs

[Kurt Quackenbush]

On 5/29/2019 3:57 AM, Styles, Andy , ITS zPlatform Services wrote:


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


I believe we received new PTFs - with RSU1903 being assigned to them at the 
same time. That's the behaviour I'm querying - and I think you agree - once IBM 
has announced RSU1903, there should have been no further PTFs with that RSU, 
whether I specify RECOMMENDED or ALL.


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.


I understand the HIPER/PE fixes, but they surely should not be assigned RSU1903 
after the publish date?


Correct.


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.


Well, we're coming up to another RSU date in the next few days. I can attempt 
to repeat this, and see what happens.


Fair enough.  It will be helpful to keep track of changes to your SMP/E 
environment between your two RECEIVE ORDER jobs, and please be sure to 
use the same RECEIVE ORDER command.  For example, either use FORTGTZONES 
in both or not at all.  My preference is not at all.


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

[Carmen Vitullo]

That's one response I can agree with ! 


I didn't want to drag myself into this, I also have been working for 
outsourcers, who's customers were very large banks, insurance companies, worked 
for a very large defense contractor, state Government, and now back in one of 
the largest health care insurance companies in the US, and I know there are all 
security standards for each, some follow the same base security standards and 
some have a higher level of standards , they are not all perfect. one thing 
I've not head is someone quoting any standards by name, for security and 
auditing, HITRUST is one of our standard, some standards we adopted over the 
years because we learned where our security holes where. I think we can argue 
till the cows come home about who's more secure, I know by fact, our Micro team 
is up very early in the AM 3-4 times a week applying security patches by the 
hundreds in the windows world, maybe I'm a little lax but I don't see us doing 
this in the Z environment so often. 
we use tools to monitor and report TSS security issues, a standard tool called 
QRADAR, it also is not perfect, but it allows the security team some insight as 
to what security issues we all have in the enterprise, Winders, AIX, Linux and 
Z. 



Carmen Vitullo 

- Original Message -

From: "ITschak Mugzach"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 29, 2019 7:26:10 AM 
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls 

Where is the list moderator when we need him/her. Some people here 
completely lost their manners. 

ITschak 

בתאריך יום ד׳, 29 במאי 2019, 14:19, מאת Bill Johnson ‏< 
0047540adefe-dmarc-requ...@listserv.ua.edu>: 

> Nah, I’ll go back to lurking. I forgot many of you already know everything. 
> 
> 
> Sent from Yahoo Mail for iPhone 
> 
> 
> On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. < 
> 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: 
> 
> Questioning the integrity of a man with his credentials and background in 
> mainframe security for over 30+ years? Who the hell are you that I should 
> even listen to one more word from you? Better to be a fool and know it than 
> open your mouth and remove all shadow of doubt. 
> 
> Bill, if you can overcome your arrogance, you should probably apologize. 
> If not, take your trolling to some other place. 
> 
> One final comment: If you had consulted on a "real life event" would you 
> give explicit details of who, what, when and where to some stranger? 
> Especially one who has questioned the comments of everyone attempting to 
> respond on this thread? 
> 
> I'll entertain one more response from you before I place you in the 
> virtual Anton Britz lookalike folder. Make it a good one. 
> 
> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bill Johnson 
> Sent: Tuesday, May 28, 2019 8:26 PM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls 
> 
> 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 
> 
> -- 
> 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 mess

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

[ITschak Mugzach]

Where is the list moderator when we need him/her. Some people here
completely lost their manners.

ITschak

בתאריך יום ד׳, 29 במאי 2019, 14:19, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> Nah, I’ll go back to lurking. I forgot many of you already know everything.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. <
> 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:
>
> Questioning the integrity of a man with his credentials and background in
> mainframe security for over 30+ years? Who the hell are you that I should
> even listen to one more word from you? Better to be a fool and know it than
> open your mouth and remove all shadow of doubt.
>
> Bill, if you can overcome your arrogance, you should probably apologize.
> If not, take your trolling to some other place.
>
> One final comment: If you had consulted on a "real life event" would you
> give explicit details of who, what, when and where to some stranger?
> Especially one who has questioned the comments of everyone attempting to
> respond on this thread?
>
> I'll entertain one more response from you before I place you in the
> virtual Anton Britz lookalike folder. Make it a good one.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Johnson
> Sent: Tuesday, May 28, 2019 8:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> 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
>
> --
> 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

[Bill Johnson]

Nah, I’ll go back to lurking. I forgot many of you already know everything.


Sent from Yahoo Mail for iPhone


On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. 
<01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:

Questioning the integrity of a man with his credentials and background in 
mainframe security for over 30+ years? Who the hell are you that I should even 
listen to one more word from you? Better to be a fool and know it than open 
your mouth and remove all shadow of doubt.

Bill, if you can overcome your arrogance, you should probably apologize. If 
not, take your trolling to some other place.

One final comment: If you had consulted on a "real life event" would you give 
explicit details of who, what, when and where to some stranger? Especially one 
who has questioned the comments of everyone attempting to respond on this 
thread?

I'll entertain one more response from you before I place you in the virtual 
Anton Britz lookalike folder. Make it a good one. 

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

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

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

[Richards, Robert B.]

Radoslaw, you took my reply entirely wrong. I'll try to restate it better.

Over many years, banks have been very susceptible to fraud, break-ins, hackers, 
insider shananigans, corrupt employees, etc. But they have learned. Experience 
taught them that and it is a tough lesson to learn. I worked, in this century, 
for one of the largest US banks. But before that, my nuclear family banking 
experience totaled 75+ years. I've heard dozens of war stories. But I also know 
that a lot of banking fraud never was revealed to the general public less they 
take their business elsewhere. Experience has taught the banking industry some 
very tough lessons. That is what I meant. Not an attack on you or your comments 
at all. Quite the opposite. I look forward to reading your replies.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, May 29, 2019 6:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

W dniu 2019-05-29 o 12:09, Richards, Robert B. pisze:
>> I'm still sure thank banks are less susceptible to break in than regular 
>> house
> Yeah, experience is a tough task master, isn't it?
Who is task master?
Do you try to insult me?
Just because you disagree with my opinions?

-- 
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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CTC (FCTC) usage

[R.S.]

NJE over BSC was obsolete 20 years ago.
However IMHO it's easier to use NJE over TCPIP than over CTC/VTAM. NJE 
over TCPIP is also not new, probably 10+ years.


--
Radoslaw Skorupka
Lodz, Poland






W dniu 2019-05-29 o 03:30, Tony Thigpen pisze:
I am talking about JES2 controlled CTCs for NJE, not VTAM controlled 
CTCs, which I expect you are thinking about and using. That is really 
NJE over VTAM, just like using NJE over TCP/IP, both of which use a 
third-party (VTAM or TCP/IP) as the actual traffic carrier. That 
third-party carrier may allow multiple types of paths (one of which 
*may* be a CTC), but JES2 does not know or care about the path selected.


Specifically, JES2 can no longer talk directly to a CTC.


Tony Thigpen

Jesse 1 Robinson wrote on 5/28/19 7:00 PM:
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





==

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

[ITschak Mugzach]

I didn't offer anything. Read the thread from begining. I was the first to
confirm the PEOPLE is the main issue.

Yes, I don't think clients buy mainframes because they are more secure, i
don't know if there are new clients for mainframes in the last few years.

Most, if not all, mainframe clients i know (many in three continents) had
the computing needs and was able to pay for them, years before any
alternative even exist. For good or bad, this is where they put their money
and i show many others that decided that their money can buy better. I
don't think they did a right decision, but they never asked me...

And... I never use FAD. Security  is the provider responsibility. They
perform under laws, acts, regulations, auditors, what ever. I can help make
identifying risks quicker, i am not managing their client's money,
information or supplied resources like energy, water or food. If they do
better without my and other vendors tools or services, that is great.

ITschak

ITschak

בתאריך יום ד׳, 29 במאי 2019, 13:25, מאת R.S. ‏<
r.skoru...@bremultibank.com.pl>:

> That's classical FUD.
> Frightening people.
> "if an exploit", "if job reads you RACF db", "unintended consequences".
> What exactly hacking scenario can provide RACF db to the hacker?
> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user
> attribute, even UPDATE to RACF db. But it's problem of people. Mistakes,
> lack of time, lack of control, lack of skills. Not a platform weakness.
>
> It's typical that assurance/lock/gun salesmen tend to talk about risks,
> threats and dangers. They create a vision.
> My English is poor, but I can observe it for two of debaters here. It's
> visible. I don't like social engineering.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 2019-05-28 o 20:41, Ray Overby pisze:
> > 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
>
> >> [...]
>
> ==
>
> 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.Pr

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

[R.S.]

W dniu 2019-05-29 o 12:09, Richards, Robert B. pisze:

I'm still sure thank banks are less susceptible to break in than regular house

Yeah, experience is a tough task master, isn't it?

Who is task master?
Do you try to insult me?
Just because you disagree with my opinions?

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

[R.S.]

That's classical FUD.
Frightening people.
"if an exploit", "if job reads you RACF db", "unintended consequences".
What exactly hacking scenario can provide RACF db to the hacker?
Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user 
attribute, even UPDATE to RACF db. But it's problem of people. Mistakes, 
lack of time, lack of control, lack of skills. Not a platform weakness.


It's typical that assurance/lock/gun salesmen tend to talk about risks, 
threats and dangers. They create a vision.
My English is poor, but I can observe it for two of debaters here. It's 
visible. I don't like social engineering.


--
Radoslaw Skorupka
Lodz, Poland







W dniu 2019-05-28 o 20:41, Ray Overby pisze:
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



[...]


==

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.

-

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

[ITschak Mugzach]

Radoslav,

I just tried to demonstrate the fact that ibm sometime don't confirm the
risk before it fix it and many of the industry ayyack methodd are also
posible with new technologies broght to mainframe. While i accept this
strategy from client security point of view, you can't relay on that they
tell you everything. I also agree that the z architecture is more secure.
The only thing is the gap between potential and actual. As others here, i
am doing that daily. What i see make me think i better be bald ...the are
so many attach surfaces that left unhandled. When we use our automatic
assessment, tool, most clients fails more then 50% of the tests.

Btw, win10 goes far with security, implementing micro VMs.

ITschak

בתאריך יום ד׳, 29 במאי 2019, 13:04, מאת R.S. ‏<
r.skoru...@bremultibank.com.pl>:

> W dniu 2019-05-28 o 19:01, ITschak Mugzach pisze:
> > 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,
> I'm sure the above is demagoguery.
> I'm still sure thank banks are less susceptible to break in than regular
> house and I'm sure z/OS is much more safe than Windows. Note: I talk
> about platform, not about people's mistakes in configuration.
>
> --
> 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 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

[Richards, Robert B.]

> I'm still sure thank banks are less susceptible to break in than regular house

Yeah, experience is a tough task master, isn't it? 

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, May 29, 2019 6:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

W dniu 2019-05-28 o 19:01, ITschak Mugzach pisze:
> 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,
I'm sure the above is demagoguery.
I'm still sure thank banks are less susceptible to break in than regular 
house and I'm sure z/OS is much more safe than Windows. Note: I talk 
about platform, not about people's mistakes in configuration.

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

[R.S.]

W dniu 2019-05-28 o 19:01, ITschak Mugzach pisze:

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,
I'm sure the above is demagoguery.
I'm still sure thank banks are less susceptible to break in than regular 
house and I'm sure z/OS is much more safe than Windows. Note: I talk 
about platform, not about people's mistakes in configuration.


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

[Richards, Robert B.]

Questioning the integrity of a man with his credentials and background in 
mainframe security for over 30+ years? Who the hell are you that I should even 
listen to one more word from you? Better to be a fool and know it than open 
your mouth and remove all shadow of doubt.

Bill, if you can overcome your arrogance, you should probably apologize. If 
not, take your trolling to some other place.

One final comment: If you had consulted on a "real life event" would you give 
explicit details of who, what, when and where to some stranger? Especially one 
who has questioned the comments of everyone attempting to respond on this 
thread?

I'll entertain one more response from you before I place you in the virtual 
Anton Britz lookalike folder. Make it a good one. 

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

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

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

Final reminder - Next meeting of the GSE UK Security Working Group

[Mark Wilson]

Ladies and Gentlemen,

A gentle reminder that the next meeting of the GSE UK Security Working Group, 
will take place on Thursday 6th June 2019 at the new offices of RSM Partners in 
Bromsgrove, UK (a 40 minute drive from Birmingham Airport).  If you cannot 
attend in person, you are welcome to join via webex.

Please note that registration is open, which you can access via our Events page 
> http://www.racf.gse.org.uk/content/content_events.php. When you register, 
please specify how you will attend (in person or via webex).

Highlights from the agenda includes:


  *   Using thin-client terminal emulation to secure 3270 access
  *   Think like an Auditor to secure your system
  *   How to improve your testing of RACF changes
  *   Secure Engineering: How to develop authorised code without compromising 
z/OS system integrity
  *   Network Security – and don’t forget VTAM/SNA
  *   The journey of two Mainframe Security Trainees
  *   Identity Management: Using the right tooling

The full agenda is available to download from our Events page.

If you have a certification or you are studying, you can earn up to 7 CPE hours 
for attending this event.

For those of you who have already registered, you will receive joining 
instructions by the end of this week.

We hope that you will be able to join us either in person or virtually!

Regards

Mark Wilson and Jamie Pease

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

Re: RSUs

[Styles, Andy (ITS zPlatform Services)]

Classification: Public
Hi Kurt, 

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

I believe we received new PTFs - with RSU1903 being assigned to them at the 
same time. That's the behaviour I'm querying - and I think you agree - once IBM 
has announced RSU1903, there should have been no further PTFs with that RSU, 
whether I specify RECOMMENDED or ALL.

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

I understand the HIPER/PE fixes, but they surely should not be assigned RSU1903 
after the publish date?

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

Well, we're coming up to another RSU date in the next few days. I can attempt 
to repeat this, and see what happens. 

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

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