I can sympathize Ed. We were on the edge with WebSphere on z/OS when I believe the freeware, v3.02, came out in 2001 and we had quite a time with problems and support on all sides including my own due to lack of practical experience. When I recommended, in a call to developers at our corporate site, that we shoot an early problem with some debug code I was told that they were not going to try that approach. When IBM got involved they made the same recommendation and all of a sudden the developers are putting in the code. Ended up being a resource spin condition due to mishandling of a double mouse click on the same screen. No dumps were read during this problem and I don't remember why. I do believe the skills now exist, master skills, although they are probably in very short supply. Ran into another more intermittent problem, this took about 14 - 16 months, with a storage leak/creep in the heap and it took literal table pounding after several months to get people with significant knowledge on the problem. Once Watson and Hursley were put on it took about a month to 6 weeks, the problem was very intermittent and they had requested additional dump options, before they finally pinned it down to internal table validation/mismatch. Even after looking at the dump they were not exactly sure where the problem was but knew enough to write some debug code to finally trap it. This last group of folks were very good. This might be an area I'd like to get into at some point since I have found the z/OS WebSphere stuff to be very interesting, will work for food.
Edward Jaffe <[EMAIL PROTECTED]> wrote: 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