Re: BPCS authority SFC routing inquiry

[MacWheel99@xxxxxxx]

from Al Macintyre

> Subj:  BPCS authority
>  From:    oludare@ix.netcom.com (oludare)
>  CC:  PSmolens@ci.manassas.va.us (Peter Smolens)

We have resolved this challenge on BPCS 405 CD by creating a Query/400 over 
the data we want people to have access to, in a display or inquiry or report 
format without updating anything, then embedded that query within a CL that 
has a name like SFCRTG, then in the security area we control who can access 
SFC stuff, including this simple variant.  

We have a naming convention in which we use the SSA prefixes of ORD SFC INV & 
so forth, but instead of a 3 digit number, the next stuff has some 
alphabetical for our modifications & queries, so that the security rules 
apply to our additions.

We actually have several variants of this based on the kinds of common needs 
that end users, engineers, production supervisors etc. might need to look at, 
so that they only need to specify the item facility combination ranges & not 
have to futz with whether or not they need to see the additional description 
or which operations.

In Boris's example of
RUNQRY     QRY(FRTVIEW) RCDSLT(*YES)
the RCDSLT parameter controls whether the end user can change selection 
criteria at time of running the query ... we have some cases where we want 
end user to be able to run something & not change criteria, in which case we 
have (*NO)  When they are sending the query to a report, we also often have a 
printer-override statement so that it is obvious on spool which query is 
which.

I guess if you wanted to be more sophisticated you could copy the code to 
something like SFCLOOK & within the program deactivate the ability to use 
certain commands.

To avoid eating up the 60 fields of BPCS security, we have families of 
general access like BOMINQ & SYSMSG in which anyone who can run any one job 
in the family can run all jobs that have that prefix.

SFC100 is not the only dangerous job that you might want to consider limiting 
access to, for those individuals who can do anything else in SFC ... we have 
limited some fiscal end-of-month & end-of-year purge type jobs to people who 
only do that stuff when it is supposed to be done, to avoid someone who does 
tons of SFC responsibilities from accidentally taking a wrong option from a 
menu.

We have tried to put EVERYTHING that end users need to do on the user menus 
so that they rarely need to be using the vanilla menus.
  
>  Guys: (I'm on  6.00.02 Jan Cum)
>  
>  How can I give user access to a module (e.g. SFC) and limit user access in
>  SFC100 to DISPLAY or INQUIRY only?.  I want the user to have access to
>  everything under SFC but limit SFC100 access to inquiry only or no access 
to
>  SFC but have DISPLAY or INQUIRY access to SFC100.  All suggestions that 
will
>  work is welcome.  I have tried different combinations but none work.
>  
>  Thanks for your help in advance.
>  
>  Oludare

From:   bpcsguru@yahoo.com (Boris Goldenberg)

SFC100 is the Routing Maintenance program.  If all you want for your user is 
to
allow them to inquire on routings, why not do the following:

1. create a Query over FRT file, call it FRTVIEW
2. create CL which will contain the following statement:

PGM
RUNQRY     QRY(FRTVIEW) RCDSLT(*YES)
ENDPGM

3. Put the new program on the menu and give user access to this program

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