Re: Sending exception messages from a CPP back to the caller

On 06-Nov 10:57 -0800, Jeff Crosby wrote:

On Wed, Nov 6, 2013 at 1:38 PM, Alan Campin wrote:

I used to build custom message id with substitution variables and
tons of second level help but finally just started using CPF9898.
Just a waste of time because no one ever looked at any of it.

<<SNIP>>
Let's say you set up a message member with this message:

USR0001 with text "This is an example of an error message"

Then SNDPGMMSG sends this message to a message queue. Now go back
into the message member and change the text for USR0001 to "You're
a weenie!"
Finally, go look at the message queue where USR0001 was originally
sent. Lo and behold, the text is what's currently in USR0001, not
what was originally sent.

Yes, good or just simplistic excuses or rationale can be found to justify avoiding doing just about anything, even if in conflict with conventions and good design practices\patterns.

But of course, the design and implementation should reflect requirements. Thus if the only requirement is to issue an effective /impromptu message/ [something that is not allowed for each of MSGTYPE(*ESCAPE|*NOTIFY|*STATUS)] to be sent as an exception message, then borrowing a system message is probably acceptable. However using something other than those message identifiers specifically created for usage by /user/ applications may cause confusion with actual system-diagnosed conditions... and could lead to difficulties being encountered when requesting defect or contractual support.

FWiW: Those dynamic results would be a potential issue given code or a person dynamically modifying Message Identifiers in a Message File. However note that the /spooled joblog/ will reflect the text set when that log was spooled; i.e. the text is obtained when the joblog is created. Regardless, the design intention for the use of MsgId in a MsgF does not include dynamically changing the first [or second] level message text to reflect an entirely unrelated condition; i.e. the message ID is for a static\known set of conditions that might be elaborated, but not rewritten to diagnose something entirely different. Thus, using that contrived example as rationale for avoiding message files and message identifiers is IMO, a poor excuse.