Re: conversion to ILE

David wrote:
>Depends on how you do it.  OPTIONS(*VARLEN) could speed up what
>you are doing.  If you are on V4R2 Varying makes a huge difference.  I
>converted our string routines to use Varying when V4R2 came out and it
>made a big improvement.  If you combining CONST and VARYING you
>get ease of use, flexibility, and speed.  The biggest drawback is that CL
>calls have to append the length manually.  Also the older (non-free format
>opcodes like xlate don't automatically set the result length.)

Ditto on encouraging the use of varying length strings.

I'm posting in response to David's last point about
fixed-format opcodes not setting the length of the
results.  This was a tough choice to make, since you
would expect that the length should be set for all
string results.  Unfortunately, the fixed-form opcodes
have some interesting semantics that complicated the
issue.  For example, how do you set the result length
for the MOVE opcode which moves data right-adjusted
into the result without erasing existing stuff at the
left of the field?  Other fixed form opcodes have
similar behaviour in that by default, existing chars
beyond the end of the source data are not removed.
OK, there is an opcode extender that says to pad the
result with blanks, but then, do we want to complicate
the behaviour with different rules for the different
options?

We decided to try to keep things simple:  For the
free-form opcodes, you get the varying length
behaviour you would expect.  For the fixed-form
opcodes, a varying length field acts just like a
fixed length field defined with the current length.

Or
   1) fixed opcodes -> varying fields work like fixed
                       length fields
   2) free-form opcodes -> varying fields are free

Needless to say, as more and more programmers move to
newer releases that support varying length strings
and more built-in functions, we expect more people to
use the free-form opcodes.  String processing is much
much easier with the free-form opcodes.

(Regarding XLATE, you'll have that as a built-in
function in some future release.  And there are at
least a dozen more in my work plan!)

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *