Re: Compile error - why?

[Rich Duzenbury <rduz@xxxxxxxxxxxxxxxxxxx>]

Hans,

Thank you for the informative reply.  I figured it must have to do with
implementation difficulties. I temporarily solved my problem by making the
format of my date field *USA, so that a %char returns the data correctly.

At 06:55 AM 10/7/02, Hans Boldt wrote:
> > Why is this restriction in place?
> First, let's review the rules for using varying length character
> variables in the fixed-form calc specs. When developing the varying
> functionality, we agonized a while over the issue of how to provide
> some sort of meaningful use of varying length variables in the calc
> specs. It was a problem due to the weird semantics of the MOVE and
> MOVEL operations (among others). For example, when moving a short
> Factor 2 operand to a longer Result Field operand using MOVE, the
> left-most characters are left unmodified. We tried coming up with
> rules that made sense using varying length fields, but attempts
> resulted in rather ornery and complex rules.
>
> And so, we adopted the general principle that any varying length
> variable coded in fixed-format calcs would be treated as a fixed
> length variable field defined with the current length. One simple
> rule - fixed-form calcs means varying length variables are treated
> as fixed length.
>
> So on to date variables. You know there's a rule that when moving a
> character variable to a date variable, the character variable must
> be long enough to hold a date value (or vice versa). The problem
> with a varying length variable is that at compile time we don't know
> if the variable will have a current length at run-time long enough
> to hold a date value. And so we disallow all varying length
> variables in date, time, and timestamp MOVE operations.
>
> I suppose you could argue that we could add a check at run-time, and
> I suppose that's true. But since there were alternatives, we decided
> not to do that extra work. Now, with V5R1, there are even more
> expression alternatives to do D/T/Z manipulation.
>
> (Oh BTW, if you want to do level breaks on integer input fields (or
> any other of the unsupported types), just define a character field
> in that field position, and code the level indicator on that field.)
>
> Cheers!  Hans