|
Martha: As I read yesterday, and tested successfully today on Full Client/Server, you may limit accesses within a program by using SYS603 - Security Group Maintenance. Please read the post from yesterday, it was very insightful. Cheers. > -----Original Message----- > From: uucp@Uucp1.mcs.net [mailto:uucp@Uucp1.mcs.net]On Behalf Of Martha > Bayer > Sent: Tuesday, July 20, 1999 6:37 AM > To: 'BPCS-L@midrange.com' > Subject: RE: BPCS Security Concepts > > > Based on the responses so far, I think the problems I have with update vs. > inquiry security must be unique due to the fact that we are client/server. > We are able to limit access by program with no problem. So we don't allow > people access to month-end programs, and we can limit their access to > programs that are inquiry only, like INV300 and CST300 without > any problem. > Our problem happens on things like the vendor master, customer master, or > item master. We can't give people access to just display the information. > There is a file command in the menu bar at the top of the window > that allows > them to choose between create, copy, revise, delete, and display > functions. > We cannot limit which function they choose. > > > Martha Bayer > Badger Mining Corporation > 920-361-2388 > mbayer@badgerminingcorp.com > > > -----Original Message----- > From: MacWheel99@aol.com [SMTP:MacWheel99@aol.com] > Sent: Monday, July 19, 1999 3:21 PM > To: BPCS-L@midrange.com > Subject: Re: BPCS Security Concepts > > > Subj: RE: BPCS Security - More information > > From: mbayer@badgerminingcorp.com (Martha Bayer) > > > We're on 6.0.02 CS AS/400. We were told by SSA consultants that > update vs. > > inquiry security may be available in version 7.0. I wonder how > many others > > think this is an important feature? Has any one found a way > around it? > > Update vs. Inquiry security is available in version 405 CD - did it > go away > in V6 or am I not understanding something? > > My understanding of this is that INQUIRY is where people can view > data via > INV300 SFC350 CST300 etc. while update means people can run jobs > that update > the BPCS data base such as ORD500 JIT600 etc. > > One headache with 405 CD security is the group security is an all or > nothing > everyone same rules, so to offer different IBM rules to some user > sub-groups, > we have to risk a performance hit by having secondary user groups. > > Another headache is that we have users who have had to be granted > command > line authority, and been shown how to do some support tunctions for > narrow > reasons, then used their know-how & access in ways I consider quite > dangerous, like DFU vs. BPCS file contents. > > > Subj: Re: BPCS Security - More information > > From: mkamara@krupsusa.com > > > > We're on 6.0.04 MM, AS/400 720 V4R3 and new to BPCS. We are a > > wholesale/distribution company in the US. I have set up basic > security > > given access to the modules based on departments. I will like to > have a > > tighter control without affecting performance where some users > will update > > capabilities and others have inquiry only. > > Check BPCS Documentation - there is an outline of how the security > works. > > Whatever consultant helped you get setup might have additional > reccommendations on this topic. Take a look at how work station > defaults are > changed & if you want end users doing that. Who should be making > changes to > BPCS User Menus? Does every module have a manager who decides who > all should > have what kind of access to which areas? Usually the department > head says > anyone can inquire into our stuff but only people in our department > ought to > be changing the contents & here is a list of users in our > department. Some > data is more sensitive than others, such as profit margins. Do you > want or > need people to be able to manipulate / view the contents of other > people's > reports? > > Check BPCS_L archives for remarks I made on BPCS Security several > months ago. > > The things that were the major conceptual stumbling blocks for my > project > team personnel regarding comprehending security issues. > > 1. The SFC600 Module List works on basis of OPPOSITES. > > Some people we have coded NO to all modules, then down below listed > just the > programs we want them to be able to run, such as some inquiries & > pop-up > menus. > > These people are coded N in the list of modules, so that the > programs listed > below are what are YES for them. > > Some people we want them to be able to do just about anything in a > particular > module, such as SFC & JIT, but we say NO to end-of-month stuff like > SFC905 & > JIT900. > > Those folks are coded Y for the overall modules - so that the stuff > down > below on that module are the NO exceptions we do not want them to > get into > for whatever reason. > > 2. Anyone can make a mistake & take a wrong menu option & get into > trouble - > for example we had some people taking some end-of-month options & > trying to > exit & in their frustration, causing unwanted updates. > > As the block of opposites grows, and as people's security needs to > be > changed, we want to keep the picture easy to read, so we organize > the stuff > generally A to Z left to right & 1 to 10 top to bottom. > > 3. A query can have any name, but to run it from BPCS Menu, it needs > to be > named logically within the BPCS naming conventions, avoid risk of > conflict > with future PTF, and fit within the security rules. Our > modifications & > queries use the 3 letter prefix of ORD INV etc. but by the 6th > character have > shifted alphabetical. We have some power users who create queries, > create > the CL to run them, and put the CL on BPCS User Menus. This > capability > requires command line authority, right SYS stuff for the menus, IBM > Programmer Authority to compile the CL, and support to cross library > lists > when copying a query between 2 different environments. > > 4. We can muck with additional rules on how BPCS Security functions, > and > change IBM commands, but let's not add to the complexity of Security > if we do > not want to make this a full time job. > > On IBM Security - you might want to make the first place people go = > the BPCS > Menu for their environment, then the second place where they go, > when they F3 > out of BPCS to be *SIGNOFF, so only people who know how with either > command > line authority, or other stuff, can get into OS/400 menus. > > We are in constant struggle of WHY DOES THIS PERSON NEED COMMAND > LINE > AUTHORITY? The main reason is they were taught how to do something > by > someone who did not think computer security was especially > important, and are > now more comfortable navigating via that method than the vanilla > menus. > > We have created CL for BPCS User Menu to do many of the things that > people > said were the reasons why they needed access to IBM Menus. > > I hope this helps > > Al Macintyre > +--- > | 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 > +--- > +--- | 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 +---
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.