Re: COBOL's Influence on C

On Fri, 16 Nov 2007 11:20:25 +1300, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:



"Robert" <no@xxxxxx> wrote in message
news:ao5nj3htd2qp1g6p1r7r2c8pvmp8556ul5@xxxxxxxxxx
On Wed, 14 Nov 2007 00:55:56 -0800, Richard <riplin@xxxxxxxxxxxx> wrote:

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.

This issue requires a rant on the inadequacies of programming language
designers. They
cause UNINTENDED CONSEQUENCES because they think like programmers rather
administrators.
Two examples are fresh in my mind because I'm fighting with them right
now.


I would have severe resevations about using a programming language designed
by Administrators.... :-)

A language designed by administrators would make you do all the work, it would decide what
went through and what got rejected. Hmm, maybe they ARE designed by administrators. :)

Picture a very large shop that runs hundreds of thousands of batch jobs
that execute
millions of programs every month. Imagine an administrator writing
automated
'verification' of those jobs BEFORE they run, so errors can be fixed
BEFORE the jobs blow
up in production. The existance of data files is the easiest thing to
check. What about
the existance of program files (verifying they are the correct version is
the next step)?

This should be a "write once" exercise by a team of people who know
something about JCL... It doesn't matter how many millions of programs are
being used, they get invoked by a Job Control language of some kind, and
that's where the problem should be addressed.

The top level program is named in JCL or script, the child programs it calls are not.

Your bitch is that with dynamic calling they can't know what will be loaded.
How is that the fault of the language designers?

Cobol is the only language that has this problem. Other compiled languages reveal the
names of their children as EXTERNALs.

Leaving that aside for a moment, there must be approaches that can provide a
"skeleton" JCL procedure, or set of JCL (or equivalent) for ANY program
that is doing dynamic calling. If you can't know what is being called, then
you can't pre-check individual load module names/versions, but, you CAN make
sure that the libraries containing ANYTHING that might be called are on line
to the job.

p: Why didn't you run my job last night?
a: The verifier said Maestro was not available.
p: What the hell is Maestro?
a: Something to do with the Mars Rover.
p: My job runs payroll. It doesn't use Maestro.
a: How are we supposed to know? Maestro is on the library list.
p: What else is on the library list?
a: Thousands of libraries.
p: The only library I use is a check formatter.
a: See, there you go. We can't run your job until ALL libraries are available.

Shop Programming Standards can ensure that every program logs
itself and its version when loaded, if that is a concern, so there is an
audit trail if required.

The scheduler is capable of logging jobs and programs. It doesn't depend on every program
to "log itself".

The problem is jobs aborting because of missing programs. Keeping logs does nothing to
address that problem.

There are always solutions, and they don't
necessarily involve analysing load modules to obtain symbols...

Let's send an email to the programmer, asking that he 'verify his job'. If it crashes,
fire him.

You should be in management. You have a knack for finding alternative solutions that don't
really address the problem, but make us feel vindicated.

Unix's ELF standard and the aforementioned ldd (LoaDer Diagnostics) tool
makes it easy to
verify the existance of called programs, recursively checking for ALL of
them. It works
for every language EXCEPT Cobol (and other programs calling dlopen()
directly, which is
rare). Why do Cobol programmers need the flexibility to determine the
names of child
programs at execution time? In the vast majority of cases, they don't.

Who are you to decide what COBOL programmers need or want? :-)

I are one. :)

The people who designed the language needed to cater for every possible use
they could reasonably envision.

They overlooked very large Unix and mainframe shops. Who would have thunk Cobol would be
used in such places?

Your site has exceptional needs.

We run batch jobs that go bump in the night. Is that exceptional?

Nevertheless, the facilites exist to meet even those needs. It is just a
question of looking at various approaches, and taking a wholistic view; not
just a language based one.

You forgot to say Think Outside The Box. Have you evr noticed .. people who use that
phrase often are the ones most in need of their own advice. :)

A few creative
programmers will write 'dynamic systems' driven by decision tables (or
similar) stored in
databases, from which they get the names of child programs. That allows
them to add child
programs without having to recompile the parents .. provided someone
installs the child
program BEFORE putting its name into the database. That's fine for small
systems with a
small number of users. The programmer will personally install the child
program. It
doesn't work when there are dozens to hundreds of machines. Worse, the
list of child
programs is in a NON-STANDARD location unknown to a general verification
tool. Each
creative programmer will design a DIFFERENT location. One might put the
list in a load
module, one in a database, one on his laptop's floppy mounted via NFS.

And that is one reason why installations have Local Standards... To ensure a
consistent approach.

We have software acquired from four major companies when we bought them. Each had its own
multiple standards -- one for mainframe, another for Unix, yet another for Java.

The nice thing about Standards is there are so many to choose from.

(Actually, most of the dynamic systems I have worked with or designed, DON'T
use a list of possible candidates for calling. Instead they CALCULATE the
name of the needed module. This is possible because the standards require a
certain naming convention, and program names are carefully controlled and
allocated in accordance with that convention. A given module name will
indicate what it does, and which sub-system it applies to...)

Ah, the old Naming Convention Standard is the solution. All we have to do is get the list
of Duly Authorized Programs and make sure they're all present and accounted for.

p: NOW why didn't you run my job?
a: Because program PRFUBAR1xT is missing from the library.
p: The FUBAR system was shut down five years ago.
a: Someone must be using that function. It's still on the list.
p: Can you see who's using it?
a: Here it is. PRONESH8aA needs it.
p: When did it last run?
a: Three years ago. It says On Demand.
p: You held my payroll job because of a three year old one shot program?
a: Hey, I'm just following the rules.

This is anarcy.

It is anarchic only if you expect conformance with ONE specific approach...

Flexibility CAN become anarchic if it isn't controlled, that is why it is,
for the most part, controlled.

What about the hundreds of production programs (out of 10,000s) on which none of the
multiple standards was enforced? We tried ignoring them, but they didn't go away.

In order to verify programs, I need ALL externals stored in ELF headers.

That is a requirement that is extremely specific and nothing to do with
COBOL.

Yes it does. Cobol programs have many many undeclared EXTERNALs. Other languages have
almost none. The reason is Cobol ENCOURAGES call through data name because of fuzzy
thinking about the meaning of 'dynamic call'. It thinks run-time binding is synonymous
with run-time determination of program name. Other languages require you to declare all
the programs you might call.

For Cobol programs calling via variables (data-names), I have to extract
the VALUE from
the data-name definition, look for MOVE 'prognm' TO DATA-NAME, use the
values to build a
dummy object that gets linked into the executable so the program's child
names are in its
symbol table. THIS SHOULD NOT BE NECESSARY.

It isn't. You find it necessary because of a specific approach you have
CHOSEN. A guy as bright and imaginative as you, Robert, could certainly find
alternative approaches. I reckon you're just not trying... :-)

On Unix, the only way to call an undeclared EXTERNAL is by calling the OS API function
dlopen() with the program's name. Cobol does this under the covers. Any language can, but
it's rare for the others. I could front-end that function, collecting history in a
database. After a few months, I'd have roughly 98%, and the database would keep getting
better. Seems like a lot of overhead for one language.

If someone on the Cobol Standards Committee
had known the requirements of LARGE systems, the language would make a
distinction between
dynamic binding (a good thing) and dynamic determination of called program
name (a bad
thing).

Nothing is Good or Bad, but thinking makes it so.


------

My second gripe is over nested COPYs. The '85 Cobol Standard says they are
not allowed.
The unintended consequence of that stupid restriction is that our builds
take 18 hours
rather than 2 hours.

Very short sighted for a committee to not foresee (over twenty years ago)
that there would be this "unintended consequence" from what they decided...
:-)

Can you name any language or compiler that does NOT support nested include/copy?

RPG doesn't count.

Here's why. We don't write copybooks manually, we generate them from
data dictionaries, for several languages -- .h files for C, .cpy for
Cobol. We produce
separate copybooks for 88 levels and for types. A Cobol type looks like
"pic x(10)". The
top level copybook for a structure looks like:
05 customer-number copy custno.typ..
05 customer-status copy status.typ..
copy status.val. *> contains 88 levels

Because the '85 Cobol Standard says nested COPYs are a no-no, we run a
pre-pre-processor
that combines the nested COPYs into a single one, which looks like this:
custrow.cpy:
05 customer-number pic x(10).
05 customer-status pic x(01).
88 active value 'A'.
88 cancelled value 'C'.

Our compilations are driven by make files, which are driven by generated
dependency (make
rule) files, which are created from source code. The problem is, we cannot
determine the
dependencies from reading Cobol source programs. All we see is "copy
custrow.cpy". We
cannot tell that status.val is a dependent. (Make decides what to compile
by comparing
timestamps of dependents to the timestamp of the executable.) One way to
make it work
would be to generate custrow.cpy into a temp area, compare it to the
previous custrow.cpy,
replacing custrow.cpy only if there is a difference. THIS SHOULD NOT BE
NECESSARY,
especially since Micro Focus and the '02 Cobol Standard both support
nested COPYs. A
better way to make it work would be to simply eliminate the
pre-pre-processor. Instead we
run 18 hour full builds because somebody back in the early '80s thought
nested COPYs were
too much trouble or unnecessary. They WERE unnecessary for small systems.
If someone on
the '85 Standards Committee had known the requirements of LARGE systems
(10,000s of
programs), our builds would already be running in 2 hours.

If you are that bothered by this, you could certainly write your own COPY
processor. (I just finished doing that for a code generator I delivered a
few days ago. It's not rocket science... :-))

We DID write our own COPY processor. That's what's causing the problem.

If you did a hardware upgrade, it wouldn't take 18 hours to build.... :-)

There are always options.

Hmmmmm..... :-)

It's hardly fair to expect a Standards Committee to predict HOW people are
going to use the provided facilities, before the applications have ever been
written... :-)

In 1985 we had 25 years of mainframe Cobol experience. During the last 10 of those years,
dynamic calls and databases were widely used.

I was interested to see your post, Robert, and I recognise the problems you
are encountering, but this is not the fault of the people who designed
COBOL, or even those who later took responsibility for it.

Installations CHOOSE how they are going to do stuff.

They've chosen Jave this decade.

It isn't the fault of the language.

This article says the most popular programming languages are Java, C , C++, Visual Basic,
PHP and C#. Cobol finished in 17th place. Why did it go from 1st to 17th? Oh, you already
answered that question. It isn't the fault of the language, it's the fault of Scott
McNealy, Bell Labs, Bill Gates and Zend.

http://www.itjungle.com/tug/tug121406-story03.html
.

Relevant Pages

  • 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. ... I would have severe resevations about using a programming language designed ... And that is one reason why installations have Local Standards... ...
    (comp.lang.cobol)
  • Re: RW and "good COBOL" (was: Cobol Myth Busters
    ... Standards are the Holy Writ. ... That's not a language, it's a destructive weapon. ... Programming forums can have many purposes. ... Little new development is in Cobol ...
    (comp.lang.cobol)
  • Re: RW and "good COBOL" (was: Cobol Myth Busters
    ... Standards are the Holy Writ. ... That's not a language, it's a destructive weapon. ... Little new development is in Cobol ... Cobol is disrespected in other programming cultures ...
    (comp.lang.cobol)
  • Re: String Functions in MF
    ... installation standards that constrained the use of the language. ... You might wonder how such standards could have been written, ... Assembler, been dragged kicking and screaming into COBOL, and was determined ... Programming Languages should not be designed for the Lowest Common ...
    (comp.lang.cobol)
  • Re: Java compatibility issues (WAS: MF having issues?)
    ... language it can do most of what C, C++, and Java can do. ... 2002 COBOL standard addresses that, but having a standard is a far ... Some flavours do have libraries. ... On the IBM mainframe we have Language Environment but it does ...
    (comp.lang.cobol)