This was a fun episode to make, not least because it featured as a guest Miroslava Barahona Rossi. She’s one of my mentees from Brasil and she’s very good.
We made it over a period of a few weeks, fitting around unusually busy “day job” schedules for Marna and I.
And this one is one of the longest we’ve done.
Anyhow, we hope you enjoy it. And that “commute length” can be meaningful to more of you very soon.
Episode 29 “Hello Trello” long show notes.
This episode is about how to be a better z/OS installation specialist, z/OS capture ratios, and a discussion on using Trello. We have a special guest joining us for the performance topic, Miroslava Barahona Rossi.
Follow up to Waze topic in Episode 8 in 2016
- Apple Maps Adds Accident, Hazard, and Speed Check Reporting using the iPhone, CarPlay, and Siri to iOS.
What’s New
-
Check out the LinkedIn article on the IBM server changing for FTPS users for software electronic delivery on April 30, 2021, from using TLS 1.0 and 1.1 to using TLS 1.2, with a dependency on AT-TLS.
-
If you are using HTTPS, you are not affected! This is recommended.
Mainframe – Being a Better Installation Specialist
-
This section was modeled after Martin’s “How to be a better Performance Specialist” presentation. It’s a personal view of some ideas to apply to the discipline.
-
“Better” here means lessons learned, not competing with people. “Installation Specialist” might just as well have used “System Programmer” or another term.
-
There’s definitely a reason to be optimistic about being a person that does that Installation Specialist or System Programmer type of work:
-
There will always be a need for someone to know how systems are put together, how they are configured, how they are upgraded, and how they are serviced…how to just get things to run.
- And other people that will want them to run faster and have all resources they need for whatever is thrown at them. Performance Specialists and Installation Specialists complement each other.
-
Consider the new function adoption needs too. There are so many “new” functions that are just waiting to be used.
-
We could put new functions into two catagories:
-
Make life easiesr: Health Checker, z/OSMF, SMP/E for service retrieval
-
Enable other kinds of workload: python, jupyter notebooks, docker containers
-
-
A good Installation Specialist would shine in identifying and enabling new function.
-
Now more than ever, with Continuous Delivery across the entire z/OS stack.
-
Beyond “change the process of upgrading”, into “driving new function usage”.
-
Although we know that some customers are just trying to stay current. Merely upgrading could bring new function activation out of the box, like SRB on z15.
-
-
A really good installation specialist would take information they have and use it in different ways.
-
Looking at the SMP/E CSIs with a simple program in C, for example, to find fixes installed between two dates.
-
Associating that with an incident that just happened, by narrowing it down to a specific element.
-
Using z/OSMF to do a cross-GLOBAL zone query capability, for seeing if a PE was present within the entire enterprise quickly.
-
Knowing what the right tool is for the right need.
-
-
Knowing parmilb really well. Removing unused members and statements. Getting away from hard-coding defaults – which can be hard, but sometimes can be easier (because some components tell you if you are using defaults).
-
Using the DISPLAY command to immediately find necessary information.
-
Knowing the z/OS UNIX health check that can compare active values with the hardened used parmlib member.
-
-
Researching End Of Service got immensely easier with z/OSMF.
-
Looking into the history of the systems, with evidence of merging two shops.
-
Could leave around two “sets” of parmlibs, proclibs. Which might be hard to track, depending on what you have such as ISPF statistics or comments. Change management systems can help.
-
Might see LPAR names and CICS region naming conventions
-
-
Might modern tools such as z/OSMF provide an opportunity to rework the way things are done?
- Yes, but often more function might be needed to completely replace an existing tool…or not.
-
You can’t be better by only doing things yourself, no one can know everything. You’ve got to work with others who are specialists in their own area.
-
Performance folks often have to work with System Programmers, for instance. Storage, Security, Networking, Applications the list goes on.
-
Examples are with zBNA, memory and zIIP controls for zCX, and estate planning.
-
-
Use your co-workers to learn from. And teach then what you know too. And in forums like IBM-MAIN, conferences, user groups.
-
Last but not least, learn how to teach yourself. Know where to find answers (and that doesn’t mean asking people!). Learn how to try out something on a sandbox.
-
Performance – Capture Ratio
-
Our special guest is Miroslava Barahona Rossi, a technical expert who works with large Brasilian customers.
-
Capture Ratio – a ratio of workload CPU to system-level CPU as a percentage. Or, excluding operating system work from productive work.
- RMF SMF 70-1 versus SMF 72-3
- 70-1 is CPU at system and machine level
- 72-3 is workload / service class / report class level
- Not in an RMF report
- RMF SMF 70-1 versus SMF 72-3
-
Why isn’t the capture ratio 100%?
- There wouldn’t be a fair way to attribute some kinds of CPU. For example I/O Interrupt handling.
-
Why do we care about capture ratio?
-
Commercial considerations when billing for uncaptured cycles. You might worry something is wrong if the capture ratio is low.
-
Might be an opportunity for tuning if below, say, 80%
-
-
What is a reasonable value?
-
Usually 80 – 90. Seeing more like 85 – 95 these days. It has been improved because more of I/O-related CPU is captured.
-
People worry about low capture ratios.
-
Also work is less I/O intensive, for example, because we buffer better
-
-
zIIP generally higher than GCP
-
Do we calculate blended GCP and zIIP? Yes, but also zIIP separately from GCP.
-
Why might a capture ratio be low?
-
Common: Low utilisation, Paging, High I/O rate.
-
Less common: Inefficient ACS routines, Fragmented storage pools, Account code verification, Affinity processing, Long internal queues, SLIP processing, GTF
-
-
Experiment correlating capture ratio with myriad things
-
One customer set of data with z13, where capture ratio varied significantly.
-
In spreadsheet calculated correlation between capture ratio and various other metrics. Used =CORREL(range, range) Excel function.
-
Good correlation is > 85%
-
Eliminate potential causes, one by one:
-
Paging, SIIS poor correlation
-
Low utilisation strong correlation
-
-
It has nothing much to do with machine generation. The same customer – from z9 to z13 – always had a low capture ratio.
-
It got a little bit better with newer z/OS releases
-
Workload mix? Batch versus transactional
-
-
All the other potential causes eliminated
-
Turned out to be LPAR complexity
-
10 LPARs on 3 engines. Logical: Physical was 7:1, which was rather extreme.
-
Nothing much can be done about it – could merge LPARs. Architectural decision.
-
-
-
Lesson: worth doing it with your own data. Experiment with excluding data and various potential correlations.
-
-
Correlation is not causation. Look for the real mechanism, and eliminate causes one by one. Probably start with paging and low utilisation
-
Other kinds of Capture Ratio
-
Coupling Facility CPU: Always 100%, at low traffic CPU per request is inflated.
-
For CICS, SMF 30 versus SMF 110 Monitor Trace: Difference is management of the region on behalf of the transactions.
-
Think of a CICS region as running a small operating system. Not a scalable thing to record SMF 110 so generally this capture ratio is not tracked.
-
-
Summary
-
Don’t be upset if you get a capture ratio substantially lower than 100%. That’s normal.
-
Understand your normal. Be aware of the relationship of your normal to everybody else’s. But, be careful when making that comparison as it is very workload dependent.
-
Understand your data and causes. See if you can find a way of improving it. Keep track of the capture ratio over the months and years.
-
Topics – Hello Trello
-
Trello is based on the Kanban idea: boards, lists, and cards. Cards contain the data in paragraphs, checklist, pictures, etc.
-
Can move cards between lists, by dragging.
-
Templates are handy, and are used in creaing our podcast.
-
Power-ups add function. A popular one is Butler. Paying for them might be a key consideration.
-
Multiplatform plus web. Provided by Atlassian, which you might know from Confluence wiki software.
- Atlassian also make Jira, whch is an Agile Project Management Tool.
-
Why are we talking about Trello?
-
We moved to it for high level podcast planning
-
One list per episode. List’s picture is what becomes the cover art.
-
Each card is a topic, except first one in the list is our checklist.
-
-
Template used for hatching new future episodes.
- But, we still outlining the topic with iThoughts
-
We move cards around sometimes between episodes.
-
Recently more than ever, as we switched Episode 28 and 29, due to the z/OS V2.5 Preview Announce.
-
Right now planning two episodes at once.
-
-
-
Marna uses it to organise daily work, with personal workload management and calendaring. But it is not a meetings calendar.
- Probably with Jira will be more useful than ever. We’ll see.
-
Martin uses it for team engagements, with four lists: Potential, Active, Dormant, Completed.
-
Engagement moves between lists as it progresses
-
Debate between one board per engagement and one for everything. Went with one board for everything because otherwise micromanagement sets in.
-
Github projects, which are somewhat dormant now, because of…
-
Interoperability
-
Github issues vs OmniFocus tasks vs Trello Cards. There is a Trello power up for Github, for issues, branches, commits, and pulls requests mapped into cards.
-
However, it is quite fragile , as we are not sure changes in state reliably reflected.
-
-
Three-legged stool is Martin’s problem, as he uses three tools to keep work in sync. Fragility in automation would be anybody’s problem.
-
iOS Shortcuts is a well built out model. For example, it can create Treello cards and retrieve lists and cards.
- Might be a way to keep the 3 above in sync
-
-
IFTTT is used by Marna for automation, and Martin uses automation that sends a Notification when someone updates one of the team’s cards.
-
Martin uses Pushcut on iOS – as we mentioned in Episode 27 Topics
-
Trello provides a IFTTT Trigger, or Pushcut provides a Notification service, which can kick off a shortcut also.
-
Encountered some issues: each list needed its own IFTTT applet. Can’t duplicate applets in IFTTT so it’s a pain to track multiple Trello lists, even within a single board.
-
-
Automation might be a better alternative to Power-ups, as you can build them yourself.
-
-
Reflections:
-
Marna likes Trello. She uses it to be more productive, but would like a couple more function which might be addded as it becomes more popular.
-
Martin likes Trello too, but with reservations.
-
Dragging cards around seems a little silly. There are more compact and richer ways of representing such things.
-
A bit of a waste of screen real estate, as cards aren’t that compact. Especially as lists are all in one row. It would be nice to be able to fill more of the screen – with two rows or a more flexible layout.
-
-
In closing
- GSE UK Virtual Conference will be 2 – 12 November 2021.
On the blog
- Martin’s posts:
- Marna’s blog has moved to a new location on the new SHARE site
Mainframe, Performance, Topics 