Cobol - New Cobol compiler written in Cobol

Author

New Cobol compiler written in Cobol

Paul Robinson

2005-01-28, 3:55 pm

I am considering the development of a Cobol compiler itself written in
Cobol. Please don't flame me over the perceived stupidity of such a
choice, I think it is a better idea than a language that cannot compile
itself. I do believe obviously that there is enough power in the
language to implement a COBOL compiler using the COBOL language. After
all, a compiler is simply a program to translate text from a source into
a target. We're not talking rocket science or brain surgery here.

I believe there is money to be made with a good inexpensive Cobol
compiler which is available for several different targets, which would
allow applications to be used unchanged on different environments, such
as IBM Mainframe, DOS, Windows, Linux and others. Having done
maintenance on three other language compilers and written one from
scratch for Fortran in three months, I decided to focus on Cobol as I
think it is an underserved market and I think there is both room for
another product and sufficient market need to merit the time and effort
in developing one.

I am wondering if there was interest in such a thing. What I am
thinking about is something that did not require run-time licensing
fees, would not be hugely expensive as most Cobol compilers seem to be,
and by writing the compiler in Cobol itself, the people who use the
compiler, if they wanted an additional feature the compiler did not
supply, could write the code for it themselves if they chose to do so.
Oh yes, source code would be included as it has been long standing
policy that customers are entitled to be able to hire someone other than
the original development staff if they choose to do so or if it was no
longer possible to continue development. (Originally I wanted to write
"to hire someone not as good as the original development staff" in the
previous sentence but I decided I should be humble! I'm probably not
that good a programmer, and I'll probably get better as I get more
experience. I've only been doing programming for 24 years and I figure
I'll get better as I learn more.)

Perhaps I am misguided and there is no market or desire for such a
thing. I think there is, but I'd like to hear people's comments on
whether they would be interested in such a thing and how much
(seriously) it would be worth to them. I mean, if it is possible to
sell (nationally or worldwide) 10,000 copies at $100 each that's a huge
market. On the other hand it might be there's only interest for perhaps
500 copies of such an application in which case it would have to be more
expensive. Or I could be kidding myself that the market is saturated
and there really is no interest. I don't know enough to judge and I
don't have enough information to say. That's why I'm asking for comments.

There is also the issue that I may be pricing the product too high to be
worthwhile or that I'm pricing it so low that no one will take me
seriously. That is also why I'm trying to find out what people who
actually use Cobol (or would buy one for use in their shop) think such a
thing is worth. Obviously what I want to develop is something that is
so valuable to them for what is being charged that they both believe
they can't afford not to get it, and worry about buying it fast enough
before I come to our senses and raise the price on them. If that is the
case and I can make money off of it, it's a win-win situation for everyone.

There is also the issue that if there is interest I am going to want to
ask some people to either send me some of the code they use or examples
of some so I can test it or to be willing to try compiling production
code against various releases of the compiler and inform me if they get
the same results as their current system, or what differences they
notice. I'll file specific notices when that happens in order to
solicit beta testers, but I'm curious if there is interest.

I'm also interested in two things: (1) what features do you find missing
in Cobol compilers or the programming environment that you wish were
available, (2) what would you want from a good quality Cobol compiler,
again with a view towards something you think is worth paying for.

Of course you can try to tell me that I'm making a huge mistake and it's
pointless for me to bother, in which case I'd like to know your reasons.

Paul Robinson
paul at code-compiler dot com

Remove NOSPAM from out of header for private e-mail replies if desired,
but I really am interested in newsgroup replies.

Donald Tees

2005-01-28, 3:55 pm

Paul Robinson wrote:
> I am considering the development of a Cobol compiler itself written in
> Cobol. Please don't flame me over the perceived stupidity of such a
> choice, I think it is a better idea than a language that cannot compile
> itself. I do believe obviously that there is enough power in the
> language to implement a COBOL compiler using the COBOL language. After
> all, a compiler is simply a program to translate text from a source into
> a target. We're not talking rocket science or brain surgery here.
>
> I believe there is money to be made with a good inexpensive Cobol
> compiler which is available for several different targets, which would
> allow applications to be used unchanged on different environments, such
> as IBM Mainframe, DOS, Windows, Linux and others. Having done
> maintenance on three other language compilers and written one from
> scratch for Fortran in three months, I decided to focus on Cobol as I
> think it is an underserved market and I think there is both room for
> another product and sufficient market need to merit the time and effort
> in developing one.
>
> I am wondering if there was interest in such a thing. What I am
> thinking about is something that did not require run-time licensing
> fees, would not be hugely expensive as most Cobol compilers seem to be,
> and by writing the compiler in Cobol itself, the people who use the
> compiler, if they wanted an additional feature the compiler did not
> supply, could write the code for it themselves if they chose to do so.
> Oh yes, source code would be included as it has been long standing
> policy that customers are entitled to be able to hire someone other than
> the original development staff if they choose to do so or if it was no
> longer possible to continue development. (Originally I wanted to write
> "to hire someone not as good as the original development staff" in the
> previous sentence but I decided I should be humble! I'm probably not
> that good a programmer, and I'll probably get better as I get more
> experience. I've only been doing programming for 24 years and I figure
> I'll get better as I learn more.)
>
> Perhaps I am misguided and there is no market or desire for such a
> thing. I think there is, but I'd like to hear people's comments on
> whether they would be interested in such a thing and how much
> (seriously) it would be worth to them. I mean, if it is possible to
> sell (nationally or worldwide) 10,000 copies at $100 each that's a huge
> market. On the other hand it might be there's only interest for perhaps
> 500 copies of such an application in which case it would have to be more
> expensive. Or I could be kidding myself that the market is saturated
> and there really is no interest. I don't know enough to judge and I
> don't have enough information to say. That's why I'm asking for comments.
>
> There is also the issue that I may be pricing the product too high to be
> worthwhile or that I'm pricing it so low that no one will take me
> seriously. That is also why I'm trying to find out what people who
> actually use Cobol (or would buy one for use in their shop) think such a
> thing is worth. Obviously what I want to develop is something that is
> so valuable to them for what is being charged that they both believe
> they can't afford not to get it, and worry about buying it fast enough
> before I come to our senses and raise the price on them. If that is the
> case and I can make money off of it, it's a win-win situation for everyone.
>
> There is also the issue that if there is interest I am going to want to
> ask some people to either send me some of the code they use or examples
> of some so I can test it or to be willing to try compiling production
> code against various releases of the compiler and inform me if they get
> the same results as their current system, or what differences they
> notice. I'll file specific notices when that happens in order to
> solicit beta testers, but I'm curious if there is interest.
>
> I'm also interested in two things: (1) what features do you find missing
> in Cobol compilers or the programming environment that you wish were
> available, (2) what would you want from a good quality Cobol compiler,
> again with a view towards something you think is worth paying for.
>
> Of course you can try to tell me that I'm making a huge mistake and it's
> pointless for me to bother, in which case I'd like to know your reasons.
>
> Paul Robinson
> paul at code-compiler dot com
>
>
> Remove NOSPAM from out of header for private e-mail replies if desired,
> but I really am interested in newsgroup replies.

Count me in for a few hours a w

. As to specifics ... start small and
expand to everything.

Donald

Robert Wagner

2005-01-28, 3:55 pm

On Fri, 28 Jan 2005 14:54:40 GMT, Paul Robinson
<paul@NOSPAMcode-compiler.com> wrote:

>I am considering the development of a Cobol compiler itself written in
>Cobol. Please don't flame me over the perceived stupidity of such a
>choice, I think it is a better idea than a language that cannot compile
>itself. I do believe obviously that there is enough power in the
>language to implement a COBOL compiler using the COBOL language.

You're in good company. Realia, the best Cobol compiler ever written,
and Micro Focus, the leader outside mainframe, are both written in
Cobol.

>I believe there is money to be made with a good inexpensive Cobol
>compiler which is available for several different targets, which would
>allow applications to be used unchanged on different environments, such
>as IBM Mainframe, DOS, Windows, Linux and others.

Generating code for all those machines and interfacing with all those
APIs is a formidable task.

>I am wondering if there was interest in such a thing.

Certainly.

> by writing the compiler in Cobol itself, the people who use the
>compiler, if they wanted an additional feature the compiler did not
>supply, could write the code for it themselves if they chose to do so.

Not a good idea. Philosophically, it would be a proprietary language,
not Cobol. As a practical matter, nobody will do it. I wrote a text
editor that could be expanded by writing code in any compiled
language. No user was interested.

If they want to extend the language, OO gives them the ability to do
so without touching the compiler.

>Oh yes, source code would be included as it has been long standing
>policy that customers are entitled to be able to hire someone other than
>the original development staff if they choose to do so or if it was no
>longer possible to continue development.

Most users don't care whether source is available.

>Perhaps I am misguided and there is no market or desire for such a
>thing. I think there is, but I'd like to hear people's comments on
>whether they would be interested in such a thing and how much
>(seriously) it would be worth to them.

I think you underestimate the work involved. An efficient indexed file
system could be as much work as the compiler. Writing a sort is not
trivial. Would you include an integrated SQL preprocessor? You should.
That's a fair amount of work. How about an IDE and debugger? More
work. How about a GUI development kit?

> I mean, if it is possible to
>sell (nationally or worldwide) 10,000 copies at $100 each that's a huge
>market. On the other hand it might be there's only interest for perhaps
>500 copies of such an application in which case it would have to be more
>expensive. Or I could be kidding myself that the market is saturated
>and there really is no interest. I don't know enough to judge and I
>don't have enough information to say. That's why I'm asking for comments.

Every software project addresses the price/volume issue. As you know,
survivors decided on a high price. If they could have gotten richer by
selling a $100 compiler, they would have done so.

>There is also the issue that I may be pricing the product too high to be
>worthwhile or that I'm pricing it so low that no one will take me
>seriously.

Whether they take you seriously will be based on performance, not
price. The free and low cost compilers available now aren't taken
seriously because they're buggy and/or lacking features.

Microsoft sells polished compilers for just under $100 without much
complaint.

> That is also why I'm trying to find out what people who
>actually use Cobol (or would buy one for use in their shop) think such a
>thing is worth. Obviously what I want to develop is something that is
>so valuable to them for what is being charged that they both believe
>they can't afford not to get it, and worry about buying it fast enough
>before I come to our senses and raise the price on them. If that is the
>case and I can make money off of it, it's a win-win situation for everyone.

It's a lose if you spend five man-years developing it, a low-ball
estimate IMO, and sell only 5,000 copies.

>I'm also interested in two things: (1) what features do you find missing
>in Cobol compilers or the programming environment that you wish were
>available, (2) what would you want from a good quality Cobol compiler,
>again with a view towards something you think is worth paying for.

That's easy: everything in the 2002 Standard. Plus a few enhancements
as shown in Micro Focus and IBM manuals. Plus an IDE, debugger and GUI
modeled after VisDev and VC++.

I'd LOVE to work on such a compiler. Every time I think about it, I'm
dissuaded by the amount of work. It's too much for one person. Five to
ten people working full time might be able to do it in a year. Realia
was written by two people in 2-3 years .. without OO, Report Writer,
an IDE, a GUI developer and the additions in 2002.

JerryMouse

2005-01-28, 3:55 pm

Paul Robinson

2005-01-28, 3:55 pm

JerryMouse wrote:
> Paul Robinson wrote:
>
>
>
> The Realia compiler is written in COBOL. I saw the source listing once - a
> binder as tall as a basketball player (well, maybe a SHORT basketball
> player). As I recall it was 800,000 lines of code.
>

Maybe I'm missing something - or deluding myself - but I think that
seems extremely high. 800,000 lines of code seems to indicate an
application that is far too complex or possibly much of the code is
generated by other programs from specifications instead of written to
handle compilation of one or more Cobol source program files. Or maybe
I'm just a little bit brighter than I thought I was.

Richard

2005-01-28, 3:55 pm

CA recently open-sourced its Ingress database. Why not approach them
and suggest they open-source the Realia compiler and you would project
manage the code.

You could then concentrate on writing OO and ESQL rather than the
grubby bits.

Paul Robinson

2005-01-28, 3:55 pm

Robert Wagner wrote:

> On Fri, 28 Jan 2005 14:54:40 GMT, Paul Robinson
> <paul@NOSPAMcode-compiler.com> wrote:
>
>
>
> I think you underestimate the work involved. An efficient indexed file
> system could be as much work as the compiler.

There is already file system handling available for every major system
around. MySQL, PostGres, and Oracle supply them for Linux/Unix; ODBC,
Access and DBase drivers handle support for such things on Windows.

> Writing a sort is not trivial. Would you include an integrated
> SQL preprocessor? You should.

I don't think I need to do that because I think most database systems
provide one. At least Microsoft's SQL Server does, and I doubt other
database providers would fail to do so. Now if you mean support for
EXEC SQL
END EXEC
that's a matter of giving the database system the SQL code. I have an
idea about how that is to be done.

> That's a fair amount of work. How about an IDE and debugger? More
> work.

There are plenty of IDEs available and everyone has their favorite for
writing code. Further, IBM has released the Eclipse IDE, and as for a
debugger I have some ideas on that.

> How about a GUI development kit?

>
>
> Every software project addresses the price/volume issue. As you know,
> survivors decided on a high price. If they could have gotten richer by
> selling a $100 compiler, they would have done so.

Or perhaps they just decided they could get more so they sold it for
more. Do not expect people who run businesses to necessarily do right
or we wouldn't have a company spending $100 million on a conversion
package that has to be scrapped. And wouldn't see same sort of botched
disaster dozens of times in many different companies.

>
> Whether they take you seriously will be based on performance, not
> price. The free and low cost compilers available now aren't taken
> seriously because they're buggy and/or lacking features.

Okay. I have noticed that to be the case. Far too often.

> It's a lose if you spend five man-years developing it, a low-ball
> estimate IMO, and sell only 5,000 copies.

Actually I can live with that.

>
> That's easy: everything in the 2002 Standard. Plus a few enhancements
> as shown in Micro Focus and IBM manuals. Plus an IDE, debugger and GUI
> modeled after VisDev and VC++.
>
> I'd LOVE to work on such a compiler. Every time I think about it, I'm
> dissuaded by the amount of work. It's too much for one person. Five to
> ten people working full time might be able to do it in a year. Realia
> was written by two people in 2-3 years .. without OO, Report Writer,
> an IDE, a GUI developer and the additions in 2002.

I think the failure to consider third-party tools is the big problem in
such development. Object Orientation I think can be implemented
reasonably. Report writer I think can be obtained by generating PDF
files or perhaps something else. For an IDE I think I can try Eclipse
as I believe it supports multiple languages. Or look at other things.
A GUI developer I'll get to. There are things which have been developed
for various systems. I don't expect to develop something this big
overnight. It will take at least a couple of days.

Louis Krupp

2005-01-28, 8:55 pm

Paul Robinson wrote:
> Robert Wagner wrote:
<snip>
>
>
> I think the failure to consider third-party tools is the big problem in
> such development. Object Orientation I think can be implemented
> reasonably. Report writer I think can be obtained by generating PDF
> files or perhaps something else. For an IDE I think I can try Eclipse
> as I believe it supports multiple languages. Or look at other things. A
> GUI developer I'll get to. There are things which have been developed
> for various systems. I don't expect to develop something this big
> overnight. It will take at least a couple of days.

I don't think COBOL Report Writer has much to do with PDF.

BTW, Google came up with this:

http://cobolforgcc.sourceforge.net/cobol_12.html

Quoting:

"We are working on a subset which will allow most of the runtime and
parts of the compiler itself to be written in COBOL."

Louis Krupp

Chuck Stevens

2005-01-28, 8:55 pm

"Paul Robinson" <paul@NOSPAMcode-compiler.com> wrote in message
news:BMuKd.9$iD.7@trnddc08...
> JerryMouse wrote:
After[color=darkred]
a[color=darkred]
>
> Maybe I'm missing something - or deluding myself - but I think that
> seems extremely high. 800,000 lines of code seems to indicate an
> application that is far too complex or possibly much of the code is
> generated by other programs from specifications instead of written to
> handle compilation of one or more Cobol source program files. Or maybe
> I'm just a little bit brighter than I thought I was.

I don't think that's all that high. The monolithic COBOL74 compiler for
Unisys MCP systems is in an ALGOL dialect (NEWP), and it's about 133k lines
(supporting lots of Unisys extensions); the predecessor COBOL(68) compiler
in ALGOL was just under 60K.

Given COBOL's infamous wordiness, and the standards features that
'85-and-later COBOL has that '74 did not, 800K for a modern COBOL compiler
written in COBOL doesn't seem all that excessive.

The COBOL85 compiler for the Unisys MCP environment is modular and part of a
system that accommodates both multiple code generators and multiple
languages, so line counts for it (in Pascal83) aren't really comparable.

-Chuck Stevens

William M. Klein

2005-01-28, 8:55 pm

--
Bill Klein
wmklein <at> ix.netcom.com
"Paul Robinson" <paul@NOSPAMcode-compiler.com> wrote in message
news:BMuKd.9$iD.7@trnddc08...
> JerryMouse wrote:
>
> Maybe I'm missing something - or deluding myself - but I think that seems
> extremely high. 800,000 lines of code seems to indicate an application that
> is far too complex or possibly much of the code is generated by other programs
> from specifications instead of written to handle compilation of one or more
> Cobol source program files. Or maybe I'm just a little bit brighter than I
> thought I was.

William M. Klein

2005-01-28, 8:55 pm

"Paul Robinson" <paul@NOSPAMcode-compiler.com> wrote in message
news:BMuKd.9$iD.7@trnddc08...
> JerryMouse wrote:
<snip[color=darkred]
>
> Maybe I'm missing something - or deluding myself - but I think that seems
> extremely high. 800,000 lines of code seems to indicate an application that
> is far too complex or possibly much of the code is generated by other programs
> from specifications instead of written to handle compilation of one or more
> Cobol source program files. Or maybe I'm just a little bit brighter than I
> thought I was.

You might (probably) could create an '85 Standard intermediate level compiler
(not including code generation) in COBOL (with extensions - so you couldn't
compile itself) in under 800,000 lines. HOWEVER, if you go for a full
high-level '85 Standard compiler (no optional modules) with just the "most
common" extensions, then I think it would certainly take that many lines (at
least).

I assume that your goal would be to make the compiler such that it could compile
itself. To do so, I would say that you need many/most of the extensions (to the
'85 Standard) added for "C-ification" in the '02 Standard. This includes such
things as:

Pointers (possibly procedure-pointers and function-pointers)
"true binary" (no truncation according to picture clause)
Bit-manipulation
Possibly "call-conventions" (to interact with operating system routines)

If you include the '89 Standard Intrinsic Functions, there are things that I
have (yet) to figure out how they could be done in COBOL (even with the '02
Standard), e.g.

Compute Which-Item = Function Ord-Max (table1 (all) table2 (all))

where the elementary items in table1 and table2 are NOT the same data definition
and either or both are ODOs.

As far as "common" extensions, the history of COBOL and the influence of IBM (in
the past at least) makes me think that you should look at their current
extensions listed at:

http://publibz.boulder.ibm.com/cgi-...R20/APPENDIX1.1

I would say that MOST (at least of the non-OO stuff) is available in many of the
PC/Linux/Unix compilers available today, e.g. Micro Focus, Realia, and Fujitsu -
and to a lesser extent AcuCOBOL and RM.

The X/Open extensions (such as LINE SEQUENTIAL and concatenation of literals)
are medium common too (and used). I would not personally go with Screen
Section/Accept/Display *UNLESS* you are targeting a "UNIX" type environment.

Personally, I would go (at least initially) with someone ELSE's indexed file
system (e.g. BTrieve) and someone else's SQL (even if this would cost the user
more).

Internationalization is a BIGGIE in the '02 Standard (including LOCALE support
as well as PIC N and various other stuff). Unless you get funding from
somewhere requiring it, I wouldn't do it in a first release.

Unless you decide to create your compiler using OO, I would not put in the OO
support initially. This certainly should be a goal to be "real world" product,
but I just don't see it being what the typical $100 COBOL programmer wants. (I
could be mistaken on this - and this forum probably won't agree - but it my
perception.)

Have you looked at Kobol? I don't *think* it has been all that successful, so
you would need to figure out what you had to offer that they don't. This, of
course assumes you are thinking of doing this as a "business" not as a hobby or
"gift to the community".

***

Finally, Although I don't think I could help too much with writing the compiler,
I would be happy to create test cases for you.

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

Joe Zitzelberger

2005-01-28, 8:55 pm

Sounds very

.

My two big feature requests are plug-in style back end to allow for
machine portability. And Operating System abstraction library to allow
for true portability.

I'd pay a hundred bucks for it, but I'd rather help write it...

In article <QmsKd.3320$u45.2035@trnddc08>,
Paul Robinson <paul@NOSPAMcode-compiler.com> wrote:

> I am considering the development of a Cobol compiler itself written in
> Cobol. Please don't flame me over the perceived stupidity of such a
> choice, I think it is a better idea than a language that cannot compile
> itself. I do believe obviously that there is enough power in the
> language to implement a COBOL compiler using the COBOL language. After
> all, a compiler is simply a program to translate text from a source into
> a target. We're not talking rocket science or brain surgery here.
>
> I believe there is money to be made with a good inexpensive Cobol
> compiler which is available for several different targets, which would
> allow applications to be used unchanged on different environments, such
> as IBM Mainframe, DOS, Windows, Linux and others. Having done
> maintenance on three other language compilers and written one from
> scratch for Fortran in three months, I decided to focus on Cobol as I
> think it is an underserved market and I think there is both room for
> another product and sufficient market need to merit the time and effort
> in developing one.
>
> I am wondering if there was interest in such a thing. What I am
> thinking about is something that did not require run-time licensing
> fees, would not be hugely expensive as most Cobol compilers seem to be,
> and by writing the compiler in Cobol itself, the people who use the
> compiler, if they wanted an additional feature the compiler did not
> supply, could write the code for it themselves if they chose to do so.
> Oh yes, source code would be included as it has been long standing
> policy that customers are entitled to be able to hire someone other than
> the original development staff if they choose to do so or if it was no
> longer possible to continue development. (Originally I wanted to write
> "to hire someone not as good as the original development staff" in the
> previous sentence but I decided I should be humble! I'm probably not
> that good a programmer, and I'll probably get better as I get more
> experience. I've only been doing programming for 24 years and I figure
> I'll get better as I learn more.)
>
> Perhaps I am misguided and there is no market or desire for such a
> thing. I think there is, but I'd like to hear people's comments on
> whether they would be interested in such a thing and how much
> (seriously) it would be worth to them. I mean, if it is possible to
> sell (nationally or worldwide) 10,000 copies at $100 each that's a huge
> market. On the other hand it might be there's only interest for perhaps
> 500 copies of such an application in which case it would have to be more
> expensive. Or I could be kidding myself that the market is saturated
> and there really is no interest. I don't know enough to judge and I
> don't have enough information to say. That's why I'm asking for comments.
>
> There is also the issue that I may be pricing the product too high to be
> worthwhile or that I'm pricing it so low that no one will take me
> seriously. That is also why I'm trying to find out what people who
> actually use Cobol (or would buy one for use in their shop) think such a
> thing is worth. Obviously what I want to develop is something that is
> so valuable to them for what is being charged that they both believe
> they can't afford not to get it, and worry about buying it fast enough
> before I come to our senses and raise the price on them. If that is the
> case and I can make money off of it, it's a win-win situation for everyone.
>
> There is also the issue that if there is interest I am going to want to
> ask some people to either send me some of the code they use or examples
> of some so I can test it or to be willing to try compiling production
> code against various releases of the compiler and inform me if they get
> the same results as their current system, or what differences they
> notice. I'll file specific notices when that happens in order to
> solicit beta testers, but I'm curious if there is interest.
>
> I'm also interested in two things: (1) what features do you find missing
> in Cobol compilers or the programming environment that you wish were
> available, (2) what would you want from a good quality Cobol compiler,
> again with a view towards something you think is worth paying for.
>
> Of course you can try to tell me that I'm making a huge mistake and it's
> pointless for me to bother, in which case I'd like to know your reasons.
>
> Paul Robinson
> paul at code-compiler dot com
>
>
> Remove NOSPAM from out of header for private e-mail replies if desired,
> but I really am interested in newsgroup replies.

Robert Wagner

2005-01-29, 3:55 am

On 28 Jan 2005 10:07:47 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>CA recently open-sourced its Ingress database. Why not approach them
>and suggest they open-source the Realia compiler and you would project
>manage the code.
>
>You could then concentrate on writing OO and ESQL rather than the
>grubby bits.

Great idea! Really. The only conflict is that Paul wants to make
money. He could by offering a GPL license (free) for amateurs and a
commercial license for companies. That's how PostGre does it. The
issue then becomes how big a slice of the commercial income goes to
CA.I wouldn't give them more than 10%.

Robert Wagner

2005-01-29, 3:55 am

On Fri, 28 Jan 2005 19:17:33 GMT, Paul Robinson
<paul@NOSPAMcode-compiler.com> wrote:

>Robert Wagner wrote:
>
>
>There is already file system handling available for every major system
>around. MySQL, PostGres, and Oracle supply them for Linux/Unix; ODBC,
>Access and DBase drivers handle support for such things on Windows.

Those are databases, although a database can simulate ISAM. There
are licensing issues with all three. The one you want is PostGre,
because it offers both GPL (free) and commercial versions.

>
>I don't think I need to do that because I think most database systems
>provide one.

True but they suck. Oracle's is the worst. The trend is for Cobol
compilers to support SQL intrinsically.

>At least Microsoft's SQL Server does, and I doubt other
>database providers would fail to do so. Now if you mean support for
>EXEC SQL
>END EXEC
>that's a matter of giving the database system the SQL code. I have an
>idea about how that is to be done.

Integrated compilers do a PREPARE to get the server to check for
syntactical and lexicological errors. But if the database isn't
available at compile time, the compiler must be able to check syntax
on its own.

>
>There are plenty of IDEs available and everyone has their favorite for
>writing code. Further, IBM has released the Eclipse IDE, and as for a
>debugger I have some ideas on that.

Eclipse isn't IBM's to release. It's owned by the Eclipse Organization
and is solidly Open Source.

>
>Or perhaps they just decided they could get more so they sold it for
>more. Do not expect people who run businesses to necessarily do right
>or we wouldn't have a company spending $100 million on a conversion
>package that has to be scrapped. And wouldn't see same sort of botched
>disaster dozens of times in many different companies.

Corporate end-users can survive such follies because they have another
stream of income. Software companies don't have that cushion. One bad
decision is all it takes to make them dry up and blow away like the
leaves of autumn. I've been there.

>I think the failure to consider third-party tools is the big problem in
>such development. Object Orientation I think can be implemented
>reasonably. Report writer I think can be obtained by generating PDF
>files or perhaps something else.

PDF is not the answer to Report Writer. The compiler must generate
code. It's not difficult, just a waste of time on a feature that won't
be used, IMO.

>For an IDE I think I can try Eclipse
>as I believe it supports multiple languages. Or look at other things.
>A GUI developer I'll get to. There are things which have been developed
>for various systems. I don't expect to develop something this big
>overnight. It will take at least a couple of days.

I like your optimism.

jce

2005-01-29, 3:55 am

>>There are plenty of IDEs available and everyone has their favorite for
>
> Eclipse isn't IBM's to release. It's owned by the Eclipse Organization
> and is solidly Open Source.
It was released by IBM. It is now solidly open source, but they've already
started a fee based program....whoopee...

> PDF is not the answer to Report Writer. The compiler must generate
> code. It's not difficult, just a waste of time on a feature that won't
> be used, IMO.
Agree. I'd rather keep my report writing capability outside of the build
process.
[color=darkred]
Eclipse supports anything you want to put into it.

JCE

Robert Wagner

2005-01-29, 3:55 am

On Fri, 28 Jan 2005 12:01:17 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>a
>
>I don't think that's all that high. The monolithic COBOL74 compiler for
>Unisys MCP systems is in an ALGOL dialect (NEWP), and it's about 133k lines
>(supporting lots of Unisys extensions); the predecessor COBOL(68) compiler
>in ALGOL was just under 60K.
>
>Given COBOL's infamous wordiness, and the standards features that
>'85-and-later COBOL has that '74 did not, 800K for a modern COBOL compiler
>written in COBOL doesn't seem all that excessive.

According to Marc Sokol, who wrote it, more than half those 800K lines
were the file system. After deducting tools (realcopy) and runtime,
the compiler core was probably less than 300K lines.

Robert Wagner

2005-01-29, 3:55 pm

On Sat, 29 Jan 2005 06:52:04 GMT, "jce" <defaultuser@hotmail.com>
wrote:

>Agree. I'd rather keep my report writing capability outside of the build
>process.

If Report Writer is omitted, the compiler cannot claim to be compliant
with the 2002 Standard. That also applies to Screen Section.

William M. Klein

2005-01-29, 3:55 pm

Robert,
You are right about Report Writer but

WRONG
about Screen Section

Screen Section and related Accept/Display" is in the

Processor Dependent

list and therefore, may be omitted for ANY reason the implementor wants.
(Functionally this is the same as "optional" was in the '85 Standard).

P.S. I can't imagine ANY implementor "starting" with an '02 conforming
compiler - as there is no existing vendor (that i know of) that claims to be
fully conforming to the '02 Standard.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:ue1nv0504pe0op9q5e2g6glqbf90h4ctkr@
4ax.com...
> On Sat, 29 Jan 2005 06:52:04 GMT, "jce" <defaultuser@hotmail.com>
> wrote:
>
>
> If Report Writer is omitted, the compiler cannot claim to be compliant
> with the 2002 Standard. That also applies to Screen Section.

Lueko Willms

2005-01-29, 3:55 pm

.. On 29.01.05
wrote spamblocker-robert@wagner.net (Robert Wagner)
on /COMP/LANG/COBOL
in ue1nv0504pe0op9q5e2g6glqbf90h4ctkr@4ax.com
about Re: New Cobol compiler written in Cobol

RW> If Report Writer is omitted, the compiler cannot claim to be
RW> compliant with the 2002 Standard. That also applies to Screen
RW> Section.

Such a compiler can comply to COBOL-1985 with extensions taken from
the 2002 standard.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Der Verleger hat ihn in effigie vor sein Werk aufhängen lassen. -G.C.Lichtenberg

Robert Wagner

2005-01-29, 3:55 pm

On Sat, 29 Jan 2005 16:21:44 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Robert,
> You are right about Report Writer but
>
>WRONG
> about Screen Section
>
>Screen Section and related Accept/Display" is in the
>
> Processor Dependent
>
>list and therefore, may be omitted for ANY reason the implementor wants.
>(Functionally this is the same as "optional" was in the '85 Standard).

Whoops, I stand corrected. I thought it had to be a GOOD reason
because the Standard says "are dependent on the functionality of the
processor" and "dependent upon a terminal device capable of supporting
them". A desktop PC is certainly capable, and variations of DISPLAY ..
AT seem to be in common use in some cultures, notably AcuCobol.

If the compiler has a GUI tool, Screen Section does seem superfluous.

>P.S. I can't imagine ANY implementor "starting" with an '02 conforming
>compiler - as there is no existing vendor (that i know of) that claims to be
>fully conforming to the '02 Standard.

If starting from scratch, it's easier to do full '02 than to do '85
followed by an upgrade. Moreover, full '02 would be a good selling
point and give the compiler credibility.

Most of the '85 features deemed obsolete in '02 are used so seldom,
they're not worth worrying about. I'd support debugging and all those
FD and ID Division entries as comments. I would not support ALTER.

steve.t

2005-01-30, 3:55 am

Paul:

The code generator, in my opinion, would have to be architecture
specific. It is possible to generate an object deck/file with COBOL now
(I know, I've done similar work).

I am currently working on a compiler based on COBOL (the source
language). However, I intend to have different code generators
depending on whether I want to generate an object or new source (a
migration tool).

COBOL is an interesting language in that you must do different things
depending on the environment you are in (perhaps I should have said
DIVISION?). The keywords change meanings! (But you must have already
known that).

I wish I could say that I would be interested in what you are doing --
from the viewpoint of being able to test it. However, due to probable
changes taking place in my life, I may not be able to continue the
development I'm currently doing.

The IDE and other things are not really needed in my opinion. Assuming
that one is using the Windoze environment, a DOS window can be used to
run the compiler, and Notepad can be used to view the listing/source
files. I happen to prefer an "SPF" product for source work.

Doing things without a runtime means having to generate a lot of code
from/with the code generator.

File handling will also get to be pretty labor intensive. You will have
to write all the code for handling the file and error processing, etc.

Might I suggest that you first tackle the first level of COBOL support
(Mr. Klein can give you the levels) and then add to that. Be prepared
for the source processor to be rather large and possibly have to be
written in separate subprograms.

Again, the code generator is what concerns me. How and who would write
the generator for each environment?

Lastly, I would love to have an '85 COBOL compiler for Linux. I could
move my whole development environment off to Linux and get rid of
Windoze.

Regards,
Steve.T

Robert Wagner

2005-01-30, 3:55 am

On 29 Jan 2005 21:44:50 -0800, "steve.t" <sthompson@ix.netcom.com>
wrote:

>Lastly, I would love to have an '85 COBOL compiler for Linux. I could
>move my whole development environment off to Linux and get rid of
>Windoze.

Fujitsu sells one for $2,500. Kobol sells one for $60. TinyCobol is
free.

Richard

2005-01-30, 3:55 pm

>> Lastly, I would love to have an '85 COBOL compiler for Linux.

> Fujitsu sells one for $2,500. Kobol sells one for $60. TinyCobol is
free.

Plus the usual cross-platform group from MF, RM, Acu.

Robert Wagner

2005-01-30, 3:55 pm

In 1962 (or so) IBM released the 1401 computer system. The dominant
machines at the time were the IBM 7090 and similar 7040. Next to them,
the 1401 looked like a toy. It couldn't address more than 16K of
memory and had no operating system. Its strongest feature was a 600
lpm printer. Mainframers brushed it aside as a computer, thinking of
it as a programmable off-line I/O device, which is the role it played
in big companies. For medium-sized companies, it was the first
computer they could afford. By 1965, when it morphed into the IBM-360,
the 14xx line had grown to become the dominant business computer.

IN 1982 IBM released the PC. The doinant business machines at the time
were the IBM 370. Next to them, the PC looked like a toy. It couldn't
address more than 640K and had a rudimentary operating system: MS-DOS.
It didn't support tape drives, which were still important in the
mainframe world, had a 10M disk and was slow. Its strongest feature
was a memory-mapped screen. Mainframers brushed it aside as a
computer, thinking of it as a programmable terminal, which is the role
it still plays in big companies. For small companies and home
businesses, it was the first computer they could afford. By 1995, when
it morphed into the Wintel box, the PC had grown to become the
dominant computer line.

In 2002 Microsoft released the XBox. The dominant machines at the time
were Windows boxes and Unix servers. Next to them, the XBox (and other
game machines) looked like a toy. It couldn't run 'real' software,
only games. It didn't have a visible operating system. Its only strong
feature was high-speed floating point. Big whoop. Programmers brushed
it aside as a computer, thinking of it as a programmable consumer
electronics entertainment device. Kids got it because their parents
didn't trust them with a 'real' computer having internet access (they
didn't notice the XBox also had internet access).

Note the regularity of timing -- twenty years between generations, by
coincidence the same as human generations. Note the similarity of
low-profile introduction and initial scorn by the computing
mainstream. Note the rapid growth of hardware capacity, which quickly
surpassed mainstream systems.

I think we have a pattern.

If I were writing a Cobol compiler, I wouldn't look at today's market.
That's myopic. I'd target the market 5 years hence. It won't be
Microsoft/Windows or Sun/Java; it will be a fat XBox or Playstation
running Linux. It will have multiple CPUs, blazing speed and huge
storage. TV-like graphics and sound will be the norm rather than an
add-on.

What will a programming language need to be successful in that world?
Ease Of Use. Programmers won't put up with cryptic languages like C++
and Java. They'll use a language they can understand at a glance.
Bingo -- that's Cobol's strength. They'll expect database to be
integrated, not an add-on. They'll expect a polished navigation in the
IDE -- more like Acrobat than a fancy text editor.

What will a programming language need to fail in that world?
Antequated concepts like binary and packed numbers, string handling
that's incompatible with other languages, difficulty communicating
with OO languages and libraries, flat files (they belong in a library,
not a language).

Donald Tees

2005-01-30, 3:55 pm

Robert Wagner wrote:
> In 1962 (or so) IBM released the 1401 computer system. The dominant
> machines at the time were the IBM 7090 and similar 7040. Next to them,
> the 1401 looked like a toy. It couldn't address more than 16K of
> memory and had no operating system. Its strongest feature was a 600
> lpm printer. Mainframers brushed it aside as a computer, thinking of
> it as a programmable off-line I/O device, which is the role it played
> in big companies. For medium-sized companies, it was the first
> computer they could afford. By 1965, when it morphed into the IBM-360,
> the 14xx line had grown to become the dominant business computer.
>
> IN 1982 IBM released the PC. The doinant business machines at the time
> were the IBM 370. Next to them, the PC looked like a toy. It couldn't
> address more than 640K and had a rudimentary operating system: MS-DOS.
> It didn't support tape drives, which were still important in the
> mainframe world, had a 10M disk and was slow. Its strongest feature
> was a memory-mapped screen. Mainframers brushed it aside as a
> computer, thinking of it as a programmable terminal, which is the role
> it still plays in big companies. For small companies and home
> businesses, it was the first computer they could afford. By 1995, when
> it morphed into the Wintel box, the PC had grown to become the
> dominant computer line.
>
> In 2002 Microsoft released the XBox. The dominant machines at the time
> were Windows boxes and Unix servers. Next to them, the XBox (and other
> game machines) looked like a toy. It couldn't run 'real' software,
> only games. It didn't have a visible operating system. Its only strong
> feature was high-speed floating point. Big whoop. Programmers brushed
> it aside as a computer, thinking of it as a programmable consumer
> electronics entertainment device. Kids got it because their parents
> didn't trust them with a 'real' computer having internet access (they
> didn't notice the XBox also had internet access).
>
> Note the regularity of timing -- twenty years between generations, by
> coincidence the same as human generations. Note the similarity of
> low-profile introduction and initial scorn by the computing
> mainstream. Note the rapid growth of hardware capacity, which quickly
> surpassed mainstream systems.
>
> I think we have a pattern.
>
> If I were writing a Cobol compiler, I wouldn't look at today's market.
> That's myopic. I'd target the market 5 years hence. It won't be
> Microsoft/Windows or Sun/Java; it will be a fat XBox or Playstation
> running Linux. It will have multiple CPUs, blazing speed and huge
> storage. TV-like graphics and sound will be the norm rather than an
> add-on.
>
> What will a programming language need to be successful in that world?
> Ease Of Use. Programmers won't put up with cryptic languages like C++
> and Java. They'll use a language they can understand at a glance.
> Bingo -- that's Cobol's strength. They'll expect database to be
> integrated, not an add-on. They'll expect a polished navigation in the
> IDE -- more like Acrobat than a fancy text editor.
>
> What will a programming language need to fail in that world?
> Antequated concepts like binary and packed numbers, string handling
> that's incompatible with other languages, difficulty communicating
> with OO languages and libraries, flat files (they belong in a library,
> not a language).

Aye, and the way to supply that is not in the traditional
compiler/linker/loader model, at least not visibly, up front.

If you are going to take OOP seriously, then basics like a "program", A
sybroutine" and "a method" should be defined in cobol at the source
level. In other words I should be able to code some thing like:

move "MY-PROGRAM-ID" TO PROGRAM-ID-PARAGRAPH OF standard-cobol-object.
INVOKE STANDARD-COBOL-OBJECT "COMPILE".
INVOKE STANDARD-COBOL-OBJECT "RUN".

The pubic domain "compiler" then, does not translate COBOL source into
object at all. It translates the code into some form of platform
indepent Cobol source that exists as Cobol readable data, readable by
itself, that it can re-write in the local cobol dialect. One you can do
the above on the local platform, you should be able to bootstrap the
system for each platform.

Donald

R.Freitag

2005-01-30, 8:55 pm

Robert Wagner wrote:
[...]
> I think we have a pattern.
>
You are focusing on the hardware pattern. This is fairly right. But as the
hardware has become powerful the software becomes also mighty- and i see a
trend that programmers tend to program more to APIs each step. In the
beginning we had really nothing except a file system. Now we have the API
of the Java machine which is available for each Hardware.

> If I were writing a Cobol compiler, I wouldn't look at today's market.
> That's myopic. I'd target the market 5 years hence. It won't be
> Microsoft/Windows or Sun/Java; it will be a fat XBox or Playstation
> running Linux. It will have multiple CPUs, blazing speed and huge
> storage. TV-like graphics and sound will be the norm rather than an
> add-on.
>
You have to look at the status quo. He is defined by Java and the JVM ( each
JVM for each Configuration) but basically code reuns everywhere. This makes
it as a de-facto-standard for the future.

> What will a programming language need to be successful in that world?
> Ease Of Use. Programmers won't put up with cryptic languages like C++
> and Java. They'll use a language they can understand at a glance.
> Bingo -- that's Cobol's strength. They'll expect database to be
> integrated, not an add-on. They'll expect a polished navigation in the
> IDE -- more like Acrobat than a fancy text editor.
>

Combine the jvm with COBOL and you are done.

Robert

Richard

2005-01-30, 8:55 pm

> Note the regularity of timing -- twenty years between generations,

Only if you ignore everything else that happened. Being selective
allows you to 'prove' any conclusion you started with.

For example 1992 or so was a significant date as the release of the
first usable version of Windows, yet it didn't fit in your '20 years'
so you didn't mention it.

> the PC had grown to become the dominant computer line.

Mainly because of Novell Netware making shared resources available
within the whole business. Again the date didn't fit your '20 year
theory'.

> Mainframers brushed it aside as a computer, thinking of it as a
programmable terminal,

IBM designed the IBM PC to be a 'better Apple ][ PC' which was
increasingly being found in corporate mainframe sites where it was used
to run Visicalc and word processing.

> I'd target the market 5 years hence. It won't be Microsoft/Windows or
Sun/Java;

I certainly agree that the market in 5 years won't be Windows or Sun.
MS are completely changing the APIs so that when Longhorn ever arrives
it won't be Windows, except in name. But by then MS will be as dead as
DOS made CP/M.

> it will be a fat XBox or Playstation running Linux. It will have
multiple CPUs, blazing speed and huge storage.

Multi-CPU and 'blazing speed' maybe but 'XBox or Playstion' is not how
I would put it. It does seem that 'XBox Next' will be Power based with
IBM manufacturing the chips while PS/3 also uses IBM tecnology which
may utilise Power designs.

Now we should see why IBM sold off, sorry 'partnered', the PC division.
Apart from being a foothold in China it also dumps the contracts with
Intel and MS leaving them free to come up with an in-house Power based
machine running Linux that can be everything from a cheap diskless
terminal (like LTSP) through desktops running Linux/workspace to
clustered servers and supercomputer closely coupled machines.

IBM can make Power chips at a fraction of the price of buying in
Pentiums. As the hardware price falls the software becomes the largest
part of the cost. Linux/Workspace (based on OpenOffice.org) will be a
fraction of the price of Windows/Office and will avoid all the TCO of
having to maintain the crap that the BSA 'spanish inquisition' insists
on.

Microsoft is increasingly tied to having to maintain individual
tracking of every licence and subscription and tying down every copy to
combat piracy, especially in emerging markets. This makes it onerous on
the users by way of the BSA, failed installs, having to repurchase if
hardware is changed, DRM, so called 'Trusted Computing' (in which MS
trusts none of their customers) and having to maintain 'subscriptions'.

The new IBMs will make all that irrelevant, much to the customers'
delight, and to MS's dismay.

> TV-like graphics and sound will be the norm rather than an
add-on.

'TV-like' is very poor compared to computer monitors. If you mean
'realistic animation' then yes, but that is not 'tv-like'.

> Programmers won't put up with cryptic languages like C++
> and Java. They'll use a language they can understand at a glance.

Sorry, but _you_ may find C++ and Java cryptic, but programmers do not,
_they_ can understand Java and C++ at a glance.

What is 'easy to understand at a glance' is entirely what one is used
to. You are used to Cobol, others are used to C++, Java, Python, Perl,
or whatever. Thus they find their language as easy as you do yours.

Robert Wagner Jan 30, 10:13 am show options
Newsgroups: comp.lang.cobol
From: Robert Wagner <spamblocker-rob...@wagner.net> - Find messages by
this author
Date: Sun, 30 Jan 2005 18:13:06 GMT
Local: Sun, Jan 30 2005 10:13 am
Subject: Re: New Cobol compiler written in Cobol
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse

In 1962 (or so) IBM released the 1401 computer system. The dominant
machines at the time were the IBM 7090 and similar 7040. Next to them,
the 1401 looked like a toy. It couldn't address more than 16K of
memory and had no operating system. Its strongest feature was a 600
lpm printer. Mainframers brushed it aside as a computer, thinking of
it as a programmable off-line I/O device, which is the role it played
in big companies. For medium-sized companies, it was the first
computer they could afford. By 1965, when it morphed into the IBM-360,
the 14xx line had grown to become the dominant business computer.

IN 1982 IBM released the PC. The doinant business machines at the time
were the IBM 370. Next to them, the PC looked like a toy. It couldn't
address more than 640K and had a rudimentary operating system: MS-DOS.
It didn't support tape drives, which were still important in the
mainframe world, had a 10M disk and was slow. Its strongest feature
was a memory-mapped screen. Mainframers brushed it aside as a
computer, thinking of it as a programmable terminal, which is the role
it still plays in big companies. For small companies and home
businesses, it was the first computer they could afford. By 1995, when
it morphed into the Wintel box, the PC had grown to become the
dominant computer line.

In 2002 Microsoft released the XBox. The dominant machines at the time
were Windows boxes and Unix servers. Next to them, the XBox (and other
game machines) looked like a toy. It couldn't run 'real' software,
only games. It didn't have a visible operating system. Its only strong
feature was high-speed floating point. Big whoop. Programmers brushed
it aside as a computer, thinking of it as a programmable consumer
electronics entertainment device. Kids got it because their parents
didn't trust them with a 'real' computer having internet access (they
didn't notice the XBox also had internet access).

Note the regularity of timing -- twenty years between generations, by
coincidence the same as human generations. Note the similarity of
low-profile introduction and initial scorn by the computing
mainstream. Note the rapid growth of hardware capacity, which quickly
surpassed mainstream systems.

I think we have a pattern.

If I were writing a Cobol compiler, I wouldn't look at today's market.
That's myopic. I'd target the market 5 years hence. It won't be
Microsoft/Windows or Sun/Java; it will be a fat XBox or Playstation
running Linux. It will have multiple CPUs, blazing speed and huge
storage. TV-like graphics and sound will be the norm rather than an
add-on.

What will a programming language need to be successful in that world?
Ease Of Use. Programmers won't put up with cryptic languages like C++
and Java. They'll use a language they can understand at a glance.
Bingo -- that's Cobol's strength. They'll expect database to be
integrated, not an add-on. They'll expect a polished navigation in the
IDE -- more like Acrobat than a fancy text editor.

> What will a programming language need to fail in that world?
> Antequated concepts like binary and packed numbers, string
> handling that's incompatible with other languages, difficulty
> communicating with OO languages and libraries, flat files
> (they belong in a library, not a language).
Haven't you just stated why Cobol will fail in the next 5 years ?

Richard

2005-01-30, 8:55 pm

> In other words I should be able to code some thing like:

> move "MY-PROGRAM-ID" TO PROGRAM-ID-PARAGRAPH OF
standard-cobol-object.
> INVOKE STANDARD-COBOL-OBJECT "COMPILE".
> INVOKE STANDARD-COBOL-OBJECT "RUN".

No. You shouldn't need to do that at all. You should be able to just
have 'INVOKE my-program-id' and all that grubby stuff gets done for you
if necessary.

In fact just as Java JIT does now.

> It translates the code into some form of platform indepent

You mean like Java, UCSD, MicroFocus, Acu, RM and so on have been doing
for up to a quarter of a century ?

> that it can re-write in the local cobol dialect.

Just as MF Generate (.int to .gnt) has been doing for a couple of
decades ?

Donald Tees

2005-01-30, 8:55 pm

Richard wrote:
>
>
>
> standard-cobol-object.
>
>
>
> No. You shouldn't need to do that at all. You should be able to just
> have 'INVOKE my-program-id' and all that grubby stuff gets done for you
> if necessary.
>
> In fact just as Java JIT does now.
>
>
>
>
> You mean like Java, UCSD, MicroFocus, Acu, RM and so on have been doing
> for up to a quarter of a century ?
>
>
>
>
> Just as MF Generate (.int to .gnt) has been doing for a couple of
> decades ?
>

Somewhat, yes. Though it is doing it from one proprietary code set to
another rather than from generalized cobol to a machine specific cobol.

Donald

Robert Wagner

2005-01-30, 8:55 pm

On Sun, 30 Jan 2005 21:37:53 +0100, "R.Freitag" <rfr-mailbox@gmx.de>
wrote:

>Combine the jvm with COBOL and you are done.

PerCobol by LegacyJ produces code for the JVM. It's been available for
several years. Demand has been modest.

Micro Focus and Fujitsu offer compilers that produce code for the CVM
(.NET virtual machine). I don't know how many they've sold; nobody
here seems interested.

Richard

2005-01-30, 8:55 pm

> Somewhat, yes. Though it is doing it from one proprietary code set
to
> another rather than from generalized cobol to a machine specific
cobol.

What would you consider to be a 'non-proprietry code set' ?

What is 'generalized cobol' ? Is it source code ? or some form of
'byte code' ? Is it just like MF .int, or Acu's or RM's, except using
a different set of byte values ? Why not use Java's byte code scheme ?
or gcc's intermediate code (like GNU Cobol is/was intended to do).

What is 'machine specific cobol' ? If you mean 'machine instruction
code', then it is not Cobol.

Peter Lacey

2005-01-31, 3:55 am

Richard wrote:

>
>
> Sorry, but _you_ may find C++ and Java cryptic, but programmers do not,
> _they_ can understand Java and C++ at a glance.
>
> What is 'easy to understand at a glance' is entirely what one is used
> to. You are used to Cobol, others are used to C++, Java, Python, Perl,
> or whatever. Thus they find their language as easy as you do yours.
>

Sorry, I can't agree. C, C+, C++, and JAVA might well be deliberately
designed to be obscure. No doubt programmers that use such languages
will find them easier to FIGURE OUT than those of us that don't, but any
language that puts a priority on symbols instead of words and encourages
fantastically compacted code is going to be hard to understand. Why,
there is floating around on the 'net a declaration that C is a hoax!

PL

Richard

2005-01-31, 3:55 am

> but any language that puts a priority on symbols instead of words

Symbols are just as easy to understand as words - once you have learnt
the symbols.

> and encourages fantastically compacted code

Code may be more compact, but not 'fantastically' (which means 'like a
fantasy'). I am not sure what verbosity gains you if much of it is
superfluous and just noise words.

For example if you compare:

IF Order-Limit IS GREATER THAN Credit-Limit
THEN
PERFORM Process-Order-Over-Limit
END-IF

with

if ( Order-Limit > Credit-Limit )
Process-Order-Over-Limit();

then it _may_ be confusing if you can't tell instantly what '>' and '<'
mean. It _may_ be confusing if you don't know what limits the if
statement. These are things that are learnt.

To me the latter is more easily understood because I use that form is
_all_ the languages that I use.

OTOH some people can't tell their left from their right when driving
(my wife for one). A sign saying 'NO RIGHT TURN' is hard for them to
understand, an arrow to the right with a red diagonal is instantly
understood.

> is going to be hard to understand.

It is only a matter of getting used to it. I have no trouble at all
with Cobol, C, C++, Java, Python or Perl (well, OK, I do with Perl).

> Why, there is floating around on the 'net a declaration that C is a
hoax!

If it's on the Internet then it _must_ be true.

Actually I have seen that 'C is a hoax and Dennis Ritchie writes
everything in Pascal'.

Robert Wagner

2005-01-31, 3:55 am

On 30 Jan 2005 13:17:41 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>Only if you ignore everything else that happened. Being selective
>allows you to 'prove' any conclusion you started with.
>
>For example 1992 or so was a significant date as the release of the
>first usable version of Windows, yet it didn't fit in your '20 years'
>so you didn't mention it.

I don't regard pre-95 Windows as a milestone. At the time, I thought
it was disappointing, didn't use it and didn't observe many others
using it. Before 95, the only GUI I liked was MacIntosh, but it wasn't
widely used enough to pursue.

Both 20 year cycles had paradigm shifts mid-cycle, generally when the
operating system caught up with hardware. I regard Win-95 as one such
milestone. Another was the release of SCO XENIX 386 in 87.

MY 20 year cycles are based on hardware platform. The early years of a
cycle, when software is inadequate, present a unique opportunity to
programmers.

>programmable terminal,
>
>IBM designed the IBM PC to be a 'better Apple ][ PC' which was
>increasingly being found in corporate mainframe sites where it was used
>to run Visicalc and word processing.

The people who start a revolution usually have no vision of what they
launched. The corrollary is that systems hyped as revolutionary
usually languish. Examples are AS/400 and Apple.

The knockout programs that made the PC a must-have were Lotus 1-2-3
and WordPerfect.

>multiple CPUs, blazing speed and huge storage.
>
>Multi-CPU and 'blazing speed' maybe but 'XBox or Playstion' is not how
>I would put it. It does seem that 'XBox Next' will be Power based with
>IBM manufacturing the chips while PS/3 also uses IBM tecnology which
>may utilise Power designs.

The CELL chip will be made by IBM, Sony and Toshiba, who are each
spending billions on fab plants. They are not spending that much money
to build PS3s. The chip will be used in HDTVs, set-top boxes and
mainframes, at least.

The trick is to find applications that don't compete head-to-head with
the PC, because superior hardware isn't enough to beat it. Amiga had
hardware 15 years ahead of the PC when it lost. Enthusiasts, not big
companies, will turn this hardware into a PC replacement, just as they
are slowly making Linux a Windows replacement. As I said, programming
opportunities will abound for the next few years.

>Now we should see why IBM sold off, sorry 'partnered', the PC division.
>Apart from being a foothold in China it also dumps the contracts with
>Intel and MS leaving them free to come up with an in-house Power based
>machine running Linux that can be everything from a cheap diskless
>terminal (like LTSP) through desktops running Linux/workspace to
>clustered servers and supercomputer closely coupled machines.

Clustered servers and supercomputers are specialized, low volume
markets. China doesn't want that, it wants millions of low priced
plain-old PCs and low-end servers. It's agnostic about operating
systems; it will use Windows, Linux or OS X .. whatever works, has the
application base and doesn't get in the way with licensing. Apple has
a semi-decent application base. If they'd stop pushing overpriced
hardware to elitists, China could be their golden opportunity.

>IBM can make Power chips at a fraction of the price of buying in
>Pentiums. As the hardware price falls the software becomes the largest
>part of the cost. Linux/Workspace (based on OpenOffice.org) will be a
>fraction of the price of Windows/Office and will avoid all the TCO of
>having to maintain the crap that the BSA 'spanish inquisition' insists
>on.

Same idea as above. BSA is a vehicle to protect Microsoft's
comfortable monopoly. China has no incentive nor inclination to play
that game. It'll buy the best value for he yuan. Short-tern, that'll
be a no-name PC with a pirated copy of Windows.

>Microsoft is increasingly tied to having to maintain individual
>tracking of every licence and subscription and tying down every copy to
>combat piracy, especially in emerging markets. This makes it onerous on
>the users by way of the BSA, failed installs, having to repurchase if
>hardware is changed, DRM, so called 'Trusted Computing' (in which MS
>trusts none of their customers) and having to maintain 'subscriptions'.
>
>The new IBMs will make all that irrelevant, much to the customers'
>delight, and to MS's dismay.

Someone will dethrone MS. IBM isn't the first contender that comes to
my mind. I'd bet on an aggressive Asian company such as Samsung,
Fujitsu or NEC. IBM, who once had a monopoly in Japan, fell to fifth
place after Japanese companies offered competition. Why would they do
better in China?

Look what happened in the cellphone market. motorola once had a
monopoly. Then nokia went from nowhere to number one. Now Samsung is
about to take the lead. While this was going on, companies like
Siemens and Sony Ericsson were too comfortable in their elderhood to
compete.

In automobiles, Hyundai is moving from a joke five years ago to the
fifth largest in the world by 2010. It has already passed Nissan and
Mazda in some Asian markets.

>add-on.
>
>'TV-like' is very poor compared to computer monitors. If you mean
>'realistic animation' then yes, but that is not 'tv-like'.

That's what I meant.

Richard

2005-01-31, 3:55 am

> I don't regard pre-95 Windows as a milestone. At the time, I thought
> it was disappointing, didn't use it and didn't observe many others
> using it.

Then you were not watching the right trends. Win 3.11 with its WFW
networking was what made Windows take off in the corporates and
especially in the SMB market. Win95 didn't add much functionality,
just a different UI (which I disliked) and Win32 (while 3.11 has
Win32S) but there wasn't much software that needed it.

> Another was the release of SCO XENIX 386 in 87.

Xenix had been around since '79 or '80. Xenix 386 was just another 386
based Unix, I was using DRX SVR3.2 on 386 (and earlier DRX SVR2 on
286).

> MY 20 year cycles are based on hardware platform.

Your '20 year cycle' is based on selection to suit your preconceived
conclusion about 20 years.

The 1401 was just a development from unit record equipment which had
been progressing since the late 20s, as was the Univac 1004. LEO II
was a far more significant advance for business computing.

The XBox is just a PC with a locked down BIOS, it isn't a new platform
at all. XBox Next _might_ be a new platform, but that breaks your '20
year' theory.

> The corrollary is that systems hyped as revolutionary usually
languish.
> Examples are AS/400 and Apple.

In what way has the AS/400 'languished' ? Did it ever fail to meet its
sales targets ?

In what way has Apple 'languished' ? Are Apple factories laying idle ?

> The knockout programs that made the PC a must-have were Lotus 1-2-3
and WordPerfect.

Software then ? Lotus 1-2-3 was a continuation of Visicalc on Apple ][
and Commodore, that 'generation' started in 1979. Pity it doesn't fit
your '20 year' theory.

> The trick is to find applications that don't compete head-to-head
with
> the PC, because superior hardware isn't enough to beat it.

You don't need superior hardware to beat the PC, you need cheaper
hardware that dumps the baggage of legacy hardware and compromised
design that has survived since 1982.

Intel CPUs still have to run in 8086 mode plus everything else up to
AMD's 64 bitedness. A new design PowerPC does not need that baggage.

> Amiga had hardware 15 years ahead of the PC when it lost.

A couple of years maybe. But the Amiga was too much a games box and
all the extra hardware was only of use to games. It made it too
expensive to use as a business machine.

> Enthusiasts, not big companies, will turn this hardware into a PC
replacement, just as they
> are slowly making Linux a Windows replacement.

Exactly. Which is why IBM will make new shiney toys for the
enthusiasts to build their systems on. Linux already runs on PowerPC
so it won't be hard to fully load a new cheap range of business boxes
that share some hardware with the new games boxes, and thus have huge
volumes to cut costs.

Apple will benefit too as they use PowerPC.

Donald Tees

2005-01-31, 3:55 pm

Richard wrote:
>
> to
>
>
> cobol.
>
> What would you consider to be a 'non-proprietry code set' ?
>
> What is 'generalized cobol' ? Is it source code ? or some form of
> 'byte code' ? Is it just like MF .int, or Acu's or RM's, except using
> a different set of byte values ? Why not use Java's byte code scheme ?
> or gcc's intermediate code (like GNU Cobol is/was intended to do).
>
> What is 'machine specific cobol' ? If you mean 'machine instruction
> code', then it is not Cobol.
>

I mean Cobol ...

Donald

Robert Wagner

2005-01-31, 3:55 pm

On 30 Jan 2005 21:50:56 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>Then you were not watching the right trends. Win 3.11 with its WFW
>networking was what made Windows take off in the corporates and
>especially in the SMB market. Win95 didn't add much functionality,
>just a different UI (which I disliked) and Win32 (while 3.11 has
>Win32S) but there wasn't much software that needed it.

One didn't need Win3 to run NetBUEI , DOS ran it fine with LANMAN.

Win3 ran on top of DOS and didn't feel like a real operating system.
Win95 was a true 32-bit operating system. Its multiple DOS boxes were
'a better DOS than DOS'. They gave DOS programs access to 32-bit
drivers and gave them with disk cacheing better than anything on DOS.

>The XBox is just a PC with a locked down BIOS, it isn't a new platform
>at all. XBox Next _might_ be a new platform, but that breaks your '20
>year' theory.

Hmmm. Perhaps PS3 is the new platform.

>
>In what way has the AS/400 'languished' ? Did it ever fail to meet its
>sales targets ?

I don't know about targets but I know the system is mediocre. Its
database feels very 80s, is lacking compared to modern databases. It's
supposed to be single level store but, on the surface, looks like
every other file system. Disaster recovery (fancy term for abend) is
like an IBM mainframe. Worse, actually, because there isn't
third-party software like Abend-AID.

>In what way has Apple 'languished' ? Are Apple factories laying idle ?

Mac has two percent of market share, and falling.

US factories for all brands are idle, because manufacturing moved to
Asia.

>with
>
>You don't need superior hardware to beat the PC, you need cheaper
>hardware that dumps the baggage of legacy hardware and compromised
>design that has survived since 1982.
>
>Intel CPUs still have to run in 8086 mode plus everything else up to
>AMD's 64 bitedness. A new design PowerPC does not need that baggage.

But, but .. WHAT ABOUT MY DOS PROGRAMS? Waaaa.

>replacement, just as they
>
>Exactly. Which is why IBM will make new shiney toys for the
>enthusiasts to build their systems on. Linux already runs on PowerPC
>so it won't be hard to fully load a new cheap range of business boxes
>that share some hardware with the new games boxes, and thus have huge
>volumes to cut costs.
>
>Apple will benefit too as they use PowerPC.

Using the parallelism in the CELL chip will require big changes in
compilers in the short term, application architecture in the long
term. The machine's not designed for emulation nor backward
compatibility. For instance, it doesn't have multi-level caches nor
microcode. It can act like a Power, or even an Intel, but doing so
wastes >90% of its speed. Each cell has 16 ALUs (not to be

with FPUs). Running it the old way would use only one of them.

Chuck Stevens

2005-01-31, 3:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:54knv0lvfe8rllm1d38l0emi7js429t4jj@
4ax.com...

> Whoops, I stand corrected. I thought it had to be a GOOD reason
> because the Standard says "are dependent on the functionality of the
> processor" and "dependent upon a terminal device capable of supporting
> them". A desktop PC is certainly capable, and variations of DISPLAY ..
> AT seem to be in common use in some cultures, notably AcuCobol.

More important than the text I believe you're referring to (ISO/IEC
1989:2002 page 696, B.3, Processor-dependent language element list) is the
citation at which "processor-dependent" is defined, namely, on Page 4,
3.1.5, Processor-dependent language elements. The last sentence of the
first of three paragraphs in that section says "The decision of whether to
claim support for a processor-dependent language element is within an
implementor's discretion. Factors that may be considered include, but are
not limited to, hardware capability, software capability, and marketing
positioning of the processor."

And "variations of DISPLAY ... AT" do not a standards-compliant, or even a
platform-independent, compiler make.

> If the compiler has a GUI tool, Screen Section does seem superfluous.

If the compiler has a GUI tool, that tool is almost certainly outside the
realm of standards compliance or portability. The presence of such tools is
one of the reasons the "green-screen" Screen Section was made processor
dependent. It was arguably OK when it was written, but by the time the
standard came out the green-screen interface was decidedly old-fashioned.
I don't know of any implementation offhand that provides a fully-compliant
implementation of the Screen Section without a whole lot of extensions that
make the "standards-compliant" part pretty much irrelevant in that
implementation.

-Chuck Stevens

Chuck Stevens

2005-01-31, 3:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:rsbmv0tcb2sqksil7orhlv28q7pu0hg41i@
4ax.com...
> On Fri, 28 Jan 2005 12:01:17 -0800, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
once -[color=darkred]
lines[color=darkred]
compiler[color=darkred]
compiler[color=darkred]
>
> According to Marc Sokol, who wrote it, more than half those 800K lines
> were the file system. After deducting tools (realcopy) and runtime,
> the compiler core was probably less than 300K lines.

And about 53k of the 133k lines in the aforementioned COBOL74 compiler is
actually devoted to *parsing*. About 64k is devoted to the general task of
converting the fixed-encoding "macros" built by the parser into
directly-executable machine language. The remainder consists of data and
processes common to both parts of the compilation process. There is no
"runtime" built or managed by that compiler; there is no linkage phase
unless the user is explicitly building code for binding with other code
files.

What's your point?

-Chuck Stevens

Robert Wagner

2005-01-31, 3:55 pm

On Mon, 31 Jan 2005 08:33:01 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:rsbmv0tcb2sqksil7orhlv28q7pu0hg41i@
4ax.com...

>
>And about 53k of the 133k lines in the aforementioned COBOL74 compiler is
>actually devoted to *parsing*.
>
>What's your point?

Trying to form a rough-cut estimate of development time. Using 500
lines/day, the estimate is two man-years for parser and code
generator.

Richard

2005-01-31, 3:55 pm

> One didn't need Win3 to run NetBUEI , DOS ran it fine with LANMAN.

LANMAN was a server based system which required additional client
software that reduced DOS memory space.

WFW 3.11 was peer-to-peer (or to server) and didn't require a dedicated
machine, and din't need additional software.

> Win3 ran on top of DOS and didn't feel like a real operating system.
> Win95 was a true 32-bit operating system.

No. Wrong. Win95 ran on to of MS-DOS 7 in exactly the same way as
Win3.x did, they just hid it better to fool the gullible. It was only
necessary to change the BootGUI=Y to boot to DOS 7 and the 'Win' would
start the GUI shell. Exiting could be done back to the DOS just like
Win3.x. It was easily shown that Win95 (and 98/ME) still relied on the
underlying DOS.

NT and its derivitives were not based on DOS, 95/98/ME were.

> Its multiple DOS boxes were 'a better DOS than DOS'.

They were no better than Win3.1's multiple DOS boxes on a 386.

> They gave DOS programs access to 32-bit drivers and

Programs don't access drivers, the OS does.

> gave them with disk cacheing better than anything on DOS.

Granted that MS-DOS 5 and 6.x had poor disk caches but Win3.11 added
its own disk cache to DOS that was almost as good as DR-DOS's and Win95
did not improve much on that.

> Using the parallelism in the CELL chip will require big changes

I doubt that an IBM business machine would use the CELL chip as the
main CPU, it is more likely to use a multi-core PowerPC.

> parallelism ... application architecture in the long term.
Java already does this, automatically.

Richard

2005-01-31, 3:55 pm

> As I remember it kept complaining something about not having an
active module.

You need to indicate that it is a 'main module' with the -M flag on the
cob2c command.

Using the kobol project window the program should be set to 'Set Main
file (for main() C)'.

> Cobol to gcc version 1.2.0 (cobol 20020808164102)
>
> Warning: no input files specified!
> Usage: cob2c [options] inputfiles...
> Options:
> -3 parse Cobol 3000
> -enn abort after nn errors
> -i generate code to move spaces to uninitialised data.
> -I <directory>
> (Specify include directories for the parser)
> -D <directory>
> (Specify output directory for the generator)
> -L (List input lines)
> -M (Generate main program)
> -N (suppress code generation)
> -R (generate non-static working storage)
> -RM (generate non-static working storage for main programs)
> -S (report statistics such as CPU time)
> -Vi (Verbosity level i)
> -W (give all warnings)

Chuck Stevens

2005-01-31, 8:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:suusv0hhoipoj4vjurd9grd0iepr6b2m68@
4ax.com...
> On Mon, 31 Jan 2005 08:33:01 -0800, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
>
> Trying to form a rough-cut estimate of development time. Using 500
> lines/day, the estimate is two man-years for parser and code
> generator.

Apples and oranges, both in terms of finished product and of design
criteria.

The question was whether 800,000 lines of COBOL code for a finished COBOL
compiler was unreasonably high. I don't think it is.

Are you saying you could *reduce* the Unisys MCP COBOL74 compiler from
133,000 lines to 125,000 lines by *rewriting it from NEWP to COBOL*? I
don't theenk so ...

And if you're trying to estimate what it would cost to code such a compiler
in COBOL based on how many lines of NEWP it currently takes, again, that's
not a valid comparison.

Part of the cost of *developing* a COBOL compiler for an *arbitrary*
platform is deciding what the object code sequences for every single
construct needed to be; deciding on best-guess object code sequence for
efficiency on just about any given platform for all of the flavors of
INSPECT, STRING and UNSTRING could itself occupy a man-year or more. I
strongly suspect that 500 lines of code per day does not include those
underlying design decisions. You may have the parsing rules predefined by
the standard, but the point of a compiler (at least in our environment) is
to generate the best possible object code for the construct, and that often
takes more than a few minutes thought.

-Chuck Stevens

Joe Zitzelberger

2005-02-01, 3:56 am

In article <ctm1gv$1g0o$1@si05.rsvl.unisys.com>,
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

> Part of the cost of *developing* a COBOL compiler for an *arbitrary*
> platform is deciding what the object code sequences for every single
> construct needed to be; deciding on best-guess object code sequence for
> efficiency on just about any given platform for all of the flavors of
> INSPECT, STRING and UNSTRING could itself occupy a man-year or more. I
> strongly suspect that 500 lines of code per day does not include those
> underlying design decisions. You may have the parsing rules predefined by
> the standard, but the point of a compiler (at least in our environment) is
> to generate the best possible object code for the construct, and that often
> takes more than a few minutes thought.
>
> -Chuck Stevens

This could be mitigated by generating RTL from the Cobol compiler and
leveraging the 30-odd back end targets in gcc.

Robert Wagner

2005-02-01, 3:56 am

On Mon, 31 Jan 2005 11:40:09 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:suusv0hhoipoj4vjurd9grd0iepr6b2m68@
4ax.com...

>Part of the cost of *developing* a COBOL compiler for an *arbitrary*
>platform is deciding what the object code sequences for every single
>construct needed to be; deciding on best-guess object code sequence for
>efficiency on just about any given platform for all of the flavors of
>INSPECT, STRING and UNSTRING could itself occupy a man-year or more. I
>strongly suspect that 500 lines of code per day does not include those
>underlying design decisions. You may have the parsing rules predefined by
>the standard, but the point of a compiler (at least in our environment) is
>to generate the best possible object code for the construct, and that often
>takes more than a few minutes thought.

My 500 lines/day is an average between heads-down coding at 1000
lines/day and experimentation with the code set, testing, etc.

Robert Wagner

2005-02-01, 3:56 am

On 31 Jan 2005 10:46:13 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>No. Wrong. Win95 ran on to of MS-DOS 7 in exactly the same way as
>Win3.x did, they just hid it better to fool the gullible. It was only
>necessary to change the BootGUI=Y to boot to DOS 7 and the 'Win' would
>start the GUI shell. Exiting could be done back to the DOS just like
>Win3.x. It was easily shown that Win95 (and 98/ME) still relied on the
>underlying DOS.

Very wrong. Claiming that 'Win9x really runs over/under DOS' is a
favorite of net-kooks. Hopefully this Web site will set you straight.

http://users.iafrica.com/c/cq/cquirke/whatdos.htm

Note the comment about a DOS window "Strictly speaking, this isn't DOS
at all". Only Safe Mode and BootGUI=0 gave a real DOS.

As an OS guy, I could feel that Win95 was NOT running over/under DOS.

>NT and its derivitives were not based on DOS, 95/98/ME were.

Nonsense. Win95 was a virtual-mode, 32-bit operating system.

Richard

2005-02-01, 3:56 am

> Very wrong. Claiming that 'Win9x really runs over/under DOS' is a
> favorite of net-kooks. Hopefully this Web site will set you straight.

Well I have a old Win95 box right here and I boot it to MS-DOS 7 with
BootGUI=0 then later load the GUI shell using Win. It works just as
Win3.11 did but does add more drivers that replace DOS functions with
extended bit, but DOS is still there underlying the GUI.

MS certainly spent a large effort on hiding the underlying DOS and
claiming in marketing blub that it was gone, but then MS marketing is
not to be trusted at all, even more so than you.

> http://users.iafrica.com/c/cq/cquirke/whatdos.htm

> Note the comment about a DOS window "Strictly speaking, this isn't
DOS
> at all". Only Safe Mode and BootGUI=0 gave a real DOS.

http://www.mdgx.com/msdos.htm

"""After all Windows 95/98/ME is a MIXED (read "partially enabled")
32-bit AND 16-bit [for backward compatibility with MS-DOS (DOS16 and
DOS32) and older 16-bit Windows/WfWG 3.xx (Win16) programs] Graphical
User Interface (GUI) protected mode virtual environment [... sorry,
Operating System :)], which still depends on the good ol' MS-DOS 7.xx
TSR modules (IO.SYS + COMMAND.COM), MS-DOS mode memory manager
(HIMEM.SYS) and compatibility (legacy) drivers (IFSHLP.SYS) to load on
top of the plain DOS command line based layer!"""

BootGUI=0 gives MS-DOS 7 which is not much different from MS-DOS 6.x
and will run Win3.11. That is how my Win95 box starts. Just like
Win3.11 I can exit the GUI back to MS-DOS 7 (and not 'safe mode' or
'dos mode' but actual exit from Win). MS tried to hide it with splash
screens which fooled the gullible.

> As an OS guy, I could feel that Win95 was NOT running over/under DOS.

So your 'evidence' is just a 'feeling' based on your claim to 'be an OS
guy'. While my evidence is actually grubbing around inside it.

Just one item is that Windows 95 relies on the underlying MS-DOS for
creating the PSPs for each program. Tracking the actual memory layout
shows that the MS-DOS is still there after 'Win' has loaded the Win95
GUI (just like Win3.11) and that this is actively involved in creating
and maintaining the PSPs.

[color=darkred]
> Nonsense. Win95 was a virtual-mode, 32-bit operating system.

Believe all the MS marketing hype that you like, Win95 still had much
16 bit stuff in in and underlying it is a real MS-DOS 7.

jce

2005-02-01, 3:56 am

"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:41FD88BD.F0B9FD8E@mb.sympatico.ca...
> Richard wrote:
>
>
> Sorry, I can't agree. C, C+, C++, and JAVA might well be deliberately
> designed to be obscure. No doubt programmers that use such languages
> will find them easier to FIGURE OUT than those of us that don't, but any
> language that puts a priority on symbols instead of words and encourages
> fantastically compacted code is going to be hard to understand. Why,
> there is floating around on the 'net a declaration that C is a hoax!
>
> PL

Also remember that not everyone speaks English anyway so an "ENGLISH LIKE"
language makes no difference to someone who has a first language of Chinese.
Things like IS GREATER THAN may not be at all obvious.....

Java has 52 reserved words and about 50 operators (many are combinations
such as x*=y which could be written as x=x*y)
C++ has about 48 reserved words and similar number of operators
C has less reserved words than C++

COBOL has over 300 reserved words.

COBOL also demands correct position in positions A/B and requires program
structure that gives no real programming benefit.

The lack of understanding a C/Java/C++ program is mostly dependent on the
practitioner using accurate nomenclature for the libraries that are written.
Some features of Java are obviously going to require more knowledge - you
can't just pick up an enterprise application written in Java and understand
it even though it is the sum of very small parts.

I laugh when people tell me they know Java....it's not much more complicated
than learning an alphabet and the first 10 times tables...this is 3rd Grade
stuff. Some people never get to read anything more exciting than Harry
Potter, if you move on to richer texts you may find you need a dictionary.
It's the same thing: 26 letters can make incredibly rich and complex texts,
52 reserved words can do the same - it's all in how they are put together.
I am almost positive that someone could write a chat server in Java and you
could pick up the code and understand it.

Similarly, people think that spoken Chinese is more complicated than
panish - I know neither but from speaking to some people I know, it's
apparent that the Masculine/Feminine and verb conjugations cause a lot of
problems for Chinese speakers where these concepts don't exist.

JCE

William M. Klein

2005-02-01, 3:55 pm

"jce" <defaultuser@hotmail.com> wrote in message
news:ryFLd.13655$JO2.4436@tornado.tampabay.rr.com...
>
> "Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
> news:41FD88BD.F0B9FD8E@mb.sympatico.ca...
<snip>[color=darkred]
>
> COBOL also demands correct position in positions A/B and requires program
> structure that gives no real programming benefit.
>

Just so you know (and not commenting on your other "arguments")

The '02 ANSI/ISO Standard removes the entire A/B margin concept.

Many (possibly most - certainly NOT all) '85 Standard compilers have also
removed this distinction -as an extension to this older Standard.

P.S. In several recent SHARE (IBM mainframe user group) meetings, this removal
was viewed as one of the more NEGATIVE changes in the '02 Standard. However, my
perception is that this is based on existing (IBM mainframe) text editors,
debugging tools, and "what they are used to" - rather than any "real"
need/desire for retaining the distinction (wich can be used but is not required
in the '02 Standard).

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