Re: Varying(4) bug ?

OK, I'll take your word for it. The last time I tried this with the CONST clause was probably more than a dozen years ago and I have since adopted the VALUE clause. I also append OPTIONS(*STRING) for reasons mentioned previously.

I would like to hear your thoughts about the (in)efficiencies of VALUE with/out OPTIONS(*STRING). For me, I see the cost of copying of a variable (especially one greater than 4096 bytes) for each call to a procedure. But I've been wrong before. Quite recently. :) Of course, if the vaule may contain non-string characters, that OPTION would be a no-no.

"Jon Paris" <jon.paris@xxxxxxxxxxxxxx> wrote:

On Apr 13, 2011, at 9:03 AM, rpg400-l-request@xxxxxxxxxxxx wrote:

Indeed, my experience shows that it does not consider unvarying to

varying as a format change!


Not so - I have several subprocedures that rely on the fact that they
are seen as different. Since moving a fixed to a varying "captures" the
original field's length it is pivotal to the subprocedures operation.

This Varying(4) thing is a bug plain and simple and should be reported
to IBM as such. Barbara may well not comment in this thread as she
tends to not respond to anything that should be a bug report.

I wonder if the OP has checked their PTF levels?


Jon Paris
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
Sent from my Galaxy tablet phone with with K-9 Mail. Please excuse my brevity.