Many of you (well, hopefully, all of you!) regularly apply PTFs to your systems to keep them current with fixes from IBM. Doing so ensures that you will always have the latest code updates from Big Blue to keep your IBM i environments running as problem-free and as securely as possible, and it is simply the tried & true best practice for maintaining fixes for the platform.
What we frequently find with customer systems is that many shops do attempt to keep their PTFs as current as possible (e.g. applying cumulative PTF packages every 12-18 months on average), but what we have also found is that the majority of shops are woefully negligent in “permanently” applying their PTFs on a regular basis as they are not aware of the importance of doing so.
From a very fundamental standpoint, there are basically three distinct code levels on IBM i that you regularly apply PTF fixes to:
- The Licensed Internal Code (or “LIC”) and these are all the MFnnnnn numbered fixes under product ID 5770999 and the LIC is the code level that interacts with the hardware and provides low-level system functions to the operating system
- The base IBM i operating system and these are all the fixes under product ID 5770SS1 and this code level constitutes the base operating system functionality
- The Licensed Program Products (or “LPPs”) and these are all of the fixes for the optionally installed licensed programs on your system
When you apply new PTFs you will typically apply them temporarily so if any of the new fixes introduce any operational issues they can be removed with a RMVPTF command. The recommended flow is that you apply say a cumulative PTF package on an IPL with all PTFs set to be applied temporarily and let the system run for a few weeks with the temporarily applied PTFs to ensure the new fixes did not introduce any problems to the system, if no problems are found then you can run the following command to set all PTFs to permanently apply on the next IPL for all code levels (LIC, base operating system, and all LPPs):
APYPTF LICPGM(*ALL) APY(*PERM) DELAYED(*YES) IPLAPY(*YES)
The running of the above APYPTF command after newly applied PTFs have been deemed stable is what most shops are not doing on a regular basis and they should be.
So specifically “why” is permanently applying PTFs …
BRMS (Backup, Recovery, and Media Solutions) is an application for IBM i used to make backups and restores easier. You can configure backups to happen just as you want them, and when you want to restore, find exactly what you want and where to restore it from. Very often users will configure BRMS to do Save-While-Active saves, so that applications don’t have to be ended during backups – keeping their system up and running and making them look like a superhero.
However, any objects that have exclusive locks on them cannot be saved during a Save-While-Active. Also, by default, objects that use commit control cannot be saved while in the middle of a commit cycle. When a single object in a save cannot be saved, it will result in the message: Control group XYZ type *BKU completed with errors. Some administrators will often begin to accept this as a good completion message and never check to see what didn’t get saved. This could lead to a potentially disastrous situation if you need to restore and it turns out that not as much of the system was getting backed up as you thought.
There are two things you want to do to rectify this situation:
1) End the application causing the lock before the save and then start it after the save finishes.
2) Omit the objects that cannot be saved. Ending the application may not be possible, so then you have to look at what’s not being saved. If the objects that cannot be saved are trivial things like log files or easily re-created data areas, you can simply choose to omit them from the backup, since they are not critical to restoring the system.
The easiest way to add omits to your BRMS control groups is by using the graphical interface for BRMS inside of Navigator for i. There is a section for Backup, Recovery, and Media Services in the panel on the left side of the page.
Inside the section for Backup Control Groups, you will find all your configured control groups. Right-click the one you want to work with and click Properties. Click on the What tab to see what you are backing up. Click on the arrows next to the Item and then click Change Omits… This will let you add either single objects or many objects by specifying a string and then ending …
When using BRMS control groups (WRKCTLGBRM), it is possible to add user commands using the *EXIT option for the backup item. These commands can run many different backup items or end/start applications.
First and Last *EXIT
If used, these are processed outside of the control group. The first *EXIT is the pre-control group exit that runs before any of the control group attributes are run (signing off users, ending subsystems, holding job queues, and so on). The last *EXIT is the post-control group and is run after all entries in the control group have been run.…
BRMS is not a set it and forget it backup and recovery application. Since BRMS uses database files to store information, some of these files can get large and have many records inserted and/or deleted every day. There are ways that you can clean up BRMS data files on a regular and as-needed basis.
Regular BRMS data files cleanup strategy:
BRMS recommends that the Start Maintenance for BRM (STRMNTBRM) command with *YES specified for the reorganize BRMS database (RGZBRMDB) parameter, is run at least once a month to clean up the files. Because it can take a long time to reorganize the BRMS database, it may be desirable to reorganize the BRMS database in batch using the STRMNTBRM command, and performing this when no other BRMS activity is being performed. The more often you run it, the less time it takes to run. I would recommend running daily, as part of your BRMS strategy to include:…
Understand the different ways to save your system, using BRMS or traditional native commands. Learn about what you need to restore your system, and the steps involved to perform the restore. Tips will be given along the way on best practices.
This webinar will cover:
- Understanding basic backup and recovery
- If you are saving the right information to recover your system
- What you need to know to recover your system
[Watch Now ]
I have been asked by customers using BRMS, if there is an easy way to exclude objects in the IFS, that are unable to be saved, when using *LINK, to prevent getting the softer error: “Save of list *LINK completed with errors” (BRM10A1 is issued)”.
There are several methods:
- Create and use a BRMS backup list in your backup control group, type *LNK, specifying the IFS directories or files you want to include and omit, and use that as a backup item *LNK in your BRMS backup control group for saving IFS information.
- When using *LINK, list type *LNK, as a backup item in your backup control group, for saving the IFS, use the BRMS backup list, type *LNK, QLNKOMT, to specify any directories or links to be excluded from a *LNK backup, by adding them to the OQLNKOMT user-modifiable list. This is the method I will discuss in further detail in this article.
Have you ever seen or gotten a BRM1744 during a BRMS full system save or SAVSYSBRM? Here is what you need to do to resolve this, and I am only going to address V5R3M0 and above. When a SAVSYS is performed through BRMS using a backup control group or the SAVSYSBRM command, BRMS will automatically attempt to end the system to a restricted condition by issuing the following command:
ENDSBS SBS(*ALL) OPTION(*CNTRLD)…