Re: COBOL's Influence on C

Robert's reply seems to "assume" an IBM mainframe environment. Most of what he
says MAY be available in other environments, but may not be universally
"relevant".

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Jones" <rjones0@xxxxxxxxxxx> wrote in message
news:1195079026.976230.183910@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Nov 14, 7:54 pm, "Frank Swarbrick" <Frank.Swarbr...@xxxxxxxxxxxxxx>
wrote:
On 11/13/2007 at 5:18 PM, in message
<snckj3564s4rjul5ctvffht6imaih84...@xxxxxxx>, Robert<n...@xxxxxx> wrote:
On Tue, 13 Nov 2007 12:47:57 -0600, "tlmfru" <la...@xxxxxxx> wrote:

Robert <n...@xxxxxx> wrote in message
news:dsmhj317b7236kep9l7j2i53jp39dcvlo6@xxxxxxxxxx
On Mon, 12 Nov 2007 10:19:38 -0500, "Rick Smith" <ricksm...@xxxxxxx>
wrote:

Modern BASICs also use conditions in the SELECT CASE
statement and may have been influenced by COBOL. <g>

Speaking of modern BASICs ...

GOSUB, which is the same as Cobol's out of line PERFORM, has been
depreciated by many/most
compilers and dropped from VB.NET. It was replaced by SUB, which is a
local function
call. In my opinion, Cobol should have done the same.

In my opinion and usage, the word SUB, short for SUBroutine, refers to a
stand-alone piece of code not included with the source program under
consideration. (It can certainly be in the same compilation unit, of
course). A function in this context is some common routine which isn't
compiled (I say this to keep OO vocabulary out of the discussion),
usually
supplied by the compiler writers: e.g., calls on the OS. There should be
a
completely different verb to execute sections of code within the source
program as opposed to that used to execute wholly external sections.
COBOL's PERFORM does the first perfectly well - unambiguous,
understandable - and CALL (or INVOKE, etc.) does the second: and neither
can
be mistaken for the other. Why change?

The target of a Cobol CALL can be in the same source or it can be
external.

In PROGRESS, a language I have little love for but have had to use quite
a
bit, the in-line perform is WHILE, and the out-of-line perform is RUN:
but
RUN is also used as the CALL. If the label isn't defined within the
current
source, it's assumed to be an external routine: no precautionary
diagnostic.
So it's very common to have a clean compile which then blows up with
unresolved linkages when attempting to execute. Not the same situation
as
what Robert's suggesting but a cautionary tale.

Cobol, along with most compiled languages, is the same. Depending on
linker options, you
learn of missing external names either at link or execution time.

Unlike most compiled languages, Cobol lets you CALL a name stored in a
variable. That kind
can only be bound at execution time. The calling program can handle
missing names with an
ON condition, but it's usually too late to do anything but abort. I've
never really needed
that feature. It is a bad idea for two reasons. First, it usually slows
every call, not
just the first. Second, the linker/loader nor tools like ldd cannot
check those references
because they don't know what value will be in the variable at execution
time. It's usually
a constant, but there's no way to declare that.

On Unix, you can check for missing externals by running "ldd -r
(program)', both after
compilation and before execution. Do z/OS or CA-7 have that ability?

I don't have much Cobol experience on the PC (or Unix et al), but on the
mainframe we use dynamic calls (CALL data-name) almost exclusively. While
I'm sure a static call is faster, we've never had a performance issue. It's
very nice to be able to change a subroutine and not have to do a static
relink of all calling programs.

Frank

The term dynamic can get very confusing at times. If you use CALL
data-name the call is always dynamic, while if you use CALL literal,
it may or may not be, depending upon your compiler and consequent
linkage editor or binder options. It has been possible to do dynamic
calls with both CALL literal and CALL data-name from the late 1970s.

The difference in performance between dynamic and static linkage is
insignificant, unless one is also repetitively cancelling dynamically
called program. One would expect an overall performance improvement
in a multitasking environmnet due to the lack of need for multiple
copies of all the COBOL language subroutines in memory, which should
reduce the amount of paging required. However, if one wants to run
multiple instances of the same COBOl program at once, then the user
written subroutines can't be in the link pack area (I have a feeling
that is called the RRR (I don't know what it stands for, perhaps
resident routines region?)in DOS/VSE), but they can still be invoked
from the JOBLIB and STEPLIB library specs.

Anyone care to elaborate?



.

Relevant Pages

  • Re: COBOLs Influence on C
    ... Consider most programs are compiled within a "development" environment, ... 'availability' of called files totally different in 'development' versus ... That's why I said "after compilation and again before execution." ...
    (comp.lang.cobol)
  • Re: COBOLs Influence on C
    ... learn of missing external names either at link or execution time. ... compilation and before execution. ... I don't have much Cobol experience on the PC, ...
    (comp.lang.cobol)
  • Re: huge array
    ... or do you know a CPU which can handle something like "FOR I = 1 TO ... The dot net JIT compilers *do* interpret pseudo code (or whatever ... parsing and execution are two separate steps. ... compilation happens in two phases ...
    (microsoft.public.vb.general.discussion)
  • Re: huge array
    ... or do you know a CPU which can handle something like "FOR I = 1 TO ... There is a huge difference between interpeted code and native code. ... parsing and execution are two separate steps. ... compilation happens in two phases ...
    (microsoft.public.vb.general.discussion)
  • Re: cxx performance
    ... > Yes, the real performance lies in execution, but when executing the TDD ... > grand total of much lost productivity over a day. ... I assume that you are being sarcastic about comparing ... > me - I was looking for ways to speed up the compilation in the current ...
    (comp.os.vms)
Loading