Re: VARLEN field read into LIKEREC DS

[Alan Campin <Alan.Campin@xxxxxxx>]

>>  Barbara Morris  
>> You can count on M.PDATE staying in the same place.  Within your
>> program, a VARYING field has a fixed storage size (the maximum length of
>> the data plus two bytes).  If you do %SIZE on the field, you will always
>> get the same result no matter what the current length is.

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?

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?  

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.  

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? 

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