Although it is possible not to use a Start-up program, finding a customer who does not use one, is like finding a needle in a haystack. Please allow me to use another expression which, when finishing reading this article makes sense for you: “if it ain’t broke don’t fix it”.
All of a sudden, after a restart of subsystem QCTL, we were noticing high CPU in the job QTOKVPNIKE. The CPU usage was constant and when investigating we found the cause. The Start-up program executed the command STRTCP while the setting for STRTCP had *YES specified for both “Start application servers” and “Start TCP/IP interfaces”. On top of that the TCP/IP Configuration Properties showed that the VPN server was started when TCP/IP starts:
This customer had the downtime available to run a restricted Full System save on a daily basis (a.k.a. “Batch Full System Saves to the Controlling Subsystem Using BRMS”) after which the Startup program would run. The program which had been running for years was now causing issues. A double start of the VPN job caused one job to spike in CPU, which could only be solved by ending that job. The probable cause was a timing issue in the start-up process of the system, causing the VPN job to start twice, making one job start to loop.
When going through the code of the Start-up program, the comments in the code told us that is was retrieved in 2000, the year in which V4R5 was released. As the customer was running IBM i 7.5, some releases were skipped. IBM has a document titled “Changing the IPL Start-Up Program”. In there a section is dedicated to the topic “Starting TCP/IP”, in which another document is mentioned “Starting TCP – Using the IPL Attributes Versus the System Startup Program”. In there you can find the recommendation:
For systems running R610 and higher, the STRTCP processing has new timing functionality and configuration changes to allow for the IPL Attributes to be successful. IBM recommends using the IPL Attributes (CHGIPLA) to start TCP services at R610 and beyond.
So by removing the STRTCP command from the Start-up program the high CPU usage of the task QTOKVPNIKE was gone.
So if you have not updated your QSTRUPPGM since that release, it is time to get started.
Changing the QSTRUPPGM program is not that difficult. Testing it, is in most cases, the opposite. When something needs to be changed you have to recompile. Maybe changing the owner and/or using adopted authority, I have seen all combinations.
In order to make our life as system administrator easy we have made a change to QSTRUPPGM program:
When starting QCTL all we are doing is calling one program, one program to control it all. Behind the STRSTP_MNG (Start/Stop Manager) is one file, containing the following data:
Depending on the status of the field “ACTIVE” the command: “SBMJOBJS JOB(SYSTEM__STR) TIME(*IMMED)” is executed. The command SBMJOBJS now comes along with your IBM i entitlement. So every IBM i LPAR can make use of this great product. When looking at the job SYSTEM_STR we can see that we have an editor in which we can add more commands as we wish.
The Navigator for i is not yet ready to look at the properties of a “Scheduled Job”. According to this link that will be solved soon, as making this function available is on the roadmap:
IBM Navigator for i – Documentation on Functional Areas.
In there another link can be found:
Advanced Job Scheduler (AJS) plugin to IBM Navigator for i.
Is in here where the words “most implemented” covers the cargo.
So we have to switch to the 5250 emulation to see what it is all about:
Some may recognize the starting of Infor M3 and the starting of Quick-EDD/HA (software replication).
Making use of the SBMJOBJS command within an Advanced Job Scheduled task makes it possible to submit that job using a specific user.
If configured we can add the option to mail the joblog in case the job being submitted ends abnormally.
The Advanced Job Scheduler is not by accident having the word “Advanced” in it’s product name.
When looking of the content of the source file being used to control your system start-up process you may have noticed lines or fields which have made you curious. If so, please let me know and I will dive into them in my next article. Please do not expect others to respond if you do.