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

[Cobolforgcc-devel] STRING Overflow Check

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

The overflow check for POINTER of zero was
wrapped in preprocessor code for DEBUG only.
I have removed this preprocessor code because
this is a standard overflow check.  Per the
standard, it is not a bug if POINTER is set
to zero, it is simply an OVERFLOW condition.

Attached is the revised file.  Tim, please
incorporate it into the CVS tree when you
have time.

Re: [Cobolforgcc-devel] Uninitialized pgm

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

Yes it's a bug. I have added 

pgm=$1;

after line 416

and I will upload the fix tomorrow.

Tim Josling

Keisuke Nishida wrote:
> 
> In cobcprs.tpl at line 416, the variable `pgm' is not initialized.
> Is this a bug?
> 
> 414: cobol_program_ended:
> 415: cobol_program end_program {
> 416:   struct cbl_tree_struct_program_top* pgm;
> 417:   pgm->end_program=$2;
> 
> Keisuke

[Cobolforgcc-devel] Re: GCC and COBOL

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

Yes send patches
Tim Josling

Keisuke Nishida wrote:
> 
> At Fri, 01 Jun 2001 06:56:52 +1000,
> Tim Josling wrote:
> >
> > I have talked to the gcc people about incorporating it into GCC.
> > I am following their coding standards etc to make that possible
> > and I also have a copyright assignment to the FSF and disclaimer
> > from my employer to that end.
> 
> It seems that your code does not follow GNU's C coding style
> in some places.  For example,
> 
>   Your code        GNU
> 
>   void* foo   -->  void *foo
>   foo(bar)    -->  foo (bar)
>   x=y         -->  x = y
> 
> May I fix them?
> 
> Keisuke

[Cobolforgcc-devel] Uninitialized pgm

[Keisuke N. <kx...@po...>]

In cobcprs.tpl at line 416, the variable `pgm' is not initialized.
Is this a bug?

414: cobol_program_ended:
415: cobol_program end_program {
416:   struct cbl_tree_struct_program_top* pgm;
417:   pgm->end_program=$2;

Keisuke

[Cobolforgcc-devel] [Fwd: GCC and COBOL]

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

Re: [Cobolforgcc-devel] COBOL compiler

[Keisuke N. <kx...@po...>]

At Mon, 28 May 2001 05:59:42 +1000,
Tim Josling wrote:
> 
> The simplest thing would be to do a small part of the cobol
> runtime. I can send you a spec if you like. None of the file IO
> has been done, sort-merge is partially done. Please let me know
> if you have any preferences. Let's start with something fairly
> small and then get more ambitious later on.

I'd like to study what has been done so far and what should be
done from now before actually starting out.  Could you send me
a list of unimplemented features (ToDo) if you have it?

> It could be helpful for you to give us some information on your
> programming background ie what languages you know, (C, COBOL?),
> do you know lex/flex and yacc/bison, do you have linux, have you
> used gcc, do you know any gcc internals. You don't need to know
> all or even most of these to be able to help, of course.

I've been a C programmer on GNU/Linux for five years.  I'd like to
run some COBOL programs on GNU/Linux and am studying COBOL right now.
Although I don't know much about lex/yacc/gcc internals, I'm going
to study them soon.

> It would also be helpful if you register on sourceforge.net as we
> can then track your work in the tasks tracking system.

My account is `knishida'.

Thanks,
Keisuke Nishida

Re: [Cobolforgcc-devel] COBOL compiler

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

Keisuke,

Help is always welcome!

The simplest thing would be to do a small part of the cobol
runtime. I can send you a spec if you like. None of the file IO
has been done, sort-merge is partially done. Please let me know
if you have any preferences. Let's start with something fairly
small and then get more ambitious later on.

It could be helpful for you to give us some information on your
programming background ie what languages you know, (C, COBOL?),
do you know lex/flex and yacc/bison, do you have linux, have you
used gcc, do you know any gcc internals. You don't need to know
all or even most of these to be able to help, of course.

It would also be helpful if you register on sourceforge.net as we
can then track your work in the tasks tracking system.

Thanks,
Tim Josling

Keisuke Nishida wrote:
> 
> At Sat, 26 May 2001 07:29:55 +1000,
> Tim Josling wrote:
> >
> > TC is being written in C, but CB4G will have much of the runtime
> > written in COBOL, using the core compiler subset.
> 
> Why do you need to write the runtime in COBOL?
> Isn't C a better language to write?
> 
> > One approach is to ask for a task from one project and then do
> > it. In free software projects generally there are more talkers
> > than coders but there are enough coders to get a lot done. Even a
> > small contribution is more help than you think!
> 
> Could you tell me a brief summary of what should be done next?
> I am a C programmer and about starting hacking GCC.
> 
> Thanks,
> Keisuke Nishida

RE: [Cobolforgcc-devel] COBOL compiler

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

Writing as much of the run-time in COBOL as possible

A) allows COBOL programmers (your "users") to participate in the development

B) Shows where "optimization" may be useful

C) provides an EXCELLENT ongoing "test suite"

  ***

NOTE: The MERANT (Micro Focus) compiler (actually "checker") is still
written in COBOL.

If you do NOT think it is a "good" language for such development, I question
(a little) why you think the project should be done at all.  COBOL *has
become* a "general purpose" language - not just a business language.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of
> Keisuke Nishida
> Sent: Sunday, May 27, 2001 5:16 PM
> To: Tim Josling
> Cc: cob...@li...
> Subject: Re: [Cobolforgcc-devel] COBOL compiler
>
>
> At Sat, 26 May 2001 07:29:55 +1000,
> Tim Josling wrote:
> >
> > TC is being written in C, but CB4G will have much of the runtime
> > written in COBOL, using the core compiler subset.
>
> Why do you need to write the runtime in COBOL?
> Isn't C a better language to write?
>
> > One approach is to ask for a task from one project and then do
> > it. In free software projects generally there are more talkers
> > than coders but there are enough coders to get a lot done. Even a
> > small contribution is more help than you think!
>
> Could you tell me a brief summary of what should be done next?
> I am a C programmer and about starting hacking GCC.
>
> Thanks,
> Keisuke Nishida
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

Re: [Cobolforgcc-devel] COBOL compiler

[<og...@li...>]

> Why do you need to write the runtime in COBOL?
> Isn't C a better language to write?

  Sometimes, COBOL is better language for COBOL runtime more than C.

  I'm writing TP monitor for COBOL (and mora many language), some
functions written in COBOL.

-- 
og...@ze...              ->  http://www.zetabits.com
Masami Ogoshi                     ->  http://www.nurs.or.jp/~ogochan/
HarvestHouse 702 2-16 Maruyama-cho Shibuya-ku Tokyo 150-0044 JAPAN

Re: [Cobolforgcc-devel] COBOL compiler

[Keisuke N. <kx...@po...>]

At Sat, 26 May 2001 07:29:55 +1000,
Tim Josling wrote:
> 
> TC is being written in C, but CB4G will have much of the runtime
> written in COBOL, using the core compiler subset.

Why do you need to write the runtime in COBOL?
Isn't C a better language to write?

> One approach is to ask for a task from one project and then do
> it. In free software projects generally there are more talkers
> than coders but there are enough coders to get a lot done. Even a
> small contribution is more help than you think!

Could you tell me a brief summary of what should be done next?
I am a C programmer and about starting hacking GCC.

Thanks,
Keisuke Nishida

Re: [Cobolforgcc-devel] COBOL compiler

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

I have not worked on the TinyCOBOL project, but I have been 
working on a couple of routines for CB4G for a few months.
My "day job" is COBOL developer.  The work I have been
doing for CB4G has been valuable to me in a number of ways.
It has made me more comfortable programming in C, which I
don't otherwise do very often.  It has been a good exercise
in the "extreme programming" style of testing, and it has 
given me the satisfaction of working on what is 
potentially a very stable and reliable product due to the 
emphasis on test cases to the emphasis on conforming with 
international COBOL standards.

Steven Ellis


Keisuke Nishida wrote:
> 
> Hello,
> 
> I'm interested in working on an open-source COBOL compiler.
> I've found two projects, TinyCOBOL and COBOL for GCC, and am
> wondering which project I should contribute.
> 
> It seems that TinyCOBOL is more active than COBOL for GCC,
> but I think the latter's approach (i.e., writing a GCC
> frontend) is preferable to the other (i.e., writing a full
> compiler).
> 
> So, my questions are:
> 
>   Is there any relationship between these projects?
>   Are these projects going to be integrated in any future?
>   How easy is it to get COBOL for GCC ready for practical use?
> 
> Thanks in advance.
> 
> --
> Keisuke Nishida
> 
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

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

Re: [Cobolforgcc-devel] COBOL compiler

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

The relationship between the projects is "friendly co-opetition"
I suspect we will end up sharing a large portion of the runtime
routines. The core compilers are completely seperate code bases
and will stay that way in my opinion.

If cobolforgcc is successful it should be a better compiler than
tiny cobol IMHO because it has access to the optimisation and
cross platform capabilities of the GCC back end. So if I had to
guess, I would say that the tiny cobol runtime and the
cobolforgcc core will survive long term. But it is hard to
predict. I get burned out every few months and take a break.

"Easy" is not the word to use for writing a cobol compiler.
Already CB4G is over 70,000 lines of code and we are not half way
yet. TC is about 25,000 lines of code but has a lot more
functionality.

If you are considering contributing, here are some differences:

Contributing to the TC core compiler is much less technically
difficult. GCC is very large and complex and for example it took
me two months of reading doco and code to get started with
integrating to the GCC back end which cobol4gcc uses. Also
contribuing to the core CB4G compiler requires you to have a
copyright assignment to the Free Software Foundation and if
needed a disclaimer from your employer or school.

CB4G requires a test case for every feature, but TC does not seem
to require this. A lot of people find writing tests boring, but
it is required by the extreme programming method used by CB4G and
to me it is essential. "If it hasn't been tested it doesn't
work". TC's model is more that use by users will test it better,
which is possibly true.

TC are freely making extensions whereas CB4G am just focussed on
getting a standards compliant compiler out the door.

TC is being written in C, but CB4G will have much of the runtime
written in COBOL, using the core compiler subset.

For either compiler, writing runtime code is not that hard, and
within the capabilities of most C programmers. 

I think I can say without fear of contradiction that Rildo is
more charismatic than I am, and has done a better job of
encouraging many people to contribute.

One approach is to ask for a task from one project and then do
it. In free software projects generally there are more talkers
than coders but there are enough coders to get a lot done. Even a
small contribution is more help than you think!

Tim Josling

Keisuke Nishida wrote:
> 
> Hello,
> 
> I'm interested in working on an open-source COBOL compiler.
> I've found two projects, TinyCOBOL and COBOL for GCC, and am
> wondering which project I should contribute.
> 
> It seems that TinyCOBOL is more active than COBOL for GCC,
> but I think the latter's approach (i.e., writing a GCC
> frontend) is preferable to the other (i.e., writing a full
> compiler).
> 
> So, my questions are:
> 
>   Is there any relationship between these projects?
>   Are these projects going to be integrated in any future?
>   How easy is it to get COBOL for GCC ready for practical use?
> 
> Thanks in advance.
> 
> --
> Keisuke Nishida
>

[Cobolforgcc-devel] COBOL compiler

[Keisuke N. <kx...@po...>]

Hello,

I'm interested in working on an open-source COBOL compiler.
I've found two projects, TinyCOBOL and COBOL for GCC, and am
wondering which project I should contribute.

It seems that TinyCOBOL is more active than COBOL for GCC,
but I think the latter's approach (i.e., writing a GCC
frontend) is preferable to the other (i.e., writing a full
compiler).

So, my questions are:

  Is there any relationship between these projects?
  Are these projects going to be integrated in any future?
  How easy is it to get COBOL for GCC ready for practical use?

Thanks in advance.

--
Keisuke Nishida

[Cobolforgcc-devel] Level 88s now supported.

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

I have uploaded the code and tests. Next: IF, then PERFORM.
Tim Josling

Re: [Cobolforgcc-devel] PIC [s]9(n) BINARY done. Figurative constants and ALL literal done.

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

That should read BINARY not COMP.

 Tim Josling wrote:
> 
> Code has been tested and uploaded to source forge.
> Tim Josling
> 
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] PIC [s]9(n) comp done. Figurative constants and ALL literal done.

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

Code has been tested and uploaded to source forge.
Tim Josling

Re: [Cobolforgcc-devel] New code added

[Fred M. <fr...@mo...>]

"William M. Klein" wrote:
> 
> Both of the VALUE with OCCURS clause "variations" were enhancements in the
> '85 Standard.  The '75 Standard did *not* allow both of those (as I recall).

The '75 standard did not allow a VALUE clause in an entry with the
OCCURS clause. It did, however permit a VALUE clause for a group field,
which can of course contain subordinate data items with an OCCURS
clause.

Regards,

Fred


> > From: cob...@li...
> > [mailto:cob...@li...]On Behalf Of Tim
> > Josling
> >
> > Thanks. I will have various options for comp, in which they get
> > translated into the internal comp format. It is amazing how
> > liitle I knew of COBOL after using it all these years.
> >
> > For example I didn't know you could do this:
> >
> > 01 x.
> >   02 y pic 999 value 123 occurs 100000.
> >
> > Even entry in the table gets set to 123.
> >
> > Or this
> >
> > 01 x value "ABC".
> >   02  xx pic x occurs 3.


-- 
Fred Mobach - fr...@mo... - pos...@mo...
Systemhouse Mobach bv - The Netherlands - since 1976

The Free Transaction Processing Monitor project : http://www.ftpm.org/

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,

[Cobolforgcc-devel] COntinue and Exit done

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

I've uploaded continue and exit. Next is pic 9(5) binary.
Tomorrow. I'm taking the rest of the day off.
Tim Josling

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

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] New code added

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

Both of the VALUE with OCCURS clause "variations" were enhancements in the
'85 Standard.  The '75 Standard did *not* allow both of those (as I recall).

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Friday, April 13, 2001 5:10 PM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] New code added
>
>
> Bill,
>
> Thanks. I will have various options for comp, in which they get
> translated into the internal comp format. It is amazing how
> liitle I knew of COBOL after using it all these years.
>
> For example I didn't know you could do this:
>
> 01 x.
>   02 y pic 999 value 123 occurs 100000.
>
> Even entry in the table gets set to 123.
>
> Or this
>
> 01 x value "ABC".
>   02  xx pic x occurs 3.
>
> Tim Josling
>
> "William M. Klein" wrote:
> >
> > IBM "traditionally" only supports
> >   COMP (binary on mainframe and PC / Packed-Decimal on OS/400)
> >   COMP-1 (short float)
> >   COMP-2 (long float)
> >   COMP-3 (packed decimal - all platforms)
> >   COMP-4 (binary - all platforms)
> >
> > "relatively recently" they have added support for COMP-5 as
> "true binary"
> > (no truncation to Picture) on PC and Mainframe (I don't know if OS/400
> > support this yet or not).  Other WinTel vendors also use COMP-5
> vs COMP to
> > distinguish "little-endian" vs "big-endian" Binary.   I don't
> (off the top
> > of my head) remember whether IBM's PC compiler also has this
> distinction.
> >
> >  COMP-6 as an "unsigned packed-decimal" came from RM (I think).
>  I know that
> > Micro Focus supports it (for compatibility with some other compiler) and
> > there may be some others that do as well.
> >
> > > -----Original Message-----
> > > From: cob...@li...
> > > [mailto:cob...@li...]On Behalf Of Tim
> > > Josling
> > > Sent: Friday, April 13, 2001 3:07 AM
> > > To: cob...@li...
> > > Subject: Re: [Cobolforgcc-devel] New code added
> > >
> > >
> > > 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
> > >
> > > _______________________________________________
> > > 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] New code added

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

Bill,

Thanks. I will have various options for comp, in which they get
translated into the internal comp format. It is amazing how
liitle I knew of COBOL after using it all these years. 

For example I didn't know you could do this:

01 x.
  02 y pic 999 value 123 occurs 100000.

Even entry in the table gets set to 123.

Or this

01 x value "ABC".
  02  xx pic x occurs 3.

Tim Josling

"William M. Klein" wrote:
> 
> IBM "traditionally" only supports
>   COMP (binary on mainframe and PC / Packed-Decimal on OS/400)
>   COMP-1 (short float)
>   COMP-2 (long float)
>   COMP-3 (packed decimal - all platforms)
>   COMP-4 (binary - all platforms)
> 
> "relatively recently" they have added support for COMP-5 as "true binary"
> (no truncation to Picture) on PC and Mainframe (I don't know if OS/400
> support this yet or not).  Other WinTel vendors also use COMP-5 vs COMP to
> distinguish "little-endian" vs "big-endian" Binary.   I don't (off the top
> of my head) remember whether IBM's PC compiler also has this distinction.
> 
>  COMP-6 as an "unsigned packed-decimal" came from RM (I think).  I know that
> Micro Focus supports it (for compatibility with some other compiler) and
> there may be some others that do as well.
> 
> > -----Original Message-----
> > From: cob...@li...
> > [mailto:cob...@li...]On Behalf Of Tim
> > Josling
> > Sent: Friday, April 13, 2001 3:07 AM
> > To: cob...@li...
> > Subject: Re: [Cobolforgcc-devel] New code added
> >
> >
> > 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
> >
> > _______________________________________________
> > 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] New code added

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

IBM "traditionally" only supports
  COMP (binary on mainframe and PC / Packed-Decimal on OS/400)
  COMP-1 (short float)
  COMP-2 (long float)
  COMP-3 (packed decimal - all platforms)
  COMP-4 (binary - all platforms)

"relatively recently" they have added support for COMP-5 as "true binary"
(no truncation to Picture) on PC and Mainframe (I don't know if OS/400
support this yet or not).  Other WinTel vendors also use COMP-5 vs COMP to
distinguish "little-endian" vs "big-endian" Binary.   I don't (off the top
of my head) remember whether IBM's PC compiler also has this distinction.

 COMP-6 as an "unsigned packed-decimal" came from RM (I think).  I know that
Micro Focus supports it (for compatibility with some other compiler) and
there may be some others that do as well.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Friday, April 13, 2001 3:07 AM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] New code added
>
>
> 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
>
> _______________________________________________
> 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...>]

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