RE: Message File Variable Length &1 Substitution Parameters

Roger, Barbara, Ken, thanks for your help.

This leaves me wondering when it's suitable/smart/optimum/advantageous to
use the *VARY size option for message parms..?...

John B.


--__--__--
Message: 1
From: "Mackie, Roger L. (Precision Press)" <RLMackie@ppress-tc.com>
To: "'rpg400-l@midrange.com'" <rpg400-l@midrange.com>
Subject: RE: Message File Variable Length &1 Substitution Parameters
Date: Wed, 3 Apr 2002 12:09:20 -0600
Reply-To: rpg400-l@midrange.com

John,

You don't need to use the *VARY option on the substitution parameter. If you
define the substitution parameter as long as the alphanumeric edited number
could be and do a %TRIM(%EDITC(number:'1')) to fill your parameter, the OS
will trim any trailing blanks from the parameter while performing the
substitution. We do it all the time with our QHMSNDPM wrapper and produce
results like your GOOD example.

HTH,
Roger Mackie

-----Original Message-----
From: Rusling, John B. (Alliance) [mailto:jbrusling@alliancedev.com]
Sent: Wednesday, April 03, 2002 11:46 AM
To: 'RPG400-L@midrange.com'
Subject: Message File Variable Length &1 Substitution Parameters


I would like to put a number in an error message as a substitution
parameter. I'll edit it into a character field first,

Then...

I want it to read nice, ie.
if the number is 115090 (say 11 long, 2 decimal)
i want it to appear in string as: 1,150.90 but
in a readable fashion

GOOD...:   Yadda yadda 1,150.90 sumtin else.
NO GOOD:   Yadda yadda     1,150.90 sumtin else.

Another time the number might be 187.25

I don't want to end up with:

NO GOOD: Yadda yadda       187.25 sumtin else.

which looks even more 'unprofessional'.



>From the work with messages msgfile screen:
-----------------------------------------------------------
                      Change Message Description (CHGMSGD)

 Type choices, press Enter.

 Message data fields formats:     _
   Data type  . . . . . . . . . .   *CHAR___      *SAME, *NONE, *QTDCHAR...
   Length . . . . . . . . . . . .   *VARY_        Number, *VARY
   *VARY bytes or dec pos . . . .   2_____        Number
                + for more values _
-----------------------------------------------------------


They give you the option to specify substitution parms
as being *VARY for size  BUT...

How da heck do I use it?

Message ID is.....: 'JBR0120'
Message text like.:  Yadda yadda &1 sumtin else.

We use a wrapper on the QHMSNDPM api to send messages to
 bottom of screen into a one line subfile that can hold
 multiple msgs and be scrolled.



Thanks.

John B.
_______________________________________________

--__--__--

Message: 2
Subject: Re: Message File Variable Length &1 Substitution Parameters
To: rpg400-l@midrange.com
From: bmorris@ca.ibm.com
Date: Wed, 3 Apr 2002 15:25:31 -0500
Reply-To: rpg400-l@midrange.com

John, just make sure the edited value is left-justified in the
character field.  Trailing blanks in the replacement text are
not included in the final message.

Left justification is easy:

c           eval    reptext = %triml(%editc(num : 'N'))

If you were using *VARY, you'd have to left-justify the value
anyway, so using *VARY will just make things more complicated.
If I recall correctly, with *VARY, you have to put the length
of the data first (2 or 4 byte binary), then the data, and then
all the subsequent fields have to follow that length of data
directly.  So you can't use a nice data structure for the
replacement text - you have to build it dynamically.

Barbara Morris


--__--__--

--__--__--

Message: 5
Date: Wed, 03 Apr 2002 13:18:12 -0800
To: rpg400-l@midrange.com
From: Ken Sims <mr2087@ke9nr.net>
Subject: Re: Message File Variable Length &1 Substitution Parameters
Reply-To: rpg400-l@midrange.com

Hi John -


You don't need to use a varying field.  Make it a fixed length character
field as long as the longest possible edited value.  In your program use
%TRIML(%EDITC to load the field with the number left-justified.  The
substitution process itself will strip off the trailing blanks.

Ken
Opinions expressed are my own and do not necessarily represent the views of
my employer or anyone in their right mind.


--__--__--