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

Re: [Cobolforgcc-devel] Lisp for COBOL

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

> Tim, do you have any specific Lisp compiler in mind for the final GCC
> COBOL implementation?
> 
> -Tom
> 
> Tom Browder
> Niceville, Florida
> USA
> 

I am mainly using SBCL for development but I also test with gcl. SBCL is a
slower compiler but is more functionally complete (ANSI compliance) and
generates faster code. Gcl has better platform coverage including Microsoft
Windows. I will probably also see if I can get it going with the free
versions of the commercial list compilers. SBCL is a recent offshoot of CMU
Lisp so it should not be too hard to support CMU Lisp too.

Tim
Josling

Message sent using MelbPC WebMail Server

[Cobolforgcc-devel] Lisp for COBOL

[Tom B. <tom...@gm...>]

Tim, do you have any specific Lisp compiler in mind for the final GCC
COBOL implementation?

-Tom

Tom Browder
Niceville, Florida
USA

Re: [Cobolforgcc-devel] GCC Source Tree

[Tom B. <tom...@gm...>]

On Fri, Feb 22, 2008 at 11:15 PM, tim <te...@me...> wrote:
> Tom,
...
>  There are disadvantages to being in the GCC SVN so I want to get as as
>  far as I can before uploading the code there.

That makes sense, thanks.

-Tom

Re: [Cobolforgcc-devel] GCC Source Tree

[tim <te...@me...>]

Tom,

I'm not sure which version you are talking about - the original C
version or the new Lisp version.

The original version had code that was not assigned to the FSF. Also it
does not work with the current GCC trunk. I think both of these would be
show-stoppers. Normally they wait until the language is more or less
working before incorporating into the GCC SVC tree as a branch and then
at an appropriate time onto the trunk.

The lisp version is too early.

There are disadvantages to being in the GCC SVN so I want to get as as
far as I can before uploading the code there.

Tim Josling

On Fri, 2008-02-22 at 06:56 -0600, Tom Browder wrote:
> Tim, have you thought about getting the current cobol CVS tree
> converted and added to the GCC subversion tree now rather than waiting
> until you have everything else ready?
> 
> -Tom
> 
> Tom Browder
> Niceville, Florida
> USA
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] GCC Source Tree

[Tom B. <tom...@gm...>]

Tim, have you thought about getting the current cobol CVS tree
converted and added to the GCC subversion tree now rather than waiting
until you have everything else ready?

-Tom

Tom Browder
Niceville, Florida
USA

[Cobolforgcc-devel] Status

[Tom B. <tom...@gm...>]

Tim, I've kludged my way to compiling gcc/cobol/cobcbei.c where I've
met the tree crowd and haven't yet gotten past:

../../gcctrunk_with_cobol/gcc/cobol/cobcbei.c:2086: error: invalid
type argument of '->' (have 'int')
../../gcctrunk_with_cobol/gcc/cobol/cobcbei.c:2086: error: invalid
type argument of '->' (have 'int')
../../gcctrunk_with_cobol/gcc/cobol/cobcbei.c:2086: error: invalid
type argument of '->' (have 'int')

When I run into such I've tried to extract the trouble spot into a
little test program. But I'm now into a nest of tree macros (many
changes since 2002) and conflicting gcc headers that I'm having
trouble unravelling.  I'm thinking that I might be more useful at this
point by shifting gears and trying another project for a while:

  from the gcc site:
    Development->
      Open projects->
        projects for beginner GCC hackers->
          General code cleanliness->
            Disentangle the current web of header-header interdependencies.

I believe this will also help the cobol project, too.  What say you?

-Tom

BTW, I've added cobol.texi into the mix and have it producing pdf
along with the other gcc docs.

Re: [Cobolforgcc-devel] Build Process

[tim <te...@me...>]

> Re work on the build prcess

Tom,

Your work is useful because someone has to work out what's changed since
then and make the necessary changes. If it's not you it will be me. So
by your doing this it means when I get to working on the compiler proper
I will have a head start.

So it means the work is in parallel rather than serialised.

It is difficult because GCC is not very well documented, it's complex,
and it's inconsistent in the way things are done. It is though mostly a
lot better than it was 5 years ago, especially the documentation.

...I have the copy verb working now. The next step is the replace verb
which is largely a subset of copy. I have the parser for replace already
written and the actions as I mentioned are very similar to the existing
code for copy. 

This should take a few days to complete I think.

Then I need to to some retokenizing because the preprocessor lexical
structure differs somewhat from the main compiler's, and then I can
start work on the main compiler parser. I have the compiler lexical
analysis already working. 
The parser should take up to a week - I can reuse the bison grammar from
before. I just need to redo the actions.

Then there is some validation and cross-referencing of the created parse
tree.

This is a few days of work.

The I need to design the file format to pass to the gcc interface
routine. I need to write code to write (in lisp) the format and to read
it in C. That's a couple of days of work.

I am at a Linux conference most of next week. So I am probably about 3
weeks from starting work on the code generation using GCC.

I do appreciate your help, though it is always your decision whether
it's sustainable for you. I dropped work on the compiler for quite a few
years after my father died because I had to sort out some things and it
became very difficult to do both.

Tim Josling

Re: [Cobolforgcc-devel] Building Old Source - Questions

[tim <te...@me...>]

On Sat, 2008-01-19 at 12:57 -0600, Tom Browder wrote:
> Tim, I've run into a stumbling block that I think I can fix but the
> question is what is the best way to do it.
> 
> The problem is when the build process gets into the gcc/cobol
> directory and starts compiling some cob_* programs and we soon run
> into missing dependencies.
> 
> One situation as an example:
> 
> + one or more files include gcc/system.h which has a macro that
> redefines abort() as fancy_abort() which is NOT in any internal
> library but is defined in gcc/gcc.o
> 
> + solutions I can think of:
> 
>  - start a gcc/libfrontend.a library to capture such functions for use
> by cobol and other front ends (that would require some
> approval/coordination with gcc)
> 
>  - add a macro in gcc/system.h to undef the abort macro for COBOL
> (that would also require coop of gcc)
> 
>  - start a cobol run time library and include the function (overkill?)
> 
>  - start a cobol build time library and include necessary function dependencies
> 
>  - make a copy of gcc/system.h as gcc/cobol/system.h and modify it as
> necessary for the abort case (but there may be other dependencies)
> 
> I don't know which, if any, solution is best.   What I'm going to try
> first is modifying gcc/system.h to undef the abort macro and see how
> far I get.
> 
> In the words of Bill O'Reilly, "What say you?"
> 
> -Tom
> 
> Tom Browder
> Niceville, Florida
> USA

As a rule, try and avoid having to change the base gcc. 

As I mentioned in my other email you should be able to pick up their
fancy_abort from whereever they have it, in some *.o file. 

I would not be too concerned though about using some hacks to get things
going. Later on you can come back and do things "right".

Regards,
Tim Josling

Re: [Cobolforgcc-devel] Building Old Source - Questions

[Tom B. <tom...@gm...>]

On Jan 20, 2008 2:41 PM, Tim Josling <te...@we...> wrote:
...
> I've subscribed to the mailing lists from my development machine so I
> should turn around any further questions more quickly.

Great, although at the rate I'm going that won't make much difference.

I believe I have the autogen templates working now.  And I'll get the
fancy_abort thing working correctly according to your instructions
after I get though a stage1 compile successfully.

-Tom

Re: [Cobolforgcc-devel] Building Old Source - Questions

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

On Sun, 2008-01-20 at 07:19 -0600, Tom Browder wrote:
> On Jan 19, 2008 9:58 PM,  <te...@me...> wrote:
> ...
> > Which module is it trying to compile / link? If it's the main compiler cob1
> > then there must be an object file that contains fancy_abort. That would
> > need to be added to the list for linking.
> >
> > If it's the preprocessor then something needs to be done to make it not try
> > and call fancy_abort. For example, add #undef abort.
> 
> Thanks, that helps.
> 
> Now I'm fooling with the autogen files to bring them up to autogen 5
> syntax.  That is really fun!  I see the need for more gcc
> documentation for the gcc build process--maybe I can add to it later.
> 
> -Tom

I've subscribed to the mailing lists from my development machine so I
should turn around any further questions more quickly.

Tim Josling

Re: [Cobolforgcc-devel] Building Old Source - Questions

[Tom B. <tom...@gm...>]

On Jan 19, 2008 9:58 PM,  <te...@me...> wrote:
...
> Which module is it trying to compile / link? If it's the main compiler cob1
> then there must be an object file that contains fancy_abort. That would
> need to be added to the list for linking.
>
> If it's the preprocessor then something needs to be done to make it not try
> and call fancy_abort. For example, add #undef abort.

Thanks, that helps.

Now I'm fooling with the autogen files to bring them up to autogen 5
syntax.  That is really fun!  I see the need for more gcc
documentation for the gcc build process--maybe I can add to it later.

-Tom

Re: [Cobolforgcc-devel] Building Old Source - Questions

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

> Tim, I've run into a stumbling block that I think I can fix but the
> question is what is the best way to do it.
> 
> The problem is when the build process gets into the gcc/cobol
> directory and starts compiling some cob_* programs and we soon run
> into missing dependencies.
> 
> One situation as an example:
> 
> + one or more files include gcc/system.h which has a macro that
> redefines abort() as fancy_abort() which is NOT in any internal
> library but is defined in gcc/gcc.o
> 
> + solutions I can think of:
> 
>  - start a gcc/libfrontend.a library to capture such functions for use
> by cobol and other front ends (that would require some
> approval/coordination with gcc)
> 
>  - add a macro in gcc/system.h to undef the abort macro for COBOL
> (that would also require coop of gcc)
> 
>  - start a cobol run time library and include the function (overkill?)
> 
>  - start a cobol build time library and include necessary function
dependencies
> 
>  - make a copy of gcc/system.h as gcc/cobol/system.h and modify it as
> necessary for the abort case (but there may be other dependencies)
> 
> I don't know which, if any, solution is best.   What I'm going to try
> first is modifying gcc/system.h to undef the abort macro and see how
> far I get.
> 
> In the words of Bill O'Reilly, "What say you?"
> 
> -Tom
> 
> Tom Browder
> Niceville, Florida;;

Which module is it trying to compile / link? If it's the main compiler cob1
then there must be an object file that contains fancy_abort. That would
need to be added to the list for linking.

If it's the preprocessor then something needs to be done to make it not try
and call fancy_abort. For example, add #undef abort.

I had similar problems with malloc, which they kindly redefined. Many other
similarly evil things go on in gcc.

Tim
Josling

Message sent using MelbPC WebMail Server

[Cobolforgcc-devel] Building Old Source - Questions

[Tom B. <tom...@gm...>]

Tim, I've run into a stumbling block that I think I can fix but the
question is what is the best way to do it.

The problem is when the build process gets into the gcc/cobol
directory and starts compiling some cob_* programs and we soon run
into missing dependencies.

One situation as an example:

+ one or more files include gcc/system.h which has a macro that
redefines abort() as fancy_abort() which is NOT in any internal
library but is defined in gcc/gcc.o

+ solutions I can think of:

 - start a gcc/libfrontend.a library to capture such functions for use
by cobol and other front ends (that would require some
approval/coordination with gcc)

 - add a macro in gcc/system.h to undef the abort macro for COBOL
(that would also require coop of gcc)

 - start a cobol run time library and include the function (overkill?)

 - start a cobol build time library and include necessary function dependencies

 - make a copy of gcc/system.h as gcc/cobol/system.h and modify it as
necessary for the abort case (but there may be other dependencies)

I don't know which, if any, solution is best.   What I'm going to try
first is modifying gcc/system.h to undef the abort macro and see how
far I get.

In the words of Bill O'Reilly, "What say you?"

-Tom

Tom Browder
Niceville, Florida
USA

Re: [Cobolforgcc-devel] Old cobolforgcc Source

[Tom B. <tom...@gm...>]

On Jan 14, 2008 2:25 PM, tim <te...@me...> wrote:
> Tom,
>
> I should have said: It would be great to get the old version running on
> the current GCC code... at the right tim we can create a branch in cvs

OK, Tim, I've started doing that--I put the old code into the gcc
mainline tree and am trying to build it.

...
> ActuallY I am using git for tracking my developments. If you are up to
> speed with git, which is a very powerful tool, I can send you my git

Hm, I started looking at git during its initial days when it was
announced that Linus and gcc crew were renouncing BitKeeper, but I
didn't follow up seriously.  I'm looking at bazaar at the moment, but
I think git is fairly easy to use for basic stuff.

I'll keep chugging with the old code and send patches if I'm
successful.  I can get your current stuff later.

I'm sure I have a release on file with FSF (with my legal name: Thomas
M. Browder, Jr.), but I'm not sure I have one for my company.  Is
there a specific form (I hunted around gcc.org but couldn't find one)?

-Tom

Re: [Cobolforgcc-devel] Old cobolforgcc Source

[tim <te...@me...>]

Tom,

I should have said: It would be great to get the old version running on
the current GCC code... at the right tim we can create a branch in cvs
and give you commit access to the repository.

ActuallY I am using git for tracking my developments. If you are up to
speed with git, which is a very powerful tool, I can send you my git
repository. I need to find somewhere that hosts git developments I
think.

Regards,
Tim Josling

On Tue, 2008-01-15 at 07:15 +1100, tim wrote:
> Tom,
> 
> Just one point to be aware of. If you are going to make a substantial
> contribution (beyond a few lines of code) then we will need to arrange
> a copyright assignment to the Free Software Foundation by yourself for
> the work. 
> 
> This is so they can sue people who try to steal the code. 
> 
> That's normally not a problem, but they also require a disclaimer from
> your employer or school or college. This is if you are employed or
> studying.
> 
> Regards,
> Tim Josling
> 
> On Mon, 2008-01-14 at 06:42 -0600, Tom Browder wrote:
> > On Jan 12, 2008 4:28 PM, tim <te...@me...> wrote:
> > ...
> > > It is still there in the repository. You can extract it using the cvs
> > > tag "original-c-version".
> > ...
> > > cvs -z3 -d:pserver:ano...@co...:/cvsroot/cobolforgcc co  -r original-c-version  .
> > 
> > Ok, that works so I'll use it to work on building
> > --enable-languages=c,cobol,treelang
> > 
> > -Tom
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

Re: [Cobolforgcc-devel] Old cobolforgcc Source

[tim <te...@me...>]

Tom,

Just one point to be aware of. If you are going to make a substantial
contribution (beyond a few lines of code) then we will need to arrange
a copyright assignment to the Free Software Foundation by yourself for
the work. 

This is so they can sue people who try to steal the code. 

That's normally not a problem, but they also require a disclaimer from
your employer or school or college. This is if you are employed or
studying.

Regards,
Tim Josling

On Mon, 2008-01-14 at 06:42 -0600, Tom Browder wrote:
> On Jan 12, 2008 4:28 PM, tim <te...@me...> wrote:
> ...
> > It is still there in the repository. You can extract it using the cvs
> > tag "original-c-version".
> ...
> > cvs -z3 -d:pserver:ano...@co...:/cvsroot/cobolforgcc co  -r original-c-version  .
> 
> Ok, that works so I'll use it to work on building
> --enable-languages=c,cobol,treelang
> 
> -Tom

Re: [Cobolforgcc-devel] Old cobolforgcc Source

[Tom B. <tom...@gm...>]

On Jan 12, 2008 4:28 PM, tim <te...@me...> wrote:
...
> It is still there in the repository. You can extract it using the cvs
> tag "original-c-version".
...
> cvs -z3 -d:pserver:ano...@co...:/cvsroot/cobolforgcc co  -r original-c-version  .

Ok, that works so I'll use it to work on building
--enable-languages=c,cobol,treelang

-Tom

Re: [Cobolforgcc-devel] Old cobolforgcc Source

[tim <te...@me...>]

Tom,

It is still there in the repository. You can extract it using the cvs
tag "original-c-version".

Eg

cvs -z3
-d:pserver:ano...@co...:/cvsroot/cobolforgcc co  -r original-c-version  .

All on one line. Note the full stop at the end. I tested this so it
might work for you.

You can also browse it using cvs browse, under the COBOL directory.

By the way I am still making progress on the new version. The parser
generator using a special skeleton for bison to output lisp is working.
I am now working on the preprocessor (copy/replace verbs).

Regards,
Tim Josling

On Sat, 2008-01-12 at 06:04 -0600, Tom Browder wrote:
> On Jan 9, 2008 1:21 AM, tim <te...@me...> wrote:
> > Tom,
> >
> > That would be extremely useful, but it would not be a job for the
> > faint-hearted. As an example, I can't get vanilla GCC to build on my PC
> > at the moment on my PC.
> >
> > My intent is to start with "treelang" and add functionality to that. The
> > have kept treelang up to date while I have been away.
> 
> Tim, I just noticed that you killed all the old cobol code on
> sourceforge (and added the new lisp stuff), so does that mean I
> shouldn't try to get the old to build with current gcc mainline?  I
> can build the mainline treelang Ok (at least I could a few weeks ago).
> 
> BTW, the gcc I'm using for everything now (including Loki lib) is a
> 4.3 snapshot (4.3.0 20071109).  I've gotten it to build on some very
> old hardware (running FC2) as well as newer stuff under Fedora 7.
> 
> -Tom

Re: [Cobolforgcc-devel] Old cobolforgcc Source

[Tom B. <tom...@gm...>]

On Jan 9, 2008 1:21 AM, tim <te...@me...> wrote:
> Tom,
>
> That would be extremely useful, but it would not be a job for the
> faint-hearted. As an example, I can't get vanilla GCC to build on my PC
> at the moment on my PC.
>
> My intent is to start with "treelang" and add functionality to that. The
> have kept treelang up to date while I have been away.

Tim, I just noticed that you killed all the old cobol code on
sourceforge (and added the new lisp stuff), so does that mean I
shouldn't try to get the old to build with current gcc mainline?  I
can build the mainline treelang Ok (at least I could a few weeks ago).

BTW, the gcc I'm using for everything now (including Loki lib) is a
4.3 snapshot (4.3.0 20071109).  I've gotten it to build on some very
old hardware (running FC2) as well as newer stuff under Fedora 7.

-Tom

Re: [Cobolforgcc-devel] Old cobolforgcc Source

[Tom B. <tom...@gm...>]

On Jan 9, 2008 1:21 AM, tim <te...@me...> wrote:
> Tom,
>
> That would be extremely useful, but it would not be a job for the
> faint-hearted. As an example, I can't get vanilla GCC to build on my PC

Well, that keeps life from being dull, right!  I'll see what happens.

Happy New Year!

-Tom

Re: [Cobolforgcc-devel] Old cobolforgcc Source

[tim <te...@me...>]

Tom,

That would be extremely useful, but it would not be a job for the
faint-hearted. As an example, I can't get vanilla GCC to build on my PC
at the moment on my PC.

My intent is to start with "treelang" and add functionality to that. The
have kept treelang up to date while I have been away.

Regards,
Tim Josling

On Sun, 2007-12-30 at 15:38 -0600, Tom Browder wrote:
> Would it be of any value to the project (and plans) to use the
> existing CVS head and try to get it to build with the current gcc
> release?
> 
> -Tom
> 
> Tom Browder
> Niceville, Florida
> USA
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] Old cobolforgcc Source

[Tom B. <tom...@gm...>]

Would it be of any value to the project (and plans) to use the
existing CVS head and try to get it to build with the current gcc
release?

-Tom

Tom Browder
Niceville, Florida
USA

[Cobolforgcc-devel] std=MVS (was: several problem issues with 0.32

[Bill K. <wm...@ix...>]

Just out of curiosity, what "IBM" product is "std=mvs" SUPPOSED to "match"?

If it is VS COBOL II, then it should NOT treat "function" as a reserved
word.

If it is any LE-conforming compiler (SAA AD/Cycle COBOL/370, COBOL for
"this-or-that", or Enterprise COBOL), then it SHOULD treat "function" as a
reserved word (and issue a message indicating that OC is "missing support"
for Intrinsic Functions supported on the (IBM) mainframe.

What OO COBOL words are "reserved" (as well as what XML words) will ALSO
vary depending upon which IBM compiler is being emulated.

(for all the VARIOUS reserved words - much less syntax) differences, check
out the Micro Focus "reserved word" dialect options of:
   OSVS
   DOSVS
   VSC2(2)
   VSC2(3)
   VSC2(4)
   COBOL370
(and I may have missed some <G>)

> -----Original Message-----
> From: ope...@li... 
> [mailto:ope...@li...] On 
> Behalf Of Rich Painter
> Sent: Monday, June 20, 2005 4:25 PM
> To: ope...@li...
> Subject: [open-cobol-list] several problem issues with 0.32
> 
> I have several questions that may result in reporting bugs.
> 
> 1. warning issue- running:
> 	cobc --std=mvs -Icopy -c file.cob -o file.o
> 
> produces the following WARNING:
> file.cob: In paragraph '5050-CREATE-CBLOG':
> file.cob:299: warning: 'FUNCTION' not implemented
> 
> if this is a warning AND i have not specified any warnings to 
> be emitted then 
> why is this happening?
> 
> 2. c output issues- running:
> 	cobc --std=mvs -Icopy -c file2.cob -o file2.o
> 
> produces this:
> 
> /tmp/cobNVeQ2m.c: In function `ML001_':
> /tmp/cobNVeQ2m.c:31: error: `f' undeclared (first use in this 
> function)
> /tmp/cobNVeQ2m.c:31: error: (Each undeclared identifier is 
> reported only once
> /tmp/cobNVeQ2m.c:31: error: for each function it appears in.)
> /tmp/cobNVeQ2m.c:31: error: initializer element is not constant
> /tmp/cobNVeQ2m.c:31: error: (near initialization for 
> `h_TSQ_FILE.record_size')
> 
> 3. cobc segmentation fault- i get a cobc segmentation fault 
> compiling a 
> different file.  is there cobc make or configure options i 
> can set to make 
> certain that the most debugging info is available in the core 
> dump?  how do i 
> report this kind of error?
> 
> thanks,
> rich
> -- 
> 
> +---------------------------------------------------------------+
> | Richard A. Painter, P.E.      Phone 719 495 7054              |
> | Painter Engineering, Inc.     Mailto:pa...@ie...         |
> | 8470 Swan Rd.                 Amateur Mailto:ab...@ar...   |
> | Black Forest, CO 80908        LatLon: N39:1:41.1 W104:40:8.4  |
> |                                                               |
> | Visit our Web site:         http://painter.inc                |
> |         http://home.earthlink.net/~painterengineering         |
> |                                                               |
> | Computer and Software Forensics                               |
> | Systems & Software Engineering + LAN WAN Networking + X.25    |
> | INTERNET TCP-IP + Real-time Transaction Processing            |
> | System & Software Integration, Testing, Verification & Audits |
> | Web Hosting & Design + Apache + PHP + modSSL + cURL           |
> | Database Design & Applications + Oracle                       |
> | Benchmarks + Course & Workshop Development & Delivery         |
> | Financial and Medical Software Integration + Security         |
> | Middleware + EDI + Cryptography + Firewalls                   |
> | Embedded Hardware & Software Development                      |
> | UNIX + Linux + Windows                                        |
> |                                                               |
> | Those who would give up essential liberty to purchase a       |
> | little temporary safety, deserve neither liberty nor safety.  |
> | - Ben Franklin, Historical Review of Pennsylvania, 1759       |
> |                                                               |
> | If you think technology can solve your security problems then |
> | you don't understand the problems and you don't understand    |
> | the technology.        - Bruce Schneier                       |
> |                                                               |
> | Face it.  You have no privacy!   - Scott McNealy              |
> |                                                               |
> | For a successful technology, reality must take precedence     |
> | over public relations, for Nature cannot be fooled.           |
> |                 - Richard P. Feynman                          |
> |                                                               |
> | The future always arrives too soon and in the wrong order!    |
> |    - Alvin Toffler                                            |
> |                                                               |
> | What is popular is not always right and what is right is not  |
> | always popular.     - Howard Cosell                           |
> |                                                               |
> | Ned Ludd wasn't completely wrong!                             |
> |                                                               |
> | Chance favors the prepared mind!   Illegitima non carborundum |
> +---------------------------------------------------------------+
> 
> 

[Cobolforgcc-devel] RE: [open-cobol-list] INITIALIZE Question

[Bill K. <wm...@ix...>]

Maybe I am missing something, but I think this is "just a bug" in =
OpenCOBOL.
I believe the original INITIALIZE was a valid (ANSI/ISO conforming) use =
of
the statement with a DEFINED behavior - that OpenCOBOL is simply NOT =
doing.
(I haven't tried this myself to verify the reported results).

When it comes to "undefined" or "extension" behavior, then you get into
"which do you want".  However, INITIALIZE of a GROUP-ITEM *must* =
initialize
all non-FILLER items of "standard defined" (i.e. not POINTER) USAGES.

> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...] On=20
> Behalf Of Alain Lucari
> Sent: Thursday, June 02, 2005 5:24 PM
> To: ope...@li...
> Subject: Re: [open-cobol-list] INITIALIZE Question
>=20
> Hi all,
>=20
> In my idea, the error is to think that=20
> you can have ONE cobol compiler wich do
> the same that many others.
>=20
> If you change your compiler from *M*F* to
> *Acu* or *Acu* to *M*F* or others
> YOU CAN CHANGE SOMETINGS IN YOURS CODE
>=20
> Keisuke is very good (many guys have tried=20
> to made a cobol compiler but nobody have a
> a good result) but I think that it is not possible
> to emulate all the cobol compilers in one
> or, at less too much difficult.
>=20
> So, if you would use Open-Cobol, do the
> same thing that you must do if you change,
> "with some money", from a "commercial" compiler for an other :
> test your code and do what is necessary.
>=20
> Other thing : it is so easy with O-C to call
> "system" that I don't undertand for what you are=20
> so excited about something like "intrinsic functions"
> this is not easy with any commercial compiler.
>=20
> Ok, it is good if this work (for how many peoples)
> but if you destroy the compiler what is the benefit ?=20
>=20
> Le Thu, 2 Jun 2005 19:00:51 +0200
> Gue...@sm... a =E9crit:
>=20
> >=20
> > Hello All,
> >=20
> > I wonder if the INITIALIZE works correctly.
> >=20
> > The output is different using mf instead of OpenCobol:
> >=20
> > using mf (windows):
> > MEM-LAST-I (1)=3D+0000
> > MEM-LAST-I (2)=3D+0000
> >=20
> > using OpenCobol:
> > MEM-LAST-I (1)=3D+8224
> > MEM-LAST-I (2)=3D+0000
> >=20
> >=20
> > Kind regards
> > Guenter
>=20
> Best regards,
> --=20
> Alain Lucari (Eurlix)
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit=20
> http://developer.yahoo.net/?fr=3Dfad-ysdn-ostg-q22005
> _______________________________________________
> open-cobol-list mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>=20

[Cobolforgcc-devel] SIZE ERROR with no SIZE ERROR specified in code

[Bill K. <wm...@ix...>]

There is a difference between the '85 and '02 Standards for what happens
when a "SIZE ERROR" condition occurs and no ON SIZE ERROR phrase is
specified.

From page 814 of the '02 Standard (list of substantive changes),

"15) Size error condition with no SIZE ERROR phrase. If a size error
condition occurs, the statement in which it occurs contains no SIZE ERROR or
NOT SIZE ERROR phrase, and there is no associated declarative, the
implementor defines whether the run unit is terminated or execution
continues with incorrect values.

Justification:
In the previous COBOL standard, the rules for size error stated that
execution would continue with undefined values, but it was not clear where
execution would continue, particularly in conditional statements.
Additionally, continued execution with incorrect results was not acceptable
for many critical applications, where it might cause corruption of
databases, incorrect continued execution of the program, and potentially a
multitude of additional errors. It was prohibitive to modify programs to add
ON SIZE ERROR for every affected statement. Responding to user requirements,
several implementors terminated execution of the program in this situation;
in some cases, the implementor allowed selection of termination based on a
compiler directive. The number and criticality of applications that
terminated in this situation provides strong justification for this change.
It is expected that this change will have little impact on existing programs
because implementors are free to continue or terminate, in accordance with
their implementation of the previous COBOL standard."

NOTE WELL:
  To test how your (non-OC) COBOL compiler works, check out a DIVIDE-BY-ZERO
with no ON SIZE ERROR specified.