On 10/13/2009 02:58 PM, Rick Fochtman wrote: > --------------------------<snip>------------------------------ > >>> 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? >>> >> >> Sure; don't have passwords for production jobs. Only allow them to be >> submitted by a user with surrogate access to the production user id. Only >> give that surrogate access to user ids that need it, e.g., scheduler. >> >> > ----------------------------<unsnip>------------------------------- > We eventually did just that. I set the password to a "private" value and > never told anyone what it was. Surrogate access was the ONLY way to > submit a production job, either by the automation or the production > support staff. > > Rick
But if you're going to use the userid in that fashion, it makes sense to go one step further and make it a RACF "PROTECTED" userid. Then there is no password to "forget" or protect, and better yet the userid cannot even be used in a context where a password would be required. Otherwise, someone can either intentionally or accidentally execute a denial-of-service attack against your production job streams by trying enough bad passwords to revoke the userid and prevent production batch from running. Also, "PROCTECTED" will prevent a rarely used production userid from getting auto-revoked from excessive days from last use. -- Joel C. Ewing, Fort Smith, AR [email protected] ---------------------------------------------------------------------- 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
