Re: Listing of objects and their owners

We would probably never mesh all the divisions into one group.  They have
separate shareholders and stuff.  Would you want your companies data in the
same files as another's if you were using a timeshare service?  Everything
is doable - it's just that the costs simply outweigh the benefits of a
single database. Queries, timing period ends, security, backups, etc all
become a pain.  As it is now it takes only about 10 minutes to backup a
division - so we don't use save-while-active.  As one big cluster we would
have to - or keep everyone out for hours.  And then there is that Ireland
division and try to time their backup!

We use the multiple owners for two reasons:  One, keeping people in the
divisions that they should be in.  Two, a user can only own so many
objects.  We actually exceeded the number of objects owned by SSA.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    MacWheel99@aol.com
                    Sent by:                  To:     midrange-l@midrange.com
                    midrange-l-admin@mi       cc:
                    drange.com                Fax to:
                                              Subject:     Re: Listing of 
objects and their owners

                    01/16/2002 11:06 AM
                    Please respond to
                    midrange-l






> 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)