Ross, First of all, I am glad you have opened a support case for this, our support team should be able to gather further diagnostic information to resolve the problem.
A bit of background information for the archives : (o) In z/OS 2.4+, the SDSF "DA" information is gathered centrally by a subtask in the SDSFAUX address space. (o) This subtask uses the RMF programming service ERBSMFI (GRBSMFI) to collect this information and any ISV product that replaces RMF supplies an alias for this module. (o) The SDSFAUX address space dumps the first 256 bytes of the ERBSMFI load module in the HSFTRACE DD that is allocated to the SDSF started task (o) When the RMF address space is not active, ERBSMFI still returns the data we require (SMF 79-1 records), however in our experience other ISV products do not return data when their STC is inactive and instead pass back a non-zero return code. As a customer for an ISV that replaces RMF, you might want to consider raising an RFE with them to address this. (o) When we get a non-zero return code from ERBSMFI for 79-1 data, we fallback to our own internal data collector (HSFSMFI) that builds pseudo 79-1 records that reflect the columns that SDSF used to display prior to using ERBSMFI (many years ago). The SDSF client code will detect this condition and the number of columns shown on the DA panel will be greatly reduced from "full-RMF" function. (o) Error conditions calling ERBSMFI are normally reflected either by WTO-style messages and/or messages written to the HSFLOG DD that is allocated to the SDSF started task. (o) Other SDSF panels that depend on ERBSMFI include DEV and PAG, however they do not have internal fallback capability. Rob Scott Rocket Software -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Ross Vaughn Sent: 03 February 2023 04:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Missing Values For The 'SDSF DA' Panels - z/OS 2.5 EXTERNAL EMAIL We are currently in the process of rolling out z/OS 2.5 and have hit an issue on a test LPAR that is not displaying any information in the SDSF DA panels. There are no messages in the syslog out of the IPL that would lead us in a certain direction. We think we may have an issue with CMF but can’t confirm. We are occasionally seeing error messages out of SDSFAUX as well. It looks like beginning with z/OS 2.4 the ’SDSF DA’ information is obtained by the SDSFAUX address space calling the BMC AMI Ops Monitor for CMF. We have verified we have the CX10GVID module in our linklist library that CMF uses to obtain the SDSF DA values. We have a ticket open with support as well, but curious if anyone has seen similar issues when rolling out z/OS 2.5? Same LPAR on z/OS 2.4 does not have the same issue. Thanks, Ross ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
