John Yeah RACROUTE VERIFY(X) is the fella - see the RACROUTE manual for more info - not exactly a "for dummies" book though :-)
Obviously with a multi-user address space you would need to wrap somnething like a task-level RESMGR around each TCB that is created for the user "signon". If there is no z/OS-supplied cleanup of ACEE, then your RESMGR could perform the VERIFYX ENVIR=DELETE - in fact this is probably a good idea anyway. Another job for the RESMGR could be to cut a "sign-off" SMF record (and you could cut a "sign-on" when you perform the VERIFYX ENVIR=CREATE). If you go down the "START" command route and your method of assigning ownership to the created address space is a parameter on the START command - what is to stop any bozo who has opercmd authority from spoofing a userid on to one of your address spaces ? There is something that makes me uneasy about an address space that spawns other address spaces in the fashion that you describe - maybe I am concerned about ASVT slot shortages if the spawn process gets into trouble or any x-memory coding errors that could mark these ASIDs as non-reusable. Rob Scott Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: 16 April 2010 14:25 To: IBM-MAIN@bama.ua.edu Subject: Re: Internal (program) start of an STC - MGCRE vs. ASCRE > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rob Scott > Sent: Friday, April 16, 2010 7:51 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Internal (program) start of an STC - MGCRE vs. ASCRE > > >>I don't think I can use a single STC because I want the STC > to service multiple users, each with their own RACF security > environment (different z/OS RACF ids). > > This is possible within z/OS and exactly why the TCBSENV field exists. > > Rob Scott Now that you mention it, I remember that ROSCOE did this too. Unfortunately, I don't know how to do this, and can't find documentation on it that I understand (I think this is some RACROUTE function, VERIFYX?). I do seem to understand the BPX1SEC service, which is address space oriented. Perhaps I should just "go UNIX" and use POSIX threads with the BPX1TLS (pthread_security_np) service. I don't know why, but these just seem easier to use, to me. Then again, there's the RACF callable service: IRRSIA00. Also, if I use a separate address space, I don't need to worry about deleting the ACEE. I don't know what happens when a subtask does a VERIFYX to set the TCBSENV terminates. I would like a RACF SMF records to be cut like happens with CICS on the CESN and CESF commands. I haven't seen a "Programming RACF Interfaces for Dummies" book around. Not that I'm likely to actually __do__ this. My company is very tight on CPU and likely would not approve me "doing things in order to lea! rn" anymore. Another point is the SDSF OWNER field. With different STCs, one per user, I think the SDSF OWNER would show who was "logged on" to the service via that STC. Of course, I could make the STC respond to a MODIFY command such as: F STCNAME,LIST USERS or some such. Also, the resource usage would be recorded to a specific STC, and thus user, in the SMF records cut for the STC. At least I hope the SMF records would show the "logged on" RACF id for the STC. But, if I use the MGCRE to do a START, then I'm going to put the RACF id in the start: START STCJCL.racfid or maybe use a started JOB: START STCJCL,JOBNAME=racfid. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
