RE: Job submitted in Qstrup

You can get entirely around the issues of programs with adopted QPGMR
authority vs. granting *USE authority to QPGMR by setting up an autostart
job entry in one of your subsystems.  I have a subsystem named ASYNC for
this kind of stuff, but you can just as easily use your batch subsystem or
probably even QSYSWRK.  It's better to use your own subsystems so such
things don't get wiped out during upgrades.

Define an autostart job entry with the job name and a job description name.
Create the job description using GAL as the user profile and specify a job
queue, and specify your program call (not submit) as the request data.  User
GAL needs to have authority to the job description.

As your subsystems start via QSTRUP the autostart job will automatically be
started.  I believe that the subsystems autostart jobs are started under the
authority of user QSYS regardless of whether QSTRUP is run under QPGMR.
QSYS should have the authority to invoke a job for user GAL.  The autostart
job entry insulates the job and user from QPGMR.

I use this technique to start daemon jobs in subsystem ASYNC and to launch
one-shot system startup jobs into QBATCH.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>



-----Original Message-----
From: Mark S. Waterbury [mailto:mark.s.waterbury@xxxxxxx]
Sent: Monday, November 03, 2003 5:21 PM
To: Midrange Systems Technical Discussion
Subject: Re: Job submitted in Qstrup


Hi, John:

Thanks for the detailed reply.

I do not advocate using QPGMR as a group profile, but I find that many
AS/400 shops do use it as a "programmer" group profile (right or wrong)...
So, I was just pointing out some of the "caveats" of doing it that way...
;-)

I agree with your proposed solution (explained in detail below).

Cheers,

Mark

----- Original Message -----
> From: "John Earl" <john.earl@xxxxxxxxxxxxxxxxxx>
> To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
> Sent: Monday, November 03, 2003 4:00 PM
> Subject: RE: Job submitted in Qstrup
>

> > If you give QPGMR *USE authority to the GAL profile,  then
> > any user who belongs to the group QPGMR will also have authority
> > to submit jobs "as" GAL...
>
> True, and I like your adopted authority approach better
> (though I would create a profile other than QSECOFR to
> adopt).  But this reply begs the question, "Why would you
> ever make QPGMR (or any other IBM profile) a group profile?"
>
> There are just so many ways to assume QPGMR's identity, if
> it is a group profile, or worse yet if it is a production
> object owning profile, there are likely a number of ways
> that people can compromise your system by acquiring QPGMR's
> rights.
>
> And the reverse is true as well, If there are a number of
> people who belong to the QPGMR group, then these folks can
> get into some of the internal IBM routines (Like QSTRUP, for
> example) and mess things up in the OS.  Either way, I think
> it's a bad idea to mix IBM profiles with your applications.
>
> So, to give a more appropriate answer to the original
> question, I would create a tiny CL program that performed
> the two SBMJOB's, and compile that program to run under
> GAL's authority.  Then give QPGMR just *USE authority to the
> program.
>
> That's secure, simple, and minimizes QPGMR's reach into your
> application.
>
> But that's JMHO,  :)
>
> jte
>