Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?


"Howard Brazee" <howard@xxxxxxxxxx> wrote in message
news:db5qnq$rev$1@xxxxxxxxxxxxxxxxxxxxxxx
>
> On 13-Jul-2005, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote:
>
>> There have been paranoid knee jerks from people who loftily believe that
>> ONLY a human could write 'proper' COBOL...
>
> I'm close to this. The reason for structured code is to make it easier
> for the
> human debugger. Putting in a bunch of switches to make a program
> "structured"
> does not do this.

I have to disagree with you Howard. ( I don't enjoy it, because you are
usually right and certainly one of the reasonable people here. :-))

I contest your premise "The reason for structured code is to make it easier
for the
human debugger."

That is certainly _A_ benefit of structured code, but there are other
reasons for structuring, that may be more important than this...benefits
from avoiding duplication and encapsulating functionality into code blocks,
for example.

Systems that use generators to pull blocks of code or OO components together
are still taking advantage of structure, without any human programmers being
involved.

"Putting in a bunch of switches to make a program "structured"
does not do this."

No it doesn't, but this is an example of how the true purpose of Oliver's
exercise gets lost. He is NOT putting in the switches to make the code
structured. (The removal of branches, in and of itself, does NOT make the
code "Structured", but it DOES make it easier to process in a subsequent
pass...) He is putting in the switches as a step towards converting the
code.

Dijkstra was one of the first to scientifically analyse computer programming
and show the fundamental functions it is comprised of: Sequence, Selection,
and Iteration. He showed that no other functions were required for flow
control. (At least, not in the Von Neumann model we are familiar with;
certain other architectures may require their own equivalents and have some
added ones. Multiple parallell asynchronous processors, quantum computers
(if we ever see them) and content addressable stores, all have different
rules..) Out of this has come a huge amount of information and it is of
particular importance in what Oliver is trying to do. He is implementing
algorithms that are well understood and guarantee success. His problem is to
ensure that he matches the language facilities (whether it is COBOL, Java,
C, Algol, PL/1 or anything else) correctly to his algorithms. (In my opinion
he has demonstrated excellent judgement in doing this...) He accepts that he
is not a COBOL expert (but he doesn't have to be; he needs to understand how
the facilities of COBOL match to his computer science model, and all the
facilities of COBOL are well documented.) He has checked in here as a belt
and braces approach that is systematic and thorough. Some good stuff has
come out of his doing so.

As COBOL programmers it is easy to start believing that we are implementing
smart and complex code sequences that could not possibly be grasped or
formulated by a machine. Wrong. The most beautiful, elegant, clever,
imaginative code that you and I have ever written, can be decomposed
according to well established (since the 80s) rules and 'simplified' or
'refactored' into something that will do the exact equivalent.

The rules are so well established that the process can be automated, and
that is what Oliver is doing.

>
>> The task you are undertaking is a very interesting and worthwhile one.
>
> Interesting and fun yes. Worthwhile to his employer? I'm not sold on
> this.

I talk to managers all the time who are concerned about replacing their
legacy systems. But they know they have to. It isn't about fashion or "if it
ain't broke don't fix it"; it is about a dynamic market place where
competitive edge is hard won and where it simply isn't viable to have
millions of lines of computer code that has to be manually maintained, when
there are other options.

So, say the company has its business model embedded in several million lines
of COBOL and you are responsible for IT. What do you do? COBOL programmers
are getting harder to come by and the whole idea of maintaining bespoke code
in-house is becoming more and more expensive and ponderous. Outsource the
lot to, say, EDS? That is one option, but you have simply shifted the
problem. The systems will be no more responsive to change in this scenario
than if they stayed in-house. Maybe the members of the board have just been
entertained by Siebel or SAP and are pretty sold on this solution.
Either of them will require tailoring, so the implementation of "New
Technology" is going to be painful.

Anything you can do to ease the move to the new platforms will be good. If
you could reuse all your existing COBOL functionality in a way that allowed
it to work in the new environment, so you had the benefits of the new
environment (too many to go into here), but bought time to consider
rebuilding your core processes, wouldn't that be good?

Re-factoring existing code does that. If the COBOL becomes Java (or any
other OO language) it can become encapsulated beans (functions) that can be
wrapped appropriately and plugged into the New Technology, just like any
other component. (Java or non-Java. Could be PHP or ASP or whatever; the New
Technology has interfaces for all of it.) The source code is really
irrelevant; it is the functionality that matters. If a given function is
found not to be doing the job, it is much easier to replace that failing
component than to try and find the required lines amongst a million lines of
COBOL code. And then, (as you have pointed out yourself here frequently), do
all the regression testing...

This is one reason why Oliver is not so concerned with source code (either
COBOL or generated) beyond making sure that his algorithms can accommodate
it. Whether he is working on a tool that will allow companies to refactor
their own code (for their own reasons) or whether it is for a specific
company who have recognised that they need such a tool and are prepaed to
develop it, what he is doing is valuable, and that was the point we
disagreed on.

The four paragraphs above are insufficient to cover all the reasons why
automated re-factoring of code is a major cost saver, but hopefully, they
may help to persuade you that it can be...

>> Re-factoring code from existing systems, whether it be COBOL or any other
>> language is a valuable exercise.
>
I stand by it; see above...

> Exercises like this can make him a better programmer, which in the long
> term can
> be useful to his employer. Exercising makes us stronger.
>
He is already a very capable programmer. However, I don't disagree with you
on this one :-)

Pete.



.

Relevant Pages

  • Re: Declining Cobol job market
    ... pursuing Cobol jobs. ... server side programming in PL/SQ. ... A lot of COBOL programmers (and RPG programmers, and Assembler ...
    (comp.lang.cobol)
  • Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... possible that Cobol programmers see themselves as defenders of an intellectual lost cause?The last hangers-on of an idea whose time has passed. ... The absolute power was a corrupting influence, just as it has been in certain other religions. ...
    (comp.lang.cobol)
  • Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... people to think about why COBOL is in the state it's in. ... a dollar for every time I have seen Business people put down by programmers. ... >> There are certainly parallels with religion in that. ...
    (comp.lang.cobol)
  • Re: Useful Utility or Not?
    ... > new releases of CoBOL for networking platforms caused me to resurrect ... ISAM files though I believe the ... Before the advent of Relational Databases I ... know of several courageous COBOL programmers who had a crack at writing ...
    (comp.lang.cobol)
  • Re: Is there a mainframe skills shortage?
    ... Grid computing is about the closest anything comes to mainframe scheduling, except for it's limited use in a large transaction/database environment. ... they would look at you and say: "Why would you want to merge these sequential files when you could have updated directly to a Relational Database in ANY sequence you like and simply ORDERed the result set?" ... The difference is that today's graduates are not completely useless when faced with commercial problems, even if they don't know COBOL. ... They can't even find relevant training, much like programmers. ...
    (comp.lang.cobol)