Shutting Down WRKSBMJOB Options

October 5, 2005 Hey, Joe

I want to hide some of the options on the Work with Submitted Jobs command display (WRKSBMJOB) from my users. I don’t want certain user IDs to run option ‘2’=Change Job or option ‘3’=Hold job. I need to do this for specific user IDs belonging to a certain group profile. For other users, I’d like these options to be usable. Do you have any suggestions?

–Pankaj

The simple way to do this would be to limit authority to the commands that WRKSBMJOB calls when you type in option ‘2’ or option ‘3’. Option ‘2’ calls the Change Job command (CHGJOB) while option ‘3’ calls the Hold Job command (HLDJOB). You can limit the authority of your users to access each of these commands by following this steps.

For either of the commands you want to limit, enter the Edit Object Authority command (EDTOBJAUT) as follows:

EDTOBJAUT OBJ(command_name) OBJTYPE(*CMD)

What you will probably see if that the public user (*PUBLIC) has use authority (*USE) and the owner of the object has all authority to manipulate that object (*ALL). Public *USE authority means that anyone can call the command. If you wanted to change your authorities to only allow certain groups of users to run the HLDJOB or CHGJOB commands, you could change the object authorities on those commands to the following:

By changing public user access to *EXCLUDE, you are revoking public use authority so that a user or a group profile has to be explicitly authorized to the command in order to use it. If the user belongs to a group profile that is authorized to run this command (*USE authority), he can run the command. If he isn’t in an authorized group, he’s out of luck. The object owner should usually have *ALL authority to the command. If you do this for both the HLDJOB and CHGJOB commands, that should solve this problem for you and prevent unauthorized users from accessing these options.

That’s the easy way to do this, but this technique does have two downsides.

First, limiting access to these commands will affect any situation where the commands are run, not just when they are executed during options ‘2’ and ‘3’ of the WRKSBMJOB command. There may be some legitimate cases where your users will need to change or hold their jobs, so think twice about your requirements before you take away their access.

The second problem occurs when you want to limit access to these commands for user profiles that have all object authority (*ALLOBJ) on the system. For *ALLOBJ users, there is no way to restrict them from accessing any object on the system. In order to restrict these users, you may need to review their access and redefine their user profile special authorities back to a level that is more compatible with a controlled system. Not everyone needs to be a security officer to get work done on the system and–in general–the fewer people who have *ALLOBJ authority on your system, the better. For more information on user authorities, see A Checklist for Creating OS/400 User Profiles, Part I.

–Joe