Re: Data Set Commander Monitor (DSCMON) Access Authority

[Robert S. Hansel]

Hi Mike,

We occasionally come across undefined-users, and they are usually the result of 
errors in setting up STARTED profiles. On rare occasions, we encounter 
installations that have not activated SETROPTS JES(BATCHALLRACF), which, as you 
point out, if not activated, can allow undefined-user batch jobs to execute. 
Most installations do not generate daily/weekly reports on undefined users, so 
they go unnoticed unless the lack of an ID causes a security violation.

Regards, Bob

Robert S. Hansel   2024 IBM Champion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-Original Message-
Date:Tue, 25 Jun 2024 11:22:17 -0500
From:Mike Cairns 
Subject: Re: Data Set Commander Monitor (DSCMON) Access Authority

Hi Peter,

Radoslaw and I probably spend more time over on the RACF_L list than here on 
IBM-MAIN, but I still like to keep an eye open here.

The use of ID(*) ACCESS(READ) is well known among the RACF community as the 
'preferred' option to UACC nowadays, and the reason you cite is indeed 
mentioned in the literature.  Though I'm not sure about the NJE port of entry 
still being able to actually get a batch job running under the JES 
UNDEFINEDUSER, I have a recollection that the RACF SETROPTS setting 
BATCHALLRACF(YES) should prevent a batch job from initiating with the 
UNDEFINEDUSER value, though I have a vague recollection that BATCHALLRACF 
itself has been redundant also for many years now as well.

I'm intrigued generally to ask of this community, just how often does anyone 
observe work executing on their system *without* a valid RACF (or ACF2 or 
TopSecret) identity associated with it?  

I think there might still be one or two started tasks, probably running as 
TRUSTED or PRIVILEGED, that are initiated in nucleus initialisation that may 
still run with traditionally either the 8 plusses or the 8 question marks as 
their ID, we can see them in SDSF, but realistically I don't believe that we 
see work running under the UNDEFINEDUSER in modern systems for a long time 
nowadays.  I'd be keen to hear otherwise if there is though.

Cheers - Mike

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

Re: TSO PREFIX change

[Robert S. Hansel]

Hi Juan,

I've typically seen this done in TSO logon PROCs that execute a CLIST or REXX 
program that executes the PROFILE command to automatically reset the PREFIX for 
the user during each logon.

Regards, Bob

Robert S. Hansel   2024 IBM Champion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-Original Message-
Date:Tue, 25 Jun 2024 16:38:37 +
From:"jgmauta...@yahoo.com.ar" 
Subject: TSO PREFIX change

Hi!
Is there a way for an administrator to change the TSO PREFIX of another RACF 
userid?
Reason for asking:When a new TSO userid is created, we need to set its TSO 
PREFIX to a value different from "USERID" (the default). Basically, as we 
generally dont allow USER datasets, we need to set the TSO PREFIX of any TSO 
userid to their "default group". In order to achieve this, just after running 
the ADDUSER RACF command, the administrator enters TSO for the first time using 
the just-created userid credentials and runs the "PROF PREFIX()" command. 
Not a very clean solution, indeed...


Thanks in advance for your help,

Juan Mautalen

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

Re: z/OS 3.1 Enhancements & Support News

[Seymour J Metz]

Any chance of getting version and release numbers into language announcements?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Tuesday, June 25, 2024 11:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1 Enhancements & Support News

Jim Horne asks:

>This looks interesting. Is it available for prior releases, or just

>z/OS 3.1?



I mentioned in my post that the IBM Open Enterprise SDK(*) for Python and IBM Z 
Open Automation Utilities runs on z/OS 2.4 and higher. The IBM Open Enterprise 
Foundation for z/OS runs on z/OS 2.5 and higher.



(*) Sorry for the typo in the original post. SDK is correct.

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
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: CPU and I/O statistics for BPXBATCH executions?

[Seymour J Metz]

There are several issues for Unix measurement.

 1. If the installation chooses to run multiple processes in a single AS,
I know of no way to separate the data for individual processes. Is
there a new SMF record type for that purpose?

 2. The converse issue is aggregating all of data for processes
spawned by a single job. Is there anything in the type 30 to
identify the original job?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Feller <05aa34d46684-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, June 25, 2024 9:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU and I/O statistics for BPXBATCH executions?

Peter, from what I recall I believe the information around Unix System
Services stuff along with zIIP activity should be available to the IEFACTRT
exit.  There is information in the SMF 30 record related to Unix activity
and zIIP activity.  I'm guessing it's a matter of updating the exit to pull
the data from the proper SMF 30 fields.  My guess would be that no one
considered updating the exit as new stuff got added to the different parts
of the SMF 30 data.


I'm guessing you are talking about the IEF032I (or IEF033I) message when you
refer to the JESSYSMSG message.  I don't really know if IBM tries to account
for any of the activity in Unix land or activity on the zIIP.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Farley, Peter
Sent: Tuesday, June 25, 2024 7:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CPU and I/O statistics for BPXBATCH executions?

Hi All,

Just a question of curiosity.  In recent days I have been running some
ad-hoc BPXBATCH jobs that executes some "cp" commands to copy a few z/OS
data files down to a Unix directory, then a python script which uses that
data.

While the job is running I can use SDSF DA and PS to see the various Unix
parts running, but at the end of the job the shop-local IEFACTRT report in
the JESMSGLG output only seems to account for the actual BPXBATCH CPU time
and I/O count.  The much more significant Unix I/O and CPU values are not
included in that report as far as I can tell.

Similarly, the JESYSMSG end-of-step output messages for the BPXBATCH step
again only seem to account for BPXBATCH usage alone, and not any of the Unix
CPU or memory usage.

Is there data available to an IEFACTRT routine or the JESYSMSG end-of-step
processing to report Unix usage in a batch step at all?  Or is that only
available in DCOLLECT output (to which I do not have and cannot get any
permissions from local security due to zero trust rules)?

Or am I seeing the python-on-ZIIP capability here, and the CPU isn't
reported because it is done on a ZIIP (though that would not explain the I/O
count being so low when I know the python script does quite a lot more I/O)?

If it matters, we're on z/OS 2.5 here at a reasonably current RSU I believe,
but I don't know the exact level.  HW is z15.

Peter

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

--
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: Epoch Index

[Peter Relson]

Gil wrote

Eerily reminiscent of a Red Alert IBM issued a couple years ago.  A macro,
customer facing therefore hard to change, was doing a STCK to a wild
address.  When a certain bit in the TOD changed, IPL cod which tests that
bit with no effect other than to crash when it had the wrong value would
make the next IPL impossible.


That seems unlikely, and almost inconceivable unless you IPL without "clear" 
(aside from if the corrupted storage got written to a data set that was read 
upon re-IPL).

Might you have any details?

I certainly understand relatively unpredictable side effects within the current 
IPL,

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: Data Set Commander Monitor (DSCMON) Access Authority

[Peter Vander Woude]

Mike,

I have normally been on the RACF-L list, however, since changing jobs last 
year, I've had some problems with the e-mails from the list getting through to 
my new e-mail address.

I, personally, have not seen work running without a valid RACF userid 
associated with it, though I have been in smaller shops, most of my career, 
where it was nominally easier to know all the work running on the system.

Peter

On Tue, 25 Jun 2024 11:22:17 -0500, Mike Cairns  wrote:

>Hi Peter,
>
>Radoslaw and I probably spend more time over on the RACF_L list than here on 
>IBM-MAIN, but I still like to keep an eye open here.
>
>The use of ID(*) ACCESS(READ) is well known among the RACF community as the 
>'preferred' option to UACC nowadays, and the reason you cite is indeed 
>mentioned in the literature.  Though I'm not sure about the NJE port of entry 
>still being able to actually get a batch job running under the JES 
>UNDEFINEDUSER, I have a recollection that the RACF SETROPTS setting 
>BATCHALLRACF(YES) should prevent a batch job from initiating with the 
>UNDEFINEDUSER value, though I have a vague recollection that BATCHALLRACF 
>itself has been redundant also for many years now as well.
>
>I'm intrigued generally to ask of this community, just how often does anyone 
>observe work executing on their system *without* a valid RACF (or ACF2 or 
>TopSecret) identity associated with it?  
>
>I think there might still be one or two started tasks, probably running as 
>TRUSTED or PRIVILEGED, that are initiated in nucleus initialisation that may 
>still run with traditionally either the 8 plusses or the 8 question marks as 
>their ID, we can see them in SDSF, but realistically I don't believe that we 
>see work running under the UNDEFINEDUSER in modern systems for a long time 
>nowadays.  I'd be keen to hear otherwise if there is though.
>
>Cheers - Mike
>
>--
>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: LOL - AWS brags about 99.9% uptime!

[Allan Staller]

Classification: Confidential

3 nines of availability is so 80's. Even back then IBM was claiming 6 nines for 
a properly configured parallel sysplex.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, June 25, 2024 4:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOL - AWS brags about 99.9% uptime!

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On 6/10/2024 4:21 PM, Charles Mills wrote:
> https://grap/
> hite.dev%2Fblog%2Fhow-amazon-deploys-code&data=05%7C02%7Callan.staller
> %40HCLTECH.COM%7C3a233e64724d45df86c108dc955f57d4%7C189de737c93a4f5a8b
> 686f4ca9941912%7C0%7C0%7C638549483946609698%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=P5Iff9rT1MQpxjzSvxco%2FM6dxubwE1a4H8whRLXypkc%3D&reserve
> d=0
>
> Aiming for only (!) four minutes of downtime a month!

Three nines?! Yikes!

IBM now touts eight nines (99.99) on IBM Z with everything properly 
configured and fully redundant.

https://www.ibm.com/z/resiliency

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not an intended recipient, please contact 
the sender by reply e-mail and destroy all copies of this email message and do 
not otherwise utilize or retain this email message or any or all of the 
information contained therein. Although this email message and any attachments 
or appended messages are believed to be free of any virus or other defect that 
might affect any computer system into which it is received and opened, it is 
the responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

--
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: LOL - AWS brags about 99.9% uptime!

[Dave Beagle]

Johnson mentioned 5 9’s and 7 9’s a year ago and many of you made fun of him 
while also insinuating IBM wasn’t truthful.


Sent from Yahoo Mail for iPhone


On Wednesday, June 26, 2024, 8:52 AM, Allan Staller 
<0632b4c7ca99-dmarc-requ...@listserv.ua.edu> wrote:

Classification: Confidential

3 nines of availability is so 80's. Even back then IBM was claiming 6 nines for 
a properly configured parallel sysplex.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, June 25, 2024 4:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOL - AWS brags about 99.9% uptime!

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

On 6/10/2024 4:21 PM, Charles Mills wrote:
> https://grap/
> hite.dev%2Fblog%2Fhow-amazon-deploys-code&data=05%7C02%7Callan.staller
> %40HCLTECH.COM%7C3a233e64724d45df86c108dc955f57d4%7C189de737c93a4f5a8b
> 686f4ca9941912%7C0%7C0%7C638549483946609698%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=P5Iff9rT1MQpxjzSvxco%2FM6dxubwE1a4H8whRLXypkc%3D&reserve
> d=0
>
> Aiming for only (!) four minutes of downtime a month!

Three nines?! Yikes!

IBM now touts eight nines (99.99) on IBM Z with everything properly 
configured and fully redundant.

https://www.ibm.com/z/resiliency

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not an intended recipient, please contact 
the sender by reply e-mail and destroy all copies of this email message and do 
not otherwise utilize or retain this email message or any or all of the 
information contained therein. Although this email message and any attachments 
or appended messages are believed to be free of any virus or other defect that 
might affect any computer system into which it is received and opened, it is 
the responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

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




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

Re: CPU and I/O statistics for BPXBATCH executions?

[Paul Feller]

My apologies I should have supplied a bit more information.  In the SMF manual 
there is chapter 8 (Chapter 8. z/OS UNIX System Services accounting) which 
talks about the different ways Unix information is collected.  By no means am I 
an expert on the different parts of the SMF type 30 records or how the Unix 
information is collected.

https://www.ibm.com/docs/en/SSLTBW_2.5.0/pdf/ieag200_v2r5.pdf


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, June 26, 2024 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU and I/O statistics for BPXBATCH executions?

There are several issues for Unix measurement.

 1. If the installation chooses to run multiple processes in a single AS,
I know of no way to separate the data for individual processes. Is
there a new SMF record type for that purpose?

 2. The converse issue is aggregating all of data for processes
spawned by a single job. Is there anything in the type 30 to
identify the original job?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Feller <05aa34d46684-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, June 25, 2024 9:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU and I/O statistics for BPXBATCH executions?

Peter, from what I recall I believe the information around Unix System Services 
stuff along with zIIP activity should be available to the IEFACTRT exit.  There 
is information in the SMF 30 record related to Unix activity and zIIP activity. 
 I'm guessing it's a matter of updating the exit to pull the data from the 
proper SMF 30 fields.  My guess would be that no one considered updating the 
exit as new stuff got added to the different parts of the SMF 30 data.


I'm guessing you are talking about the IEF032I (or IEF033I) message when you 
refer to the JESSYSMSG message.  I don't really know if IBM tries to account 
for any of the activity in Unix land or activity on the zIIP.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Tuesday, June 25, 2024 7:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CPU and I/O statistics for BPXBATCH executions?

Hi All,

Just a question of curiosity.  In recent days I have been running some ad-hoc 
BPXBATCH jobs that executes some "cp" commands to copy a few z/OS data files 
down to a Unix directory, then a python script which uses that data.

While the job is running I can use SDSF DA and PS to see the various Unix parts 
running, but at the end of the job the shop-local IEFACTRT report in the 
JESMSGLG output only seems to account for the actual BPXBATCH CPU time and I/O 
count.  The much more significant Unix I/O and CPU values are not included in 
that report as far as I can tell.

Similarly, the JESYSMSG end-of-step output messages for the BPXBATCH step again 
only seem to account for BPXBATCH usage alone, and not any of the Unix CPU or 
memory usage.

Is there data available to an IEFACTRT routine or the JESYSMSG end-of-step 
processing to report Unix usage in a batch step at all?  Or is that only 
available in DCOLLECT output (to which I do not have and cannot get any 
permissions from local security due to zero trust rules)?

Or am I seeing the python-on-ZIIP capability here, and the CPU isn't reported 
because it is done on a ZIIP (though that would not explain the I/O count being 
so low when I know the python script does quite a lot more I/O)?

If it matters, we're on z/OS 2.5 here at a reasonably current RSU I believe, 
but I don't know the exact level.  HW is z15.

Peter

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

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

Re: z/OS 3.1 Enhancements & Support News

[Marna WALLE]

Hi Jim,
Of course!  You can always order a "Product ServerPac" (which really is just a 
z/OS SREL ServerPac, but withOUT the operating system).  These products are 
available as a Product ServerPac, that you can then run and enjoy on your z/OS 
V2.5 system.  

(fyi:  You won't see "Product ServerPac" on Shopz, it is really just a normal 
ServerPac in which you have haven't selected the base operating system.  
"Product ServerPac" is just our common term for a Z038 ServerPac without z/OS 
in it.) 

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

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

Re: [EXTERNAL] Re: z/OS 3.1 Enhancements & Support News

[Horne, Jim]

Thanks, Marna, this helps!
Jim

Marna Walle wrote:
Of course!  You can always order a "Product ServerPac" (which really is just a 
z/OS SREL ServerPac, but withOUT the operating system).  These products are 
available as a Product ServerPac, that you can then run and enjoy on your z/OS 
V2.5 system.

(fyi:  You won't see "Product ServerPac" on Shopz, it is really just a normal 
ServerPac in which you have haven't selected the base operating system.  
"Product ServerPac" is just our common term for a Z038 ServerPac without z/OS 
in it.)

NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

Re: Data Set Commander Monitor (DSCMON) Access Authority

[Radoslaw Skorupka]

Peter,
Thank you for the explanation.
However I think the same "problem" exists with ID(*) and LNKLST.

Regarding undefined users - BATCHALLRACF should be enough. And AFAIR 
NODES class could be set up to reject such jobs.
However it is still minor issue, IMHO - the job would use some 
resources, that's all. I would not expect DDOS-like attack. NJE is not 
Internet with thousands of anonymous attackers.



Regards
--
Radoslaw Skorupka
Lodz, Poland




W dniu 25.06.2024 o 15:46, Peter Vander Woude pisze:

R.S.

One of the reasons to use ACCESS(READ) ID(*) and not UACC(READ) would be that 
the first forces the user accessing the programs to actually be a racf userid.  
I believe, that if you have a job, come across via NJE, it is possible that the 
submitting system did not provide a userid, and would then get assigned the JES 
UNDEFINEDUSER userid (which should not be an actual racf userid).

That right there would deny the job from accessing datasets with UACC(NONE)  
and ACCESS(READ) ID(*). whereas UACC(READ) would allow that job (if it were 
allowed to execute of course), to access that dataset.

Peter

On Mon, 24 Jun 2024 12:48:42 +0200, Radoslaw Skorupka  
wrote:


This is the way (one of few) to do this.
In other words HOW to do this.
However it doesn't answer WHY to do this.
I still don't know any *reasonable* justification for UACC(NONE) for
linklisted libraries.

--
Radoslaw Skorupka
Lodz, Poland





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

Re: Data Set Commander Monitor (DSCMON) Access Authority

[Bob Bridges]

I've seen it in CICS, of course.  Never in TSO.  I rarely get into other 
environments.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Let the righteous smite me in kindness and reprove me.
It is oil upon my head; do not let my head refuse it.  -Psalms 141:5 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Vander Woude
Sent: Wednesday, June 26, 2024 08:50

I, personally, have not seen work running without a valid RACF userid 
associated with it, though I have been in smaller shops, most of my career, 
where it was nominally easier to know all the work running on the system.

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

Re: Epoch Index

[Attila Fogarasi]

I haven't seen that Red Alert but my guess is that it is STP related; STP
provides that non-z/OS persistent data store that can cross IPLs.   I know
that an Epoch change in STP can prevent zos joining sysplex and requires
sysplex-wide re-ipl, for example -- one of the rather rare sysplex-wide
failures, though to zos's credit even that doesn't cause an outage.  STP
also has options of how Epoch changes are (mis)managed.  Always wondered
about STP design, but I don't know the constraints they had, it never
seemed up to the standards of the rest of the system.

On Wed, Jun 26, 2024 at 10:07 PM Peter Relson  wrote:

> Gil wrote
> 
> Eerily reminiscent of a Red Alert IBM issued a couple years ago.  A macro,
> customer facing therefore hard to change, was doing a STCK to a wild
> address.  When a certain bit in the TOD changed, IPL cod which tests that
> bit with no effect other than to crash when it had the wrong value would
> make the next IPL impossible.
> 
>
> That seems unlikely, and almost inconceivable unless you IPL without
> "clear" (aside from if the corrupted storage got written to a data set that
> was read upon re-IPL).
>
> Might you have any details?
>
> I certainly understand relatively unpredictable side effects within the
> current IPL,
>
> 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
>

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

Re: CPU and I/O statistics for BPXBATCH executions?

[Andrew Rowley]

On 26/06/2024 10:05 pm, Seymour J Metz wrote:

  1. If the installation chooses to run multiple processes in a single AS,
 I know of no way to separate the data for individual processes. Is
 there a new SMF record type for that purpose?


There is some data for individual processes in the type 30 record in the 
z/OS Unix Process Section. However, because you can have multiple 
processes, the information can be spread across multiple records if 
there is too much information  for a single record. So it isn't 
necessarily in the same SMF record as e.g. the Processor Accounting section.



  2. The converse issue is aggregating all of data for processes
 spawned by a single job. Is there anything in the type 30 to
 identify the original job?


The issue of which processes should be aggregated is also difficult. For 
example, you probably want processes spawned by sshd accounted 
separately (although there are multiple levels, some belong to sshd, 
some to the user logging in.) But if a batch job does some work under 
UID 0, it still belongs to the batch job.


There is a session id which identifies related processes, but the 
original job might end long before or long after the other processes so 
it can be difficult to relate them in the SMF data.


--
Andrew Rowley
Black Hill Software

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

Re: CPU and I/O statistics for BPXBATCH executions?

[Farley, Peter]

Andrew,

I am not asking about batch jobs that can start long-lasting or somehow 
disconnected Unix processes that outlive the batch job execution.  I am only 
asking about synchronous processes started and completed in the course of one 
batch job.  Your reference to “sshd” is what has confused me.  What does the 
“ssh” demon process have to do with a simple batch job that runs shell commands 
and a python (or go, etc.) program for some application-specific reasons?

For such a limited batch job, it ought to be possible to report all I/O’s, CPU 
and memory statistics for all processes that were started and ended during the 
job execution in one or two aggregated set of messages to the batch job 
JESYSMSG and JESMSGLG outputs such that the combination reports all of the 
actual usage, whether z/OS batch or Unix command(s).

And again, this is all out of pure curiosity – there is zero chance I can ever 
get our local IEFACTRT routine or end-of-step processes changed to do any such 
reporting.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Andrew Rowley
Sent: Wednesday, June 26, 2024 8:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU and I/O statistics for BPXBATCH executions?


On 26/06/2024 10:05 pm, Seymour J Metz wrote:

>   1. If the installation chooses to run multiple processes in a single AS,

>  I know of no way to separate the data for individual processes. Is

>  there a new SMF record type for that purpose?



There is some data for individual processes in the type 30 record in the

z/OS Unix Process Section. However, because you can have multiple

processes, the information can be spread across multiple records if

there is too much information  for a single record. So it isn't

necessarily in the same SMF record as e.g. the Processor Accounting section.



>   2. The converse issue is aggregating all of data for processes

>  spawned by a single job. Is there anything in the type 30 to

>  identify the original job?



The issue of which processes should be aggregated is also difficult. For

example, you probably want processes spawned by sshd accounted

separately (although there are multiple levels, some belong to sshd,

some to the user logging in.) But if a batch job does some work under

UID 0, it still belongs to the batch job.



There is a session id which identifies related processes, but the

original job might end long before or long after the other processes so

it can be difficult to relate them in the SMF data.



--

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: Using environment variables in JCL and USS

[Paul Gilmartin]

On Tue, 25 Jun 2024 23:32:55 -0500, Paul Gilmartin wrote:

>On Wed, 26 Jun 2024 03:15:25 +, kekronbekron wrote:
>
>>Are you able to share this, Paul?
>> 
>I no longer have the code.
> 
I'll suggest that as a PoC you try  allocating your SYSIN  to a data set,
RECFM=VB to see whether it meets your need.

It's absurd that the various SUBMIT commands, TSO, ISPF, Rexx,
and OMVS enforce FB,80, a convention designed to accommodate
devices that haven't been marketed in this century.

>I used ISPF Edit facilities to get LRECL, RECFM of the Edited file.
>
>BPXWDYN or ALLOCATE SYSOUT INTRDR with similar attributes.
>
>Extracted lines and wrote one-by-one with EXECIO.
>(Why doesn't silly ISPF support stem variables!?)
>
>In an earlier approach I used FTP; FILETYPE=JES, JESRECFM, JESLRECL.
>
>Both successful.
>
>
>>On Tuesday, June 25th, 2024 at 23:32, Paul Gilmartin wrote:
>>
>>> On Tue, 25 Jun 2024 13:33:59 -0400, Phil Smith III wrote:
>>> 
>>> > SWAG but have you tried a trailing semicolon? Or quotes around the value? 
>>> > I found an example on the web for another product:
>>> > ENVAR C='X Y'
>>> > ...which sorta suggests that the quotes might work. Might try both 
>>> > flavors of quote, too.
>>> 
>>> Or, RECFM=VB.
>>> 
>>> I wrote an Edit macro which allocates INTRDR with the attributes of the
>>> file being edited in order to avoid the 80-characte limit. Why didn't IBM
>>> think of that? I consider quiet truncation to be data corruption.

-- 
gil

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

Re: Using environment variables in JCL and USS

[Seymour J Metz]

> It's absurd that the various SUBMIT commands, TSO, ISPF, Rexx,
> and OMVS enforce FB,80,

REXX?

As for ISPF, it uses TSO SUBMIT, and that's where the fix has to go. Is there 
an RFE?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, June 26, 2024 9:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using environment variables in JCL and USS

On Tue, 25 Jun 2024 23:32:55 -0500, Paul Gilmartin wrote:

>On Wed, 26 Jun 2024 03:15:25 +, kekronbekron wrote:
>
>>Are you able to share this, Paul?
>>
>I no longer have the code.
>
I'll suggest that as a PoC you try  allocating your SYSIN  to a data set,
RECFM=VB to see whether it meets your need.

It's absurd that the various SUBMIT commands, TSO, ISPF, Rexx,
and OMVS enforce FB,80, a convention designed to accommodate
devices that haven't been marketed in this century.

>I used ISPF Edit facilities to get LRECL, RECFM of the Edited file.
>
>BPXWDYN or ALLOCATE SYSOUT INTRDR with similar attributes.
>
>Extracted lines and wrote one-by-one with EXECIO.
>(Why doesn't silly ISPF support stem variables!?)
>
>In an earlier approach I used FTP; FILETYPE=JES, JESRECFM, JESLRECL.
>
>Both successful.
>
>
>>On Tuesday, June 25th, 2024 at 23:32, Paul Gilmartin wrote:
>>
>>> On Tue, 25 Jun 2024 13:33:59 -0400, Phil Smith III wrote:
>>>
>>> > SWAG but have you tried a trailing semicolon? Or quotes around the value? 
>>> > I found an example on the web for another product:
>>> > ENVAR C='X Y'
>>> > ...which sorta suggests that the quotes might work. Might try both 
>>> > flavors of quote, too.
>>>
>>> Or, RECFM=VB.
>>>
>>> I wrote an Edit macro which allocates INTRDR with the attributes of the
>>> file being edited in order to avoid the 80-characte limit. Why didn't IBM
>>> think of that? I consider quiet truncation to be data corruption.

--
gil

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


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

Re: Using environment variables in JCL and USS

[Paul Gilmartin]

On Thu, 27 Jun 2024 01:55:39 +, Seymour J Metz wrote:

>> It's absurd that the various SUBMIT commands, TSO, ISPF, Rexx,
>> and OMVS enforce FB,80,
>
>REXX?
>


>As for ISPF, it uses TSO SUBMIT, and that's where the fix has to go. Is there 
>an RFE?
> .
In a sense, ISPF is worse than TSO.  TSO fails wit a message and
a return code if attributes are wrong.  ISPF *quietly* truncates.  I
consider that data loss.

IIRC, TFM formerly mentioned the F,80 restriction.  I no longer
see it.  Did they fix it?

I suspect it took much resource to enhance the C/I, then ehey
didn't correspondingly fix SUBMIT.  Conway's Law.

--  
gil

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

Re: CPU and I/O statistics for BPXBATCH executions?

[Andrew Rowley]

On 27/06/2024 10:54 am, Farley, Peter wrote:

I am not asking about batch jobs that can start long-lasting or somehow 
disconnected Unix processes that outlive the batch job execution.  I am only 
asking about synchronous processes started and completed in the course of one 
batch job.  Your reference to “sshd” is what has confused me.  What does the 
“ssh” demon process have to do with a simple batch job that runs shell commands 
and a python (or go, etc.) program for some application-specific reasons?


SSHD was an example of a BPXBATCH job/stc where the resulting tasks far 
outlive the job that started them.


Even for a simple batch job: BPXBATCH -> shell -> shell script -> Python,

the different parts are running in separate address spaces, and I don't 
think that the system can be sure which order they will end. How can it 
tell the difference between a simple batch job and something that 
behaves like sshd?


It would be nice if the CPU etc was rolled up into the BPXBATCH job, but 
I think it would make writing the SMF records when unix tasks end very 
complex.


The CPU/IO etc for the cp, Python etc. steps is recorded, but it is in 
separate SMF records with SMF30WID = OMVS. IEFACTRT could presumably 
process them, but there are potentially thousands per second.


--
Andrew Rowley
Black Hill Software

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

Re: GRS in MONOPLEX without physical CTCs ?

[80]

Hello Allan,
Thanks for this clarification.
Regards

*De :* Allan Staller [mailto:0632b4c7ca99-dmarc-requ...@listserv.ua.edu]
*Envoyé :* lundi 24 juin 2024 à 13:52
*Pour :* IBM-MAIN@LISTSERV.UA.EDU
*Objet :* GRS in MONOPLEX without physical CTCs ?


Classification: Confidential

IMO, no.

The various images will not attempt to communicate with each other in Monoplex 
mode.

The CTC's should be defined and then run GRS in RING mode.
As I previously posted, the more systems to be communicated with in the longer 
GRS will take to respond.
This escalates very rapidly.

  CF or CF engine is not required.

HTH,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
MANCINI Frédéric (80)
Sent: Friday, June 21, 2024 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GRS in MONOPLEX without physical CTCs ?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Actually, we do share a few DASD devices between our lpars.

Thanks to all the replies, I understand better now what we must do in order to 
implement a fully functional GRS without buying an external coupling facility.

I understand that we can leave our lpars in MONOPLEX mode and use GRS managed 
CTCs, possibly on a ring architecture in order to minimize the hardware 
connections.

Using virtual CTCs without interconnecting the MONOPLEX lpars doesn't seem to 
make sense for resource serialization.

Am I right ?


*De :* Tom Marchant [mailto:000a2a8c2020-dmarc-requ...@listserv.ua.edu]
*Envoyé :* vendredi 21 juin 2024 à 15:30 *Pour :* IBM-MAIN@LISTSERV.UA.EDU 
*Objet :* GRS in MONOPLEX without physical CTCs ?


The OP hasn't said whether or not any DASD is shared.

If there is a need to share PDSE, it is only supported within a
Sysplex. MIM is not sufficient

--
Tom Marchant

On Fri, 21 Jun 2024 13:49:29 +0200, Radoslaw Skorupka  
wrote:


To complement:
Parallel Sysplex - a CF is required, which mean sysplex links
(emulated, free - for PS within single CPC). GRS is STAR mode is
possible and strongly suggested. (GRSplex is required, the mode is suggested).

Base Sysplex - CTC links required. In the old days also sysplex timer.
Now it can be sysplex link to provide time synchronization for STP
(Server Time Protocol). The GRS is mandatory and it's configuration
is RING, which is not the best from performance point of view. For
base sysplex within single CPC there are no STP-only links, but CTC
over FICON is required. Note: the FICON can be shared, that means
used for other purposes.

Monoplex. GRSplex is still possible (unless something changed) and it
is RING topology with drawbacks mentioned above. Of course multiple
monoplex LPARs may share DASD without GRSplex, but again it is not
seamless - at least PDSE sharing is almost impossible.

...and there is CA-MIM family of products. :-)


--
Radoslaw Skorupka
Lodz, Poland




W dniu 21.06.2024 o 08:41, Brian Westerman pisze:

You can just use extra FICON interfaces as FCTC's.  IBM refers to that method 
as a baby sysplex.  It allows you to have GRS in ring mode.  TO have star mode 
you need CF's.

If you have multiple LPARs and you share dasd, then you need either CF's 
(expensive) or Ficon CTCs (pretty cheap).  The setup is very simple.  CF's are 
much faster but ficon CTC's easily handle 3,4 or 5 lpars without any issues at 
all.

Brian


-- 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
::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, i