While I agree that it would be nice if the messages were complete, I'm not sure I can see a business case for IBM to implement that. It would cost a lot, consume the last two or three remaining docs folks well past their retirement age, and.for what? Will it increase z/OS uptake? I doubt it.
Me, I'd settle for the hex codes having good and centralized explanations. Though I realize that way could lie madness, as it could encourage laziness-adding new messages as just another such code rather than thinking about it and giving a "real" error message. I and others have observed that when creating good software, error handling can be the largest part of the job. In complex environments, there are often many, many errors that *should* never appear. Bad software ignores those errors, figuring it'll show up somewhere else (as it often does, to the user's complete confusion); or falls back on a catch-all, like Microsoft's "That didn't work", with no additional info and no idea what to do about it. One school would have every such error try to be complete and distinct, so that errors 4832 and 4833 might be similar but are definitely differentiated. But then if you're documenting the errors, your manual/database may be 75% such errors-for all of which the suggested action is "Contact support", since it's basically "We have no idea what you did to even cause this?!" For such errors, I'd argue that a single error *with a distinct subcode* is more useful: "Internal error 1234; contact support". That takes one entry in the Messages & Codes, and since there is no real additional useful information to record, it's no less helpful to the user. I suspect that's where the USS hex error codes came from originally, though I sure don't know. When this is the approach, it's probably important to have a goal-and perhaps a policy-of paying attention to occurrences of such errors, and making them more "real" if appropriate. Maybe that sounds obvious, but it's really self-defense as much as anything: if "Internal error 1234" means "You need to enable the Florblatz option and try again", you change that case of the error to say just that, thus eliminating (some of!) the support calls. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
