Re: CTC (FCTC) usage [EXTERNAL]

2019-05-31 Thread Feller, Paul
Munif, maybe my original comments didn't make through the world of email 
servers.  

I don't think I've ever seen one doc that list all the things that can use 
CTCs.  At our shop the real users of CTCs devices are XCF and VTAM.  Those are 
the only tasks that have CTC device addresses defined to them.

In a sysplex (base or parallel) things like GRS (and others) can use XCF for 
communications so they don't need to have any CTC devices defined to them.  
They let XCF handle the message traffic.

If you don't have any of your lpars in a sysplex then you can't use XCF so for 
like GRS you would have to define some CTC devices to GRS.

Tasks like JES2 or CICS can use IP (OSAs or Hipersockets) or VTAM/SNA for 
communications.


Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, May 31, 2019 7:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CTC (FCTC) usage [EXTERNAL]

It's true that no one has answered the original basic question. I think that's 
largely because there is no single doc that lays out all application uses of 
(F)CTC any more than doc that lays out all application uses of DASD or tape. 

.
.
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 
Munif Sadek
Sent: Friday, May 31, 2019 9:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CTC (FCTC) usage

Thanks a lot  for so many replies.
My basic question still remains the same..where all CTC(FCTC) can be used under 
zOS  and all required configurations. Do agree HCD/IOCP is very well documented 
but  not the applications, VTAM, IP configurations.
regards
Munif


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

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

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


Re: CTC (FCTC) usage

2019-05-31 Thread Jesse 1 Robinson
It's true that no one has answered the original basic question. I think that's 
largely because there is no single doc that lays out all application uses of 
(F)CTC any more than doc that lays out all application uses of DASD or tape. 

.
.
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 
Munif Sadek
Sent: Friday, May 31, 2019 9:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CTC (FCTC) usage

Thanks a lot  for so many replies.
My basic question still remains the same..where all CTC(FCTC) can be used under 
zOS  and all required configurations. Do agree HCD/IOCP is very well documented 
but  not the applications, VTAM, IP configurations.
regards
Munif


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


Re: Just how secure are mainframes? | Trevor Eddolls

2019-05-31 Thread Ray Overby
In response to "Since when does MODESET turn on the JSCBAUTH bit? Just 
how do you propose that IBM prevent key zero code from setting it? Why 
do think that turning on JSCBAUTH lets key zero code do anything that it 
couldn't do anyways? If the installation doesn't control what goes into 
its authorized libraries then the vulnerability is in management, not in 
the platform."


You are correct - MODESET does not set JSBCAUTH. What I meant to say is:

Some of the vulnerabilities I have discovered in the wild will do the 
following:


 * As part of a APF authorized product there is a SVC or PC routine
   that when called will turn on the JSBCAUTH bit
 * Product application code (psw key 8 problem state not-apf
   authorized) will issue the SVC or PC to turn on JSCBAUTH bit
 * After control returns from SVC or PC routine the application program
   then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH
   bit is on this does not ABEND with S047 - MODESET works.
 * Application code will do "authorized stuff"
 * Application will invoke the SVC or PC routine to turn off the
   JSBCAUTH bit

By dynamically turning on the JSCBAUTH bit allows the application to 
dynamically elevate its z/OS authority (ability to MODESET) which it 
would not normally be allowed to do. Disallowing this type of dynamic 
elevation of z/OS authority would make this kind of code logic unusable. 
It would force those that use this technique to adopt a different, more 
secure approach.



On 5/31/2019 12:21 PM, Seymour J Metz wrote:

The security code path can be modified (if it is non-rent), frontended by using 
content supervision functions (ex - task lib), or bypassed.

Sure, a user can front end parts of the application, he won't have access to 
the production data. Of course, if installation management lets everybody and 
his buddy alter the production JCL, then all bets are off, but then the 
crackers don't need to front end the application.


   *   I don't know who Schiller is. Can you clarify? Thanks.

https://en.wikipedia.org/wiki/Friedrich_Schiller
https://en.wikipedia.org/wiki/The_Maid_of_Orleans_(play)


   * As an example - The platform could make a new integrity rule such
as: Only SVC 107 can turn on JSCBAUTH bit.

Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose that 
IBM prevent key zero code from setting it? Why do think that turning on 
JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the 
installation doesn't control what goes into its authorized libraries then the 
vulnerability is in management, not in the platform.



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


From: IBM Mainframe Discussion List  on behalf of Jesse 1 
Robinson 
Sent: Thursday, May 30, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Just how secure are mainframes? | Trevor Eddolls

It must be Friday somewhere. I put 'against stupidity' into Google. Schiller's 
exact quote popped up first. Just sayin'.

.
.
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 Ray 
Overby
Sent: Thursday, May 30, 2019 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Please note that an unprivileged application can still have a 
dangerous back door that compromises, e.g., privacy, by giving a user authorized to 
access the application access more data than he is authorized to see."

As a developer of security interfaces for applications: It is extremely 
difficult to design an unprivileged application security interface in code that 
runs in PSW Key 8 problem state not apf-authorized. The security code path can 
be modified (if it is non-rent), frontended by using content supervision 
functions (ex - task lib), or bypassed. In addition, application storage areas 
+ ESM (external security manager) credentials cannot be in key 8 storage as the 
application code could accidentally or maliciously modify them.

A properly designed z/OS application would have separate application and system 
level programs and memory objects. These programs would be invoked differently 
(ex - EXEC PGM= vs a SVC or PC routine). The application code would call the 
system level programs whenever an application function needs to be performed 
that requires security checks. In this way the system level code + memory 
objects they reference cannot be accidentally or maliciously compromised by the 
application code or other programs running on the platform.

So called unprivileged application security code is really just application code.  
Important (really). But I do not like calling it security code as it does not meet the 
due diligence required for system level security code. Calling 

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

2019-05-31 Thread Ray Overby

Seymour,

A specific example would help with this discussion. Do you have one?

I will use a TSO ISPF application as my example. The assumption is that 
application security code is PSW KEY 8 problem state code (just like the 
application code). In fact, it could be CLIST or REXX execs as well.


 * The following ways to frontend the application programs (lmods or
   clist or rexx):
 o TSO has TSOLIB command. I could add a non-apf DSN to STEPLIB so
   that when the application programs are fetched they will pick up
   my version of the program instead of the applications.
 o ISPF supports a TASKLIB call ISPLLIB. I could add my non-apf DSN
   to ISPLLIB so that when the application programs are fetched
   they will pick up my version of the program instead of the
   applications.
 o ISPF supports LIBDEF. I could use LIBDEF to add my non-apf DSN
   so that when the application programs are fetched they will pick
   up my version of the program instead of the applications.
 o TSO has ALTLIB command. I could add my CLIST library to SYSPROC
   so that when the application clists (or rexx) are fetched they
   will pick up my version of the program instead of the applications

I have identified some (but not all) of the available ways to frontend 
application programs in a TSO/E environment. If I frontend the security 
module (whether I replace it or copy it and zap off the stuff I don't 
want) does not matter - I will be able to bypass the "so called" 
security controls. If this was a common criteria evaluation for the 
application I would not even have to create an exploit. I would just 
have to document that the security is implemented in the application 
layer - therefore is it always vulnerable.


The TSO user would need access to the data as the security calls would 
probably be performed with the TSO users credentials. More details about 
the TSO/E ISPF application would be required to do further analysis.


If you were referring to CICS as the application to logon to I am not as 
familiar with this environment. It would appear that there are not as 
many options for module frontending here. Can CICS users edit a file, 
type in a rexx exec which uses the REXX STORAGE function and execute the 
rexx exec? If so they may be able to start zapping the CICS region 
private area. This may or more not include the CICS transaction 
programs. I will have to try this to see what I can do ;-) The CICS user 
may be able to logon to TSO to create the rexx exec. And then execute it 
from CICS. I will give this a try.




in 5/31/2019 1:33 PM, Seymour J Metz wrote:

A user who front-ends an application is running with his own credentials; he 
doesn't have access to the production data. A user who simply logs on to the 
application canfront-end it.


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


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

In response to "Please note that an unprivileged application can still
have a dangerous back door that compromises, e.g., privacy, by giving a
user authorized to access the application access more data than he is
authorized to see."

As a developer of security interfaces for applications: It is extremely
difficult to design an unprivileged application security interface in
code that runs in PSW Key 8 problem state not apf-authorized. The
security code path can be modified (if it is non-rent), frontended by
using content supervision functions (ex - task lib), or bypassed. In
addition, application storage areas + ESM (external security manager)
credentials cannot be in key 8 storage as the application code could
accidentally or maliciously modify them.

A properly designed z/OS application would have separate application and
system level programs and memory objects. These programs would be
invoked differently (ex - EXEC PGM= vs a SVC or PC routine). The
application code would call the system level programs whenever an
application function needs to be performed that requires security
checks. In this way the system level code + memory objects they
reference cannot be accidentally or maliciously compromised by the
application code or other programs running on the platform.

So called unprivileged application security code is really just
application code.  Important (really). But I do not like calling it
security code as it does not meet the due diligence required for system
level security code. Calling application code "Unprivileged application
security code" leads people to assume that the code has integrity and
therefore is secure. In most cases, this is not true. It spreads a false
sense of security.

In response to "It can if you don't install the broken application."

   * Must of the code vulnerabilities I find are zero day
 

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

2019-05-31 Thread Ray Overby

In response to "What convention? The z/OS platform is (mostly) secure."

z/OS is the most secure-able platform I know. However, a z/OS 
installation is only secure when the installation configures it 
correctly AND all programs running on the system do not violate the 
statement of integrity. Both must be true or it is not secure.


In response to "If the user adds authorized code then it is no longer 
IBM's platform, and security vulnerabilities caused by not following the 
statement of integrity are vulnerabilities in the installation, not in 
z/OS."


Please assume a TRAP DOOR vulnerability is in IBM, ISV, or installation 
written code for this. That will help focus the discussion.


 * Do the capabilities of the code vulnerability change based on whose
   code the vulnerability is located in? I don't think so - it
   certainly does not for a TRAP DOOR.
 * Does the vulnerability risk to the installation change based upon
   whose code the vulnerability is located in?  I don't think so - it
   certainly does not for a TRAP DOOR.
 * Does the installation, whose mainframe has exploitable code
   vulnerabilities, really care if the vulnerabilities come from IBM,
   ISV's, or installation written code?  Yes, but only because they
   will need to know in order to report the problem to get a fix.

I do not see that your distinction between an "IBM platform" and an 
"Installation Platform" helpful for an installation when it is trying to 
deal with exploitable code vulnerabilities. Perhaps there is a reason 
that I don't see.


Something that might help this discussion (I would suggest this be done 
periodically - for example monthly):


 * How many integrity vulnerabilities are located in an installations
   CSI's GLOBAL zones?
 * How many are in apply status?
 * How many new ones are there each reporting period?

My company does not have access to this data so I don't really know the 
answers. Perhaps someone else could report it (assuming that does not 
violate some legal agreement). Even if you don't report it the 
information may be enlightening.


I think people need to understand - TRAP DOORS (as well as other 
vulnerability categories) exist in IBM, ISV, and installation code on a 
regular basis based upon the data my company has acquired. As others 
have pointed out my company does not find all code vulnerabilities but 
we still have found several hundred. Code vulnerabilities are not a once 
in a lifetime occurrence as most people assume. The numbers are not like 
the other platforms but they are greater than what most would expect. 
Perhaps if someone reports the information in their SMP/E CSI's that 
might shed more light on this subject.


In response to "Now, when *IBM* fails to follow the statement of 
integrity, that *is* a z/OS vulnerability, but when is the last time 
that IBM refused to correct such an error when it was reported?"


I attribute this to Mark Nelson (IBM) - I am paraphrasing - Mark - 
please correct this if I get this wrong - That IBM has corrected all 
accepted integrity problems with one exception. Mark thought that the 
product with the vulnerability was removed from marketing. This one 
exception caused a change to the IBM statement of integrity to "IBM will 
always take action".


I think the problem here is that some people assume that there are no 
integrity problems in IBM code. IBM's statement of integrity clearly 
states that if an integrity problem is found and accepted by IBM that 
they will take some action.  Periodic review of the SMP/E CSI's will 
establish whether or not there are any integrity fix's.



On 5/31/2019 12:29 PM, Seymour J Metz wrote:

What convention? The z/OS platform is (mostly) secure. If the user adds 
authorized code then it is no longer IBM's platform, and security 
vulnerabilities caused by not following the statement of integrity are 
vulnerabilities in the installation, not in z/OS.

Now, when *IBM* fails to follow the statement of integrity, that *is* a z/OS 
vulnerability, but when is the last time that IBM refused to correct such an 
error when it was reported?

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


From: IBM Mainframe Discussion List  on behalf of Wayne 
Driscoll 
Sent: Thursday, May 30, 2019 5:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

If the trap door is in an APF authorized library, then by convention it's part 
of the operating system, and would be considered a platform issue. Anything 
that is APF authorized is expected to adhere to the statement of integrity that 
z/OS publishes.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, May 29, 2019 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls


  A single TRAP DOOR code 

Re: BNDRY=PAGE possible CPU hit?

2019-05-31 Thread Mike Schwab
Week long AMODE 32 thread?  Only a week on IBM main, I think.  Wrong
idea for sure.  Running with 32 bit literals and AMODE 64 would work,
but since address literals are such a small part of programs it does
not make sense and I think would risk branching out of your 4GB memory
area.  The 380 group has been arguing with Paul for months.

On Fri, May 31, 2019 at 12:20 PM Mike Hochee  wrote:
>
> Thanks for all the responses on this one, especially Jim and Peter, and all 
> the links. I unsubscribed from this list some months ago and re-subscribed 
> last night, now realizing how much I might have missed (week-long AMODE32 
> threads notwithstanding)
>
> The info I initially received was from an IBM gent in the z processor group, 
> and was consistent with the Processor Optimization doc pg 31. Some time ago I 
> converted most of our MVCL*s over to MVC and XC instructions, resulting in 
> modest cpu savings. Since that time, I began checking for page alignment of 
> source and target addresses and routing to MVCL* rtns when page aligned, and 
> lastly tried to make things more eligible for ADM or the 'near-memory engine' 
> with BNDRY=PAGE which may have run headlong into fragmentation issue 
> described or...
>
> >  Whether use of the near-memory engine helps or hurts your performance
> > depends on how/when you were using the storage before the MVCL/MVCLE,
> > and how/when you use it after the MVCL/MVCLE.
>
> Thanks again!
> Mike
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Don Poitras
> Sent: Friday, May 31, 2019 10:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: BNDRY=PAGE possible CPU hit?
>
> Expanding the ... leads one to (there might be more, but this is the one I 
> found):
>
> https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/07c69512-ac74-4394-87b9-a61ea201347e/media/IBMzSystemsProcessorOptimizationPrimerv2.pdf
>
> Gratuitous wrap noted.
>
> Other files in this "community" can be found at:
>
> https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=9a17556c-6094-4201-acd0-d8125a3fa0db
>
>
>
> In article 
> 
>  you wrote:
> > See page 31 in this document:
>
> > https://www.ibm.com/.../IBMzSystemsProcessorOptimizationPrimerv2.pdf
>
> >  Whether use of the near-memory engine helps or hurts your performance
> > depends on how/when you were using the storage before the MVCL/MVCLE,
> > and how/when you use it after the MVCL/MVCLE.
>
> > Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> > Poughkeepsie NY
>
> > "IBM Mainframe Discussion List"  wrote on
> > 05/30/2019 11:12:13 PM:
>
> > > From: "Michael Hochee" 
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Date: 05/31/2019 12:31 AM
> > > Subject: BNDRY=PAGE possible CPU hit?
> > > Sent by: "IBM Mainframe Discussion List" 
> > >
> > > Hi,
> > > I recently added the BNDRY=PAGE parameter to a set of STORAGE
> > > OBTAINS which acquire storage areas of various sizes from several
> > > low private  subpools. My intent was a reduction of CPU used by
> > > subsequent MVCLE instructions, as ADM would more likely be employed
> > > for MVCLE executes, since the storage areas involved were page
> > > aligned (apparently an ADM pre-req.)  Unfortunately my initial
> > > testing revealed a significant increase in CPU consumption, rather
> > > than a reduction.
> > >
> > > I did a few searches of the IBM-MAIN archive and found nothing
> > > involving increased CPU overhead resulting from BNDRY=PAGE usage.
> > > Any thoughts on what might be causing the elevated CPU?  Again, the
> > > only change made was adding BNDRY=PAGE. (I have since backed the
> > > change off, tested, reapplied the change and tested with the same
> > results)
>
> --
> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com   (919) 531-5637Cary, NC 27513
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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


ISPF Development Tips and Tricks package updated

2019-05-31 Thread Lionel Dyck
The ISPF Development Tips and Tricks package has been updated to release 1.1 
and is now available on my personal website at 
www.lbdsoftware.com for all to enjoy.

This update incorporates several updates suggested by the readers of the 
initial 1.0 release. Both the documentation and the sample code are updated.


Lionel B. Dyck 



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


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

2019-05-31 Thread Seymour J Metz
A user who front-ends an application is running with his own credentials; he 
doesn't have access to the production data. A user who simply logs on to the 
application canfront-end it.


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


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

In response to "Please note that an unprivileged application can still
have a dangerous back door that compromises, e.g., privacy, by giving a
user authorized to access the application access more data than he is
authorized to see."

As a developer of security interfaces for applications: It is extremely
difficult to design an unprivileged application security interface in
code that runs in PSW Key 8 problem state not apf-authorized. The
security code path can be modified (if it is non-rent), frontended by
using content supervision functions (ex - task lib), or bypassed. In
addition, application storage areas + ESM (external security manager)
credentials cannot be in key 8 storage as the application code could
accidentally or maliciously modify them.

A properly designed z/OS application would have separate application and
system level programs and memory objects. These programs would be
invoked differently (ex - EXEC PGM= vs a SVC or PC routine). The
application code would call the system level programs whenever an
application function needs to be performed that requires security
checks. In this way the system level code + memory objects they
reference cannot be accidentally or maliciously compromised by the
application code or other programs running on the platform.

So called unprivileged application security code is really just
application code.  Important (really). But I do not like calling it
security code as it does not meet the due diligence required for system
level security code. Calling application code "Unprivileged application
security code" leads people to assume that the code has integrity and
therefore is secure. In most cases, this is not true. It spreads a false
sense of security.

In response to "It can if you don't install the broken application."

  * Must of the code vulnerabilities I find are zero day
vulnerabilities. This means there is no fix. If there is no fix then
it is almost 100% certain that the client installing and/or running
the product would have no idea that they are installing/running a
back door on their system.
  * Before you install a product (how often does that happen these
days?) do you ensure that all maintenance is applied or just hipers?
What about integrity fix's? You probably have a different answer
depending upon which vendor it is

In response to "To quote Schiller, "Against stupidity the gods themselves 
contend in vain." The OS can prevent am unauthorized application from accessing 
unauthorized data or elevating its privileges; it cannot prevent the 
application from violating its own specifications. The OS also cannot protect 
against malicious modifications; it's a management responsibility to vet 
personnel and 3rd party providing OS changes and other privileged code."

  *   I don't know who Schiller is. Can you clarify? Thanks.
  * As an example - The platform could make a new integrity rule such
as: Only SVC 107 can turn on JSCBAUTH bit. Any other SVC or any PC
routine that does it will abend with S047-98 (yes, I just created a
new abend code for integrity - Byte me!). This would render useless
most of the currently implemented "magic SVC or PC routines" that
turn on JSCBAUTH bit that are running in the wild today (FYI - this
is another sub-category of a TRAP DOOR vulnerability). There are
ways to get around this (several come to mind as I write this)
however I would ague that a change like this would benefit all users
of the platform. The same business arguments that were used to
eliminate Key 8 common storage usage could be used for this change.
With similar benefits.

On 5/30/2019 10:28 AM, Seymour J Metz wrote:
>> Does it really matter if an application vs z/OS has a trap door 
>> vulnerability?
> Not if you don't care about security. If you care then you must investigate 
> both. Please note that an unprivileged application can still have a dangerous 
> back door that compromises, e.g., privacy, by giving a user authorized to 
> access the application access more data than he is authorized to see.
>
>> In either case z/OS and the ESM's cannot function
>> properly when the TRAP DOOR vulnerability is exploited.
> It can if you don't install the broken application.
>
>> Shouldn't z/OS be able to protect itself from accidental and/or malicious 
>> vulnerabilities?
> To quote Schiller, "Against stupidity the gods themselves contend in vain." 
> The OS can prevent am unauthorized application from 

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

2019-05-31 Thread Seymour J Metz
What convention? The z/OS platform is (mostly) secure. If the user adds 
authorized code then it is no longer IBM's platform, and security 
vulnerabilities caused by not following the statement of integrity are 
vulnerabilities in the installation, not in z/OS.

Now, when *IBM* fails to follow the statement of integrity, that *is* a z/OS 
vulnerability, but when is the last time that IBM refused to correct such an 
error when it was reported?

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


From: IBM Mainframe Discussion List  on behalf of 
Wayne Driscoll 
Sent: Thursday, May 30, 2019 5:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

If the trap door is in an APF authorized library, then by convention it's part 
of the operating system, and would be considered a platform issue. Anything 
that is APF authorized is expected to adhere to the statement of integrity that 
z/OS publishes.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, May 29, 2019 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

>  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
https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C4ec98728280a4395aab708d6e46ff2fd%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636947566821955527sdata=Ggtx2UoZolPoAJZgbcdFshw16B%2B1Yy998xUO7Bts%2FzU%3Dreserved=0


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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 

Re: Just how secure are mainframes? | Trevor Eddolls

2019-05-31 Thread Seymour J Metz
> The security code path can be modified (if it is non-rent), frontended by 
> using content supervision functions (ex - task lib), or bypassed.

Sure, a user can front end parts of the application, he won't have access to 
the production data. Of course, if installation management lets everybody and 
his buddy alter the production JCL, then all bets are off, but then the 
crackers don't need to front end the application.

>   *   I don't know who Schiller is. Can you clarify? Thanks.

https://en.wikipedia.org/wiki/Friedrich_Schiller
https://en.wikipedia.org/wiki/The_Maid_of_Orleans_(play)

>   * As an example - The platform could make a new integrity rule such
>as: Only SVC 107 can turn on JSCBAUTH bit.

Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose that 
IBM prevent key zero code from setting it? Why do think that turning on 
JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the 
installation doesn't control what goes into its authorized libraries then the 
vulnerability is in management, not in the platform.



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


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, May 30, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Just how secure are mainframes? | Trevor Eddolls

It must be Friday somewhere. I put 'against stupidity' into Google. Schiller's 
exact quote popped up first. Just sayin'.

.
.
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 Ray 
Overby
Sent: Thursday, May 30, 2019 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Please note that an unprivileged application can still have a 
dangerous back door that compromises, e.g., privacy, by giving a user 
authorized to access the application access more data than he is authorized to 
see."

As a developer of security interfaces for applications: It is extremely 
difficult to design an unprivileged application security interface in code that 
runs in PSW Key 8 problem state not apf-authorized. The security code path can 
be modified (if it is non-rent), frontended by using content supervision 
functions (ex - task lib), or bypassed. In addition, application storage areas 
+ ESM (external security manager) credentials cannot be in key 8 storage as the 
application code could accidentally or maliciously modify them.

A properly designed z/OS application would have separate application and system 
level programs and memory objects. These programs would be invoked differently 
(ex - EXEC PGM= vs a SVC or PC routine). The application code would call the 
system level programs whenever an application function needs to be performed 
that requires security checks. In this way the system level code + memory 
objects they reference cannot be accidentally or maliciously compromised by the 
application code or other programs running on the platform.

So called unprivileged application security code is really just application 
code.  Important (really). But I do not like calling it security code as it 
does not meet the due diligence required for system level security code. 
Calling application code "Unprivileged application security code" leads people 
to assume that the code has integrity and therefore is secure. In most cases, 
this is not true. It spreads a false sense of security.

In response to "It can if you don't install the broken application."

  * Must of the code vulnerabilities I find are zero day
vulnerabilities. This means there is no fix. If there is no fix then
it is almost 100% certain that the client installing and/or running
the product would have no idea that they are installing/running a
back door on their system.
  * Before you install a product (how often does that happen these
days?) do you ensure that all maintenance is applied or just hipers?
What about integrity fix's? You probably have a different answer
depending upon which vendor it is

In response to "To quote Schiller, "Against stupidity the gods themselves 
contend in vain." The OS can prevent am unauthorized application from accessing 
unauthorized data or elevating its privileges; it cannot prevent the 
application from violating its own specifications. The OS also cannot protect 
against malicious modifications; it's a management responsibility to vet 
personnel and 3rd party providing OS changes and other privileged code."

  *   I don't know who Schiller is. Can you clarify? Thanks.
  * As an example - The platform could make a new integrity rule such
as: Only SVC 107 can turn on JSCBAUTH bit. Any other SVC or any PC
routine that does it will abend with 

Re: BNDRY=PAGE possible CPU hit?

2019-05-31 Thread Mike Hochee
Thanks for all the responses on this one, especially Jim and Peter, and all the 
links. I unsubscribed from this list some months ago and re-subscribed last 
night, now realizing how much I might have missed (week-long AMODE32 threads 
notwithstanding)   

The info I initially received was from an IBM gent in the z processor group, 
and was consistent with the Processor Optimization doc pg 31. Some time ago I 
converted most of our MVCL*s over to MVC and XC instructions, resulting in 
modest cpu savings. Since that time, I began checking for page alignment of 
source and target addresses and routing to MVCL* rtns when page aligned, and 
lastly tried to make things more eligible for ADM or the 'near-memory engine' 
with BNDRY=PAGE which may have run headlong into fragmentation issue described 
or... 

>  Whether use of the near-memory engine helps or hurts your performance 
> depends on how/when you were using the storage before the MVCL/MVCLE, 
> and how/when you use it after the MVCL/MVCLE.

Thanks again! 
Mike 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Don Poitras
Sent: Friday, May 31, 2019 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BNDRY=PAGE possible CPU hit?

Expanding the ... leads one to (there might be more, but this is the one I 
found):

https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/07c69512-ac74-4394-87b9-a61ea201347e/media/IBMzSystemsProcessorOptimizationPrimerv2.pdf

Gratuitous wrap noted.

Other files in this "community" can be found at:

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=9a17556c-6094-4201-acd0-d8125a3fa0db



In article 

 you wrote:
> See page 31 in this document:

> https://www.ibm.com/.../IBMzSystemsProcessorOptimizationPrimerv2.pdf

>  Whether use of the near-memory engine helps or hurts your performance 
> depends on how/when you were using the storage before the MVCL/MVCLE, 
> and how/when you use it after the MVCL/MVCLE.

> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY

> "IBM Mainframe Discussion List"  wrote on
> 05/30/2019 11:12:13 PM:

> > From: "Michael Hochee" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 05/31/2019 12:31 AM
> > Subject: BNDRY=PAGE possible CPU hit?
> > Sent by: "IBM Mainframe Discussion List" 
> > 
> > Hi,
> > I recently added the BNDRY=PAGE parameter to a set of STORAGE 
> > OBTAINS which acquire storage areas of various sizes from several 
> > low private  subpools. My intent was a reduction of CPU used by 
> > subsequent MVCLE instructions, as ADM would more likely be employed 
> > for MVCLE executes, since the storage areas involved were page 
> > aligned (apparently an ADM pre-req.)  Unfortunately my initial 
> > testing revealed a significant increase in CPU consumption, rather 
> > than a reduction.
> > 
> > I did a few searches of the IBM-MAIN archive and found nothing 
> > involving increased CPU overhead resulting from BNDRY=PAGE usage.
> > Any thoughts on what might be causing the elevated CPU?  Again, the 
> > only change made was adding BNDRY=PAGE. (I have since backed the 
> > change off, tested, reapplied the change and tested with the same
> results)

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

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

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


Re: BATCH JOB TO RUN GRS COMMAND

2019-05-31 Thread Willie Bunter
Thanks John.  I will check out the SDSF option.

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


Re: BATCH JOB TO RUN GRS COMMAND

2019-05-31 Thread John McKown
On Fri, May 31, 2019 at 11:50 AM Willie Bunter <
00ff0e22811f-dmarc-requ...@listserv.ua.edu> wrote:

> I tried the job  but nothing was displayed.
>
>
Most likely your shop is set up to disallow issuing commands that way. I
had another thought. But I don't have any example code. But you can use
SDSF to issue operator command. You can run a batch job using PGM=SDSF or
PGM=ISFAFD documented here:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.isfa600/batchy.htm

Or write a REXX program which uses the SDSF REXX API as documented here:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.isfa600/rexx.htm

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.isfa600/rxsl2.htm


I think this needs to run via IKJEFT01 (or IKJEFT1A or IKJEFT1B).



-- 
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: BATCH JOB TO RUN GRS COMMAND

2019-05-31 Thread Willie Bunter
I tried the job  but nothing was displayed.

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


Re: BATCH JOB TO RUN GRS COMMAND

2019-05-31 Thread John McKown
On Fri, May 31, 2019 at 11:33 AM willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> Hallo All,
> Would anybody have an example to run the GRS command for the following
> dsn  via a batch job :
>  DGRS,RES=(*,SYS1.LINKLIB)
> Thanks in advance
>
>
This worked for me  on my system. But the INTRDR must be set to allow
commands.

//DOCMD9XX JOB (H0I),MCKOWN,CLASS=Z,MSGCLASS=X,NOTIFY=
// COMMAND 'D GRS,RES=(*,SYS1.LINKLIB)'
//ALLOC EXEC PGM=IEFBR14

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


BATCH JOB TO RUN GRS COMMAND

2019-05-31 Thread willie bunter
Hallo All,
Would anybody have an example to run the GRS command for the following dsn  via 
a batch job :
 DGRS,RES=(*,SYS1.LINKLIB)
Thanks in advance

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


Re: CTC (FCTC) usage

2019-05-31 Thread Munif Sadek
Thanks a lot  for so many replies.
My basic question still remains the same..where all CTC(FCTC) can be used under 
zOS  and all required configurations. Do agree HCD/IOCP is very well documented 
but  not the applications, VTAM, IP configurations.
regards
Munif

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


Re: How to delete and allocate files in bpxbatch

2019-05-31 Thread Paul Gilmartin
On Fri, 31 May 2019 08:26:50 -0400, Billy Ashton wrote:

>Hi John, I am getting ready to go away for a few days, and when I get back
>I will give you a mockup of my workflow so you can see what's what. Thanks
>for helping!
> 
Thoughts on this:

Might your dangling ENQ (EDC5061I) occur because you have
_BPX_SHAREAS=MAYBE?  Would _BPX_SHAREAS=NO cp
mitigiate this?

I believe ssh, scp, and sftp are all wrappers around a comon core,
their functions and entitlements are largely interchanbable, and:
o sftp performs pure binary transfers
o scp is text-oriented (possibly performing CRLF conversion?)
o z/OS (only?) ssh performs ISO8859-1<->IBM-1047 conversion.
  I've been able to circumvent this by piping through iconv on
  the z/OS side.  (Do I hear Kirk snickering?)
o Co:Z may provide options to suppress some of these misbehaviors.
o I hate EBCDIC!

AMATERSE UNPACK performs an inane check on (DEVTYPE of
the first catenand of?) SYSUT1, prohibiting UNIX files.  I can
circumvent this by supplying as SYSUT1 a concatenation of:
o (first) an empty temp PS CKD dataset
o a UNIX file (I don't recall trying this with a pipe).

Rexx may be more suitable than sh.  z/OS likes Rexx.

Rexx can invoke AMATERSE with ADDRESS LINKMVS AMATERSE.
This passes allocated DDNAMES (with their ENQs) to AMATERSE.

If Rexx is invoked from sh, it can invoke shell commands
with ADDRESS SH.

If Rexx is invoked from any environment it can invoke
POSIX functions with ADDRESS SYSCALL (cumbersome)
or shell commands with BPXWUNIX (simpler).

There's a prevalent misconception that BPXWUNIX stdin,
stdout, and stderr can only be compound stems or STACK.
In fact, any of those streams can be:
o stem,
o STACK,
o pre-allocated DDNAME, or
o pre-existing descriptor 0, 1, or 2 (e.g. a pipe).

-- gil

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


SAP Processor Utilization

2019-05-31 Thread Richards, Robert B.
Is there a way, a tool, etc. to measure "historical" SAP utilization? 

We are aware of the real time Monitor Dashboard's various displays on the HMC.

Bob

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


Re: ads on Knowledge Center?

2019-05-31 Thread Elardus Engelbrecht
Susan Shumway wrote:

>Yikes, thanks for the notice! We alerted the KC folks and they confirmed that 
>it's a glitch with DISQUS. They disabled the functionality until a fix is 
>found. 

Thanks Susan! Much appreciated.

I did not have time to check why my browsers are different (showing ads or 
not), but as soon as I see this glitch again, I will then compare these 
browsers.

At least this will spare all of us unneeded bandwidth. 

Thanks again! ;-)

Groete / Greetings
Elardus Engelbrecht

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


Re: BNDRY=PAGE possible CPU hit?

2019-05-31 Thread Don Poitras
Expanding the ... leads one to (there might be more, but this is the one
I found):

https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/07c69512-ac74-4394-87b9-a61ea201347e/media/IBMzSystemsProcessorOptimizationPrimerv2.pdf

Gratuitous wrap noted.

Other files in this "community" can be found at:

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=9a17556c-6094-4201-acd0-d8125a3fa0db



In article 

 you wrote:
> See page 31 in this document:

> https://www.ibm.com/.../IBMzSystemsProcessorOptimizationPrimerv2.pdf 

>  Whether use of the near-memory engine helps or hurts your performance
> depends on how/when you were using the storage before the MVCL/MVCLE, and 
> how/when you use it after the MVCL/MVCLE. 

> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY

> "IBM Mainframe Discussion List"  wrote on 
> 05/30/2019 11:12:13 PM:

> > From: "Michael Hochee" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 05/31/2019 12:31 AM
> > Subject: BNDRY=PAGE possible CPU hit?
> > Sent by: "IBM Mainframe Discussion List" 
> > 
> > Hi, 
> > I recently added the BNDRY=PAGE parameter to a set of STORAGE 
> > OBTAINS which acquire storage areas of various sizes from several 
> > low private  subpools. My intent was a reduction of CPU used by 
> > subsequent MVCLE instructions, as ADM would more likely be employed 
> > for MVCLE executes, since the storage areas involved were page 
> > aligned (apparently an ADM pre-req.)  Unfortunately my initial 
> > testing revealed a significant increase in CPU consumption, rather 
> > than a reduction. 
> > 
> > I did a few searches of the IBM-MAIN archive and found nothing 
> > involving increased CPU overhead resulting from BNDRY=PAGE usage. 
> > Any thoughts on what might be causing the elevated CPU?  Again, the 
> > only change made was adding BNDRY=PAGE. (I have since backed the 
> > change off, tested, reapplied the change and tested with the same 
> results) 

-- 
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: BNDRY=PAGE possible CPU hit?

2019-05-31 Thread John McKown
On Fri, May 31, 2019 at 9:30 AM Jim Mulder  wrote:

> See page 31 in this document:
>
> https://www.ibm.com/.../IBMzSystemsProcessorOptimizationPrimerv2.pdf
>

I got a 404 on that page. What is supposed to be in the /.../ portion? That
link, for me in Gmail, is actually "/.../"

But I got the pdf here:

https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/07c69512-ac74-4394-87b9-a61ea201347e/media/IBMzSystemsProcessorOptimizationPrimerv2.pdf



>
>  Whether use of the near-memory engine helps or hurts your performance
> depends on how/when you were using the storage before the MVCL/MVCLE, and
> how/when you use it after the MVCL/MVCLE.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
> "IBM Mainframe Discussion List"  wrote on
> 05/30/2019 11:12:13 PM:
>
> > From: "Michael Hochee" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 05/31/2019 12:31 AM
> > Subject: BNDRY=PAGE possible CPU hit?
> > Sent by: "IBM Mainframe Discussion List" 
> >
> > Hi,
> > I recently added the BNDRY=PAGE parameter to a set of STORAGE
> > OBTAINS which acquire storage areas of various sizes from several
> > low private  subpools. My intent was a reduction of CPU used by
> > subsequent MVCLE instructions, as ADM would more likely be employed
> > for MVCLE executes, since the storage areas involved were page
> > aligned (apparently an ADM pre-req.)  Unfortunately my initial
> > testing revealed a significant increase in CPU consumption, rather
> > than a reduction.
> >
> > I did a few searches of the IBM-MAIN archive and found nothing
> > involving increased CPU overhead resulting from BNDRY=PAGE usage.
> > Any thoughts on what might be causing the elevated CPU?  Again, the
> > only change made was adding BNDRY=PAGE. (I have since backed the
> > change off, tested, reapplied the change and tested with the same
> results)
>
>
>
> --
> 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: [External] Re: ads on Knowledge Center?

2019-05-31 Thread Ronald Kristel
Thank you Sue. Much appreciated!!

Ronald Kristel

From: IBM Mainframe Discussion List  on behalf of 
Pommier, Rex 
Sent: Friday, May 31, 2019 4:14:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: ads on Knowledge Center?

Thanks, Sue, for all you do to keep the documentation usable.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Susan Shumway
Sent: Friday, May 31, 2019 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: ads on Knowledge Center?

Hi all,

Yikes, thanks for the notice! We alerted the KC folks and they confirmed that 
it's a glitch with DISQUS. They disabled the functionality until a fix is 
found. Unfortunately, you'll now need to look elsewhere if you want links to 
learn how to "Forget Your 401K if you Own a Home (Do This)."

Yours truly,
Sue Shumway

Thanks for alerting us!
On 5/31/2019 4:58 AM, Ronald Kristel wrote:
> Hi,
>
> Is anyone else also getting ads in Knowledge Center?
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zo
> s.v2r3.adru000/r2321.htm
>
> This page for example shows a dozen ads that seems to be part of the 
> DISQUS/forum plugin at the bottom of the page.
>
> Ronald Kristel
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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


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

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


Re: BNDRY=PAGE possible CPU hit?

2019-05-31 Thread Jim Mulder
See page 31 in this document:

https://www.ibm.com/.../IBMzSystemsProcessorOptimizationPrimerv2.pdf 

 Whether use of the near-memory engine helps or hurts your performance
depends on how/when you were using the storage before the MVCL/MVCLE, and 
how/when you use it after the MVCL/MVCLE. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

"IBM Mainframe Discussion List"  wrote on 
05/30/2019 11:12:13 PM:

> From: "Michael Hochee" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/31/2019 12:31 AM
> Subject: BNDRY=PAGE possible CPU hit?
> Sent by: "IBM Mainframe Discussion List" 
> 
> Hi, 
> I recently added the BNDRY=PAGE parameter to a set of STORAGE 
> OBTAINS which acquire storage areas of various sizes from several 
> low private  subpools. My intent was a reduction of CPU used by 
> subsequent MVCLE instructions, as ADM would more likely be employed 
> for MVCLE executes, since the storage areas involved were page 
> aligned (apparently an ADM pre-req.)  Unfortunately my initial 
> testing revealed a significant increase in CPU consumption, rather 
> than a reduction. 
> 
> I did a few searches of the IBM-MAIN archive and found nothing 
> involving increased CPU overhead resulting from BNDRY=PAGE usage. 
> Any thoughts on what might be causing the elevated CPU?  Again, the 
> only change made was adding BNDRY=PAGE. (I have since backed the 
> change off, tested, reapplied the change and tested with the same 
results) 



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


Re: [External] Re: ads on Knowledge Center?

2019-05-31 Thread Pommier, Rex
Thanks, Sue, for all you do to keep the documentation usable.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Susan Shumway
Sent: Friday, May 31, 2019 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: ads on Knowledge Center?

Hi all,

Yikes, thanks for the notice! We alerted the KC folks and they confirmed that 
it's a glitch with DISQUS. They disabled the functionality until a fix is 
found. Unfortunately, you'll now need to look elsewhere if you want links to 
learn how to "Forget Your 401K if you Own a Home (Do This)."

Yours truly,
Sue Shumway

Thanks for alerting us!
On 5/31/2019 4:58 AM, Ronald Kristel wrote:
> Hi,
> 
> Is anyone else also getting ads in Knowledge Center?
> 
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zo
> s.v2r3.adru000/r2321.htm
> 
> This page for example shows a dozen ads that seems to be part of the 
> DISQUS/forum plugin at the bottom of the page.
> 
> Ronald Kristel
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 

--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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


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: BNDRY=PAGE possible CPU hit?

2019-05-31 Thread Martin Packer
My thought was that perhaps the STORAGE OBTAIN or GETMAIN on a page 
boundary might be more expensive than a non-aligned one. If the OP were 
doing that repeatedly it might matter.

But I might be talking twaddle. :-)

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Peter Relson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   31/05/2019 14:43
Subject:Re: BNDRY=PAGE possible CPU hit?
Sent by:IBM Mainframe Discussion List 



If you add BNDRY=PAGE to every obtain regardless of size you likely waste 
storage. VSM would not be able to satisfy multiple requests from the same 
page, for example. Wasting storage can translate to worse performance in a 

lot of ways.

I seem to recall that MVCLE is not a good performance choice in general, 
so should be avoided unless there is reason to think that the needed 
length could exceed 16M. That recollection might be wrong. 

Your thought process behind adding BNDRY=PAGE seems somewhat flawed. I'm 
not sure exactly what you're referring to with "ADM" (since in at least 
some cases ADM refers to devices, not simply storage, and z/Architecture 
does not include the asynchronous data mover of ESA/390). If you are 
manipulating storage via MVCL, the main machine optimization for MVCL 
involves full pages on a full page boundary so would never come into play. 

If it's exactly a page, you ought to determine whether you're going to 
reference the target soon or not, and consider using XC's/MVC's if you 
are, since one of the MVCL optimization avoids bringing the storage into 
L1 cache. If your storage exceeds a page, then in most cases you'll land 
with a full page on a page boundary being part of the area (whether at the 

beginning or the end), so the number of full pages on page boundary in 
your area might not depend on your use of BNDRY=PAGE.

Peter Relson
z/OS Core Technology Design


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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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


Re: BNDRY=PAGE possible CPU hit?

2019-05-31 Thread Peter Relson
If you add BNDRY=PAGE to every obtain regardless of size you likely waste 
storage. VSM would not be able to satisfy multiple requests from the same 
page, for example. Wasting storage can translate to worse performance in a 
lot of ways.

I seem to recall that MVCLE is not a good performance choice in general, 
so should be avoided unless there is reason to think that the needed 
length could exceed 16M. That recollection might be wrong. 

Your thought process behind adding BNDRY=PAGE seems somewhat flawed. I'm 
not sure exactly what you're referring to with "ADM" (since in at least 
some cases ADM refers to devices, not simply storage, and z/Architecture 
does not include the asynchronous data mover of ESA/390). If you are 
manipulating storage via MVCL, the main machine optimization for MVCL 
involves full pages on a full page boundary so would never come into play. 
If it's exactly a page, you ought to determine whether you're going to 
reference the target soon or not, and consider using XC's/MVC's if you 
are, since one of the MVCL optimization avoids bringing the storage into 
L1 cache. If your storage exceeds a page, then in most cases you'll land 
with a full page on a page boundary being part of the area (whether at the 
beginning or the end), so the number of full pages on page boundary in 
your area might not depend on your use of BNDRY=PAGE.

Peter Relson
z/OS Core Technology Design


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


Re: ads on Knowledge Center?

2019-05-31 Thread Susan Shumway

Hi all,

Yikes, thanks for the notice! We alerted the KC folks and they confirmed 
that it's a glitch with DISQUS. They disabled the functionality until a 
fix is found. Unfortunately, you'll now need to look elsewhere if you 
want links to learn how to "Forget Your 401K if you Own a Home (Do This)."


Yours truly,
Sue Shumway

Thanks for alerting us!
On 5/31/2019 4:58 AM, Ronald Kristel wrote:

Hi,

Is anyone else also getting ads in Knowledge Center?

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2321.htm

This page for example shows a dozen ads that seems to be part of the 
DISQUS/forum plugin at the bottom of the page.

Ronald Kristel

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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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


Re: RSUs

2019-05-31 Thread Kurt Quackenbush

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


Not exactly. It is a set of PTFs that have been extensively tested together by 
IBM.
Then they have been adopted as a whole by many shops.


Is that true? I thought it was just the CST that was extensively tested; that's 
only released quarterly, whereas RSUs are released every month.

IBM's RSU (Recommended Service Update) is assigned like this:

IBM's monthly RSUs (RSUyy01, 02, 04, 05, 07, ...) identify PTFs that fix 
HIPER, PE, Security/Integrity, or pervasive problems *AND* have 
completed a 30 day CST (Consolidated Service Test) cycle.


IBM's quarterly RSUs (RSUyy03, 06, 09, 12) identify the usual monthly 
RSU PTFs as described above, plus all other PTFs that have completed at 
least a 90 day CST cycle.


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


RMM Retention Method(EXPDT)

2019-05-31 Thread Benik, John E
I'm wondering if any of you are currently using the RMM retention 
method(expdt)?  We are using it on one system and looking at implementing it on 
all of our systems running RMM now that we are z/OS 2.3.  If you are using it 
can you share your  experiences or issues you ran into migrating to this?

Sincerely,

John Benik



This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

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


Re: How to delete and allocate files in bpxbatch

2019-05-31 Thread John McKown
On Fri, May 31, 2019 at 7:27 AM Billy Ashton  wrote:

> Hi John, I am getting ready to go away for a few days, and when I get back
> I will give you a mockup of my workflow so you can see what's what. Thanks
> for helping!
>

Hope you have fun while away. I am not currently busy, so having something
to do is interesting.



>
> Billy
>

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


Maranatha! <><
John McKown

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


Re: How to delete and allocate files in bpxbatch

2019-05-31 Thread Billy Ashton
Hi John, I am getting ready to go away for a few days, and when I get back
I will give you a mockup of my workflow so you can see what's what. Thanks
for helping!

Billy

On Wed, May 29, 2019 at 10:58 AM John McKown 
wrote:

> 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 <
> john.archie.mck...@gmail.com>
> > 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
>
> 

Re: ads on Knowledge Center?

2019-05-31 Thread Steve Horein
Yes, I'm seeing it too,
I hate seeing the direction IBM continues to move in.


On Fri, May 31, 2019 at 3:59 AM Ronald Kristel 
wrote:

> Hi,
>
> Is anyone else also getting ads in Knowledge Center?
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2321.htm
>
> This page for example shows a dozen ads that seems to be part of the
> DISQUS/forum plugin at the bottom of the page.
>
> Ronald Kristel
>
> --
> 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: BNDRY=PAGE possible CPU hit?

2019-05-31 Thread Binyamin Dissen
On Thu, 30 May 2019 22:12:13 -0500 Michael Hochee 
wrote:

:>I recently added the BNDRY=PAGE parameter to a set of STORAGE OBTAINS which 
acquire storage areas of various sizes from several low private  subpools. My 
intent was a reduction of CPU used by subsequent MVCLE instructions, as ADM 
would more likely be employed for MVCLE executes, since the storage areas 
involved were page aligned (apparently an ADM pre-req.)  Unfortunately my 
initial testing revealed a significant increase in CPU consumption, rather than 
a reduction. 

:>I did a few searches of the IBM-MAIN archive and found nothing involving 
increased CPU overhead resulting from BNDRY=PAGE usage. Any thoughts on what 
might be causing the elevated CPU?  Again, the only change made was adding 
BNDRY=PAGE. (I have since backed the change off, tested, reapplied the change 
and tested with the same results) 

Might it be that the page aligned storage is less likely to be assigned at
GETMAIN time, waiting for first reference, thus guaranteeing page-fault
processing?

Try fetching/altering one byte on the page before doing the timing.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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


ads on Knowledge Center?

2019-05-31 Thread Ronald Kristel
Hi,

Is anyone else also getting ads in Knowledge Center? 

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2321.htm
 

This page for example shows a dozen ads that seems to be part of the 
DISQUS/forum plugin at the bottom of the page. 

Ronald Kristel

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