Mainframe Performance Topics Podcast Episode 21 “Fits and Starts”

(Originally posted 2018-12-08.)

We released this episode a few days ago. But I only got round to writing this post today, 5 days later. That’s because I (and probably half of our listenership 🙂 ) were involved in a rather urgent piece of customer business. There are some learning points from that one, but that’s for another day.

So it goes, indeed.

I’m continuing to experiment with recording techniques – to minimise noise (and hence distortion caused by heavy noise removal). Hopefully this one is better.

The Performance topic was from a real live, very recent, customer situation I had a lot of fun with.

The Topics topic we had a lot of fun making. It seems the Apple versus non-Apple thing we have going works well.

Nobody has mentioned chapter markers yet. If you get to see them let us know how they work for you. In this episode there’s an extra one – which some of you will appreciate… 🙂

Anyhow, enjoy the show!

Episode 21 “Fits and Starts”

Here are the show notes for Episode 21 “Fits and Starts”. The show is called this because we talk about fitness devices, and the Performance topic that had work submitted after a one minute hiatus.

Where We’ve Been Lately

Marna and Martin have been to GSE UK Annual Conference Nov 5-7 in Whittlebury, UK. Great conference!


  • We’ve received feedback from a New Zealand listener requesting a GDPS topic. Good idea, and we’ll look into it! Martin is still playing around with a gentler stereo effect, in response to two listener comments. We hope audio is improving, by using Ferrite.
  • DocBuddy 2.2.1 for iOS and Android is available. The levels are the same between the two platforms, and yet it appears the functional content is different.

What’s New

  • z/OS V2.3 Enhancements
    • The z/OSMF Sysplex Management task is enhanced by the PTF for APAR PI99307 which is PTF UI58355 on V2.3 so you can modify sysplex resources.
    • A new z/OSMF plug-in called the zERT Network Analyzer is now available to visually determine which z/OS TCP and Enterprise Extender traffic is or is not cryptographically protected in z/OS V2.3 with APAR PH03137.

Mainframe: SMF Recording of APF Modifications

  • Post-IPL dynamic APF changes are reflected in SMF 90 Subtype 37
  • A lot of the function is in z/OS V2.2, with these fields in the SMF record:
    • Function: Add, Delete, DynFormat, StatFormat
    • Was the update via SETPROG, SET PROG, CSVAPF
    • Parmlib member suffix for the SET PROG case
    • Data set name
    • Volser
    • Time of update (STCK)
    • Jobname
    • Command Scheduling Control Block (CSCB)’s CHKEY field
    • Console ID of issuer (-1 for CSVAPF)
    • Utoken of issuer
  • More in z/OS V2.3:
    • The RACF UTOKEN is stored in its “unencrypted format”
    • The UserID within the UTOKEN is at offset x‘98’ in the data
    • The console name is provided at offset x’A8’
    • PROGxx supports APFSMFALL:
      • When specified, the SMF record includes information about updates that are “already in the correct state”. Defaults to initial behavior of not placing “no change”cases in the SMF records. The record identifies this situation by a bit: SMF90T37_AlreadyAsNeeded –the x‘01’ bit in byte SMF90T37Flags (offset 1)
  • Triggers when post-IPL APF changes dynamically: PROGxx: APF ADD …or APF DELETE … SETPROG APF,ADD,… or SETPROG APF,DELETE,…
  • Ensure to collect by setting in SMFPRMxx type 90 subtype 37 record
  • Presumably there’s not much overhead, as it will be produced when changes happen (which is probablyl not often).
  • Auditors will probably want this

Performance: An interesting Db2 DDF case

DDF stands for Distributed Data Facility. DDF is how you get to Db2 from outside the LPAR, and with a Type 4 JDBC driver if the java application is local.

Central to Martin’s DDF work is some analysis code to process SMF 101 DB2 Accounting Trace.

A customer complained their DDF application stopped dead one evening – for 1 minute. It was an application serviced by a 3-way Datasharing group. The customer sent SMF 101 data from all 3 members for 3 hours around the stoppage, and for 3 hours the previous evening for a presumably “good behaviour”.

Martin plotted application statistics at a one second interval level – across both days. Lots of data points: 6 hours x 3600 seconds is a lot of data points – 21,600.

Excel was frustrating – as ever! (Martin thinks he’s getting better at this but the swearing hasn’t diminished and it’s despite, rather than because of Excel.)

He plotted the transaction ending rate for each member.It showed sloshing (moving of workload to lightly used system to the point of it being too busy) but much more:

It showed a 40-second stoppage the evening they hadn’t complained, making the 1 minute threshold interesting as a number.

But why did the app stop?

Theory number one is that the transactions elongated. They weren’t elongated enough to support that explanation.

NOTE: SMF 101s are written at transactionending / commit not on an interval basis.

He looked more at the in-DB2 time components, and there was not much “Not Accounted For” time – typically CPU queuing.

Martin “zoomed in” to a much shorter time range . When transactions started again they were elongated, and it that was due to the clustered arrivals in clearing the backlog.

The best theory is something external stopped transactions arriving.

Further he thought there could be “near misses” many times, just short of the 1 minute mark. Martin speculates an external monitor alerted or standby process kicked in – based on a 1-minute threshold.

After transactions started coming again there were spikes in transactions arriving every minute. The speculation is this might be the middle tier doing something on a 1 minute basis: Maybe retries of some sort?

The key learning point from this experience is that drilling down well below the RMF interval can help, and you can see sloshing and routing behaviours.

NOTE: With SMF timestamp granularity you can go to 100th of a second granularity, but that’s a lot of data points!

…and you wouldn’t get many transaction endings per data point, either. (100 transactions per second = 1 per 100th, so it would appear “lumpy”.)

Topics: Fitness Tracking

  • Why are we doing this? Nosy about data, wanted to get fitter, and wanted to lose weight.
  • Marna uses a Fitbit Charge 2.
    • Key features: sleep analysis, step counts, heart rate.
    • There is a Fitbit Charge 3 coming soon.
    • Fitbit app for the Android: calculates floors, miles, calories, sleep analysis, across timescales – day, month, overall, etc and compares with age bracket.
  • Martin uses an Apple Watch, and used to have a Fitbit.
    • He wanted the Watch for other reasons: for health a few months ago, and all of the above – except for sleep tracking.
  • Marna gets employer incentives, to help with health care cost reduction.
    • However, IBM and health insurance company has the data.
    • Fitbit links to a “Vitality” website, but asked for permission.
  • Martin has been successful, as he hasn’t failed to close his rings for 3 months, for the Apple Watch. This makes him obsessive.
    • Uses iOS Overcast podcast player to send podcast episodes to the watch.
    • Runs with just the watch and AirPods. Listening to podcasts keeps me going – whether running or walking.
    • He has lost a considerable amount of weight! Cardiac situation much better, lowered resting heart rate, faster recovery from exercise, and clothes fit better.
    • There is plenty of data, and some of it is alarming.
    • Once you start you want to keep going, and you could become obsessive.

Customer requirements

  • z/OSMF supplied ftp profiles need to be GDPR compliant
    • z/OSMF supplied ftp profiles can’t be modified to require passwords (per GDPR compliance) and can’t be removed. They are useless now and confusing, as they can’t be removed and can’t be modified.
    • Adoption of z/OSMF Problem Management is difficult enough with the additional confusion of ftp profiles that no longer work and can’t be modified or removed.
    • IBM update for requirement: We take this as the ability for a customer to remove the IBM supplied profiles that they don’t want to use such as profiles that don’t require a userid and password. Martin thinks that we take GDPR pretty seriously, so this sounds reasonable in that spirit.

Places we expect to be speaking at

  • Milan, 27/28 November at an IBM technical conference.

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…

Published by Martin Packer

I'm a mainframe performance guy and have been for the past 35 years. But I play with lots of other technologies as well.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: