Re: RPG ILE *VARSIZE issue?

On Fri, 2016-02-12 at 22:48 -0600, Bradley Stone wrote:

Wow.. thanks for the responses! Makes sense to me... I missed that last
part in the docs.

I guess I just assumed there was more automation going on in the background
with *VARSIZE.

The issue is the length could be 1 to anything. What if I wanted to pass
back more than the full length declared? That sounds like it's not going
to work. I may need to move to just using pointers instead.

If your caller had say a field length of 10 and you modified the data
within the called procedure to have a length of say 100 (ignoring any
possible exception that might happen) how would that 10 character field
be able to access the additional 90 characters?

By changing the caller to be a 100 character varying field with a set
length of 10 (its data length), modifying it within the procedure to now
contain 100 characters would cause no issues.

Passing a pointer to a 10 character field, then modifying 100 bytes
within the caller would likely result in other fields being corrupted or
if other fields within the caller are changed they would overwrite the
10>100 bytes that had been set.

If you think of the caller's fields as being stored one after the
other:-
Name: len: start memory address: value in caller
MyField 10 1 1234567890
lenof 5 11 abcde
another 1 16 *on

The called procedure now amends 100 bytes to be 0987654321AAAAA3

that means the calling procedures fields now contain:
0987654321
AAAAA
3

By using a combination of *varsize, varying (not strictly required), and
opdesc and then checking/limiting updates to the "real" field size (as
defined within the caller) using CEEDOD you can then allow a more
generic procedure that can handle multiple differing lengths defined
within the callers.

CEEDOD returns the "defined length within the caller" so where a caller
passes a defined length (not content length) 10 char field the value 10
will be returned. Where a caller has a 30 char field, CEEDOD will return
30. The called procedure can then have a field length of 32K without
requiring all the callers to pass 32K fields.

The called procedure must make sure that it doesn't change, or access,
more than the "real" length returned by CEEDOD - there be dragons that
way.

On Fri, Feb 12, 2016 at 9:57 PM, Barbara Morris <bmorris@xxxxxxxxxx> wrote:

On 2/12/2016 8:22 PM, Brian Johnson wrote:

In #test_test wouldn't the assignment of '?' to parameter named input be
padding with 65534K blanks and overwriting who-knows-what in memory?

Exactly right. Here's what the manual says about *VARSIZE:

"When OPTIONS(*VARSIZE) is specified, the passed parameter may be shorter
or longer in length than is defined in the prototype. It is then up to the
called program or subprocedure to ensure that it accesses only as much data
as was passed. To communicate the amount of data passed, you can either
pass an extra parameter containing the length, or use operational
descriptors for the subprocedure. For variable-length fields, you can use
the %LEN built-in function to determine the current length of the passed
parameter."

Bradley, if you just want the called procedure to be able to use the
parameter's value, it would be much safer to make the parameter varying
length. Then the called procedure could get the length by checking %LEN. If
you want the procedure to get the trimmed value of the parameter, code
OPTIONS(*TRIM), although that will trim both left and right.

If you want the procedure to be able to modify up to the full length of
the passed parameter, I think your second parameter should be the size of
the passed parameter, not the trimmed size. The procedure could figure out
the trimmed length itself by using
%len(%trim(%subst(parm:1:parmsize)))

--
Barbara


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.