× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

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-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.