Re: Big Owners (of Objects) -- BPCS-L

Al,
The root cause of your problem(s) seems to stem from environement management
and security settings. It's a complicated topic and one I am well versed in
following two years of managing a development box with 9(ish) BPCS
environments each linked (integrated) to the equivalent environment for a
number of other software packages (several in house, JDE, JBA etc etc).
Keeping library lists and job descriptions in sync and correct etc is a
nightmare and we have some 400,000 objects on the box, the majority of which
are owned by only a small number of profiles. Furthermore, we have applied
our own standards to the security setup in terms of object owner naming
conventions and so forth. Vendors don't like it much but it gets messy
otherwise and if third party software can't operate in a sensible
[structured] fashion on a machine other than one didicated to its own use
then it doesn't say much for the vendor standards. However, I've never heard
that this alone will cause a [significant] performance hit, although masses
of objects will make some difference. Aside, there are a number of factors
which I summise from your message that might. I'll try to clarify:

1. Dozens of users using RUNQRY / WRKQRY / STRSQL (basically anything query
oriented rather than structured with forthought (like BPCS!!!)) will hit the
box. This will be because users will inevitably link files together, or run
queries over single files for which a suitable key does not exist - result
will be temporary on line index building every time the query is run  (like
building a LF into QTEMP over ITH, running the program then ending the job,
only to do it all again)

2. You are correct about BPCS security, it is managed (of a fashion) by the
application and thus you can reduce the number of security lookups performed
by the application by implementing library level security. The secret here
is to remove as many private authorities as possible and set everything to
*PUBLIC *ALL (or *CHANGE, *USE or USER DEF, whatever). I've seen this
approach reduce one box's daily security lookup count from in excess of 6
million to 22,000.

Briefly, do the following.
        Revoke all authoriry from everything from everyone (for a given library)
        Revoke any authorisation list entries again specific objects which
may be hanging about.
        Grant *PUBLIC *ALL (or *USE for program libraries)
        Set the group access against the library (using an AUTL is best as
you can maintain on line)
                e.g.    GROUPA=*USE can only read
                        GROUPB=*ALL can do anything.

Then link your users to the group that they require. - This is simplified (a
lot!) and you MUST prototype and plan carefully any change you plan to
introduce, and have a backout plan cause if it goes belly up you'll not be
popular!

3. I too have considered (and plan to implement) different security settings
(library AUTL's) for different environments, mainly to stop developers
systematically corrupting every data library they can get their hands on and
in the process screwing up important business proto-typing / testing /
training etc. This I am confident is perfectly possible but I plan to keep
the object owner profile the same for all the environments as this does not
control the access granted to a give user profile anyway. (But I'll look up
what you say about > objects on one profile and consider it)

4. You say that users are confused about which query is for which
environment - I'm not surprised! Query will always qualify the library on
which the query is based even if you put *LIBL in the definition (in which
case it will just search for it in *LIBL) and this will be retained in the
query definition, but because like named files have the same level from one
environment to another you can run the query against any data libray by
overriding the qualified library with *LIBL at run time.   Take their
command line away and wrap the query up in a CL as follows (simplistically),
put the CL on a MENU and then it will be common to all environments (as long
as you set the BPCS menu up in all environments, because SSA havn't yet
sussed that menu and security settings should (in almost all cases) also be
common to all environments)

        PGM
        RUNQRY qryname QRYFILE((*LIBL/file1) (*LIBL/file2))
        ENDPGM

Thus, one library with all your queries in it any of which can be run on any
environment. Note the location of the query isn't qualified either and thus
*LIBL applies.

5. You say 99% of your stuff is on library lists - I assume what you mean by
this is that 99% of your programs etc find the object (program, files,
whatever) that it is looking for by searching the library list of the job in
question - This is how it should be as is what enables you to maintain
multiple environments on one box (it's the same thing as your query library,
if they all use *LIBL, then they'll all run regardless of which environment
you are in). Think about life without LIBL's and I think you'll agree!
However, it sounds like you may have a lot of small libraries towards to top
of your LIBL, and this will certainly make some difference. Once a BMR is
proven (and signed to that effect by the business in blood!) merge the
objects into a 'base BMR' library, more commonly referred to by SSA as
BPCSUSR I believe. This should help you simplify things. Since then we now
use Thenon SEE/Change change management to apply BMR's (and mods, add ons
etc), the beauty being that we can revoke if need be also.

6. Users own objects in BPCS if they sign onto a device name which has never
beed used before and their profile is defined to own the object (as apose to
their primary group). Deleting them will do no harm (assuming your deleting
the profile anyway). Worst case is that one user (device) will need to reset
their desired OUTQ. If they are annoying you (they do me!), change the
ownership / security template to that of your other objects. Personally I
find setting a users owner to *USRPRF better that *GRPPRF as I then stand
some chance of seeing / cleaning up all the crap left on the system by less
than tidy IT people - contractors and permies alike (of which I am one of
the former before anyone takes offence)!!!

Hope the above helps point you in the right direction.
Paul


At 13:22 12/05/99 EDT, you wrote:
>from Al Macintyre
>
>IBM class on Adv Sys Op taught me that when a user group owns excessive 
>volume of objects, this leads to a performance hit.  What's excessive and 
>what can we do about it without violating BPCS rules?  There's a report from 
>GO DISKTASKS on object owner distribution.
>
>SSA owns 36,300 objects
>
>This is the BPCS user group - any object created by any BPCS user should 
>belong to the group & any user should be able to access any object in the 
>group.  BPCS security controls the actual running of BPCS software, but we 
>have granted widespread command line authority, such as to RUNQRY that since 
>made it into CL but the end departments prefer RUNQRY to options from BPCS 
>user menus.  I can't see justifying lowering security in the name of 
>performance.  
>
>However, I tentatively plan to put secondary environments in different 
>groups.  Since all environments share the same BMR libraries, I"ll leave them 
>with SSA & make the secondary environments users secondary members of SSA 
>group so as to access the BMR libraries, which may be a performance hit, 
>offset by improving the production environment performance, by significantly 
>lowering the SSA object ownership size.  Is that a smart plan?
>
>If a secondary group owned the libraries that are common to all environments, 
>such as our modifications & library of queries (whose contents I also plan to 
>split into multiple libraries due to user confusion over which are for which 
>environments), then this would mean we would not have the performance hit due 
>to such a humongous volume of objects in one group, but there is another 
>performance hit due to checking security for multiple user groups.  99% of 
>our stuff is library list, not qualified.  Am I asking for more trouble than 
>this is worth?
>
>I am aware that one of the BPCS vendors has a product to analyse BPCS files 
>needed for applications that we are not using, for the purpose of removing 
>them from on-line.  I figure that more than half our BPCS objects fall into 
>that category, but how much space do thousands of empty files occupy?.
>
>QSECOFR owns 29,000 objects
>
>This is a combination of IBM objects and MIS add-ons.  I'm tempted to start 
>two dummy disabled group profiles to own the MIS objects, used in software 
>development & general tools, not end user library lists.
>a) those I expect we'll need for all time.
>b) conversion tools which hopefully will go away some day.
>This will reduce the load to what IBM thinks QSECOFR needs to own.
>
>3rd place owner is 200 objects
>
>Surprise was that some individual members of SSA group should own only their 
>*MSGQ but I found some of them owning
>
>work station *DTAARA
>remembered keys *USRSPC
>QDOC *FLR
>
>So, are our numbers of objects owned by one profile typical or problematic?
>
>Al
>+---
>| This is the BPCS Users Mailing List!
>| To submit a new message, send your mail to BPCS-L@midrange.com.
>| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
>| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner: dasmussen@aol.com
>+---
>
>

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