Re: show message on line 24

[D.BALE@xxxxxxxxxxxxx]

You finished making the point I failed to make in my orignal post - if I've
got to create my own message file and message descriptions to get the
second-level text, then I might as well code the text in the message
descriptions!

Usually, this catch-22 arises when I've written a simple utility, just one or
two messages that could possibly be sent.  You use the CPF9898, test it,
somebody else asks for it, returns to you and says, "what does this message
mean?", you go, "hmmm, really needs more than the 75 characters on the message
line, should use second-level text; oh cr*p!  Can't use CPF9898, so create a
new message ID?  Can't (won't) create one in QCPFMSG, so create a new message
file?  Fergetaboutit, just document the thing in a README and in the source
code."

I just know someone's gonna ask, well why not just create the message file?
(Hey, Leif, why didn't you just create a message file?)  Maybe I'm just lazy,
but I just think it's overkill to create a message file for a single-app
utility.  I _do_ define message files for entire "application systems" that
I've designed and written in the past.  But for the simple CL utility program?
 Eh...

Plus, what's easier to understand, snippet A or snippet B?:

A:   MONMSG  CPF3777 EXEC(SNDPGMMSG MSGID(USR1001) MSGF(USRMSGF))
B:   MONMSG  CPF3777 EXEC(SNDPGMMSG MSGID(CPF9897) MSGF(QCPFMSG)
              MSGDTA('One or more libraries were not completely saved.')

I vote for B.

<sigh>

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952

-------------------------- Original Message --------------------------

Dan

>Am I the only one who has, many times, lamented the fact that IBM failed to
>open up the second-level text for these two message IDs?

No, I have bemoaned this fact many times. I console myself with the thought
that the majority of users don't hit F1 once let alone twice :)

>I realize that I *could* create a new message description, but I would, by
>most standards, have to create it in a user-defined message file (and NOT
>QCPFMSG).  OS upgrades and, possibly, PTFs could replace the QCPFMSG msgfile.
>Even if I didn't have to worry about that, other clients' 400's may have
>already defined a message ID that I had intended to use for my purposes.

If you create a purpose-built message file in your own library then none of
this ought to affect you. I have kind of come round to the idea that the
CPF9898 message is OK as a pinch hitter but all the hassle of a message
file and defining the variables etc is probably worth it in the long run if
you generate lots of messages (as I do)

The thing that convinced me of this is the fact that subsequent
interpretation of the message was possible by storing the message data and
the Message ID. For example if I have a message I use that says "Subsystem
XXXXXX not ready yet" I am able at some later stage to get a list of all
the subsystems that weren't ready by using the message data values - this
is assuming I have the message data and the message ID stored somewhere !
Compare this to the thought of having to break down every one of the
message strings....

I guess my conclusion eventually was CPF9898 was OK for progress messages,
ad-hoc one-off messages etc but any serious use of messages - indicated IMO
by needing the extra features IBM's messages offer - means doing the kind
of work IBM did to build the CPF message file.

Just my take :)

Cheers
Evan Harris
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---