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

Re: [Cobolforgcc-devel] File IO

[Matthew V. <lin...@ho...>]

On 30 Mar 2001 09:06:34 +1000, Tim Josling wrote:
> I will be here. The only thing is, do a small bit at a time and
> send it in.
> 
> We are making progress. Working on the Go To verb at the moment.
> 
> Re being on call: I was on call for many years, and I got sick of
> being called at 4am all the time. We did an analysis and found
> the most common causes for being called in and fixed them.
> Callins went down by a factor of 10. Of course management is not
> going to pay for the work unless it costs them. Do you get paid
> for a) being on call b) being called c) coming in to work.
> 
> Tim Josling
> 

It is pretty bad.  There are the occasional challenging issues, however.
I'm currently doing baseline support (the next line past the helpdesk).
With us, though, that translates to answering how-to questions on
weekends, to fixing data in databsse tables, to fixing bugs in
production code, to marathon code diving sessions.  I'm scheduled to
rotate back to development soon--hopefully that will coincide with our
replatforming effort...

Don't get paid, really, for being on-call.  We do, however, compensate
ourselves by taking a day off for every week on-call.  I guess it works
out.  The more production code we fix, well, you know, another just pops
right on up there....keeps me in coding practice, anyhow. :)

> Matthew Vanecek wrote:
> > 
> > Just as an FYI, I"m still poking away at the file I/O grammar and
> > runtime.  I've been very busy with work lately, and with planning my
> > wedding for next week.  I should be able to devote more attention to it
> > shortly.
> > 
> > Being on-call, in the words of Kyle, Stan, and Cartman, "sucks ass!"
> > 
> > --
> > Matthew Vanecek
> 
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel
> 



-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...

Re: [Cobolforgcc-devel] File IO

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

I will be here. The only thing is, do a small bit at a time and
send it in.

We are making progress. Working on the Go To verb at the moment.

Re being on call: I was on call for many years, and I got sick of
being called at 4am all the time. We did an analysis and found
the most common causes for being called in and fixed them.
Callins went down by a factor of 10. Of course management is not
going to pay for the work unless it costs them. Do you get paid
for a) being on call b) being called c) coming in to work.

Tim Josling

Matthew Vanecek wrote:
> 
> Just as an FYI, I"m still poking away at the file I/O grammar and
> runtime.  I've been very busy with work lately, and with planning my
> wedding for next week.  I should be able to devote more attention to it
> shortly.
> 
> Being on-call, in the words of Kyle, Stan, and Cartman, "sucks ass!"
> 
> --
> Matthew Vanecek

[Cobolforgcc-devel] File IO

[Matthew V. <lin...@ho...>]

Just as an FYI, I"m still poking away at the file I/O grammar and
runtime.  I've been very busy with work lately, and with planning my
wedding for next week.  I should be able to devote more attention to it
shortly.

Being on-call, in the words of Kyle, Stan, and Cartman, "sucks ass!"


-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...

[Cobolforgcc-devel] Re: Cobol (need advice)

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

Marko,

At this time I would not recommend COBOL For GCC. Tiny COBOL may
be a viable option. You may also consider Fujitsu COBOL V3 which
has been available for downloading, though the source is not
available. 

It will be another six months to a year or so before IO have a
viable solution for you.

Tim Josling

Marko Kessler wrote:
> 
> Hello,
> my name is Marko, and I was looking for a free Cobol
> compiler, or the one that works the most. From the reviews
> it seems that this one is the best. Well the reason why Im
> looking for this is that Im doing a research for a class,
> that want us to install Cobol on the lab machines, so they
> can use it later for research and developement. I didn't
> look closely to the files, but can you give me few quick
> pointers how to go about installing it. Im installing it on
> a Sun Ultra 5 machine with Solaris 8 on them. I know this
> might sound like Im an idiot, but we all got to start from
> somewhere, right? Thank you very much for your help
> 
> Marko
> 
> 4th year Computer Science Student
> University of Northern British Columbia
> Prince George, BC
> Canada

[Cobolforgcc-devel] Re: Convert routine

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

Daniel,

Will do once I have them cleaned up sufficiently. The other two
are crashing at present. Should be done soon though,

Regards,
Tim Josling

"Daniel H. Ardison" wrote:
> 
> Tim,
> 
> Send me back the sources with the new standard and I will convert the test
> program to run automatically.
> 
> Regards,
> Daniel

Re: [Cobolforgcc-devel] Data division of core compiler subset now complete

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

Bill,

The usages I am supporting are

- display with PIC X(n) only
- pointer (based on IBM's implementation)
- binary-char binary-short binary-long and binary-double (from
the new COBOL standard).

No:
- numeric PIC clauses
- comp-x

These will be done in the nucleus proper which is phase 2. I
intend to write the PIC clause analysis in COBOL. 

It is only a subset of the nucleus so there is no file IO - this
will have to be done via calls to C routines like fread etc.

Once I have the full compiler subset done I will make it
available - at that time I will be asking for test cases and bug
reports.

Tim Josling

"William M. Klein" wrote:
> 
> Do you have a list of what "non-standard" (extension) USAGEs you support?
> (e.g COMP-3, POINTER, whatever).  How about Line Sequential?
> 
> Basically, do you have a list of "extensions" that are supported?
> 
> Do you want "test case" source code - for the data division?
>

RE: [Cobolforgcc-devel] Data division of core compiler subset now complete

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

Do you have a list of what "non-standard" (extension) USAGEs you support?
(e.g COMP-3, POINTER, whatever).  How about Line Sequential?

Basically, do you have a list of "extensions" that are supported?

Do you want "test case" source code - for the data division?

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Monday, March 26, 2001 5:12 PM
> To: cobolforgcc-devel
> Subject: [Cobolforgcc-devel] Data division of core compiler subset now
> complete
>
>
> I have finished the data division for the core compiler subset.
> This is a subset of the cobol nucleus which will be used to write
> much of the remaining compiler.
>
> The display and set address statements are also done.
>
> Tim Josling
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] Data division of core compiler subset now complete

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

I have finished the data division for the core compiler subset.
This is a subset of the cobol nucleus which will be used to write
much of the remaining compiler. 

The display and set address statements are also done. 

Tim Josling

RE: [Cobolforgcc-devel] Re: NIST testsuite

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

I used to have a copy of the printed instructions (from Micro Focus days).
I'll check my "old paper files" to see if I can find them.

Don Schricker the J4 chair says that he knows who at EDS is *supposed* to be
a contact for running the validation suite currently.  You might want to
contact Don and see if he can give you a contact to get the instructions.
(I am CC'ing him on this note - in case he has information EASILY
available).

P.S.  I know that "you all" aren't actually going for "validation" - but are
you aware of the ANSI vs FIPS differences? The two major ones that come to
mind are:

 A) flagging requirements (what is flagged and what needs to be included)
 B) Is Intrinsic Function required or Optional for High-level subset

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Saturday, March 24, 2001 5:48 PM
> To: David Essex
> Cc: Fred Mobach; cobolforgcc-devel
> Subject: [Cobolforgcc-devel] Re: NIST testsuite
>
>
> David,
>
> I had am email from them saying that we were welcome to use the
> test suite for testing our compilers. But there does not seem to
> be any doco.
>
> The way it is structured is that the first program is a program
> that extracts the other programs. You need to provide various
> parameters to guide the first program. I didn't get any further
> than that. You will need to reverse engineer the parameter
> details from the source.
>
> Tim Josling
>
> David Essex wrote:
> >
> > Hi Fred, Tim,
> >
> > At 04:22 PM 22/03/01, Fred Mobach wrote:
> > > ...
> > >While you are on this topic, can anyone give me some information on the
> > >test suite from NIST ?
> > >I have it here but I can't find so much information.
> >
> > Besides the COBOL programs, I could not find any information either.
> >
> > Tim, since you have been in touch with these people. Is there
> any further
> > information available some where ?
> >
> > David
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

[Cobolforgcc-devel] Re: NIST testsuite

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

David,

I had am email from them saying that we were welcome to use the
test suite for testing our compilers. But there does not seem to
be any doco.

The way it is structured is that the first program is a program
that extracts the other programs. You need to provide various
parameters to guide the first program. I didn't get any further
than that. You will need to reverse engineer the parameter
details from the source. 

Tim Josling

David Essex wrote:
> 
> Hi Fred, Tim,
> 
> At 04:22 PM 22/03/01, Fred Mobach wrote:
> > ...
> >While you are on this topic, can anyone give me some information on the
> >test suite from NIST ?
> >I have it here but I can't find so much information.
> 
> Besides the COBOL programs, I could not find any information either.
> 
> Tim, since you have been in touch with these people. Is there any further
> information available some where ?
> 
> David

Re: [Cobolforgcc-devel] Debug information.

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

Betty,

COBOL4GCC uses the GCC code generation back end for code
generation. GCC also generates the debugging information. The
program "GDB" is used as the debugger.

The compoiuler front end captures the information and passes it
to the code generation. It is then passed to the assembler as
special pseudo-ops. There are numberous formats (see the doco on
gcc -g option for details).

The GCC site has a lot of documentation on this. Have a look at
http://gcc.gnu.org. 

Tim Josling

> Betty Liu wrote:
> 
> We would like to build a debugging tool for real-time
> applications (CHORUSOS).
> Information such as user defined data type is mandatory. All
> the debugging information
> suppose to be captured during the compiling stage.  Questions
> are:
>         - Where the information is captured? In the executable
> or *.o files?
>         - How to decode the information?  Any documentations,
> examples or source code?
> 
> It would be appreciated if somebody would reply my e-mail.
> 
> Thank you and regards,
> 
> Betty L. Bousfield

[Cobolforgcc-devel] Debug information.

[Betty L. <be...@no...>]

We would like to build a debugging tool for real-time applications
(CHORUSOS).
Information such as user defined data type is mandatory. All the debugging
information 
suppose to be captured during the compiling stage.  Questions are:
	- Where the information is captured? In the executable or *.o files?
	- How to decode the information?  Any documentations, examples or
source code?

It would be appreciated if somebody would reply my e-mail.

Thank you and regards,

Betty L. Bousfield

[Cobolforgcc-devel] A little more than a month

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

From Bill,
  Just wanted to send out a "reminder" that US Public Review comments on the
draft Standard are due in a little over a month.

Public Review comments in other countries *may* be due at other times (you
will need to check with your own national standards body)

Re: [Cobolforgcc-devel] STRING

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

Tim,

Thanks, and thanks for catching those hidden bugs!  It's good to
know that STRING is now part of the package.

Cheers,

Steven


Tim Josling wrote:
> 
> Steven,
> 
> Thanks, very professionally done. All checked into sourceforge
> CVS now, and the tests are part of the test suite. I found a
> minor bug in tests 22/23 where in printing out the "actual" the
> x[0] element is printed as x[i] which gives wrong output though
> the tests work. I fixed this also I added a printout of test
> numbers to make it easier to find out what is happening.
> 
> Unstring is still up for grabs, or anything else you may care to
> do now or later,
> 
> Regards and thanks again,
> Tim Josling
> 
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

Re: [Cobolforgcc-devel] STRING

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

Steven,

Thanks, very professionally done. All checked into sourceforge
CVS now, and the tests are part of the test suite. I found a
minor bug in tests 22/23 where in printing out the "actual" the
x[0] element is printed as x[i] which gives wrong output though
the tests work. I fixed this also I added a printout of test
numbers to make it easier to find out what is happening. 

Unstring is still up for grabs, or anything else you may care to
do now or later, 

Regards and thanks again,
Tim Josling

Re: [Cobolforgcc-devel] STRING

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

Steven,
Thanks got the three emails. I will integrate them today. I
assume it is now complete - if so I will put the tests into the
test suite. Pls let me know if not.
Tim Josling

[Cobolforgcc-devel] STRING

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

According to the standard (below), pointer offset must be set to a
value greater than 0 before the string routine is called.  And since
both pointer offset and delimiter count are defined as COB_UINT32 
within cobr_string.c, I have changed the test routines in 
test_cobr_string.c to be consistent with cobr_string.c.  I changed

	COB_INT32 pointer_offset 
	COB_INT32 delimiter_count	
to
	COB_UINT32 pointer_offset 
	COB_UINT32 delimiter_count.

Also, the initial coding of cobr_string.c allowed a pointer_offset of
0.  
I have changed that to an overflow condition and put it in debug code:

	#ifndef NDEBUG
	  if (pointer_offset == 0)
	    return 1;
	#endif


6.25.2 General Format 

STRING 
 {
    {identifier-l | literal-l} ... 
       DELIMITED BY {identifier|literal|SIZE}
 } ... 
INTO identifier-3 
[WITH POINTER identifier-41 
[ON OVERFLOW imperative-statement-l 
[NOT ON OVERFLOW imperative-statement-21 [END-STRING] 


6.25.3 Syntax Rules 

. . .

(5) If the POINTER phrase is specified, the data item referenced
by identifier-4 must be set to an initial value greater than zero
prior to the execution of the STRING statement. 

(6) If the POINTER phrase is not specified, the following general
rules apply as if the user had specified identifier-4 referencing
a data item with an initial value of 1. 

. . .

[Cobolforgcc-devel] a free transaction processing monitor, anyone ?

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

Hello,

Still not used to headlines with to much capitals ? Than this one will
do.

Today the free transaction processing monitor project is launched. It is
a bit unusual as the current code won't run or even compile on any
GNU/Linux or even a UNIX platform. It runs only on the Siemens BS2000
mainframes, but there it is already for more than 7 years in daily
production use.

Some messages on the tiny-cobol mailinglist triggered me to release this
software under the GNU GPL. That might be un-American. Great, not my
problem ;-).

An important part of the code has to be rewritten in C as it is
originally written in Siemens Assembler (a S/390 look-alike). But most
of the code is written in COBOL and we are very happy with the ongoing
development of the free COBOL compilers, tiny-cobol and CobolForGCC.
Both of them can be found on sourceforge.net.

A second major problem is the documentation, not because it's lacking
but because it is written in the language I master better than any other
: Dutch. In case you are willing to learn a very beautiful language :
try Dutch, you will not be disappointed.

OK, the distracting aspects are covered now, COBOL and Dutch. Now the
joy. Imagine a software system able to communicate with many concurrent
users, which system happens to communicate with many other user
applications in other processes. Depending on the communication method
these user applications can run on the same or another server. A system
which has special functions geared to developpers like REP and dump
functions.

Some numbers per subdirectory :

directory     # files    # lines    # lines
                         (+ comm)   (- comm)

assembler          97      65060      29431
cobol             237     141502     111596  *1
copies            787      40427      20938  *1
documentation       3      12400       9286  *2
forms             143      12694      10120
jcl                19       1104       1104
macros            166      17590       8748

Totals           1452     290777     191223

*1  Also lines are excluded which only contains a dot 
    as end of a sentence.

*2  Excluded are empty lines / lines with only whitespace.

One of the first goals is to get a running I/O monitor which can serve
multiple applications running locally or remote.

This project is hosted by the Linux Organization in the Netherlands,
nl.linux.org. Those guys have also spent a lot of time to install the
services like www, cvs, ftp and majordomo. Thanks, Armijn, Cor, Mendel,
Rik. You can find these services at :
www.ftpm.org, cvs.ftpm.org, ftp.ftpm.org and maj...@nl....

Have fun.

Fred Mobach <fr...@mo...>

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

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

Next time you send me an update I will make the change and send it back to you, which you should use as a base. I have a sec script to do it.
No need to duplicate this.

Regards,
Tim Josling

"Steven O. Ellis" wrote:

> Tim,
>
> Am I to change each instance of INT32, UINT8, etc. as indicated below in
> the STRING routine and it's testing routines?
>
> -Steven Ellis
>
> Tim Josling wrote:
> >
> > Curt,
> >
> > I have updated the cvs version changing all the int/char/float
> > types to COB_*. So that means that
> >
> > INT32 -> COB_INT32
> > UINT8 -> COB_UINT8
> > ... etc
> > size_t -> COB_SIZE_T
> >
> > If you really need char (eg for a parm to pass to str*, then use
> > COB_CHAR. So
> >
> > char -> COB_CHAR
> >
> > This applies to all variables not just interfaces in header
> > files. The reason is for 64 bit CPU compatibility.
> >
> > 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 mailing list
> > Cob...@li...
> > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel
>
> --
> \/\/\/\/\/\/\/\/\/\/\/\/
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

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

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

Tim,

Am I to change each instance of INT32, UINT8, etc. as indicated below in
the STRING routine and it's testing routines?

-Steven Ellis


Tim Josling wrote:
> 
> Curt,
> 
> I have updated the cvs version changing all the int/char/float
> types to COB_*. So that means that
> 
> INT32 -> COB_INT32
> UINT8 -> COB_UINT8
> ... etc
> size_t -> COB_SIZE_T
> 
> If you really need char (eg for a parm to pass to str*, then use
> COB_CHAR. So
> 
> char -> COB_CHAR
> 
> This applies to all variables not just interfaces in header
> files. The reason is for 64 bit CPU compatibility.
> 
> 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 mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel

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

[Cobolforgcc-devel] IMPORTANT NEWS - '85 *ANSI* Standard soon to be WITHDRAWN !!!

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

FYI - this is *not* official yet - but I thought that I would send this out
to various vendors and other "interested" COBOL watchers - sooner rather
than later.

It appears as if the ANSI COBOL standards
 - X3.23-1985  ("The '85 Standard)
   and
 - X3.23a-1989 ("The Intrinsic Function Amendment")

will PROBABLY be withdrawn as ANSI Standards as of June 24, 2001. (With
little expectation that they will ever be "re-instated" - although that is a
theoretical possibility.)

NOTE WELL:
  This does *not* impact the status of the FIPS COBOL Standard (if any), ISO
COBOL Standards (although I don't personally understand what an endorsement
of a non-existent ANSI Standard means), X/Open CAE (if still considered
relevant), and it is even less clear what this means for X3.23b-1993 ("The
Correction Amendment")

Possibly MORE IMPORTANT - this "withdrawal" has no currently identified
impact on the ongoing work on a "full revision".  I have asked some
questions about what happens when you try to "revise" a "not current" ANSI
Standard, but I do not think that this has any "known" impact (on schedule
or required text).  I may hear differently on this at some time in the
future. It is even possible (although I question how likely it is) that J4
will actually be able to spend more time, sooner, on the revision - once
their current responsibilities for maintaining X3.23-1985 are "officially"
removed.

I must say here, that if I (personally) had kept "my mouth shut" and if the
current ANSI "bureaucracy" had gone along "silently and without comment" -
this might not have even been an issue.  Therefore, if you are particularly
unhappy about this - please feel free to send me any "hate" mail that you
think appropriate. Do not blame others (J4, NCITS, ANSI, etc) as all they
did was "ignore" (my wording - not theirs) maintenance of the current
Standard for five (or more) years.

The bottom-line is that ANSI Standards are supposed to be revised or AT
LEAST reaffirmed every five years.  There are rules that let the "five year"
reaffirmation "slip" - but there is another rule that says that "under NO
circumstances" may this slip more than 10 years.  By the end of June 2001,
the '85 Standard and the Intrinsic Function Amendment will have gone 10
years without a reaffirmation.

Given the same "bureaucracy" that has allowed "maintenance" of the current
Standard to be ignored (or at least prioritized so low that no work was ever
done on it), it was missed (until too late) that this 10 year date was
coming up.

I expect to see an official announcement of a Public Review period about
reaffirmation soon (probably the next few days) and will be happy to pass
this along when I see it.  I have already submitted my initial comments on
this reaffirmation - and will be happy to send a copy of this to any
individuals who are interested. (Please send me private email if you would
like a copy - before it is posted on the J4 web-site.)

BOTTOM-LINE:
  Will the world change on June 24, 2001?
   Will COBOL programmers notice any difference?
    Will COBOL vendors notice any difference?
     Will those "outside" of COBOL have any better or worse opinion of
COBOL?

I think the answer to all of these questions is NO!
  But if you disagree, please feel free to contact your "vendor of choice",
standards representative, or other "responsible" party to determine what
they have been doing for the past 5 years to maintain the '85 Standard - and
what they would be willing to do in the next few years (the time before they
produce a  200x conforming compiler - if that ever occurs) to actually
SUPPORT (not just give "lip service to") the current ANSI COBOL Standard(s).

NOTE WELL:
  This note is being sent well before June 23, 2001.  ANYTHING could happen
between now and then - so I don't "guarantee" there will be no "active"
COBOL Standard on June 24th - I just "extrapolate" this from the information
available to me at this time.

[Cobolforgcc-devel] Occurs clause added

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

I have added occurs code and tests to the CVS repository. Next is
pointers and linkage section, then local storage (trivial) then
fillers and duplicate data items. Then on to the procedure
division at last.

Tim Josling

[Cobolforgcc-devel] Press Release on COBOL Public Review

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

For those interested in the future of COBOL, the following is the complete
Press Release "requesting" Public Review Comments on the draft COBOL
Standard,

(a web copy of this can be found at:
  http://people.ne.mediaone.net/doncobol/01-0074.htm

The method described below is for submitting *US* public review comments.
If you are "outside" the US, please contact your national Standards body -
as documented at:
  http://www.iso.ch/addresse/membodies.html)

"IT/01-0162
J4/01-0074

National Committee for Information Technology Standards (NCITS)
NCITS Secretariat, Information Technology Industry Council (ITIC)
1250 Eye St. NW, Suite 200, Washington, DC 20005
Telephone 202-737-8888; Fax 202-638-4922;
Email: nc...@it...

Date: January 31, 2001

NCITS (National Committee for Information Technology Standards is announcing
the public comment period for ISO/IEC FCD 1989, Information Technology-
Programming languages, their environments and system software interfaces-
Programming Language COBOL. The public review extends from February23, 2001
to April 9, 2001, the U.S. TAG (NCITS/J4) will accept comments immediately.
ISO/IEC FCD 1989 can be downloaded from the NCITS/J4home page at:
http://www.ncits.org/tc_home/j4.htm

COBOL is the most widely used and most accepted of programming languages.
First developed in the late 1950's, COBOL has grown and evolved over time
with the release of international standards. Now in the wake of twin "40
Years of COBOL" celebrations in Japan and the US, a new draft international
standard is available for review.

The features of the new standard continue the COBOL tradition of being the
vanguard of international programming languages. The new standard continues
the tradition of the original COBOL specification, created to provide an
easy, natural syntax that is easy to use and maintain.

Key features of this draft include greater internationalization of the
language, better interlanguage communication and object orientation. In
addition, numerous updates to the syntax allows COBOL to continue as the
pre-eminent language for processing and manipulating data.  The introduction
of the new Validate feature is just one example. The new standard also
implements common exception handling.  Free format source will free the
programmer from the traditional 80 column restraints of the original COBOL.
Inline comments will make it easier to comment specific features of a
program to ease future maintenance.  New TYPEDEFS and new data types will
make it easier for the COBOL programmer to communicate with other languages
as well as making it easier for these other languages to make use of COBOL
programs that contain key business rules.

New COBOL development using Object Orientation will now be possible. The
COBOL OO syntax is feature rich and robust.  Object oriented programmers
will find the syntax familiar, while traditional COBOL programmers will be
pleased with the continued tradition of an English like syntax that makes
programs easy to read and understand.

COBOL is the language of the new millennium and NCITS/J4 is very pleased to
present this update for public review.

Public Review Comment Instructions

To facilitate speedy consideration of comments, please submit them via email
to Deborah Donovan at ddo...@it...,  with a copy to:  PSA Department
(ps...@an...) ANSI, 11 West  42nd Street, New York, NY  10036.  In
addition, all public review comments must include name, company name,
address, telephone number, and email address if applicable.

Any public review comments received after April 9, 2001 will be addressed
and considered for future balloting and/or revision.

[Note to Commentors]:  Due to their meeting schedule for ISO/IECFCD 1989,
the U.S. TAG (NCITS/J4) does not plan to be able to issue responses to
commentors until May 2002.

Call for Patents

A call for possible patents and pertinent issues (copyrights, trademarks) is
also being issued. Please submit information on these issues to the NCITS
Secretariat at 1250 Eye Street NW, Suite 200, Washington DC 20005.Email:
NCITS @itic.org

NCITS issues this call for patents in accordance with ANSI Procedures for
the Development and Coordination of American National Standards."


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

[Cobolforgcc-devel] Latest updates

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

I have uploaded the latest code from Curt Timmerman, Ted Seward,
Denial Ardison, and some bug fixes from Fergus Henderson to the
CVS. 

As mentioned before I also changed the UINT* and INT* to
COB_UINT* and COB_INT*. Have a look at cobr_temp_config.h for the
new details. 

We have now passed 50,000 lines of code. 

Tim Josling

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

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

Curt,

I have updated the cvs version changing all the int/char/float
types to COB_*. So that means that 

INT32 -> COB_INT32 
UINT8 -> COB_UINT8 
... etc
size_t -> COB_SIZE_T

If you really need char (eg for a parm to pass to str*, then use
COB_CHAR. So

char -> COB_CHAR

This applies to all variables not just interfaces in header
files. The reason is for 64 bit CPU compatibility.

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