Here are the show notes for Episode 13 "We'll Always Have Paris". The show is called this because both Marna and Martin reminisce about lovely times in the City of Light.

Where we've been

Martin has been to Chicagoland to visit a customer, and partake in the local victuals.

Marna has just returned from vacation (hence, the title and Topics topic on Paris).

Mainframe

Our "Mainframe" topic discusses what has been a popular item since more people have finished migrating to z/OS V2.2: GDGEs.

Generation Data Group Extended (GDGEs) were introduced in z/OS V2.2, and should only be used after fully migrated to that release everywhere. "Old" GDGs allow >255 generations. GDGEs allow up to 999, but with a very different internal structure. GDGEs are externally usable transparently.

There is no straightforward conversion way in DFSMS. Steve Branch (alias name of "Mr. Catalog") and Marna had a six step JCL job to convert (which used IDCAMS ALTERs), and would work if the generations were SMS-managed, which was the initial use case.

A nice customer used our original six-step JCL, but didn't work for him. His use case was non-SMS GDGs on tape. Back to the drawing board, and with more test cases.

• Problem was IDCAMS ALTERs, as didn't handle non-SMS managed GDG (with IDC3009I). Steve thought that replacing them with TSO/E RENAMEs might be better. But tape would still be a problem.

Steve's thoughts on why a DFSMS utility to convert is difficult: GDGE internal record design does two things: makes the Generation Aging Table limit field 2 bytes (instead of 1) and removes the concept of GDG sub-records which were present in GDG.

• For Steve to handle the conversion in DFSMS, there are important worries about backout and failures if the conversion didn't complete successfully. And these worries happen at three different points a when it comes to the steps in the necessary conversion. He mentioned that a recovery might look something like a full volume dump and restore if there were problems, which is not palatable in many cases.

• And because so many ask: the limit is 999 because it was the largest number that JCL could handle without making changes which might have been incompatible. (Incompatibility brings Marna to your office for a personal deskside chat about z/OS migration.)

Tests ran for three cases with the new TSO/E RENAME flavor: combos of NON-SMS/SMS, and DASD/Tape:

• NON-SMS/DASD was a success, and SMS/DASD (but migrated data sets were recalled!) was a success.

• NON-SMS/TAPE: failure because it is not on DASD. However, a solution could be constructed whereby:

  • write some REXX to produce JCL that would individually: uncatalog the tape GDG generations,

  • delete the GDG base, define it as a GDGE, recatalog all the tape generations as GDGE.

  • Doable, but with work...but might be worth it for 999 generations!

This nice customer, however, has followed up with me and has offered the share the REXX to do just that. All JCL and REXX discussed can be found here: Marna's Blog.

Mainframe Summary

• You can do the conversions for your GDGs to GDGEs, but you need to decide if it's worth it.

• The TSO/e RENAME will work in all the cases that IDCAMS ALTER would, plus more.

• The shared REXX exec can be used if you want to convert NON_SMS/TAPE GDGs to GDGEs.

• Still, if you have a gazillion references in places like JCL, it is a compelling case to take some extra one-time work and do the conversion.

• Mind the recalls! You'll need a lot of recall space on DASD, if you are recalling lots of data sets and they are large.

Performance

Martin talked about a presentation he's been keeping updated, Even More Fun With DDF. The original presentation covered:

• why you should care about DDF,
• LPAR to Service Class Level views,
• side themes of zIIP and DB2 address spaces, and a discussion of SMF 101 and DDF.
• Contains three different customer cases: some basic statistics, a CPU Spike case, and "sloshing".

The updated presentation has:

• SMF 30 Enclave Statistics graphing

• Thoughts on handling clients with huge numbers of short commits

• Matching client and server DB2 101s where DB2 to DB2 DDF

• Production vs Feral DDF

• Diagrams of machines connecting to DB2 via DDF

An analysis is done using RMF and SMF 30, and SMF 101 DB2 Accounting Trace, using special code written by Martin:

• DFSORT WITH E15 To select and "flatten" DDF 101s

• DFSORT and a small amount of REXX to run queries

  • From hours to seconds level granularity

  • From subsystem to client software / hardware / userid granularity

• Might generally be useful, contact Martin if you want to chat about it.

Performance summary

• Last year's presentation significantly extended, with experience and better tooling.
• Most likely more will be coming.
• Look at DDF: remarkably interesting topic and an important one

Topics

Our podcast "Topics" topic was Paris and visiting it. Marna just got back from Paris with her son (the one that built his own gaming computer). They discuss what they like to do there.

• Sites:

  1. Martin loves to go to the museums. Especially the Louvre and Beaubourg. He could spend all day in the Louvre.
  2. Marna's son doesn't like museums, so they visit other spots like the Catacombs (with a four hour wait!) and the gargoyles at Notre Dame (only a two hour wait).

• Food: Marna and her son focus on cheese, and have become quite adept at all three raclette contraptions available: pans, "two winged panels", and "up/down lever". Of course, these are not the official names, but they are the best describers of the method to scrap all the cheese you can onto your plate.

• Getting around: Martin loves the metro, which is so easy and convenient. He loves the part on the metro when you come out from underground to the raised tracks in some places. Marna did a lot of walking. (Fitbit while at Versailles registered 31k steps = 13. miles = 22 km.)

• At Versailles: lots of walking, especially if you go all the way out to Marie Antoinette's "farm" with goldfish...or is that carp ? You can decide.

• Pro Tips: Use the "skip the line" and make reservations very early. Buy tickets early online too. Use the available apps too (like for Versailles ). Check the schedule for when the Versailles fountains are on.

Where We'll Be

Marna will be at IBM Systems Technical University in Orlando, 22-26 May 2017.

Martin will be at GSE UK zCMPA 18 May, 2017

On The Blog

Martin has published two blog posts recently:

• Automatic For The Person

• Back To Machines

Marna had this prior blog from 28 March 2017, which this Mainframe Topic was based on:

• GDG to GDGE conversions

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.