× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: BPCS Security Concepts
  • From: MacWheel99@xxxxxxx
  • Date: Mon, 19 Jul 1999 16:21:25 EDT

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.