*They told me most of their support effort involves wading through source code to see what might be going wrong. (No wonder they move so slowly!!!) I almost laughed out loud! Their dump reading skill shortage was so acute, the managers were convinced that dumps were useless clumps of bits & bytes.* <rant on> This attitude drives me nuts. But if people are unwilling to commit to the study, self-discipline, and diligence to achieve a competent level of professional understanding because that type of achievement is not rewarded, this is what you are stuck with. But why should anyone strive to be a competent engineer when you make more money as a manager? If, as a manager, you can always blame a skill shortage for poor results, and still collect the big $$$, what is the downside? When a company focuses its resources on management and bureaucracy instead of technical excellence, results are going to deteriorate. (Put nine women on that right away, we need the baby next month) <rant off>
* * On 12/13/07, Edward Jaffe <[EMAIL PROTECTED]> wrote: > > Barbara Nitz wrote: > > Quote from the diagnosis book: > > > > "It is easier for IBM Service to solve a problem when a test case is > available. Include a test case with your problem report wherever possible." > > > > This really rubs me the wrong way, not because it isn't true, but > because to me it sounds like justification why these highly intermittend, > non-reproducible problems are never found! To someone used to z/OS and > finding the bug with the one and only dump ever produced (because it is a > serialization problem of some sort, possibly caused by the fact that > multiple processors can execute the same instruction at exactly the same > time), this sounds like an excuse, proven by the way these problems are > always handled, due to lack of skill and knowledge.. > > > > Exactly! I've run into *massive* skills shortage problems trying to get > the Library Server for z/OS fixed. > > When working one problem in particular, I was training *them* on how I/O > works in MVS! On a telephone conference call, they were suggesting I do > things that make sense only on a PC. (Can't remember the specifics. But, > it was laughable!) And, try as I might, I simply could not understand > one of the guys at all -- his accent was so heavy. And, the rest of them > pretended not to notice. (That was a language skills shortage. Equally > frustrating. But, perhaps I digress...) After a year of back and forth, > I finally just decided not to use the "broken" function because it was > clear they could/would never fix it. I judged them incapable of doing so. > > I sent a dump for another problem with the same group. The dump had > "everything in it but the kitchen sink" and the response came back, "The > dump was not helpful to the developer. We need to try to recreate in > house." Translation? "The developer does not know how to read the dump. > He only knows how to reproduce bugs under his debugger." I got so > frustrated by this, I demanded a conference call with two levels of > management for this group. While the managers readily acknowledged their > skills shortage, and tried to placate me by telling about plans to add > more z/OS-centric people to the mix, they _actually believed_ that > chasing dumps was unproductive. They told me most of their support > effort involves wading through source code to see what might be going > wrong. (No wonder they move so slowly!!!) I almost laughed out loud! > Their dump reading skill shortage was so acute, the managers were > convinced that dumps were useless clumps of bits & bytes. Virtual boat > anchors. > > There's not much you can do when the skills shortage affects all levels > of an organization. I tried my best to convince them that effective dump > analysis is what makes z/OS a robust platform and that such skills > should be emphasized. I doubt they ever fully understood the point I was > trying to make. > > In the end, we agreed to send, and they agreed to accept, licensed and > proprietary documentation (softcopy books) from which they were finally > able to reproduce the problem locally on a PC. Sad. > > -- > 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
