We recently installed a new i5 System i server in our office. This is always an exciting time and we normally rush to get the system set up so we can move operations onto the new hardware as soon as possible. Since we do this kind of changeover infrequently (this is our 4th system since 1988), we are not really what you consider to be experts in this field.
When we got our new system up and running and then unplugged our venerable, now antique, server, we found that some things seemed to be working differently. It took us a little while to sort it out, but some of the issues we were having could be traced back to the fact that several system values were now set up differently from our old system. And, to our dismay, the old server was now on a truck on its way back to the leasing company. So, we were left to sift through the system value listing and see if we could remember what our old system was configured for and get it reset. Shame on us, we should have thought about this before releasing our former system.
I'm sure that we are not alone with this problem. In fact, system values are so critical to how a system behaves, that having a current inventory of their authorized settings should be an important part of your security plan.
The easy way out of this is to just run a complete listing of the current system values using the Work with System Value (WRKSYSVAL) command. If you prompt this command, there is an output parameter that will allow you to run a complete listing to a print spool file. This report will show you all of the system values on your system along with the current value, the value as it was shipped from the factory and a description of the value. Then, just print the simple three-page report and keep it in an active file. While you're at it, take a look at those values that are different from the factory defaults on your system and make sure you understand why the changes have been made. Those system values that are different are identified by a > character on the report between the system value and the current value setting.
If you're like me, however, it would be nice if you could automate this process, even just a little. One way to help with this is to keep the report in a physical file on your system. You could create a separate member for each day when you run the report and then see if system values are changing. I set this up on my system by creating a simple physical file in library QUSRSYS named QSYSVALUES using the following command:
CRTPF FILE(QUSRSYS/QSYSVALUES) RCDLEN(132)
MBR(*NONE) MAXMBRS(*NOMAX)
Then, run the report with the output going to an output queue that will not print right away. You can do this with the following command:
WRKSYSVAL OUTPUT(*PRINT)
Lastly, save the report in your database file with the following command:
CPYSPLF FILE(QSYSPRT) TOFILE(QUSRSYS/QSYSVALUES)
SPLNBR(*LAST) TOMBR(V20070423)
In this case, the member name gives the year, month and date when the values were stored.
If you set this up to run once a month, you can then build up a collection of system value reports that you can check against each other. This will help you to know that the values are not changing over time and, if they are changing, get you started on back tracking as to when they got changed. If you're feeling adventurous, you could even create some database query programming to check for changes from one member to the next.
System values are critical to how your system works. Keeping them under control will keep your system running smoothly.
If you have any questions about this topic you can reach me at (rich@kisco.com), I'll try to answer any questions you may have. All email messages will be answered.
---------------------------
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.
