In Episode 25 I said it had been a long time since we had recorded anything. That was true for Episode 25, but it certainly wasn’t true for Episode 26. What is true is that it’s taken us a long time from start to finish on this episode, and ever so much has happened along the way.
But we ploughed on and our reward is an Episode 26 whose contents I really like.
On to Episode 27!
Here are the unexpurgated show notes. (The ones in the podcast itself have a length limitation; I’m not sure Marna and I do, though.) 🙂
Episode 26 “Sounding Board”
Here are the show notes for Episode 26 “Sounding Board”. The show is called this because it relates to our Topics topic, and because we recorded the episode partly in the Pougkeepsie recording studio where Martin sounded zen, and partly at home.
Where we have been
Marna has been in Fort Worth for SHARE back in February
Martin has been to Las Vegas for “Fast Start”, for technical sales training, and he got out into the desert to Valley Of Fire State Park
- Then, in April he “visited” Nordics customers to talk about
- zIIP Capacity and Performance
- So You Don’t Think You’re An Architect?
But he didn’t get to go there for real. Because, of course, the world was upended by both Covid and Black Lives Matter.
Follow up
- Chapter markers, discussed in Episode 16. Marna finally found an Android app that shows them – Podcast Addict. Martin investigated that app, and noted it is available on iOS too.
What’s New – a couple of interesting APARs
APAR PH21919: NEW FUNCTION – WORKFLOW SUPPORT SAVE JOB OUTPUT
When you run a workflow step that invokes a job you can automatically save the job output in a location of your choosing files (z/OS Unix file directory).
In the same format as you’d see in SDSF . Means users can have an automatic permanent record of the work that was done in a workflow
PTF Numbers are UI68359 for 2.3 and UI68360 for 2.4
APAR OA56774 (since 2.2) Provides new function to prevent a runaway sysplex application from monopolizing a disproportionate share of CF resources
This APAR has a dependency on CFLEVEL 24.
This case is pretty rare, but is important when you have it.
Not based on CF CPU consumption. Is based on deteriorating service times to other structures – which you could measure with SMF 74–4 Coupling Facility Activity data.
Mainframe – z15 FIXCATs
Important to cover as there are many questions about them.
IBM.Device.Server.z15–8561.RequiredService
Absolute minimum needed to run on a z15
Unfortunately some of these PTFs in that list have been involved in messy PE chains
If that happens, involve IBM Service (Bypass PE or ++APAR)
Usually intent is to keep these PTFs to a minimum – and keep the number of PTFs relatively constant.
- CORRECTION: System Recovery Boost for z15 GA1 is in Required, not Exploitation category, as the recording states!
IBM.Device.Server.z15–8561.Exploitation
Needed for optional functions, and you can decide when you want to use them.
This PTF list could grow – if we add new functions
IBM.Device.Server.z15–8561.RecommendedService
This is more confusing. Usually to fix a defect that is found but haven’t risen up to required. We might’ve detected it in testing, or a customer might have.
Over time this category probably will grow, as field experience increases
Might want to run an SMP/E REPORT MISSINGFIX to see what’s in this FIXCAT. Might install some, all, or none of the fixes. Might want to be more selective. Based on how much change you want to encounter, versus what problems are fixed
By the way there are other FIXCATs you might want to be interested in for z15, e.g. IBM.Function.SYSPLEXDataSharing
Performance – DFSORT And Large Memory
A very special guest joins us, Dave Betten, former DFSORT performance lead.
Follows on from Elpida’s item in Episode 10 “234U” in 2017, and continues the “Managing Large Memory” theme.
- Number of things to track these days:
- Often track Average Free
- Also need to track Minimum Free
- Fixed frames – Especially Db2, and now with z/OS 2.4 zCX
- Large frames – Again Db2 but also Java Heap
- In z/ 2.2
- OPT controls simplified
- Thresholds set to Auto
- Default values changed
- 64GB versus %
- OPT controls simplified
- In z/ 2.3
- LFAREA
- Not reserved anymore but is a maximum
- BTW the LFAREA value is in SMF 71
- Dave reminded us of what’s in SMF 71
- LFAREA
- Dave talked about DFSORT memory controls
- DFSORT has historically been an aggressive user of memory
- Installation defaults can be used to control that
- But the EXPOLD parameter needs special care – because of what constitutes “old pages”, which aren’t actually unused.
- DFSORT Tuning Guide, especially Chapter 3
Dave talked about how handy rustling up RMF Overview Reports can be, with several Overview conditions related to memory.
Most of the information in this topic is relevant to LPARs of all sizes
Topics – Update on recording techniques
Last talked about this in Episode 12, December 2017
Planning for podcast – still using iThoughts for outlining the episode (though its prime purpose is for mind mapping and Martin (ab)uses it for depicting various topologies.
- Recording of podcast – still using Skype to collaborate
- Record locally on each side, but now Marna’s side is in the new Poughkeepsie recording studio!
- Martin has moved to Piezo and then Audio Hijack
- Recording in stereo, with a microphone stand to minimise bumps
- Has to slow the computer’s fan speed, and has an external cooling pad
- Also he hides behind pillows to minimise the noise and improve audio quality.
- For a guest, it’s different. We can’t record in stereo. Guests might not have recording software. But still use Skype (unless in Poughkeepsie).
Production
Martin’s editing
- Moved from Audacity on Mac to Ferrite on iPad OS
- Moved to iPad so he can edit anywhere, except where there is noise. Apple Pencil helps with precision.
- Then, throw away remote side – in stereo terms.
- Then, perform noise reduction, still not perfect.
Publishing
- Marna’s publishing: Uploading the audio, publishing show notes, still the same as before.
Customer requirements
– Insert Usual Disclaimer Here – which is only our thoughts.
RFE 139477 “Please include the CPU Time Limit for a Job/Step in SMF Type 30”
The CPU Time Limit in effect for a JobStep is not currently written to SMF Type30 at the end of the step.
While a job is running this information is available in the Address Space Control Block (ASCBJSTL) and can be displayed or even modified by tools such as OMEGAMON.
However the information is not retained after the JobStep completes. This information would be very useful after the fact to see the CPU time limit in effect for a JobStep.
This enhancement request is to include the information in ASCBJSTL in the SMF Type30 Subtype 4 record written at the end of the JobStep.
An additional consideration would be how to best deal with the Job CPU time Limit (as specified on the JOB statement) and whether this can also be catered for in the RFE
Business justification: Our site got caught out by a Test job being submitted overnight with TIME=1440 and consuming over 6 hours CPU before it was cancelled. We would like to be able to prevent similar issues in future by having the CPU Time Limit data available in SMF.
Our comments:
- After the fact
The RFE was calling for “after the fact”. i.e. when the step has ended. Might also like the source of the limit.
End of step looks useful. Could run query comparing to actual CPU time, then track to see if ABEND is on the horizon
“As it happens”
Would like on the SMF Interval as well as Step End records, maybe with tools to dynamically change the parameters.
May not need the SMF information if vendor and IBM tools already do it today, making it perhaps not a high enough priority for SMF
And the source of the parameters might not be readily available in control blocks so this might not even be feasible.
- After the fact
On the blog
Here are Martin’s many blog posts since the last episode. (We summarised in the podcast.)
Marna has three:
Contacting Us
You can reach Marna on Twitter as mwalle and by email.
You can reach Martin on Twitter as martinpacker and by email.
Or you can leave a comment below. So it goes…
Mainframe, Performance, Topics 