Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

[Tim J. <te...@me...>]

Bill,

I agree on point one, however for the core compiler subset (which
is to be used for writing the compiler runtime, I don't see much
use for V). 

Therefore I have deferred it to the next phase. The sequence is
this

utilities - done
preprocessor - done (copy/replace etc)
core compiler subset for writing compiler runtime routines -
getting close to done
rest of COBOL nucleus including full support for PICs, overflow,
rounding, missing verbs, nested procedures, special names - next
rest of inter program communication: after that
sort, files: after that
intrinsic functions: after that
report writer: after that
segmentation, debug, communications: never except to recognize
and ignore. Debug lines will probably be done as part of the wrap
up of the nucleus as it's simple. 

I haven't thought about point 2 at all so I will make a note of
your suggestion for later.

Regards,
Tim Josling

"William M. Klein" wrote:
> 
> I may be missing the target of this post, but I did want to make two
> suggestions:
> 
> 1) Do *not* delay the implementation of "V" in Picture clauses.  I know of
> no COBOL program more complex than "Hello World" - that doesn't have at
> least SOME "V" picture clauses.
> 
> 2) For edited data items, (alphanumeric-edited or numeric-edited) I would
> *strongly* suggest that you "store" the editing mask in your data
> definition.  This should *not* be stored as something like
>    X(10)
>         but rather
>    XXXXXXXXXX
> 
> It is true that the picture-character-string is *only* limited to 50
> characters - and this can be something like
>   Pic  X(2000)/(20)X(1000)
> but I still think that you will find it "easier in the long run" to store
> the edited version in a (variable length) "normalized" version with no
> duplication numbers.
>