InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for checking code levels on a system

IP.com Disclosure Number: IPCOM000244110D
Publication Date: 2015-Nov-09
Document File: 3 page(s) / 39K

Publishing Venue

The IP.com Prior Art Database


Described is a preventative mechanism to alert and prevent clients from using non-production code levels.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 01 of 3

Method for checking code levels on a system

There have been some recent issues where customers have received power systems with pre-release firmware. The pre-existing checks currently in place to catch for putting pre-release firmware on customer systems are manual and did not catch the firmware load in this case. A need exists to better automate detection of pre-release code levels on production-level systems. Currently on power systems, all levels of code (HW, FW FRUs, VIOS, OS, etc.) have an associated signed digital certificate to verify the validity of the code. This certificate can indicate the code level. When the customer is using the system as a development system, it is not as critical that these code levels be checked. For example, if the customer is a beta customer, they may have beta code in a development environment which is valid.

    However, once the customer uses the system in a production-like manner (explicitly or implicitly), this invention does a call home to verify that all of the code levels on the system are valid for production use. If there is a version of hardware (HW) or software (SW) that is not valid, the customer is alerted and the system is not allowed to be classified as a production-level system until the version is updated. However, once the system is successfully classified as production-level system, the customer is not forced to do further version updates to retain production classification. The classification of the system can be used to prioritize service and support efforts. This invention requires a new indicator on each piece of code and hardware element (e.g., HW FRU, firmware, VIOS, etc.) to signify if the element is "development" or "production". By default, on components with beta code, this indicator is set to "development". On components with GA level code, this indicator is set to "production".

    On power systems, all levels of code (HW FRUs, FW, VIOS, OS, etc.) have an associated signed digital certificate to verify the validity of the code. This digital certificate could either be stored on the system itself or remotely (i.e., the cloud). If the code does not have an associated certificate, the system assumes the code to be invalid. Because one can detect the code level from that digital certificate [*], a call home can be run periodically to validate if a customer has an old or bad version of a particular piece of code or code combination. (For example, once code is GAed, beta code would be considered "old and the certificate for that code would be invalid".) In normal running modes, the hardware management console (HMC) can then present this information to the user to indicate should update their code at their earliest convenience.

    However, in the instance where the user has a development system and wants to turn it into a production system in order to receive prioritized support, one would want this invention to ensure that the customer is at the proper code levels. Because produc...