COBOL compilers for parallel computers? 
Author Message
 COBOL compilers for parallel computers?

Does anyone know whether there are any COBOL compilers
running on parallel computer systems (and taking advantage
of the multiple processors, e.g. by running PERFORMs or
statements like SORT in parallel)? What about performing
I/O in parallel?

Any info or pointers appreciated.

Cheers,

--rizos



Sun, 27 Jun 1999 03:00:00 GMT  
 COBOL compilers for parallel computers?

Quote:

> Does anyone know whether there are any COBOL compilers
> running on parallel computer systems (and taking advantage
> of the multiple processors, e.g. by running PERFORMs or
> statements like SORT in parallel)? What about performing
> I/O in parallel?

Probably the only one that comes close is Tandem's.  You can run
parallel sorts using up to seven different processors and SQL
statements use multiple processors.  Because of the way the COBOL
language works, it is impossible to run PERFORM statement in parallel
or much of anything else either for that matter.  It is a simple
matter to fire up other COBOL programs in other processors and
communicate with them with the whole mess running in parallel.  I
suppose you could say that some I/O is done in parallel because when
Tandem COBOL does some I/O statements it starts up action on the next
one and the action for that is normally done in another processor.  
This doesn't work for random operations and other operations that are
not sequential in nature.

--
Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees

No clever quotes here



Mon, 28 Jun 1999 03:00:00 GMT  
 COBOL compilers for parallel computers?

Quote:


>Subject: Re: COBOL compilers for parallel computers?
>Date: Thu, 09 Jan 1997 10:11:11 -0800

>> Does anyone know whether there are any COBOL compilers
>> running on parallel computer systems (and taking advantage
>> of the multiple processors, e.g. by running PERFORMs or
>> statements like SORT in parallel)? What about performing
>> I/O in parallel?

>Probably the only one that comes close is Tandem's.  You can run
>parallel sorts using up to seven different processors and SQL
>statements use multiple processors.  Because of the way the COBOL
>language works, it is impossible to run PERFORM statement in parallel
>or much of anything else either for that matter.  It is a simple
>matter to fire up other COBOL programs in other processors and
>communicate with them with the whole mess running in parallel.  I
>suppose you could say that some I/O is done in parallel because when
>Tandem COBOL does some I/O statements it starts up action on the next
>one and the action for that is normally done in another processor.  
>This doesn't work for random operations and other operations that are
>not sequential in nature.
>--
>Don Nelson
>COBOL Development, Tandem Computers, Inc.
>Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees

>No clever quotes here

hmmmmm, does NCR still make its 9800 series parallel processors? They also
functioned very similar to the way Don describes the Tandem. The O/S would
automatically partion app logic into one processor and I/O to another. As
well, you could use MCS to "partition" your app into multiple tasks across
various processors.

Peter Clark



Tue, 29 Jun 1999 03:00:00 GMT  
 COBOL compilers for parallel computers?

Quote:

>Does anyone know whether there are any COBOL compilers
>running on parallel computer systems (and taking advantage
>of the multiple processors, e.g. by running PERFORMs or
>statements like SORT in parallel)? What about performing
>I/O in parallel?

>Any info or pointers appreciated.

>Cheers,

>--rizos

There have *nearly* always been outboard / channel processors for I/O.
In fact the old RCA BIZMAC of the early 1960's had seperate sort
processors.  The CDC 6600 with many outboard 160A's was a

While there have been compilers that inspect code for independance to
allow some method of parallelism like a fortran variant for the
special Illiac IV,  there has been only limited task splitting using
FORK, JOIN, SYNCHONIZE, WAIT as compiler verbs that would leave the
parallelism decisions to the programmer rather than the compiler.

With client server technology (more to the point, intellegent
data-base servers) being continuously improved, non-homogeneous
parallel processing may be now leapfrogging the parallelism you are
interested in without the demand of the programmers advanced planning.

Most business sites would probably be running multiple programs which
would interfere greatly in the efficient parallel processing of just
one of the programs, just as certain vector processors (allowing some
parallelism) can only run one *job* at a time (by the way, because of
the hugh time expense at vector setup, the vector process is often not
interruptable, unless there are an enormous amount of registers).

The vector processors are often coupled with *normal* processors to
handle timely interrupt processing.....

.........whoops...what was that question again?

The does not terminate the need for the large parallel 'arithmetic /
logical' processors used for wind-tunnel simulation, weather
prediction and cartoons.

JR
and stir with a Runcible spoon...



Wed, 30 Jun 1999 03:00:00 GMT  
 COBOL compilers for parallel computers?

Quote:

> There have *nearly* always been outboard / channel processors for I/O.
> In fact the old RCA BIZMAC of the early 1960's had seperate sort
> processors.  The CDC 6600 with many outboard 160A's was a

I'm not too sure what the rest of the sentence was supposed to be, but
I assume it was about "outboard" processors.  The 6600 did not have
outboard 160As.  While the peripheral processors (10 in the basic
configuration - up to 20 extended) were similar to 106As (12-bit words
and so on), they were an integral part of the system and had several
instructions 160As did not have.  The 6600 also had 10 functional
units that ran in parallel - you would probably call them parallel
processors.  The COBOL compiler (I worked on all of the COBOL
compilers for the 6600) and all the other compilers optimized code so
that the processors would work in parallel as much as possible.  For
example, if you wanted a word you would initiate a load and while that
was going on you would do a multiply or add with some data you had
started loading before, meanwhile storing something else.  It was
great sport.

Quote:
> While there have been compilers that inspect code for independance to
> allow some method of parallelism like a Fortran variant for the
> special Illiac IV,

The CDC FORTRAN compilers for the Star and other parallel processors
did this too.

Quote:
> there has been only limited task splitting using
> FORK, JOIN, SYNCHONIZE, WAIT as compiler verbs that would leave the
> parallelism decisions to the programmer rather than the compiler.

Many did not use such archiac stuff.  A CDC implementation used simple
COBOL statements and a semiphore method based on the CODASYL COBOL
Committee proposal on asynchronous processing (which never passed and
was never added to a standard - I wrote a goodly part of it).  This
was for a giant Air Force logistical system.  It worked, too.

Quote:
> With client server technology (more to the point, intellegent
> data-base servers) being continuously improved, non-homogeneous
> parallel processing may be now leapfrogging the parallelism you are
> interested in without the demand of the programmers advanced planning.

Tandem has had client/server for 20 years.  One COBOL server can
handle lots of clients (written in a COBOL dialect called SCOBOL that
is essentually the screen handling stuff in MF and other COBOLs).  
Although the programmer has to use advanced planning, it is quite
simple and fits in well with COBOL.  The closest thing in the standard
is the Message Control System (MCS).

Jeff's response was very good and right on.  I just wanted to fill in
a few spots, not take exception to anything he said.

--
Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees

No clever quotes here



Sat, 03 Jul 1999 03:00:00 GMT  
 COBOL compilers for parallel computers?

Another set of design parameters were being discussed at a Guide/Share
joint committee (IBM users) for input to the ANS standards committee
(a long while ago.)  This included data communication without
multi-tasking (not necessarily parallel processing).  Fun for a COBOL
based message system.

As Don has indicated, we have LOTS of standards.

JR
and stir with a Runcible spoon...



Sun, 04 Jul 1999 03:00:00 GMT  
 COBOL compilers for parallel computers?

Quote:

> Because of the way the COBOL
> language works, it is impossible to run PERFORM statement in parallel
> or much of anything else either for that matter.

I'm not quite sure about this. I understand that this doesn't happen
but it seems to me feasible... For instance, a PERFORM XXX N TIMES
statement may be translated as different processors executing XXX
in parallel, for different values (assuming that different executions
of XXX are independent of each other); a typical example would be the
addition of two arrays. All needed to exploit this form of parallelism
(how much can be gained is a different issue) is just some compiler
support, isn't it?

--rizos



Tue, 06 Jul 1999 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Ada Compilers for Parallel Computers

2. Mikro Focus Cobol Compiler 3.0/ Personal Cobol Compiler 2.0

3. Something else for a change / Parallel Computer for APL - in case you didn't know

4. Forth for parallel computers?

5. Workshop on Compilation of (Symbolic) Languages for Parallel Computers

6. need information for Monte Carlo algorithm for parallel computers

7. PROLOG on Parallel Computers, T-3D or CM-5

8. Parallel computer access?

9. Workshop on Compilation of (Symbolic) Languages for Parallel Computers

10. SISAL as Intermediate Language for parallel compilers

11. Ada compilers for parallel platforms

12. Ada compiler for parallel computin on a PC?

 

 
Powered by phpBB® Forum Software