It can be done. We provide logons for some of our operations people which could be considered very restricted with privileges needed to manage printers for instance.
RACF-L is the best place to go for HOWTO advice on RACF but IBM-MAIN covers just about anything too. RACF-L From http://www-1.ibm.com/servers/eserver/zseries/zos/racf/racf-l.html The RACF-L Discussion List Customers and IBM participants may also discuss RACF on the RACF-L discussion list. RACF-L is not operated or sponsored by IBM, but is run by the University of Georgia. To subscribe to the RACF-L discussion in order to receive postings, send a note to: [EMAIL PROTECTED] Include the following line in the body of the note, substituting your first name and last name as indicated: subscribe racf-l first_name last_name To post a question or response to the RACF-L forum, send a note to: [EMAIL PROTECTED] Please include an appropriate subject line in your posting. The RESTRICTED attribute assigned to the USERID should help a lot. RESTRICTED specifies that global access checking is bypassed when resource access checking is performed for the user, and neither ID(*) on the access list nor the UACC will allow access. The RESTRICTED.FILESYS.ACCESS profile in the UNIXPRIV class can also be used to bypass the z/OS UNIX 'other' permission bits during file access checking for RESTRICTED users. Note: If your installation has profiles defined in the PROGRAM class, and the user ID with the RESTRICTED attribute needs to load programs covered by one or more of these profiles, the user id must be put on the access list with EXECUTE or READ authority. We built out users long before RESTRICTED became available so we did much the same thing with a group called NOACCESS and permitted them NONE to virtually everything. Today I think RESTRICTED is a better way to go but in full disclosure I have read about but not implemented with it yet. As far as TSO/E you should not need anything more than a unique LOGON PROC and you might consider to make the allocations and throw them directly into the application using the an EXEC run by the LOGON PROC. Good Luck! Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -----Original Message----- From: IBM Mainframe Discussion List On Behalf Of Steve Grimes Sent: Tuesday, October 25, 2005 7:11 PM To: [email protected] Subject: Allowing Joe User into TSO Hello, z/OS 1.4 here. I apologize in advance for not knowing the best list to send this question to. (Perhaps ISPF-L? But I'm not a subscriber there.) I'm proposing to our systems folks that we allow a "user" to use TSO to get to the Zeke Work Center function. I'm being told that there is no way for us to limit what the user can do if we let them intoTSO. (Historically, we had RACF practically emasculated. This has been tightened down recently. Our application programmers no longer, for instance, have update access to SYS1.PARMLIB, etc.) I'm going to counter this assertion with my own, namely: We can create a sign-on PROC that executes a CLIST and panel that only gives this user access to Zeke. Once they're in Zeke, I'm confident (using the Zeke security functions) that I can limit them to just what I want them to be able to do. I'm hoping no RACF changes will be required, except perhaps for authorization to execute the sign-on proc. The only catch I see is that we currently select (from our initial menu) the "Altai/Platinum" product support menu which has Zara and Zeke, and choose Zeke from there. We don't want this user to see Zara, only Zeke. Am I making sense? Is my position sound? Any tips? I have been looking at the TSO/E Customization manual. The two-step I'll face is: 1) It can't be done. 2) It would take a long time to do that. TIA! Stg ---------------------------------------------------------------------- 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 ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. ---------------------------------------------------------------------- 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
