|
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)
As an Amazon Associate we earn from qualifying purchases.
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.