Re: AS/400 USER PROFILE

I've a similar problem problem to Gilberts', apart from the fact that we don't
use group profiles.  So all my users are set up as follows

 SPCAUT               *NONE
 GRPPRF               *NONE
 OWNER                *USRPRF
GRPAUT               *NONE
GRPAUTTYP      *PRIVATE

LIMIT CAPABILITIES is set to *NO as we use a mixture of JBA Explorer and Green
Screens.

Yet members of staff are still capable of changing jobqs.

regards

Jon








"Jeff_Klipa/Harvard"@harvardind.com on 14/08/2001 01:48:56 PM

Please respond to JBAUSERS-L@midrange.com
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      JBAUSERS-L@midrange.com                             
                                                              
 cc:      (bcc: Jon Wadey/MSTNOTES)                           
                                                              
                                                              
                                                              
 Subject: Re: AS/400 USER PROFILE                             
                                                              








When I worked for JBA one of the jobs I did there was to Install the Software on
the New Customer's AS/400.

When I first started the unwritten rule was that all users had to have a GRPPRF
= QPGMR.  The reason I was told was that every object in JBA was owned by QPGMR
when it was shipped and this would avoid any authority problems with any user
using any object.  I used to tell this to the customer when I loaded their
system.

That also meant that any object created by any user would be owned by QPGMR.
Many customers complained about security problems and eventually Software
Products Ltd. in Studley, England agreed and began compiling their objects with
Adopt Owner Authority so that it did not matter who used the objects there would
not be any authority issues...

Since that time (v3.5 I think) it became unnecessary to have GRPPRF = QPGMR...
In light of that we do not have any of our users intentionally setup with QPGMR
as their GRPPRF...  *NONE is sufficient...  It also helps us keep track of the
true owner of any objects created on the system...

This may alleviate your problem with users changing their jobs...  Suggest you
try a sample user profile to test...

A note about "LIMIT CAPABILITIES = *YES"...  You cannot use this if you are
using the GUI Explorer package...

Otherwise, if you are using a Green Screen you can set them up just as you
described :
  (With two Exceptions  GROUP PROFILE  *NONE  and   OWNER  *USRPRF)
          GRPAUT              *NONE
          USER CLASS          *USER
          LIMIT CAPABILITIES  *YES
          SPECIAL AUTHORITY   *NONE

This allows QPGMR to retain its ability to function as needed (background
processing jobs especially...!!!), and yet restrict the users access to the
command line...  Also, set the Command line restriction in their JBA Profile if
you really want to tighten down their access...

This is a complex issue and you should do lots of testing to see what your
changes really do accomplish.

Let me know how it turns out for you...

Jeff Klipa
Harvard Industries, Inc.
Manager, System Applications & Development
Farmington Hills, Michigan, USA
248-932-8106








GManoovaloo@ibl.intnet.mu on 08/14/2001 06:14:10 AM

Please respond to JBAUSERS-L@midrange.com



  To:          JBAUSERS-L@midrange.com

  cc:          (bcc: Jeff Klipa/Harvard)



  Subject      AS/400 USER PROFILE
  :







Hi,
Our understanding is that any S21 user should be  setup with , amongst
other parameters :

          GROUP PROFILE  QPGMR
          OWNER          *GRPPRF
          *GRPAUT        *NONE

We also make sure that :

          USER CLASS          *USER
          LIMIT CAPABILITIES  *YES
          SPECIAL AUTHORITY   *NONE

However, we noted  that some smart users could change their job  (run
priority for example ). We tried to
solve this problem by removing  *JOBCTL from user  QPGMR . This resulted in
so many problems that
we had to backpedal.
Has anybody encountered such a problem ? I would be happy to know how this
was tackled .
Thank you for any suggestion
Gilbert


+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---



+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---



+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---