× 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.


  • Subject: Re: conversion to ILE
  • From: boldt@xxxxxxxxxx
  • Date: Thu, 22 Apr 1999 08:29:55 -0400



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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.