--------------------------<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.
-----------------------------------------------------------------------------------------------------
True enough, but the "PROTECTED" attribute didn't exist when this was
all put in place.
Rick
----------------------------------------------------------------------
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
