Re: COBOL's Influence on C

On Nov 14, 1:18 pm, 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?

It is certainly _not_ a bad idea. It is also not true that abort is
the only option. Simply because you have never discovered how to
exploit it to build dynamic systems does not make it bad.


.

Relevant Pages

  • Re: COBOLs Influence on C
    ... The target of a Cobol CALL can be in the same source or it can be external. ... learn of missing external names either at link or execution time. ... On Unix, you can check for missing externals by running "ldd -r ', both after ... compilation and before execution. ...
    (comp.lang.cobol)
  • Re: COBOLs Influence on C
    ... The target of a Cobol CALL can be in the same source or it can be ... learn of missing external names either at link or execution time. ... you can check for missing externals by running "ldd -r ... compilation and before execution. ...
    (comp.lang.cobol)
  • Re: COBOLs Influence on C
    ... Cobol, along with most compiled languages, is the same. ... 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 (or Unix et al), ...
    (comp.lang.cobol)
  • Re: COBOLs Influence on C
    ... Cobol, along with most compiled languages, is the same. ... learn of missing external names either at link or execution time. ... you can check for missing externals by running "ldd -r ... compilation and 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)