Correcting Mestakes

Oh, did I misspell mistake? That reminds me. As a relatively new hire, I was looking at some of the workloads we used to evaluate CMS performance. While looking over the commands, I saw one named XXXXX. I scratched my head as I wasn't sure what this command did. I looked around and couldn't find anything on this mysterious command. I finally spoke with one of the more senior members who was an expert in CMS performance, Gary Hine.

Gary smiled, "Ohhh, that's one of the more common commands people use." I looked back at him the same way I used to look back at my older brothers when I thought they were spinning a tale, and asked what it did. Still smiling Gary replied, "Nothing". He then went on to explain that one of the more common commands was a typo which was an invalid command. They had picked this up at some point when studying real users. (Though I know my rate of typos is proportional to how many people are watching me type). I found it interesting that we actually measured the performance of mistakes. It made sense. The quicker it would execute, the quicker the user would realize they made a mistake and correct it.

In System z, it's one of the things we think about a lot (perhaps still not enough, but a lot). That is, what happens when there is a mistake? How obvious is it that there was a problem, and more importantly how obvious is the method to correct things? A few years ago Richard Lewis and Chuck Morse started doing hands-on Labs at SHARE and other conferences. I started attending those sessions to help, but also to learn. I got a whole new perspective seeing a student who made a mistake updating CP Config and trying to sort out what they did wrong. Oh, you typed PAG001 instead of PG0001. The hard part in writing documentation is often clearing your mind so you only know what the reader will know before they start to read the documentation. Yes, not so easy.

The other area where I remember us doing significant performance work in the early days that surprised me was HELP. These days HELP isn't used that often relative to the number of transactions running through a z/VM system. In the past though, it was used quite heavily and we made various improvements over the years. I'm biased, but I still think it's easier in some regards than some other help systems.

For example, the software for this blog. I want to find out... well heck. I can't find any help on this gui based blog editor. So there goes my example. But we've all been there. Lets look at Thunderbird email client instead:

1. Click help 
2. Click help contents
3. Wait for browser to start
4. In search menu, type in 'help set font'
5. Scratch head
6. In search menu, type in 'set font'
7. Look at dozen options provided
8. Pick one
9. Back to thunderbird
10. Click Tools
11. Click Options
12. Click Composition
13. Click General
14. Set fonts
15. See if that did what I wanted

Seems like a lot of clicking.

z/VM HELP has short comings, but it's fairly concise and gives me much of what I need. And the number of steps in navigating has never been so many that I forgot what I needed before I found it.

While assisting in one of the labs I mentioned earlier, I saw a student make a mistake and get an error message. I showed them that they could type HELP message_number and presto. More smiles.

Knowing we all make mistakes, learning from them, and helping others avoid or correct mistakes is something VM has been doing for a long time.

Speaking of help. A shout out to the various people that let me know about typos and other corrections. It is appreciated.