Our shop runs under V2R1M1. The end users sometimes submit jobs that clear or delete a file. Granting the user the authority to do this requires compiling the CL program adopting authority, by specifying USRPRF(*OWNER) instead of *USER.

An authority problem we've encountered seems to arise from a certain sequence of events. Let's say you've just written a CL program that will be submitted by an end user and clears a file. You compile it with the default of *USER, realize your error and recompile it with a user profile of *OWNER. You print out the compile source listing and confirm the USRPRF parameter is *OWNER. That looks fine so you move the program into production and the user makes the selection to submit the job. The job bombs with the message that the user has no authority to clear the file.

Now you double-check your compile source listing. There it is in black and white: USRPRF(*OWNER). Confused, you display the program with the DSPPGM command and guess what? The user profile is *USER! Of course, the Change Program (CHGPGM) command enables you to modify the user profile for the object, so the problem is correctable, but it is certainly misleading.

Editor's Note: This error happens every time you use the REPLACE(*YES) option in the CRTxxxPGM commands. When you specify REPLACE(*YES), the system recompiles the program but gives the new object the same value it previously had in the USRPRF parameter-not the value you supplied in the CRTxxxPGM command. To avoid this problem, you need to delete the program with the DLTPGM command before recompiling, or run CHGPGM afterwards to fix the problem. This so-called "feature" of the compiler has existed for years.