cobolforgcc-devel

[Cobolforgcc-devel] MOVE subroutine in UNSTRING

[Steven O. E. <so...@so...>]

Tim,

The UNSTRING statement, conceptually at least, has an embedded MOVE in
it.  I understand from recent messages on the mailing list that you are
working on MOVE.  Please let me know when you have a first draft, so
that I may "borrow" from it when coding UNSTRING.  Meanwhile, I will
work on test cases, and rest of the prototype.  Here is the relevant
clause from the 1985 Standard, referring to a subset of characters from
the source area to be moved to one of the receiving areas.

	6.27.4  General Rules

	(13) c.  The characters thus examined (excluding the delimiting 
	character(s), if any) are treated as an elementary alphanumeric 
	data item, and are moved into the current receiving area 
	according to the rules for the MOVE statement.  (See page VI-103, 
	The MOVE Statement.)

This becomes nontrivial when you consider that the receiving area may be
defined as signed numeric or alphanumeric right-justified.

Steven

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

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

Steven,

I have written the move code but I am not supporting right
justified at present. The alpha moves are being done by directly
generated code in the compiler rather than by runtime routines so
fortunately there is no module I will be able to send you for
that. The runtime routines I have written (and tested yesterday)
are all to do with num->X and x->num. 

I suggest that you add a flag for left/right justified to the
receiving area description for alphanumeric fields.

In 6.27.3 (2) states that the receiving areas have to be
alphanumeric (fortunately), so the numeric issue should not
arise.

By the way the same problem would arise with cobr_string.c as
well - support for right justified. I will add a bug report so I
don't forget it.

Tim Josling

"Steven O. Ellis" wrote:
> 
> Tim,
> 
> The UNSTRING statement, conceptually at least, has an embedded MOVE in
> it.  I understand from recent messages on the mailing list that you are
> working on MOVE.  Please let me know when you have a first draft, so
> that I may "borrow" from it when coding UNSTRING.  Meanwhile, I will
> work on test cases, and rest of the prototype.  Here is the relevant
> clause from the 1985 Standard, referring to a subset of characters from
> the source area to be moved to one of the receiving areas.
> 
>         6.27.4  General Rules
> 
>         (13) c.  The characters thus examined (excluding the delimiting
>         character(s), if any) are treated as an elementary alphanumeric
>         data item, and are moved into the current receiving area
>         according to the rules for the MOVE statement.  (See page VI-103,
>         The MOVE Statement.)
> 
> This becomes nontrivial when you consider that the receiving area may be
> defined as signed numeric or alphanumeric right-justified.
> 
> Steven
> 
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

[Steven O. E. <so...@so...>]

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


Tim Josling wrote:
> 
> Steven,
> 
> I have written the move code but I am not supporting right
> justified at present. The alpha moves are being done by directly
> generated code in the compiler rather than by runtime routines so
> fortunately there is no module I will be able to send you for
> that. The runtime routines I have written (and tested yesterday)
> are all to do with num->X and x->num.
> 
> I suggest that you add a flag for left/right justified to the
> receiving area description for alphanumeric fields.
> 
> In 6.27.3 (2) states that the receiving areas have to be
> alphanumeric (fortunately), so the numeric issue should not
> arise.
> 
> By the way the same problem would arise with cobr_string.c as
> well - support for right justified. I will add a bug report so I
> don't forget it.
> 
> Tim Josling
> 
> "Steven O. Ellis" wrote:
> >
> > Tim,
> >
> > The UNSTRING statement, conceptually at least, has an embedded MOVE in
> > it.  I understand from recent messages on the mailing list that you are
> > working on MOVE.  Please let me know when you have a first draft, so
> > that I may "borrow" from it when coding UNSTRING.  Meanwhile, I will
> > work on test cases, and rest of the prototype.  Here is the relevant
> > clause from the 1985 Standard, referring to a subset of characters from
> > the source area to be moved to one of the receiving areas.
> >
> >         6.27.4  General Rules
> >
> >         (13) c.  The characters thus examined (excluding the delimiting
> >         character(s), if any) are treated as an elementary alphanumeric
> >         data item, and are moved into the current receiving area
> >         according to the rules for the MOVE statement.  (See page VI-103,
> >         The MOVE Statement.)
> >
> > This becomes nontrivial when you consider that the receiving area may be
> > defined as signed numeric or alphanumeric right-justified.
> >
> > 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

-- 
\/\/\/\/\/\/\/\/\/\/\/\/

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

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

Steven,

You are right. String is OK.

For unstring the receiving area must not be justified but may be
an integer without 'P' in the PIC. So it could be usage anything
- binary, packed, display.

I will have to think about how to structure this. 

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

RE: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

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

Tim,
  In terms of "priority" - I would delay support for "P" and (possibly?) "0"
picture clause items.  I believe these are:
  - little used
  - poorly defined
  - basically unneeded if you support 31-digit numeric items and the new
BINARY-xxxx and FLOAT-xxxx Usages

If you gave a "compile-time" error when such items were "defined" and put
these in an "eventual" list of things to do, I don't think many
programs/programmers would be "bothered".

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Monday, April 09, 2001 4:09 PM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING
>
>
> Steven,
>
> You are right. String is OK.
>
> For unstring the receiving area must not be justified but may be
> an integer without 'P' in the PIC. So it could be usage anything
> - binary, packed, display.
>
> I will have to think about how to structure this.
>
> 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

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

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

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
> 
> Tim Josling wrote:
> >
> > Steven,
> >
> > I have written the move code but I am not supporting right
> > justified at present. The alpha moves are being done by directly
> > generated code in the compiler rather than by runtime routines so
> > fortunately there is no module I will be able to send you for
> > that. The runtime routines I have written (and tested yesterday)
> > are all to do with num->X and x->num.
> >
> > I suggest that you add a flag for left/right justified to the
> > receiving area description for alphanumeric fields.
> >
> > In 6.27.3 (2) states that the receiving areas have to be
> > alphanumeric (fortunately), so the numeric issue should not
> > arise.
> >
> > By the way the same problem would arise with cobr_string.c as
> > well - support for right justified. I will add a bug report so I
> > don't forget it.
> >
> > Tim Josling
> >
> > "Steven O. Ellis" wrote:
> > >
> > > Tim,
> > >
> > > The UNSTRING statement, conceptually at least, has an embedded MOVE in
> > > it.  I understand from recent messages on the mailing list that you are
> > > working on MOVE.  Please let me know when you have a first draft, so
> > > that I may "borrow" from it when coding UNSTRING.  Meanwhile, I will
> > > work on test cases, and rest of the prototype.  Here is the relevant
> > > clause from the 1985 Standard, referring to a subset of characters from
> > > the source area to be moved to one of the receiving areas.
> > >
> > >         6.27.4  General Rules
> > >
> > >         (13) c.  The characters thus examined (excluding the delimiting
> > >         character(s), if any) are treated as an elementary alphanumeric
> > >         data item, and are moved into the current receiving area
> > >         according to the rules for the MOVE statement.  (See page VI-103,
> > >         The MOVE Statement.)
> > >
> > > This becomes nontrivial when you consider that the receiving area may be
> > > defined as signed numeric or alphanumeric right-justified.
> > >
> > > 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
> 
> --
> \/\/\/\/\/\/\/\/\/\/\/\/
> 
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

[Steven O. E. <so...@so...>]

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
> >

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

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

Steven,

OK. The main priority for me is to get the pic x(n) ones done.
Later on when I add support for all the esoteric types we can
plug in the mover routine. You are welcome to add support for the
numerics but I would prefer to have enums passed rather than PIC
characters or strings. If you need a new enum then make it up.

I don't know why leading sign seperate is not there. I assume it
will have to be added later on. Just having a quick look I think
the comments in the file may be wrong. I will check. 

Tim Josling

"Steven O. Ellis" wrote:
> 
> 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
>

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

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

[Steven O. E. <so...@so...>]

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

-- 
\/\/\/\/\/\/\/\/\/\/\/\/

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

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

Steven,
What I normally do is:
- put assertions in the code that will trigger when someone tries
to go past what's supported
- put a note in the code 
/* lll; this only supports usage display output areas that are
left aligned */

Every so often I do a grep on the source.

I also have "xxx;" but that is for things that have to be fixed
right away.

Or, if you register in sourceforge.net I could put you into the
project and you could put in a bug report; and I could also
record sub projects assigned to you, and give you cvs access,

Tim Josling


"Steven O. Ellis" wrote:
> 
> 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?

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

[Steven O. E. <so...@so...>]

Tim,

My sourceforge login is soellis.

Steven


Tim Josling wrote:
> 
> Steven,
> What I normally do is:
> - put assertions in the code that will trigger when someone tries
> to go past what's supported
> - put a note in the code
> /* lll; this only supports usage display output areas that are
> left aligned */
> 
> Every so often I do a grep on the source.
> 
> I also have "xxx;" but that is for things that have to be fixed
> right away.
> 
> Or, if you register in sourceforge.net I could put you into the
> project and you could put in a bug report; and I could also
> record sub projects assigned to you, and give you cvs access,
> 
> Tim Josling
> 
> "Steven O. Ellis" wrote:
> >
> > 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?
> 
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

-- 
\/\/\/\/\/\/\/\/\/\/\/\/

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

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

Steven,

Welcome! I have added you to the project. You should be able to
log on at http://sourceforge.net/ and the link to the project
should be down on the bottom left of the screen.

Please let me know if you plan to use the CVS upload, because if
you want to change any of the code other than the runtime (cobr*)
we need to get a copyright assignment to the FSF done, which
includes an employer disclaimer. This is so the compiler (as
opposed to the runtime) can be incorporated into GCC.

The unstring task is now assigned to you. It should also come up
in your task list.

Tim Josling

"Steven O. Ellis" wrote:
> 
> Tim,
> 
> My sourceforge login is soellis.
> 
> Steven
> 
> Tim Josling wrote:
> >
> > Steven,
> > What I normally do is:
> > - put assertions in the code that will trigger when someone tries
> > to go past what's supported
> > - put a note in the code
> > /* lll; this only supports usage display output areas that are
> > left aligned */
> >
> > Every so often I do a grep on the source.
> >
> > I also have "xxx;" but that is for things that have to be fixed
> > right away.
> >
> > Or, if you register in sourceforge.net I could put you into the
> > project and you could put in a bug report; and I could also
> > record sub projects assigned to you, and give you cvs access,
> >
> > Tim Josling
> >
> > "Steven O. Ellis" wrote:
> > >
> > > 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?
> >
> > _______________________________________________
> > 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

Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

[Steven O. E. <so...@so...>]

Thanks, Tim.  I see that unstring is now on my task list.
If I want to use CVS, I'll let you know.

Steven

Tim Josling wrote:
> 
> Steven,
> 
> Welcome! I have added you to the project. You should be able to
> log on at http://sourceforge.net/ and the link to the project
> should be down on the bottom left of the screen.
> 
> Please let me know if you plan to use the CVS upload, because if
> you want to change any of the code other than the runtime (cobr*)
> we need to get a copyright assignment to the FSF done, which
> includes an employer disclaimer. This is so the compiler (as
> opposed to the runtime) can be incorporated into GCC.
> 
> The unstring task is now assigned to you. It should also come up
> in your task list.
> 
> Tim Josling
> 
> "Steven O. Ellis" wrote:
> >
> > Tim,
> >
> > My sourceforge login is soellis.
> >
> > Steven
> >
> > Tim Josling wrote:
> > >
> > > Steven,
> > > What I normally do is:
> > > - put assertions in the code that will trigger when someone tries
> > > to go past what's supported
> > > - put a note in the code
> > > /* lll; this only supports usage display output areas that are
> > > left aligned */
> > >
> > > Every so often I do a grep on the source.
> > >
> > > I also have "xxx;" but that is for things that have to be fixed
> > > right away.
> > >
> > > Or, if you register in sourceforge.net I could put you into the
> > > project and you could put in a bug report; and I could also
> > > record sub projects assigned to you, and give you cvs access,

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.
>