Re: May I introduce myself to cobol?...

From: Peter E.C Dashwood (dashwood_at_enternet.co.nz)
Date: 02/16/05 

Date: Wed, 16 Feb 2005 23:35:15 +1300

"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1108526697.928623.234600@g14g2000cwa.googlegroups.com...
> Well, declaring variables in cobol programs is a Major job, you need to
> define the correct
> type, the correct size, the correct location (working storage section,
> local section and
> linkage section), and you need to define all these variables with
> descriptive names --- so
> you can remember them when you are coding the main logic in the
> procedure division.
> most programs (Real World Applications) make a large number of calls to
> the win32 AP's
> system ---- so, if you can reduce the number of declared variables
> (overloading functions),
> it will make the program much smaller in size, and therefore will run
> much faster, and
> that should improve the performance of the application. Right? Also,
> if we can perform
> two functions simultaneously (overloading) that should save CPU
> execution time as well.
> most C++ programmers claim that cobol have a major problem with
> Prolixity, too Verbose
> and very Wordy language --- so, why declare a storage in memory when we
> can have the
> win32 API function use a temporary location on the stack, while
> executing that function?
> this way, we can hit two birds with one stone, and silence our critics.
> :--) am I correct?
>
No Kellie, you are not strictly correct on this occasion. (But you are not
totally wrong either :-))

Read Richard's explanation again. (I found it informative and interesting)

As to why you are not 'correct' consider this:

1. Most application programs do NOT make a large number of calls to the
API. This is manipulated by another layer, often provided by a third party
supplier. By tying your program directly to the API (rather than to an
abstract layer) you are sentencing it to life with ONE operating system.
That's why we use multi-tier systems and multi-tier design. Separate the
business logic from the 'presentation' layer. How do you do that?... make
your application code communicate with a memory buffer that 'represents' a
window or screen display. This is an interface to the presntation layer.

2. Your observations about defining data in COBOL are right on the button;
it IS tedious... BUT it takes no more space at run time than any other
method in any other language. I think you may be confusing source code and
runtime object code here.
Do not incorrectly assume that because data is pushed on the stack it does
not occupy space in memory. Where do you think the stack is? :-)

3. Making a program smaller in size (by overloading functions, or any other
way, short of removing code that it currently executes) does NOT guarantee
that it will run faster. It will load faster (although the difference would
be impossible for a human to detect). The time it takes to run will be
determined by the execution path (the capture time), not by the size of it.
(I covered this in an article about components some time ago; here's a link:
http://www.aboutlegacycoding.com/archives/v3/v30201.asp

4.Overloading a function does not necessarily allow it to execute
simultaneously with another instance of itself. This will be determined by
threading models and instantiation, not by overloading.

Hope this helps.

Pete.

> Regards, Kellie.
>
>

Relevant Pages

  • Re: Starting MPD on a multicore processor machine
    ... it gives the error: "problem with execution of ... try something like "mpirun -np 4 pwd" to find out what is the current working directory. ... Then you can specify the correct location of your executable file. ...
    (comp.parallel.mpi)
  • installation SQL 7 on 64-bit itanium
    ... I have read about the IA 32 execution layer... ... Tim Derriks ...
    (microsoft.public.sqlserver.setup)