cobolforgcc-devel — For discussion about development of COBOL for GCC

Re: [Cobolforgcc-devel] New code added

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

Bill,
I thought comp-6 was IBM for binary. I will check. It will be
optional, turned on by the -fibm option.
Tim Josling

"William M. Klein" wrote:
> 
> Tim,
>   I have seen you mention COMP-6 is a couple of notes.  Any chance that this
> was a "typo" for COMP-5?  If not, then COMP-6 is a "relatively" unused and
> non-portable USAGE.  The most common (that I know) definition of it is an
> UNSIGNED packed-decimal item.
> 
> COMP-5 is QUITE common in PC and UNIX COBOL's (as is - of course COMP-1,
> COMP-2, and COMP-3).
> 
> > -----Original Message-----
>  <snip>
> > Still to go, in order
> 
> > - pic [s]9(n) binary/comp-6.
> 
> _______________________________________________
> 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: FW: FW: [Cobolforgcc-devel] New code added

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

Bill,
Thanks, so it's a no op anywhere. I will just make it a warning
(non compliant with std),
Tim Josling

"William M. Klein" wrote:
> 
> After sending Tim the attached, I went to the IBM LRM and it states the
> following (in BLUE as an IBM extension),
> 
> "As an IBM extension, the EXIT statement does not need to appear in a
> sentence by
> itself. Any statements following the EXIT statement are executed; the EXIT
> statement is treated as the CONTINUE statement."

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

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

FW: FW: [Cobolforgcc-devel] New code added

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

After sending Tim the attached, I went to the IBM LRM and it states the
following (in BLUE as an IBM extension),

"As an IBM extension, the EXIT statement does not need to appear in a
sentence by
itself. Any statements following the EXIT statement are executed; the EXIT
statement is treated as the CONTINUE statement."

-----Original Message-----
From: William M. Klein
Sent: Thursday, April 12, 2001 5:10 PM
To: Tim Josling
Subject: RE: FW: [Cobolforgcc-devel] New code added


Tim,
  I just was recently reminded that both Micro Focus and IBM have a
"documented" extension allowing EXIT to *not* be the only statement in a
paragraph.  I have *not* yet figured out what they do with it when it isn't,
e.g.

  If A = "A"
     Display "This"
     Exit
  Else
    Display "That"
  End-If
  Display "Does this show up if A = 'A'?"
     .

> -----Original Message-----
> From: ti...@me... [mailto:ti...@me...]On Behalf Of Tim
> Josling
> Sent: Thursday, April 12, 2001 4:20 PM
> To: William M. Klein
> Subject: Re: FW: [Cobolforgcc-devel] New code added
>
>
> Bill,
>
> True - continue is a no-op. But I have to put some code in to
> warn if exit is not the only verb in a paragraph. IF is a
> different story - by the way I will be interested in some test
> cases for that but only using the compiler subset data types
>
> display pic x(n).
> binary/comp-6/comp pic 9(n).
> binary-char/short/long/double
> plus 88 levels for these types
>
> Not including
> - any special names things
> - any class tests (NUMERIC etc).
>
>
> Regards,
> Tim Josling
>
> "William M. Klein" wrote:
> >
> > (not posted) <JOKE>
> >   I think that even *I* could almost do CONTINUE and EXIT (if
> you mean the
> > '85 Standard EXIT - and not the "new" EXIT
> PARAGRAPH/SECTION/CYCLE stuff)
> >

RE: [Cobolforgcc-devel] New code added

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

Tim,
  I have seen you mention COMP-6 is a couple of notes.  Any chance that this
was a "typo" for COMP-5?  If not, then COMP-6 is a "relatively" unused and
non-portable USAGE.  The most common (that I know) definition of it is an
UNSIGNED packed-decimal item.

COMP-5 is QUITE common in PC and UNIX COBOL's (as is - of course COMP-1,
COMP-2, and COMP-3).

> -----Original Message-----
 <snip>
> Still to go, in order

> - pic [s]9(n) binary/comp-6.

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

[Cobolforgcc-devel] New code added

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

I have now added tested code for move including move
corresponding, and I have enhanced compute to support
exponentiation now.

The task list for the core compiler subset now includes all the
features that are needed for it so you can see how far I've
gotten so far.

Still to go, in order
- bug in initialiation of group items
- continue
- exit
- if
- perform
- 88 levels
- pic [s]9(n) binary/comp-6.
- call enter with parameters exit program and goback
- external data items
- user defined functions and function invocation
- function and program pointers

I think I am now a couple of months from having this all done,

Tim Josling

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

[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] FW: MOVE 2002

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

You're right (at least in the FCD).  The rule says,

"2) If a signed numeric literal is specified, the subject of the entry shall
be a signed numeric data item."

but does NOT say that the opposite is true.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Wednesday, April 11, 2001 4:13 PM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] FW: MOVE 2002
>
>
> As I read it you cannot specify a signed number for an unsigned
> data item. But a signed data item can have an unsigned number.
>
> But then again I am hopeless at reading standards.
>
> Tim Josling
>
> "William M. Klein" wrote:
> >
> > Tim,
> >  Sorry for not getting back to you sooner on this.  I believe
> that you are
> > correct that this is "underspecified" in the FCD.  There is no way to
> > determine HOW MANY "leading zeroes" are in the USAGE
> BINARY-LONG item before
> > its "conversion" which makes the "alignment rules" impossible
> to figure out.
> > It is clear that the "signed" phrase is "ignored" - but that
> doesn't really
> > answer your question.
> >
> > I plan on including this in my (last) Public Review comment -
> but you may
> > want to include it as well.
> >
> > P.S.  I haven't checked it - but your "VALUE" clause for V1 may not be
> > "conforming".  I can't remember if you can have an unsigned
> VALUE clause for
> > a USAGE BINARY-LONG SIGNED data item or not.  However, that wouldn't
> > "change" the impact of your question.
> >
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

Re: [Cobolforgcc-devel] FW: MOVE 2002

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

As I read it you cannot specify a signed number for an unsigned
data item. But a signed data item can have an unsigned number. 

But then again I am hopeless at reading standards.

Tim Josling

"William M. Klein" wrote:
> 
> Tim,
>  Sorry for not getting back to you sooner on this.  I believe that you are
> correct that this is "underspecified" in the FCD.  There is no way to
> determine HOW MANY "leading zeroes" are in the USAGE BINARY-LONG item before
> its "conversion" which makes the "alignment rules" impossible to figure out.
> It is clear that the "signed" phrase is "ignored" - but that doesn't really
> answer your question.
> 
> I plan on including this in my (last) Public Review comment - but you may
> want to include it as well.
> 
> P.S.  I haven't checked it - but your "VALUE" clause for V1 may not be
> "conforming".  I can't remember if you can have an unsigned VALUE clause for
> a USAGE BINARY-LONG SIGNED data item or not.  However, that wouldn't
> "change" the impact of your question.
>

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

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

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

[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

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

[Cobolforgcc-devel] FW: MOVE 2002

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

Tim,
 Sorry for not getting back to you sooner on this.  I believe that you are
correct that this is "underspecified" in the FCD.  There is no way to
determine HOW MANY "leading zeroes" are in the USAGE BINARY-LONG item before
its "conversion" which makes the "alignment rules" impossible to figure out.
It is clear that the "signed" phrase is "ignored" - but that doesn't really
answer your question.

I plan on including this in my (last) Public Review comment - but you may
want to include it as well.

P.S.  I haven't checked it - but your "VALUE" clause for V1 may not be
"conforming".  I can't remember if you can have an unsigned VALUE clause for
a USAGE BINARY-LONG SIGNED data item or not.  However, that wouldn't
"change" the impact of your question.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Tuesday, April 03, 2001 3:48 AM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] MOVE 2002
>
>
> Bill,
>
> The problem I have is that is says (p484 s14.10.24.3) "conversion
> of the sending operand to the internal representation takes
> place". That's good, but what sort of conversion?
>
> 01   v1 usage binary-long signed value 123.
> 01   v2 pic x(5).
> move v1 to v2.
>
> There are many ways to convert a binary number to an alphanumeric
> (see the C function printf for a list).
>
> The result could be:
>
> "123bb" (b=blank)
> or "00123"
> or "00000" (with the remaining digits 00123 truncated on the
> right, on the basis that the 32 bit integer gets converted to a
> 10 digit string because it needs that many characters to hold 32
> bit numbers in general).
>
> Pre-COBOL 2002, the problem probably did not exist as everything
> has a PIC, so the number of characters is defined.
>
> Reading the standard again, I find that the reverse situation
> *is* covered OK (ie move pic x(n) to binary-*). So moving "123"
> to a binary-char gets you 123, whereas moving "  123" gets you an
> error.
>

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

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

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

Bill,

The problem I have is that is says (p484 s14.10.24.3) "conversion
of the sending operand to the internal representation takes
place". That's good, but what sort of conversion?

01   v1 usage binary-long signed value 123.
01   v2 pic x(5).
move v1 to v2.

There are many ways to convert a binary number to an alphanumeric
(see the C function printf for a list).

The result could be:

"123bb" (b=blank)
or "00123"
or "00000" (with the remaining digits 00123 truncated on the
right, on the basis that the 32 bit integer gets converted to a
10 digit string because it needs that many characters to hold 32
bit numbers in general).

Pre-COBOL 2002, the problem probably did not exist as everything
has a PIC, so the number of characters is defined.

Reading the standard again, I find that the reverse situation
*is* covered OK (ie move pic x(n) to binary-*). So moving "123"
to a binary-char gets you 123, whereas moving "  123" gets you an
error.

Tim Josling


"William M. Klein" wrote:
> 
> I believe that the MOVE rules in the FCD are all written talking about
> "numeric" items as either INTEGER or NON-INTEGER.  The BINARY-xxxx items
> *are* integer,  the FLOAT-xxxx depend on whether or not STANDARD arithmetic
> is in effect and what the "evaluate" to.  Rules that "explicitly" talk about
> sign or non-signed depend on the "singed" phrase for BINARY-xxxx.  I believe
> that all the FLOAT-xxxx items are ALWAYS signed.
> 
> Is there some specific rule that you have a question about?
> 
> If you haven't already, look at the rules for "integers in general rules" on
> page 20 of the FCD.
> 
> > -----Original Message-----
> > From: cob...@li...
> > [mailto:cob...@li...]On Behalf Of Tim
> > Josling
> > Sent: Sunday, April 01, 2001 4:24 PM
> > To: cobolforgcc-devel
> > Subject: [Cobolforgcc-devel] COMPUTE and MOVE 2002
> >
> >
> > I have now implemented compute (compiler subset - no
> > overflow/size error; only the subset's supported data types).
> > Move is next.
> >
> > By the way Bill if you are reading this do you know what the
> > following code should do  (in COBOL 2002)?
> >
> > 01   v1 usage binary-char signed value 123.
> > 01   v2 pic x(5).
> >
> > move v1 to v2.
> > display "*" v2 "*".
> >
> > Is the answer the same if v1 is unsigned?
> >
> > how about this?
> >
> > move "00123" to v2
> > move v2 to v1
> > display v1.
> >
> > The description of move in the standards seems to assume a PIC is
> > present for all elementary data items, but this is not so for
> > binary-* and also for the floating point types which have a
> > similar issue.
> >
> > Tim Josling
> >
> > _______________________________________________
> > 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] COMPUTE and MOVE 2002

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

I believe that the MOVE rules in the FCD are all written talking about
"numeric" items as either INTEGER or NON-INTEGER.  The BINARY-xxxx items
*are* integer,  the FLOAT-xxxx depend on whether or not STANDARD arithmetic
is in effect and what the "evaluate" to.  Rules that "explicitly" talk about
sign or non-signed depend on the "singed" phrase for BINARY-xxxx.  I believe
that all the FLOAT-xxxx items are ALWAYS signed.

Is there some specific rule that you have a question about?

If you haven't already, look at the rules for "integers in general rules" on
page 20 of the FCD.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Sunday, April 01, 2001 4:24 PM
> To: cobolforgcc-devel
> Subject: [Cobolforgcc-devel] COMPUTE and MOVE 2002
>
>
> I have now implemented compute (compiler subset - no
> overflow/size error; only the subset's supported data types).
> Move is next.
>
> By the way Bill if you are reading this do you know what the
> following code should do  (in COBOL 2002)?
>
> 01   v1 usage binary-char signed value 123.
> 01   v2 pic x(5).
>
> move v1 to v2.
> display "*" v2 "*".
>
> Is the answer the same if v1 is unsigned?
>
> how about this?
>
> move "00123" to v2
> move v2 to v1
> display v1.
>
> The description of move in the standards seems to assume a PIC is
> present for all elementary data items, but this is not so for
> binary-* and also for the floating point types which have a
> similar issue.
>
> Tim Josling
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] COMPUTE and MOVE 2002

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

I have now implemented compute (compiler subset - no
overflow/size error; only the subset's supported data types).
Move is next.

By the way Bill if you are reading this do you know what the
following code should do  (in COBOL 2002)?

01   v1 usage binary-char signed value 123.
01   v2 pic x(5).

move v1 to v2.
display "*" v2 "*".

Is the answer the same if v1 is unsigned?

how about this?

move "00123" to v2
move v2 to v1
display v1.

The description of move in the standards seems to assume a PIC is
present for all elementary data items, but this is not so for
binary-* and also for the floating point types which have a
similar issue.

Tim Josling

Re: [Cobolforgcc-devel] GOTO

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

I am planning to do alter/alterable-goto but not for a while. It
is quite easy to implement using the GCC back end (GCC has an
'address of label' type).

I already support comment-entries (via the presprocessor).

Tim Josling

"William M. Klein" wrote:
> 
> Are you planning on doing ALTER/GO TO?  It is in the '85 Standard - but not
> in the draft of the next one.  My guess is that it is not only "ugly" for
> programmers to maintain application code - but also "ugly" to implement.
> 
> My personal suggestion would be that it should be "low" on any list of
> things to implement (along with all the other items that are EXPLICITLY
> "obsolete" in the '85 Standard - with the possible exception of
> "comment-entries" in the Identification Division.
> 
> > -----Original Message-----
> > From: cob...@li...
> > [mailto:cob...@li...]On Behalf Of Tim
> > Josling
> > Sent: Saturday, March 31, 2001 1:41 AM
> > To: cobolforgcc-devel
> > Subject: [Cobolforgcc-devel] GOTO
> >
> >
> > GOTO now works and is in the CVS on sourceforge, including goto
> > depending on.
> > Tim Josling

RE: [Cobolforgcc-devel] GOTO

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

Are you planning on doing ALTER/GO TO?  It is in the '85 Standard - but not
in the draft of the next one.  My guess is that it is not only "ugly" for
programmers to maintain application code - but also "ugly" to implement.

My personal suggestion would be that it should be "low" on any list of
things to implement (along with all the other items that are EXPLICITLY
"obsolete" in the '85 Standard - with the possible exception of
"comment-entries" in the Identification Division.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Saturday, March 31, 2001 1:41 AM
> To: cobolforgcc-devel
> Subject: [Cobolforgcc-devel] GOTO
>
>
> GOTO now works and is in the CVS on sourceforge, including goto
> depending on.
> Tim Josling
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] GOTO

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

GOTO now works and is in the CVS on sourceforge, including goto
depending on.
Tim Josling