Home > Archive > Cobol > May 2004 > R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed
|
|
| Richard 2004-05-20, 7:30 am |
| 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 is
> 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.
[color=darkred]
> Suppose the program needs to do process A, B and C. A traditional Cobol program
> 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.
| |
| Robert Wagner 2004-05-21, 2:30 am |
| 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 Win32
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 wants
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 cannot
both write to the same variable unless they take extra steps to lock it before
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 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 to
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 current
single-threaded environment. If they were used in the multithreaded Oracle
External Procedure environment, they'd occasionally produce wrong answers or
abends.
program[color=darkred]
>
>
>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 had
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 are
even putting two of them on one chip. They call it HyperThreading. You really
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 runs
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 "require
sequencing to be maintained." Many or most operations don't.
Hardware engineers are running out of ideas, and fast approaching the physical
speed limit of a ten angstrom trace. They want us software types to help them 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 that
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, who
represents everyman. The dog pulled the curtain aside to expose the fraud.
| |
| Richard 2004-05-21, 6:30 pm |
| 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 but 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 worker
> thread is no longer required to periodically issue Yield (but can if it wants
> 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 Win3,
> both could write without a problem. Under Win32's multithreading, they cannot
> both write to the same variable unless they take extra steps to lock it before
> 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 and
> both add 1. There is a 50% chance the answer will be 1 and 50% it will be 2.
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:
[color=darkred]
> 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-Storage
> 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 two,
> 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 really
> 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 the
> 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 among
> 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 Cobol'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 physical
> speed limit of a ten angstrom trace. They want us software types to help them
> by moving beyond Von Niemann thinking, where we've been stuck for 40 years.
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 is
> 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.
| |
| Warren Simmons 2004-05-21, 9:30 pm |
| 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
| |
| Robert Wagner 2004-05-22, 10:30 am |
| 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 don't
review legacy code here). I've used it in demos and test programs. I have used
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 perform
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, it
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[color=darkred]
the[color=darkred]
>
>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 create
threads. Most commercial software on your PC runs multiple threads. If you don'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, which
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 the
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 have
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 single
process goes into the thousands. We usually have 100 such Oracle processes
running.
Java is another heavy multithreading user, especially when there are multiple
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 memory).
Major Cobol compilers make it easy to do this with a single compiler option. The
threads don't communicate with each other.
>
runs[color=darkred]
>
>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 psychologist.
>
>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 system'
only stored persistent objects. Want a record? Create a collection class. Want a
file? Create a collection class for that. In anticipaton, I know it's an '80s
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-force,
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 perform a
variety of tasks at the lab. Capable of churning 19.94 trillion operations per
second, it would have ranked second in the Top 500 list of supercomputers
published bi-annually by the University of Mannheim, the University of Tennessee
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 quickly
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 to
published tables.
There is no way heat from a kerosene fire caused the Towers to collapse. A major
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 off
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 that
could be flown 100% by software, the parameters for which are commonly stored 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 it
with a CD programmed to fly into the WTC. They didn't have to know how to fly 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 still
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.../23/widen23.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.
| |
| Richard 2004-05-22, 8:30 pm |
| 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.
>
> 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 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 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.
>
> 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.
| |
| Robert Wagner 2004-05-23, 4:30 pm |
| 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 does
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 anything
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 create
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 least
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[color=darkred]
>
>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 faster.
That's what databases do. They split a complex query into subqueries, run them
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 program. 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 threads.
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. My
systems are always designed that way, as are 'classic' three-tier client-server
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 existing
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 read,
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 the
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 have
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 windows
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 greater
its thrust. In order to increase exhaust temperature, jet engines spend 50-60%
of their energy compressing input air by more than 20:1 (300 psi). Compression
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 required
to do that was more than 5,000 psi. A large ammonium nitrate bomb 40 feet away
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 the
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 bombs
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 guys
to act as patsies, the public believing an official explanation that defies the
laws of physics, and a government investigation that, unsurprisingly, confirms
the official explanation.
>And no one ever walked on the moon either.
You're saying all government explanations are true; a person who questions any
of them is a nut.
| |
| PAUL RAULERSON 2004-05-23, 7:30 pm |
|
"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
[color=darkred]
>
> 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.
| |
| Richard 2004-05-23, 8:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> 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.
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.
| |
| Robert Wagner 2004-05-23, 10:30 pm |
| "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, including
human labor -- by supply and demand. If Cobol compiler sales were 500,000 per
year, a compiler would sell for $109, same as C#. The software market, at least
'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 Cobol
programmers. If you s someone to blame for the high cost of Cobol compilers,
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 even
a hundred thousand for a development tool is a drop in the bucket. So why are 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 wager
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 just
>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 itself,
they're things like the file system. Marc Sokol of Realia said they spent more
time writing the file system than the compiler. That stuff is now either
unnecessary (indexed files) or available free in class libraries from Microsoft
and others.
If you ignore nonsense such as BNF notation and just write a compiler, you could
probably do it in a year. To your salary add the cost of a Web site, sales and
support staff. Estimate how many dot.net or JVM Cobol compilers you might sell
in the first year. (My guess: 500). Add a factor for the uncertainty and risk
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 increases
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 per,
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
>
>
| |
| Richard 2004-05-24, 1:30 am |
| robert.deletethis@wagner.net (Robert Wagner) wrote
>
> The generated code for CALL/GOBACK is nearly identical to PERFORM/return. I
> don't see how scaling could be an issue.
There may be a lot of things that you don't see. These may only
become visible when it is actually tried in a large scale environment.
> Duplicate names is a straw man. There are loader commands to resolve symbols
> internally and ignore duplicates.
Which may, or may not, be useful, and may, or may not, cause problems
with other programs and with the run-time.
> There are 13 ENTRYs in the Trees demo.
Which is not 'heavily' compared to your suggestion that _EVERY_
pargraph in programs be replaced.
I also noticed that you still used PERFORM extensively.
> 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.
Those that are still using ANS'74 style should be updated via ANS'85
and ANS'2002 and not to something that _isn't_ 'modernized Cobol'.
[color=darkred]
> Every thread requires at least one ENTRY or callable program. Converting an
> existing Cobol program to run paragraphs in parallel requires changing at least
> one paragraph name to ENTRY, or breaking the program into smaller ones.
So you do agree that your claim of 'Changing EVERY paragraph' was
wrong.
> 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.
'Ugly' is subjective. Some see all lower case as 'ugly'. Some see
your style of full stops as 'ugly'. You seem to think that your
standards of what is 'ugly' and what is 'beautiful' should be
universal.
>
> If you'd read the programs I post here, you'd see them calling the Unix API.
I had already assumed that you hadn't actually written a Windows GUI
API program. It was obvious from your messages.
>
> Sounds like Win3 technology (cooperative) was provided for backward
> compatibility. I'd write it as three threads: search, cancel and results.
As I said: 'in the minimal case', your cliams about who did what were
wrong.
> There you go .. you're an old hand with multithreading.
Than you for realising that I do actually have enough of a background
to know what I am talking about.
>
> No it isn't. A Java or C++ program is similar to the Cobol concept of program.
Geez, Robert, what is it that you fail to notice about Java ?
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
What part of this is not a class ?
> A Class is analogous to a Cobol called program.
What did I just say ? What distinction between 'equivalent' and
'analogous' makes a difference ?
> 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.
So now you are not only requiring that it be done exclusively in MF,
but in a particular very recent version of MF that they must buy in
order to bend to your will.
But you are advocating things which require REENTRANT(n). Are these
cheaper ? Do you have one ?
[color=darkred]
> One step at a time. If I advocate OO AND multithreading, 'traditional' Cobol
> programmers' eyes will glaze over.
At least OO is modern and useful and adding multithreading to OO is
better than your 'how assembler did it in the 60s' with hand coded
locks (which even you acknowledge as being flakey).
> It will seem like a new language to them.
> Multithreading is something they could do _today_, even retrofit into existing
> programs, using familiar syntax and requiring only a few lines of change.
You really don't get it do you. You have demonstrated that
multi-threading is _slower_ on single CPUs and uses more machine
resources, even when using your flakey mechanism. The reason that
there is 50% CPU free is probably because the disk IO is the limiting
factor. What does increasing the task numbers do to the system
thruput ? Almost nothing when these just make the IO queue longer.
> Not surprising. All the heavy lifting is done in methods. From what I've read,
> 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 the
> high cost of synchronization, deadlocks and intermittent wrong answers. Some
> things never change.
Locking is only required for _external_ data items. Ones that can be
accessed by more than one thread. In your use of ENTRY _everything_
in W-S is 'external' and potentially needs locking. Local-Storage is
not external, but cannot survive EXIT PROGRAM so data must be saved in
W-S between CALLs.
RENTRANT(2) appears to create a new create a new instance of Data
Division for each thread, which is exactly what would happen if an
instance of an object were created for each thread. This means that
locking only need be done for data that is really EXTERNAL.
> No high-rise building has ever collapsed as the result of fire,
Typical lame consiracy theorist claim.
No high-rise ever had that many tons of avgas dumped into them.
Building have collapsed because of fire, steel frame building have
collapsed because of fire.
| |
| Paul Raulersonv 2004-05-24, 2:30 am |
| Amazingly enough - you missed the whole point entirely. There is no fundamental difference
between a C compiler and a COBOL compiler, not at a technical level. Yet one costs zero dollars
for any platform, and the other costs a minimum of $1000 (my guess is more like $1500)
per developer, and who knows what for each runtime.
Vote with their wallet? Why not?
FileSystems the most difficult part? I think not. Not only are there plenty of free ones out there,
but writing an indexed file system is, or at least used to be, a pretty standard part of everyone's
education. Same as writing a Pascal compiler... it is *not* all that difficult.
Writing for .net? I think that Fujitsu did that, and they still tend to charge $1500 per developer.
(*sigh*) You would think that they would learn from both Microsoft and UNIX. Microsoft
generally makes it possible for anyone who really wants one to legally obtain a compiler.
UNIX delivers the C compiler as part of the Operating System, except in the case of SCO,
which is a bad thing anyway.
-Paul
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message news:40b12e4c.91581135@news.optonline.net...
> "PAUL RAULERSON" <pkraulerson@verizon.net> wrote:
>
>
> 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, including
> human labor -- by supply and demand. If Cobol compiler sales were 500,000 per
> year, a compiler would sell for $109, same as C#. The software market, at least
> '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 Cobol
> programmers. If you s someone to blame for the high cost of Cobol compilers,
> 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 even
> a hundred thousand for a development tool is a drop in the bucket. So why are 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.
>
>
> Ask a C++, C# or Java programmer why he or she chose the language. I'll wager
> 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.
>
>
> 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 itself,
> they're things like the file system. Marc Sokol of Realia said they spent more
> time writing the file system than the compiler. That stuff is now either
> unnecessary (indexed files) or available free in class libraries from Microsoft
> and others.
>
> If you ignore nonsense such as BNF notation and just write a compiler, you could
> probably do it in a year. To your salary add the cost of a Web site, sales and
> support staff. Estimate how many dot.net or JVM Cobol compilers you might sell
> in the first year. (My guess: 500). Add a factor for the uncertainty and risk
> 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 increases
> 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 per,
> 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 --
>
| |
| William M. Klein 2004-05-24, 3:30 am |
|
"PAUL RAULERSON" <pkraulerson@verizon.net> wrote in message
news:9D9sc.10541$No1.7731@nwrddc02.gnilink.net...
<much snippage>
>
> Put a good COBOL compiler out there at a decent price, with no runtime
> costs, and you would see things change radically.
>
I assume that you are aware that Fujitsu put their V3 compiler out FOR FREE (no
run-time charges and ORIGINALLY available for people to use for "production
use" - with no restriction on distribution). Lots and "lots" of people got it k-
but it didn't REALLY change much (for Fujitsu *or* COBOL). It did "some-what"
reduce the Micro Focus "domination" of the Windows market - but Micro
Focus/Merant policies and problems did almost as much in causing that.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
|
| William M. Klein wrote:
> I assume that you are aware that Fujitsu put their V3 compiler out FOR FREE (no
> run-time charges and ORIGINALLY available for people to use for "production
> use" - with no restriction on distribution). Lots and "lots" of people got it k-
> but it didn't REALLY change much (for Fujitsu *or* COBOL). It did "some-what"
> reduce the Micro Focus "domination" of the Windows market - but Micro
> Focus/Merant policies and problems did almost as much in causing that.
Does anyone still have a copy of THAT licensed version lying around?
I'd LOVE to have a PC-based COBOL compiler that would allow me to play
with SQL...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| PAUL RAULERSON 2004-05-24, 11:30 pm |
| Naw Bill, Fujitsu 3 was just starting to kick in when they came out with
Fujitsu-4, and started charging
significant bucks for it. While I have three (grin) Fujitsu legal licenses
for V3 (and paid for versions of
newer stuff too), I can't use Fujitsu-3 for anything.
Now if they really want to see that thing fly, they could release it to open
source maintenance.
-Paul
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:mtgsc.6989$Tn6.1308@newsread1.news.pas.earthlink.net...
>
> "PAUL RAULERSON" <pkraulerson@verizon.net> wrote in message
> news:9D9sc.10541$No1.7731@nwrddc02.gnilink.net...
> <much snippage>
>
> I assume that you are aware that Fujitsu put their V3 compiler out FOR
FREE (no
> run-time charges and ORIGINALLY available for people to use for
"production
> use" - with no restriction on distribution). Lots and "lots" of people got
it k-
> but it didn't REALLY change much (for Fujitsu *or* COBOL). It did
"some-what"
> reduce the Micro Focus "domination" of the Windows market - but Micro
> Focus/Merant policies and problems did almost as much in causing that.
>
>
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
>
| |
| Richard 2004-05-25, 3:30 am |
| "PAUL RAULERSON" <pkraulerson@verizon.net> wrote
> Naw Bill, Fujitsu 3 was just starting to kick in when they came out with
> Fujitsu-4, and started charging
> significant bucks for it.
I just checked my records and notice that I paid $US 189 for Fujitsu
Cobol 4 Enterprise (the whole real thing) and $US 180 for a Complete
set of printed manuals, plus $US 50 shipping. This was a Special
'Order by June 30th' in 1998 and was probably because I had Version 3.
I can't find what I did pay for the several V3 CDs that I have, they
may have all been free, but I bought a set of V3 manuals for $US
149.95 plus $US 19.05 shipping.
On the basis of having V4 I paid the 'Special upgrade, today only'
price to Version 6.1 professional. The VISA statement shows $US 313
which included shipping.
> Now if they really want to see that thing fly, they could release it to open
> source maintenance.
Certainly the prices on their site are more than I would want to pay.
| |
| Robert Wagner 2004-05-25, 6:30 am |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>
>There may be a lot of things that you don't see. These may only
>become visible when it is actually tried in a large scale environment.
I saw that today. The code for calling is not a problem, but the code for
_receiving_ a call is.
least[color=darkred]
>
>So you do agree that your claim of 'Changing EVERY paragraph' was
>wrong.
It was a trial baloon. You and WK disliked it; others were silent.
>
>'Ugly' is subjective. Some see all lower case as 'ugly'. Some see
>your style of full stops as 'ugly'. You seem to think that your
>standards of what is 'ugly' and what is 'beautiful' should be
>universal.
Drat. My proclivity to be a control freak has been exposed.
>I had already assumed that you hadn't actually written a Windows GUI
>API program. It was obvious from your messages.
I spent a year doing Accenture FCP (Foundation Control Program), which received
messges via callbacks.
>
>Thank you for realising that I do actually have enough of a background
>to know what I am talking about.
I never questioned your knowledge. You question mine all the time, including
areas where it should be obvious I've been. For instance, I say I wrote an OO
operating system and you talk as though I'm an OO neophyte.
>
>So now you are not only requiring that it be done exclusively in MF,
>but in a particular very recent version of MF that they must buy in
>order to bend to your will.
All compilers will have the equivalent of reentrant(2), where every thread is
sealed up, not sharing memory with other threads. I'm not positive they have
reentrant(1), which is true multithreading.
>
>But you are advocating things which require REENTRANT(n). Are these
>cheaper ? Do you have one ?
Fair comment. No, I don't have it at home but do at work. I looked at its OO
features yesterday afternoon, found the syntax easy to understand. Methods are
just nested programs. My next demo will be OO.
>
>At least OO is modern and useful and adding multithreading to OO is
>better than your 'how assembler did it in the 60s' with hand coded
>locks (which even you acknowledge as being flakey).
I didn't say they were flaky. They're leak-proof and the ONLY way to get
expected performance. If you have to call thread functions such as mutex, you're
better off single-threaded.
existing[color=darkred]
>
>You really don't get it do you. You have demonstrated that
>multi-threading is _slower_ on single CPUs and uses more machine
>resources, even when using your flakey mechanism. The reason that
>there is 50% CPU free is probably because the disk IO is the limiting
>factor. What does increasing the task numbers do to the system
>thruput ? Almost nothing when these just make the IO queue longer.
You're trying to solve today's problems with solutions you developed in the '80s
and early '90s, when programmers had to hold the machine's hand and alter their
style to cope with its inadequacies. Those days are gone. Machines now have 16G
of real memory and gobs of on-ship cache.
When I do a Cobol compilation for the first time, it takes about a second. When
I do subsequent compilations, they take milliseconds. The whole compiler is in a
cache.
>Locking is only required for _external_ data items. Ones that can be
>accessed by more than one thread. In your use of ENTRY _everything_
>in W-S is 'external' and potentially needs locking. Local-Storage is
>not external, but cannot survive EXIT PROGRAM so data must be saved in
>W-S between CALLs.
Correct, working-storage is 'shared memory'. Updates to it must be locked unless
they are thread-specific.
That's the best way to communicate between parallel threads. It's a lot faster
than IPC memory.
>RENTRANT(2) appears to create a new create a new instance of Data
>Division for each thread, which is exactly what would happen if an
>instance of an object were created for each thread. This means that
>locking only need be done for data that is really EXTERNAL.
Sounds like the thread managers you've used made every thread reentrant(2).
That's a wasteful solution
>
>Typical lame consiracy theorist claim.
>
>No high-rise ever had that many tons of avgas dumped into them.
Avgas is 100 octane gasoline for reciprocating engines. Jet fuel is kerosene.
A fire's temperature doesn't increase because of fuel quantity. It does only in
the movies.
>Building have collapsed because of fire, steel frame building have
>collapsed because of fire.
Name two.
| |
| Michael Wojcik 2004-05-25, 2:30 pm |
|
In article <40b0ccfe.66666851@news.optonline.net>, robert.deletethis@wagner.net (Robert Wagner) writes:
> riplin@Azonic.co.nz (Richard) wrote:
>
>
> No it isn't. A Java or C++ program is similar to the Cobol concept of
> program. A Class is analogous to a Cobol called program.
Neither of those statements are particularly felicitous.
In Java, all code has to be part of a class method, but a class is
not the equivalent of a program. The Java language does not define
"program", AFAIK, so it's not entirely clear what would constitute a
Java program; in particular, it's not clear how the component models
defined by various Java standards (Javabeans, EJBs, and so forth)
relate to "program" either as it's popularly used, or in the special
COBOL sense. However, Java applications and applets (applications
which run in a JVM that's hosted within another application) are
probably similar enough to what's usually understood by "program" to
qualify for the latter.
Given that, a Java "program" in the popular sense is a collection of
one or more classes, at least one of which must have a public "main"
method, which will be the starting point of execution if that class
is the one being invoked to start the program.
Since Java classes are normally compiled into separate units, there
is some structural similarity between a Java class and a COBOL
"program": each is a separately compiled unit with at least one entry
point. However, there are major differences as well. Most Java
classes do not have a default entry point (ie a public "main"
method), which is the Java equivalent of the beginning of the COBOL
procedure division. Most Java classes have multiple public methods,
which are the equivalent of entry statements - except that there are
considerable semantic differences between Java public methods and
COBOL entry statements. Non-final Java methods are polymorphic,
whereas in conventional (non-OO) COBOL the program or entry
identifier specifies only one entry point. And so forth.
Of course it's possible to write COBOL in a Java-like fashion, with
multiple entry statements per module (as Robert is advocating) as
additional "methods" and so forth. And of course it's possible to
write OO COBOL in the first place rather than doing all the work by
hand. But as the languages are normally used, the correspondence
between a COBOL program and a Java class is limited at best.
It's even more distant with COBOL and C++. A C++ module may have
any number of external entry points (though a module with no external
entry points is only useful to define data). It may define any
number of classes, including 0. A C++ program begins execution at
its main function, which is not a class method, and may not use any
classes at all.
Since all Java code exists in a method, no Java threads run anything
other than within a class (if that is indeed a meaningful thing to say),
unless they're invoking non-Java code (eg through JNI). However, since
Java threads begin execution in a given *method*, they are created for
a method and not a class, and in that sense are indeed at the "sub-class
level" (in the sense that a method is only part of a class).
C++ doesn't define threads as part of the standard language, so how
they work is entirely an implementation detail. However, I'm not
aware of any implementation where thread creation refers to anything
other than a function, which may or may not be a class method.
[color=darkred]
> If each Class is already a thread, there's no need to create additional
> threads. I like the concept. It's like "each object living in its own
> machine."
It's like "hugely inefficient", if we substitute "object" for "Class"
in order to make it a meaningful statement. Even then I'm not sure
exactly what it would entail. A Smalltalk-like model where
inter-class interaction is defined as message passing, but with each
object running in its own preemptive thread? It'd be a disaster. A
typical real OO program has thousands of objects. Just think about
how many context switches you'd be looking at. Think about how many
private thread areas. With anything less than a 64-bit address
space, you'd never be able to allocate reasonable-size contiguous
areas for each thread (even in 64-bit that could get ugly), so you
wouldn't be able to use a stack for calls - you'd have to use
noncontiguous activation records, which are far more expensive (more
overhead and less locality of reference).
Maybe you should read the comp.programming.threads FAQ, or better yet
some actual CS background on threading theory, before arguing the
relative merits of multithreading.
Multithreading is a programmer convenience. It improves performance
in two cases: applications that weren't very well-designed in the
first place and used more expensive task-partitioning mechanisms, and
applications that can increase their CPU utilization by adding
threads. The latter are actually relatively rare. They include
CPU-bound programs running on SMP systems, and some programs that can
better overlap I/O and processing using threads - but there's usually
a non-threaded way of achieving that with lower overhead.
Adding threads usually decreases performance for a well-written
application. It adds context switches. It increases memory
consumption and decreases locality of reference. It adds synchron-
ization overhead. This is all well understood.
The case Richard mentioned of a web server using one thread to service
each request is a classic example of a poor application of multi-
threading, for example. (It comes up on comp.programming.threads
periodically.) It's far more efficient for the server to multiplex
I/O - preferably both network and file I/O, if the OS supports that -
since it's almost entirely I/O bound. The server can wait for any
I/O event: new conversation, data available from client on existing
conversation, client ready to receive on existing conversation with
pending response data, file I/O ready, and so forth, and service
each event as it fires. Unless there are multiple CPUs, threading
such a server just slows it down. (In some cases it's worth starting
a thread to process events that may have unanticipated delays, to
avoid latency in the event loop; and on some OSes it's necessary to
add some concurrency because of OS scheduling or queuing deficiencies.
But in general thread-per-connection is a bad idea.)
> It's not about keeping users separated; it's about processing a query in
> parallel for speed.
There's no speed benefit unless CPU consumption can be increased,
which is generally only the case with SMP.
--
Michael Wojcik michael.wojcik@microfocus.com
_
| 1
| _______ d(cabin) = log cabin + c = houseboat
| (cabin)
_| -- Thomas Pynchon
| |
| docdwarf@panix.com 2004-05-25, 5:30 pm |
| In article <40b304fa.212092913@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>riplin@Azonic.co.nz (Richard) wrote:
>
>
>I saw that today. The code for calling is not a problem, but the code for
>_receiving_ a call is.
An unreceived call is of... questionable use for any sort of processing,
Mr Wagner; common use might cast doubt as to whether an unanswered call is
a call at all. Consider:
'Did you contact him about the change in plans?'
'I sent an email; I tried to call but there was no answer.'
>
>
>It was a trial baloon. You and WK disliked it; others were silent.
Trial aside, dislike aside, silence (not equal to assent) aside... your
claim was, it seems, proven incorrect.
>
>
>Drat. My proclivity to be a control freak has been exposed.
Some might deem it apropriate to insert a ', yet again' before that last
period/full stop there.
[snip]
>I never questioned your knowledge. You question mine all the time, including
>areas where it should be obvious I've been.
A difficulty might be, Mr Wagner, that you state with what appears to be
equal force and certainty those things about which you have knowledge and
those things which - as demonstrated above - rather simple experiments
demonstrate conclusions contrary to your assertions.
[snip]
>
>Fair comment. No, I don't have it at home but do at work. I looked at its OO
>features yesterday afternoon, found the syntax easy to understand. Methods are
>just nested programs. My next demo will be OO.
The form of a sonnet is 'easy to understand', Mr Wagner... but there is a
bit of an interchange between Oronte and Alceste in Moliere's
'Misanthrope' which might prove instructive. You say you've considered
these features for a whole quarter-hour?
[snip]
>
>You're trying to solve today's problems with solutions you developed in the '80s
>and early '90s, when programmers had to hold the machine's hand and alter their
>style to cope with its inadequacies. Those days are gone. Machines now have 16G
>of real memory and gobs of on-ship cache.
>
>When I do a Cobol compilation for the first time, it takes about a second. When
>I do subsequent compilations, they take milliseconds. The whole compiler is in a
>cache.
Platform? When I do a compile, Mr Wagner, I submit JCL and wait for a
message like JOB34577 $HASP165 WSXCOMPL ENDED AT NIHJES2 MAXCC=4
CN(INTERNAL) to flash across my screen. You may criticise my client for
usin such ancient technology... but my client wishes to have archaic and
eat it, too; after I make my suggestions and receive a 'That's
interesting, we'll get back to you on that' I go back to doing the job in
the manner my client has indicated it would like to see.
DD
| |
| Richard 2004-05-25, 6:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> I saw that today. The code for calling is not a problem, but the code for
> _receiving_ a call is.
The 'receiving' code is to do exactly what the compiler manual says it
will do: set up LOCAL-STORAGE (and possibly initialise it), set the
instance PERFORM stack, ... But the CALL is also part of the problem
because it isn't direct linked as nested programs will be. ENTRYs can
be accessed from outside and so they will be in the call table in the
run-time and this requires a search for them.
>
> It was a trial baloon. You and WK disliked it; others were silent.
No. You made specific, alegedly technical claims that certain things
were _required_, and that this was _better_ and _faster_.
>
> I spent a year doing Accenture FCP (Foundation Control Program), which
> received messges via callbacks.
A simple 'no I haven't' is all you need say.
> I never questioned your knowledge. You question mine all the time, including
> areas where it should be obvious I've been. For instance, I say I wrote an OO
> operating system and you talk as though I'm an OO neophyte.
It is obvious where you have been, and where you have not. It was
obvious you hadn't been into Windows inner workings, or tried your
idea on any other compiler, or learnt from the progression of B to C++
to Java over 35 years, and many other things.
>
> All compilers will have the equivalent of reentrant(2), where every thread is
> sealed up, not sharing memory with other threads. I'm not positive they have
> reentrant(1), which is true multithreading.
Which 'all compilers' are you referring to ? Does 'will' mean 'will
in the future' ? If you are saying 'does' then you are not correct.
REENTRANT(n) appears to be quite recent with MF. Previously a program
was marked re-entrant (or recursive which is self-reentrant) when it
had LOCAL-STORAGE and that equates to having just one W-S but a new
L-S for every re-entry.
You seem to think that all these things are for multi-threading when
the features were for something else and threads are imposed on top of
this.
> Fair comment. No, I don't have it at home but do at work. I looked at its OO
> features yesterday afternoon, found the syntax easy to understand. Methods are
> just nested programs. My next demo will be OO.
So you _are_ a neophyte in Cobol OO.
> I didn't say they were flaky. They're leak-proof and the ONLY way to get
> expected performance.
Perhaps I misunderstood this:
*> Check again for collision not caught above. If detected, the locks
*> are not 100% leak-proof. This demo detects no tertiary collisions.
> If you have to call thread functions such as mutex, you're
> better off single-threaded.
If there is no actual benefit from multi-threading then one is better
off single threading.
> You're trying to solve today's problems with solutions you developed in the '80s
> and early '90s, when programmers had to hold the machine's hand and alter their
> style to cope with its inadequacies. Those days are gone. Machines now have 16G
> of real memory and gobs of on-ship cache.
This seems to be a completely unrelated rant that has no bearing on
the issue.
Fujitsu, for example, has a complete mechanism for doing
multi-threading where it is actually beneficial, for example for
Web-serving. They explain how it is done and what needs to be catered
for.
It is your approach that I see as 'what was done in the 80s',
especially with your very low-level code to cope with locks.
Your approach is also very much to single-tasking, promoting your own
one program as being what the machine should be dedicated to. Very
70s. The benefit you claimed was that your one program could use all
4 CPUs at the same time, the system should read all of your files in
when you open them so that _your_ _one_ program can benefit from using
all the RAM and CPU, even if it means that your program will several
times the total CPU cycles.
_Modern_ (since the 70s) systems have the throughput maximised, not
that of one program, even if it has been written by a self-styled
'real programmer'.
>
> Sounds like the thread managers you've used made every thread reentrant(2).
> That's a wasteful solution
It is as if you deliberately completely miss the point.
You had made claims about a 'candidate' program. When it was pointed
out that there was only one FD and this had to be shared, you 'solved'
it by saying use REENTRANT(2). Yes, it was a complete bloody waste of
time, but it was _your_ stupid 'wasteful solution'.
In any case while REENTRANT(2) may well create a separate data area it
is not assured that the FD can be used two or three times for separate
files at the same time.
So not only do you, once again, suggest 'wasteful solutions', but ones
that may not even work.
| |
| Richard 2004-05-25, 10:30 pm |
| mwojcik@newsguy.com (Michael Wojcik) wrote
> The server can wait for any
> I/O event: new conversation, data available from client on existing
> conversation, client ready to receive on existing conversation with
> pending response data, file I/O ready, and so forth, and service
> each event as it fires.
Certainly a program can do this if it works at a low enough level and
handles interrupts directly, or can get the OS to block on enough
services, or polls.
One case where I have had to resort to multi-threading (or
multi-tasking on shared data and code segments) is where the OS could
only block on each resource separately. I needed to monitor two ports
which operated asynchonously and buffer all the data between them. I
could have polled and used up all the CPU, or hooked interrupts, but
these were shared and managed by the OS. The simplest solution was to
have two threads, each using blocking I/O OS calls.
You may well call that a poor OS design that required me to do that.
I expect that, at least to some extent, a server may be in the same
position. As the concurrency increases it becomes increasingly
difficult to ensure that you get each 'firing', unless it has control
over, say, the disk i/o queue.
| |
| Joe Zitzelberger 2004-05-26, 12:30 am |
| In article <c8vrev016go@news1.newsguy.com>,
mwojcik@newsguy.com (Michael Wojcik) wrote:
> In article <40b0ccfe.66666851@news.optonline.net>,
> robert.deletethis@wagner.net (Robert Wagner) writes:
>
> Neither of those statements are particularly felicitous.
>
> In Java, all code has to be part of a class method, but a class is
> not the equivalent of a program. The Java language does not define
> "program", AFAIK, so it's not entirely clear what would constitute a
> Java program; in particular, it's not clear how the component models
> defined by various Java standards (Javabeans, EJBs, and so forth)
> relate to "program" either as it's popularly used, or in the special
> COBOL sense. However, Java applications and applets (applications
> which run in a JVM that's hosted within another application) are
> probably similar enough to what's usually understood by "program" to
> qualify for the latter.
>
> Given that, a Java "program" in the popular sense is a collection of
> one or more classes, at least one of which must have a public "main"
> method, which will be the starting point of execution if that class
> is the one being invoked to start the program.
I've got to chime in here. There are 'class methods' and then there are
'Class Methods'. Your usage seems to indicate that a 'class method' is
simply a method that is defined in a given class. The well-defined
'Class Method' is a static method that can be used without in instance
of the class.
A Java program is a well-defined entity. Any class that contains a
'Class Method', or static method called main is a complete, standalone,
program. Any class that does not is not a complete, standalone, program.
This is very similar to some Cobol compilers that require a "main"
program to create and initialize their runtime and then allow that main
to call any number of subprograms. (and thus we come full circle to the
STOP RUN -v- GOBACK debate...)
| |
| Robert Wagner 2004-05-26, 2:30 am |
| mwojcik@newsguy.com (Michael Wojcik) wrote:
>Of course it's possible to write COBOL in a Java-like fashion, with
>multiple entry statements per module (as Robert is | | |