R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed

robert.deletethis@wagner.net (Robert Wagner) wrote
 
>
> There is truth in this statement. You don't offer many better ideas.

Which is strange because you claimed that you adopted some of my
ideas.

> I dislike GLOBAL because it is variant of EXTERNAL and 'blank common'. It'
s a
> mechanism to defeat 'data hiding' by passing data by stealth rather than
> explicitly.

Now I can't make out whether you would "pass 17 parameters" or would
leave the data items in WS where your ENTRYs can access everything
without any explicit permission.  You seem to dislike both, yet ENTRY
is what you want to do.

> The ENTRY header lists the linkage section variables being passed. The
> compiler _could_ diagnose errors.

But doesn't.  STICKY-LINKAGE will keep some linkage items valid from
parent routines, but then the programmer will have to keep track of
what is and is not, it may depend on what made the call - assuming
that you allow reuse of routines.

> Local-Storage is setup complete for each instance,
> therefore all references are valid.

But won't have any valid data as it will be clear on entry to the
routine.  If data needs to be used other than by parameter it would
have to be in WS, and thus implicitly GLOBAL.  Or would you pass 17
parameters ?

> Your argument and counter-example are based on a 'cooperative' (i.e. not
> preemptive) operating system that was obsolete ten years ago. This is
> irrelevant
> in a discussion about contemporary operating systems, where multitasking i
s
> the norm.

My example was about call-backs.  Call-backs are a fundemental part of
all Windows programs.  It is Call-backs that require re-entrancy,
regardless of whether it is co-operative or pre-emptive.

You seem to forget that each program is a single-task.  Multi-tasking
is the mechanism that allows several separate tasks to run, ie several
programs.  Co-operative or pre-emptive describes the mechanism that
operates _between_ tasks and has no effect on how a single task works.

My counter example is not based on 'cooperative' it is how Windows
programs work with call-backs.  ie when it was recompiled as a Win9x
program it still worked exactly the same way.

In spite of you claim about what re-entrancy is for, it is actually
for re-entrancy whether this be indirect recursion or by call-backs.

> My client has many 'external procedures'

They aren't 'existing programs' they are 'existing database
procedures'.

> The challenge is to make existing Cobol procedures thread-safe.
 

> Suppose the program needs to do process A, B and C. A traditional Cobol pr
ogram
> would say:
> perform A
> perform B
> perform C
> Execution time would be the sum of A+B+C.

> A multithreaded program would say:
> start A
> start B
> start C
> wait for A and B and C
> Execution time would be the longest of the three.

A 'traditional program' would open the file in A, close it in C, and
read until eof in B.  I would bet that the close of the file would be
the fastest part.

It was your claim that "_EVERY_ paragraph" must be changed to
something else.  Does your A have all its PERFORMs changed into 'start
A2' etc ?  Are we going to wind up with 100 threads running, each
using data items that haven't been created yet ?

But you didn't seem to connect my reference to 'timeslicing'.
Execution time is still the CPU time for A+B+C on single CPU systems.

While there may be situation where multi-threading is useful, this is
probably not at the sub-program level.  Your example is most likely
just silly.  Where multithreading will be useful is for web-serving,
for example, where each message starts it own thread to pass through
the suite of several cobol programs independently. Each program still
perform paragraphs, and/or calls programs and/or invokes classes as
required.

In other words we don't want a single 'traditional' program to
fragment into dozens of threads because the operation requires
sequencing to be maintained.  We may want one complete sequence of
processing to be done end to end while another thread also runs
through the same programs.

And perhaps you can explain why you think that _EVERY_ pargraph must
be changed to something else.

riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
 
>
>Now I can't make out whether you would "pass 17 parameters" or would
>leave the data items in WS where your ENTRYs can access everything
>without any explicit permission.  You seem to dislike both, yet ENTRY
>is what you want to do.

Doing MAINTENANCE on a monolithic program, I prefer implicitly global
Working-Storage, with paragraphs converted to ENTRY.

When designing NEW programs, I prefer better data structures passed as
parameters (no more than 4) to called programs, either nested or external.
 
>
>My example was about call-backs.  Call-backs are a fundemental part of
>all Windows programs.  It is Call-backs that require re-entrancy,
>regardless of whether it is co-operative or pre-emptive.

Correct so far ...

>You seem to forget that each program is a single-task.

Not really. With multithreading, a program is technically a single task but 
each
thread functions as another task.

>My counter example is not based on 'cooperative' it is how Windows
>programs work with call-backs.  ie when it was recompiled as a Win9x
>program it still worked exactly the same way.

No it didn't. That was an illusion. As an example, consider the familiar
long-running search in the background with an active Cancel button on the
screen. Under Win3, you had two cooperative 'threads of execution'. Under Wi
n32
et seq you have two actual Threads running independently. If the machine has
more than one processor, they're probably running on separate CPUs. The UI
thread (probably in 'main') is listening for a Click, as before. The worker
thread is no longer required to periodically issue Yield (but can if it want
s
to). It listens for a Quit message from the UI thread, as before.

The difference is in writes to shared memory -- Working-Storage. Under Win3,
both could write without a problem. Under Win32's multithreading, they canno
t
both write to the same variable unless they take extra steps to lock it befo
re
writing. If they don't, there is a very real chance both will write within t
he
same nanosecond, causing unpredictable results. Say a word contains zero and
both add 1. There is a 50% chance the answer will be 1 and 50% it will be 2.

When there is one processor, its inherant serialization acts as a de-facto
'lock'. As a result, developers working on a single processor machine tend t
o
become sloppy. Programs work fine on the development machine, but produce
intermittent wrong answers on a user's multi-processor (or hyperthreading)
machine.
 
>
>They aren't 'existing programs' they are 'existing database
>procedures'.

Whatever. They are ordinary callable Cobol programs which work ok in the cur
rent
single-threaded environment. If they were used in the multithreaded Oracle
External Procedure environment, they'd occasionally produce wrong answers or
abends.
 
program 
> 
>
>It was your claim that "_EVERY_ paragraph" must be changed to
>something else.  Does your A have all its PERFORMs changed into 'start
>A2' etc ?  Are we going to wind up with 100 threads running, each
>using data items that haven't been created yet ?

It's not NECESSARY to change all paragraph names. We COULD have:

start "A"
..
. end-paragraph

. entry "A".
perform A2
goback
. A2.
..
. end-paragraph

. entry "B"

This would be necessary in order for A2 to access A's Local-Storage. If A ha
d
CALLed (not started) A2, the compiler would have created a new Local-Storage
 for
A2.

But it's ugly and irregular. I'd rather have one calling mechanism than two,
 and
PERFORM isn't going to be it.

>But you didn't seem to connect my reference to 'timeslicing'.
>Execution time is still the CPU time for A+B+C on single CPU systems.

Haven't you heard? Multiple CPUs are all the rage. Companies such as Intel a
re
even putting two of them on one chip. They call it HyperThreading. You reall
y
should get out more.

>While there may be situation where multi-threading is useful, this is
>probably not at the sub-program level.  Your example is most likely
>just silly.

Stay tuned for a demo that achieves dramatic performance improvement at the
sub-program level. When run on a machine with twice as many processors, it r
uns
almost twice as fast. That's called scalability, which is a hot topic among
airline magazine cognosenti (your clients and bosses).

>Where multithreading will be useful is for web-serving,
>for example, where each message starts it own thread to pass through
>the suite of several cobol programs independently. Each program still
>perform paragraphs, and/or calls programs and/or invokes classes as
>required.

If the paragraphs it performs are not dependent on each other, for example
database queries, they should run in parallel. You cannot do that with Cobol
's
PERFORM, which is chained to altar of Von Niemann.

>In other words we don't want a single 'traditional' program to
>fragment into dozens of threads because the operation requires
>sequencing to be maintained.  We may want one complete sequence of
>processing to be done end to end while another thread also runs
>through the same programs.

Speak for yourself. I WANT them to fragment when the operation doesn't "requ
ire
sequencing to be maintained." Many or most operations don't.

Hardware engineers are running out of ideas, and fast approaching the physic
al
speed limit of a ten angstrom trace. They want us software types to help the
m by
moving beyond Von Niemann thinking, where we've been stuck for 40 years.

We tried AI, which failed. We tried OO, with some success. We tried others t
hat
didn't work. Let's now try multithreading, which is low-level enough that it
might possibly work.

Under OO, every object could theoretically live in its own CPU. hardware is 
not
here yet, nor moving in that direction.

>And perhaps you can explain why you think that _EVERY_ pargraph must
>be changed to something else.

Pay no attention to the man behind the curtain. The hero here is the dog, wh
o
represents everyman. The dog pulled the curtain aside to expose the fraud.

robert.deletethis@wagner.net (Robert Wagner) wrote

> Doing MAINTENANCE on a monolithic program, I prefer implicitly global
> Working-Storage, with paragraphs converted to ENTRY.

Do thay actually allow you to reengineer code like this ?  How do you
deal with sections ?  thru ? goto -exit ?  What parameters do you
pass, if not why bother changing to CALL. Don't you just wind up with
momolithic programs that are now completely untested and are in a
style that is unproven ?

Or is it that you have never actually done this yet and it is just one
of your unproven 'ideas' ?

> When designing NEW programs, I prefer better data structures passed as
> parameters (no more than 4) to called programs, either nested or external.

"What Pascal did in the 80s" it is then.

> Correct so far ...

Well at least you now agree instead of tell me I was wrong.
 
>
> Not really. With multithreading, a program is technically a single task bu
t each
> thread functions as another task.

But program do not need to be multithreaded.

> No it didn't. That was an illusion. As an example, consider the familiar
> long-running search in the background with an active Cancel button on the
> screen. Under Win3, you had two cooperative 'threads of execution'.

No. Wrong.  There is only one thread.  The program 'co-operates' (ie
'co' 'operates') with _one_ thread in the whole Win3 system, shared
between all Windows programs.  The long running search does a 'yield'
(actually a messagep) which transfers the thread back to the
despatcher which handles messages and then passes the _one_ thread
back to the search.

> Under Win32
> et seq you have two actual Threads running independently.

No. Wrong.  There is only one thread in each program (and one in all
Win3 programs together) unless the program specific starts another
thread itself.  The difference is that each Win32 program has it own
one thread.

> If the machine has
> more than one processor, they're probably running on separate CPUs. The UI
> thread (probably in 'main') is listening for a Click, as before. The worke
r
> thread is no longer required to periodically issue Yield (but can if it wa
nts
> to). It listens for a Quit message from the UI thread, as before.

Geez, Robert, it almost sounds like you have actually written a
Windows program using the API.  Have you ? was it in Cobol ?

> The difference is in writes to shared memory -- Working-Storage. Under Win
3,
> both could write without a problem. Under Win32's multithreading, they can
not
> both write to the same variable unless they take extra steps to lock it be
fore
> writing. If they don't, there is a very real chance both will write within
 the
> same nanosecond, causing unpredictable results. Say a word contains zero a
nd
> both add 1. There is a 50% chance the answer will be 1 and 50% it will be 2.[/colo
r]

That is of course true, but _only_ if the program has specifically
increased its number of threads by _explicitly_ doing so.

> When there is one processor, its inherant serialization acts as a de-facto
> 'lock'. As a result, developers working on a single processor machine tend
 to
> become sloppy. Programs work fine on the development machine, but produce
> intermittent wrong answers on a user's multi-processor (or hyperthreading)
> machine.

Only if the program has _explicitly_ invoked multi-threading and then
doesn't bother to handle the consequences.  And it makes no difference
whether it is one or two CPUs.  Pre-emptive is pre-emptive.

> It's not NECESSARY to change all paragraph names. We COULD have:

So you agree that you were wrong with:
 

> This would be necessary in order for A2 to access A's Local-Storage. If A 
had
> CALLed (not started) A2, the compiler would have created a new Local-Stora
ge
> for A2.

Exactly.  You do see how your wholesale changing of existing programs
simply won't work.

> But it's ugly and irregular. I'd rather have one calling mechanism than tw
o,
> and PERFORM isn't going to be it.

That's OK, as I said, you would probably be happier working in a
completely different language.

> Haven't you heard? Multiple CPUs are all the rage. Companies such as Intel
 are
> even putting two of them on one chip. They call it HyperThreading. You rea
lly
> should get out more.

You may also have vaguely heard about mult-tasking where several
programs run on one machine.  A box with 4 processors can run 4
edifferent programs at the same time.  You seem to have sucha na
attachment to _your_ program that you think all resources should be
dedicated to it regardless of other needs.

Now there _are_ sensible uses for multi-threading, such as web servers
where a new thread can be started for each message so that I/O in one
won't block the processing of the next message.  But this is handled
at a higher level so that CALLed programs don't have to worry about
this.

In fact it can work much like separate tasks with shared code
segments.

> Stay tuned for a demo that achieves dramatic performance improvement at th
e
> sub-program level. When run on a machine with twice as many processors, it
 runs
> almost twice as fast. That's called scalability, which is a hot topic amon
g
> airline magazine cognosenti (your clients and bosses).

Ooooh, really impressive.  of course it slows down every other program
running on the same machine by stealing CPU.  But if you are used to
running single batch streams on a mainframe then you may think that it
is required.

> If the paragraphs it performs are not dependent on each other, for example
> database queries, they should run in parallel. You cannot do that with Cob
ol's
> PERFORM, which is chained to altar of Von Niemann.

You completely fail to notice that in a run-unit of several to several
dozen programs each thread will do its own CALL of the programs and
there is no need for each CALLed program to split itself into its own
multiple threads.

Write your programs as sequences that _are_ sequentially dependant,
and mostly they are, and put the multi-threading (or multi-tasking) at
a higher level.

You came up with a silly idea of misusing ENTRY because you hate THRU
and are now attempting to show how it _must_ be used.  Pargraphs
_must_ be eliminated in your desire for recognition as some sort of
super-programmer.

 
>
> Speak for yourself. I WANT them to fragment when the operation doesn't
> "require > sequencing to be maintained." Many or most operations don't.

Can you quantify that. Can you show some actual single existing
program in use within a system where 'sequencing is _not_ required to
be maintained' ?

(where single indicates a separately compiled cobol program).

> hardware engineers are running out of ideas, and fast approaching the phys
ical
> speed limit of a ten angstrom trace. They want us software types to help t
hem
> by moving beyond Von Niemann thinking, where we've been stuck for 40 years.[/color
]

Actually hardware engineers are _not_ running out of ideas.

> We tried AI, which failed.

I note the use of first person, I am sure you meant 'they'.

> We tried OO, with some success.

I note the use of first person, surely you mean 'they', have you
actually tried OO ?

> We tried others that didn't work.

Possibly even using ENTRY instead of PERFORM, but that doesn't work.

> Let's now try multithreading, which is low-level enough that it
> might possibly work.

I suggest that you may be happier working in some other language. Have
you tried Java where multithreading is automatic and can be almost
invisible ?

You want to convert existing program to 'what C did in the 70s' or
'what Pascal did in the 80s'.  Now you want to bang in low-level
multithreading.

Why not at least try to update to 'what Java did in the 90s' and use
OO Cobol if  multithreading is actually what you want to achieve.

> Under OO, every object could theoretically live in its own CPU. hardware i
s
> not here yet, nor moving in that direction.

Have you not heard of Beowulf clusters (and many other clustering
systems) ?

 
>
> Pay no attention to the man behind the curtain. The hero here is the dog, 
who
> represents everyman. The dog pulled the curtain aside to expose the fraud.

You seem to have an obsession with dogs, too.

Richard wrote:
> robert.deletethis@wagner.net (Robert Wagner) wrote
>
> 
>
>
> Do thay actually allow you to reengineer code like this ?  How do you
> deal with sections ?  thru ? goto -exit ?  What parameters do you
> pass, if not why bother changing to CALL. Don't you just wind up with
> momolithic programs that are now completely untested and are in a
> style that is unproven ?
>
> Or is it that you have never actually done this yet and it is just one
> of your unproven 'ideas' ?
>
> 
>
>
> "What Pascal did in the 80s" it is then.
>
> 
>
>
> Well at least you now agree instead of tell me I was wrong.
>
> 
>
>
> But program do not need to be multithreaded.
>
> 
>
>
> No. Wrong.  There is only one thread.  The program 'co-operates' (ie
> 'co' 'operates') with _one_ thread in the whole Win3 system, shared
> between all Windows programs.  The long running search does a 'yield'
> (actually a messagep) which transfers the thread back to the
> despatcher which handles messages and then passes the _one_ thread
> back to the search.
>
> 
>
>
> No. Wrong.  There is only one thread in each program (and one in all
> Win3 programs together) unless the program specific starts another
> thread itself.  The difference is that each Win32 program has it own
> one thread.
>
> 
>
>
> Geez, Robert, it almost sounds like you have actually written a
> Windows program using the API.  Have you ? was it in Cobol ?
>
> 
>
>
> That is of course true, but _only_ if the program has specifically
> increased its number of threads by _explicitly_ doing so.
>
> 
>
>
> Only if the program has _explicitly_ invoked multi-threading and then
> doesn't bother to handle the consequences.  And it makes no difference
> whether it is one or two CPUs.  Pre-emptive is pre-emptive.
>
> 
>
>
> So you agree that you were wrong with:
>
> 
>
> 
>
>
> Exactly.  You do see how your wholesale changing of existing programs
> simply won't work.
>
> 
>
>
> That's OK, as I said, you would probably be happier working in a
> completely different language.
>
> 
>
>
> You may also have vaguely heard about mult-tasking where several
> programs run on one machine.  A box with 4 processors can run 4
> edifferent programs at the same time.  You seem to have sucha na
> attachment to _your_ program that you think all resources should be
> dedicated to it regardless of other needs.
>
> Now there _are_ sensible uses for multi-threading, such as web servers
> where a new thread can be started for each message so that I/O in one
> won't block the processing of the next message.  But this is handled
> at a higher level so that CALLed programs don't have to worry about
> this.
>
> In fact it can work much like separate tasks with shared code
> segments.
>
> 
>
>
> Ooooh, really impressive.  of course it slows down every other program
> running on the same machine by stealing CPU.  But if you are used to
> running single batch streams on a mainframe then you may think that it
> is required.
>
> 
>
>
> You completely fail to notice that in a run-unit of several to several
> dozen programs each thread will do its own CALL of the programs and
> there is no need for each CALLed program to split itself into its own
> multiple threads.
>
> Write your programs as sequences that _are_ sequentially dependant,
> and mostly they are, and put the multi-threading (or multi-tasking) at
> a higher level.
>
> You came up with a silly idea of misusing ENTRY because you hate THRU
> and are now attempting to show how it _must_ be used.  Pargraphs
> _must_ be eliminated in your desire for recognition as some sort of
> super-programmer.
>
>
> 
>
>
> Can you quantify that. Can you show some actual single existing
> program in use within a system where 'sequencing is _not_ required to
> be maintained' ?
>
> (where single indicates a separately compiled cobol program).
>
> 
>
>
> Actually hardware engineers are _not_ running out of ideas.
>
> 
>
>
> I note the use of first person, I am sure you meant 'they'.
>
> 
>
>
> I note the use of first person, surely you mean 'they', have you
> actually tried OO ?
>
> 
>
>
> Possibly even using ENTRY instead of PERFORM, but that doesn't work.
>
> 
>
>
> I suggest that you may be happier working in some other language. Have
> you tried Java where multithreading is automatic and can be almost
> invisible ?
>
> You want to convert existing program to 'what C did in the 70s' or
> 'what Pascal did in the 80s'.  Now you want to bang in low-level
> multithreading.
>
> Why not at least try to update to 'what Java did in the 90s' and use
> OO Cobol if  multithreading is actually what you want to achieve.
>
> 
>
>
> Have you not heard of Beowulf clusters (and many other clustering
> systems) ?
>
>
> 
>
>
> You seem to have an obsession with dogs, too.

OTOH, it may be that he has the group doing homework
for him.

Warren

riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
> 
>
>Do thay actually allow you to reengineer code like this ?

I could if I wanted but haven't used ENTRY in a production program. (They do
n't
review legacy code here). I've used it in demos and test programs. I have us
ed
nested programs in production.

> How do you
>deal with sections ?  thru ? goto -exit ?

Use the section name as the ENTRY name. (They don't use sections here.)
THRU is always the exit. Just drop it.
Go to -exit becomes goback.

> What parameters do you pass, if not why bother changing to CALL.

Dates and other input data.
I'd change them so procedures are all the same. A mixture of call and perfor
m
looks ugly.

> Don't you just wind up with
>monolithic programs that are now completely untested and are in a
>style that is unproven ?

If translation is mechanical, it's the same program. Programs are tested 4-5
ways before making it to production.

>Or is it that you have never actually done this yet and it is just one
>of your unproven 'ideas' ?

I posted a working program here that used call/entry heavily.
 
>
>"What Pascal did in the 80s" it is then.

It's better than "What Cobol did in '74", a standard defended here with much
passion.
 
>
>No. Wrong.  There is only one thread in each program (and one in all
>Win3 programs together) unless the program specific starts another
>thread itself.  The difference is that each Win32 program has it own
>one thread.

Ok, so it starts the thread itself. My point wasn't who starts the thread, i
t
was the fact that multiple threads are running. The only alternative is
do-it-yourself dispatching in main().
 
>
>Geez, Robert, it almost sounds like you have actually written a
>Windows program using the API.  Have you ? was it in Cobol ?

I've written many many Cobol programs that call the OS API -- mainframe, DOS
,
Windows and Unix.
 
before 
the 
>
>That is of course true, but _only_ if the program has specifically
>increased its number of threads by _explicitly_ doing so.

In order to run a search with an active Cancel button, it MUST explicitly cr
eate
threads. Most commercial software on your PC runs multiple threads. If you d
on't
think so, go to sysinternals.com and download their Process Explorer.
 
>
>Only if the program has _explicitly_ invoked multi-threading and then
>doesn't bother to handle the consequences.  And it makes no difference
>whether it is one or two CPUs.  Pre-emptive is pre-emptive.

Single-processor doesn't make collisions impossible, but greatly lowers the
probability.

In the old days, we protected Critical Sections with the CLI instruction, wh
ich
used the CPU as a locking device.

>You may also have vaguely heard about mult-tasking where several
>programs run on one machine.  A box with 4 processors can run 4
>different programs at the same time.

The ones I work on run thousands of processes and hundreds of programs at th
e
same time.

> You seem to have such an
>attachment to _your_ program that you think all resources should be
>dedicated to it regardless of other needs.

Tell it to companies who write major databases, who use multithreading with
abandon. It was invented by Sybase. It's common for ONE Oracle process to ha
ve
3-500 threads running, and generate 20 task switches per second when nothing
 is
happening. When processing a complex query, the task switch rate for that si
ngle
process goes into the thousands. We usually have 100 such Oracle processes
running.

Java is another heavy multithreading user, especially when there are multipl
e
JVMs running.

>Now there _are_ sensible uses for multi-threading, such as web servers
>where a new thread can be started for each message so that I/O in one
>won't block the processing of the next message.  But this is handled
>at a higher level so that CALLed programs don't have to worry about
>this.

At minimum, they must be thread-safe.

>In fact it can work much like separate tasks with shared code
>segments.

That's what I call "CICS mode", which puts Working-Storage, buffers (if any)
 and
compiler-generated variables ALL in the stack (or dynamically allocated memo
ry).
Major Cobol compilers make it easy to do this with a single compiler option.
 The
threads don't communicate with each other.
> 
runs 
>
>Ooooh, really impressive.  of course it slows down every other program
>running on the same machine by stealing CPU.

System tuning deals with that issue. My 5-10 threads are small potatoes on a
machine that runs thousands of threads all the time.

> But if you are used to
>running single batch streams on a mainframe then you may think that it
>is required.

I'm used to running single batch streams on Unix. Excepting two years during
Y2K, I haven't touched a mainframe in 20 years.
 
>
>You completely fail to notice that in a run-unit of several to several
>dozen programs each thread will do its own CALL of the programs and
>there is no need for each CALLed program to split itself into its own
>multiple threads.
>
>Write your programs as sequences that _are_ sequentially dependant,
>and mostly they are, and put the multi-threading (or multi-tasking) at
>a higher level.

At risk of repetition, tell that to database companies and Java people. Both
routinely create threads at the sub-program level. Databases do it at the
statement level.

>You came up with a silly idea of misusing ENTRY because you hate THRU
>and are now attempting to show how it _must_ be used.  Paragraphs
>_must_ be eliminated in your desire for recognition as some sort of
>super-programmer.

I can't address the problem here because I'm a programmer, not a psychologis
t.
 
>
>Can you quantify that. Can you show some actual single existing
>program in use within a system where 'sequencing is _not_ required to
>be maintained' ?

Digging through archives, the first candidate I found appears to read three
files and print three or more reports:

MOVE 'MT.DTA' TO FILE-NAME.
PERFORM ONE-FILE.
MOVE 'HG.DTA' TO FILE-NAME.
PERFORM GET-FILE-NAME.
PERFORM ONE-FILE.
MOVE 'HG1.DTA' TO FILE-NAME.
PERFORM ONE-FILE.
 
>
>I note the use of first person, surely you mean 'they', have you
>actually tried OO ?

I wrote an operating system that was OO through and through. It's 'file syst
em'
only stored persistent objects. Want a record? Create a collection class. Wa
nt a
file? Create a collection class for that. In anticipaton, I know it's an '80
s
concept. OS/400, created in the late '80s, uses similar ideas.

I haven't written OO Cobol because I don't have an OO compiler at home. They
're
too expensive.

>I suggest that you may be happier working in some other language. Have
>you tried Java where multithreading is automatic and can be almost
>invisible ?

No. There seems to be a surplus of Java programmers willing to work cheap.

>You want to convert existing program to 'what C did in the 70s' or
>'what Pascal did in the 80s'.  Now you want to bang in low-level
>multithreading.

Multithreading is available in major Cobol compilers, almost all operating
systems, is routinely used in other languages, but very seldom used in Cobol
.
Perhaps the other guys know something we don't. I'm curious to see what can 
be
done with it .. or not.
 
>
>Have you not heard of Beowulf clusters (and many other clustering
>systems) ?

Of course. The behemouths are used for massively parallel, almost brute-forc
e,
solutions. Being optimized for speed, I doubt they're using OO.

-- begin quote --
Thunder, a supercomputer recently installed at Lawrence Livermore National
Laboratory, is possibly the second-most powerful computing machine on the
planet--and it was built by a company with about as many employees as a real
estate office.

California Digital, a 55-person company located on the outskirts of Silicon
Valley, created Thunder from 1,024 four-processor Itanium 2 servers to perfo
rm a
variety of tasks at the lab. Capable of churning 19.94 trillion operations p
er
second, it would have ranked second in the Top 500 list of supercomputers
published bi-annually by the University of Mannheim, the University of Tenne
ssee
and Lawrence Berkeley National Laboratory, had it made the deadline.

The key to the setup, and many like it, is to use the Linux operating system
 to
lash together a lot of comparatively cheap, off-the-shelf hardware to quickl
y
create computers with enough power to simulate the potential effects of
explosions or crunch data on galaxy formation.

http://news.com.com/2100-7337_3-520...ml?tag=nefd.top
-- end quote --

Effects of explosions? Looks like technocrats are using 9/11 as an excuse to
enlarge empires. Hopefully their supercomputer will figure out that kerosene
burns at 600C. The WTC was designed to have five times the required strength
.
Heat required to weaken its structural steel 80% is about 1400C, according t
o
published tables.

There is no way heat from a kerosene fire caused the Towers to collapse. A m
ajor
US professional fire fighter journal published a report that said the same. 
The
airplane crashes were an entertaining diversion. The buildings were brought 
down
by demolition charges. Firemen in the stairwells reported hearing them go of
f
and photographs show debris flying out just before the buildings collapsed.

The planes involved were Boeing 757/767, sister designs which share common
software. Both "exceeded their design requirements" by producing a plane tha
t
could be flown 100% by software, the parameters for which are commonly store
d on
a CD. They could take off, navigate and land (at an airport equipped with
Automated Landing) without a human pilot on board.

Given the government's love affair with computers, I believe the terrorists'
ONLY mission was to get into the cockpit, remove the legit CD, and replace i
t
with a CD programmed to fly into the WTC. They didn't have to know how to fl
y a
plane. They'd been told the plane would fly to a friendly country. They were
victims as much as the innocents.

And they weren't who the media said they were. According to reports in the
mainstream press more than half of the alleged terrorists have been found st
ill
living, including Atta, the alleged leadert. Someone stole their  identities
 and
assigned them to anonymous Arabs.
http://www.welfarestate.com/911/
http://news.bbc.co.uk/1/hi/world/mi...ast/1559151.stm
http://propagandamatrix.com/seven_o...ound_alive.html
http://www.portal.telegraph.co.uk/n...n23.xml


WTC 7, a fifty story building, collapsed that evening without being hit by a
plane. Observers heard explosions just before it collapsed.

Check the 10 TFlop Virginia Tech system at:

http://www.top500.org/list/2003/11/

Conspicuously absent from that list: NSA.

robert.deletethis@wagner.net (Robert Wagner) wrote

> I've used it in demos and test programs.

So, you haven't demonstrated it scaling past a handful of 'paragraphs'
in a toy program using a single compiler on just one platform.

> If translation is mechanical, it's the same program.

But it may not work the same, so far you haven't shown anything that
might in a production evironment.  You haven't shown what happens when
one program calls another in the same run-unit and they both have
mechanically changed names and may have the same.  What happens when
there are several programs being called and cancelled ?

So far the _only_ 'benefit' is that you think PERFORMs are 'ugly'.
Yet you must still use PERFORMs for iteration.

What most people do before they try to promote an idea is to actually
prove it in practice, show that it scales, find the problems and
determine solutions, show which vendors support it and what the limits
are.

As  I have said, the whole issue is your emotional attachment to some
brain fart that you had, just puffery.

> I posted a working program here that used call/entry heavily.

'Heavily' ? I must have missed that.

> It's better than "What Cobol did in '74", a standard defended here with mu
ch
> passion.

Is it ?  What that shows is that code from the 70s still runs and
still does the task that it was developed for.  For an enterprise that
represents ROI.

ENTRYs are an extension that is not in any standard, and in fact, do
go back to the 70s.  They are _not_ 'modern'.

> Ok, so it starts the thread itself. My point wasn't who starts the thread,

Your point seemed to be that Windows started more than one thread.
That was wrong.

> it
> was the fact that multiple threads are running. The only alternative is
> do-it-yourself dispatching in main().

Quite wrong.  Multiple threads are _only_ running if specificall
programmed.  You may be correct that if a naieve programmer calls the
API to start a new thread and does not cater for the consequences then
there will be problems.

But is does _not_ require, as you claimed, the replacement of
paragraphs with ENTRYs.
 
>
> I've written many many Cobol programs that call the OS API -- mainframe, D
OS,
> Windows and Unix.

It almost sounds like you are avoiding to answer.  Console mode
Windows with an odd CALL to some utility API was it then ?

> In order to run a search with an active Cancel button, it MUST explicitly
> create threads.

No. That is not true.  As I have attempted to educate you, it is only
necessary, in the minimal case, to 'yield' during the search using a
call to messagep.  This worked in Win3 and Win32.  It also caters
for the redraw of the Window so the results are displayed as they are
found, otherwise the redraw messages wait in the message queue until
the search end _even_ if you have another thread for the Cancel
button.

Now it may be that starting another thread for the Cancel button is a
better solution, more responsive perhaps.  But the code will only be
required to set an 'abandon' flag that the search code will check in
each cycle, at the same point that it may do the 'yield'.  The code
for the Cancel will not suddenly jump in an add 1 to a counter for no
reason, or try to help doing the search.

> Most commercial software on your PC runs multiple threads. If you don't
> think so, go to sysinternals.com and download their Process Explorer.

> In the old days, we protected Critical Sections with the CLI instruction,
> which used the CPU as a locking device.

In the 'old days' I was using mutual exclusion queues on
Concurrent-CP/M for my multi-threading control.

> Tell it to companies who write major databases, who use multithreading wit
h
> abandon. It was invented by Sybase. It's common for ONE Oracle process to 
have
> 3-500 threads running,

And that is exactly the same case as the web server.  It starts a
thread for each separate request and these proceed independently (or
as much as possible) through the system.  Cobol programs do not
normally act as servers except where they specifically are used as web
servers, and each thread is dealing with one request.

What you are proposing is quite different.

> At minimum, they must be thread-safe.

They need to be recompiled, but they only _need_ to worry about
external data.

> That's what I call "CICS mode", which puts Working-Storage, buffers (if an
y) and
> compiler-generated variables ALL in the stack (or dynamically allocated me
mory).
> Major Cobol compilers make it easy to do this with a single compiler optio
n. The
> threads don't communicate with each other.

Because they don't need to.  The Oracle threads that are performing
tasks on behalf of separate request don't need to communicate with
each other either.
 
>
> At risk of repetition, tell that to database companies and Java people. Bo
th
> routinely create threads at the sub-program level. Databases do it at the
> statement level.

In Cobol a 'program' is a separately compiled unit that has a
program-id.  The equivalent in Java or C++ is a Class.  Do Java and
C++ programs create a thread at the 'sub-class level' ?  I think not.
In fact I don't think they can.

If you are referring to Database 'statements' then perhaps you mean an
SQL statement, which, in fact, is the unit of client request.  Yes a
new thread may well be started for every client request.  This has
nothing to do with 'sub-program'.

> Digging through archives, the first candidate I found appears to read thre
e
> files and print three or more reports:
>
>  MOVE 'MT.DTA' TO FILE-NAME.
>  PERFORM ONE-FILE.
>  MOVE 'HG.DTA' TO FILE-NAME.
>  PERFORM GET-FILE-NAME.
>  PERFORM ONE-FILE.
>  MOVE 'HG1.DTA' TO FILE-NAME.
>  PERFORM ONE-FILE.

In what way is that a 'candidate' ?  It will use the same one FD for
the file and the same one printer FD for the report.  These are
exactly the 'external resources' that must be locked to prevent
multiple simultaneous access.  And I will clarify that so there is no
mistake: it is the FDs that must be locked.

If this was run as three separate run-units, ie multi-tasking, with
each doing one of the 3 tasks then that would work, ie there is no
real problem when there are 3 FDs for each of file and printer.  It
may be that if the program were duplicated into 3 separate compile
units, one for each file, then one parent process could start a thread
for each program.  As these 3 programs would each have separate FDs
and record buffers, they could run as 3 threads just as they could as
3 run-units.

Now for something radical:  If this program was made into a Class that
took the filename as a parameter then you would only need one class
(and not 3 duplicate programs) and could create 3 instances that could
each be made to run on their own thread.

This is _actually_ how Java does it.

> I haven't written OO Cobol because I don't have an OO compiler at home.
> They're too expensive.

Then I suggest that you may be happier with Java.  It overcomes your
objective by being free.  Once you have learnt how to do
multi-threading you should come back and show how it is to be done in
OO Cobol.  Now _that_ might be useful.

> Multithreading is available in major Cobol compilers, almost all operating
> systems, is routinely used in other languages, but very seldom used in Cob
ol.
> Perhaps the other guys know something we don't. I'm curious to see what ca
n be
> done with it .. or not.

What happened in many other languages is that they tried things and
discovered what worked, what didn't and what needed fixing.  By
learning those other languages you can learn what they did wrong and
what they did right.  In many cases those other languages did not
learn what Cobol did right, but then they were working in other
problem domains.

There is a reason why mult-threading in Java is attached to the Class:
it works better that way.

You seem to just jump in _without_ having learnt the lessons of 35
years of other languages.  You don't seem to even know what solutions
they arrived at let alone why.

> Effects of explosions? Looks like technocrats are using 9/11 as an excuse 
to
> enlarge empires. Hopefully their supercomputer will figure out that kerose
ne
> burns at 600C. The WTC was designed to have five times the required streng
th.
> Heat required to weaken its structural steel 80% is about 1400C, according
 to
> published tables.

Typical lame conspiracy theorist nonsense.

If kerosene burns at 600c then how do the jet engines work at 2000+c ?

> The airplane crashes were an entertaining diversion.

Entertaining ?

> The buildings were brought down by demolition charges.

[much junk deleted]

And no one ever walked on the moon either.

riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
> 
>
>So, you haven't demonstrated it scaling past a handful of 'paragraphs'
>in a toy program using a single compiler on just one platform.

The generated code for CALL/GOBACK is nearly identical to PERFORM/return. I
don't see how scaling could be an issue.
 
>
>But it may not work the same, so far you haven't shown anything that
>might in a production evironment.  You haven't shown what happens when
>one program calls another in the same run-unit and they both have
>mechanically changed names and may have the same.  What happens when
>there are several programs being called and cancelled ?

What happens is the compiler generates a machine-language call, same as it d
oes
for PERFORM.

Duplicate names is a straw man. There are loader commands to resolve symbols
internally and ignore duplicates.
 
>
>'Heavily' ? I must have missed that.

There are 13 ENTRYs in the Trees demo.
 
>
>Is it ?  What that shows is that code from the 70s still runs and
>still does the task that it was developed for.  For an enterprise that
>represents ROI.

Organizations are grateful for the longevity of old code, but see no reason 
to
develop new code with the same technology. Not realizing Cobol can be anythi
ng
more than '70s style, they've gone to other languages such as C and Java. I'
d
prefer they use modernized Cobol.

>ENTRYs are an extension that is not in any standard, and in fact, do
>go back to the 70s.  They are _not_ 'modern'.

True, but I found a novel use for the old ENTRY.
 
>
>Your point seemed to be that Windows started more than one thread.
>That was wrong.
> 
>
>Quite wrong.  Multiple threads are _only_ running if specifically
>programmed.  You may be correct that if a naive programmer calls the
>API to start a new thread and does not cater for the consequences then
>there will be problems.

Nearly all non-trivial programs with a UI or other real-time requirement cre
ate
multiple threads. It's the Windows and Unix way to make a program responsive
.

>But is does _not_ require, as you claimed, the replacement of
>paragraphs with ENTRYs.

Every thread requires at least one ENTRY or callable program. Converting an
existing Cobol program to run paragraphs in parallel requires changing at le
ast
one paragraph name to ENTRY, or breaking the program into smaller ones.

The result is an ugly (IMO) jumble of paragraph names and ENTRY. You can see
what it looks like in the multithreading demo I just posted.
 
>
>It almost sounds like you are avoiding to answer.  Console mode
>Windows with an odd CALL to some utility API was it then ?

If you'd read the programs I post here, you'd see them calling the Unix API.
 
>
>No. That is not true.  As I have attempted to educate you, it is only
>necessary, in the minimal case, to 'yield' during the search using a
>call to messagep.  This worked in Win3 and Win32.  It also caters
>for the redraw of the Window so the results are displayed as they are
>found, otherwise the redraw messages wait in the message queue until
>the search end _even_ if you have another thread for the Cancel
>button.

Sounds like Win3 technology (cooperative) was provided for backward
compatibility. I'd write it as three threads: search, cancel and results.
 
> 
>
>In the 'old days' I was using mutual exclusion queues on
>Concurrent-CP/M for my multi-threading control.

There you go .. you're an old hand with multithreading.
 
have 
>
>And that is exactly the same case as the web server.  It starts a
>thread for each separate request and these proceed independently (or
>as much as possible) through the system.  Cobol programs do not
>normally act as servers except where they specifically are used as web
>servers, and each thread is dealing with one request.

The role of Cobol programs in this context is to get legacy data. The Cobol
program often runs on a machine external to the web server. It is called via
RPC, a database stored procedure, CICS or some middleware like Websphere.

>What you are proposing is quite different.

Yes, I'm proposing multithreading within a Cobol program to make it run fast
er.
That's what databases do. They split a complex query into subqueries, run th
em
in parallel, wait for all to finish and merge the results.
 
>
>In Cobol a 'program' is a separately compiled unit that has a
>program-id.  The equivalent in Java or C++ is a Class.

No it isn't. A Java or C++ program is similar to the Cobol concept of progra
m. A
Class is analogous to a Cobol called program.

>Do Java and
>C++ programs create a thread at the 'sub-class level' ?  I think not.
>In fact I don't think they can.

If each Class is already a thread, there's no need to create additional thre
ads.
I like the concept. It's like "each object living in its own machine."

>If you are referring to Database 'statements' then perhaps you mean an
>SQL statement, which, in fact, is the unit of client request.  Yes a
>new thread may well be started for every client request.  This has
>nothing to do with 'sub-program'.

A dozen threads may start for one query: one for the compiler, one for the
optimizer, one or more for caching (to see whether it's seen the same query
recently), and one for each parallel query activity.  EXPLAIN PLAN shows the
activities and which are run in parallel.

It's not about keeping users separated; it's about processing a query in
parallel for speed.
 
>
>In what way is that a 'candidate' ?  It will use the same one FD for
>the file and the same one printer FD for the report.  These are
>exactly the 'external resources' that must be locked to prevent
>multiple simultaneous access.  And I will clarify that so there is no
>mistake: it is the FDs that must be locked.
>
>If this was run as three separate run-units, ie multi-tasking, with
>each doing one of the 3 tasks then that would work, ie there is no
>real problem when there are 3 FDs for each of file and printer.  It
>may be that if the program were duplicated into 3 separate compile
>units, one for each file, then one parent process could start a thread
>for each program.  As these 3 programs would each have separate FDs
>and record buffers, they could run as 3 threads just as they could as
>3 run-units.

It's not necessary to pick one approach or the other. You can have both in a
single run-unit. Suppose flat-file IO is done in simple callable programs. M
y
systems are always designed that way, as are 'classic' three-tier client-ser
ver
designs (where the IO programs are called DAMs, Data Access Module). Suppose
 the
file-io programs are compiled REENTRANT(2), which gives separate buffers and
FCBs per thread, whereas all other programs are compiled REENTRANT(1). Under
that scenario, it's not necessary to lock FDs.

>Now for something radical:  If this program was made into a Class that
>took the filename as a parameter then you would only need one class
>(and not 3 duplicate programs) and could create 3 instances that could
>each be made to run on their own thread.
>
>This is _actually_ how Java does it.

That's the same as I just described above. Old wine in new bottles.
 
>
>Then I suggest that you may be happier with Java.  It overcomes your
>objective by being free.  Once you have learnt how to do
>multi-threading you should come back and show how it is to be done in
>OO Cobol.  Now _that_ might be useful.

One step at a time. If I advocate OO AND multithreading, 'traditional' Cobol
programmers' eyes will glaze over. It will seem like a new language to them.
Multithreading is something they could do _today_, even retrofit into existi
ng
programs, using familiar syntax and requiring only a few lines of change.

>What happened in many other languages is that they tried things and
>discovered what worked, what didn't and what needed fixing.  By
>learning those other languages you can learn what they did wrong and
>what they did right.

Yes, I concur.

>There is a reason why mult-threading in Java is attached to the Class:
>it works better that way.

Not surprising. All the heavy lifting is done in methods. From what I've rea
d,
synchronization is not automatic nor magical. The programmer controls it (or
not) with the word SYNCHRONIZED and/or explicit locking methods -- wait(),
notify() -- little different from the ones we use. I see complaints about th
e
high cost of synchronization, deadlocks and intermittent wrong answers. Some
things never change.


>Typical lame conspiracy theorist nonsense.

No high-rise building has ever collapsed as the result of fire, and there ha
ve
been fires much worse than WTC. In 1991, Philadelphia's One Meridian Plaza
burned for 18 hours and experienced temperatures high enough to blow out win
dows
and melt aluminum (which did not happen at WTC).

Before WTC, the ONLY causes for high-rise collapse were earthquakes and
demolition charges.

http://911research.wtc7.net/wtc/ana...pare/fires.html

>If kerosene burns at 600c then how do the jet engines work at 2000+c ?

According to the Law of Gasses, the hotter a jet engine's exhaust, the great
er
its thrust. In order to increase exhaust temperature, jet engines spend 50-6
0%
of their energy compressing input air by more than 20:1 (300 psi). Compressi
on
causes a hotter fire.
 
>
>[much junk deleted]

Here's more junk. The Oklahoma City Federal building (partially) collapsed
because something sheared a structural beam in its center. The pressure requ
ired
to do that was more than 5,000 psi. A large ammonium nitrate bomb 40 feet aw
ay
can deliver less than 100 psi.

When the former head of US Air Force munitions research (along with other
explosives professionals) said it was impossible for that bomb to cause that
damage, he was dismissed as a nut. So he found a similar building and built 
a
similar bomb. It did cosmetic damage, didn't touch the building's structure.
When he put a smallish explosive in contact with the main beam, it brought t
he
building down. Contact explosives can assert 1M psi.

Workers in the building said there were two explosions --  a small one that 
made
the building shake and sway followed ten seconds later by a big one outside,
which  broke windows. Seismographs showed two shock waves.

The bomb squad kept rescuers out until they could remove two unexploded bomb
s
from the rubble. The ends of the building did not collapse. There was a bomb
 in
each end.

Finally, the bomb squad arrived a half hour before the explosion(s).

Similarities between OKC and WTC are: collapsed buildings, stereotyped bad g
uys
to act as patsies, the public believing an official explanation that defies 
the
laws of physics, and a government investigation that, unsurprisingly, confir
ms
the official explanation.

>And no one ever walked on the moon either.

You're saying all government explanations are true; a person who questions a
ny
of them is a nut.

"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40b0ccfe.66666851@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
> 
[interesting stuff deleted ]

That idea below is well - just all wet. What caused the main exodus from
COBOL was not lags in teh capability of the language, it was purely and
simply the cost of the compiler and runtimes.

Put a good COBOL compiler out there at a decent price, with no runtime
costs, and you would see things change radically.

C basically took over because C is cheap to the point of being free.

Ccompilers are easy to write (the language is simple) and the libaries are
very portable. You can get one or more top quality free C compilers for just
about any platform out there now, including z/OS.

-Paul

 
>
> Organizations are grateful for the longevity of old code, but see no
reason to
> develop new code with the same technology. Not realizing Cobol can be
anything
> more than '70s style, they've gone to other languages such as C and Java.
I'd
> prefer they use modernized Cobol.

robert.deletethis@wagner.net (Robert Wagner) wrote

> Digging through archives, the first candidate I found appears to read thre
e
> files and print three or more reports:
>
>  MOVE 'MT.DTA' TO FILE-NAME.
>  PERFORM ONE-FILE.
>  MOVE 'HG.DTA' TO FILE-NAME.
>  PERFORM GET-FILE-NAME.
>  PERFORM ONE-FILE.
>  MOVE 'HG1.DTA' TO FILE-NAME.
>  PERFORM ONE-FILE.

While your demo does show that it can benefit from running on four
processors (but is slower to _much_ slower when limited to a single
CPU), those results would not apply to your claim for this program to
be candidate.

The program reads a file, actually 3 separate files, and produces
reports.  The CPU requirement is likely to be small in comparison with
the I/O time.  With multi-threading, even with several CPUs, the
result is most likely that it will be slower.

In fact in the early-80s, when I was using 8086 based multi-user
machines, I added mutual exclusion queues to some programs to defeat
the task switching. By restricting disk access by the programs to only
be done while holding the token and having a program hold the token
while sequentially processing several records it reduced the cache
flushes by the system.  In a 1Mb machine there were too few disk
buffers and each program in turn was reusing these and causing
thrashing of the disk buffers.

In some cases the MX queues increased the performance of certain tasks
by a factor of 3 while having negligible effects on others.

While your demo only demonstrates the problems of 'task thrashing'
leading to slow performance, doing it to this program may also show
problems of 'disk cache thrashing' as each 'read next' has to retrieve
index file and data blocks only just discarded because of other tasks.

Actually, it is unlikely to be a problem with just one 3 thread
program, as here.  But if you did this to a number of programs then as
the thread count went up so would the time required to complete all
tasks.

"PAUL RAULERSON" <pkraulerson@verizon.net> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40b0ccfe.66666851@news.optonline.net... 
>[interesting stuff deleted ]
>
>That idea below is well - just all wet. What caused the main exodus from
>COBOL was not lags in the capability of the language, it was purely and
>simply the cost of the compiler and runtimes.
>
>Put a good COBOL compiler out there at a decent price, with no runtime
>costs, and you would see things change radically.

Realia did .. in 1985. They are no longer in business. Back then I was an
independent developer with a 'borrowed' copy that worked fine. I paid $1,000
 for
a legal copy and didn't take the shrinkwrap off the package for years.

The price of software is determined like the price of everything else, inclu
ding
human labor -- by supply and demand. If Cobol compiler sales were 500,000 pe
r
year, a compiler would sell for $109, same as C#. The software market, at le
ast
'mature' software, is driven by demand, not by supply.

There are ab estimated 5,000,000 C/Java programmers in the US vs. 60,000 Cob
ol
programmers. If you s someone to blame for the high cost of Cobol compile
rs,
it should be all those programmers who voted for C with their wallets.

I work for companies that spend _multi-millions_ on Enterprise software such
 as
SAP, Peoplesoft, Cognos and Oracle. In this environment, a few thousand or e
ven
a hundred thousand for a development tool is a drop in the bucket. So why ar
e we
developing new applications in Java and C# rather than Cobol? The reason may
 be
right or wrong, but it's certainly not compiler cost.

>C basically took over because C is cheap to the point of being free.

Ask a C++, C# or Java programmer why he or she chose the language. I'll wage
r
fewer than 1% say 'because the compiler was cheap.' Their eyes will light up
 as
they talk about the language's 'ness'. I empathize with that feeling. I 
find
Cobol even er.

>C compilers are easy to write (the language is simple) and the libaries are
>very portable. You can get one or more top quality free C compilers for jus
t
>about any platform out there now, including z/OS.

Writing a Cobol compiler for dot.net or JVM might be simple too. 'They' have
provided your back-end native code generator free. You need only to compile 
to
intermediate code.

The most time-consuming parts of writing a compiler are not the compiler its
elf,
they're things like the file system. Marc Sokol of Realia said they spent mo
re
time writing the file system than the compiler. That stuff is now either
unnecessary (indexed files) or available free in class libraries from Micros
oft
and others.

If you ignore nonsense such as BNF notation and just write a compiler, you c
ould
probably do it in a year. To your salary add the cost of a Web site, sales a
nd
support staff. Estimate how many dot.net or JVM Cobol compilers you might se
ll
in the first year. (My guess: 500). Add a factor for the uncertainty and ris
k
involved .. double your costs. Now set a sales price that will recoup the
startup cost in the first year. It will be in the neighborhood of $2K.

As your compiler company matures, cost will go up as development staff incre
ases
from YOU to a few dozen developers plus support people. Before you know it, 
your
compiler will sell for $4K, just like the others.

OTOH, if your conjecture is correct, you'll sell 10,000 per year. At $300 pe
r,
you'd be a $3M company with net profit of $1M per year.

Go for it if you want. I'm not so sanguine.

Robert

-- history follows --
>
>-Paul
>
> 
>reason to 
>anything 
>I'd 
>
>