|
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 mailing list archive is Copyright 1997-2025 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.