Re: "Service Aids Authority" ??? -- MIDRANGE-L

The problem is that you could grant a user 'Service aid authority' by doing a 
CHGUSRPRF and giving them the special authority *SERVICE and they could still 
not run STRSST because they do not have authority to the command STRSST.  The 
problem is that IBM chose to use command authority to limit stuff.  Why did 
they not check the user profile who executed the STRSST command to see if they 
have *SERVICE authority?  Did they do this because it would be easier for us to 
mess with who can run what commands?  Is this IBM's recommendation - just do a 
GRTOBJAUT on the commands?

Why do some programmers insist on *ALLOBJ?
If someone's spool files go into a secured output queue then even someone with 
*SPLCTL cannot look at them.  A secured output queue is one with the 'Operator 
Controlled' set to *NO and QSPL set to *CHANGE and *PUBLIC set to *EXCLUDE.
They cannot look at the joblog of any active job running under someone else 
with *ALLOBJ authority.  For example.  We set up a user profile call MASTER 
with *ALLOBJ and the rest of the authorities except *SECADM.  This profile runs 
certain never ending jobs.  You cannot look at the joblog of any active jobs 
running under this user profile unless you have *ALLOBJ authority yourself.  
*JOBCTL authority won't cut it for you.  This is something IBM changed a few 
releases back.
Sometimes you'll have two group profiles on your system.  Perhaps one for 
manufacturing and one for payroll.  If someone is designing an interface 
between the two, labor hours reporting for example, they'll object to the hoops 
they'll have to jump through for testing and implementation.
My sarcasm dealing with a pet peeve.  Programmers don't care about how 
something will work for the users.  If it works for them then shouldn't it work 
for the users?  We had an accounting system that we implemented that we had 
'tested throughly'.  However when the users started using it and they did not 
have *ALLOBJ it blew all to hell.  For example lazy programmer A didn't want to 
use his manufacturing user profile so now all the stuff he created for 
manufacturing is owned by the payroll group profile.  It works for him, he has 
*ALLOBJ.  Project is complete and he saved 30 seconds by not having to sign off 
and on again.  Or open up a new session.





mshaw@ncal.verio.com on 08/24/98 03:41:32 PM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     MIDRANGE-L@midrange.com@Internet
cc:      
Subject:        Re: "Service Aids Authority" ???

Don,

I would take that to mean *SERVICE authority in: Can I start the SST stuff?

Mike
-----Original Message-----
From: Don <dr2@access.digex.net>
To: midrange-l@midrange.com <midrange-l@midrange.com>
Date: Monday, August 24, 1998 11:05 AM
Subject: "Service Aids Authority" ???


>
>
>
>
>Greetings,
>
>Section 2A of CUM C8195420 refers to a USRPRF with "service aids
>authority" ....what the heck is this?  How, if at all, does this vary from
>the *SERVICE special authority in the usrprf?
>
>Tks...
>Don in DC
>
>+---
>| 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 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
+---