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

Re: [Cobolforgcc-devel] cobolforgcc on AIX (RS6000)

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

Curt,
I am just about to update the cvs with the new version, now I
have fixed the bugs I created with the global change,
Regards,
Tim Josling

Curt Timmerman wrote:
> 
> My first thought was to test for a previous definition but there is no guarantee the meaning would be the same. The 'COB_' sounds good.
> 
> Curt

[Cobolforgcc-devel] Cobol Column ideas?

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

My column for the COBOL report is due next week
(http://cobolreport.com). 

I donate the fee to the Free Software Foundation - see
http://www.fsf.org/thankgnus/2000supporters.html for
acknowledgement of this. 

Apart from the usual release reports, please let me know if there
is anything else you want to bring to the attention of the COBOL
community. 

One exciting development is the use of Tiny COBOL in a live
application (under development). 

I am also going to look at the year ahead. Would anyone care to
venture a suggestion where we might be in 12 months time?

Tim Josling

[Cobolforgcc-devel] [Fwd: [Tiny-cobol-users] CVS Using Windows]

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

Anyone wanting to use CVS on windows can use this. I recommend
CVS as a way to keep your source up to date with the latest
updates,
Tim Josling

Andrew Cameron wrote:
> 
> Hi,
> 
> I am successfully using CVS Under Windows.
> 
> For information on how to do this have a look at
> http://ptolemy.eecs.berkeley.edu/~johnr/info/cvs.html
> 
> This helps when you only have a Winmodem.
> 
> Regards
> Andrew
> 
> _______________________________________________
> Tiny-cobol-users mailing list
> Tin...@li...
> http://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

[Cobolforgcc-devel] COBOL'ers of tomorrow - PLEASE read and act now !!

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

FYI - I just posted the following in the comp.lang.cobol and IBM-MAIN
newsgroups.

-----Original Message-----

If you think that COBOL may be in your future (your shop's future, or even
creating your paychecks <G>) for the next few years, please read the
following AND act upon it.

The FCD (Final Committee Draft) of the next COBOL revision is now available
and desperately (IMHO) needs reviewing.

You can get a copy (download) from:

     http://www.ncits.org/tc_home/j4.htm

Look for the line:

 COBOL FCD (6.8 MB) or  Compressed Self-Extracting File (2 MB)

Time is OF THE ESSENCE in reviewing this document and getting your input
(good, bad, whatever) to the appropriate people.  The official "review
period" will begin (unless something changes between now and then) on
February 1, 2001 and last 4 months (internationally) but only 3 months (for
US Public Review - subject to possible modification).  I will point "you
all" to the official Press Release when it becomes available - but I wanted
to give a "heads up" as soon as this document became generally available.

If you are in the US (or wish to submit your comments via US-only channels),
then you will need to send them to NCITS - details on how to do this will be
in the Press Release - when available.

   HOWEVER,

if you do not live/work in the US and/or are a citizen of another country
and are interested in submitting your comments thru your own (non-US)
national Standards body (and I strongly, STRONGLY recommend this), then go
to the following page to get "contact information" - and find out ASAP how
and when they will be taking comments:

 http://www.iso.ch/addresse/membodies.html

  ***

So much for "preface" - now let me make some suggestions (and these are ONLY
personal opinions) on how and what to do for your "personal" review of what
will happen to COBOL in the near, medium-near, and somewhat far futures.

Step 1: (critical)
  Contact your COBOL compiler "vendor of choice".  Find out:
    - how much resource THEY are spending on reviewing this document - both
for its "ease" of implementation - but also for any compatibility issues tha
t it will be causing THEIR customers
    - what their current position is on whether or not they think they will
ever implement this version of COBOL - in part or whole.  Let them KNOW
whether or not this is important to you - and how much you will PAY for it.
    - whether they (the vendor) or any of its user groups plan on providing
"consolidated" input to the review process.

(If they aren't reviewing this document now, you can be pretty certain that
either they won't be providing a conforming compiler in the short-term - or
that you and they will BOTH be unhappy with what they will be required to
provide.)

Step 2: (minimum - if you are interested in what MAY happen to COBOL in the
next few years)
 Download a copy of the draft Standard - and if nothing else review the two
appendices:
    - D.1 Substantive changes potentially affecting existing programs
    - D.2 Substantive changes not affecting existing programs

the first section will tell you about changes that MIGHT "change behavior"
in your existing programs; the second section will tell you (at a HIGH
level) what the major enhancements in this revision are.

Step 3: (if the last step "got you interested at all")
 Look at the section
    - Concepts

This section "describes" (in as non-technical as possible - which is still
pretty technical - way) many of the old and new features included in this
revision of COBOL.  Some (not as many as some would want) examples are even
included.

Step 4: (If you are a "do-er" and not someone who thinks that someone else
will make YOUR life easy/better)
  REVIEW the document in as much or as little detail as you want.
  Formulate your "comments" and send them to your national body (not to me,
not to J4, not to any electronic newsgroup or distribution list, but to your
national Standards body) and do this as FAR before the end of April 2001 as
possible.

REAL COMMENTS from REAL reviewers DO make a difference - and they DO get
looked at in detail (or at least in as much detail as you provide "us").

   ***

Some comments and suggestions on what *I* think will be "good and useful"
comments.

A) This document is pretty much at the "final" stage of development.  It is
HIGHLY unlikely that new features or enhancements to existing features will
be added at this time (unless "you" can justify that it would be worth
waiting another 2-5 years to get ANY revision of the '85/'89/'92 Standard
out.)

PLEASE do not use this review period to make suggestions of "nice to have"
additions for THIS revision of the Standard.  If there is something that you
just MUST tell people to think about adding, I strongly suggest that you
CLEARLY document this as an idea for a (possibly the next) revision of
COBOL.  Better yet, create a separate document with these "ideas" and send
them to the chair of the J4 COBOL committee marked "candidates for a future
revision" and include as much or as little detail as you think appropriate.
He can be reached at:

  doncobol <at> mediaone.net

B) It really is useful to say that you think that the whole document is
"swell" and you wouldn't change a thing (or at least wouldn't change a thing
if that means a "delay" in getting the Standard approved and out).  You can
even add "minor" editorial issues, suggestions, to such a comment.  However,
please do NOT assume that everyone in the world thinks that this is a great
idea (or even a worthwhile revision).  Therefore, it is important to hear
from people who think it is - unless you fall into the other category, see
below.

C) If you think that this revision should NOT be approved and published as
an ISO Standard, this too is useful information to convey.  However, it is
important that you ALSO tell why you think this.  Don't just be general and
say that "COBOL is dead" or something similar, but give specific reasons why
you think that the "programming world" will be a BETTER place (even for
COBOL programmers) if this revision is NOT adopted as an International
Standard.  (FYI - if you have read this far, this is the category that I fal
l in - but I won't go into details on that in this note. I will in future
input.)

D) ALL editorial notes are useful, but be aware that the ISO "drafting
rules" are specific and some things that are done in this document MUST be
done this way.  However, it is particularly useful to hear about additional
index entries that would be helpful (and where they should point to) or
cross-references and index entries that are pointing to the wrong place.
Similarly, if you find sentences or sections that seem to have been "messed
up" in editing (and don't make any sense), this too may be useful
information.  It really does help if you tell what the correction is and NOT
just point out what the problem is.  (For non-native English speakers this
may be difficult - but often if something doesn't make sense to you, it is
more important to get your editorial comments identifying problems than it
is to get comments who can "guess" at what was intended.)

E) PLEASE tell "us" about any technical errors that you find.  Not so much
things that are "fuzzy" but things where two (or more) parts of the Standard
conflict with each other - or where one part assumes something that another
says cannot happen. Similarly, parts of the draft that are "impossible" to
implement or otherwise technically "wrong". Again, the more specific you can
be (and the more you can provide "corrections") the more likely such
comments are to be "accepted" and acted upon.

F) If you do find "fuzzy" or unclear sentences (or sections), don't just say
that they were unclear but give SPECIFIC suggestions on how they should be
re-worded.  (Make certain that you clearly state which part of the draft -
page, section, and paragraph - you are talking about.  This is really true
for ALL comments that you submit).

G) If you think that there is something SO awful or so seriously flawed that
you think that it should be REMOVED from the draft Standard, this has a
"little" better chance of happening than adding something new.  HOWEVER,
almost everything in this document has been fought over for over half a
decade (some for close to a decade now) - so getting it removed would
require some PRETTY STRONG evidence of a critical problem (not just a
preference - or the way that you or your operating environment works today).

  ***

A special note about "spreading the word" - as well as spreading the
document.

PLEASE feel free to forward this document to as many people as you think
MIGHT be interested and willing to do ANY work on reviewing (and commenting)
on this document. You should, however, be aware that page ii of this
document states,

"This ISO document is a draft International Standard and is
copyright-protected by ISO. Except as permitted under the applicable laws of
the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by
any means, electronic, photocopying, recording or otherwise, without prior
written permission being secured. ..."

*HOWEVER* page xx states,

"Any organization interested in reproducing the COBOL standard and
specifications in whole or in part, using ideas from this document as the
basis for an instruction manual or for any other purpose, is free to do so.
..."

If you work in a "large" and/or "legalistic" environment, I suggest that you
contact *YOUR* personal legal authorities and/or advisors for an
interpretation on how these two statements (and their surrounding text)
impact you and your distribution of the document itself.

   ***

Happy reviewing - and please feel free to send me personal or public
questions if you need help in understanding what YOU can do and why I am
asking for you to do so.

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

Re: [Cobolforgcc-devel] cobolforgcc on AIX (RS6000)

[Curt T. <cu...@cu...>]

My first thought was to test for a previous definition but there is no guarantee the meaning would be the same. The 'COB_' sounds good.

Curt

--- Tim Josling <te...@me...>
> wrote:
>Curt,
>Thanks for the information. How about I change them to COB_*? I
>will run a sed job on the source tree and anything I receive.
>Tim Josling
>
>
>Curt Timmerman wrote:
>> 
>> I ran a quick compile/test of the tolower intrinsic on our AIX box at work and received redefinition errors on the following defines in cobr_temp_config.h:
>> UINT64_MAX
>> INT64_MAX
>> INT64_MIN
>> 
>> These were previously defined in:
>> /usr/include/sys/inttypes.h
>> 
>> ==
>> Curt Timmerman
>> cu...@cu...
>>
>
>_______________________________________________
>Cobolforgcc-devel mailing list
>Cob...@li...
>http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel

==
Curt Timmerman
cu...@cu...

_____________________________________________________________

BootBox.Net - Home Of The Totally Free Internet Solution

http://www.bootbox.net

Get an @bootbox.net webmail account - http://webmail.bootbox.net

Host Your Website For Free - http://webhosting.bootbox.net

Put Your E-Commerce Business Online Virtually Free - http://bcommerce.bootbox.net

Re: [Cobolforgcc-devel] cobolforgcc on AIX (RS6000)

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

Curt,
Thanks for the information. How about I change them to COB_*? I
will run a sed job on the source tree and anything I receive.
Tim Josling


Curt Timmerman wrote:
> 
> I ran a quick compile/test of the tolower intrinsic on our AIX box at work and received redefinition errors on the following defines in cobr_temp_config.h:
> UINT64_MAX
> INT64_MAX
> INT64_MIN
> 
> These were previously defined in:
> /usr/include/sys/inttypes.h
> 
> ==
> Curt Timmerman
> cu...@cu...
>

[Cobolforgcc-devel] cobolforgcc on AIX (RS6000)

[Curt T. <cu...@cu...>]

I ran a quick compile/test of the tolower intrinsic on our AIX box at work and received redefinition errors on the following defines in cobr_temp_config.h:
UINT64_MAX
INT64_MAX
INT64_MIN

These were previously defined in:
/usr/include/sys/inttypes.h

==
Curt Timmerman
cu...@cu...

_____________________________________________________________

BootBox.Net - Home Of The Totally Free Internet Solution

http://www.bootbox.net

Get an @bootbox.net webmail account - http://webmail.bootbox.net

Host Your Website For Free - http://webhosting.bootbox.net

Put Your E-Commerce Business Online Virtually Free - http://bcommerce.bootbox.net

RE: [Cobolforgcc-devel] OCCURS (was Redefines

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

I think that (eventually) you will want to emulate something like MERANT's
ODOSLIDE directive - that allows for *either* fill-up *or* slide-in
behavior.  IBM works like the latter - so MUCH of the code that you get
probably will "rely" on it.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Tuesday, January 02, 2001 2:35 AM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] OCCURS (was Redefines
>
>
> Bill,
>
> First up I am implementing the standard with needed enhancements
> to allow calling C routines. I had my fingers well and truly
> burned implementing an earlier extension. The earlier extension
> was the use of fully nested COPY with REPLACING - a can of worms.
> Once you go beyond the standard it raises a lot fo indefined
> issues.
>
> In the OCCURS example, the issues are what happens to the holes
> in the occurs. Do you fill them up or leave them vacant? So I
> will leave this alone for now.
>
> Later on, we need to have a look at what the existing compilers
> have done. What do you think is the best approach,
>
> Tim Josling
>
> "William M. Klein" wrote:
> >
> > Tim,
> >  For OCCURS are you going to stick (at least initially) to the "strict"
> > ANSI/ISO rules - which require that an ODO (Occurs Depending
> On) be the LAST
> > item in a record - and that they not be nested (or have other
> OCCURS nested
> > in them)?
> >
> > IBM, MERANT, and most "similar" compilers have extensions to
> "remove these
> > restrictions" - but what they do about the run-time results can differ
> > DRAMATICALLY (compare MERANT's ODOSLIDE directive).
> >
> > > -----Original Message-----
> > > From: cob...@li...
> > > [mailto:cob...@li...]On Behalf Of Tim
> > > Josling
> > > Sent: Monday, January 01, 2001 2:12 PM
> > > To: cobolforgcc-devel
> > > Subject: [Cobolforgcc-devel] Redefines
> > >
> > >
> > > I have uploaded the code and tests for redefines. Apart from
> > > trivia like filler, the main hard thing left in the data division
> > > is occurs.
> > >
> > > The debugging information is not all coming out. This needs a bit
> > > more work to find out which magic fields I need to fill in.
> > >
> > > Ted Seward is working on sort merge. The basic routines are
> > > mainly done, with only the basic merge to go - actually the most
> > > interesting algorithm.
> > >
> > >
> > >
> > > Tim Josling
> > >
> > > _______________________________________________
> > > Cobolforgcc-devel mailing list
> > > Cob...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel
> >
> > _______________________________________________
> > Cobolforgcc-devel mailing list
> > Cob...@li...
> > http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel

Re: [Cobolforgcc-devel] OCCURS (was Redefines

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

Bill,

First up I am implementing the standard with needed enhancements
to allow calling C routines. I had my fingers well and truly
burned implementing an earlier extension. The earlier extension
was the use of fully nested COPY with REPLACING - a can of worms.
Once you go beyond the standard it raises a lot fo indefined
issues. 

In the OCCURS example, the issues are what happens to the holes
in the occurs. Do you fill them up or leave them vacant? So I
will leave this alone for now.

Later on, we need to have a look at what the existing compilers
have done. What do you think is the best approach,

Tim Josling

"William M. Klein" wrote:
> 
> Tim,
>  For OCCURS are you going to stick (at least initially) to the "strict"
> ANSI/ISO rules - which require that an ODO (Occurs Depending On) be the LAST
> item in a record - and that they not be nested (or have other OCCURS nested
> in them)?
> 
> IBM, MERANT, and most "similar" compilers have extensions to "remove these
> restrictions" - but what they do about the run-time results can differ
> DRAMATICALLY (compare MERANT's ODOSLIDE directive).
> 
> > -----Original Message-----
> > From: cob...@li...
> > [mailto:cob...@li...]On Behalf Of Tim
> > Josling
> > Sent: Monday, January 01, 2001 2:12 PM
> > To: cobolforgcc-devel
> > Subject: [Cobolforgcc-devel] Redefines
> >
> >
> > I have uploaded the code and tests for redefines. Apart from
> > trivia like filler, the main hard thing left in the data division
> > is occurs.
> >
> > The debugging information is not all coming out. This needs a bit
> > more work to find out which magic fields I need to fill in.
> >
> > Ted Seward is working on sort merge. The basic routines are
> > mainly done, with only the basic merge to go - actually the most
> > interesting algorithm.
> >
> >
> >
> > Tim Josling
> >
> > _______________________________________________
> > Cobolforgcc-devel mailing list
> > Cob...@li...
> > http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel
> 
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] OCCURS (was Redefines

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

Tim,
 For OCCURS are you going to stick (at least initially) to the "strict"
ANSI/ISO rules - which require that an ODO (Occurs Depending On) be the LAST
item in a record - and that they not be nested (or have other OCCURS nested
in them)?

IBM, MERANT, and most "similar" compilers have extensions to "remove these
restrictions" - but what they do about the run-time results can differ
DRAMATICALLY (compare MERANT's ODOSLIDE directive).

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Monday, January 01, 2001 2:12 PM
> To: cobolforgcc-devel
> Subject: [Cobolforgcc-devel] Redefines
>
>
> I have uploaded the code and tests for redefines. Apart from
> trivia like filler, the main hard thing left in the data division
> is occurs.
>
> The debugging information is not all coming out. This needs a bit
> more work to find out which magic fields I need to fill in.
>
> Ted Seward is working on sort merge. The basic routines are
> mainly done, with only the basic merge to go - actually the most
> interesting algorithm.
>
>
>
> Tim Josling
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] Redefines

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

I have uploaded the code and tests for redefines. Apart from
trivia like filler, the main hard thing left in the data division
is occurs. 

The debugging information is not all coming out. This needs a bit
more work to find out which magic fields I need to fill in. 

Ted Seward is working on sort merge. The basic routines are
mainly done, with only the basic merge to go - actually the most
interesting algorithm. 



Tim Josling

Re: [Cobolforgcc-devel] Re: cobolforgcc

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

This page has instructions for getting the daily CVS tarball via
ftp, useful if you do not want tyo wait to set up the cvs ssh ssl
up.

http://sourceforge.net/docman/display_doc.php?docid=764&group_id=1

Tim Josling

[Cobolforgcc-devel] Patch options

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

The preferred command options for generating the patches are
diff -u -p 
Tim Josling

[Cobolforgcc-devel] Re: cobolforgcc

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

Curt,

http://sourceforge.net/projects/cobolforgcc/ is the project main
page. Click on CVS and there are the instructions for doing an
anonymous cvs download. I am trying to remember what the 'module'
name is - it is "." without the quotes.

For now you can either email the patches to me, or submit them
using the patch option in the page above. Don't worry about the
Makefile at this stage. Just ensure you get as clean a compile as
possible with the options:

-W -Wall -pedantic -Wno-long-long -Wmissing-prototypes
-Wmissing-declarations -Wwrite-strings -Wstrict-prototypes

Next time you log on to source forge, your summary page should
have some 'tasks' which you can have a look at - see what you
think. The intrinsic functions contain a large variety of things
from quite easy to very difficult so there is a lot to choose
from. 

Send all the questions you like...

The timelines depend on a number of things so I have never
committed to anything specific. But if we do not have something
very useful by the end of 2001 I will be very disappointed. We
have about 45,000 lines of code so far, and I figure there are
about 77,000 to go. The more progress we make the more people
come on board which is encouraging. Since I started in March
1999, it has not just been codiing all the time. I had to do a
lot of R&D to get integrated with GCC, during which time very
little code got written. So 75,000 is not as much as it seems.

If you want to build the full GCC integration thing I can send
some more specific instructions and command files to help set it
all up. The cvs aspects are a little tricky because part fo the
source tree (GCC) is in one repository and part is in another
(cobolforgcc). It is not necessary at this stage though to do
this.

I think you made an earlier comment about the fact COBOL is not a
YACC (LALR(1)) grammar. True. Have a look at cobctok.def for the
details of what I needed to do. Some similar things are needed
for other parts of the procedure division, though the other
divisions are more or less OK.

Regards,
Tim Josling

Copied to the mailing list (I see you got on OK) hope that's all
right.

"Timmerman, Curt" wrote:
> 
> Tim,
> 
> Great! Is there a web page that explains the source checkout/checkin
> procedure? I saw something on it but I can't find it again.
> 
> I have some additional questions about project timelines and milestones, but
> I will hold off until I do some coding.
> 
> Thanks for the speedy response,
> Curt Timmerman
> 
>         Curt
> 
>         You have now been added as a developer to the project.
> 
>         You should be able to subscribe to the mailing list
> cobolforgcc-devel at this URL (once you have signed on using SSL from the
> sourceforge main page): https://sourceforge.net/mail/?group_id=5709. I will
> try and add you in tonight.
> 
>         I will pick one of the intrinsic modules and send you a spec RSN.
> 
>         Tim
>         Josling

Re: [Cobolforgcc-devel] Sort definition

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

Bill,

Thanks. Which section of the standard are you referring to?
Declaratives are down the track but it is good to know these
things in advance. 

The spec below is just for the 'inner sort' - other moodules will
do the file IO, interfacing to the compiled code, overflowing to
disk and so on. So it is not as bad as it looks. 

Regards,
Tim Josling

PS no need to cc me I always read the mailing list.

"William M. Klein" wrote:
> 
> I seem to have missed whatever note this is replying to - but does this
> handle both
> 
>    WITH DUPLICATES
> 
>         and
> 
>    COLLATING SEQUENCE clauses?
> 
> Also, what (if anything) does this do with INPUT/OUTPUT procedures?
> 
> If you "implement" a simple (Using/Giving - native collating sequence -
> only) SORT, then I suggest that you add a compile-time message "warning"
> that other phrases are "currently ignored"
> 
> P.S.  There is a VERY obscure rule in the ANSI Standard (that some compiler
> ignore and most programmers do NOT know about) which states that you "must"
> go to a File Declarative in the middle of a SORT - should the "condition"
> specified in the DECLARATIVE occur anywhere during the SORT.  Just thought I
> would mention this - so you might want to "design" around this.
>

RE: [Cobolforgcc-devel] Sort definition

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

I seem to have missed whatever note this is replying to - but does this
handle both

   WITH DUPLICATES

	and

   COLLATING SEQUENCE clauses?

Also, what (if anything) does this do with INPUT/OUTPUT procedures?

If you "implement" a simple (Using/Giving - native collating sequence -
only) SORT, then I suggest that you add a compile-time message "warning"
that other phrases are "currently ignored"

P.S.  There is a VERY obscure rule in the ANSI Standard (that some compiler
ignore and most programmers do NOT know about) which states that you "must"
go to a File Declarative in the middle of a SORT - should the "condition"
specified in the DECLARATIVE occur anywhere during the SORT.  Just thought I
would mention this - so you might want to "design" around this.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Tuesday, December 26, 2000 4:28 AM
> To: Tim Josling
> Cc: cobolforgcc-devel
> Subject: [Cobolforgcc-devel] Sort definition
>
>
> Ted,
>
> How about this for the basic in core sort? You could do it in one
> call but then you would need to reanalyze the sort field details
> for each buffer full of records.
>
> Regards,
> Tim Josling
>
> /* set up for one or more sorts */
>
> enum cobr_sort_status_enum
> cobr_basic_sort_init
> (
>  UINT32 sort_field_count,
>  struct sort_field_desc* sort_fields,
>  UINT8* collating_sequence /* 256 bytes in order for text field
> sort or NULL */
> );
>
> /* do a sort */
>
> enum cobr_sort_status_enum
> cobr_basic_sort(
>  void * handle,
>  UINT32 record_count,
>  void** records,
>  UINT32* record_lengths);
>
> /* free the memory etc */
>
> enum cobr_sort_status_enum
> cobr_basic_sort_wrap(void * handle);
>
> struct sort_field_desc
> {
> UINT32 offset;
> UINT32 length;
> UINT32 decimals;
> UINT32 type;
> UINT32 flags;
> };
>
> enum cobr_sort_status_enum
> { /* sample only */
> cobr_sort_status_OK=0,
> cobr_sort_status_invalid_key_definitions,
> cobr_sort_status_record_too_short,
> ...etc...
> };
>
> <end>
>
>
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] Sort definition

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

Ted,

How about this for the basic in core sort? You could do it in one
call but then you would need to reanalyze the sort field details
for each buffer full of records.

Regards,
Tim Josling

/* set up for one or more sorts */

enum cobr_sort_status_enum
cobr_basic_sort_init
(
 UINT32 sort_field_count,
 struct sort_field_desc* sort_fields,
 UINT8* collating_sequence /* 256 bytes in order for text field
sort or NULL */
);

/* do a sort */

enum cobr_sort_status_enum
cobr_basic_sort(
 void * handle,
 UINT32 record_count, 
 void** records, 
 UINT32* record_lengths);

/* free the memory etc */

enum cobr_sort_status_enum
cobr_basic_sort_wrap(void * handle);

struct sort_field_desc
{
UINT32 offset;
UINT32 length;
UINT32 decimals;
UINT32 type;
UINT32 flags;
};

enum cobr_sort_status_enum
{ /* sample only */
cobr_sort_status_OK=0,
cobr_sort_status_invalid_key_definitions,
cobr_sort_status_record_too_short,
...etc...
};

<end>

[Cobolforgcc-devel] SQL pre-processor

[David E. <de...@ar...>]

Hi All,

I was wondering if anyone else is working on a embedded SQL
pre-processor and run-time.

Reason why I ask is that I have begun some preliminary work on a SQL
pre-processor and RTL for TinyCOBOL.

I think this portion of the compiler should easily integrate in both the
TC and COBOL4GCC projects, so what I would like to suggest is a
co-operation between the two projects in developing the SQL
pre-processor and run-time. 

The current scope of the project is as follows:

Front end Scanner/Parser:
- This will replace END-EXEC to COBOL CALLs to the API libraries.
- Currently considering using asql. This can be found on the web as
  asql_yacc.txt.

Backbend interface
- This will be an interface between the COBOL CALLs to the database API
  or the OBDC API.
- Candidate for an direct interface to the database API.
  A C++ library derived from foxsql which abstracts the underlying
  API's. Currently can dynamically load mSql, MySql, pgSql drivers. 
- Candidates for an interface to the OBDC API.
  unixOBDC
  iOBDC

If anyone would like to help with this sub project, please let me know.
 

David

RE: [Cobolforgcc-devel] Added function

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

There is NO restriction on using concatenation expressions in the Data
Division. (can you point to something that told you there was?)

The figurative constant rule "boils down" to the fact that you may *NOT* use
"ALL" - but can use things like LOW-VALUE or ZERO. (each is treated as a
single character).

The biggest difference between concatenation and the new (or old) forms of
continuation is that COPY/REPLACING treats
    "A"-
    "B"
       or
     "A"
  -  "B"

  as a single text word of "AB"

while it treats
    "A" & "B"
  as 3 separate text words - so

a COPY xyz Replacing =="A"== by =="X"==.
 would match the concatenation example but NOT either of the 1st two.


> -----Original Message-----
> From: ti...@me... [mailto:ti...@me...]On Behalf Of Tim
> Josling
> Sent: Saturday, December 16, 2000 10:26 PM
> To: William M. Klein; cobolforgcc-devel
> Subject: Re: [Cobolforgcc-devel] Added function
>
>
> Bill,
>
> Sorry I mean non-numeric literals, not C style null terminated
> strings. I'm aware of the issues with figurative constants, ALL
> etc.
>
> It appears that in the procedure division I can concatenate
> literals like this
> "a" & "b"
>
> but this is not allowed elsewhere eg in the working-storage.
> There, one must do
> "a"-
> "b"
>
> Is that right? I must say I fail to see what good is achieved by
> this irregularity.
>
> Currently I allow & anywhere, as in X/Open COBOL.
>
> Tim Josling
>
> "William M. Klein" wrote:
> >
> > I am a "mere" COBOL person.  Can you tell me what you mean by "string
> > literals"?  I can think of several "possible" meanings (in
> COBOL terms) but
> > don't know what you mean by them.
> >
> > NOTE: The draft Standard provides a facility called "Concatenation
> > Expression" (defined in "8.8.3 Concatenation expressions" on
> page 124 of CD
> > 1.10).  If this is what you are talking about, make certain
> that you look at
> > rules concerning figurative constants, class and category, etc.
> >
> > P.S.  If by "string literals," you are referring to (what I know as)
> > ASCII-null-terminated-strings, then this is NOT allowed in the draft
> > Standard - but is implemented (as an extension) in several
> compilers by the
> > use of Z-literals. If these are of interest, then I can point
> to either IBM
> > or MERANT LRM entries for them.
> >
>
>

Re: [Cobolforgcc-devel] Added function

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

Bill,

Sorry I mean non-numeric literals, not C style null terminated
strings. I'm aware of the issues with figurative constants, ALL
etc.

It appears that in the procedure division I can concatenate
literals like this 
"a" & "b" 

but this is not allowed elsewhere eg in the working-storage.
There, one must do 
"a"-
"b"

Is that right? I must say I fail to see what good is achieved by
this irregularity.

Currently I allow & anywhere, as in X/Open COBOL. 

Tim Josling

"William M. Klein" wrote:
> 
> I am a "mere" COBOL person.  Can you tell me what you mean by "string
> literals"?  I can think of several "possible" meanings (in COBOL terms) but
> don't know what you mean by them.
> 
> NOTE: The draft Standard provides a facility called "Concatenation
> Expression" (defined in "8.8.3 Concatenation expressions" on page 124 of CD
> 1.10).  If this is what you are talking about, make certain that you look at
> rules concerning figurative constants, class and category, etc.
> 
> P.S.  If by "string literals," you are referring to (what I know as)
> ASCII-null-terminated-strings, then this is NOT allowed in the draft
> Standard - but is implemented (as an extension) in several compilers by the
> use of Z-literals. If these are of interest, then I can point to either IBM
> or MERANT LRM entries for them.
>

RE: [Cobolforgcc-devel] Added function

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

I am a "mere" COBOL person.  Can you tell me what you mean by "string
literals"?  I can think of several "possible" meanings (in COBOL terms) but
don't know what you mean by them.

NOTE: The draft Standard provides a facility called "Concatenation
Expression" (defined in "8.8.3 Concatenation expressions" on page 124 of CD
1.10).  If this is what you are talking about, make certain that you look at
rules concerning figurative constants, class and category, etc.

P.S.  If by "string literals," you are referring to (what I know as)
ASCII-null-terminated-strings, then this is NOT allowed in the draft
Standard - but is implemented (as an extension) in several compilers by the
use of Z-literals. If these are of interest, then I can point to either IBM
or MERANT LRM entries for them.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Thursday, December 14, 2000 3:33 PM
> To: cobolforgcc-devel
> Subject: [Cobolforgcc-devel] Added function
>
>
> I have now added concatenated string literalss (in all contexts
> where strings can be used ie non-numeric literals.
>
> I also added support for 64 bit integers BINARY-DOUBLE. Display
> now works with all the numeric and display formats that are
> supported.
>
> Adding new function is not too hard but COBOL is *big*.
>
> Tim Josling
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] Added function

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

I have now added concatenated string literalss (in all contexts
where strings can be used ie non-numeric literals. 

I also added support for 64 bit integers BINARY-DOUBLE. Display
now works with all the numeric and display formats that are
supported. 

Adding new function is not too hard but COBOL is *big*.

Tim Josling

[Cobolforgcc-devel] COBOL,ADS/O,IDMS,OS 390 -Programmers/Analysts- Adelaide,Australia .

[Filip P. <fpa...@tm...>]

Dear Sir/Madam,

TMP Worldwide, a personnel consultancy active on international markets, is
currently looking for analysts/programmers who are interested in working in
Australia on a challenging one-year project. Competitive conditions offered
!!

If you would be interested in such a position, I would be very grateful if
you could send me some more details relating to the following areas:


On a scale of 1-5, please assess your knowledge of;

- IDMS       1   2   3   4  5
- ADS/O     1   2   3   4  5
- COBOL    1   2   3   4  5  


When did you last work with

-IDMS
-ADS/O
-COBOL

 Do you have any experience with the following DATABASES:

-IDMS DB
-IDMS DC 

Do you have any experience with OS390 or MSP Platforms?


If you could send your reply either to myself or Marta Makowska- the address
is given below- we will get back to you as soon as possible.

Yours faithfully,

Filip Pasterski    

P.S. Please insert the ref. code Cobol/AUSTRALIA



Filip Pasterski
Gateway Consultant_e-Resourcing Technology
TMP Worldwide
ul. Krzywickiego 34
02-078 Warsaw, PL
Tel:   +48 (0)22 622 42 93
Fax:  +48 (0)22 621 20 19
E:  fpa...@tm...
E:  mma...@tm...
-------------------------------------------------------------------
Visit our website at
http://www.tmpw.com.pl
for online recruitment and career advice
-------------------------------------------------------------------

[Cobolforgcc-devel] Re: COBOL for GCC

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

Larry,

Good to hear from you. 90% of the work is the runtime, which is
where we need the most help. Depending on your interests there
are many different projects you could do.

A few things to be aware of:

Coding standards are the Free Software Foundation's coding
standards http://www.fsf.org/prep/standards_toc.html. The main
things are meaningful names, indenting style, no tabs, good
comments for every function.

Every code needs a test driver or test case. Usually you write
the test first and then write the code when you run the test and
it doesn't work. Tested code is useful but untested code is not. 

I am working on a COBOL subset at present. When this is done, we
can/will write some of the remaining compiler in COBOL.

It helps if you are using GCC, even better to be using linux, but
again not essential.

I assume you have read the documentation I have written to far.

In terms of the process:

It would really help if you register as a developer with source
forge http://www.sourceforge.net. Then we can track projects
using their task manager. It is not absolutely essential to do so
though.

Also if you could subscribe to the mailing list
cob...@so... and we can converse via the
list; that way there is a record of the design decisions and
specs etc.

Normally one of us comes up with a spec which is really the
function prototypes and any extra clarification that is needed.
Then write the tests and code, and then I check it in. 

Now for the fun bit - what to write. Here are some possibilities.

Speed up the existing 128 bit arithmetic routines; and add new
256 bit routines. Use the algirothms in 'The Art of Computer
Programming" by Knuth, or better algorithms if you can find them.

Implementations of some or all of the intrinsic functions. 

Implementation of sort/merge. Key requirement is effectively
unlimited size, greater than virtual memory. Knuth has lots on
this too.

Implementation of any of the COBOL file IO. 

Improve the emacs editing mode code (cobol.el).

There are many others...pick one.

Regards,
Tim Josling

(Larry Vandewalle is interested in contributing to COBOLforGCC.)

[Cobolforgcc-devel] Free COBOL news - Tim Josling's latest column

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

Free COBOL news: http://cobolreport.com/columnists/tim/