The university of Alabama is a public university and receives both state & federal funding.
Sent from [Proton Mail](https://proton.me/mail/home) for iOS On Mon, Sep 18, 2023 at 3:19 PM, Phil Smith III <[li...@akphs.com](mailto:On Mon, Sep 18, 2023 at 3:19 PM, Phil Smith III <<a href=)> wrote: > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
