SDSF to provide a display/panel for System Recovery Boost (SRB) for Middleware Subsystems on z16 showing boost eligibility and if boost has actually occurred along with type of boost.

There is currently no way to determine whether a Middleware Subsystem running on a z16 is eligible for BOOST without going into the WLM Service Definition --> Classification Rules --> STC and then paging right to check the BOOST column. Not a very efficient process.

The other way is trawling through SMF data and writing a homegrown report but this is historical and not real time

The above two scenarios are also just to provide information as to the address space(s) eligible for BOOST. It does not provide information as to whether the address space(s) actually have had or are currently undergoing a BOOST action and what that BOOST action may be. 

You do see in the SYSLOG/OPERLOG, the IEA687I message, which can have a text string of one of the following -

 o  Not identified                      
                                       
o  Sysplex Partitioning                
                                       
o  CF Structure Recovery               
                                       
o  CF Data-sharing Member Recovery     
                                       
o  Hyperswap                           
                                       
o  SVC Dump                            
                                       
o  Middleware Region Startup           
                                       
o  Hyperswap Config Load               

However, the IEA687I message does not identify the Middleware Subsystem address space that generated the IEA687I message in the first place

The ideal situation is to have SDSF DA panel enhanced (with additional columns) OR another complete SDSF Panel to show the eligible address spaces that have BOOST=YES in the active WLM Policy displaying the address space(s) that  *CAN* be boosted as well as if the address space(s)  *HAS*  been boosted or *ARE* currently being  boosted. Subsequently, if the panel shows the address space(s) *HAVE* been boosted or *ARE* undergoing a boost, to be able to drill down and display the boost reason (as per the current 8 possible text string reasons from the IEA687I message. This would assume that the SDSF address space itself would have to be started/available very early in the IPL process to be able to capture this boost information.