× 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.



Security type S (BPCS Security Officer) can get into anything on any BPCS 
Menu, irrespective of the other settings on the standard BPCS security screen.

I am deliberately saying "standard security" because there is a place you can 
go to change the rules & say for this or that program you REALLY need 
authority to this or that collection of modules.  Some of this is setup but 
not working right in BPCS 405 CD so I suggest you check the on-line 
documentation on menu DOC (for access you need SYS authority or security type 
S) & review the documents on general BPCS logic, SYS functions, and Security 
... it is a bit vague in places, probably for security reasons.

We do not have it, but I suspect the BPCS Reference Manual from David Slicker 
would be a better place to go to put the interplay of security files into 
perspective.

When I was the only Security Officer for my employer I was very careful to 
use a different sign-on for Security capabilities (changing security) as I 
used for day to day operations, because the latter is often left signed on 
when I am called away from my work station, but as it has become appropriate 
to extend BPCS Security decision making adjustments to a departmental 
management level & in the hands of power users on a project team, they do not 
see that sort of duties division as a mission critical policy we needed, so 
we now have several BPCS security officers who use one sign-on for everything.

We have both the vanilla menus & user-menus ... we have several queries that 
list what users may access which of the latter, but even if they can get to 
an option on a menu, they cannot run it unless the BPCS security permits it.

One thing security auditors might be sensitive to is whether the people 
creating & implementing additions to the collection are rigorously following 
the module separation ... we have queries in CL on menus that start with ORD 
or INV or SFC or whatever whose contents may be data out of some other module 
that the user might not be authorized to see through vanilla channels.

BPCS 405 may have a different coding system than the version Robert M Mack is 
describing.  Instead of 1s + 0s we have Ys + Ns on the screen, confirmed by 
queries we have written over the file to get at summary pictures of who can 
access what ... like who all is authorized to update what kinds of 
applications.

So in Robert's example
ACP-N means that user is NOT authorized to access ACP programs EXCEPT where 
the program list has opposite exception list ... this also means that the 
user might have a hard time getting to the vanilla ACP menu.

Be sure to check the second screen of authorizations ... even if someone can 
run a particular program, they might not have authority to run all the 
options within it.

When you found the same entry more than once, was it in an area that is under 
the control of users able to enter it twice ... sometimes humans have some 
trouble navigating how this works and make mistakes.

One thing that is easily confused by start-up users of the standard security 
area, is that the list below refers to OPPOSITES.

Generally we might set up someone as INV-Y but not INV900 or INV910 meaning 
access anything in inventory EXCEPT end-of-fiscal.

With respect to financial auditors wanting to know what users can access via 
the menus, I would suggest 
1. Give them a copy of the Logic Manual so they can see the official naming 
conventions, and warn them that in-house modifications may be in violation, 
and that sometimes SSA violates its own rules - this is a general navigation 
guide.
2. Familiarize yourself with how the menus are named, so that you can check 
the source code & see what menus exist, then get a screen print reference of 
each one ... organize them alphabetically by the command used to access them 
such as ACP.
3. Create a query to show who all can access what modules, alphabetically, so 
you can then look at the list of ACP authorized users for example when you 
are looking at the ACP menu screen prints.
4. Review the other ways ACP data can be manipulated such as via Command 
Line, and other possible holes in how AS/400 security has been implemented 
such as through PCs.

Hoping that this has been helpful - if any of the above desirable, in a later 
e-mail we can address which files & fields are keys to what part of the 
security kingdom

Al Macintyre  ©¿©

Y2K is not the end of my universe, but a re-boot of that old chinese curse.
The road to success is always under construction.
Sanity is the playground of the unimaginative.
Stiff in opinions, always in the wrong.
Every software improvement comes with some new challenges.
When in doubt, read the manual.
+---
| 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.