Re: Disabled Userids

Steve.Neeland wrote:

Is anyone aware if a way exists to exempt a userid profile from
switching to a *DISABLED status when too many invalid passwords may be
entered? We have some special userids used for batch-only applications,
and if they happened to get disabled the applications would return
abends.

Steve:

A *DISABLED profile can still be the user of a submitted batch job. A simple batch job doesn't need an enabled job user. Why would such a profile have a password?

However, if something within the job requires an enabled job profile, then call a proc/program that ensures the profile is *ENABLED before entering the sensitive portion.

This proc/program could be created *OWNER and have sufficient authority to enable the job's profile. If it's a proc, call it out of a *SRVPGM.

One reason a password might be needed would be for signing on to remote servers and a matching password is being used. Note that an additional problem could be that the password was changed -- the profile is still enabled but the connection ain't gonna work. You fix the disabling but it still fails.

The above proc could also ensure that a password value was a correct one. The correct value would be stored externally in encrypted form and retrieved as needed.

There are various ways of automating the re-enabling of profiles, but perhaps a closer look at the actual business need is called for. Maybe it just isn't needed. Even for remote servers, there are usually better ways.

Tom Liotta