Re: One function to Trim and Edit a number.

Hi Chuck,

I agree with what you're saying (and the other replies) about
the efficacy of message files and message ids.

I did find, that at my previous job, when analyzing a pgm that
used msgids (from msg file), I had to keep 'looking them up'
in the msg file, which invariably 'trained' me to always paste
a comment above my message id's, in pgms I wrote, that echoed
the text of the msg file msgid.

To me, it seemed/seems redundant to add a msg file entry AND place
comments in the pgm that echoed (almost exactly) what the msgid was.

I also have a propensity for placing more logic in the program itself
rather that the dds (display files, physical files etc.) or elsewhere.
I mean, I'll use qsysprt and O-specs whenever I can. <g>

So, like Alan, when I need a msgid, I end up using CPF9897 or CPF9898.

Anyway, more than one way to skin a cat, so to speak.

John B.

Wholeheartedly agree - your comment about users! <g>

The mention of /logs/ was why /retrieve message/ was explicitly noted, beyond
just /send message/. That retrieve feature can be used to effect the same
formatted [first level] message text [with the same trimmed character replacement
variable] as would be generated with /send message/. No argument that use of
impromptu over identifiers can be worthwhile in some environments; I prefer to
make use of the tools for the functions they provide when it makes sense, and I
especially prefer to have someone tell me a message identifier than the[ir] "words"
to describe the failure, since users can be so creative [dense?] in explaining the error they received.

Regards, Chuck