(Originally posted 2017-04-01.)
This episode came hot on the heels of Episode 11. The next one will be somewhat further away, unfortunately. As usual it was fun to make, though not without its share of technical difficulties. Which is ironic, considering our “Topics” topic.
We’re still playing with the “Zero Indexing” thing, as all good geeks should. 🙂 Hence the title.
Episode 12 “Baker’s Dozen” Show Notes
Here are the show notes for Episode 12 “Baker’s Dozen”. The show is called “Baker’s Dozen” because it is the thirteenth episode, after starting at Episode #0.
Where we’ve been
Martin has not been anywhere since our last podcast.
Marna has not been anywhere, either.
Our “Mainframe” topic discussed some fun small enhancements Marna has enjoyed from GRS.
With OA42221 back to z/OS R13, GRS has the ability to write SMF records (87 subtype 1) to identify heavy users of global generic queue scans. This is what Marna calls a new “monitoring capability”. These issuers might be the cause of increased CPU and GRS private storage. Turn on with GRSCNFxx MONITOR(YES)
- Existing monitoring of ENQ/DEQs at this point, are not written into SMF records. And the only filtering capability at this point is the old “ISGAUDIT” method. “ISGAUDIT” is a where you prepare you filter, assemble and link edit it into load module and then manipulate it with many MODIFY commands. Not very simple for everyone to do.
With z/OS V2.2, there are two excellent new functions building on OA42221:
- SMF 87 subtype 2 records can be written for ENQ/DEQs, and
- a new filtering capability available with parmlib member GRSMONxx. There is no IEASYSxx for GRSMONxx, so you must start it with SETGRS GRSMON=xx. Only one GRSMONxx is allowed per system.
Now, you can get all your “monitoring” into SMF records for both ENQ/DEQs and global generic queue scans. And you don’t need to use the cumbersome ISGAUDIT anymore.
Martin talked about coupling facility structure performance, especially as it concerns DB2 lock and cache structures. Having a lot of structures isn’t a problem, as long as you are looking at how “busy” the coupling facility is – both CPU- and memory-wise.
Sorting in descending order the structures by a metric you want is an important and easy way to figure out which structures to pay attention to.
Balance this with the number of DB2 structures to manage – perhaps hundreds! Some advice was given as to what were the most important metrics to concentrate on.
Looking at “false contentions” and “XES contention” for lock structures is important, and may indicate that these structures need to be larger. Especially if the number of false contentions is high, relative to the lock structure requests.
For cache structures, there are different metrics.
You may have gotten a large number of structures because you are using DB2 data sharing. Look at names and types for a clue as to where they came fromm.
Our podcast “Topics” topic is how the audio for this podcast gets produced. If you are interested in audio editing, here are some items that recording this podcast has uncovered:
For editing process:
Record in chunks, for each podcast section.
Audacity is used for the actual editing. Martin places each speaker on a different side (right or left). Guests might be half-left, half-right, or in the middle. Audacity makes this very easy.
Clean up removes noise, ensures flow, and sound effects are added. Audacity has some nice filters for noise removal, though this isn’t 100% perfect.
As you can tell some “humanity” (mistakes and flubs) is kept in. But hopefully not too much.
Marna and Martin discussed two customer requirements which concern sysplex:
Where We’ll Be
Marna will still be at IBM Systems Technical University in Orlando, May 22–26, 2017.
Martin will be in Chicago, IL USA for pizza in mid April, and he’ll have to make a customer visit while he’s there.
On The Blog
Martin has published one blog post recently:
Marna has finally finished one blog post:
Or you can leave a comment below.