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
+---


This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].