RE: AS/400 USER PROFILE

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

Yes you can, sometimes!!

All of the users at one of my clients use JBA Explorer and none of them have
access to the green on black screens.  This was done because when JBA was
installed it was decided that as this was a new system it had to look
different to the old system.

By default the initial program in jbasmg.ini on each users PC is set to
CWSINITIAL.  JBA Explorer simply 'screen scrapes' the AS/400 screens and
when the user signs on, Explorer places this program name in the initial
program field on the AS/400 sign on screen and uses this instead of the
initial program set up in the user profile.  This needs LMTCPB(*NO).

If the user will only use JBA Explorer you set LMTCPB(*YES) and set the
initial program in the user profile to CWSINITIAL.  Then, on the users PC,
change the jbasmg.ini file to set the initial program to *NONE.  When the
user signs on the default initial program on the user profile is used.

Therefore if the user has access only to JBA Explorer or only to green
screens then you can set LMTCPB(*YES).  If they switch between the two then
they must have LMTCPB(*NO).

I do not have a JBA Explorer set up in front of me as I prefer green on
black and I may have got some of the file names wrong but if anyone is
interested I can get the details for them.

--
Fred Mitchell
Concise Consulting Ltd.
Newcastle upon Tyne, England
mailto:fred@ccl400.com
http://www.ccl400.com

-----Original Message-----
From: owner-jbausers-l@midrange.com
[mailto:owner-jbausers-l@midrange.com]On Behalf Of
Jeff_Klipa/Harvard@harvardind.com
Sent: 14 August 2001 13:49
To: JBAUSERS-L@midrange.com
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...


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