× 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: Clarification of Security type S
  • From: MacWheel99@xxxxxxx
  • Date: Thu, 13 Jan 2000 16:06:09 EST

> Subj:  Clarification of Security type S
>  From:    Robert.M.Mack@sgcna.com (Mack, Robert M.)
>  
>  I want to make sure I understand this correctly. 
>  The following is the way I
>  understand how security access works from the greatest to the most
>  restrictive  based on Marc's and everyone else's information.

You might also look at the IBM statistics on how recently passwords have been 
changed for such all important "sign-ons" as the SSA owner of all of BPCS 
files, and anyone who is an AS/400 security administrator, has command line 
access, or is a BPCS security officer.  We have users whose passwords have 
not been changed in DECADES.

>  Security Type "S" means the all powerful category.  Any user with this
>  can get to all menus/products/programs.  In effect, they can do it all.

Yes AND they can also change anyone else's BPCS security & their own to 
include COMMAND LINE ACCCESS, which will only work right for them if IBM 
security has been setup to authorize this, and if they are on client access 
there are other considerations.  

And there is no audit trail on stuff changed, then changed back, other than 
easily deleted print-out, so for instance someone could change how 
transaction effects work, enter some improper activity, then change the 
transaction effects back again to how they were originally, but you do not 
need Security "S" to do this, just who can do which transactions.

>  A user with Sec Type "U" and PROD ALL "1" can get to all Products/Programs
>  with the exception of a few SYS programs.
>  
>  A user with Sec Type "U" and Prod All "0" can only get to applications if
>  they are "1" for that application or to specific programs if they are "1".
>  I know that you can give a user access to a product/application and then
>  explicitly exclude a program by making the users authority to that program 
a
>  "0".  And vice versa.

Yes

>  So.... When I find a user with Sec type "S" and Prod All "1" that would be
>  redundant. 
>  
>  Why would someone set up a user with Sec Type "S", Prod ALL "0", Exclude
>  them from an application ACP "0" and explicitly exclude them from 4 
programs
>  ACP9xx "0" and then give them INV "1" and INV300 "1".  Looks to me like
>  someone wasn't paying attention or doesn't understand how the security
>  works.

Yes, this is a key area in which people who manage security need to be given 
a clear explanation of how it works, with periodic review for those who do 
not work with it very often.

We have had some fluctuation in individuals who are / are not / BPCS security 
officers - we want to keep the REST of their authorities pretty close to what 
they are allowed to do if we should take them off of "S" status.

We have also conducted some security tests ... the documentation says that if 
you setup security a certain way, then the security will work a certain way 
... let's deliberately setup some "test people sign-ons" with screwed up 
security & run some tests to verify that the documentation is correct.

>  How does Transaction Effect figure into all this?

Ask your BPCS Security officer to get you a screen print of ALL the security 
settings, which includes Transaction Effects that people are authorized to do 
& Facility & other filters.  We have most of our users setup with asterisk 
which means "wild card" they can do any type of transaction.  

You might also like to create a Query of what is in the ITE file, which 
stores Transaction Effects ... e.g. all what transaction types impact what 
areas, such as General Ledger codes.  We have an end-month query that totals 
numbers of transactions by user by transaction type from ITH history, so we 
can review whether some transaction types are being used inappropriately.

You might also find rules in SYS800 to be of interest.

>  I apologize for the trouble, but I haven't gotten a straight answer from my
>  programming department and my RPG skills are non-existent.

Your programming department might not even know ... what you need to be doing 
is looking at the documentation, which we have talked about in another 
thread, and you can also ask me about off-line from BPCS_L.  I am an RPG/400 
programmer & when I have had occasion to look at SSA Security, CL skills were 
more important than RPG.

There are several on-line documents that address aspects of security ...ask 
your programming department to show you how to SCAN them (using the FIND 
command) to locate words of interest to you like "security" then how to print 
out just the section (using LP) with the text that interests you, instead of 
the whole door stop document.

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.
Stiff in opinions, always in the wrong.
When you want it cheap - you get what you paid for.
When in doubt, read the manual, assuming you can find the right one.
+---
| 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-Ups:

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.