New Podcast Episode: New location, long episode, with correction

Martin and I have finally published another episode of Mainframe, Performance, Topics (https://anchor.fm/marna-walle/episodes/Episode-26-Sounding-Board-efp6in/a-a2kalnf).  This is quite a long episode.  It took us so long to record, as it was done in at least three locations, and we were happy to have a special guest:  Dave Betten.

If you have not subscribed to our new podcast location, please do, as to not lose any notifications on new episodes.  We are only found on our new podcast host location, and on all popular podcast apps.  Our new publishing site only allows us 4000 characters of show notes.  As you know, I'm quite verbose, so I wanted to put the full show notes below.  Also I have a correction to make, which I want to point out in the show notes below.

Happy listening, and remember to use the chapter markers if you want to skip over something!

-Marna 

===>  Beginning of long show notes, with correction 

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.

What’s New - a couple of interesting APARs

  • APAR PH21919: NEW FUNCTION - WORKFLOW SUPPORT SAVE JOB OUTPUT

    • 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

    • 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

  • IBM.Device.Server.z15-8561.RequiredService: Absolute minimum needed to run on a z15. 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: Usually to fix a defect that is found but haven’t risen up to required. 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 %
  • 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
  • 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.

On the blog

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...

===>  End of long show notes 

Recent Stories
New Podcast Episode: New location, long episode, with correction

Our podcast's new home away from home

The best (and last?) GDG to GDGE conversion method