Re: COBOL's Influence on C

It might (or might not) be of interest to point out that for IBM mainframe
compilers, compiling with NODYNAM is documented as making your program "not ANSI
conforming". The reason is an "odd" one, i.e. for IBM (mainframe - at least
MVS-ish), when you compile with NODYNAM, the CANCEL statement (if present)
becomes a "NO-OP" and called programs are (without the IS INITIAL clause) are
always reached in "last used state".

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@xxxxxx> wrote in message
news:ii4qj31jest077scok4e6mo40njbjda9o3@xxxxxxxxxx
On Fri, 16 Nov 2007 10:37:41 +1300, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:



<snip>>
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.

I think late binding is one of the best things in COBOL, and strongly
disagree it is a "bad idea" :-)

I didn't say late binding is a bad idea; I said undeclared EXTERNALs are a bad
idea.

You can do late binding in Cobol without calling through a data name. It's a
compiler
option. On IBM, you say DYNAM; on Micro Focus, you say -z; on Fujitsu, you
say -dy.

Cobol did not invent late binding. It's an operating system feature.

In both OO and procedural implementations, the flexibility this affords far
outweighs any slight inefficiency, in my opinion.

Small, modular, component based systems, NEED the flexibility this affords,
in order to be responsive. Depending on user selection, code is loaded as
needed. Cool!


First, it usually slows every call, not
just the first.

Don't care. And disagree that subsequent calls are slower once the required
module has loaded.They certainly will be if you keep cancelling your loaded
module, but the days when we needed to do that are long gone.

Again, you are confusing late binding with undeclared EXTERNALS.

A late bound call, after the first, is not slow because its only overhead is
checking
whether a pointer is null

A call through data name IS slowed because it must do a string compare to see
whether the
program name changed since the last call, then figure out which of multiple
possible
pointers belongs to that particular program.

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.

With early bound OO COBOL the compiler will check for compliance and that
the parameter lists conform to the requirements of the called component;
with late bound, as you point out, it cannot. But, if you REALLY care about
this (and I don't...) then there is nothing to stop you adding a prototype
for your late bound call and this will be validated against the Repository.
(At least, it will if you use Fujitsu...)

You can't use a prototype when CALLing (non-OO) through a data name and you
can't INVOKE
a method through a data name. All EXTERNALs must be declared in OO Cobol.
Thank you for
supporting my argument.

From procedural COBOL on mainframes using dynamic linkage, to OO Components
on the Network, I have used late binding for decades and found it powerful,
flexible, and useful. No way, is this a "bad idea"...

I too have been using late binding for decades.

Traditionalists dislike late binding because they're afraid someone will
change a function
without retesting every blasted application that calls it. Their idea of
reusable code is
copy-and-paste.


.