Mainframe, Performance, Topics

Episode 17 is about the new z/OS V2.3 RACF parmlib member IRRPRMxx, and digging into whether two LPARs (or 2 CECs) or four LPARs (on 2 CECs) is better. Our Topic is a one year followup on a gamer's personal computer, and how he fixed a wifi problem.

Marna and Martin discuss Coupling Facility encryption, CPU fields for pricing, and adding chapter markers to mp3 files.

Here are the show notes for Episode 16 "Chapter and Worse". The show is called this because our Topics topic is about adding chapter markers (and pictures!) to our published MP3 file. We hope those of you that can see them enjoy them.

Where we've been

Marna has just returned from conferences and events in Johannesburg ZA, Chicago IL, and Munich Germany.

Martin has been to Munich Germany, and also visited a customer in Siena Italy.

Feedback

We have received feedback (in person, in Munich!) that our stereo separation of the channels was a little dizzying. Martin will be trying to make it less severe to relieve this effect.

Thanks for the feedback; We want to hear more!

Follow Up

Martin and Marna talked to the developers of the DocBuddy app, about their new release.

The latest release is 2.0.1, and has added a lot of social aspects (and fixed reported problems). The ability to look up messages is still there, but z/OS V2.3 isn't there yet. We anticipate it will be coming soon, though, as it is important.

You can sign into the app (very easy to do!), and subscribe to Products and People, and discover them. People are "Influencers" and can be subscribed to. Products doesn't include all the core z/OS elements, but Communications Server is there and has been active.

Feedback can be given, it's an email under "Settings", which took us a while to find.

Mainframe

Our "Mainframe" topic discusses a new z/OS V2.3 function, Coupling Facility Encryption, with Mark Brooks, Sysplex Design and Development. Mark talked about this latest capability in Sysplex, which has been getting a lot of attention as part of the larger Pervasive Encryption direction.

Mark explained that CF Encryption means that the customer's data is encrypted by XCF in z/OS, sent along the link as encrypted, and stored as encrypted on the Coupling Facility.

z/OS sysprog needs to set it up by:

• using new keywords on CFRM policy on a structure by structure basis

• putting it in your CFRM couple data sets, and the policy change will be pending

• rebuild the struture (to get it from unencyrpted to encrypted)

• DISPLAY XCF structure commands can be used to see what the policy has, what the structure currently is, and the form of encryption used.

List and Cache structures contain customer sensitive data, the XCF control information will not be encrypted because it is not sensitive customer data. Lock structures don't contain sensitive customer data, and are not encryptable.

Software requirements:

• z/OS V2.3. Strongly recommend not using CF encryption in production until fully at z/OS V2.3.

• ICSF. Need to have ICSF to generate keys and talk to the crypto cards. Every system in sysplex needs to be running with the same AES master key (meaning, same PKDS), note this requirement!

• XCF generates the key from ICSF services and stores that wrapped key inside the CFRM couple data set.

Hardware requirements:

• CPACF

• Encryption is performance sensitive, because it is extra work to encrypt and decrypt.
  You want it to be executed quickly. Encryption is host-based, and zEC12 has these facilities, however the older machines are not as fast as a z14. Take that into consideration.

Tooling:

• zBNA looks at new SMF data, so that you can see the amount of data transferred to the CF. From there, you could judge the cost of doing the encryption.

• SMF 74 Subtype 4 records contain the new information on the amount of data, via measurement APAR OA51879 on z/OS V2.2. Planning can begin on z/OS V2.2 with this APAR.

For more information, see the z/OS Setting Up a Sysplex.

Performance

Martin talked about MSU-related CPU fields for doing software pricing analysis. Some of these fields are used by SCRT in support of the new Mobile function.

Most notably the fields cover:

• Mobile Workload Pricing (MOBILE), using a new WLM mechanism, is available to many customers today. (The old way of doing Mobile Workload Pricing has been around for quite a long time.) Note a misrecording of IMS Mobile CPU at the Service Class Period level, which is fixed in IMS V15 APAR PI84889 and IMS V14 APAR PI84838.

• CATEGORYA and CATEGORYB: These are just placeholders for any future additional pricing options that come about.

These categories of CPU/MSUs are brought to life using the Workload Manager ISPF panels, using a new reporting attribute. You scroll twice to the right to get there. The values in the field can be MOBILE, CATEGORYA, or CATEGORYB.

Container Pricing is another pricing model, ....., and maybe another topic on that later.

The overall idea: Be aware of the new fields that you will be analysing. These fields are available at two levels:

• At the System level, as Rolling 4 Hour Average numbers - in SMF 70 Subtype 1.
• At the Service Class Period level, as interval-based numbers - in SMF 72 Subtype 3.

Topics

Our podcast "Topics" topic is about adding chapter markers to the MP3 file for podcast apps. This makes it nice to skip from one section to another easily. Our podcast has five sections, each with its own graphic and chapter.

Copyright on the MP3 specification expired finally in 2017, allowing more things to be done with the format. Chapters is one of them.

Martin adds the chapter markers into the MP3 file after doing the audio editing with Audacity. He then takes the MP3 file, and runs it into another tool on iOS called Ferrite. Audacity doesn't have the ability to mark chapters (or to add the graphics), but Ferrite does. Hence it has to be processed with this second program to give the final MP3 chapters and graphics! (Ferrite was among the first tools to support Chapter Markers, with or without graphics.)

On Martin's iOS podcast app, Overcast, he sees the chapter markers and graphics fine.

Marna uses Android and CastBox, in which she cannot see them. She then tried another Android app, PodcastAddict, which claimed to have chapter support, and yet she still doesn't see them. So it goes. :-)

Customer Requirements

RFE 100505 Specify DSN HLQ for Healthchecker Debugging

The quoted description is: When the Healthchecker DEBUG option is turned on, the Healthcheck needs to write to a dataset. If that HLQ is not defined to security (in the case of Top Secret), the Healthcheck will fail. The customer then has to get this HLQ defined and appropriate access granted. I would like the customer to have the ability to control the DSN that the Healthcheck writes to.

Our discussion:

• Those checks which are added by the check writer themselves, usually during initialization with HZSADDCK service, set the HLQ. Right now, these checks are not changable by the user for DEBUG, which is what the requirement is all about.

• Sounds helpful, and desirable to have control of the high level qualifier(s) of the data sets. We agree.

• A likely solution would be to put it in HZSPRMxx, and allow the customer to control it (hopefully) across several checks.

Where We'll Be

Martin will be in Whittlebury UK 7-8, November for GSE UK.

Marna will also be in Whittlebury UK 7-8, November for GSE UK with Martin. Then, at the big IBM Z event Systems Technical University in Washington, DC, 13-17 November. Then, in Milan, Italy 28-29 November for a System Z Symposium.

On The Blog

Martin published one blog post, which highlights a screencast of his:

• Screencast 11 - DDF Spikes

Marna has an idea for a blog, but needs more time to do some testing for it. It will be coming!

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.

Marna and Martin talk about Automatic Version Filesystem Unmount, LPAR weight and logical engine maintenance, and screencasts.

Here are the show notes for Episode 15 "Waits and Measures". The show is called this because our Performance topic is about LPAR weights, and because this episode was after a seasonal hiatus.

Where we've been

Martin has been to nowhere in person, but has talked on the phone to several interesting locations.

Marna has just returned from SHARE in Providence, RI and from Melbourne, Australia for conferences.

Mainframe

Our "Mainframe" topic discusses a small new function in z/OS UNIX that there were customer requirements for, and that might not have been highlighted as much as other new functions in z/OS V2.3: automatic unmount of the version "root" file system in a shared file system environment. Our guest was Barry Lichtenstein, the developer of the function, and he told us all about it:

• there is a new BPXPRMxx VERSION statement parameter, UNMOUNT. This means that when no one is using that "version file system" (the new name for the "version root file system"!), it will be automatically unmounted. This is not the default. Syntax here
• this function is nice, as it will allow an unused version file system to be "rolled off" when you don't need it anymore. Unused here, means that no system is using it or using any file system mounted under it. z/OS UNIX will do this detection automatically, and unmount not just the version file system, but mounted file systems under it that are no longer used by any systems after an unspecified amount of time.
• you can turn this on and off dynamically with a SET OMVS or SETOMVS command. There is DISPLAY command support of it. And perhaps the best news, the health check USS_PARMLIB will see if the current settings don't match the used parmlib specification. (Marna thinks this check is the gold standard for using dynamic commands and not regressing them on the next IPL with the hardened parmlib member!)
• we weren't sure if SMF record 92 would be cut when the unmount happened, but Barry said nothing unique was happening for this function so what happens today is most likely the same behavior. There are messages that are issued in the hardcopy log when the unmounts happen. SMF 90 might be issued for SET changes.

Performance

Martin talked about Weights and Online Engines in LPARs, and Martin again looking at customer information.

• Intelligent Resource Director (IRD) changed PR/SM worked:
  1. Dynamic weight adjustment
  2. Online logical engine management (vary online and offline). Shows minimum and maximum weights when changed by IRD.
• HiperDispatch: took away logical engine management (and manages it better!), and kept IRD dynamic weight adjustment. With HiperDispatch's parking of engines, no work is directed towards it. An affinity node is a small group of logical engines to which a subset of the LPAR's work is directed.
• More instrumentation was introduced, such as Parked Time and refined instrumentation on weights (vertical weights, by engine).
• Customer situation was that they did their own version of IRD and HiperDispatch: Varying logical engines online and varying weights (not using IRD itself). Martin expected IRD to change weights, but he saw the IRD weight fields were all zero. You must look at the "inital weights", which means initial since you last changed it.
• Why not let IRD do it? Martin thinks there was something in the customer's mind to control it themselves, perhaps somethind other than WLM goal attainment (which IRD would adjust weights for).
• Why not use HiperDispatch? Martin thinks that maybe a subtle difference might be needed, but LPARs should be designed properly. One possible aim might be to fit in one drawer, for instance. Maybe it's not understanding what HiperDispatch does.
• How did the customer adjust the weights? It was an open question. Probably via BCPii? Feedback would be welcome on this.
• As an aside, with IRD a change in weights would lead to HiperDispatch recalculating how many Vertical High, Medium, and Low logical engines each LPAR has.

Lesson learned: Assumption on how something has dynamically changed may not always be correct.

Topics

Our podcast "Topics" topic was "Video Killed the Radio Star?" and about screencasting.

Martin has been trying to post screencasts to YouTube. Here's one.

Screencasts are not videos where you see the speaker. It's just a visual of what is happening on a screen with a talkover.

The best candidates are graphs and program output. Martin uses these steps to create these screencasts:

1. First, make a set of slides or images. Annotations are good to use, to point to a particular feature on the screen. (They don't have to be animated.)

2. Use the screen recorder to add sound to the slide. (In PowerPoint, record the slides.)

3. Editing, with proper fadeouts. Split the audio out and clean it up with Audacity.

4. Re-unite the audio and the video. Camtasia, while expensive, has some promise.

5. Publish on Youtube.

Customer Requirements

As well as Barry's mention on the z/OS V2.3 automatic unmount of version file system requirement (RFE Number 47549, "Automatic disposal of z/OS UNIX version root"), there was another customer requirement we discussed:

RFE 97101 Make /dev/random available on z/OS without ICSF dependency

The quoted description is:

/dev/random is a special file that serves as a psuedo-random number generator source for applications. On z/OS, this special file is only provided if ICSF is started. If ICSF is not available, we need to resort to some other source of random numbers (which will have to be implemented within applications). Goal here is to make /dev/random available on z/OS, independently of whether ICSF is available or not.

Our discussion:

• It's a major migration action in z/OS V2.2 to have ICSF available for /dev/random.
• ICSF is a dependency for many functions. It's important to have on every single z/OS system.
• Another aspect: each user had to have authority to use these ICSF services for certain of the functional depedencies (including /dev/random).

Martin mentioned that random number generators vary in quality, and behaviour. He hopes, if this were done, it would be high quality. One criterion would mean a close enough match to the ICSF-based algorithm, distributionwise.

Where We'll Be

Martin will be in middle of Italy in August, 2017. He is threatening to drive from Italy to the Munich zTechU conference.

Marna will also be in Munich too. Marna is going to Johannesburg for the IBM Systems Symposium, aka IBM TechU Comes to You. She is also going to Chicagoland area on Sept 26 and 27, 2017 for some area briefings.

Both Martin and Marna are hoping to do a poster session in Munich, which should be jolly good fun.

On The Blog

Martin has actually not published a blog recently!

Marna actually did publish a blog recently!

• Some handy z/OS V2.3 and z14 information

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.

Here are the show notes for Episode 15 "Waits and Measures". The show is called this because our Performance topic is about LPAR weights, and because this episode was after a seasonal hiatus.

 

Where we've been

Martin has been to nowhere in person, but has talked on the phone to several interesting locations.

Marna has just returned from SHARE in Providence, RI and from Melbourne, Australia for conferences.

Mainframe

Our "Mainframe" topic discusses a small new function in z/OS UNIX that there were customer requirements for, and that might not have been highlighted as much as other new functions in z/OS V2.3: automatic unmount of the version "root" file system in a shared file system environment. Our guest was Barry Lichtenstein, the developer of the function, and he told us all about it:

• there is a new BPXPRMxx VERSION statement parameter, UNMOUNT. This means that when no one is using that "version file system" (the new name for the "version root file system"!), it will be automatically unmounted. This is not the default. Syntax here
• this function is nice, as it will allow an unused version file system to be "rolled off" when you don't need it anymore. Unused here, means that no system is using it or using any file system mounted under it. z/OS UNIX will do this detection automatically, and unmount not just the version file system, but mounted file systems under it that are no longer used by any systems after an unspecified amount of time.
• you can turn this on and off dynamically with a SET OMVS or SETOMVS command. There is DISPLAY command support of it. And perhaps the best news, the health check USS_PARMLIB will see if the current settings don't match the used parmlib specification. (Marna thinks this check is the gold standard for using dynamic commands and not regressing them on the next IPL with the hardened parmlib member!)
• we weren't sure if SMF record 92 would be cut when the unmount happened, but Barry said nothing unique was happening for this function so what happens today is most likely the same behavior. There are messages that are issued in the hardcopy log when the unmounts happen. SMF 90 might be issued for SET changes.

Performance

Martin talked about Weights and Online Engines in LPARs, and Martin again looking at customer information.

• Intelligent Resource Director (IRD) changed PR/SM worked:
  1. Dynamic weight adjustment
  2. Online logical engine management (vary online and offline). Shows minimum and maximum weights when changed by IRD.
• HiperDispatch: took away logical engine management (and manages it better!), and kept IRD dynamic weight adjustment. With HiperDispatch's parking of engines, no work is directed towards it. An affinity node is a small group of logical engines to which a subset of the LPAR's work is directed.
• More instrumentation was introduced, such as Parked Time and refined instrumentation on weights (vertical weights, by engine).
• Customer situation was that they did their own version of IRD and HiperDispatch: Varying logical engines online and varying weights (not using IRD itself). Martin expected IRD to change weights, but he saw the IRD weight fields were all zero. You must look at the "inital weights", which means initial since you last changed it.
• Why not let IRD do it? Martin thinks there was something in the customer's mind to control it themselves, perhaps somethind other than WLM goal attainment (which IRD would adjust weights for).
• Why not use HiperDispatch? Martin thinks that maybe a subtle difference might be needed, but LPARs should be designed properly. One possible aim might be to fit in one drawer, for instance. Maybe it's not understanding what HiperDispatch does.
• How did the customer adjust the weights? It was an open question. Probably via BCPii? Feedback would be welcome on this.
• As an aside, with IRD a change in weights would lead to HiperDispatch recalculating how many Vertical High, Medium, and Low logical engines each LPAR has.

Lesson learned: Assumption on how something has dynamically changed may not always be correct.

Topics

Our podcast "Topics" topic was "Video Killed the Radio Star?" and about screencasting.

Martin has been trying to post screencasts to YouTube. Here's one.

Screencasts are not videos where you see the speaker. It's just a visual of what is happening on a screen with a talkover.

The best candidates are graphs and program output. Martin uses these steps to create these screencasts:

1. First, make a set of slides or images. Annotations are good to use, to point to a particular feature on the screen. (They don't have to be animated.)

2. Use the screen recorder to add sound to the slide. (In PowerPoint, record the slides.)

3. Editing, with proper fadeouts. Split the audio out and clean it up with Audacity.

4. Re-unite the audio and the video. Camtasia, while expensive, has some promise.

5. Publish on Youtube.

Customer Requirements

As well as Barry's mention on the z/OS V2.3 automatic unmount of version file system requirement (RFE Number 47549, "Automatic disposal of z/OS UNIX version root"), there was another customer requirement we discussed:

RFE 97101 Make /dev/random available on z/OS without ICSF dependency

The quoted description is:

/dev/random is a special file that serves as a psuedo-random number generator source for applications. On z/OS, this special file is only provided if ICSF is started. If ICSF is not available, we need to resort to some other source of random numbers (which will have to be implemented within applications). Goal here is to make /dev/random available on z/OS, independently of whether ICSF is available or not.

Our discussion:

• It's a major migration action in z/OS V2.2 to have ICSF available for /dev/random.
• ICSF is a dependency for many functions. It's important to have on every single z/OS system.
• Another aspect: each user had to have authority to use these ICSF services for certain of the functional depedencies (including /dev/random).

Martin mentioned that random number generators vary in quality, and behaviour. He hopes, if this were done, it would be high quality. One criterion would mean a close enough match to the ICSF-based algorithm, distributionwise.

Where We'll Be

Martin will be in middle of Italy in August, 2017. He is threatening to drive from Italy to the Munich zTechU conference.

Marna will also be in Munich too. Marna is going to Johannesburg for the IBM Systems Symposium, aka IBM TechU Comes to You. She is also going to Chicagoland area on Sept 26 and 27, 2017 for some area briefings.

Both Martin and Marna are hoping to do a poster session in Munich, which should be jolly good fun.

On The Blog

Martin has actually not published a blog recently!

Marna actually did publish a blog recently!

• Some handy z/OS V2.3 and z14 information

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.

 

Marna Walle and Martin Packer's "Mainframe, Performance, Topics" podcast episode 14: a deep dive into z/OS V2.3 Part 1, Parallel Sysplex CF and XCF Signaling, and Podcast Meets Podcast.

See all episodesSubscribe on iTunesSubscribe on Google Play MusicSubscribe by email

Also available on your favorite Android podcast app.

Here are the show notes for Episode 14 "In the Long Run". The show is called this because the episode ran much longer than usual, and it is of fitting length if you have a very long commute.

Followups

Martin has two new blog posts about DDF (DB2's Distributed Data Facility), following up on Episode 13 where he talked about recent DDF analysis enhancements:

• A Tale Of Two Batteries
• Happy Days Are Here Again?

(Follow Up is of course an invention of John Siracusa.) :-)

Where we've been

Martin has been to London (to the UK GSE zCMPA User Group) to present his ever-updated DDF presentation, and had more fun with it. Marna has been to the Systems University in Orlando, Florida (May 22, 2017 week).

Mainframe

Our "Mainframe" topic is the first in a series of deep dives into z/OS V2.3. Part 1 is on z/OSMF Autostart. This is the most important migration action in z/OS V2.3, and requires special consideration by every customer IPLing z/OS V2.3. Things that you'll need to consider are:

• Whether to start z/OSMF or not. (Starting is the default). You control this via IZUPRMxx parmlib members (which in new news can be shared via PI82068).
• If you don't start z/OSMF and have its functions available to system(s), then you not be able to use certain functions (notably in z/OS V2.3: JES2 Notification).
• If you don't want to start z/OSMF on a certain system, you can connect to another z/OSMF system in the same sysplex, and that requires specification on which group that would be.
• The number of z/OSMF servers in a sysplex hasn't changed, still as it was before V2.3.
• z/OSMF server starting on an LPAR with good zIIP capacity, and memory (minimum of 4GB) is a starting consideration.
• Strong recommendation: start z/OSMF now on your V2.1 or V2.2 system so that there are fewer work items to do (a couple of security profiles, new procs, parmlib updates only).

Performance

In our "Performance" topic Martin talked about two Parallel Sysplex items that he's been pondering extensively recently. He's been using RMF data (taken from SMF type 74 subtype 2 and 4).

Coupling Facility

This is the subject of a blog post: Some Parallel Sysplex Questions, Part 1 - Coupling Facility

• Resources: CPU, memory, and path
• Structures: their role to applications, and how responsiveness responds to work load is interesting

XCF Signalling

This is the subject of another blog post: Some Parallel Sysplex Questions, Part 2 - XCF

• Resources: Paths, buffers, and transport groups
• Groups: again, knowing the application types, with the theme of managing traffic down when possible

Topics

Our "Topics" topic is subtitled "Podcast meets Podcast" with the newest mainframe podcast we know: Terminal Talk. Frank De Gilio and Jeff Bisti are the hosts, and concentrate on a wider introductory perspective than our MPT podcast does.

• Terminal Talk (TT) has enviable technology for recording, and came about from Frank and Jeff taking long car rides to Pennsylvania.
• Planning for the TT podcast consists mostly on engaging guests, and not necessarily following an outline.
• Length is a big consideration: TT is intended to be of a work-commute length.
• Editing is done with Audacity, just like our MPT podcast. TT records mono. MPT does stereo. Martin uses the Audacity waveform visualisation when editing; Hence the terms "um fish" and "so so birds". :-)

We had great fun talking to Frank and Jeff; Martin left some of the laughs in the final edit. And we're sure a lot of you will enjoy Terminal Talk, having listened to all their episodes so far.

Customer Requirements

Marna and Martin discussed three customer requirements:

• DSS needs to support Extended TIOT
• Update of an OpenSSH
• Option to suppress override messages from SMFLIMxx on z/OS 2.2

Where We'll Be

Marna will be at SHARE in Providence, RI, 7-11 August 2017 and IBM Systems Symposium, 15-17 August 2017 in Melbourne, AU Martin will be going nowhere for a while.

On The Blog

Martin has published six blog posts recently. The two not already mentioned are:

• Give Me All Your Logging
• Some Lessons On DFSORT Join

Marna has not blogged since our last podcast episode.

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.

Marna Walle and Martin Packer's "Mainframe, Performance, Topics" podcast episode 13, on GDGE conversions, new fun with DDF, and traveling to the City of Light.

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.

Marna Walle and Martin Packer's "Mainframe, Performance, Topics" podcast episode 12, on two nice GRS goodies, CF structure performance, and doing audio editing for this podcast.