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
