Re: COBOL's Influence on C

On Sat, 17 Nov 2007 01:10:09 +1300, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:



"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 openers, every database table has a library of data layer functions. There is no
embedded SQL in application programs. There are 10,000s of tables.

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

That works in small to medium shops. We have hundreds of development groups all over the
world, each managing its own libraries.

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.

The log contains the name of the failed job and program, but not necessarily the name of
the called program.

Version control is another aspect. A program can optionally specify the minimum version of
a library in its ELF header. For example, 'foo 3.2 or greater'. If the library is 3.1,
the bind fails, similar to a missing library.

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?

Many people are concerned about runtime verification, for example:

http://publib.boulder.ibm.com/infocenter/cmgmt/v8r3m0/index.jsp?topic=/com.ibm.sysadmin.hlp/msr10023.htm
http://www.dcmsi.com/jeda2.htm
http://www.diversifiedsoftware.com/
http://e-jcl.com/_wsn/page2.html
http://www.asg.com/products/product_details.asp?code=PJM


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.

AFIK, none of them can validate Cobol programs. I'd be delighted to be proven wrong.

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?

1. Statements like this one from Frank, ".. on the mainframe we use dynamic calls (CALL
data-name) almost exclusively."

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.

I'm talking about calling programs using the language's standard call mechanism. Calling
via the OS API isn't found in ANY language standard, with the possible exception of
Microsoft. Doing that ties the program to a single OS platform.

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.

1. Calling the OS API is definately NOT "a tried, proven, and accepted technique" for
calling application programs. The language's call is the accepted technique.
2. My installation is managed better than most.
3. As a systems programmer, I have extensive experience with the OS API.

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.

If you don't know how to validate batch jobs, just say so.

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.

And why would you need 80,000 components? This now comes
down to an Administrative responsibility. For example, if there are rules
about how components get assigned to subsytems, the chaos is diminished. Jobs
running certain systems will only reference components 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...

Couldn't Fujitsu's COBOL For .NET call the same componnts? If yes, a Cobol version of your
C# would measure about the same 9500 lines.

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

Being stuck in the 1980s caused the downfall of Cobol.


.

Relevant Pages

  • 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)
  • 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 ... And that is one reason why installations have Local Standards... ...
    (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: Java compatibility issues (WAS: MF having issues?)
    ... syntax than add a standard XML library to COBOL. ... Adding "native language support" for IBM's Enterprise ...
    (comp.lang.cobol)
  • Re: Cobol language dictionary page -- assignment complete?
    ... > REMARKS Paragraph. ... >> an IBM-ism, it is, nonetheless, no longer standard COBOL ... >> representative of recent standard COBOL. ... COBOL is, is to do a disservice to the language and, ...
    (comp.lang.cobol)