Cobol - Re: GO TO HELL.

Author

Re: GO TO HELL.

Clark F Morris

2007-05-21, 9:55 pm

On Tue, 22 May 2007 11:35:53 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>
>"Doug C" <NoSpam@Spamblocker.org> wrote in message
>news:KOidncaUa62mic_b4p2dnA@giganews.com...
>Thanks for posting that.
>
>A very flexible, efficient, approach that evoked some very happy memories
>of running COBOL on very small machines in tight environments... in the
>er... 1960s :-)
>
>Think of it as a railway, with various points that can be switched. Start by
>drawing the rail network with the possible entries and exits from each set
>of points. The very action of mapping this will help you to see how it
>works. From the snippet, it looks as though the rail network (of program
>control) is individually initialized for each incoming transaction, then the
>transaction is allowed to run through the network. (A bit like letting rats
>run through a maze, but first initializing the maze for each individual
>rat...)
>
>If you drop your GOTOless training and try not to prejudge it, you may
>actuallu enjoy fixing this... It is a glimpse of how computer programming
>used to be, and some of us here still remember it... :-)
>
>At the end of the day, it is only COBOL....

As someone who inflicted a number of COBOL programs (only payroll,
marketing and a critical file dump program) on his former shop to stay
within a 16K partition limitation, I find the above code worthy of
getting a number of people fired. My ALTERs were of the form ALTER
SW4000-EDIT-EX TO PROCEED TO 2800-CHK-GROSS-PAY. Cryptic names such
as those are designed to have the original coder not understand the
code.

I now practice GO TO free programming, mostly because it is less of a
headache for the poor soul that inherits it but also because it is
optimizer friendly.

Does anyone have current specs for this beast?
>
>Go to it.
>
>Pete.
>

Pete Dashwood

2007-05-22, 7:55 am

"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:08m453p05hcen0760fg3213gmc8crh2k0u@
4ax.com...
> On Tue, 22 May 2007 11:35:53 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> As someone who inflicted a number of COBOL programs (only payroll,
> marketing and a critical file dump program) on his former shop to stay
> within a 16K partition limitation, I find the above code worthy of
> getting a number of people fired. My ALTERs were of the form ALTER
> SW4000-EDIT-EX TO PROCEED TO 2800-CHK-GROSS-PAY. Cryptic names such
> as those are designed to have the original coder not understand the
> code.

I don't think you have any right to claim higher moral ground just because
your names were "meaningful", Clark.

There is very possibly a shop standard that says names MUST be of the format
shown. If that's true, then the names are NOT cryptic.

In fact, it really doesn't matter what you call the "points"; functionally
they are simply places where control can be switched. Within the context of
such a program the entrances and possible exits are all that matters (I have
maintained a few of these in my time) and meaningful destination names can
actually be confusing. (You think it's going to a particular process but it
gets switched from somewhere else before it can. I stand by the railway
analogy. ) You could rename every label as L1, L2, L3 etc and it still
wouldn't make the program any more or less intelligible. A program
containing 134 ALTER statements and 326 GO TO statements, won't be improved
by changing the labels on the switching points.

If you would seriously fire people over this code, then I sincerely hope you
never get that opportunity. :-)

>
> I now practice GO TO free programming, mostly because it is less of a
> headache for the poor soul that inherits it but also because it is
> optimizer friendly.

Sure, we've all learned a thing or two since the 60s... :-)

However, a real programmer will fix any code that is broken, without
requiring heads to roll, without making judgements on it, just because it is
program code, and that's what we do.

Pete.

Louis Krupp

2007-05-22, 9:55 pm

Pete Dashwood wrote:
<snip>

> However, a real programmer will fix any code that is broken, without
> requiring heads to roll, without making judgements on it, just because it is
> program code, and that's what we do.

But sometimes you gotta vent first.

Louis

Howard Brazee

2007-05-22, 9:55 pm

On Tue, 22 May 2007 10:08:25 -0600, Louis Krupp
<lkrupp@pssw.nospam.com.invalid> wrote:

>
>But sometimes you gotta vent first.

Yep.

And if you're more than a programmer, with an interest in your
company's bottom line, you need to evaluate alternatives to
maintaining such code and make appropriate recommendations.

Of course, often your best recommendation is "It would cost too much
in the short run to re-write this now".

Michael Mattias

2007-05-22, 9:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:4m865318rmdlddnhf7vj8u8b4bq4mmg65b@
4ax.com...
> And if you're more than a programmer, with an interest in your
> company's bottom line, you need to evaluate alternatives to
> maintaining such code and make appropriate recommendations.
>
> Of course, often your best recommendation is "It would cost too much
> in the short run to re-write this now".

I wonder how many times that particular "cost-benefit" analysis turned out
valid in the short term, but way, way incorrect in the LONG TERM?

MCM

Howard Brazee

2007-05-22, 9:55 pm

On Tue, 22 May 2007 12:13:55 -0500, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>
>I wonder how many times that particular "cost-benefit" analysis turned out
>valid in the short term, but way, way incorrect in the LONG TERM?

You see why I worded it the way I did.

We live in the short term, and things will change. We all give up
some long term benefit for the short term. The famous quote "If I
had known I was going to live this long I would have taken better care
of myself" also might include "invested more".

In the long run we are all dead.
- John Maynard Keynes

Clark F Morris

2007-05-22, 9:55 pm

On Tue, 22 May 2007 20:56:04 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>
>"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
> news:08m453p05hcen0760fg3213gmc8crh2k0u@
4ax.com...
>
>I don't think you have any right to claim higher moral ground just because
>your names were "meaningful", Clark.
>
>There is very possibly a shop standard that says names MUST be of the format
>shown. If that's true, then the names are NOT cryptic.

Having inherited a program with data names like this on a report file,
I may have overreacted and if the paragraphs are in sequence it MAY be
tolerable. However, this program looks like it was designed in the
core scrounge mode which can lead to problems for even the original
coder even with meaningful names. In a sense it almost looks like
they were writing Assembler in COBOL where starting at
C12420-TRAN-83-84 the code up to the next major point is like the
internal parts of a Macro. Indeed this may have originally come from
a code generator. One of the major revolutions at the time of early
(1960 -1961) COBOL was the idea of long meaningful tags. Fortran was
limited to 6 characters and most assemblers were limited to 8 - 10
characters for tags. Granted FACT from Honeywell and others also
allowed for decent size names. This ramble is saying that obscurity
in coding is never good and ALTER immediately adds obscurity and this
code just compounded it. There also are some assembler programs that
I remember with cringing where the input fields were CARDIO+6(4). I
probably should not be so critical because I would not be surprised if
this program (if batch) dates back to the 1960's. It definitely
should be scheduled for replacement or major rewrite. It is a time
bomb waiting to explode because it is difficult to understand. I know
the breed. I created them and am glad virtually all of them have been
retired.
>
>In fact, it really doesn't matter what you call the "points"; functionally
>they are simply places where control can be switched. Within the context of
>such a program the entrances and possible exits are all that matters (I have
>maintained a few of these in my time) and meaningful destination names can
>actually be confusing. (You think it's going to a particular process but it
>gets switched from somewhere else before it can. I stand by the railway
>analogy. ) You could rename every label as L1, L2, L3 etc and it still
>wouldn't make the program any more or less intelligible. A program
>containing 134 ALTER statements and 326 GO TO statements, won't be improved
>by changing the labels on the switching points.
>
>If you would seriously fire people over this code, then I sincerely hope you
>never get that opportunity. :-)
>
>
>Sure, we've all learned a thing or two since the 60s... :-)
>
>However, a real programmer will fix any code that is broken, without
>requiring heads to roll, without making judgements on it, just because it is
>program code, and that's what we do.
>
>Pete.
>

Sponsored Links