Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING
Status: Pre-Alpha
Brought to you by:
timjosling
Menu
▾
▴
Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING
|
From: Steven O. E. <so...@so...> - 2001-04-13 00:17:06
|
OK. This is from Tim's and Bill's input and my own thoughts on it.
Rather than implement a "pseudo-move" in UNSTRING, I will restrict it to
text-only. Then, when the regular MOVE code is fleshed out, all the
needed functionality can be put in at once, including the editing mask,
and the "V", when present, and the logic to accomodate "SIGN IS
SEPARATE". Tim, is there a repository for such issues as they relate to
a particular command?
"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.
>
> > -----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
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel
--
\/\/\/\/\/\/\/\/\/\/\/\/
|
