1. Cheryl’s Hot Flashes #26
2. Update on z/OSMF
3. SHARE in Orlando
1. Cheryl ‘s Hot Flashes #26
You probably know that I give a presentation on the last day of every SHARE confer-ence called “Cheryl’s Hot Flashes.” This was my 13th year of giving these sessions where I bring up a few tidbits from our past Tuning Letters, along with new things I’ve learned. I usually expand on the new items in the next Tuning Letter. You can find the most recent Hot Flashes at www.watsonwalker.com/presentations.html.
If you attended my presentation at SHARE, I need to correct something I said about z/OSMF, where I surmised that its high CPU time might be due to RMF settings. As pointed out in the white paper described below, it isn’t RMF that could cause the CPU increase. RMF in z/OSMF takes only a fraction of 1%. My apologies to the RMF development team.
2. Update on z/OSMF
Just before SHARE, I became aware of a new white paper (WP101779, 10May2011) and APAR (PR34596, 9May2011) regarding the resource requirements needed to run z/OSMF. While everyone knew that the installation footprint of WAS OEM was fairly large, the white paper seemed to indicate that the CPU and storage requirements were very high. The paper says that you need a minimum of 120 MIPS of available CPU and 2 GB of storage to run z/OSMF. Needless to say, a lot of us were very surprised because we had thought that z/OSMF was a perfect solution for small installations, and most small sites don’t have an available 120 MIPS.
As you might expect, it doesn’t take 120 MIPS for steady state (running, but no active requests). IBM set the minimum requirement to accommodate long running z/OSMF tasks which otherwise might cause z/OSMF to time out and abort with an EC3 ABEND. If an abend occurs, all work done on z/OSMF up to that point could be lost. So the 120 MIPS is NOT a minimum, but a recommendation. According to the white paper, those activities might be editing and updating very large WLM policies or the first display of the incident log where there are a very large number (300-400) of incidents. Of interest, the white paper noted that the CPU used for managing a WLM policy was higher when using the traditional ISPF WLM application than when using z/OSMF. (That’s because part of the work is offloaded to a PC.)
At SHARE, I talked to several z/OSMF customers who were running z/OSMF in much smaller environments. While it wasn’t lightening fast, it was certainly acceptable. Anyone installing z/OSMF for the first time should be aware that their first experience with z/OSMF will probably be on a small test LPAR that doesn’t have many resources. So performance may suffer.
As an example of a steady state (no z/OSMF activity), Mary Anne Matyaz and Mark Brown working at US Customs found that on their development LPAR (400 MIPS, 10 GB), z/OSMF took about .26 MIPS, and startup took only .13 MIPS. The working set size of all z/OSMF components (including WAS OEM) ranged from 1 GB to 1.5 GB. Mary Anne’s SHARE session on z/OSMF Experiences can be found here –share.confex.com/share/117/webprogram/Session9737.html. In a later email Mary Anne sent me the results of additional testing. She did a lot of work under z/OSMF, including working with a fairly large WLM policy, and the z/OSMF STCs took less than 10 MIPS. Not part of z/OSMF, but just for comparison, the FTP of a dump to IBM took about 160 MIPS.
What does this mean to large sites? Almost nothing. Except that if you need to use all that 120 MIPS during peak processing, your rolling 4-hour average might increase, and thus the cost of all other software may increase. Of course, you can always consider putting z/OSMF in its own LPAR. Or you could avoid performing the tasks that use a lot of CPU until a less busy time of day. (E.g. you could update your huge WLM policy or work with a large incident log at 8 am instead of 11 am.)
But small sites, and anyone testing in a small development LPAR, might encounter some performance issues if they do not provide enough resources. One site found that z/OSMF startup took over 20 minutes until they added more storage. The white paper indicates that z/OSMF startup should take about 2 minutes on a z10.
At SHARE, IBM said that they are working on ways to reduce the resource usage of z/OSMF. I believe so strongly in the future of z/OSMF and the benefits it provides our newer sysprogs, that I still think it’s worth your time to investigate it and try it out. You can monitor the resource usage on your test system before moving it to production. If you’re a Tuning Letter subscriber, be sure to see our recommendations on the easiest way to get into z/OSMF in our next newsletter.
3. SHARE in Orlando
Although I had a great deal of back pain during the SHARE conference in Orlando (and even had to miss a whole day), it was still an exciting week for me. There were a LOT of sessions on the enhancements in z/OS 1.13 (which I’ll cover in our upcoming Tuning Letter), but there were many other things to learn, often from other participants. You can find the presentations at www.share.org. Look at the Orlando proceedings to select your favorite subjects.
I had outpatient back surgery scheduled for the Friday following SHARE, but was postponed a week. (It’s today, actually.) So next SHARE I plan to be running between sessions! That will be March 11-16, 2012 in Atlanta. Hope to see you there.
Stay Tuned!