Re: Listing of objects and their owners -- MIDRANGE-L

Now I understand. Thanks for your time in giving such a detailed explanation.

>>> <MacWheel99@aol.com> 01/16/02 11:06AM >>>
> why do you need for the owner of the library to be the owner of the objects
> within that library?

Alan

In the BPCS reality, all the objects are the property of the SSA owner of the
environment.  All users of that environment are members of the group SSA.
All objects created by members of the group belong to the group.  All users
in the group may access any of the objects that belong to the group.  There
is some additional security within BPCS to control what programs people may
use to do what with the objects.

In this reality, if an object got created that did not belong to the group,
then members of the group might not be able to access it.  Software would
bomb.

Now what ROB's company is doing is outside of the BPCS reccommended reality.

Under SSA rules, what you supposed to do is either consolidate all your
divisions into one humongous data base, using company codes & facility codes
& etc. to differentiate which division it is, which does impose some hassles
managing the security area when some people are authorized to some divisions
& not to others ... this is the approach my company took because people were
whining about having to enter vendors items etc. once for each division, when
same vendors etc. across many divisions.

A downside of this is that we have people who work in one city who are
authorized to be doing a wide range of transactions to the data in that city,
and allowed to look at but not change data in another city ... for example
... we are running low on raw-materials-X because of a rush order on customer
part-Y ... do you have any we can borrow until the associated rush order on
the raw materials gets here?

But with BPCS security, you cannot do that ... people are either authorized
to be doing a wide range of transactions to the data in any city, or they are
inquiry users, so under many methods of BPCS implementation, you have to
trust your people, you cannot rely exclusively on security to impose company
rules.  Of course we can also run histories to see who has been doing what
kinds of transactions in which divisions, so that after the fact we see if
anyone breaking the rules.

The other SSA approach is to have different environments & different sign ons
for each data base.  This is what my company used to have to do when we were
on BPCS/36 which did not support separation of MRP by division.

It may well be that what ROB's company needs to be doing is shopping around
for a replacement for BPCS that is a better mesh for the size of the
corporation.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated
http://www.globalwiretechnologies.com = new name same quality wire
engineering company: fax # 812-424-6838
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.