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

[Cobolforgcc-devel] Re: possibly bug: Compare: numeric (USAGE COMP ...) with alphanumeric

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

I now agree with your evaluation that the 2002 Standard (like the '85
Standard) does NOT allow the comparison of a integer data item and an
alphanumeric (or national) item UNLESS the integer item is USAGE DISPLAY =
or
National.

Where I looked was in the paragraph:

 8.8.4.1.1 Relation conditions

which (on page 127) states that it legal to have a comparison between:

6) Two operands where one is a numeric integer and the other is class
alphanumeric or national.

However, the paragraph that you quote from

 8.8.4.1.1.4 Comparison of a numeric integer operand with an operand of
class alphanumeric or national

on page 128 does add an ADDITIONAL restriction that

 "The numeric integer operand shall be an integer literal or an integer
numeric data item of usage display or national."

It isn't particularly unusual for the Standard to have a "general"
description which is LATER "further restricted".  I had simply missed =
that
additional restriction.

P.S.  I think the rules for comparisons for integer numeric items and
alphanumeric or national items is "clear" and would work as an EXTENSION
when the integer item is of "any" USAGE.  However, if that is supported =
in
OpenCOBOL - it should receive an "extension" flag. =20

> -----Original Message-----
> From: Thomas Biehler [mailto:tob...@us...]=20
> Sent: Tuesday, May 18, 2004 6:39 AM
> To: William M. Klein
> Cc: Keisuke Nishida
> Subject: Re: [open-cobol-list] Re: possibly bug: Compare:=20
> numeric (USAGE COMP ...) with alphanumeric
>=20
> On Monday 17 May 2004 21:53, you wrote:
> > I agree with you that the '85 Standard does *not* allow for=20
> a comparison
> > between a numeric (non-DISPLAY) item and an alphanumeric=20
> item.  This should
> > get a "flaggint" (extension) message when done.
> >
> > However, the 2002 Standard eplicitly says,
> >
> > "Two operands where one is a numeric integer and the other is class
> > alphanumeric or national.'
>=20
> Ooops. !?
> At which paragraph in the ISO 2002 Standard stands this sentence?
> >
> > Is allowed.  Have I missed some place in the 2002 Standard=20
> that disallows
> > such comparions (as you indicate)?
> >
>=20
> Yes, i think so.
> I have showed it in my answer mail to Roger While from 08.05.2004.
> If you are not a subscriber of the open-cobol mailinglist you can=20
> found it in the mail-archive at sourceforge.=20
>=20
> It follows the cruical excerpt of the ISO Standard 2002=20
> (Especially the first sentence of =A7 8.8.4.1.4 is significant!)
>=20
> ISO/IEC 1989:2002(E)=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> =A78.8.4.1.1.4  Comparsion of a numeric integer operand with=20
>                    an operand of class alphanumeric or national
>=20
>   The numeric integer operand shall be an integer literal or=20
>   integer numeric data item of usage display or national .... =20
>  =20
>   --> is now absolut clear and much easier to unterstand as=20
> in ANSI 1985 !
>=20
> Thomas
>=20
>=20
>=20

[Cobolforgcc-devel] [off-topic] test

[Hudson R. <hu...@ti...>]

Test, please ignore.

Hudson
------------------------------------------------------------------------
Hudson Reis                                  http://hudson.tinycobol.org

[Cobolforgcc-devel] off-topic - Test please ignore

[Hudson R. <hud...@gm...>]

[Cobolforgcc-devel] Next (post 2002) ISO COBOL Standard

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

To: comp.lang.cobol - and others:

As a result of the recent J4 and WG4 meetings (and "Future of COBOL"
workshop), there is now a "definitive" list of what is INTENDED to be in =
(or
at least investigated for) the next ISO COBOL Standard - now "scheduled" =
for
2008.

The following are the relevant agenda items from:

   http://www.cobolportal.com/j4/files/03-0168.doc

"17.       Develop ISO 1989:2008 - must do items
            17.1      @Dynamic tables (Piggott+Karlin/Nutsford)
            17.2      @Function pointers (Bennett)
            17.3      @Variable length data items
(Piggott+Ebbinkhuijsen/Nutsford)
            17.4      @Function pointers (Bennett)
            17.5      @Increase size limit on non-numeric literals
(Ebbinkhuijsen)
            17.6      @Locale on upper and lower case functions =
(Bennett)
            17.7      @Structured constants (Stevens)
            17.8      @Pipes (Lanam+Klink)
            17.9      @Increase minimum maxima for record locks
(Grealish+Ebbinkhuijsen)
            17.10    @Function for current date in ISO-standard format
(Ebbinkhuijsen+Grealish)
            17.11    03-0166 - Eliminate Cryptic Ref to "Hardware" in =
ACCEPT
Rules (Stevens)
            17.12    03-0167 - Allow <> As Synonym for NOT EQUAL TO
(Stevens)
            17.13    @PAGE clause corrections (00-0581) (?Bennett)
            17.14    @Clarification of 8.4.1.1, Qualification, =
especially
rule 4 (????)

18.       Develop ISO 1989:2008 - investigate and include if feasible in =
the
time frame
            18.1      @Asynchronous processing (?Lanam?)
            18.2      @Command line and environment variables (Klink)
            18.3      @Method overloading (Karlin)"

For some "background" on how both J4 and WG4 "ranked" features for this =
next
revision, see:

     http://www.cobolportal.com/j4/files/s16.doc

Also expected to be "rolled into"  the 2008 ISO COBOL Standard are the
following "features" for which ISO TR (Technical Reports) will be =
available
in ADVANCE of 2008:

 - Finalizer (for Objects) - (this TR has already been approved by JTC1)
 -  native syntax for XML support
        schedule at: http://www.cobolportal.com/j4/files/03-0161.doc
 - collection classes
        schedule at: http://www.cobolportal.com/j4/files/03-0162.doc

To see the "approved" (well the final draft of what was approved) copy =
of
the FINALLIZER TR, go to:

      http://www.cobolportal.com/j4/files/03-0046.doc

Related to the issue of "native syntax for XML support", I (personally)
found the following statement from:

     http://www.cobolportal.com/j4/files/03-0117.doc

to be particularlly interesting:

"15.1     @02-0246 - XML classes (Schricker)
J4 considers at this time that native syntax for XML is of greater use =
to
the general COBOL community than an XML class library.  J4 will consider =
an
XML class library at a later date."

    ***

Finally, it should be noted that just because an item from S-16 (see =
above)
is NOT scheduled for the 2008 ISO Standard, this does NOT mean that it =
won't
be considered for a "future" Standard.


--=20
Bill Klein
 wmklein <at> ix.netcom.com

[Cobolforgcc-devel] ANSI and ISO COBOL news

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

From the Chair of J4 (who is also the convenor of WG4)

"I don't think most of you know that the Finalizer TR was approved by JTC1
without comments.  The project editor has made the necessary changes, such
as removal of the word "draft" and the document has been forwarded for
publication.

Also of interest - ANSI has adopted the ISO COBOL standard and will be
selling the PDF version for 18 USD in the near future.

Don"

--
Bill Klein
 wmklein <at> ix.netcom.com

[Cobolforgcc-devel] manufacturer of garments and bags in China

[Rachel <ra...@pu...>]

Dear Sir or Madam,  

I have the pleasure to know your esteemed Corp. 

We are a manufacturer of garments and bags in Quanzhou, China.

I think we can cooperate and supply you with garments and bags as you need.  

The following is some introductions about our company.

       Set up: 1988

       Type: manufacturer & exporter

       Product: knitted garments and bags

       Employees: 1300 persons ( garments factory: 500      bags factory: 800)

       Product data:       

                                  product (main items)                      capacity(/year)

                                  brief                                    2,000,000dzs    

                                  baby body                                1,800,000dzs

                                  boxer short                                200,000dzs

                                  pajama                                      50,000dzs

                                  soft bag                                 1,500,000pcs

                                  hard bag                                   500,000pcs

Mimn order:  300dzs for garments 
               
             500pcs for bags


Payment:  irrevocable L/C at sight


Our garment factory mainly specialize in Lady's and men's underwear,

children's wear, baby's wear, pajama, boxer shorts, T-shirt, etc. 

The materials we often use are cotton, T/C, Polyester, Polyamide, 

Elasthan, and Polyamide. Our products are design with PAD system, 

produced with advanced equipment, processed in highly quality control 

system with seasoned workmanship and high efficiency. Our main market 

is Europe, Australia, Japan. We also accept the orders designed 

and required by costumers.  


Our bag factory was founded in 1988, too. We produce all kinds of bags, 

including suitcase, backpack, travel bag, shoulder bag, sport bag, trolley, 

camera bag, tote bag, school bag, computer case, luggage,waist bag, notecase, etc. 

And the goods have met a great favor in the Europe countries, Australia 

and America because of their good quality, beautiful design and competitive price.


Thank you very much. Hope you will give us an opportunity to do 

business together and we will try our level best to fulfill your present 

requirement. Should you therefore need any more details for your 

clarification, pls do not hesitate to contact us. And you are welcome 

to visit our factories.


With best regards


Rachel Wang

Mob:0086-13960286700


Jason Chen

Mob:0086-13959893400


Vicki Wang

Mob:0086-13960228599


-----------------------------------------------------------------------------

SENWER GARMENTS CO., LTD.

ADD: Room F202, Fugui Renjia Building, Liuguan Road, Quanzhou, Fujian, China.

Tel: 0086-595-2506700    Fax: 0086-595-2563400    P.C.:362000

E-mail: ra...@pu...

-----------------------------------------------------------------------------

[Cobolforgcc-devel] RE: What is the future of COBOL? Answer: Irrelevant???

[Thane H. <th...@so...>]

For your reading pleasure. 

http://www.eweek.com/article2/0,3959,1098146,00.asp



--------------------
Everything I need to know about debugging I learned from Sesame Street.

[Cobolforgcc-devel] RE: What is the future of COBOL? Answer: Irrelevant???

[Thane H. <th...@so...>]

I'm not going to get into a war with you.  I think you erroneously see a 
departure from COBOL - I don't see that at all - in fact I see failed attempts 
at departure where in the end they RETURNED to COBOL and got the results they 
desired in the first place.  I have FIRST hand experience to the back this up.  
The world if IT is still expanding - COBOL use is expanding.  Considering the 
audience of this message, I'm not going to speak to the Fujitsu specific issues 
- these are trade secrets and the release of any such information could have an 
impact on future competitive advantage.

But - while we are throwing wood on the fire.  Let's talk about the Lattice C 
compiler or maybe Borland or Watcom?  I don't see COBOL vendors drying up at 
the rate I see C/C++ compilers going away.

On 23 May 2003 at 17:17, William M. Klein wrote:

> Please be advised that replying to this message goes to the sender. If you wish
> to send a reply to all on the list, please respond with "Reply All".
> _____________ Thand,
>  So, is the vendor that you represent on J4 going to implement the full 2002
> COBOL Standard? Have they made ANY "statement of direction" to that effect? Is
> that vendor finding COBOL to be a profitable product in the Windows, Unix, or
> Linux environmens? What is their "staffing" level like - growing or shrinking or
> staying the same? 
> 
> Actually, the years 1990 to 1993 (to use your years) was a time of
> SIGNIFICNT new releases of COBOL. (Several vendors came out with their
> "high-level" '85 Standard compilers during that period of time.  Others
> introduced their versions with Intrinsic Function support then.)
> 
> As of this momement (and I certainly could be wrong on this), ONLY the
> Siemens portion of Fujitsu (which is not the part that I believe you
> represent on J4) and Micro Focus have made ANY public commitment to 2002
> conforming compilers.  Micro Focus initially indicated that there "next"
> release would be conforming, but when their V4 product came out, they only
> claim conformance to the OO porition of the 2002 Standard.
> 
> I did indicate and I do believe that many of the existing vendors will
> continue producting new releases/versions with new features.  I just don't
> think that those release will stem the flow AWAY from COBOL.
> 
> > -----Original Message-----
> > Hogwash.
> > 
> > Especially this part:
> > 
> > > question of "Is COBOL a dynamic/growing programming 
> > environment?" seems to
> > > warrant an equally strong "NO" as an answer.
> > 
> > There have been more new COBOL releases by a variety of 
> > vendors RECENTLY than 
> > in the same time frame 10 years ago. (say 1990-1993).   In 
> > the last few years 
> > the gap between what you can do with COBOL and what you can 
> > do with other 
> > languages has narrowed considerably.  It isn't because the 
> > other environments 
> > are becoming static or shrinking - it's because COBOL is 
> > dynamic and growing.
> > 
> > Yes - COBOL Expo got cancelled (Postponed).  Don't blame COBOL.
> > 
> > On 23 May 2003 at 16:16, William M. Klein wrote:
> > 
> > > Please be advised that replying to this message goes to the 
> > sender. If you wish
> > > to send a reply to all on the list, please respond with "Reply All".
> > > _____________
> > >  J4 and WG4 posed the question "What <is> your vision for 
> > the COBOL language 5
> > > years from now?"
> > > 
> > > Although, I haven't heard it officially yet, I believe that 
> > I have heard it from
> > > sufficiently "reliable sources" that CobolExpo 2003 (for 
> > June in Las Vegas) is
> > > now canceled.  I also BELIEVE that as of this moment, the 
> > "forum on the future
> > > of COBOL" is still planned to take place that week in Las 
> > Vegas.  Anyone already
> > > planning on attending the forum (originally in addition to 
> > the CobolExpo) should
> > > verify exactly what the plans are for it.
> > > 
> > > HOWEVER, the major reason that I am posting this note to a 
> > few groups and
> > > lists is that I really think that "we all" need to step up 
> > to the actual
> > > answer to the question of where COBOL will be 5 years from 
> > now - and the
> > > answer is close to (but not quite) irrelevant.
> > > 
> > > I *strongly* believe that there will still be COBOL 
> > compilers (even some
> > > with new releases, new features, and new interfaces) - not 
> > only 5 years from now
> > > but even 10 years from now.
> > > 
> > > I even believe (from some documents submitted to J4) that 
> > there MAY be one
> > > or two compilers that conform (at least mostly) to the 2002 
> > ISO COBOL
> > > Standard.
> > > 
> > > I suspect that there will even be new and "upgraded" COBOL 
> > applications that use
> > > NEW features introduced in the 2002 COBOL Standard - and 
> > some of the TR's
> > > (Technical Reports) currently being worked on by J4 and WG4.
> > > 
> > >     ON THE OTHER HAND,
> > > 
> > > The following are some of my "crystal ball" visions 
> > (whether "fears" or
> > > simply "forebodings")
> > > 
> > > 1) I expect that MOST COBOL compilers will use the 2002 ISO 
> > Standard (and
> > > the TR's - if approved) as a "Chinese menu" and will "pick 
> > and choose" which of
> > > the (required - not just processor dependent) features they 
> > ever implement.
> > > 
> > > 2) COBOL will NEVER be a *major* player in the "user-side" 
> > of the web or
> > > server application environment. (Which is NOT to say that 
> > there won't be
> > > some new - as well as continued - applications that do this.)
> > > 
> > > 3) New "businesses" doing data processing or existing 
> > businesses creating
> > > NEW applications will *only* select COBOL as their 
> > "programming language of
> > > choice" in infrequent and unusual circumstances.
> > > 
> > > 4) Sites with existing COBOL applications will increase their
> > > "consideration" of language conversions away from COBOL 
> > when they do "major
> > > maintenance" or new functionality to those programs.
> > > 
> > > 5) Membership in J4 and WG4 will continue to "decrease" 
> > with NO new COBOL
> > > vendors joining J4; no new countries joining WG4; and those 
> > doing the "real
> > > work" of the committees continuing to be limited to a VERY 
> > SMALL handful of
> > > individuals (not vendors or user companies).
> > > 
> > > 6) There never will be robust  "certification tests" for 
> > the 2002 ISO
> > > Standard - and the US government (along with European and 
> > Asian governmental
> > > bodies) will NEVER require "2002 conforming" compilers.  
> > (And possibly they will
> > > even - within the next 10 years - drop COBOL as a 
> > "authorized" programming
> > > language for new projects - in cases where they have a list 
> > of such authorized
> > > programming "languages" or "tools").
> > > 
> > >         ***
> > > 
> > > Bottom-Line:
> > >   I will continue to "post" to newsgroups and others the 
> > information of what is
> > > happening with "development" and "maintenance" of the COBOL 
> > language by various
> > > Standards groups.  I think it is important that all 
> > existing COBOL programmers
> > > "keep abreast" of what is or might be happening or going to happen.
> > > 
> > > OTOH,  I can't see - unless something DRAMATICALLY changes 
> > - that COBOL will be
> > > seen as a GROWING programming environment.  Certainly the 
> > 30-year old question
> > > of "Is COBOL dead?" still deserves an answer of NO.  On the 
> > other hand, the
> > > question of "Is COBOL a dynamic/growing programming 
> > environment?" seems to
> > > warrant an equally strong "NO" as an answer.
> > > 
> > > OBVIOUSLY, this post reflects PERSONAL OPINION only.  I 
> > wouldn't mind being
> > > proven wrong - but I won't hold my breath either.
> > > 
> > > --
> > > Bill Klein
> > >  wmklein <at> ix.netcom.com
> > > 
> > > 
> > > 
> > > 
> > > ________
> > > This mailing list may not be used for unlawful purposes. 
> > All postings should be
> > > relevant, but ITI accepts no responsibility for any posting 
> > and may terminate
> > > access to any subscriber violating any policies of the 
> > Association. Please
> > > review the INCITS Antitrust Guidelines at 
> > <http://www.incits.org/natrust.htm>.
> > > 
> > 
> > 
> > ---
> > COBOL - Immune 
> > to buffer overflows
> > 
> > 
> > 
> > ________
> > This mailing list may not be used for unlawful purposes. All postings 
> > should be relevant, but ITI accepts no responsibility for any 
> > posting and 
> > may terminate access to any subscriber violating any policies of the 
> > Association. Please review the INCITS Antitrust Guidelines at 
> > <http://www.incits.org/natrust.htm>.
> > 
> 
> 
> 
> ________
> This mailing list may not be used for unlawful purposes. All postings should be
> relevant, but ITI accepts no responsibility for any posting and may terminate
> access to any subscriber violating any policies of the Association. Please
> review the INCITS Antitrust Guidelines at <http://www.incits.org/natrust.htm>.
> 


--------------------
Everything I need to know about debugging I learned from Sesame Street.

[Cobolforgcc-devel] RE: What is the future of COBOL? Answer: Irrelevant???

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

Thand,
 So, is the vendor that you represent on J4 going to implement the full =
2002
COBOL Standard? Have they made ANY "statement of direction" to that =
effect?
Is that vendor finding COBOL to be a profitable product in the Windows,
Unix, or Linux environmens? What is their "staffing" level like - =
growing or
shrinking or staying the same?=20

Actually, the years 1990 to 1993 (to use your years) was a time of
SIGNIFICNT new releases of COBOL. (Several vendors came out with their
"high-level" '85 Standard compilers during that period of time.  Others
introduced their versions with Intrinsic Function support then.)

As of this momement (and I certainly could be wrong on this), ONLY the
Siemens portion of Fujitsu (which is not the part that I believe you
represent on J4) and Micro Focus have made ANY public commitment to 2002
conforming compilers.  Micro Focus initially indicated that there "next"
release would be conforming, but when their V4 product came out, they =
only
claim conformance to the OO porition of the 2002 Standard.

I did indicate and I do believe that many of the existing vendors will
continue producting new releases/versions with new features.  I just =
don't
think that those release will stem the flow AWAY from COBOL.

> -----Original Message-----
> Hogwash.
>=20
> Especially this part:
>=20
> > question of "Is COBOL a dynamic/growing programming=20
> environment?" seems to
> > warrant an equally strong "NO" as an answer.
>=20
> There have been more new COBOL releases by a variety of=20
> vendors RECENTLY than=20
> in the same time frame 10 years ago. (say 1990-1993).   In=20
> the last few years=20
> the gap between what you can do with COBOL and what you can=20
> do with other=20
> languages has narrowed considerably.  It isn't because the=20
> other environments=20
> are becoming static or shrinking - it's because COBOL is=20
> dynamic and growing.
>=20
> Yes - COBOL Expo got cancelled (Postponed).  Don't blame COBOL.
>=20
> On 23 May 2003 at 16:16, William M. Klein wrote:
>=20
> > Please be advised that replying to this message goes to the=20
> sender. If you wish
> > to send a reply to all on the list, please respond with "Reply All".
> > _____________
> >  J4 and WG4 posed the question "What <is> your vision for=20
> the COBOL language 5
> > years from now?"
> >=20
> > Although, I haven't heard it officially yet, I believe that=20
> I have heard it from
> > sufficiently "reliable sources" that CobolExpo 2003 (for=20
> June in Las Vegas) is
> > now canceled.  I also BELIEVE that as of this moment, the=20
> "forum on the future
> > of COBOL" is still planned to take place that week in Las=20
> Vegas.  Anyone already
> > planning on attending the forum (originally in addition to=20
> the CobolExpo) should
> > verify exactly what the plans are for it.
> >=20
> > HOWEVER, the major reason that I am posting this note to a=20
> few groups and
> > lists is that I really think that "we all" need to step up=20
> to the actual
> > answer to the question of where COBOL will be 5 years from=20
> now - and the
> > answer is close to (but not quite) irrelevant.
> >=20
> > I *strongly* believe that there will still be COBOL=20
> compilers (even some
> > with new releases, new features, and new interfaces) - not=20
> only 5 years from now
> > but even 10 years from now.
> >=20
> > I even believe (from some documents submitted to J4) that=20
> there MAY be one
> > or two compilers that conform (at least mostly) to the 2002=20
> ISO COBOL
> > Standard.
> >=20
> > I suspect that there will even be new and "upgraded" COBOL=20
> applications that use
> > NEW features introduced in the 2002 COBOL Standard - and=20
> some of the TR's
> > (Technical Reports) currently being worked on by J4 and WG4.
> >=20
> >     ON THE OTHER HAND,
> >=20
> > The following are some of my "crystal ball" visions=20
> (whether "fears" or
> > simply "forebodings")
> >=20
> > 1) I expect that MOST COBOL compilers will use the 2002 ISO=20
> Standard (and
> > the TR's - if approved) as a "Chinese menu" and will "pick=20
> and choose" which of
> > the (required - not just processor dependent) features they=20
> ever implement.
> >=20
> > 2) COBOL will NEVER be a *major* player in the "user-side"=20
> of the web or
> > server application environment. (Which is NOT to say that=20
> there won't be
> > some new - as well as continued - applications that do this.)
> >=20
> > 3) New "businesses" doing data processing or existing=20
> businesses creating
> > NEW applications will *only* select COBOL as their=20
> "programming language of
> > choice" in infrequent and unusual circumstances.
> >=20
> > 4) Sites with existing COBOL applications will increase their
> > "consideration" of language conversions away from COBOL=20
> when they do "major
> > maintenance" or new functionality to those programs.
> >=20
> > 5) Membership in J4 and WG4 will continue to "decrease"=20
> with NO new COBOL
> > vendors joining J4; no new countries joining WG4; and those=20
> doing the "real
> > work" of the committees continuing to be limited to a VERY=20
> SMALL handful of
> > individuals (not vendors or user companies).
> >=20
> > 6) There never will be robust  "certification tests" for=20
> the 2002 ISO
> > Standard - and the US government (along with European and=20
> Asian governmental
> > bodies) will NEVER require "2002 conforming" compilers. =20
> (And possibly they will
> > even - within the next 10 years - drop COBOL as a=20
> "authorized" programming
> > language for new projects - in cases where they have a list=20
> of such authorized
> > programming "languages" or "tools").
> >=20
> >         ***
> >=20
> > Bottom-Line:
> >   I will continue to "post" to newsgroups and others the=20
> information of what is
> > happening with "development" and "maintenance" of the COBOL=20
> language by various
> > Standards groups.  I think it is important that all=20
> existing COBOL programmers
> > "keep abreast" of what is or might be happening or going to happen.
> >=20
> > OTOH,  I can't see - unless something DRAMATICALLY changes=20
> - that COBOL will be
> > seen as a GROWING programming environment.  Certainly the=20
> 30-year old question
> > of "Is COBOL dead?" still deserves an answer of NO.  On the=20
> other hand, the
> > question of "Is COBOL a dynamic/growing programming=20
> environment?" seems to
> > warrant an equally strong "NO" as an answer.
> >=20
> > OBVIOUSLY, this post reflects PERSONAL OPINION only.  I=20
> wouldn't mind being
> > proven wrong - but I won't hold my breath either.
> >=20
> > --
> > Bill Klein
> >  wmklein <at> ix.netcom.com
> >=20
> >=20
> >=20
> >=20
> > ________
> > This mailing list may not be used for unlawful purposes.=20
> All postings should be
> > relevant, but ITI accepts no responsibility for any posting=20
> and may terminate
> > access to any subscriber violating any policies of the=20
> Association. Please
> > review the INCITS Antitrust Guidelines at=20
> <http://www.incits.org/natrust.htm>.
> >=20
>=20
>=20
> ---
> COBOL - Immune=20
> to buffer overflows
>=20
>=20
>=20
> ________
> This mailing list may not be used for unlawful purposes. All postings=20
> should be relevant, but ITI accepts no responsibility for any=20
> posting and=20
> may terminate access to any subscriber violating any policies of the=20
> Association. Please review the INCITS Antitrust Guidelines at=20
> <http://www.incits.org/natrust.htm>.
>=20

[Cobolforgcc-devel] Re: What is the future of COBOL? Answer: Irrelevant???

[Thane H. <th...@so...>]

Hogwash.

Especially this part:

> question of "Is COBOL a dynamic/growing programming environment?" seems to
> warrant an equally strong "NO" as an answer.

There have been more new COBOL releases by a variety of vendors RECENTLY than 
in the same time frame 10 years ago. (say 1990-1993).   In the last few years 
the gap between what you can do with COBOL and what you can do with other 
languages has narrowed considerably.  It isn't because the other environments 
are becoming static or shrinking - it's because COBOL is dynamic and growing.

Yes - COBOL Expo got cancelled (Postponed).  Don't blame COBOL.

On 23 May 2003 at 16:16, William M. Klein wrote:

> Please be advised that replying to this message goes to the sender. If you wish
> to send a reply to all on the list, please respond with "Reply All".
> _____________
>  J4 and WG4 posed the question "What <is> your vision for the COBOL language 5
> years from now?"
> 
> Although, I haven't heard it officially yet, I believe that I have heard it from
> sufficiently "reliable sources" that CobolExpo 2003 (for June in Las Vegas) is
> now canceled.  I also BELIEVE that as of this moment, the "forum on the future
> of COBOL" is still planned to take place that week in Las Vegas.  Anyone already
> planning on attending the forum (originally in addition to the CobolExpo) should
> verify exactly what the plans are for it.
> 
> HOWEVER, the major reason that I am posting this note to a few groups and
> lists is that I really think that "we all" need to step up to the actual
> answer to the question of where COBOL will be 5 years from now - and the
> answer is close to (but not quite) irrelevant.
> 
> I *strongly* believe that there will still be COBOL compilers (even some
> with new releases, new features, and new interfaces) - not only 5 years from now
> but even 10 years from now.
> 
> I even believe (from some documents submitted to J4) that there MAY be one
> or two compilers that conform (at least mostly) to the 2002 ISO COBOL
> Standard.
> 
> I suspect that there will even be new and "upgraded" COBOL applications that use
> NEW features introduced in the 2002 COBOL Standard - and some of the TR's
> (Technical Reports) currently being worked on by J4 and WG4.
> 
>     ON THE OTHER HAND,
> 
> The following are some of my "crystal ball" visions (whether "fears" or
> simply "forebodings")
> 
> 1) I expect that MOST COBOL compilers will use the 2002 ISO Standard (and
> the TR's - if approved) as a "Chinese menu" and will "pick and choose" which of
> the (required - not just processor dependent) features they ever implement.
> 
> 2) COBOL will NEVER be a *major* player in the "user-side" of the web or
> server application environment. (Which is NOT to say that there won't be
> some new - as well as continued - applications that do this.)
> 
> 3) New "businesses" doing data processing or existing businesses creating
> NEW applications will *only* select COBOL as their "programming language of
> choice" in infrequent and unusual circumstances.
> 
> 4) Sites with existing COBOL applications will increase their
> "consideration" of language conversions away from COBOL when they do "major
> maintenance" or new functionality to those programs.
> 
> 5) Membership in J4 and WG4 will continue to "decrease" with NO new COBOL
> vendors joining J4; no new countries joining WG4; and those doing the "real
> work" of the committees continuing to be limited to a VERY SMALL handful of
> individuals (not vendors or user companies).
> 
> 6) There never will be robust  "certification tests" for the 2002 ISO
> Standard - and the US government (along with European and Asian governmental
> bodies) will NEVER require "2002 conforming" compilers.  (And possibly they will
> even - within the next 10 years - drop COBOL as a "authorized" programming
> language for new projects - in cases where they have a list of such authorized
> programming "languages" or "tools").
> 
>         ***
> 
> Bottom-Line:
>   I will continue to "post" to newsgroups and others the information of what is
> happening with "development" and "maintenance" of the COBOL language by various
> Standards groups.  I think it is important that all existing COBOL programmers
> "keep abreast" of what is or might be happening or going to happen.
> 
> OTOH,  I can't see - unless something DRAMATICALLY changes - that COBOL will be
> seen as a GROWING programming environment.  Certainly the 30-year old question
> of "Is COBOL dead?" still deserves an answer of NO.  On the other hand, the
> question of "Is COBOL a dynamic/growing programming environment?" seems to
> warrant an equally strong "NO" as an answer.
> 
> OBVIOUSLY, this post reflects PERSONAL OPINION only.  I wouldn't mind being
> proven wrong - but I won't hold my breath either.
> 
> --
> Bill Klein
>  wmklein <at> ix.netcom.com
> 
> 
> 
> 
> ________
> This mailing list may not be used for unlawful purposes. All postings should be
> relevant, but ITI accepts no responsibility for any posting and may terminate
> access to any subscriber violating any policies of the Association. Please
> review the INCITS Antitrust Guidelines at <http://www.incits.org/natrust.htm>.
> 


---
COBOL - Immune to buffer overflows

[Cobolforgcc-devel] What is the future of COBOL? Answer: Irrelevant???

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

 J4 and WG4 posed the question "What <is> your vision for the COBOL =
language
5 years from now?"

Although, I haven't heard it officially yet, I believe that I have heard =
it
from sufficiently "reliable sources" that CobolExpo 2003 (for June in =
Las
Vegas) is now canceled.  I also BELIEVE that as of this moment, the =
"forum
on the future of COBOL" is still planned to take place that week in Las
Vegas.  Anyone already planning on attending the forum (originally in
addition to the CobolExpo) should verify exactly what the plans are for =
it.

HOWEVER, the major reason that I am posting this note to a few groups =
and
lists is that I really think that "we all" need to step up to the actual
answer to the question of where COBOL will be 5 years from now - and the
answer is close to (but not quite) irrelevant.

I *strongly* believe that there will still be COBOL compilers (even some
with new releases, new features, and new interfaces) - not only 5 years =
from
now but even 10 years from now.

I even believe (from some documents submitted to J4) that there MAY be =
one
or two compilers that conform (at least mostly) to the 2002 ISO COBOL
Standard.

I suspect that there will even be new and "upgraded" COBOL applications =
that
use NEW features introduced in the 2002 COBOL Standard - and some of the
TR's (Technical Reports) currently being worked on by J4 and WG4.

    ON THE OTHER HAND,

The following are some of my "crystal ball" visions (whether "fears" or
simply "forebodings")

1) I expect that MOST COBOL compilers will use the 2002 ISO Standard =
(and
the TR's - if approved) as a "Chinese menu" and will "pick and choose" =
which
of the (required - not just processor dependent) features they ever
implement.

2) COBOL will NEVER be a *major* player in the "user-side" of the web or
server application environment. (Which is NOT to say that there won't be
some new - as well as continued - applications that do this.)

3) New "businesses" doing data processing or existing businesses =
creating
NEW applications will *only* select COBOL as their "programming language =
of
choice" in infrequent and unusual circumstances.

4) Sites with existing COBOL applications will increase their
"consideration" of language conversions away from COBOL when they do =
"major
maintenance" or new functionality to those programs.

5) Membership in J4 and WG4 will continue to "decrease" with NO new =
COBOL
vendors joining J4; no new countries joining WG4; and those doing the =
"real
work" of the committees continuing to be limited to a VERY SMALL handful =
of
individuals (not vendors or user companies).

6) There never will be robust  "certification tests" for the 2002 ISO
Standard - and the US government (along with European and Asian =
governmental
bodies) will NEVER require "2002 conforming" compilers.  (And possibly =
they
will even - within the next 10 years - drop COBOL as a "authorized"
programming language for new projects - in cases where they have a list =
of
such authorized programming "languages" or "tools").

        ***

Bottom-Line:
  I will continue to "post" to newsgroups and others the information of =
what
is happening with "development" and "maintenance" of the COBOL language =
by
various Standards groups.  I think it is important that all existing =
COBOL
programmers "keep abreast" of what is or might be happening or going to
happen.

OTOH,  I can't see - unless something DRAMATICALLY changes - that COBOL =
will
be seen as a GROWING programming environment.  Certainly the 30-year old
question of "Is COBOL dead?" still deserves an answer of NO.  On the =
other
hand, the question of "Is COBOL a dynamic/growing programming =
environment?"
seems to warrant an equally strong "NO" as an answer.

OBVIOUSLY, this post reflects PERSONAL OPINION only.  I wouldn't mind =
being
proven wrong - but I won't hold my breath either.

--
Bill Klein
 wmklein <at> ix.netcom.com

[Cobolforgcc-devel] manufacturer of garments and bags in China

[Rachel <se...@pu...>]

Dear Sir or Madam,  

I have the pleasure to know your esteemed corp. 

We are a manufacturer & exporter of garments and bags in Quanzhou, China.

I think we can cooperate and supply you with garments as you need.  

The following is some introductions about our company.

       Set up: 1988

       Type: manufacturer & exporter

       Product: knitted garments and bags

       Employees: 1300 persons ( garments factory: 500      bags factory: 800)

       Product data:       

                                  product (main items)                      capacity(/year)

                                  brief                                    2,000,000dzs    

                                  baby body                                1,800,000dzs

                                  boxer short                                200,000dzs

                                  pajama                                      50,000dzs

                                  soft bag                                 1,500,000pcs

                                  hard bag                                   500,000pcs

Mimn order:  300dzs for garments

Payment:  irrevocable L/C at sight

Bank: BANK OF CHINA


Our garment factory mainly specialize in Lady's and men's underwear,

children's wear, baby's wear, pajama, boxer shorts, T-shirt, etc. 

The materials we often use are cotton, T/C, Polyester, Polyamide, 

Elasthan, and Polyamide. Our products are design with PAD system, 

produced with advanced equipment, processed in highly quality control 

system with seasoned workmanship and high efficiency. Our main market 

is Europe, Australia, Japan and America. We also accept the orders designed 

and required by costumers. You can see some pictures of our samples through 

our web http://www.senwer.com. (For more pictures in your interesting, 

pls kindly contact us directly). 
 

Our bag factory was founded in 1988, too. We produce all kinds of bags, 

including suitcase, backpack, travel bag, shoulder bag, sport bag, trolley, 

camera bag, tote bag, school bag, computer case, luggage,waist bag, notecase, etc. 

And the goods have met a great favor in the Europe countries, Australia 

and America because of their good quality, beautiful design and competitive price.


Thank you very much. Hope you will give us an opportunity to do 

business together and we will try our level best to fulfill your present 

requirement. Should you therefore need any more details for your 

clarification, pls do not hesitate to contact us. And you are welcome 

to visit our factories.


With best regards


Rachel Wang

Mob:0086-13960286700
E-mail:ra...@se...


Jason Chen

Mob:0086-13959893400
E-mail: jas...@se...


Vicki Wang

Mob:0086-13960228599
E-mail: vi...@se...


-----------------------------------------------------------------------------

SENWER GARMENTS CO., LTD.

ADD: Room F202, Fugui Renjia Building, Liuguan Road, Quanzhou, Fujian, China.

Tel: 0086-595-2506700    Fax: 0086-595-2563400    P.C.:362000

Http://www.senwer.com    E-mail: se...@pu...

-----------------------------------------------------------------------------

Re: [Cobolforgcc-devel] Re: GCC front end for COBOL

[Keisuke N. <kni...@ne...>]

At Tue, 6 May 2003 16:29:15 -0500,
William M. Klein wrote:
> 
> > Features that are missing:
> > 
> >   Nested programs
> >   Intrinsic functions
> >   REPORT SECTION
> >   COMMUNICATION SECTION
> >   SCREEN SECTION
> >   Embedded SQL
> >   Debugging with GDB
> 
> Just a PERSONAL suggestion, do NOT bother with "Communications Section".

Thanks.  I am not going to support it because it seems there is no user of it.

> Also,  which "variation" of Screen Section are you thinking of implementing?

Maybe we could support all of them by selecting a compiler option.
At the beginning, I am going to support the one of COBOL 2002.

Regards,
Keisuke Nishida

[Cobolforgcc-devel] Fw: XML proposal initial input for future COBOL Standard

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

FYI

"William M. Klein" <wm...@ix...> wrote in message news:...
> (Sent to various NG's)
>=20
> For those of you interested in COBOL and XML, you might want to see an
> "initial" paper proposing full (???) XML support for a future COBOL
> Standard.  This paper may be viewed at:
>=20
>      http://www.cobolportal.com/j4/files/03-0094.doc
>=20
> Notice particularly the statement,
>=20
> "This paper is based on a working implementation.
>=20
> Since WG4 and J4 are evaluating alternative approaches for XML, I have =
not
> identified the pages on which the changes should be made, but left =
this to
> the imagination of the reader.  I am willing to develop this working =
paper
> into a formal proposal if this is the approach that is chosen."
>=20
> As I am sending a copy of this note to IBM-MAIN, it should be noted =
that
> this is a QUITE different approach than that currently available in
> Enterprise COBOL.
>=20
> I would think that if "you" have input on this (or another) approach =
to
XML
> support in "native" COBOL, that J4 and WG4 would be interested in it.  =
You
> can contact the J4 Chair, the WG4 convenor, and the author of this =
paper
> (all of whom are the same person) by emailing:
>=20
>    Don.Schricker <at> microfocus.com
>=20
> --
> Bill Klein
>  wmklein <at> ix.netcom.com
>=20
>=20

RE: [Cobolforgcc-devel] Re: GCC front end for COBOL

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

> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Keisuke Nishida
> Sent: Monday, May 05, 2003 6:00 PM
> To: Tim Josling
> Cc: cob...@li...; gc...@gc...
> Subject: Re: [Cobolforgcc-devel] Re: GCC front end for COBOL
<snip>
>=20
> Features that are missing:
>=20
>   Nested programs
>   Intrinsic functions
>   REPORT SECTION
>   COMMUNICATION SECTION
>   SCREEN SECTION
>   Embedded SQL
>   Debugging with GDB
>=20

Just a PERSONAL suggestion, do NOT bother with "Communications Section".

Also,  which "variation" of Screen Section are you thinking of =
implementing?

  AcuCOBOL syntax (includes character mode *AND* GUI)
  Micro Focus, RM, or any of the other currently available on Unix =
system
variations
  X/Open  (medium "basic" character mode - and medium portable to =
existing
implementation
  2002 COBOL Standard (possibly the MOST portable - in the future, but =
not
yet)

Each of these has "PROs and CONs".  My personal SUGGESTION would be to =
go
with the 2002 COBOL Standard definition (which is SIMILAR to - but not
identical to - the X/Open specification)

Re: [Cobolforgcc-devel] Re: GCC front end for COBOL

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

Keisuke Nishida wrote:
> At Mon, 05 May 2003 06:15:47 +1000,
> Tim Josling wrote:
> ...
> 
> Thanks.  Can I put my code on the CVS repository of the COBOL for GCC
> project?
> 

Yes, once you have the FSF paperwork done.

> 
>>Could you send me details of what your compiler does and does not 
>>support? That is, what features are present and what features are missing.
> 
> 
> Features that are present:

 > ...

> 
> Thanks for your advice, and I agree with you.  Maybe we should target
> GCC 3.3.
> 
> Best regards,
> Keisuke Nishida
> 
> 

I think this is a good idea.

I will be in Japan from 2-13 July. Perhaps we could get togther for a 
few hours and work out a plan which meets both our needs.

One possibility is:

Most of the code comes from opencobol.

Except

- preprocessor (cobol4gcc is complete implementation of COPY/REPLACE)
- GCC integration

Then we could both pick features to work on and get it done twice as fast.

Tim Josling

Re: [Cobolforgcc-devel] Re: [open-cobol-list] GCC front end for COBOL

[Geoff K. <ge...@ge...>]

Tim Josling <te...@me...> writes:

> The only issue would be the copyright. While they have given
> permission to use the suite freely, it is not public domain, nor
> copyright FSF.

This may be OK; the testsuite has different rules to the rest of the
compiler.  It would depend on the exact license.

-- 
- Geoffrey Keating <ge...@ge...>

Re: [Cobolforgcc-devel] Re: [open-cobol-list] GCC front end for COBOL

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

The only issue would be the copyright. While they have given permission 
to use the suite freely, it is not public domain, nor copyright FSF.

Bill Klein also pointed out it has not been updated for the second 
revision of COBOL 85 (the correction amendment).

Tim Josling

Robert Dewar wrote:
> Tim Josling said
> 
> 
>>1. A test suite. Existing languages have comprehensive test suites.
> 
> 
> I would think the standard COBOL test suite (used for GSA cobol validations
> at least in the past, not sure of current policy) would be a fine test
> suite for this purpose.
> 

Re: [Cobolforgcc-devel] Re: GCC front end for COBOL

[Keisuke N. <kni...@ne...>]

At Mon, 05 May 2003 06:15:47 +1000,
Tim Josling wrote:
> 
> My objective is to get a working free cobol compiler. I think by joining 
> up we may be able to get their faster. As you remember I was keen to 
> join up before. You have done a lot of work very quickly, more than me.

Thanks.  Can I put my code on the CVS repository of the COBOL for GCC
project?

> Could you send me details of what your compiler does and does not 
> support? That is, what features are present and what features are missing.

Features that are present:

  COBOL core features (95% of NIST NC module), except
    - SPECIAL-NAMES. ALPHABET clause.
    - COLLATING SEQUENCE clause
    - variable length group item (OCCURS DEPENDING ON)

  SEQUENTIAL/REALTIVE/INDEXED/SORT-MERGE file I-O
  (85% of NIST SQ, RL, IX, and ST modules), except
    - SAME clause
    - LINAGE clause
    - variable length records
    - SORT with duplicate keys
    - COLLATING SEQUENCE

  CALL statement (48% of NIST IC module)
    A program can be compiled into either a native
    executable or a shared library (.so), and they
    can be linked either statically or dynamically.

    Nested programs are not supported.

  COPY and REPLACE statements (58% of NIST SM module)
    The current preprocessor cannot handle complex COPY statement.
    The preprocessor can handle both fixed and free form.

Features that are missing:

  Nested programs
  Intrinsic functions
  REPORT SECTION
  COMMUNICATION SECTION
  SCREEN SECTION
  Embedded SQL
  Debugging with GDB

  Compile-time / run-time error checking is not complete
  (I am currently improving this)

  Optimization is not well done

> One thing for you to consider: if you integrate into GCC, you will find 
> that GCC integration takes a lot of ongoing effort. People change things 
> that break your compiler. This will slow you down. I found that keeping 
> up with GCC changes is taking most of my time, not adding features. In 
> my opinion it would be best to target, say, gcc3.3 and then later on 
> upgrade to a later release. This protects you to some extent.
> 
> All in all, it may be better to integrate later on, once your compiler 
> is 'function complete'.

Thanks for your advice, and I agree with you.  Maybe we should target
GCC 3.3.

Best regards,
Keisuke Nishida

[Cobolforgcc-devel] Re: [open-cobol-list] GCC front end for COBOL

[Keisuke N. <kni...@ne...>]

At Sun, 04 May 2003 22:31:39 +0200,
Bernard Giroud wrote:
> 
> > I like "gobol" ;)
> 
> Well done, Mark ! I like this one pretty much.

It's pretty :)  I like it too.

Keisuke

Re: [Cobolforgcc-devel] Re: GCC front end for COBOL

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

Keisuke,

My objective is to get a working free cobol compiler. I think by joining 
up we may be able to get their faster. As you remember I was keen to 
join up before. You have done a lot of work very quickly, more than me.

Could you send me details of what your compiler does and does not 
support? That is, what features are present and what features are missing.

Also I will have a look at your compiler and verify if the structure is OK.

Could you give me your phone number and a time I can call you, in a few 
days time, so we can discuss all this?

By the way, I am visiting Japan in July... maybe we could get togther then.

One thing for you to consider: if you integrate into GCC, you will find 
that GCC integration takes a lot of ongoing effort. People change things 
that break your compiler. This will slow you down. I found that keeping 
up with GCC changes is taking most of my time, not adding features. In 
my opinion it would be best to target, say, gcc3.3 and then later on 
upgrade to a later release. This protects you to some extent.

All in all, it may be better to integrate later on, once your compiler 
is 'function complete'.

Regards,
Tim Josling

Keisuke Nishida wrote:
> Hello,
> 
> As I talked in the gcc list, I would like to write a COBOL front end
> for GCC.  I know there have been lots of discussion and efforts on
> this list, and I wonder if we could work together.
> 
> I would like to contribute my code to the COBOL for GCC project and
> join in if you are comfortable with that.  What do you think?
> 
> Thanks,
> Keisuke Nishida

[Cobolforgcc-devel] Re: [open-cobol-list] GCC front end for COBOL

[Bernard G. <bg...@fr...>]

Mark Hahn a écrit :

> Bernard Giroud a écrit :
> > I would just suggest changing the external name
> > gcb (and the project name) to something like
> > gcob: quicker to pronounce, and better imaging
> > against GNU (like gcc, g77, ...).
>
> I like "gobol" ;)

Well done, Mark ! I like this one pretty much.
Just a shame I realized only now that I was
the sole destinator...

Hence the publication in the lists.

--
Bernard Giroud
TinyCOBOL Developer

[Cobolforgcc-devel] Re: [open-cobol-list] GCC front end for COBOL

[Keisuke N. <kni...@ne...>]

Hi Bernard,

At Fri, 02 May 2003 16:01:16 +0200,
Bernard Giroud wrote:
> 
> I would just suggest changing the external name
> gcb (and the project name) to something like
> gcob: quicker to pronounce, and better imaging
> against GNU (like gcc, g77, ...).

Yes, that might be better.

> I wonder how much easy it would be to continue
> to work with OpenCOBOL modified to have
> a structure more compatible to GCC, so that minimal
> modifications could be applied back to gcc-cobol ?

It is not hard, but developing two compilers in parallel
is troublesome.  I am going to switch to gcc-cobol sooner
or later.

> A few technical hints when making the compiler:
> 
> - on a RH8.0, I had to rename all malloc in cob-tree.c
>   into xmalloc, following a error message about
>   "poisonous malloc".
> - contrary to your instructions, you need OpenCOBOL 0.12.
>   If 0.11, cob_get_environment and cob_put_environment
>   are missing. If 0.20, then cob_decimal_get, cob_decimal_get_r
>   and cob_error_code are missing.

I will fix them.  Thanks.

> Also where should cobc1 be installed to make it work ?

Anywhere on the PATH.

Keisuke

[Cobolforgcc-devel] Re: [open-cobol-list] GCC front end for COBOL

[Bernard G. <bg...@fr...>]

Keisuke Nishida a écrit :

> Hi,
>
> I am a developer of a COBOL compiler called OpenCOBOL,
> and I would like to make it a GCC front end.
>
> I have experimentally implemented a GCC front end by
> modifying OpenCOBOL, and it now compiles basic COBOL
> programs as much as OpenCOBOL can do.
>
>

A whole lot of thanks for the excellent work you've
done so far, Keisuke !!

I would just suggest changing the external name
gcb (and the project name) to something like
gcob: quicker to pronounce, and better imaging
against GNU (like gcc, g77, ...).

> So, what should I do next?  Could I contribute the
> code to the GCC team, or should I continue development
> by myself until it becomes more useful and stable?

I wonder how much easy it would be to continue
to work with OpenCOBOL modified to have
a structure more compatible to GCC, so that minimal
modifications could be applied back to gcc-cobol ?

>
> I have implemented the front end from scratch by
> myself and I am ready to send a copyright assignment
> (with my employer's disclaimer).

Better sending now your copyright assignment request,
by experience, it takes time to proceed !

>
> The current status of my compiler is that it is
> partially compliant to the COBOL 85 standard.  It
> can compile some useful COBOL programs, but still
> there is lots of work to be done.
>
> At this time, I implemented the front end based on
> the gcc-3_3-branch.  I am aware of the tree-ssa
> branch, and probably I had better rewrite the front
> end using the new internal representation, but I am
> not sure when and how I should do that.
>
> The current implementation of my front end is more
> like a quick hack; it works, but is not so elegant.
> I am going to rewrite it to make it cleaner and
> more efficient.
>
> Before further going on, I would like to hear what
> people think about my project.  Would GCC accept
> my front end for the COBOL language?  With what
> version (branch) of GCC I should work?
>
> The source code of my COBOL front end is available
> at the following page:
>
>   http://www.open-cobol.org/gcc.html
>

A few technical hints when making the compiler:

- on a RH8.0, I had to rename all malloc in cob-tree.c
  into xmalloc, following a error message about
  "poisonous malloc".
- contrary to your instructions, you need OpenCOBOL 0.12.
  If 0.11, cob_get_environment and cob_put_environment
  are missing. If 0.20, then cob_decimal_get, cob_decimal_get_r
  and cob_error_code are missing.

Also where should cobc1 be installed to make it work ?

>
> Thanks,
> Keisuke Nishida

--
Bernard Giroud
TinyCOBOL Developer

Re: [Cobolforgcc-devel] Re: [open-cobol-list] GCC front end for COBOL

[Gerald P. <pf...@db...>]

On Thu, 1 May 2003, Keisuke Nishida wrote:
> I think I need to write more documentation, including comments in the
> source.  On the other hand, I want to spend more time on coding than
> commenting because I often rewrite the code.
>
> After having some thought on this, I have decided to keep development
> by myself for now, at least until the compiler becomes more stable
> and more people use it.  Then, I will ask to include it in GCC again.

You may want to submit a patch for http://gcc.gnu.org/frontends.html to
add/update the state of Cobol frontends.

Tim, currently we have a link suggested by yourself; is that still fine
as is?

Gerald
-- 
Gerald "Jerry"   pf...@db...   http://www.pfeifer.com/gerald/