When you ask customers how often they patch IBM i, the answer will most likely be, once or twice a year. Part of the reasoning behind this, is the schedule of cumulative PTF packages (cumpkg). Which is in general twice a year. What new is that, we now see that in many cases, the release date of a new cumulative PTF package, is close to the general availability (GA) date of a Technology Refresh (TR). In general it is fair to say that the cumulative PTF package is there for bug fixing, the (TR) offers new functionality. For this reason there is a lot more media attention around a TR.
How often do you need a SAVSYS?
When applying a cumpkg, a system administrator knows that a SAVSYS is needed. So, once or twice a year, a SAVSYS is made.
In today’s world, patching IBM i once or twice a year is enough in the mind of most system administrators, but is that true?
When looking at the update frequency of the Hiper PTF Group, which is every two weeks, it is hard to explain why all those PTFs are not needed. In order to determine that, you would have to know what they fix.
Be mindful of the time
As IBM i has been around for a few decades, we have to adjust to the changing world, looking different to our patch frequency is one them. It does do harm to check the way we work.
The outcome of this is that we may decide to patch IBM more frequently. It is here where the command SAVSYSINF has an important role.
An IPL command with a PTF apply in general does not take much more than 15 minutes, but when combining this with a SAVSYS or a Full System save we are talking about hours instead of minutes.
Let's talk about disk space
A SAVSYSINF does not replace a SAVSYS and after a TR apply, a SAVSYS is needed before we can use the SAVSYSINF command. In order to cleanup disk space used by PTF cover letters and savefiles, it is good practice to delete PTF's which have been applied, after a SAVSYS was done.
So, if we decide to apply PTFs during an IPL, without running a SAVSYS afterwards, we need the PTF savefiles. The complexity coming along with PTFs is that sometimes one PTF superseded another, sometimes it requires a PTF to be applied permanently. It there where the trouble starts. If this is too complex for you, skip the next section and continue with the repair script section.
Back-up & good practice (backup without the "-")
When we run a SAVSYS, we create a backup of the current situation with all PTFs saved with the state they are in. Some permanently, some temporarily applied. After that SAVSYS it is good practice to run the command DLTPTF.
So, after a SAVSYS we no longer have any PTF savefiles on the system. So if we apply a new PTF which changes of temporarily applied PTF to permanently applied, the savefile of that PTF is needed for the SAVSYSINF command to work.
The reason for this is simple, the SAVSYSINF command is unable to determine if a permanently applied PTF, was already applied temporarily. The message shown below can be found in your joblog when running the SAVSYSINF command without having all the required PTF savefiles on your system:
The repair script
In order to detect which PTFs already applied temporarily, were changed to permanently, the SQL script shown below can be used.
In order to run this SQL script you need IBM i 7.3 TR10 or 7.4 TR4 on your LPAR.
SELECT qsys2.QCMDEXC('CL:SNDPTFORD PTFID(' concat (substring(MESSAGE_TEXT, 13, 7)) concat ') ORDER(*PTFID) REORDER(*YES)')
FROM TABLE(QSYS2.HISTORY_LOG_INFO(CURRENT TIMESTAMP - 5 DAY)) X
WHERE MESSAGE_ID='CPF3629' and 'Q' || (substring(MESSAGE_TEXT, 13, 7)) not in
(SELECT objname
FROM TABLE(qsys2.object_statistics('QGPL', '*FILE', '*ALL')) AS x);
What this SQL script does, is:
- Check the history log for CPF3629 (indicating which PTF was applied permanently.
- Check the history log for the last 5 days, depending on how long ago your PTF apply was done.
- Check if the PTF ID in that message CPF3629 does not have a savefile in QGPL.
- Combine this direction with the new scalar function
To make my life easier I have combined this script with a way to check if a SAVSYSINF is running fine or not. Again SQL rules:
CL:DLTF FILE(QRPLOBJ/SAVSYSINF);
CL:CRTSAVF FILE(QRPLOBJ/SAVSYSINF) TEXT('TEST SAVSYSINF *SAVF');
CL:SAVSYSINF DEV(*SAVF) SAVF(QRPLOBJ/SAVSYSINF);
The above allows me to keep control, now I have the option to patch my LPAR more frequently, removing the need, that after every apply, I need a SAVSYS. The biggest advantage is less down time with a more up to date system.
