Re: Authority annoyances, continued...

Richard

I would submit that this is not a good idea.

As someone else indirectly points out, this gives anyone with authority to
the submit job command AND authority to the job description the de-facto
ability to run jobs as the user profile embedded in the job description if
the machine is at security level 30 if I recall correctly.

(How many shops are still at 30 ? Is this a good poll subject ? Would a
poll like this be representative ?)

If you are interested and are at security level 30, try an experiment I
seem to remember working for me: creating a job description that is
accessible to *public use and has a QSECOFR class profile as the user.
Submit a job to change the security officers password....

Hope this helps

Regards
Evan Harris

Create a job description that will be used to submit the back up job to
>batch. Ensure that the USER parameter of the job description specifies the
>new user (eg. USER(BACKUPUSER)). Any job submited to batch using this job
>description will then run under the new user profile.
>
>Create a CL program to submit the backup job and add it to the standard
>daily procedures. (eg. Job scheduler, menu system, whatever)
>
>This will solve the authority problem without getting into any complicated
>programming routines.