setting params when you define a dummy variable?

[Nancy Palmquist]

Kenneth Brody wrote:

> Quoting Nancy Palmquist (Tue, 12 Apr 2005 16:35:59 -0400):
> 
> 
>>Mike Schwartz wrote:
>>
>>
>>>     I have been doing some programming for a customer who usually
>>>doesn’t put any length or edit type on their dummy variables. 
> 
> For
> 
>>>example:
>>>
>>>Ky=”Smith” or ky=”10” * xy
>>>
>>>Instead of:
>>>
>>>Ky(30,*)=”Smith” or ky(15,.0)=”10” * xy
> 
> [...]
> 
>>>I thought there were some downsides to not setting a length or edit
>>>type, like extra RAM memory wasted.  This is probably a “Ken
> 
> Brody”
> 
>>>question and maybe even a good topic for the filePro room tonight, but
>>>are there any other reasons why it might be good or bad not to put
>>>edit types on dummy variables?
> 
> [...]
> 
>>You are right about RAM.  On undefined variables, filePro uses a new
>>memory location each time the variable is assigned a value, instead of
>>reusing the same location.  Most critical on Long reports that might
>>then crash after enough records to eat up all the available memory.  I
>>learned this one from experience.
> 
> 
> Except that the previous memory is freed for reuse, so you will not see
> a runaway memory hog.  In fact, on most platforms, the only time new
> memory will be grabbed is if the new value is longer than the current
> value.

I have documented cases where it was not released and the processed 
crashed.  Has this behavior changed over the years?  I think it was in 
4.1 or 4.5 on a Unix system.
> 
> However, variables with a defined length are allocated memory once, and
> that memory is reused every time.  Variables with undefined length do
> have extra overhead involved when assigning to them, as new memory may
> need to be allocated every time you make an assignment to them.
> 
> 
>>Also, you are right about math.  Undefined variables are assumed
>>literal.  So doing the following:
>>
>>ab="5"
>>ac="6.2"
>>ac=ab/ac
> 
> 
> Field ac, being the result of a division, will be numeric.  (Assuming,
> of course, that we're talking about undefined fields.  If ac is defined
> with a length/type, then obviously it keeps that definition.)
> 

Mathematically, what could be affected is precision.  If the type of the 
numbers is not defined correctly, the result may not be to the right 
number of decimals or might have too few places.  This can be important. 
  I have also seen rounding errors where using more or fewer places can 
affect rounding choices on the results.
> 
>>might result, in some cases, in issues caused by changes from literal
>>--> to decimal  -- > to binary.  I remember running tests on this and it
>>might be possible also to have things like:
>>
>>if: ab eq "0"	test false when you can clearly see the value of ab is
>>equal to "0" but a literal zero not a numeric zero.
> 
> 
> If ab is numeric, then the above will be true if ab contains zero or
> is empty.  If ab is not numeric, then it will be true only if its
> first character is '0'.
>

Again, ab is not defined so contents could be anything.  Who knows what 
will be there.  How can you depend on results if the data is not controlled?


> 
>>It can make things like numbers test wrong where they would right
>>justify but literals do not.
>>
>>"2" is not equal to "   2"
> 
> 
> Again, it depends on the types.  If one of those values is in a numeric
> field, then they are equal.  If they're both literals, or non-numeric
> fields, then you are correct that they are not equal.

He was asking about undefined dummy variables so they are all literal.



-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com