RE: Formatting non-program messages

I am also a huge advocate of externalizing messages into *MSGFs and I agree
with everything in Al's email. 
1) Think of MessageIDs as standard way of dynamically communicating business
rule violations or business events.  
2) Process the occurrence of an error message thru a error
processor(*SRVPGM.
3) *SRVPGM determines if this is a hard error, warning, action msg or turned
off.  This is accomplished by external tables which can override the error
severity based on MsgID, calling program, user. 
4) *SRVPGM formats the message variables into the message text if message is
to be communicated back to user or the log.
4) *SRVPGM can log each occurrence (ability to control log level).
5) Complete cross reference of MsgIDs by program.

Don Tully
Tully Consulting LLC

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Al Mac
Sent: Friday, September 29, 2006 2:00 PM
To: Midrange Systems Technical Discussion
Subject: Re: Formatting non-program messages

4) messages created for "one time scenarios" are there convenient, 
available to be used in future programs, that we had not yet dreamed of at 
the "one time"
6) We can "merge" modifications and additions when vendor upgrades message 
file in some upgrade or PTF
7) We can have copy of message file with text in a non-English language so 
our friends south of the border, and other places, can see the error 
message in their tongue
8) Less hassle that scenario of MSG to specified user AL or other long time 
employee, when time comes that person leaves the company

Using externally defined messages in a message file is more about 
communications and ease of program maintenance than it is about re-use of 
message IDs. There are many advantages:

1) It makes it easier to monitor for different errors. (I hate it when 
commands and programs send CPF9898 escape messages.)
2) When retrieving messages it makes it easier to figure what's going on 
without having to programatically parse the message text.
3) To find which part of a program sent an error it's easier to searching 
for a unique message IDs in source is much easier than searching for text 
strings or for the dreaded CPF9898 message ID.
5) The text of the messages are stored externally, like file record 
formats, which makes life easier all around, so if you want to change the 
text of a message you can do so without re-compiling the program (or

programs).

It might be helpful if there was a GO CMDREF variant to cross-index what 
programs call what messages, unless we use a standard &# for ME (identify 
&PGM that sent the message)

There are probably many more that I can't think of right now.

[Can you tell that I'm a zealous message handling advocate?  ;-)  ]

IMHO all messages whether used once or many times should be defined in a 
message file.