Re: RACF identity when ACEE is above 16MB
-Message d'origine- De : Walt Farrell [mailto:wfarr...@us.ibm.com] Envoyé : jeudi 8 décembre 2011 15:24 Objet : Re: RACF identity when ACEE is above 16MB Also, if you're asking formal questions related to product development, you might want to consider joining PartnerWorld and asking them formally via the channels that PartnerWorld provides, rather than asking here or in RACF-L. Thanks for the suggestion. I will check with the person in charge in my company if we are perhaps members already. Jonathan Eshel RSD S.A. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF identity when ACEE is above 16MB
-Message d'origine- De : Binyamin Dissen [mailto:bdis...@dissensoftware.com] Envoyé : jeudi 8 décembre 2011 15:07 Objet : Re: RACF identity when ACEE is above 16MB How about ICHRTX00? It's an idea but since it's a product we sell to clients (we are a software vendor) I would prefer not to use standard exits and have to combine our code with what clients already do with these exits. Since the TCBSENV method seems to work nonetheless with 31 bit addresses as Walt Farrell pointed out, it would be more straight forward for us to continue using it. Thanks, Jonathan Eshel RSD S.A. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF identity when ACEE is above 16MB
-Message d'origine- De : Walt Farrell [mailto:wfarr...@us.ibm.com] Envoyé : jeudi 8 décembre 2011 15:22 Objet : Re: RACF identity when ACEE is above 16MB First, for RACF-specific questions I would suggest using the RACF-L mailing list, rather than IBM-MAIN. Thank you for the tip Walt, I am now subscribed to RACF-L as well. However, since you asked here: If all the application code running in that address space is code that you own and control, and it's all AMODE(31) code, or you can guarantee that any AMODE(24) code won't try to look at the ACEE itself, then it's probably safe to put an 31-bit address into TCBSENV. The problem with doing that in the more general case is that you can't guarantee that only AMODE(31) application code will run in an address space, and if any AMODE(24) code tried to look at the ACEE it would abend. In principle it's yes to all - it's our code and it's all in AMODE(31). I have done what you suggest and according to first tests it's fine. BTW what about standard IBM services a few of which still switch to AMODE(24) from time to time (or am I wrong ?) like some I/O stuff ? If we use them are we exposed ? Additionally, as far as I can tell the InitACEE callable service will create ACEEs in 31-bit storage, and will anchor them in TCBSENV. That's why I suspect it's safe to do so in other cases, too. On the other hand, you might just want to switch to using InitACEE to manage all your ACEEs. It's an idea for the longer term. In any case many thanks for your very helpful answer. Regards, Jonathan Eshel RSD S.A. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RACF identity when ACEE is above 16MB
Hello list, This is my first posting to the list so please bear with me if I missed something in the archives or in the IBM documentation both of which I scrutinized thoroughly. For a product managing a multi number of users in the same address space, we are trying to release some space below the 16MB line especially for a client who has a lot of users /groups and therefore a great deal of below the line memory is taken by ACEEs. We modified our RACROUTE REQUEST=VERIFY and added an ACEE parameter and we effectively create it above the line. However, how will RACF identify now the user linked to the task for operations like datasets open and jobs submission ? The obvious thing to do is storing the address of the ACEE created in the TCB, field TCBSENV, but the documentation clearly stipulates not to do it when the ACEE reside above the line. So what RACF is doing right now is reverting to the ACEE pointed to by the ASXB (the user linked to the whole address space) and this is not what we want. Is there a way to point RACF to the above the line ACEE so it will correctly identify the task with its user ? Thank you, Jonathan Eshel RSD S.A. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF identity when ACEE is above 16MB
On Thu, 8 Dec 2011 13:24:59 + ESHEL Jonathan j.es...@rsd.com wrote: :Hello list, Hello poster :This is my first posting to the list so please bear with me if I missed something in the archives or in the IBM documentation both of which I scrutinized thoroughly. :For a product managing a multi number of users in the same address space, we are trying to release some space below the 16MB line especially for a client who has a lot of users /groups and therefore a great deal of below the line memory is taken by ACEEs. We modified our RACROUTE REQUEST=VERIFY and added an ACEE parameter and we effectively create it above the line. However, how will RACF identify now the user linked to the task for operations like datasets open and jobs submission ? The obvious thing to do is storing the address of the ACEE created in the TCB, field TCBSENV, but the documentation clearly stipulates not to do it when the ACEE reside above the line. So what RACF is doing right now is reverting to the ACEE pointed to by the ASXB (the user linked to the whole address space) and this is not what we want. :Is there a way to point RACF to the above the line ACEE so it will correctly identify the task with its user ? How about ICHRTX00? -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF identity when ACEE is above 16MB
Also, if you're asking formal questions related to product development, you might want to consider joining PartnerWorld and asking them formally via the channels that PartnerWorld provides, rather than asking here or in RACF-L. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF identity when ACEE is above 16MB
On Thu, 8 Dec 2011 13:24:59 +, ESHEL Jonathan j.es...@rsd.com wrote: This is my first posting to the list so please bear with me if I missed something in the archives or in the IBM documentation both of which I scrutinized thoroughly. For a product managing a multi number of users in the same address space, we are trying to release some space below the 16MB line especially for a client who has a lot of users /groups and therefore a great deal of below the line memory is taken by ACEEs. We modified our RACROUTE REQUEST=VERIFY and added an ACEE parameter and we effectively create it above the line. However, how will RACF identify now the user linked to the task for operations like datasets open and jobs submission ? The obvious thing to do is storing the address of the ACEE created in the TCB, field TCBSENV, but the documentation clearly stipulates not to do it when the ACEE reside above the line. So what RACF is doing right now is reverting to the ACEE pointed to by the ASXB (the user linked to the whole address space) and this is not what we want. Is there a way to point RACF to the above the line ACEE so it will correctly identify the task with its user ? First, for RACF-specific questions I would suggest using the RACF-L mailing list, rather than IBM-MAIN. However, since you asked here: If all the application code running in that address space is code that you own and control, and it's all AMODE(31) code, or you can guarantee that any AMODE(24) code won't try to look at the ACEE itself, then it's probably safe to put an 31-bit address into TCBSENV. The problem with doing that in the more general case is that you can't guarantee that only AMODE(31) application code will run in an address space, and if any AMODE(24) code tried to look at the ACEE it would abend. Additionally, as far as I can tell the InitACEE callable service will create ACEEs in 31-bit storage, and will anchor them in TCBSENV. That's why I suspect it's safe to do so in other cases, too. On the other hand, you might just want to switch to using InitACEE to manage all your ACEEs. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
