The whole idea of "production" user profiles is that they have no passwords,
thus limiting the access to them to surrogat profiles. The RACF surrogat
class, in the form "userid.submit", as others have cited, can provide the
ability for USERA to submit a job with USER=USERB, with no password operand
on the job card.
In rationally configured shops only the scheduling package started task has
access to any surrogat profiles. Odd that this is continuing on IBM-MAIN.
It's rather basic RACF-L subject matter.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Edward Jaffe
Sent: Monday, October 05, 2009 4:01 PM
To: [email protected]
Subject: Re: Multiple jobs/same name
Rick Fochtman wrote:
> But you still need to prevent testers from submitting jobs with a
> production USERID. We used a TSO exit to remove USER/PASSWORD parms
> from the JOB statement. Got a better idea?
Really?
1. You use a TSO/E user exit to block this? What if they submit a job with
USER= and PASSWORD= to INTRDR using IEBGENER in a batch job?
2. Your testers know a userid/password combination that will give them
production credentials?
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[email protected]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
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
_______________________________________
No viruses found in this incoming message Scanned by iolo AntiVirus 1.5.8.3
http://www.iolo.com
----------------------------------------------------------------------
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
