Re: Easy way to determine blanks

[Scott Klement <klemscot@xxxxxxxxxxxx>]

On Tue, 22 Jan 2002, Lori Crane wrote:
>
> Can anyone give me some examples of what would cause Blanks in numeric
> fields done by programs only?
>

There are probably 100 ways that blanks can end up in numeric fields,
off the top of my head, I can think of 4 that are very common, so I'll
list them...

   1)  A file that is program described, when doing an EXCEPT with
          ADD, will write blanks to any position that's not explicitly
          defined in the output specs, including numeric positions.

   2)  When defining a data structure, the whole structure (including
          numeric vars) is, by default, initialized to blanks.  You
          must be careful to make sure you either change the way it's
          initialized using the INZ keyword, or that you always set
          the value of the subfields before trying to read them.

   3)  When passing a parameter from the command line, either define
          the parm as 15,5 and do not use quotes when typing it, *or*
          pass the variable as a character field.   If you define it
          as numeric in the program, then pass it with quotes around it
          from the command line, you may get blanks...

   4)  If you pass a char parm to a subprocedure with options(*VARSIZE)
          on the parameter, you have to be careful that you only work
          with the size of variable that was passed.  If you did, for
          example, an 'eval parm = *blanks', it could write blanks past
          the end of the variable, overwriting whatever happened to be
          in memory after it.    If that happened to be a numeric var,
          then you'd get blanks in it (and probably have a really hard
          time figuring out where they came from!)

Good luck