Tweet
My primary area of responsibility is the database, and I am not familiar with AS/400 security. I know the AS/400 has security within the database because it has a GRANT statement. Since I have been working with the system, I haven't had to grant any access to users or programs. This must be because of the authority of the *PGMR group. What special authorities should be given to the *PGMR group, if any.
-
-
SQL database security
On Saturday, May 01, 1999, 11:58 AM, R.O. Weber wrote: My primary area of responsibility is the database, and I am not familiar with AS/400 security. I know the AS/400 has security within the database because it has a GRANT statement. Since I have been working with the system, I haven't had to grant any access to users or programs. This must be because of the authority of the *PGMR group. What special authorities should be given to the *PGMR group, if any.
You damn sure don't want *ALOBJ nor *SECADM ..........Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080
-
SQL database security
On Saturday, May 01, 1999, 11:58 AM, R.O. Weber wrote: My primary area of responsibility is the database, and I am not familiar with AS/400 security. I know the AS/400 has security within the database because it has a GRANT statement. Since I have been working with the system, I haven't had to grant any access to users or programs. This must be because of the authority of the *PGMR group. What special authorities should be given to the *PGMR group, if any. You do not say what security level the system is running at, but it should be at minimum level 30. On the user profiles, set SPCAUT to *USRCLS to get IBMs recommended authorities. HTH COLOR="#800080"> Phillip E. RodgersSRC="http://www.mca.com/music/images/anims/homeanim3.gif" WIDTH=233 HEIGHT=141>
Comment
-
SQL database security
How about securing the update/delete function w/in sql? We've had a rather large screwup. Is there any way to restrict the update/delete function w/in sql?Comment
Comment