Re: VARLEN field read into LIKEREC DS

Alan Campin wrote:
> 
> Ouch, so you are saying if I declare a VARYING field to be 32767 which I 
> routinely do, it takes 32K of storage? I thought the amount of storage was 
> equal to the current string length + 2 bytes. If I do %LEN(string) = 0, the 
> length of the string was zero. Are you saying that even though I set it's 
> length to zero, it still occupies 32K of storage?
> 
> Doesn't that kind of defeat of the whole purpose of VARYING? I thought the 
> whole idea was that I could declare strings and not have to worry about these 
> issues? What advantages would I get using VARYING over simply declare a 
> string of 32K other than being able to say %LEN?

The purpose of VARLEN in the DDS is to possibly reduce storage in the
database.  The purpose of VARYING is more to give better performance and
easier coding of string manipulation (and also just to support using the
VARLEN fields that the database provides).

> 
> I routinely pass in varying string as parameters by value but I guess I hear 
> that the system is going to have to copy the whole 32K to the stack?

Yes.  It's better to pass varying strings as CONST, even if you have to
copy the parameter to a temporary within the procedure in the cases
where you want to modify the parameter.

> 
> I know that %SIZE returns the maximum + two bytes but not that it was reading 
> the actual length of the string. The compiler knows the maximum length of the 
> string at compile time so that it would just insert the value at compile 
> time. I was trying to think of a scenario were the compiler would not the 
> maximum string length at compile time but can't think of one.

%SIZE isn't reading the whole length of the string.  %SIZE is a
compile-time value that is always the same.  My point was that %SIZE
gives you the number of storage bytes occupied by the string, and that
the number of storage bytes is constant.

> 
> I was thinking about this issue the other night and it seemed to me that best 
> possibility was that each VARYING string always occupied 18 bytes. 2 bytes 
> for the length and a pointer to the actual storage so if I set the value to 
> zero, the storage was released. If I changed it to 20 bytes, I would have 
> internally a pointer to the allocated storage but I guess you are saying no. 
> This is done because doing allocations would take too much resources?

When VARYING fields were introduced to RPG, the format of the fields in
the database was already set.  I don't know if the database format ever
considered using pointers as you describe.  I don't know what would be
the relative performance of doing runtime-allocations vs allocating the
full length.  There's nothing to say that an alternate form of varying
length field couldn't be added to the language.  If RPG ever gets
strings longer than 65535, some new form of varying length will _have_
to be introduced (if only a 4-byte length prefix), since the 2-byte
prefix only holds lengths up to 65535.

> 
> Ouch, ouch. Going to have to change a lot of code.

I hope you just mean changing your the parameters from VALUE to CONST. 
I wouldn't stop using varying fields since they perform much better than
fixed length fields if the alternative is doing repeated %TRIM
operations to get the actual data.  The storage required by a varying
field is only 2 more than the equivalent fixed-length field.