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

From: Richard (riplin_at_Azonic.co.nz)
Date: 05/23/04 

Date: 22 May 2004 16:19:21 -0700

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 much
> 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.

> >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.

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 messagepeek. 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 with
> 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 any) and
> compiler-generated variables ALL in the stack (or dynamically allocated memory).
> Major Cobol compilers make it easy to do this with a single compiler option. 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.

> >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.

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 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.

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 Cobol.
> Perhaps the other guys know something we don't. I'm curious to see what can 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 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 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.