Robbie > I am trying to setup MVS/APPC for RRSF. Have all the definitions, in place, but am obviously making some mistake. When I start the APPC address space I get the following message
> ATB052E LOGICAL UNIT GHT1RACF FOR TRANSACTION SCHEDULER *NONE* 069, NOT ACTIVATED IN THE APPC CONFIGURATION. REASON CODE = 24. I expect you should have said "I *think* I have all the definitions in place" <g> Incidentally I had no idea what RRSF might be but I Googled it and found "RACF Remote Sharing Facility". > From what I understand is that this is indicative of a security problem. I do not see any RACF messages issued on either of the systems. There are also no VTAM BIND failure messages. When I first read your post, I thought you were assuming that this was a security problem because of the presence of the characters "RACF" in the name of the logical unit. Now knowing what RRSF means, I see that could be a reason for having RACF in the name of the LU. In fact, the ACB error (ACBERFLG) code 24 is a security error specifically when opening the ACB, which is the control block used by a program in order for the program to make itself known to VTAM. If this fails there is no possibility for any attempts to start sessions so there will certainly be no BIND failure messages. > So nothing much to go on..... What there is to go on is what the ATB052E message and the code 24 is telling us. First the ATB052E message is an error trying to open the ACB. The name of the APPL statement which corresponds to the ACB is GHT1RACF. The name of the transaction scheduler is *NONE*. I expect this means that the corresponding LUADD statement specifies NOSCHED. Turning to the error code 36 (hexadecimal 24), we find that the cause can be one of three: 1. "The password specified by the ACB did not match the corresponding password in the APPL entry." This means that the ACB identified a password which must be matched against the APPL statement PRTCT operand. The APPL statement PRTCT operand may or may not have specified a password but, either way, there was no match. As far as I can see, the LUADD statement does not allow for the specification of the ACB password. The LUADD statement is where I would expect such a password to be specified. 2. "The ACB did not specify a password and the APPL contains one." This means that the ACB did not identify a password but the APPL statement PRTCT operand did. Thus a way this condition could apply is if you specified a value on the PRTCT operand. As I just mentioned, I cannot see how a password can be specified for the APPC/MVS ACB. 3. "The security management product determined that the user is not authorized to open the ACB." Probably - and ironically, of course, given that the application concerns RACF - we have to conclude that the interaction of APPC/MVS and RACF is to blame. Note that it is *not* at the level of the session, conversation or transaction, but simply getting the d***ed ACB corresponding to the LUADD statement open at the time APPC/MVS is started.. Many years ago - 15 or so I guess - someone came into my office asking for help getting started with APPC/MVS. I had made sure I understood the topic and so had a nice neat set of definitions suitable for test/education systems. For the gentleman's benefit, I copied all the relevant definitions to CMS. When I left the education centre, I copied all these files to a diskette with the expectation I may need them again elsewhere. Indeed I did. Because of wanting to get to grips with APPC/MVS, I decided I had to get to know how RACF was working on my systems which hitherto had just corresponded to the environment created by the group from whom I "pinched" my basic system. This I did, shamefully remembering I was going through the RACF manual while listening to a New Year's concert.[1] I created a file with all necessary definitions and any changes were introduced by simply rebuilding the RACF data base. This is a suitable approach for a test/education system but not for production of course. I think I ran the same file for all 8 of my systems. Because that gentleman came into my office, I still have the file. Turing to the MVS Planning: APPC/MVS Management manual, I find section 10.4[2], "LU Security: Protecting APPC/MVS Logical Units". Here we find the following: <quote> Controlling the use of VTAM ACBs You can ensure that an LU is defined to VTAM from the APPC address space only, using RACF VTAMAPPL profiles. Subtopics: ... 10.4.3 Controlling the Use of VTAM ACBs </quote> It's encouraging that I find the following in my RACF file: RDEFINE VTAMAPPL A5xAPPC OWNER(SYSTEM) UACC(NONE) WARNING There are 8 statements for x = 1 to 8, one relating to each system. You should study section 10.4.3, "Controlling the Use of VTAM ACBs" in order to work out how to get round this third condition. I hope that's it! Chris Mason [1] European readers will instantly know to what I refer but those poor folk on the other side of the pond may need to know that every New Year's morning there is an essentially Strauss (father and son) concert from the Musikverein in Vienna. [2] Well, I *hope* I've understood the message. <g> ----- Original Message ----- From: "Robert Bell" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Friday, 23 February, 2007 8:43 PM Subject: MVS APPC RRSF > I hope that someone will be able to help. I do have an open question with > IBM, and have gone through all the posts on the racf listserv. > > I am trying to setup mvs/appc for rrsf. Have all the definitions, in place, > but am obviously making some mistake. When I start the appc address space I > get the following message > > ATB052E LOGICAL UNIT GHT1RACF FOR TRANSACTION SCHEDULER *NONE* 069, > NOT ACTIVATED IN THE APPC CONFIGURATION. REASON CODE = 24. > > From what I understand is that this is indicative of a security problem. > I do not see any racf messages issued on either of the systems. There are > also no vtam bind failure messages. > > So nothing much to go on..... > > Anyone able to help ? Any suggestions..... > > I will cross post to the racf list as well. > > TIA > Robbie ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
