Re: Securing job queues

Robert,

Not only can't you change JobQ attributes after they've been created, you can't 
even
see them.  :^(     You can see an change OutQ properties, it couldn't have been 
too
much work to extend this ability to JobQ's

You'll have to delete and recreate the JobQ to change these parameters.  That
shouldn't be a problem, just pick a time when the subsystem is idle.  Then end 
the
subsystem and recreate the JobQ.

jte

robert.lilley@springs.com wrote:

>      Regarding the suggestion to lockdown QBATCH - exactly how do you make
>      the suggested change?  AUTCHK(*DTAAUT) and AUT(*EXCLUDE) can be
>      specified on the CRTJOBQ command, but how do you apply them as a
>      change?
>
> ______________________________ Reply Separator 
>_________________________________
> Subject: RE: Securing job queues
> Author:  MIDRANGE-L@midrange.com ("Steve Glanstein" <mic@aloha.com>) at 
>NSPRINGS
> Date:    7/1/99 11:42 PM
>
>        Hello all:
>
>        Several Solutions:
>
>             a.   Management: Nail them for unauthorized access based upon a
>        written
>        policy!
>             b.   Add a routing entry for QBATCH that checks where the job came
>        from.
>                  If the job was not from the "chosen", cancel it!
>             c.   Add a routing entry that makes the renegade job run at the
>        worst
>        priority!
>             d.   Use this as an excuse to reinstate LMTCPB(*YES) and lock 
>things
>        down a
>        bit.
>             e.   Lockdown QBATCH so they can't move the job into it
>                  AUTCHK(*DTAAUT) AUT(*EXCLUDE)
>
>        Steve Glanstein
>        mic@aloha.com
>
>        > Subject:  Securing JobQs
>
>        > We have several jobqs on the system. Generally, most departments use
>        > QBATCH.
>        > Payroll uses PAYROLL, and there are a few special purpose queues.
>        >
>        > The problem is that payroll gets impatient, and they move jobs from
>        PAYROLL
>        > to QBATCH. So... I want to restrict payroll personnel to the PAYROLL
>        jobq.
>        >
>        > Are using authorization lists the best way of handling this? (IE, put
>        an
>        > auth list on QBATCH for all users EXCEPT payroll, then PUBLIC 
>*EXCLUDE
>        the
>        > jobq) Obviously, I'd also restrict the PAYROLL jobq to payroll 
>people,
>        etc
>        > etc.
>        >
>        > Will this wreak havoc on IBM-supplied profiles?
>        >
>        > Thanks!
>        >
>        > - --
>        > Loyd Goodbar
>        > Programmer/Analyst
>        > Borg-Warner Automotive, AFS, Water Valley
>        >
>        >
>        +---
>        | This is the Midrange System Mailing List!
>        | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>        | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>        | To unsubscribe from this list send email to
>        MIDRANGE-L-UNSUB@midrange.com.
>        | Questions should be directed to the list owner/operator:
>        david@midrange.com
>        +---
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---



--
John Earl                                              johnearl@toolnet.com
PowerTech Toolworks                         206-575-0711
PowerLock Network Security              www.400security.com
The 400 School                                    www.400school.com
--



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---