FLRT assists administrators in formulating a maintenance plan for IBM Systems. It uses various code and fix levels to provide recommendations on updates or incompatibilities on your system.
Overview and History
The Fix Level Recommendation Tool (FLRT) was initially created to support Power hardware customers. New products, brands and platforms have been added in the last few years, but Power customers remain our target audience.
FLRT provides many features for system administrators and service planning. In addition to providing update and upgrade recommendations, it also provides test matrix data for storage and compatibility information for many IBM software and middleware products.
Its main mission is to provide a report with data to aid system administrators with service planning. System administrators can come to the site and provide their current firmware, HMC, operating system and software levels and receive a report with current recommendations. This is very useful when planning for your next maintenance window.
FLRT supports Power, Power blades (BladeCenter), and PureFlex Power compute nodes on the hardware side.
The first thing you must do if you want to get recommendations for firmware, HMC or operating systems is select the machine type and model of the system. This allows FLRT to display the applicable levels in the drop down menus. Only the supported levels are displayed. This serves to reduce the list to a reasonable number of choices and will also tell you what levels are supported.
Another way to view base level requirements for systems is to use System software maps.
This site pulls data from FLRT to show the minimum level requirements for AIX, IBM i, VIOS, RHEL and SUSE for Power systems, including BladeCenter and PureFlex. Check it out the next time you plan to purchase a new system to see the minimum requirements.
When FLRT was first released (2005) it only supported one partition and did not support VIOS. Now that virtualization has become the standard, we have added the ability to enter data and levels for each partition on your system. We also added the ability to save all the hard work of entering the data with the inventory save option.
Let's discuss some frequently asked questions to help you understand how FLRT works and why it works the way it does.
Frequently Asked Questions
Where does FLRT get its recommendations and how often are they updated?
FLRT is updated frequently with new recommendations. The frequency depends on the recommendation type.
FLRT supports many products and each product has its own recommendation 'type'.
- Automated - some recommendations are set up to automatically set the recommended level after a specified period of time or to the latest level available. AIX is set up to mark a service pack as recommended when it is 90 days old. These automated recommendations can be overwritten if there are issues with the service pack and the service teams would not want it to be marked as recommended. We meet with the AIX team each month to verify the recommendations, notes and behavior.
- Aged - make the recommendation based on a specified time period. This type of recommendation can be overwritten if the level has issues that would cause the service or product teams to not recommend it. In some cases, the recommendation may be put on hold until a HIPER fix can be released or the level may be skipped altogether.
- Latest - some products, for instance, cluster software (GPFS, Parallel Environment, etc) automatically mark their latest levels as recommended.
The same is true for VIOS. We have received feedback asking why older levels of VIOS are recommended and not the newer levels. The VIOS team is more conservative in their recommendations. They wait until the newer levels have a fair amount of field time and then will change the recommendation. This does not mean that the new levels are 'bad', just that it's not imperative that the customer move to them.
Of course, all of these recommendations are just that, recommendations. Occasionally, there will be a 'mandatory' update for firmware because of a HIPER issue, but this is rare. For the most part, IBM recommends that customers stay at 'current' levels and do not fall too far behind. Customers should stay on supported service levels when possible.
Maintaining a service strategy to stay on a current service level will reduce your risk when unplanned maintenance is required. Applying many changes during an unplanned maintenance window is not something we would recommend. If you have to apply a HIPER or security fix, try to make sure it is the only thing you are doing in that unplanned maintenance window.
What products are supported?
All of the Power firmware and software will provide recommended levels. IBM Software Group products, such as Tivoli, DB2, etc provide compatibility information.
The IBM SWG products are checked for compatibility with their dependencies. In most cases, the results are supported or unsupported. Occasionally, the results will include a specific required update for a specified OS level.
What are the End of Service Pack Support dates?
The EoSPS date is the end of service pack support. This is the date (approximately) when Service Packs/Fix Packs/fixes will no longer be shipped for a service level. For AIX, TLs are supported for three years, starting with AIX 6.1 TL6. Power firmware and HMC have different EoSPS dates. Power firmware usually supports their levels two years if there is an upgrade level. If no upgrade level is available, they can support up to eight years or until the upgrade level is available.
VIOS has just started supporting multiple service levels, so now clients have more choices on when to move to a new level.
Older Power systems may have a 'Last' indicator for EoSPS because that is the last supported service level, but new updates will continue to ship, just at a slower rate.
What is the difference between an update recommendation and an upgrade recommendation?
Many products support multiple service levels at the same time. For example, AIX, HMC, VIOS (now) and Power firmware, all support more than one level at a time and ship updates out for more than one level. This means that customers have a choice if they are on an 'older' service level. They can apply an update to that level if the level is still in service or they can upgrade to a new service level.
Updates will contain a smaller set of changes than an upgrade, so lower risk, but if a service level is near or at the EoSPS date (see below), an upgrade may be required to move to a supported level.
In the case of Power firmware, upgrades are usually disruptive, while updates are not.
The update and upgrade recommendations are provided for our clients use. They are offered as information to help with service strategy decisions.
Just because you are given an upgrade recommendation does not mean you have to do it. Take a look at your current level and the EoSPS dates to help decide.
The upgrade recommendations are usually the latest service level that has a recommended level. Which means that you will not see an upgrade recommendation to a new service level until it actually is a recommended 'update' level.
Sometimes, there will not be an update recommendation, only an upgrade. Even if there are other service packs or fix packs available, the service or product engineering team may not want to make an update recommendation. This is usually because of EoSPS dates.
Check out this example:
The system firmware is not providing an update recommendation, only upgrade. Because the level is older (it shipped before 2009) and because there is a newer service level available, the recommendation is to upgrade.
In the HMC example, there are options, but if you look closely at the EoSPS, it's clear that it may be time to think about upgrading from V7 R730 to V7 R760.
For VIOS, there is both an update and upgrade recommendation. The EoSPS dates aren't currently filled in, but that will be coming shortly, along with a VIOS service strategy chart, similar to what AIX has today in Fix Central.
Are firmware and AIX levels tied together?
In general, the answer is no. There have been one or two cases in the last twenty plus years where a firmware level required a specific AIX or VIOS level, but it is extremely rare.
There are minimum levels of firmware and operating system levels required for Power hardware, and only those supported levels are displayed in the drop down menus.
The firmware and HMC have a relationship. Upgrading or using a new level of firmware may require an upgrade to your HMC.
If you were going to add a new 8205-E6D system to your data center, you may need to update or upgrade your HMC. The 8205-E6D uses AL770 level firmware, which requires V7 R770 level HMC code. In this scenario, you could check out your other systems attached to the HMC and probably would not have a problem upgrading the HMC to the 770 level and leaving the other firmware at their current levels, as long as they were supported.
What are the symbols in the report?
FLRT also uses several icons to communicate information. The icons are meant to serve as a way to alert you to additional information you may have missed if just scanning the report
What are 'Notes' in the report?
There are times when information needs to be provided in the report in addition to the regular data.
In working with the various product and service teams, we may decide to include a note to relay information if we feel like it would keep the customers from getting into trouble.
The following example shows a situation where the upgrade recommendation (6100-08-02) was released before the input level (6100-06-11). This will cause issues during upgrade with the build dates. In this case, you would wait until the next service pack is released or becomes recommended.
For the most part, we won't duplicate information that is found in release notes or READMEs, but when the information is specific to the recommendation, we try to give a 'heads-up'.
What about interim fixes?
FLRT will recommend interim fixes for products that provide them in Fix Central and also interim fixes for security and HIPER issues on AIX and VIOS. Applying these types of fixes is up to you. The interim fixes may only be applicable for specific environments or function, so review each one.
The example below shows a recommendation for VIOS with interim fixes. This particular example may change over time.
The FLRT report will list the interim fixes for security and HIPER issues for AIX and VIOS. We also provide a set of tables with all the HIPER and security interim fixes that have been released since June 2012. These tables are provided under 'Other resources' in the right hand navigation section in FLRT.
How do I use FLRT scripting?
FLRT has a mechanism to allow clients to pull data or request a report directly from their system. This is extremely useful for automation because it allows you to receive a report on a weekly or monthly basis and not have to think about going to the web site.
We have examples of the FLRT 'scripts' that you can modify to suit your needs.
You can create a script that dynamically collects inventory data and sends to FLRT, or you can use the new inventory save function to create an inventory and use it on a periodic basis to send to FLRT to get a report.
The scripts can be found in the Scripting help section in the right hand navigation column.
Feedback and surveys
All of the feedbacks and surveys are sent to Julie Craft and the FLRT team. You are welcome to submit anonymous surveys, but we like to have contact information for follow-up. We always respond if contact information is provided.
While FLRT supports most browsers, some function may not be available in older versions.
Tested browser information is available in the Browser requirements section in the right hand navigation column.
FLRT currently has one YouTube video available on the Electronic Support channel:
FLRT is social!
Please follow us @IBM_FLRT
Thanks for using FLRT and please let us know how we are doing!