Re: RUCSA
Is anyone using RUCSA yet? We currently have a very old ISV product that requires running with ALLOWUSERKEYCSA(YES) on z/OS 2.2. As we prepare for new hardware to support upgrade to z/OS 2.4, I'm faced with the possibility of needing to run 2.4 with RUCSA if we cannot get an upgrade for this old ISV product in time. I see RUCSA as orderable on ShopZ, just wondering, can it be ordered and installed seperately or does it need to be ordered at the same time as the z/OS 2.4 order? Thanks Dana On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote: >Folks, > >Remind me, is RUCSA support a chargeable feature? I find nothing in the >manual, the only clue I find is it is a separate line-item in ShopZ, so >thinking it may be chargeable, and enabled via IFAPRDxx? Just looking for a >bit of confirmation > >_ >Dave Jousma >AVP | Manager, Systems Engineering >[cid:image003.png@01D4F915.C9E34050] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RUCSA
Can't speak for IBM, but AFAIK, it should be orderable separately. To quote the old commercial: "Try it. You'll like it" -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dana Mitchell Sent: Thursday, March 12, 2020 7:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] Is anyone using RUCSA yet? We currently have a very old ISV product that requires running with ALLOWUSERKEYCSA(YES) on z/OS 2.2. As we prepare for new hardware to support upgrade to z/OS 2.4, I'm faced with the possibility of needing to run 2.4 with RUCSA if we cannot get an upgrade for this old ISV product in time. I see RUCSA as orderable on ShopZ, just wondering, can it be ordered and installed seperately or does it need to be ordered at the same time as the z/OS 2.4 order? Thanks Dana On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote: >Folks, > >Remind me, is RUCSA support a chargeable feature? I find nothing in the >manual, the only clue I find is it is a separate line-item in ShopZ, so >thinking it may be chargeable, and enabled via IFAPRDxx? Just looking for a >bit of confirmation > >___ >__ >Dave Jousma >AVP | Manager, Systems Engineering >[cid:image003.png@01D4F915.C9E34050] -- 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: RUCSA
Does it come with a free sample of Alka Seltzer? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, March 12, 2020 9:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA Can't speak for IBM, but AFAIK, it should be orderable separately. To quote the old commercial: "Try it. You'll like it" -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dana Mitchell Sent: Thursday, March 12, 2020 7:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] Is anyone using RUCSA yet? We currently have a very old ISV product that requires running with ALLOWUSERKEYCSA(YES) on z/OS 2.2. As we prepare for new hardware to support upgrade to z/OS 2.4, I'm faced with the possibility of needing to run 2.4 with RUCSA if we cannot get an upgrade for this old ISV product in time. I see RUCSA as orderable on ShopZ, just wondering, can it be ordered and installed seperately or does it need to be ordered at the same time as the z/OS 2.4 order? Thanks Dana On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote: >Folks, > >Remind me, is RUCSA support a chargeable feature? I find nothing in the >manual, the only clue I find is it is a separate line-item in ShopZ, so >thinking it may be chargeable, and enabled via IFAPRDxx? Just looking for a >bit of confirmation > >___ >__ >Dave Jousma >AVP | Manager, Systems Engineering >[cid:image003.png@01D4F915.C9E34050] -- 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: RUCSA
From the z/OS V2.4 announcement. Reading between the lines, I don’t think you can install this on lower version of z/OS, but maybe a quick support ticket would be in order. Also it is chargeable feature. Removal of user key common storage User key common storage is memory that can be updated by any unauthorized program. z/OS V2.4 no longer supports unrestricted user key common storage, thereby improving application isolation and security. PTFs for APARs OA53355 and OA56180 are available at lower releases to assist in migration and identification of programs accessing user key common storage. Removal of support of YES setting for VSM ALLOWUSERKEYCSA DIAGxx parmlib parameter: z/OS V2.3 will be the last release of z/OS to support the YES setting for the VSM ALLOWUSERKEYCSA DIAGxx parmlib parameter. If you run any software that requires the setting of this parameter to YES, the software will need to be changed to no longer require the setting of this parameter to YES or the optional priced RUCSA feature will be required. All IBM provided software should not require this setting. If you have any other non-IBM provided software that requires this setting, contact the owner of the software regarding this usage. Removal of support for obtaining user key CSA/ECSA storage: z/OS V2.4 does not support the usage of the GETMAIN, CPOOL, and STORAGE OBTAIN interfaces to obtain user key (8-15) CSA/ECSA storage. If you have any software that obtains user key CSA/ECSA storage, the software will need to be changed to no longer require this capability or the optional priced RUCSA feature will be required. Removal of support for obtaining user key CSA/ECSA storage: z/OS V2.4 does not support the usage of the GETMAIN, CPOOL, and STORAGE OBTAIN interfaces to obtain user key (8-15) CSA/ECSA storage. If you have any software that obtains user key CSA/ECSA storage, the software will need to be changed to no longer require this capability or the optional priced RUCSA feature will be required. Removal of support for changing Common ESQA (Subpool 247-248) storage to user key: z/OS V2.4 does not support the usage of the CHANGKEY interface to change Common ESQA (Subpool 247-248) storage to user key (8-15). If you have any software that changes Common ESQA (Subpool 247-248) storage to user key, the software will need to be changed to no longer require this capability. Removal of support of YES setting for ALLOWUSERKEYCADS DIAGxx parmlib parameter: z/OS V2.4 does not support the YES setting for the ALLOWUSERKEYCADS DIAGxx parmlib parameter. On prior releases, when ALLOWUSERKEYCADS(YES) is in effect, usage of the DSPSERV CREATE interface to create a SCOPE=COMMON data space in user key (8 -15) is supported. If you run any software that requires the setting of this parameter to YES, the software will need to be changed to no longer require the setting of this parameter to YES. All IBM provided software should not require this setting. If you have any other non-IBM provided software that requires this setting, contact the owner of the software regarding this usage. Removal of support for creating SCOPE=COMMON data spaces in user key: z/OS V2.4 does not support the usage of the DSPSERV CREATE interface to create a SCOPE=COMMON data space in user key (8 -15). If you have any software that creates a SCOPE=COMMON data space in user key, the software will need to be changed to no longer require this capability. Restricted Use Common Service Area (RUCSA) feature A new optional priced feature, RUCSA, is offered to enable clients to define a restricted use CSA (RUCSA) and manage it through SAF security protection. While avoiding user key common storage entirely is recommended, this feature enables clients who cannot update their applications that allocate user key CSA to gain enhanced protection without the need for application changes. Additionally, new health checks and instrumentation are added to track usage of this area. PTFs for APARs OA53355 and OA56180 are available at lower releases to assist in migration and identification of programs accessing user key common. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Thursday, March 12, 2020 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Does it come with a free sample of Alka Seltzer? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, March 12, 2020 9:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA Can't speak for IBM, but
Re: RUCSA
That rather implies segment-level protection, rather than page. Cheers, Martin 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: Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Date: 12/03/2020 16:59 Subject:[EXTERNAL] Re: RUCSA Sent by:IBM Mainframe Discussion List RUCSA has to be allocated on a 1M boundary, so take that into consideration when looking at your virtual storage map. A RUCSA allocation below the line, if you don't also reduce CSA will result in the below the line private being reduced by 1M. Extended private isn't usually much of a concern. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=lNiQeZuiD4Q6umXm_yMCJWEXWafS72oqVI88BoMIYB8=3Ic9ZT6StCzl4I0XY0hY1sJAM4AoTn_emnlZJULRPI0= ‐‐‐ Original Message ‐‐‐ On Thursday, March 12, 2020 12:11 PM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Thanks for clarifying Jim! > > Dave Jousma > > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 > > 616.653.8429 | fax: 616.653.2717 > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of Jim Mulder d10j...@us.ibm.com > Sent: Thursday, March 12, 2020 11:38:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RUCSA > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected emails > > For releases earlier than z/OS 2.4, RUCSA is provided by APAR OA56180. > > R790 PSY UA98722 UP19/03/28 P F903 > R7A0 PSY UA98723 UP19/03/28 P F903 > R7B0 PSY UA98724 UP19/03/28 P F903 > > publibz.boulder.ibm.com/zoslib/pdf/OA56180.pdf > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY > > "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU wrote on > 03/12/2020 11:07:04 AM: > > > From: "Jousma, David" 01a0403c5dc1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 03/12/2020 11:34 AM > > Subject: Re: RUCSA > > Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU > > > The problem with RUCSA "feature" not being available in prior > > version (maybe it is, I just don’t see it), is that there is no path > > to convert into that prior to rolling V2.4. I guess all the > > prep work could be done (SAF rules, etc) ahead of time, but that > > would surely be a "must check out". The other problem with RUCSA > > is that if your offending/affected app requires below-the-line CSA, > > the minimum amount of RUCSA is 1MB, even if you only needed a few K > > for whatever you are doing. That will affect below-the-line > > private for sure. > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected emails > This e-mail transmission contains information that is confidential and may be privileged. > It is intended only for the addressee(s) named above. If you receive this e-mail in error, > please do not read, copy or disseminate it in any manner. If you are not the intended > recipient, any disclosure, copying, distribution or use of the contents of this information > is prohibited. Please reply to the message immediately by informing the sender that the > message was misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > >
Re: RUCSA
RUCSA has to be allocated on a 1M boundary, so take that into consideration when looking at your virtual storage map. A RUCSA allocation below the line, if you don't also reduce CSA will result in the below the line private being reduced by 1M. Extended private isn't usually much of a concern. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, March 12, 2020 12:11 PM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Thanks for clarifying Jim! > > Dave Jousma > > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI > 49546 > > 616.653.8429 | fax: 616.653.2717 > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of Jim > Mulder d10j...@us.ibm.com > Sent: Thursday, March 12, 2020 11:38:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RUCSA > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected > emails > > For releases earlier than z/OS 2.4, RUCSA is provided by APAR OA56180. > > R790 PSY UA98722 UP19/03/28 P F903 > R7A0 PSY UA98723 UP19/03/28 P F903 > R7B0 PSY UA98724 UP19/03/28 P F903 > > publibz.boulder.ibm.com/zoslib/pdf/OA56180.pdf > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY > > "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU wrote on > 03/12/2020 11:07:04 AM: > > > From: "Jousma, David" 01a0403c5dc1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 03/12/2020 11:34 AM > > Subject: Re: RUCSA > > Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU > > > The problem with RUCSA "feature" not being available in prior > > version (maybe it is, I just don’t see it), is that there is no path > > to convert into that prior to rolling V2.4. I guess all the > > prep work could be done (SAF rules, etc) ahead of time, but that > > would surely be a "must check out". The other problem with RUCSA > > is that if your offending/affected app requires below-the-line CSA, > > the minimum amount of RUCSA is 1MB, even if you only needed a few K > > for whatever you are doing. That will affect below-the-line > > private for sure. > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected > emails > This e-mail transmission contains information that is confidential and may be > privileged. > It is intended only for the addressee(s) named above. If you receive this > e-mail in error, > please do not read, copy or disseminate it in any manner. If you are not the > intended > recipient, any disclosure, copying, distribution or use of the contents of > this information > is prohibited. Please reply to the message immediately by informing the > sender that the > message was misdirected. After replying, please erase it from your computer > system. Your > assistance in correcting this error is appreciated. > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOSTNAMES on Z/OS TCPIP
According to my old references, if the Unix file exists, it is used. If not, the system searches for one of several possible z/OS datasets. Check your current z/OS Communications Server IP Configuration Guide. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of esst...@juno.com > Sent: Thursday, March 12, 2020 7:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: HOSTNAMES on Z/OS TCPIP > > Hi,..I was previously on a Z/OS 2.2 system where I would update > hostnames and IP Address in a Unix directory (/SYSTEM/etc/HOSTS) > . > When I transfered to a different division within the same company I am > working on a z/OS 2.3 system, where Host Names and their associated > IP Address's are stored in a Sequential File (TCP.HOSTNAME.LOCAL). > . > So here is my questions: > How do I properly derive/navigate/determine if a System is using > a USS directory or a MVS file to maintain its TCP HOST Names ? > . > Is this specified in UNIX System Services directory/configuration ? > Is this specified in a TCPIP dataset ? Which Dataset ? > Is this specidied in a RESOLVER dataset ? Which Dataset ?.Paul D'Angelo* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RUCSA
RUCSA([xM],[yM]) Specifies the sizes of the virtual restricted use common service area (RUCSA) and extended RUCSA. xM Specifies the size of the non-extended RUCSA, located below 16 MB. yM Specifies the size of the extended RUCSA, located above 16 MB. Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, March 12, 2020 1:56 PM, Martin Packer wrote: > That rather implies segment-level protection, rather than page. > > Cheers, Martin > > 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: Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/03/2020 16:59 > Subject: [EXTERNAL] Re: RUCSA > Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU > > RUCSA has to be allocated on a 1M boundary, so take that into > consideration when looking at your virtual storage map. A RUCSA allocation > below the line, if you don't also reduce CSA will result in the below the > line private being reduced by 1M. Extended private isn't usually much of a > concern. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=lNiQeZuiD4Q6umXm_yMCJWEXWafS72oqVI88BoMIYB8=3Ic9ZT6StCzl4I0XY0hY1sJAM4AoTn_emnlZJULRPI0= > > ‐‐‐ Original Message ‐‐‐ > On Thursday, March 12, 2020 12:11 PM, Jousma, David > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu wrote: > > > Thanks for clarifying Jim! > > Dave Jousma > > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, > > MI 49546 > > > 616.653.8429 | fax: 616.653.2717 > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf > > of Jim Mulder d10j...@us.ibm.com > > > Sent: Thursday, March 12, 2020 11:38:36 AM > > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: RUCSA > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or > > unexpected emails > > > For releases earlier than z/OS 2.4, RUCSA is provided by APAR OA56180. > > R790 PSY UA98722 UP19/03/28 P F903 > > R7A0 PSY UA98723 UP19/03/28 P F903 > > R7B0 PSY UA98724 UP19/03/28 P F903 > > publibz.boulder.ibm.com/zoslib/pdf/OA56180.pdf > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > > Poughkeepsie NY > > "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU wrote on > > 03/12/2020 11:07:04 AM: > > > > > From: "Jousma, David" 01a0403c5dc1-dmarc-requ...@listserv.ua.edu > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Date: 03/12/2020 11:34 AM > > > Subject: Re: RUCSA > > > Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU > > > > > The problem with RUCSA "feature" not being available in prior > > > version (maybe it is, I just don’t see it), is that there is no path > > > to convert into that prior to rolling V2.4. I guess all the > > > prep work could be done (SAF rules, etc) ahead of time, but that > > > would surely be a "must check out". The other problem with RUCSA > > > is that if your offending/affected app requires below-the-line CSA, > > > the minimum amount of RUCSA is 1MB, even if you only needed a few K > > > for whatever you are doing. That will affect below-the-line > > > private for sure. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or > > unexpected emails > > > This e-mail transmission contains information that is confidential and > > may be privileged. > > > It is intended only for the addressee(s) named above. If you receive > > this e-mail in error, > > > please do not read, copy or disseminate it in any manner. If you are not > > the intended > > > recipient, any disclosure, copying, distribution or use of the contents > > of this information > > > is prohibited. Please reply to the message immediately by informing the > > sender that the > > > message was misdirected. After replying, please erase it from your > > computer system. Your > > > assistance in correcting this error is appreciated. > > > For IBM-MAIN subscribe / signoff / archive access instructions,
Re: RUCSA
Yea. The idea is to remediate. We had one home grown automation tool that we retired (finally), and one vendor (FiServ) banking application that they have remediated, so we are clear to roll V2.4 to prod. The problem with RUCSA "feature" not being available in prior version (maybe it is, I just don’t see it), is that there is no path to convert into that *prior* to rolling V2.4.I guess all the prep work could be done (SAF rules, etc) ahead of time, but that would surely be a "must check out". The other problem with RUCSA is that if your offending/affected app requires below-the-line CSA, the minimum amount of RUCSA is 1MB, even if you only needed a few K for whatever you are doing. That will affect below-the-line private for sure. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Thursday, March 12, 2020 10:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Well, any product that requires ALLOWUSERKEYCSA(YES) won't run on z/OS 2.4 until you do install it. On Thu, Mar 12, 2020 at 7:54 AM Dana Mitchell wrote: > > Is anyone using RUCSA yet? We currently have a very old ISV product that > requires running with ALLOWUSERKEYCSA(YES) on z/OS 2.2. As we prepare for > new hardware to support upgrade to z/OS 2.4, I'm faced with the possibility > of needing to run 2.4 with RUCSA if we cannot get an upgrade for this old > ISV product in time. > > I see RUCSA as orderable on ShopZ, just wondering, can it be ordered and > installed seperately or does it need to be ordered at the same time as the > z/OS 2.4 order? > > Thanks > Dana > > On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote: > > >Folks, > > > >Remind me, is RUCSA support a chargeable feature? I find nothing in the > >manual, the only clue I find is it is a separate line-item in ShopZ, so > >thinking it may be chargeable, and enabled via IFAPRDxx? Just looking for > >a bit of confirmation > > > >_ > > > >Dave Jousma > >AVP | Manager, Systems Engineering > >[cid:image003.png@01D4F915.C9E34050] > > -- > 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 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] HOSTNAMES on Z/OS TCPIP
This doesn't answer your specific question but the search order is documented in the Communication Server IP configuration Guide. Here's what I found: The resolver uses the IPv4-unique search order for sitename information unconditionally for getnetbyname API calls. The IPv4-unique search order for sitename information is as follows. The search ends at the first file found: 1. The value of the environment variable X_SITE The value of the environment variable is the name of the MVS data set that contains the sitename information. This data set is created by the TSOMAKESITE command. 2. /etc/hosts 3. userid.HOSTS.SITEINFO userid is the user ID that is associated with the current security environment(address space or task/thread). 4. hlq.HOSTS.SITEINFOhlq represents the value of the DATASETPREFIX statement specified in the base resolver configuration file (if found); otherwise, hlq is TCPIP by default. HTH, Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of esst...@juno.com Sent: Thursday, March 12, 2020 9:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] HOSTNAMES on Z/OS TCPIP Hi,..I was previously on a Z/OS 2.2 system where I would update hostnames and IP Address in a Unix directory (/SYSTEM/etc/HOSTS) . When I transfered to a different division within the same company I am working on a z/OS 2.3 system, where Host Names and their associated IP Address's are stored in a Sequential File (TCP.HOSTNAME.LOCAL). . So here is my questions: How do I properly derive/navigate/determine if a System is using a USS directory or a MVS file to maintain its TCP HOST Names ? . Is this specified in UNIX System Services directory/configuration ? Is this specified in a TCPIP dataset ? Which Dataset ? Is this specidied in a RESOLVER dataset ? Which Dataset ?.Paul D'Angelo* . -- 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
HOSTNAMES on Z/OS TCPIP
Hi,..I was previously on a Z/OS 2.2 system where I would update hostnames and IP Address in a Unix directory (/SYSTEM/etc/HOSTS) . When I transfered to a different division within the same company I am working on a z/OS 2.3 system, where Host Names and their associated IP Address's are stored in a Sequential File (TCP.HOSTNAME.LOCAL). . So here is my questions: How do I properly derive/navigate/determine if a System is using a USS directory or a MVS file to maintain its TCP HOST Names ? . Is this specified in UNIX System Services directory/configuration ? Is this specified in a TCPIP dataset ? Which Dataset ? Is this specidied in a RESOLVER dataset ? Which Dataset ?.Paul D'Angelo* . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RUCSA
For releases earlier than z/OS 2.4, RUCSA is provided by APAR OA56180. R790 PSY UA98722 UP19/03/28 P F903 R7A0 PSY UA98723 UP19/03/28 P F903 R7B0 PSY UA98724 UP19/03/28 P F903 publibz.boulder.ibm.com/zoslib/pdf/OA56180.pdf Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 03/12/2020 11:07:04 AM: > From: "Jousma, David" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 03/12/2020 11:34 AM > Subject: Re: RUCSA > Sent by: "IBM Mainframe Discussion List" > The problem with RUCSA "feature" not being available in prior > version (maybe it is, I just don’t see it), is that there is no path > to convert into that *prior* to rolling V2.4.I guess all the > prep work could be done (SAF rules, etc) ahead of time, but that > would surely be a "must check out". The other problem with RUCSA > is that if your offending/affected app requires below-the-line CSA, > the minimum amount of RUCSA is 1MB, even if you only needed a few K > for whatever you are doing. That will affect below-the-line > private for sure. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RUCSA
Well, any product that requires ALLOWUSERKEYCSA(YES) won't run on z/OS 2.4 until you do install it. On Thu, Mar 12, 2020 at 7:54 AM Dana Mitchell wrote: > > Is anyone using RUCSA yet? We currently have a very old ISV product that > requires running with ALLOWUSERKEYCSA(YES) on z/OS 2.2. As we prepare for > new hardware to support upgrade to z/OS 2.4, I'm faced with the possibility > of needing to run 2.4 with RUCSA if we cannot get an upgrade for this old > ISV product in time. > > I see RUCSA as orderable on ShopZ, just wondering, can it be ordered and > installed seperately or does it need to be ordered at the same time as the > z/OS 2.4 order? > > Thanks > Dana > > On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote: > > >Folks, > > > >Remind me, is RUCSA support a chargeable feature? I find nothing in the > >manual, the only clue I find is it is a separate line-item in ShopZ, so > >thinking it may be chargeable, and enabled via IFAPRDxx? Just looking for > >a bit of confirmation > > > >_ > >Dave Jousma > >AVP | Manager, Systems Engineering > >[cid:image003.png@01D4F915.C9E34050] > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RUCSA
Thanks for clarifying Jim! _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 From: IBM Mainframe Discussion List on behalf of Jim Mulder Sent: Thursday, March 12, 2020 11:38:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** For releases earlier than z/OS 2.4, RUCSA is provided by APAR OA56180. R790 PSY UA98722 UP19/03/28 P F903 R7A0 PSY UA98723 UP19/03/28 P F903 R7B0 PSY UA98724 UP19/03/28 P F903 publibz.boulder.ibm.com/zoslib/pdf/OA56180.pdf Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 03/12/2020 11:07:04 AM: > From: "Jousma, David" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 03/12/2020 11:34 AM > Subject: Re: RUCSA > Sent by: "IBM Mainframe Discussion List" > The problem with RUCSA "feature" not being available in prior > version (maybe it is, I just don’t see it), is that there is no path > to convert into that *prior* to rolling V2.4.I guess all the > prep work could be done (SAF rules, etc) ahead of time, but that > would surely be a "must check out". The other problem with RUCSA > is that if your offending/affected app requires below-the-line CSA, > the minimum amount of RUCSA is 1MB, even if you only needed a few K > for whatever you are doing. That will affect below-the-line > private for sure. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESSPOOL
Have you done any internet searches on JESSPOOL RACF? I got lots of good docs by doing that Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Thursday, March 12, 2020 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JESSPOOL If you were not aware, there is a RACF List that you can join to ask RACF specific questions. rac...@listserv.uga.edu Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Thursday, March 12, 2020 1:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JESSPOOL I’m not a RACF expert and need help giving a user the ability to delete their own SDSF output. Not really sure why they don’t have it. Not my setup. Is it an easy 1 command fix or more complex? Thanks -- 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
JESSPOOL
I’m not a RACF expert and need help giving a user the ability to delete their own SDSF output. Not really sure why they don’t have it. Not my setup. Is it an easy 1 command fix or more complex? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESSPOOL
If you were not aware, there is a RACF List that you can join to ask RACF specific questions. rac...@listserv.uga.edu Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Thursday, March 12, 2020 1:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JESSPOOL I’m not a RACF expert and need help giving a user the ability to delete their own SDSF output. Not really sure why they don’t have it. Not my setup. Is it an easy 1 command fix or more complex? Thanks -- 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: JESSPOOL
A *very* crude approach is to look at any RACF violation message on the console and translate that into a PERMIT command: PERMIT resource CL(class) ID(id) ACC(acc). There is typically a resource, a class and the access in the messages. You may have to apply some "intelligence" -- for example, if your shop may prefer to give permissions by GROUP rather than by individual userid. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESSPOOL
Yes, that’s the first thing I did. And IBM doc is so easy to understand I came here. Sent from Yahoo Mail for iPhone On Thursday, March 12, 2020, 4:47 PM, Lizette Koehler wrote: Have you done any internet searches on JESSPOOL RACF? I got lots of good docs by doing that Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Thursday, March 12, 2020 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JESSPOOL If you were not aware, there is a RACF List that you can join to ask RACF specific questions. rac...@listserv.uga.edu Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Thursday, March 12, 2020 1:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JESSPOOL I’m not a RACF expert and need help giving a user the ability to delete their own SDSF output. Not really sure why they don’t have it. Not my setup. Is it an easy 1 command fix or more complex? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESSPOOL
Not all shops use SAF to control SDSF. If so, this advice is fine. If still using native ISFPARMS, the approach will need to be different, including some tweaking of the SDSF user exit if used. I'm surprised that any action at all is necessary for a user's own jobs... . . 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 Charles Mills Sent: Thursday, March 12, 2020 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: JESSPOOL CAUTION EXTERNAL EMAIL A *very* crude approach is to look at any RACF violation message on the console and translate that into a PERMIT command: PERMIT resource CL(class) ID(id) ACC(acc). There is typically a resource, a class and the access in the messages. You may have to apply some "intelligence" -- for example, if your shop may prefer to give permissions by GROUP rather than by individual userid. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESSPOOL
On 3/12/2020 4:24 PM, Jesse 1 Robinson wrote: Not all shops use SAF to control SDSF. If so, this advice is fine. If still using native ISFPARMS, the approach will need to be different, including some tweaking of the SDSF user exit if used. I'm surprised that any action at all is necessary for a user's own jobs... SDSF has nothing whatever to do with it. JESSPOOL provides generic, non-product-specific ESM access control to SPOOL data sets. SDSF is at best a footnote¶ In z/OS 1.9, SSI 80 and related SSIs became available to unauthorized callers. ANYONE! Therefore, if you don't use JESSPOOL -- worse yet, if you have such checking fully disabled -- you are *highly* exposed to data breach! This was brought up by the illustrious Tom Wasik of IBM z/OS JES2 Development at time mark 12:00 (twelve minutes) into this video of SHARE Bit Bucket x'32' https://youtu.be/zXF6U1dtM3s -- 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
Re: JESSPOOL
Thanks. Sent from Yahoo Mail for iPhone On Thursday, March 12, 2020, 4:46 PM, Lizette Koehler wrote: If you were not aware, there is a RACF List that you can join to ask RACF specific questions. rac...@listserv.uga.edu Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Thursday, March 12, 2020 1:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JESSPOOL I’m not a RACF expert and need help giving a user the ability to delete their own SDSF output. Not really sure why they don’t have it. Not my setup. Is it an easy 1 command fix or more complex? Thanks -- 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: JESSPOOL
Yeah, I’ve never seen a shop in which a user couldn’t delete their own output either. Thanks Sent from Yahoo Mail for iPhone On Friday, March 13, 2020, 12:06 AM, Jesse 1 Robinson wrote: Not all shops use SAF to control SDSF. If so, this advice is fine. If still using native ISFPARMS, the approach will need to be different, including some tweaking of the SDSF user exit if used. I'm surprised that any action at all is necessary for a user's own jobs... . . 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 Charles Mills Sent: Thursday, March 12, 2020 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: JESSPOOL CAUTION EXTERNAL EMAIL A *very* crude approach is to look at any RACF violation message on the console and translate that into a PERMIT command: PERMIT resource CL(class) ID(id) ACC(acc). There is typically a resource, a class and the access in the messages. You may have to apply some "intelligence" -- for example, if your shop may prefer to give permissions by GROUP rather than by individual userid. Charles -- 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
