Submitted By: SHARE-MVSE
Submitted Date: 03/19/2022
Submitter Name: Mike Shorkend (System Software Specialist)
Submitter Email: mike@shorkend.com
Description:
The current documentation ( https://www.ibm.com/docs/en/zos/2.5.0?topic=customization-using-sdsf-server) specifies that SDSFAUX should be assigned to a medium priority service class. It seems that since z/OS 2.4, SDSFAUX now populates the 'DA" SDSF panel. On a busy system, the values on the "DA" screen will fail to update if SDSFAUX is assigned a relatively low priority.
This is the related discussion from the SHARE requirements community
It seems like this would be better be explored in a PMR or a request to update doc. It expresses an opinion (probably valid) that SDSFAUX one sentence in doc should be changed to recommend HIGH or SYSSTC rather than MED. Its not a bad observation but I would probably start by posting to IBM-MAIN, sending a note to Rob Scott at Rocket, or opening a PMR. Requirements to make a single specific doc change have historically not been the vehicle. If I was going to push this as a requirement it would be to have SDSFAUX automatically set an appropriate service level or detect when it was getting poor service and outdated information.
Other thoughts?
------------------------------
Sam Knutson
VP, Product Management
BMC Software
Port Matilda PA
------------------------------
Thanks Sam,
I did post this issues to IBM-MAIN in March and Rob Scott responded. My post and his response follow.
My post:
Hi,
On z/OS 2.4, I have set up SDSFAUX so that it goes to a medium priority service class as recommended by the documentation.
When an LPAR is very busy, hitting enter on the SDSF DA screen does not change the cpu% column values. I looked at SDSFAUX and it was starved for CPU. I changed SDSFAUX to a higher service class and the problem went away.
I do not recall this happening in previous z/OS versions.
I will just leave SDSFAUX at a higher priority but was curious if anyone else ran into this.
Thanks
Mike
Rob's response:
This is because the data for the "DA" panel (derived from calls to both RMF and JES) from 2.4 onwards is collected centrally by the SDSFAUX address space rather than being gathered by every SDSF user every time they press enter on the panel.
I think there is a good case to update the SDSF manuals to reflect more realistic tuning advice.(my bold)
Rob Scott
Rocket Software
Rob refrained from suggesting service class importance or goal, but his response did prompt me to raise a requirement.
Since I posted that question, I have found that when SDSFAUX is starved for CPU, it will also delay the changing of a service class from the DA panel, or the service class might change but it takes ages to show up on the panel.
Most confusing when you are trying to troubleshoot and fix a performance issue.
So I think that we can agree that the documentation needs to be changed(especially as it recommends a service class, STCMD, which means nothing without the general WLM context).
Maybe this should be raised as a case/PMR and not a requirement?
Any other thoughts?
Mike
------------------------------
Mike Shorkend
System Software Specialist
Michael Shorkend
Shoham
------------------------------
