Re: COBOL's Influence on C



"Robert" <no@xxxxxx> wrote in message
news:5nspj3tm974nq8isu919j2fut34ipg7sh5@xxxxxxxxxx
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:

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

They can't if it isn't known until runtime. Statically linked COBOL will
also grizzle about unresolved EXTERNs, but it does so at Link time.

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.

And why would you have "thousands of libraries" on the list? This now comes
down to an Administrative responsibility. For example, if there are rules
about how libraries get assigned to subsytems, the chaos is diminished. Jobs
running certain systems will only reference libraries pertinent to those
systems, and common libraries used for common components. It is manageable,
but it needs ot be managed. If you DON't manage it, it is hardly fair to
blame the COBOL language...

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.

It indicates which programs (and which version of them) called missing
programs, and what thiose missing programs should have been. Certainly, you
could also derive this information from other system sources, but it is a
convenient one.

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.

If this is directed to me, I AM in Management. And I don't have a problem
with systems running dynamically or late bound or determining which modules
to load from an internal algorithm, or a raised event, or a menu selection.
And I never have done.

(However, I've never loaded 64 million records to a database, or had to
manage the JCL for millions of programs in an overnight batch window,
either, so my experience may be considered limited, compared to some
here...)


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

I have no idea what you're talking about...(is that mutual...? :-))


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. :)

(I are one, too :-)) Although it is one of several hats I wear...

Precisely. ONE. I wonder why the others are not disturbed by the points you
raise?


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. :)

I do use that phrase and I have even been known to apply it. On this
occasion, it wasn't appropriate, as there are existing and standard
solutions to the problems you are raising.



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.

So, PAYROLL is FUBAR? Looks like something certainly is... :-)

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.

Then, it would seem expedient, as I mentioned earlier to have a team of
people applied to fixing the mess. Given a reluctance to invest in the
"10,000"s of programs currently in use, one might conclude that you get what
you deserve...


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

And you came to this conclusion, exactly....... how?

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.

No, they don't. Any program (in ANY Language, and assuming it has the
requisite Authorization) containing a Shell Exec (for example) can activate
anything it likes. The same can be done with API calls or DotNET Process
Objects. The mainframe can do it from COBOL, PL/1, RPG, and Assembler, to my
knowledge, there are probably others.

It is a tried, proven, and accepted technique. You find yourself on a
specific installation which does not seem to be well managed (from what
you've written; I'm not qualified to judge the reality, as I don't have
enough information...), you admit to a lack of experience in using this
facility, and then decide that COBOL is wrong to allow it.

It isn't a good case, Robert.

There is nothing wrong with dynamic linkage OR with dynamically deciding
what to CALL; your problem is YOUR lack of experience and familiarity with
it, and the special needs of the site where you are working. Although
"pre-validating" batch runs may be a useful facility in your case, for most
sites it doesn't gain them much. The batch runs are pretty standard and run
from a standard set of JCL or REXX; the required libraries are easily
identifiable and assignable, and when things crash, it isn't because of a
system problem like a required load module not being available, but because
of crap data that has never been encountered before, pushing a program past
its breaking point.


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.

But it is a requirement. Because that's what they want to do... And the
solution you just suggested is language independent.



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.


<snipped discussion on nested COPY, which we probably all agree would be
useful...>

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

Ever wondered why? :-) They are useful facilities.

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.

And there are sound reasons for that.


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.

The same paradigm shift that promoted Java, demoted COBOL. Object Oriented
programming and component based design, replaced procedural integrated code.
Java is a "pure" OO language and was designed that way from the beginning.
C++ allows the ancient C to move easily into the same arena, and even VB has
been given OO. C# and PHP are both based around the OO paradigm, like Java.
There are some "new kids" (like Ruby) that are rising quickly also.
Invariably, they implement the model that COBOL rejected.

Yes, there IS OO COBOL, and I used it and loved it for around 12 years, but
after using C# there is no comparison. I just finished refactoring and
upgrading some old COBOL, wrapping it in C# and adding new facilities in C#.
The new system is written mainly in C# but calls some COBOL components. If
the entire system had been written in COBOL it would have been around
100,000 lines of code. Instead it is around 5000 lines of COBOL and 9500
lines of C#... (It was enthusuastically received in Melbourne when I
delivered it two days ago...) Small, efficient, utilising some of the 80,000
components available through the DotNET framework. Easy and simple to write
and enhance. There is no way I'd go back to COBOL as a main development
language.

The point is that it wasn't COBOL's ability to make dynamic CALLs that led
to the rise of Java...


Why did it go from 1st to 17th? Oh, you already
answered that question.

Yes. I did. Above.

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • 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: Odd behaviur...
    ... > and C was a language suitably scaled to the problems then in hand. ... > libraries, most of which are your own, the includes are easily managed. ... entire generation of programmers frustrated with simplistic and restrictive ... But its always fun to ask them if they have ever heard of the COBOL ...
    (comp.lang.pascal.delphi.misc)
  • 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: COBOLs Influence on C
    ... Cobol is the only language that has this problem. ... sure that the libraries containing ANYTHING that might be called are on ... I'm talking about calling programs using the language's standard call mechanism. ...
    (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)