I came up as an Operator and I have been a sysprog for a number of years now. All of my fellow sysprogs here were Operators at one time. I suspect that is true for most of us.
I remember, when I started, that we were lucky if at least one of our systems didn't turn toes up and crash at least once during the week. Lots of opportunity for hands-on hot seat training. In those days, in my shop, the IPL procedures were a half page laundry list of things to start. No commands, no expected messages, just the list. The theory being that if you didn't know all of the commands and dependences that you weren't qualified to IPL. Three years later, when I was a lead and responsible for training Operators, I could schedule a training change and use all of the leftover time in the 4 hour change window for training. Not just straight up and down training, but I would 'salt' the training with problems for the Operator to recognize, troubleshoot, determine the impact, etc. These days, we have to minimize or eliminate outages, even during the service window. I have had ONE production IPL this year. Let's face, in most shops, Operators just don't IPL nearly as much as we used to. We don't have a big enough box to give the Operators a sandbox. So we document a lot more fully. We have at least two people, at minimum 1 experienced Operator and a green one, even for minor changes. Anything major, a sysprog comes in. We involve Operations in IPLs, etc on our sysprog test bed as much as we can. I came in on the IPL in May. I supported, I explained, I pointed things out, and generally added on as much training as I could for them. It helps. Mistakes happen and people who are afraid to make them generally don't grow in expertise. Still, when dealing with a slacker, or someone who repeatedly fails to prepare, I don't have much tolerance for that. As for IPLing the wrong LPAR, I have seen that happen. One easy mistake is leaving the LPAR icon highlighted after the LOAD. It's really the kind of mistake the 'rusty' and the green fall into. Then at the next IPL of a different LPAR, the leftover highlighted one comes along for the ride. I have found that if I give the procedures to a greenie or a rusty (asking their help to test the procedures), and then I partner with an experienced operator and have the operators show me what to do, I can spot places where procedures, methods, training, etc. need to be improved. That also keeps them involved in the improvement process and in the partnership. That helps to keep a solution focus instead of a finger pointing/blame focus. Involvement in the process improves skill levels, and as Ed said, deepens the bench. That means a more productive working relationship too. We tried automation several years ago. It made things much worse so we pulled it out. Linda Mooney -------------- Original message -------------- From: Edward Jaffe <[EMAIL PROTECTED]> > Tom Marchant wrote: > > It should be no surprise that with a philosophy of removing responsibility > > from operators that they would act irresponsibly. My experience is that > > operators who are treated with respect and given responsibility do good > > work. Attempts to make a shop "operator-proof" don't work as well, IMO. > > > > Exactly. The deeper the bench, the better the team. > > -- > Edward E Jaffe > Phoenix Software International, Inc > 5200 W Century Blvd, Suite 800 > Los Angeles, CA 90045 > 310-338-0400 x318 > [EMAIL PROTECTED] > http://www.phoenixsoftware.com/ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
