(Originally posted 2009-12-07.)

If you use RMF Postprocessor you won’t see this one. If you use Service Units rather than CPU seconds fields in the SMF 72-3 record you also won’t see it. It’s only if (like me) you use the CPU time for zAAPs in your CPU Utilisation calculation that you’ll run into this problem.

If you examine fields R723IFAT (zAAP CPU Time) and R723IFCT (zAAP on GCP CPU Time) you might find them zero when you don’t expect them to be i.e. when the Service Units analogues (R723CIFA and R723CIFC) are non-zero. IFAT and IFCT are indeed out of line and CIFA and CIFC (and the Workload Activity Report) are correct.

A (sensible) suggested workaround is to use CIFA and CIFC, converting from service units to CPU time.

The answer is to apply the fix for APAR OA29974. I think I’d apply it anyway. It seems like a fairly harmless PTF.

I ran into this because a colleague showed me a Workload Activity postprocessor report with substantial zAAP on GCP time in it, whereas MY code showed zero. (My code was correct but misdirected by the data.) 🙂

Because I can’t control the SMF that customers send me I think I’m going to have to code around this one – if I start seeing this regularly.

(Originally posted 2009-11-30.)

Thanks to Marna Walle for pointing out this change:

In z/OS Release 11 there is a requirement for an additional 1608 bytes of ESQA per address space. To put that in context, I’ll do some obvious maths: That’s about 1.6MB per 1000 address spaces. It just might be of interest to certain customers I know with thousands of CICS regions in a system, or very large TSO or Batch systems. It’s probably not enough to trouble most people. But it reminds me of the importance of having a quick virtual storage check when migrating from one major product release to another.

There are several ways of checking for this particular one:

• You can use Healthchecker VSM_SQA_THRESHOLD check.
• You can process the SMF 78-2 Virtual Storage record.

The latter would be my favourite as using the SMF 78-2 data to look at usage by time of day can show some useful patterns. You might want to review, for example, whether (E)SQA threatens to overlow into (E)CSA. It’s not a big tragedy if that happens but your installation might have views on such things.

(In case you’re unfamiliar with such things the “E” in “(E)SQA” and “(E)CSA” refers to 31-bit areas whereas the names without the “E” refer to 24-bit areas, there being analogues above and below the line for both SQA and CSA.)

One other thing – in case you think ESQA and ECSA are unimportant having very large such areas can impact on the 31-bit Private Area virtual storage picture.

(Originally posted 2009-11-27.)

A new set of function was recently made available for DFSORT via PTFs UK51706 and UK51707.

In this post I want to talk about the new JOINKEYS function, and try to add a little value by discussing some performance considerations. I’ve had the code for a couple of months and have played with it but not extensively. So much of what follows is based on thinking about the function (described in this document) and bringing some of my DB2 experience to bear.

With this enhancement DFSORT allows you to do all the kinds of two-way joins DB2 folks would expect to be able to do – in a single simple operation. "Two way" refers to joining two files together. You can perform e.g. a three-way join by joining two files together and then joining the resulting file with a third. With "raw" DFSORT that would be two job steps. With ICETOOL you can make this a single job step. In any case I think I’d recommend using ICETOOL because converting to ICETOOL later when you find you want to add a third file to the join would be additional work.

How JOINKEYS Works

Before talking about performance let me describe how JOINKEYS works. In JOINKEYS parlance we talk about files "F1" and "F2". Indeed the syntax uses those terms…

• The join itself is performed by the main DFSORT program task. I receives its data through a special E15 exit and processes it like any other DFSORT invocation, with the exception that it knows it’s doing a join. So things like E35 exits and OUTFIL all work as normal.
• Both F1 and F2 files are read by separate tasks. Each of these writes their data using an E35 exit. Normal processing capabilities such as E15 exits (potentially different for F1 and for F2) and INCLUDE / OMIT and INREC processing apply.
• The F1 and F2 tasks and the main tasks communicate by "pipes" constructed between the F1 and F2 E35 exits and the main task E15 exit. These pipes have no depth and don’t occupy significant working memory or any intermediate disk space.

A Potential For Parallelism?

So we have three DFSORT tasks operating in parallel, feeding data through pipes. In principle they could run on separate processors. The extent to which that’s useful would, I think, depend on whether these tasks are performing sorts or just reformatting copies. I say this because in the copy case I’d expect the F1 and F2 tasks to be interlocked with the main task whereas in the sort case there’s stuff to do before we get to writing through the pipes. And in the latter case we’re probably only effectively driving two separate processors. But this is a fine point.

In any case we derive I/O Parallelism because the F1 and F2 tasks run in parallel. Again its usefulness depends on timing.

Managing The Sorts

You can specify whether the F1 and F2 tasks perform a sorts. So you could declare that F1 was already sorted, whereas F2 wasn’t.

You can decide whether DFSORT will terminate if the F1 or F2 files are not in order. (This only applies and makes sense if you’ve claimed the data was already sorted.)

You can specify whether the main task sorts the results of the joined F1 and F2 files.

More on why sort avoidance might be important in a minute.

Join Order

As I mentioned earlier, you can use repeated invocations of JOINKEYS (most readily using ICETOOL) to join more than two files together.

Now this is where some DB2 SQL tuning background comes in handy…

You have a choice which order to join the files in. As this isn’t DB2 you don’t have the Optimizer making such decisions for you. So you have to decide for yourself. But think about it: If you joined a large file to a small file in Step 1 and then joined the large resulting intermediate file to another small file in Step 2 you’ve chucked a lot of data around – twice. If you could arrange to join the large file in Step 2 to the results of joining the small files in Step 1 there would be less data chucking around. It ought to run faster.

Cutting Down The Data

As with all DFSORT invocations, cutting down the data early is important: Joining two large files together, only to throw away large amounts of the result is inefficient: If you can throw away unwanted records on the way in, or can throw away unwanted fields, the join will be more efficient. In the F1 and F2 tasks you can.

In the F1 and F2 tasks you can supply file size estimates – as they each have their own control files – by default “JNF1CNTL” and “JNF2CNTL”. You could do this for the main sort, too. In the F1 and F2 case this is more important when you cut down the files on the way in.

Avoiding Unnecessary Sorts

If you know the files you are joining are already sorted in an appropriate order for the join you can avoid sorts on the way into the join. And this will obviously be more efficient. If you can live with the order DFSORT writes the records from JOINKEYS you can use COPY rather than SORT in the main task.

Memory Usage

In the worst case – where F1 and F2 files are sorted in parallel and where the main task also sorts data – you have the potential for large amounts of memory being necessary. You need to cater for that.

In Summary

I really like this function. It removes the need for much fiddliness – and it does it in a simple way. (I’m conscious I’ve shown no examples but the documentation linked to above is replete with them.)

My perspective is as a performance guy who has some knowledge of how DB2 does joins. This isn’t the same code so the lessons from the DB2 Optimizer have to be applied sparingly. And note we don’t even have indexes on sequential files (though you could simulate an “index scan” by retrieve only the join keys.)

I’d like to do some performance runs that illustrate the points above. I’m a little tight on time right now – so that’ll have to wait. And I’m sure there’s more thinking that could be done on how to tune JOINKEYS invocations.

(Originally posted 2009-11-22.)

Our channel reporting has consisted forever of a single chart. Before I tell you what the chart looked like I’ll hazard that your channel reporting was about as bad. 🙂

See, it’s not something people tend to put much effort into.

Our one-chart report basically listed the top channels, from the perspective of the z/OS system under study, ranked by total channel utilisation descending – as a bar chart. The raw data for this is SMF Type 73. Actually there were two refinements people had made over the decades:

• Someone acknowledged the existence of the (then-called) EMIF capability to share channels between LPARs in the same machine. So stacked on top of this partition’s busy they added other partitions’ busy.
• Someone supported FICON by using the new FICON instrumentation to derive channel utilisation. (Of course if the channel’s not FICON we still use the old calculation: with some smart copying involved.)

And that’s where we left it until I got my hands on the code…

• The first thing I did, some months ago, was to add the channel path acronym (for example “FC_S” for “FICON Switched”). This is also in SMF 73.
• The second thing was much more significant:

  The “other partitions’ busy” number is all other partitions’ use of the channel, without breaking down which other partitions these are.

• The third thing was a nice “fit and finish” item: Listing which controllers were attached to which channel.

Which LPARs Share This Channel

Each z/OS image can create its own SMF 73 records. For me I’m hostage to which systems my clients send in data for. Also I have to cut down the potential LPARs in the data. I do this using the following rules:

• The channel number (in Type 73) has to match.
• For multiple Logical Channel Subsystem (LCSS) machines (System z9 and System z10) the LCSS number must match. (This can be gleaned from Type 73. Actually Type 70 as well – as each LPAR has only one LCSS.)
• The machine serial number has to match. (Machine serial number isn’t in Type 73. You have to go to the Type 70 for it.)
• (I do a “belt and braces” check that the Channel Path Acronym (in Type 73) matches.)

So that set of checks tells you which LPARs really share the channel. And so you can then stack up their utilisations to gain a better picture of the channel. It’s quite nice when you do.

One other thing: Because I don’t necessarily see all the LPARs sharing a channel I compute an “Other Busy” number and add that to the stacked bar. In fact my test data showed all the major channels were missing LPARs’ contributions.

Which Controllers Are Accessed Using This Channel

To me a channel isn’t really interesting until you know what’s attached to it. (In my current set of data my test LPAR’s data shows one group of four channels attached to five controllers and another group of eight attached to two controllers.)

Working out which controllers are attached is quite fiddly:

1. Use SMF 78 Subtype 3 (I/O Queuing) records to list the Logical Control Units (LCUs) attached to this channel.
2. Use some magic code we have to relate LCUs to Cache Controller IDs. Basically it does clever stuff with SMF 74-5 (Cache) and 74-1 (Device) records to tie the two together.

I made a design decision not to annotate the graph with LCU names as there are usually many in a Cache Controller. It would be very cluttered if I had. (I do have another report that lists them and the channels attached to them.) Instead I list the Cache Controller IDs. You can probably relate to Controller IDs. If we’ve done our homework (and as we use your cache controller serial numbers we generally have) you’ll recognise the IDs.

So, if you’re one of my customers and I throw up a chart that shows channels and systems sharing them and the controllers attached it may look serene and slick. But believe me, there’s a lot of furious paddling that’s gone on under the surface. 🙂

But I tell you all this in case you’re wondering about how to improve your channel reporting. And I still think there’s more I can do in this area – particularly with the (more exotic) SMF 74-7 record, which brings FICON Director topology into play. And everything I’ve said above applies equally to whichever tools you use to crunch RMF SMF, I’m quite sure.

(Originally posted 2009-11-09.)

There’s a pattern I’ve seen over a number of test Parallel Sysplex environments over the past few years, a couple of them in situations this year:

It’s not much use drawing performance inferences from test environments if they’re not set up properly for performance tests.

Sounds obvious, doesn’t it?

There are two problem areas I want to draw your attention to:

1. Shared Coupling Facility Images
   
   If you run a performance test in an environment with shared coupling facility images you stand to get horrendous request response times and the vast majority of requests going async (given a chance). I’ve even seen environments where XCF refuses to use coupling facility structures and routes ALL the traffic over CTCs. (And I’ve seen a couple of environments where there are no CTCs to route it over and XCF traffic is then reduced to a crawl.)
2. "Short Engine" z/OS Coupled Images
   
   In a recent customer situation I saw the effect of this: The customer was testing DB2 Loads where actually it was a bunch of SQL inserts. They were also duplexing the LOCK1 structure for the data sharing group. The Coupling Facility setup was perfect, but still response times became really bad once duplexing was established for the LOCK1 structure. Two salient facts: Because of duplexing all the LOCK1 requests were async. XCF list structure request response times were always awful.
   
   The answer to why this problem occurred lies in understanding how async requests are handled: The coupled z/OS CPU doesn’t spin in the async case. In the "low LPAR weight relative to logical engines online" case the z/OS LPAR’s logical engines were but rarely dispatch on physical engines. This meant there was a substantial delay in z/OS detecting the completion of an async request. Hence the elongated async response times. As I said, the LOCK1 structure went async once it was duplexed.
   
   As it happens the physical machine wasn’t all that busy: Allowing the LPAR to exceed share – using a soaker job – ensured logical engines remained dispatched on physical engines longer. And, perhaps paradoxically, the async request response times went right down. This, I hope, reassured the customer that in Production (with "longer-engine" coupled z/OS LPARs) async coupling facility response times ought to be OK.

Now, this is just Test. But it could unnecessarily freak people out. But, hopefully, it’s easy to see why Test Parallel Sysplex environments might perform much worse tan Production ones.

(I’m guessing you’re going "duh, I knew Test would be worse than Prod". 🙂 But these two cases are specifics of why Test might be even worse compared to Prod than expected.)

Anyhow, I thought they were interesting. And I have seen 1. quite a few times now. 2. not so much, in fact only once so far.

(Originally posted 2009-11-08.)

I’ve just submitted a set of slides to Slideshare. They’re not mine, they’re not new, they’re not even in a modern format. But they are a very good presentation worth preserving…

In 1993 Curt Cotner presented a set of slides on the new DDF Inactive Thread support in Version 3 of DB2. It’s still highly relevant and this support was the base on which the Version 4 WLM classification line item was built.

You can find the slides here.

I’d also recommend you went on to read John Arwe’s paper on Preemptible-Class SRBs.

(Originally posted 2009-11-08.)

Apologies for being away. For a while I couldn’t get the blog to operate – as an author. And then I gave up trying. 😦

Count this as a "testing 1-2-3" post but also as notice I intend to back with more (hopefully useful) content soon. MUCH has happened in the "intermission". 🙂

(Originally posted 2009-05-07.)

I’m reporting what I’m learning (or I think is significant) in conference sessions on Twitter. My Id is “MartinPacker” and I’m using the Hashtag “#zOS09” to tag my posts. Feel free to follow along. In principle you don’t even need to sign up to Twitter to do this.

It seems more immediate than posting here.

Oh, and feel free to comment on Twitter using the same tag.

(Originally posted 2009-04-26.)

Here’s another “For Beginners” post to encourage people to just leap in and try it…

Javascript is a language popularly used for such things as web pages with some programming in them (and that includes frameworks like dojo), building Firefox extensions, and the Adobe AIR (desktop) runtime. As it happens I’m pretty familiar with Javascript anyway – having done all 3 of the above. This post shows how I got it to run on z/OS using Mozilla’s Rhino…

Mozilla’s Rhino project is a javascript interpreter written in java. (Java 6 does in fact have a general-purpose scripting interface – with javascript as a prime target.) It’s important to note that Rhino requires Java 5.

So here’s what I did…

1. Downloaded the Rhino package to my PC from here.
2. Unpacked it on my PC using a Zip tool (in my case 7-Zip).
3. Tested it out on my PC – just to get comfortable with how it worked (and that was well worth the half an hour it took).
4. FTP’ed binary the included js.jar file to an HFS file (in my case /u//rhino/js.jar). The file was under 1MB in size.
5. Adjusted my CLASSPATH to point additionally to js.jar (including js.jar explicitly, not just the directory it was in).
6. Invoked Rhino in interactive mode:

   java org.mozilla.javascript.tools.shell.Main

7. Typed in a few javascript statements such as

   print(1+2)

8. Quit by typing “quit()”

You can pass the name of a javascript file to Rhino by adding eg “test.js” to the command to invoke it.

In my case I also used the “.profile” startup script to adjust my CLASSPATH and to alias “js” to mean “run the Rhino javascript interpreter”.

So, it’s actually VERY straightforward to run Javascript under z/OS – thanks to Rhino. (And I suspect anyone with Java 6 installed would find it even easier.)

As always, if you know better please feel free to comment here. Remember, I’m learning as I go, and I just want to encourage others to try a few things.

(Originally posted 2009-04-25.)

In this post (and any others in a similar vein) I'm going to be displaying a great deal of ignorance – but I think I'm doing it in a good cause.

I know a fair amount about things like Java, XML and C++ – but NOT on z/OS. So I'm determined to learn and present what I learn as "For Beginners" posts here.

The idea is that I'll encourage other people with more traditional z/OS skills to try some simple new things, such as java. So, if you've not done these things before do have a go. Stuff is remarkably straightforward to do.

Here's how I created a simple "Hello World" java application in Unix System Services.

1. Log onto TSO with a region of 64MB (64000 in the logon panel). When I tried this with 32000 I got a "JVMDBG001" message, complaining of not being able to GETMAIN enough memory to start the JVM (but the JVM started anyway).
2. Type OMVS. (If your userid has been set up to use Unix System Services it should start you in a directory (mine being "/u/userid").
3. Create a subdirectory using "mkdir javatest".
4. Change to this subdirectory using "cd javatest".
5. List what's in this subdirectory (actually nothing) using "ls".
6. Create a new java source file using "oedit Hello.java".
7. While in the (ISPF) Editor add the following lines:

   
   public class Hello{
     public static void main(String args[]){
       System.out.println("Welcome!");
     }
   }
   
   

8. Press PF3 to save. (Treat the resulting dialog as any "leaving ISPF" dialog.)
9. Compile the resulting java with "javac Hello.java".
10. Run the compiled java bytecode with "java Hello".

And that's all there is to it. One note – if you're not familiar with java: Case is significant. Mismatches would cause problems.

The java book I used to get started (and then some) was Deitel & Deitel's "Java How To Program" but there are lots of them to choose from.

If you're more experienced at this than me please feel free to comment as you see fit. But remember this is a "For Beginners" post. I'm trying to encourage people to GET STARTED.