Episode 12 "Baker's Dozen"

Spela upp

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.

Mainframe

Our "Mainframe" topic discussed some fun small enhancements Marna has enjoyed from GRS.

1. 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.
2. With z/OS V2.2, there are two excellent new functions building on OA42221:
   1. SMF 87 subtype 2 records can be written for ENQ/DEQs, and
   2. 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.

Performance

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

Topics

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 recording: Equipment: Headphones and microphones are necessary. Recording programs: We use Skype with plugins to record.
• 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). 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.

Contacting Us

You can reach Marna on Twitter as mwalle and by email.

You can reach Martin on Twitter as martinpacker and by email and blogs at blog.