Manage Learn to apply best practices and optimize your operations.

System values on i: Setting them up and locking i down

AS/400 system values define global, system-wide settings on your platform. Many of these pertain to system security implementation. Take a look at these settings and learn how to lock them down. Many system values are security-related and the operating system designers provided an easy way to review and work with the security settings: The WRKSYSVAL command.

When you implement your company's security policy on System i, you should first review your system values. System values define global, system-wide settings on your System i platform. Many of these pertain to how you want to implement system security. This tip will review how to look at these settings and how to lock them in place so that they cannot be changed.

So many system values are security-related that the designers of the operating system provided an easy way to review and work with security settings. This is by using the "work with system values" (WRKSYSVAL) command with the "system value" (SYSVAL) parameter set to the special value of *SEC. Setting the OUTPUT parameter to *PRINT will produce a listing of the security system values. Alternativelyy, you can run the command with the OUTPUT parameter blank and the system will bring the security system values up for you to review. A similar review function is available from iSeries Access, but the security functions are spread out over several different selection tabs (at least on my version) and you have to go several places to find everything that is available from the single *SEC review ability of the WRKSYSVAL command.

When working with the values interactively, you can review the current setting using option 5 or you can change the value using option 2. The list of system values displayed shows the name of the value and a text description. Often this is not enough information to determine exactly what you're looking at. When I find myself in this situation, I put a 5 next to it, then position the cursor over the current value displayed and press the HELP key. The help text that comes with this command is quite comprehensive and very helpful.

Security changes should be planned for and locked down
Changing any of your security system values should not be done on a whim. Planning and preparation are the watchwords for this process. It is all too easy to shoot yourself in the foot by making a security change in the fly and then losing, for example, the ability to log into your system. All security changes should be researched in advance to determine the exact impact on your system. If you're not sure, do the work to find out rather than trying it out without knowing the impact.

On too many systems, there are too many users with all object (*ALLOBJ) and security administrator (*SECADM) permissions in their user profiles.

Once you have your security system values set along with the other system value (and there are loads of them), it is a good idea to lock them in place. On too many systems, there are too many users with all object (*ALLOBJ) and security administrator (*SECADM) permissions in their user profiles. By locking the system values, you canl prevent casual changes to the system values and preserve the security policies that you've designed and implemented.

To lock your security system values in place, you can use the System Service Tools. To lock the settings, start the systemservice tools from a display session using the start system service tools (STRSST) command. You will need to supply your service tools user ID and password to complete the start of the tools. Once completed, choose option 7 from the menu (work with system security). Then, from the next screen, use option 2 to lock the security system values in place.

Once these are locked in place, you can only unlock them to make changes by going back into the system service tools and unlocking them from the same screen where you locked them. The unlock option is done by entering option 1. These settings can also be manipulated during IPL time by running the Dedicated System Tools (DST). Once locked, even users with *SECADM or *ALLOBJ cannot make capricious changes to the security system values so your security policy decisions will remain in force without worry.

If you have any questions about anything included in this tip, you can reach me at All email messages will be answered as quickly as possible.

ABOUT THE AUTHOR: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.

Dig Deeper on iSeries system and application security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.