P.S. We have hundreds of users!
A: I had to handle that exact problem at my shop, and the solution is simple. The Grant User Permission (GRTUSRPMN) command on the AS/400 allows one user to "work on behalf of" another user. Here's some of the command's help text:
"The Grant User Permission (GRTUSRPMN) command allows you to grant permission for a user to handle documents and folders or to perform OfficeVision/400-related tasks on behalf of another user. Access is restricted to documents, folders, and mail items that are not personal."
This command was exactly what I was looking for. Figure 1 below illustrates how it can be used.
Figure 1: GRTUSRPMN allows one user to work on behalf of another.
In the code above, the SNDDST will work fine if the current user attached to the job is enrolled in the system directory. But if that user is not enrolled in the system directory, a CPF9006 error is generated: "User not enrolled in system distribution directory." If that happens, the MONMSG takes over; the user is granted permission to work on behalf of user CATALOG, the distribution is sent for user CATALOG, and (pay attention here!) the permission to work on behalf of user CATALOG is revoked.
Sometimes, the best security we have is that our users don't know what they can and cannot do (yeah, I see you nodding your head guiltily!). Still, I think it's a very good idea to revoke the authority to work on behalf of a user as soon as the task is done, and the command to do this is Revoke User Permission (RVKUSRPMN).
One problem that you may encounter using the GRTUSRPMN and RVKUSRPMN commands is that one of the users must have All Object Authority (*ALLOBJ). From the command's description in the OS/400 CL Reference V4R4 , I can't tell which user has to have the *ALLOBJ authority! The way we have all users or user CATALOG set up on my system, the command works fine; I didn't have to do anything with authority.
If you do encounter the authority problem, there are ways around that, such as using adopted authority. Authority issues are beyond the scope of this tip, but you can search on the MC Mag Online Security Patrol column to find out more.
So there you have it, the entire enchilada; now, you know that your users don't need to be enrolled in the system directory in order to send email.