Re: Changing the primary AUTHID using RACROUTE
The TSBX picks up the termid for TSO userid said but I think you want the submitter userid and termid ? Scott On Sunday, October 16, 2016, scott Ford wrote: > Janet, > > I work off the TSB > > On Thursday, October 13, 2016, J R > wrote: > >> My apologies, yes, I meant ASXBSENV. >> Re. RACROUTE, this is a higher layer (SAF - System Authorization >> Facility) to request auth functions without concern over which specific >> security server is in use, ie. RACF, ACF2 or TSS. Before SAF, non-RACF >> alternatives would need to hijack SVCs 130-133. >> >> If you are not sure which security server is in use, it's always safer to >> use RACROUTE. >> >> Sent from my iPhone >> >> >> >> >> From: IBM Mainframe Discussion List on behalf >> of Janet Graff <004dc9e91b6d-dmarc-requ...@listserv.ua.edu> >> Sent: Thursday, October 13, 2016 1:14 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Changing the primary AUTHID using RACROUTE >> >> >Put the address of the new ACEE in ASCBSENV and/or TCBSENV as >> appropriate? >> >> >J R >> >> I think it's ASXBSENV. >> >> For my test application TCBSENV is 0. >> >> I get a S0C4 when I do attempt to replace ASXBSENV despite being >> authorized and in supervisor mode. It feels like there is a RACROUTE macro >> or equivalent that says "start using this ACEE" which will put the value in >> ASXBSENV and probably update ASXBUSER? >> >> I see references to the RACINIT macro which has similar parameters but it >> appears to be a parallel function to RACROUTE ENVIR=CREATE and not a >> sequencing thing, that is you aren't supposed to do RACROUTE ENVIR=CREATE >> and then RACINIT ENVIR=CREATE. >> >> For what I'm trying to do, that is create a new secondary ACEE and run >> under this new ACEE's authority, would the RACINIT macro be more >> appropriate? >> >> Janet >> >> -- >> 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: Changing the primary AUTHID using RACROUTE
Janet, I work off the TSB On Thursday, October 13, 2016, J R wrote: > My apologies, yes, I meant ASXBSENV. > Re. RACROUTE, this is a higher layer (SAF - System Authorization Facility) > to request auth functions without concern over which specific security > server is in use, ie. RACF, ACF2 or TSS. Before SAF, non-RACF alternatives > would need to hijack SVCs 130-133. > > If you are not sure which security server is in use, it's always safer to > use RACROUTE. > > Sent from my iPhone > > > > > From: IBM Mainframe Discussion List > on behalf of Janet Graff < > 004dc9e91b6d-dmarc-requ...@listserv.ua.edu > > Sent: Thursday, October 13, 2016 1:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Changing the primary AUTHID using RACROUTE > > >Put the address of the new ACEE in ASCBSENV and/or TCBSENV as appropriate? > > >J R > > I think it's ASXBSENV. > > For my test application TCBSENV is 0. > > I get a S0C4 when I do attempt to replace ASXBSENV despite being > authorized and in supervisor mode. It feels like there is a RACROUTE macro > or equivalent that says "start using this ACEE" which will put the value in > ASXBSENV and probably update ASXBUSER? > > I see references to the RACINIT macro which has similar parameters but it > appears to be a parallel function to RACROUTE ENVIR=CREATE and not a > sequencing thing, that is you aren't supposed to do RACROUTE ENVIR=CREATE > and then RACINIT ENVIR=CREATE. > > For what I'm trying to do, that is create a new secondary ACEE and run > under this new ACEE's authority, would the RACINIT macro be more > appropriate? > > Janet > > -- > 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: Changing the primary AUTHID using RACROUTE
My apologies, yes, I meant ASXBSENV. Re. RACROUTE, this is a higher layer (SAF - System Authorization Facility) to request auth functions without concern over which specific security server is in use, ie. RACF, ACF2 or TSS. Before SAF, non-RACF alternatives would need to hijack SVCs 130-133. If you are not sure which security server is in use, it's always safer to use RACROUTE. Sent from my iPhone From: IBM Mainframe Discussion List on behalf of Janet Graff <004dc9e91b6d-dmarc-requ...@listserv.ua.edu> Sent: Thursday, October 13, 2016 1:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Changing the primary AUTHID using RACROUTE >Put the address of the new ACEE in ASCBSENV and/or TCBSENV as appropriate? >J R I think it's ASXBSENV. For my test application TCBSENV is 0. I get a S0C4 when I do attempt to replace ASXBSENV despite being authorized and in supervisor mode. It feels like there is a RACROUTE macro or equivalent that says "start using this ACEE" which will put the value in ASXBSENV and probably update ASXBUSER? I see references to the RACINIT macro which has similar parameters but it appears to be a parallel function to RACROUTE ENVIR=CREATE and not a sequencing thing, that is you aren't supposed to do RACROUTE ENVIR=CREATE and then RACINIT ENVIR=CREATE. For what I'm trying to do, that is create a new secondary ACEE and run under this new ACEE's authority, would the RACINIT macro be more appropriate? Janet -- 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: Changing the primary AUTHID using RACROUTE
>For simplicity and safety,you could attach a subtask, and do the VERIFY (and >the cross-memory call) from that subtask. Then, on the VERIFY, if you >omit >the ACEE parameter RACF will (as documented in the RACROUTE book) put the ACEE >address into TCBSENV for you. If the cross-memory server >is setup correctly >it should find the ACEE there. >-- >Walt Walt (and everyone else!) Thank you so much! That did it. My test program is exhibiting the same behaviors that I get when invoking my system level task from CICS etc. I can't thank you enough for all your help! Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
>I'm afraid we still don't know enough about how your cross-memory server is >operating. In an earlier post you implied that it will choose whether to >use >the primary or secondary ID. How does it make that choice? And how does it >find both of them. >If you change ASXBSENV you are changing the primary ID, not creating a >secondary one as (I think) you mentioned. That is dangerous and may ?>have >side effects you haven't thought about. >For simplicity and safety,you could attach a subtask, and do the VERIFY (and >the cross-memory call) from that subtask. Then, on the VERIFY, if you >omit >the ACEE parameter RACF will (as documented in the RACROUTE book) put the ACEE >address into TCBSENV for you. If the cross-memory server >is setup correctly >it should find the ACEE there. >-- >Walt Thanks Walt! The cross memory server is designed to handle callers from CICS, IDMS and other environments like that. For my test program I want to simulate the secondary ACEE that occurs in those environments without the test harness overhead of using those actual environments. So really do need a primary ACEE and a secondary ACEE. I will code up the attached subtask. For my clarification, I current have just the one main task that does a RACROUTE REQUEST=VERIFY,ENVIR=CREATE that specifies the USERID, PASSWORD and the ACEE as follows RACROUTE REQUEST=VERIFY,WORKA=(R7),SYSTEM=YES,PASSCHK=YES,X ENVIR=CREATE,USERID=(R5),PASSWRD=(R6),ACEE=(R8),X GROUP=(R10),X RELEASE=1.9.2,MF=(E,RACRWORK) And you are advising me to put this in an attached subtask to my test program and remove the ACEE parameter? Will I need to specify additional parameters in that case? ISTR that without the ACEE parameter I was getting the '*' in the ACEE's userid as per the doc (sort of), but that was when I was running the VERIFY in the main task. "1. If you omit USERID, GROUP, and PASSWRD and if you code ENVIR=CREATE or if ENVIR=CREATE is used as the default, you receive a return code of X'00' and obtain an ACEE that contains an asterisk (*) (X'5C') in place of the USERID and group name. " Thanks! Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
On Thu, 13 Oct 2016 00:29:58 -0500, Janet Graff wrote: >Aha, I just released I have to be in Key 0 to store into the ASXB. Can >someone confirm that to change the ACEE in use, I have to update ASXBSENV? >That there is no macro that will do this for me? I'm afraid we still don't know enough about how your cross-memory server is operating. In an earlier post you implied that it will choose whether to use the primary or secondary ID. How does it make that choice? And how does it find both of them. If you change ASXBSENV you are changing the primary ID, not creating a secondary one as (I think) you mentioned. That is dangerous and may have side effects you haven't thought about. For simplicity and safety,you could attach a subtask, and do the VERIFY (and the cross-memory call) from that subtask. Then, on the VERIFY, if you omit the ACEE parameter RACF will (as documented in the RACROUTE book) put the ACEE address into TCBSENV for you. If the cross-memory server is setup correctly it should find the ACEE there. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
>>Put the address of the new ACEE in ASCBSENV and/or TCBSENV as appropriate? >>J R >I think it's ASXBSENV. >For my test application TCBSENV is 0. >I get a S0C4 when I do attempt to replace ASXBSENV despite being authorized >and in supervisor mode. It feels like there is a RACROUTE macro or >>equivalent that says "start using this ACEE" which will put the value in >ASXBSENV and probably update ASXBUSER? >I see references to the RACINIT macro which has similar parameters but it >appears to be a parallel function to RACROUTE ENVIR=CREATE and not a >>sequencing thing, that is you aren't supposed to do RACROUTE ENVIR=CREATE and >then RACINIT ENVIR=CREATE. >For what I'm trying to do, that is create a new secondary ACEE and run under >this new ACEE's authority, would the RACINIT macro be more >appropriate? >Janet Aha, I just released I have to be in Key 0 to store into the ASXB. Can someone confirm that to change the ACEE in use, I have to update ASXBSENV? That there is no macro that will do this for me? Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
>Put the address of the new ACEE in ASCBSENV and/or TCBSENV as appropriate? >J R I think it's ASXBSENV. For my test application TCBSENV is 0. I get a S0C4 when I do attempt to replace ASXBSENV despite being authorized and in supervisor mode. It feels like there is a RACROUTE macro or equivalent that says "start using this ACEE" which will put the value in ASXBSENV and probably update ASXBUSER? I see references to the RACINIT macro which has similar parameters but it appears to be a parallel function to RACROUTE ENVIR=CREATE and not a sequencing thing, that is you aren't supposed to do RACROUTE ENVIR=CREATE and then RACINIT ENVIR=CREATE. For what I'm trying to do, that is create a new secondary ACEE and run under this new ACEE's authority, would the RACINIT macro be more appropriate? Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
Put the address of the new ACEE in ASCBSENV and/or TCBSENV as appropriate? Sent from my iPhone On Oct 12, 2016, at 21:36, Janet Graff <004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote: >> Thanks for the info. It helps a bit, but not enough. > >> First, just to make sure you know, you can't do a RACROUTE REQUEST=VERIFY >> while running in cross-memory mode. You would need to create a >request for >> another task running in your server primary, queue the request to the task, >> and suspend the cross-memory task until you have an >answer. > >> Next, doing a VERIFY for a user ID is not really sufficient in the general >> case, as there are many other aspects of the user's security environment >> >that could affect the answer to an authorization check (group name, >> terminal name or other port of entry, SECLABEL etc.). At a minimum you >> should >use the UTOKEN as input to the VERIFY (if you have to create a new >> ACEE) but even that is not sufficient in some cases. So, if you're doing >> this for a >product (as opposed to a bit of home-grown code just for your >> own company's use) then you need to rethink how much data you capture. For >> >example, it may be much better to use a RACROUTE REQUEST=EXTRACT >> TYPE=ENVRXTR to get a copy of the user's ACEE, and then recreate it in >your >> address space using RACROUTE REQUEST=VERIFY that specifies ENVIRIN. > >> But even before that, what kind of checks do you plan to make using the ACEE >> once you have it? (What resource class, for example?) If you're lucky >they >> will be checks that you could perform using the existing user's ACEE rather >> than rebuilding one. That would be both more efficient, and give you >a much >> simpler overall design. > > -- >> Walt > > Walt, > > Thanks for the reply! > > The cross memory mode for the system level task code is all written and has > been in the field for many years. (chances are I'm going to bolix up this > explanation but I'll give it a go) The system level code uses an RACROUTE > FASTAUTH or AUTH to verify General Resource Profiles with a pointer to the > callers ACEE for it's own use. It doesn't EXTRACT anything from the ACEE but > uses it for authorization checks. In any case my little test program doesn't > get involved in all that. > > What I'm trying to write is a stand alone assembler test program, that runs > in Batch under a userid. The test program creates a secondary ACEE using a > hard coded userid and password that is just used for testing purposes. Then > using this secondary ACEE it invokes the cross memory services support to the > system level task that will eventually use either the primary or the > secondary ACEE to validate access to resources. > > So I've got the return zero creating the secondary ACEE, but it appears that > after that, when I invoke the cross memory services it's done using the ACEE > from the primary id. What do I have to do to switch to using the secondary > ACEE? > > Janet > > -- > 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: Changing the primary AUTHID using RACROUTE
>Thanks for the info. It helps a bit, but not enough. >First, just to make sure you know, you can't do a RACROUTE REQUEST=VERIFY >while running in cross-memory mode. You would need to create a >request for >another task running in your server primary, queue the request to the task, >and suspend the cross-memory task until you have an >answer. >Next, doing a VERIFY for a user ID is not really sufficient in the general >case, as there are many other aspects of the user's security environment >that >could affect the answer to an authorization check (group name, terminal name >or other port of entry, SECLABEL etc.). At a minimum you should >use the >UTOKEN as input to the VERIFY (if you have to create a new ACEE) but even that >is not sufficient in some cases. So, if you're doing this for a >product (as >opposed to a bit of home-grown code just for your own company's use) then you >need to rethink how much data you capture. For >example, it may be much better >to use a RACROUTE REQUEST=EXTRACT TYPE=ENVRXTR to get a copy of the user's >ACEE, and then recreate it in >your address space using RACROUTE >REQUEST=VERIFY that specifies ENVIRIN. >But even before that, what kind of checks do you plan to make using the ACEE >once you have it? (What resource class, for example?) If you're lucky >they >will be checks that you could perform using the existing user's ACEE rather >than rebuilding one. That would be both more efficient, and give you >a much >simpler overall design. -- >Walt Walt, Thanks for the reply! The cross memory mode for the system level task code is all written and has been in the field for many years. (chances are I'm going to bolix up this explanation but I'll give it a go) The system level code uses an RACROUTE FASTAUTH or AUTH to verify General Resource Profiles with a pointer to the callers ACEE for it's own use. It doesn't EXTRACT anything from the ACEE but uses it for authorization checks. In any case my little test program doesn't get involved in all that. What I'm trying to write is a stand alone assembler test program, that runs in Batch under a userid. The test program creates a secondary ACEE using a hard coded userid and password that is just used for testing purposes. Then using this secondary ACEE it invokes the cross memory services support to the system level task that will eventually use either the primary or the secondary ACEE to validate access to resources. So I've got the return zero creating the secondary ACEE, but it appears that after that, when I invoke the cross memory services it's done using the ACEE from the primary id. What do I have to do to switch to using the secondary ACEE? Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
I am by no means an expert on this topic but keep in mind of course -- in addition to Walt's excellent tips -- that not every customer uses RACF: some use CA TSS and some use CA ACF2. While a lot of the behavior of the three subsystems is the same, some behavior is definitely different. Does it affect what you are doing here? I don't know. The three systems are surprisingly compatible in many ways (and totally different in others). I don't know enough to warn you of specific gotchas, but at the very least you should be aware that they could exist and think about testing in the TSS and ACF2 environments. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Janet Graff Sent: Wednesday, October 12, 2016 4:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Changing the primary AUTHID using RACROUTE >It would help to know why you want to do that, and what you intend to do after >you have the ACEE. It's possible that there are alternatives that >would be >better, which we might recommend if we had some more information. >However, you don't _need_ a TERMID unless you're doing a RACROUTE >REQUEST=VERIFY for a user's TSO session. It's certainly not related to the >>error message you're getting, which is quite clearly due to an invalid user >ID. You probably got that error message because you've said that the >ength of >the user ID is 8, but MYUSER is only 6 characters long. That won't work. >-- >Walt Walt, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
On Wed, 12 Oct 2016 18:53:29 -0500, Janet Graff wrote: >I am writing a test program for a system level task. The system level task >accepts cross memory service calls from various address spaces including CICS, >IDMS and IMS so it needs to be able to handle secondary ACEEs. Instead of >bringing up a more complicated subsystem in my automation tests I'd like to >write a neat standalone assembler program that creates a secondary ACEE and >then uses it to make the cross memory services call. > >With your's and Charles' help I now have the ENVIR=CREATE working and I've >determined that the ENVIR=CHANGE does me no good because it can only modify >the GROUP and the not the userid. > >I expected that the ENVIR=CREATE would create the ACEE and start using it. >However I'm still getting indications after the ENVIR=CREATE that the cross >memory services call is still using the initial userid and not the userid from >the secondary ACEE. > >Is there another step I should do before performing the cross memory services >call to make the new ACEE active? I also expected to get a message from RACF >indicating the switch to the new ACEE with maybe an ICH message showing the >new userid, which I'm not getting and is leading me to believe that I haven't >actually switched to the new ACEE. Thanks for the info. It helps a bit, but not enough. First, just to make sure you know, you can't do a RACROUTE REQUEST=VERIFY while running in cross-memory mode. You would need to create a request for another task running in your server primary, queue the request to the task, and suspend the cross-memory task until you have an answer. Next, doing a VERIFY for a user ID is not really sufficient in the general case, as there are many other aspects of the user's security environment that could affect the answer to an authorization check (group name, terminal name or other port of entry, SECLABEL etc.). At a minimum you should use the UTOKEN as input to the VERIFY (if you have to create a new ACEE) but even that is not sufficient in some cases. So, if you're doing this for a product (as opposed to a bit of home-grown code just for your own company's use) then you need to rethink how much data you capture. For example, it may be much better to use a RACROUTE REQUEST=EXTRACT TYPE=ENVRXTR to get a copy of the user's ACEE, and then recreate it in your address space using RACROUTE REQUEST=VERIFY that specifies ENVIRIN. But even before that, what kind of checks do you plan to make using the ACEE once you have it? (What resource class, for example?) If you're lucky they will be checks that you could perform using the existing user's ACEE rather than rebuilding one. That would be both more efficient, and give you a much simpler overall design. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
On 12 October 2016 at 18:25, Janet Graff <004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote: > I changed the TERMID to point to a D'0' but I'm getting the same error message > > ICH408I JOB(JIGRACF ) STEP(RUN ) 944 > LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED > IRR012I VERIFICATION FAILED. USER PROFILE NOT FOUND. > > Which I think implies that it thinks I'm a terminal user, even though it has > binary zeros for the TERMINAL value in the ICH408I message. It *does* think you're a terminal user, but that's because you used TERMID= in the first place. Just don't specify it at all. If you specify it as D'0', RACINIT (invoked by RACROUTE) will generate a non-zero pointer to it, and then it will get mentioned in any messages, and possibly used as part of logon checking. But as Walt points out, the problem is not with the TERMID, but with the userid. One could argue that the ICH408I message is a bit unclear, but it's the standard "userid not found" that happens to mention the (null) terminal name in passing. Also... These are problematic if they are this way in your actual source. (Of course I understand you may have posted an abbreviated example here): MVC USERLEN,8 MVC USERID,=CL8'MYUSER ' MVC PSWLEN,8 MVC PASSWD,=CL8'' Those two length MVCs should almost certainly be MVIs. Or you can use MVC with =FL1'8' if you prefer. (While you're there, turn on the HLASM option "PAGE0". I know it has saved me much debugging angst, and it may do the same for you some day even if this isn't part of the current problem.) And the length you tell RACF for the userid (and password, for that matter) must match the actual userid's length - not that of the blank-padded field it's in. > Also I suspect I might be archaic by using RELEASE=1.9.2, is there a more > appropriate value for this decade? I've been using 7730 for some time. Certainly 7730 is of this millennium, but it's probably time that I looked into its antiquity too. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
>It would help to know why you want to do that, and what you intend to do after >you have the ACEE. It's possible that there are alternatives that >would be >better, which we might recommend if we had some more information. >However, you don't _need_ a TERMID unless you're doing a RACROUTE >REQUEST=VERIFY for a user's TSO session. It's certainly not related to the >>error message you're getting, which is quite clearly due to an invalid user >ID. You probably got that error message because you've said that the >ength of >the user ID is 8, but MYUSER is only 6 characters long. That won't work. >-- >Walt Walt, I am writing a test program for a system level task. The system level task accepts cross memory service calls from various address spaces including CICS, IDMS and IMS so it needs to be able to handle secondary ACEEs. Instead of bringing up a more complicated subsystem in my automation tests I'd like to write a neat standalone assembler program that creates a secondary ACEE and then uses it to make the cross memory services call. With your's and Charles' help I now have the ENVIR=CREATE working and I've determined that the ENVIR=CHANGE does me no good because it can only modify the GROUP and the not the userid. I expected that the ENVIR=CREATE would create the ACEE and start using it. However I'm still getting indications after the ENVIR=CREATE that the cross memory services call is still using the initial userid and not the userid from the secondary ACEE. Is there another step I should do before performing the cross memory services call to make the new ACEE active? I also expected to get a message from RACF indicating the switch to the new ACEE with maybe an ICH message showing the new userid, which I'm not getting and is leading me to believe that I haven't actually switched to the new ACEE. Thanks! Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
Was I being clear? You asked "where do I get the TERMID?" and I meant "why not pick up your current TERMID from your existing ACEE? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Janet Graff Sent: Wednesday, October 12, 2016 3:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Changing the primary AUTHID using RACROUTE >From your current ACEE? >http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r >1.ichb200/ich2b2_ACEE_and_related_control_blocks.htm >52 (34) ADDRESS 4 ACEETRMP Address that points to the terminal ID. The >field is zero for non-terminal users. >Charles Yes, the Batch job is run under the job's userid. I want to then programmatically change to a second userid and create an ACEE. Do I have to get hold of my current ACEE and update the USERID/PASSWRD/GROUP fields or can I just issue the code I specified in my original post? I changed the TERMID to point to a D'0' but I'm getting the same error message ICH408I JOB(JIGRACF ) STEP(RUN ) 944 LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED IRR012I VERIFICATION FAILED. USER PROFILE NOT FOUND. Which I think implies that it thinks I'm a terminal user, even though it has binary zeros for the TERMINAL value in the ICH408I message. Janet -- 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: Changing the primary AUTHID using RACROUTE
On Wed, 12 Oct 2016 15:58:12 -0500, Janet Graff wrote: >I have an application and I want to change the the userid. I have the RACF >macros coded but I'm having trouble coming up with the >source of TERMID. >Where do I get the TERMID? It would help to know why you want to do that, and what you intend to do after you have the ACEE. It's possible that there are alternatives that would be better, which we might recommend if we had some more information. However, you don't _need_ a TERMID unless you're doing a RACROUTE REQUEST=VERIFY for a user's TSO session. It's certainly not related to the error message you're getting, which is quite clearly due to an invalid user ID. You probably got that error message because you've said that the length of the user ID is 8, but MYUSER is only 6 characters long. That won't work. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
>From your current ACEE? >http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ichb200/ich2b2_ACEE_and_related_control_blocks.htm > >52 (34) ADDRESS 4 ACEETRMP Address that points to the terminal ID. The field is >zero for non-terminal users. >Charles Yes, the Batch job is run under the job's userid. I want to then programmatically change to a second userid and create an ACEE. Do I have to get hold of my current ACEE and update the USERID/PASSWRD/GROUP fields or can I just issue the code I specified in my original post? I changed the TERMID to point to a D'0' but I'm getting the same error message ICH408I JOB(JIGRACF ) STEP(RUN ) 944 LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED IRR012I VERIFICATION FAILED. USER PROFILE NOT FOUND. Which I think implies that it thinks I'm a terminal user, even though it has binary zeros for the TERMINAL value in the ICH408I message. Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing the primary AUTHID using RACROUTE
>From your current ACEE? http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ichb200/ich2b2_ACEE_and_related_control_blocks.htm 52 (34) ADDRESS 4 ACEETRMP Address that points to the terminal ID. The field is zero for non-terminal users. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Janet Graff Sent: Wednesday, October 12, 2016 1:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Changing the primary AUTHID using RACROUTE I have an application and I want to change the the userid. I have the RACF macros coded but I'm having trouble coming up with the source of TERMID. Where do I get the TERMID? The code in question looks like this: MODESET MODE=SUP LAR7,RACFWORK MVC RACRWORK,RACRLIST MVC USERLEN,8 MVC USERID,=CL8'MYUSER ' MVC PSWLEN,8 MVC PASSWD,=CL8'' MVC MYACEE,=F'0' MVC MYTERM,=CL8'' < clearly I need a value here LAR5,USERLEN LAR6,PSWLEN LAR8,MYACEE LAR9,MYTERM RACROUTE REQUEST=VERIFY,WORKA=(R7),SYSTEM=YES,PASSCHK=YES,X ENVIR=CREATE,USERID=(R5),PASSWRD=(R6),ACEE=(R8), X TERMID=(R9), X RELEASE=1.9.2,MF=(E,RACRWORK) STR15,RC ... MVC RACRWORK,RACRLIS2 LAR8,MYACEE RACROUTE REQUEST=VERIFY,WORKA=(R7),SYSTEM=YES,PASSCHK=NO, X ENVIR=CHANGE,ACEE=(R8), X RELEASE=1.9.2,MF=(E,RACRWORK) STR15,RC MODESET MODE=PROB The error I'm getting is this ICH408I JOB(JIGRACF ) STEP(RUN ) 790 LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED Which clearly says I need to provide a TERMID (or equivalent) on the ENVIR=CREATE. Where do I get the TERMID? Also I suspect I might be archaic by using RELEASE=1.9.2, is there a more appropriate value for this decade? Janet -- 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
Changing the primary AUTHID using RACROUTE
I have an application and I want to change the the userid. I have the RACF macros coded but I'm having trouble coming up with the source of TERMID. Where do I get the TERMID? The code in question looks like this: MODESET MODE=SUP LAR7,RACFWORK MVC RACRWORK,RACRLIST MVC USERLEN,8 MVC USERID,=CL8'MYUSER ' MVC PSWLEN,8 MVC PASSWD,=CL8'' MVC MYACEE,=F'0' MVC MYTERM,=CL8'' < clearly I need a value here LAR5,USERLEN LAR6,PSWLEN LAR8,MYACEE LAR9,MYTERM RACROUTE REQUEST=VERIFY,WORKA=(R7),SYSTEM=YES,PASSCHK=YES,X ENVIR=CREATE,USERID=(R5),PASSWRD=(R6),ACEE=(R8), X TERMID=(R9), X RELEASE=1.9.2,MF=(E,RACRWORK) STR15,RC ... MVC RACRWORK,RACRLIS2 LAR8,MYACEE RACROUTE REQUEST=VERIFY,WORKA=(R7),SYSTEM=YES,PASSCHK=NO, X ENVIR=CHANGE,ACEE=(R8), X RELEASE=1.9.2,MF=(E,RACRWORK) STR15,RC MODESET MODE=PROB The error I'm getting is this ICH408I JOB(JIGRACF ) STEP(RUN ) 790 LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED Which clearly says I need to provide a TERMID (or equivalent) on the ENVIR=CREATE. Where do I get the TERMID? Also I suspect I might be archaic by using RELEASE=1.9.2, is there a more appropriate value for this decade? Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
