RE: BPCS Security Concepts -- BPCS-L

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