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.
Bruce Bardini is a Senior Programmer/Analyst at Bachrach Clothing, Inc., with over 15 years of experience on the AS/400. He can be reached by email at
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online