Have you ever had the need to submit a job to batch? Of course you have! But have you wanted to submit it as though you were the security officer? Again, I bet you have. When a job is running in batch mode, its authority to access objects is based upon whether or not the user who submitted the job has the necessary authority. Take the following example:

My Data Processing controller wants to incorporate one of these neat ResourceLibrary utilities to optimize the system as opposed to chunking out more money for additional DASD. The utility he is reading about will reorganize files, optimize programs, etc., provided that the user who submits the job to batch is authorized to the objects being optimized. He compiles the objects, picks a Sunday to execute them, and Monday morning (drum roll, please) discovers that this process bought him a whopping 1.3298 MB of DASD. At this point he groans, moans and requisitions additional DASD.

But wait! I, the programmer, have also been using the ResourceLibrary, and happen to know that there is a solution. I have discovered that even though you are not authorized to do the cleanup, you may submit the job as though you were. But would this breach security? No, not if implemented properly.

See below:

 SBMJOB CMD(CALL PGM(OPTIMIZE)) + JOB(OPTIMIZE) USER(OPTIMIZE) 

This command will do the job! Notice that the USER parameter contains OPTIMIZE. This is the name of a user profile, created with a user class of *SECOFR (security officer) and a password of *NONE, which is to say that it cannot be used to initiate an interactive job. Remember to revoke all public authority to user profile OPTIMIZE and grant the DP controller *USE authority to the same. Here's how:

 GRTOBJAUT OBJ(OPTIMIZE) + OBJTYPE(*USRPRF) USER(*PUBLIC) + AUT(*EXCLUDE) GRTOBJAUT OBJ(OPTIMIZE) + OBJTYPE(*USRPRF) USER(...) + AUT(*USE) 

Now for the best part: once this was done, we chose another Sunday to try it again. Guess what. We went from 87 percent to 76 percent of utilized DASD. Thanks ResourceLibrary!