×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hey James
Nothing wrong with EVALR that I can see - it's use, though - FOO is a fixed-length variable, so all those trailing blanks are part of it - you are trying to right-justify a 50-char value into a 50-char variable - and that is what you get.
Just looking at the documentation for EVAL and EVALR - the former is padded or truncated on the right - the latter is padded or truncated on the left - EVALR does not strip trailing blanks, just as EVAL does not strip leading blanks - interesting, eh?
Cheers
Vern
On Tue, 14 Feb, 2023 at 5:20 PM, James H. H. Lampert via RPG400-L <rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:
To: rpg programming on ibm i
Cc: jamesl@xxxxxxxxxxxxxxxxx
On 2/14/23 2:27 PM, Roger Harman wrote:
Why on earth would you do all that manipulation when a simple opcode
does the job?
Because that simple opcode *doesn't* do the job by itself.
Consider:
D FOO S 50A
D BAR S 50A
D BAZ S 50A
C EVAL FOO = 'FOOBAR'
C EVALR BAR = FOO
C EVALR BAZ = %TRIM(FOO)
C FOO DSPLY
C BAR DSPLY
C BAZ DSPLY
C SETON
If you compile and run this, you get:
DSPLY FOOBAR
DSPLY FOOBAR
DSPLY FOOBAR
If the EVALR were *all* it took to forcibly quad a string to the right,
then the second line of the output would look like the third, not the first.
As to explicitly adding spaces on the left, that would only be necessary
if you were using a version of ILE RPG that lacked the EVALR.
--
JHHL
midrange.com
