Example: Change the menu control environment

In this example, you are changing the menu control environment for the Order Entry (OEMENU) menu and the associated files and programs.

This example starts with the following assumptions and requirements:
Perform the following steps to change this menu-access-control environment to accommodate the need for queries:
  1. Make sure that the OEMENU object (it may be a *PGM object or a *MENU object) is owned by a user profile that is not used for signon. The user profile should be disabled or have a password of *NONE. For this example, assume that OEOWNER owns the OEMENU program object.
  2. Make sure that the user profile that owns the OEMENU program object is not a group profile. You can use the following command: DSPUSRPRF USRPRF(OEOWNER) TYPE(*GRPMBR)
  3. Change the OEMENU program to adopt the authority of the OEOWNER user profile. Use the CHGPGM command to change the USRPRF parameter to *OWNER. *MENU objects cannot adopt authority. If OEMENU is a *MENU object, you can adapt this example by doing one of the following:
    • Create a program to display the menu.
    • Use adopted authority for the programs that run when the user selects options from the OEMENU menu.
  4. Set the public authority to all of the files in ORDERLIB to *USE by typing the following two commands:RVKOBJAUT OBJ(ORDERLIB/*ALL) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*ALL)GRTOBJAUT OBJ(ORDERLIB/*ALL) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*USE) Remember that if you select *USE authority, users can copy the file by using PC file transfer or FTP.
  5. Give the profile that owns the menu program *ALL authority to the files by typing the following: GRTOBJAUT OBJ(ORDERLIB/*ALL) OBJTYPE(*FILE) USER(OEOWNER) AUT(*ALL) For most applications, *CHANGE authority to files is sufficient. However, your applications may perform functions, such as clearing physical file members, that require more authority than *CHANGE. Eventually, you should analyze your applications and provide only the minimum authority that is necessary for the application. However, during the transition period, by adopting *ALL authority, you avoid application failures that may be caused by insufficient authority.
  6. Restrict authority to the programs in the order library by typing: GRTOBJAUT OBJ(ORDERPGM/*ALL) OBJTYPE(*PGM) USER(*PUBLIC) AUT(*EXCLUDE)
  7. Give the OEOWNER profile authority to the programs in the library by typing: GRTOBJAUT OBJ(ORDERPGM/*ALL) OBJTYPE(*PGM) USER(OEOWNER) AUT(*USE)
  8. Give the users that you identified in step 1 authority to the menu program by typing the following for each user: GRTOBJAUT OBJ(ORDERPGM/OEMENU) OBJTYPE(*PGM) USER(user-profile-name) AUT(*USE)
When you have completed these steps, all system users who are not explicitly excluded will be able to access (but not change) the files in the ORDERLIB library. Users who have authority to the OEMENU program will be able to use the programs that are on the menu to update files in the ORDERLIB library. Only users who have authority to the OEMENU program will now be able to change the files in this library. A combination of object security and menu access control protects the files.
When you complete similar steps for all the libraries that contain user data, you have created a simple scheme for controlling database updates. This method prevents system users from updating database files except when they use the approved menus and programs. At the same time, you have made database files available for viewing, analyzing, and copying by users with decision support tools or with links from another system or from a PC.
Tip: When your system participates in a network, *USE authority may provide more authority than you expect. For example, with FTP, you can make a copy of a file to another system (including a PC) if you have *USE authority to the file.