RE: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

[William M. K. <wm...@ix...>]

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.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of
> Steven O. Ellis
> Sent: Thursday, April 12, 2001 2:52 AM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING
>
>
> Tim,
>
> Fair enough.  I propose yet another parameter containing the picture
> character string for each receiving area.
>
> As Bill suggests, "P" and "0" can be disallowed for now, and for the
> immediate purposes, I would disallow "V" and anything else except
> {X,S,(,),0,1,2,3,4,5,6,7,8,9}.  "0" would be allowed only within
> parentheses.  The receiving area could then be text, signed integer, or
> unsigned integer.  I think that would make the UNSTRING routine
> "seaworthy" for the time being.
>
> Receiving areas will be USAGE DISPLAY because:
>
> 6.27.3 Syntax Rules
>
> (3) Identifier-4 may be described as either the category alphabetic,
>     alphanumeric, or numeric (except that the symbol 'P' may not be
>     used in the PICTURE character-string), and must be described
>     implicitly or explicitly, as USAGE IS DISPLAY.
>
> There is one other thing, though.  In the set of usage flags currently
> defined in cobr_temp_config.h, there is "SIGN IS TRAILING SEPARATE", but
> no "SIGN IS LEADING SEPARATE".  This simplifies the problem.  But will
> the COBOLforGCC implementation always require a separate sign to be
> trailing, or will this be changed in the future?
>
>
> 	Steven
>
>
> Tim Josling wrote:
> >
> > Steven,
> >
> > How about this:
> >
> > - add a parameter for each receiving area, to specify the type
> > per cobr_type enum in cobr_temp_config.h.
> > - add a parameter for each receiving area to say if it is left
> > justified or right justified (eg a COB_UINT32 which has value 1
> > if right justified
> > - hand code to cater only for the type cobrTypeText which is pic
> > x(n) and also cater for right justified.
> > - add assert(type_parm==cobrTypeText);
> > so that it will crash if someone passes something it can't
> > handle.
> >
> > Or some other scheme, as long as it is simple and uses the types
> > in cobr_temp_config.h
> >
> > Later on once all the move variants are supported we can add code
> > to call the appropriate routine.
> >
> > Regards,
> > Tim Josling
> >
> > "Steven O. Ellis" wrote:
> > >
> > > Tim,
> > >
> > > STRING is OK.  The following rule disallows a right-justified
> receiving
> > > item.  Identifier-3 is the receiving item.
> > >
> > > 6.25.3 Syntax rules
> > >
> > > 4) Identifier-3 must not represent an edited data item and must
> > > not be described with the JUSTIFIED clause.
> > >
> > > However, for UNSTRING, the receiving area may be numeric.   UNSTRING
> > > General Rule 6.27.3 (2) refers to the sending area, not the receiving
> > > area.  I do believe there is the potential for a numeric move per
> > > General Rule 6.27.4 (13c), quoted below.  And per MOVE General Rule
> > > 6.19.4 (4b), when the receiving area is numeric and the
> sending area is
> > > alphanumeric, "data is moved as if the sending operand were
> described as
> > > an unsigned numeric integer."
> > >
> > > This is not something that needs to be resolved at once, but I am
> > > thinking that the final version of UNSTRING is going to have
> to be able
> > > to handle a more sophisticated move.
> > >
> > > Steven
> > >
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel