On Sat, 30 Aug 2025 20:08:46 +0100, Rupert Reynolds <[email protected]> wrote:
>Very true. I remember wondering if one message would continue from vol.1 to >vol.2 :-) What do you perceive as a problem with "overloaded messages"? Don't let anyone drag you into this wild herring. There are multiple advantages to overloaded messages and they are extremely important even if you feel a minor inconvenience. 1. I don't consider these overloaded messages because the message does not change. 2. Most overloaded messages are associated to I/O. 3. GDPS needs to know if a device is having a single temporary error or multiple I/O errors with different statuses. 4. Automation can easily handle all types of errors for a device instead of writing rules for each msg id. 5. If the message requires changes, the change is simple and consistent for all cases. 6. The action is typically the same regardless of the status. 7. Need I mention doc writers? 8. You recognize the error and don't think about the uniqueness of the message id. >Even so, I think having a message ID to look up (if you want extra info) is >streets ahead of the competition. Forget about the competition. These messages are vital to z/OS and they have the same attributes as any other message. z/OS is better off with them than without them.
