Q:Do you have any guidelines for user profile names?

A:Here are some guidelines for user profile names. The individual profiles should have a maximum of 8 characters rather than the 10 allowed by the AS/400. This simplifies the use of the same profile on other systems. The $, #, and @ characters should not be used because they do not appear on all the keyboards of international systems.

The individual profiles should not have a departmental designation that would need to be changed if the individual changes job responsibilities and moves to a different department. I prefer to construct the profile from the user's last name and the first initial of his first name. I append a number in the case of duplicates. For example, the user profile for Jane Smith would be SMITHJ. If John Smith requires a profile, append his middle initial or a number to distinguish his profile from Jane's. One problem associated with using last names-a user typically wants her profile renamed when her name changes because of marriage or divorce.

Q:As a system manager, I want users to be able to send me messages; but I want to prevent them from viewing my messages. I also want to control other user message queues in the same manner. Is there a way I can accomplish this?

A:I recommend that you change the *PUBLIC authority for your message queue to *OBJOPR (operation authority) and *ADD (data add). Use the following two commands to change the *PUBLIC authority to your message queue:

 RVKOBJAUT OBJ(message_queue) + OBJTYPE(*MSGQ) USER(*PUBLIC) + AUT(*ALL) GRTOBJAUT OBJ(message_queue) + OBJTYPE(*MSGQ) USER(*PUBLIC) + AUT(*OBJOPR *ADD) 

When you create a new user profile, OS/400 creates a message queue with the same name and assigns it to the user profile. The *PUBLIC authority of the new message queue is *CHANGE.

The program in 1 changes the *PUBLIC authority for message queues assigned to user profiles. The program explicitly excludes QSYSOPR. Specific authorities giving user profiles access to a message queue are not affected. This program must be run by the security officer. To avoid allocation conflicts, you should run this program when no users are active.

The program in Figure 1 changes the *PUBLIC authority for message queues assigned to user profiles. The program explicitly excludes QSYSOPR. Specific authorities giving user profiles access to a message queue are not affected. This program must be run by the security officer. To avoid allocation conflicts, you should run this program when no users are active.

Q:I attempted to use your program from "Dynamic Change of Group Profile," MC, May 1994. The program would not work unless the user had *SECADM authority. Users received a not-authorized message from the Change User Profile (CHGUSRPRF) command. The program did not seem to adopt authority. I specified USRPRF(*OWNER) on the Create CL Program (CRTCLPGM) command as follows:

 CRTCLPGM PGM(GRP004CL) + USRPRF(*OWNER) 

Have other readers had similar problems? Is something wrong with program adoption?

A:The problem might occur because the program is not adopting authority or because the owner of the program does not have *SECADM authority. To determine if the program is actually adopting authority, display the program using the following command:

DSPPGM PGM(GRP004CL)

The Display Program Information panel shows you the user profile value and the owner of the program. The user profile value should be *OWNER. The owner of the program should have *ALLOBJ and *SECADM special authority. Use the Display User Profile (DSPUSRPRF) command to determine if the owner actually has these special authorities.

You may have an earlier version of the program on your AS/400 that did not adopt authority by specifying USRPRF(*OWNER). If the program object exists on your AS/400, the recompiled program will not adopt authority even if you specify USRPRF(*OWNER) on the CRTxxxPGM command.

The failure to adopt authority results from the way that Create CL Program (CRTCLPGM) and other CRTxxxPGM commands handle security attributes. In addition to the USRPRF keyword, each program creation command has a REPLACE keyword. The default for the REPLACE keyword is *YES, which indicates that you want to replace the existing program and that the new version of the program should retain the security attributes of the existing program. OS/400 ignores parameters such as USRPRF and AUT when the object currently exists and REPLACE(*YES) is specified.

To assign different security attributes to an existing version of a program you have two options:

1. Use the Change Program (CHGPGM) command to change the User Profile (USRPRF) attribute of the program to *OWNER.

2. Delete the existing program and then issue the CRTCLPGM command again. In this case, when you specify USRPRF(*OWNER), the new program will adopt authority.

I recommend option 1 if you have authorized several users to an existing program because all private authorities to the program are retained. You are not the first person (nor likely to be the last) to be confused by the REPLACE option.

Security Patrol: Security Questions & Answers

Figure 1 CL Program AUT002CL

 /*===============================================================*/ /* To compile: */ /* */ /* CRTCLPGM PGM(XXX/AUT002CL) SRCFILE(XXX/QCLSRC) */ /* */ /*===============================================================*/ AUT002CL: + PGM DCLF FILE(QADSPOBJ) DSPOBJD OBJ(QSYS/*ALL) OBJTYPE(*USRPRF) OUTPUT(*OUTFILE) + OUTFILE(QTEMP/ALLUSRPRF) OVRDBF FILE(QADSPOBJ) TOFILE(QTEMP/ALLUSRPRF) READ: + RCVF MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(EOF)) IF COND(&ODOBNM *NE 'QSYSOPR') THEN(DO) RVKOBJAUT OBJ(&ODOBNM) OBJTYPE(*MSGQ) USER(*PUBLIC) + AUT(*ALL) MONMSG MSGID(CPF0000) GRTOBJAUT OBJ(&ODOBNM) OBJTYPE(*MSGQ) USER(*PUBLIC) + AUT(*OBJOPR *ADD) MONMSG MSGID(CPF0000) ENDDO GOTO CMDLBL(READ) EOF: + ENDPGM