Hi Alan, Messages and Codes manuals are used to explain in greater detail what a "message" means and what response to take. In the mainframe world we don't just have "messages" (i.e. random text that may or may not mean something useful) - we also have codes - ever message has a unique code that identifies it.
So is such a thing useful for Linux - ABSOLUTELY! So when I get the following message: "kernel panic: foobar barfed!" I can then go and cross reference this manual which will tell me, in great detail, just what the heck this message means, and how to respond if necessary. Unfortunately, Linux messages are not numbered, so cross-referencing them would be simply alpha based. But, Paul, here is the problem. Unlike say an IBM operating system where IBM created and maintains it's content (and third party vendors follow their standards) - Linux is more akin to the "wild, wild, west". There is no standard format for messages - and the components which make up a Linux distribution may have been created by thousands of different people. Nobody reviews whether or not messages are intelligible and meaningful - they are whatever the author wanted to code up (if anything!) to be displayed when a condition occurs. I actually find a Linux messages cross reference at Borders recently. It was a very good start given the complications discussed above. I ultimately didn't buy the book because it was incomplete (and probably any book that might be written would become incomplete or obsolete in a VERY short time given the way Linux is constantly changing). The Linux folks think we mainframe types are "spoiled" by the extensive documentations that IBM mainframe systems have. We, on the other hand, wouldn't think of running an Enterprise on anything LESS. I've heard time and time and time and time again that documentation is NOT necessary for Linux because you can always "read the source"! So next time one of your Operators sees a "kernel panic" message on a Linux/390 console - simply tell them to go read the source (all of it, every single last module!) and find who issues this message, what it means, and what they should do about it. Michael Coffin, VM Systems Programmer Internal Revenue Service - Room�6030 1111 Constitution Avenue, N.W. Washington, D.C.� 20224 Voice: (202)�927-4188�� FAX:� (202) 622-6726 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -----Original Message----- From: Alan Cox [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 11:57 AM To: [EMAIL PROTECTED] Subject: Re: Messages Manual > Is there a messages manual for Linux? In going back through the archives, > I see a lively discussion on this subject in 2000. But I have not fund > much since then. Our automation and production support groups are > concerned about the lack of a messages manual. So far, it looks like the > only available approach is the handle it as it hits you method. What are > other companies doing to provide the various operations organizations the > documentation they need to support a production environment? Question: What is a "messages manual", what does it achieve ? (This probably sounds as dumb to the S/390 crowd as the unix questions sometimes do to me but its a foreign concept) Alan
