Hello Everyone, I have been following this conversation with great interest. I like Rob have been on both sides of Conversation. Now I am the customer with the documentation.
Having good documentation helps everyone involved, and good change management (of some sort) helps debug issues. I have noticed that I always have 'Almost' enough information, but it is 'you need a little more'. (I hope that I never caused that much problem for my customers but....) Is there a check list that we could come up with that would be a standard, short list of documentation? Or is this just a pipe dream? Ed Martin Aultman Health Foundation 330-363-5050 ext 35050 -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Rob van der Heij Sent: Friday, July 23, 2010 8:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: New standard for networking help On Thu, Jul 15, 2010 at 5:06 PM, Alan Altmark <alan_altm...@us.ibm.com> wrote: > Bottom line, it enabled me to discover the problem in about 5 minutes - > the NATIVE and default VLAN on DEFINE VSWITCH had the same value. With so many people getting excited, I feel un irresitable urge to assume my position on the peanut gallery this Friday afternoon... "Well that may be true, but at what expense for the customer?" >From my current position, I obviously welcome any effort the customer is willing to put in to increase my efficiency and improve the quality of my response. And I do expect that most of those 17 pages was their normal documentation that they maintain for the system anyway. But one should ask how long that customer has been fighting the problem to make them think it required such extensive documentation. And if it only took you 5 minutes to browse those 17 pages (certainly not read it all) and find the cause and post to the mailing list, is it clear enough in the books to prevent the problem from happening. But in a former life as customer, I soon realized that vendors were asking for extensive documentation and experiments only to buy time (so once you had things collected, they could tell you that you have a really old level and could you try with the latest version). An automated program to generate such documentation with no effort - or worse, even before the vendor asks for it - really defeats the purpose... :-) Seriously, I doubt such a "tell me all you know" program will improve things. Especially since it only shows what the customer defined, not what he meant to define or should have defined. Much of what you can collect just is not needed in most cases. Like in this case, having the Rick's list of 16,000 volumes would not have made Alan's task any easier (depending on the layout of that list, he would have told us 285 pages of documentation to be the norm :-) Don't get me wrong. I do value some kind of standard form or checklist for each specific problem area. But I would focus on the 10% of the information that resolves 90% of the questions. My experience is that 3 questions is about the maximum you can do (beyond that, people seem to think it's multiple choice and they answer just one or two of them :-) | Rob
