Home > Archive > Cobol > May 2007 > Re: GO TO HELL.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Richard 2007-05-24, 7:55 am |
| On May 22, 11:35 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> 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 :-)
Fortunately my only memories of any code with ALTER was a system that
was evaluated and after looking at one program I suggested they burn
the lot. It made me happy that they did.
It was 'efficient' in that the executing code was directly modified so
no 'if' was required.
> 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.
You should note that the only way to know what happens in any
particular run of the program is to start at the beginning, have the
whole set of data available, and step through every item of data and
every line of code. In other words pretend that you are the computer.
Without following the whole run you will not know which switches are
set in any particular way.
With an *efficient* coding structure it is possible to look at any
isolated part of the code and understand what it does without
reference to other parts of the program or, indeed, to what code has
been previously executed. 'GO TO's will not be part of that structure.
'ALTER's, and all the programmers that used them should have been
killed off at the end of the 60s.
> 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...)
Of course some may not be reset at the start of every transaction, so
the path of each transaction must be traced through in turn before the
switch settings can be adequately known.
> 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... :-)
If you can find a copy of 'Early British Computers' it has a section
on mercury tube memory and how to program using it. The cycle time of
the memory was much longer than the instruction execution time. If
each instruction was followed by the one in the next address then the
machine would be too slow. So each instruction included a 'goto'. This
allowed the program to be written as
20: ADD 30: ->40: address 20 is add address 30 to mill, next is 40
....
....
30: data value
....
....
40: STORE 50: ->60: store mill in 50 next is 60
given the add instruction can do the fetch in < 10 steps and the add
in < 10 steps of the memory then these two instructions can run in
less than one memory cycle.
The only way to know what the program does is to follow every
instruction as if it were being executed by the machine.
ALTER is only one degree better.
> At the end of the day, it is only COBOL....
Sorry, it may be Cobol, but it is crap Cobol, always was, always will
be.
| |
| Pete Dashwood 2007-05-24, 7:55 am |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1179984661.635350.327300@u36g2000prd.googlegroups.com...
> On May 22, 11:35 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
>
> Fortunately my only memories of any code with ALTER was a system that
> was evaluated and after looking at one program I suggested they burn
> the lot. It made me happy that they did.
>
> It was 'efficient' in that the executing code was directly modified so
> no 'if' was required.
>
>
> You should note that the only way to know what happens in any
> particular run of the program is to start at the beginning, have the
> whole set of data available, and step through every item of data and
> every line of code. In other words pretend that you are the computer.
> Without following the whole run you will not know which switches are
> set in any particular way.
>
> With an *efficient* coding structure it is possible to look at any
> isolated part of the code and understand what it does without
> reference to other parts of the program or, indeed, to what code has
> been previously executed. 'GO TO's will not be part of that structure.
> 'ALTER's, and all the programmers that used them should have been
> killed off at the end of the 60s.
>
>
> Of course some may not be reset at the start of every transaction, so
> the path of each transaction must be traced through in turn before the
> switch settings can be adequately known.
>
>
> If you can find a copy of 'Early British Computers' it has a section
> on mercury tube memory and how to program using it. The cycle time of
> the memory was much longer than the instruction execution time. If
> each instruction was followed by the one in the next address then the
> machine would be too slow. So each instruction included a 'goto'. This
> allowed the program to be written as
>
> 20: ADD 30: ->40: address 20 is add address 30 to mill, next is 40
> ...
> ...
> 30: data value
> ...
> ...
> 40: STORE 50: ->60: store mill in 50 next is 60
>
> given the add instruction can do the fetch in < 10 steps and the add
> in < 10 steps of the memory then these two instructions can run in
> less than one memory cycle.
>
> The only way to know what the program does is to follow every
> instruction as if it were being executed by the machine.
>
> ALTER is only one degree better.
>
>
> Sorry, it may be Cobol, but it is crap Cobol, always was, always will
> be.
An informed opinion, but one that is unlikely to encourage the person faced
with the task of fixing it :-)
Pete.
>
| |
|
| In article <1179984661.635350.327300@u36g2000prd.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
[snip]
>With an *efficient* coding structure it is possible to look at any
>isolated part of the code and understand what it does without
>reference to other parts of the program or, indeed, to what code has
>been previously executed.
Mr Plinston, I wonder if your definition of 'efficiency' assumes it'sself.
I was taught, lo, those many years ago, that programming involves
balancing machine resources and human ones, that what makes the machine
execute the code most quickly might be what makes a programmer, at 2:am,
consider homicide.
>'GO TO's will not be part of that structure.
Of course they will... but this discussion's been had before.
DD
| |
| Clark F Morris 2007-05-24, 9:55 pm |
| On 23 May 2007 22:31:01 -0700, Richard <riplin@Azonic.co.nz> wrote:
>On May 22, 11:35 am, "Pete Dashwood"
><dashw...@removethis.enternet.co.nz> wrote:
>
>
>Fortunately my only memories of any code with ALTER was a system that
>was evaluated and after looking at one program I suggested they burn
>the lot. It made me happy that they did.
>
>It was 'efficient' in that the executing code was directly modified so
>no 'if' was required.
>
>
>You should note that the only way to know what happens in any
>particular run of the program is to start at the beginning, have the
>whole set of data available, and step through every item of data and
>every line of code. In other words pretend that you are the computer.
>Without following the whole run you will not know which switches are
>set in any particular way.
>
>With an *efficient* coding structure it is possible to look at any
>isolated part of the code and understand what it does without
>reference to other parts of the program or, indeed, to what code has
>been previously executed. 'GO TO's will not be part of that structure.
>'ALTER's, and all the programmers that used them should have been
>killed off at the end of the 60s.
I am glad that I survived the 1960's. I am less glad the ALTER heavy
programs (1 blew a code restructuring program) also survived far
longer than they should. The payroll programs were replaced by a pack
that didn't handle some of the bargaining agreements well. The
marketing programs which were inadequate for the business in the
1970's survived at least until the 1990's. They should have gotten a
decent set of specifications and started over because they didn't meet
business needs having been basic rewrites of a 1401 system and
probably not right for the business then. In both cases, I would not
write them the same way given the job to do over again with the IBM
DOS COBOL D compiler and the 16K partition limitation.
>
>
>Of course some may not be reset at the start of every transaction, so
>the path of each transaction must be traced through in turn before the
>switch settings can be adequately known.
>
>
>If you can find a copy of 'Early British Computers' it has a section
>on mercury tube memory and how to program using it. The cycle time of
>the memory was much longer than the instruction execution time. If
>each instruction was followed by the one in the next address then the
>machine would be too slow. So each instruction included a 'goto'. This
>allowed the program to be written as
>
>20: ADD 30: ->40: address 20 is add address 30 to mill, next is 40
>...
>...
>30: data value
>...
>...
>40: STORE 50: ->60: store mill in 50 next is 60
>
>given the add instruction can do the fetch in < 10 steps and the add
>in < 10 steps of the memory then these two instructions can run in
>less than one memory cycle.
>
>The only way to know what the program does is to follow every
>instruction as if it were being executed by the machine.
>
>ALTER is only one degree better.
>
>
>Sorry, it may be Cobol, but it is crap Cobol, always was, always will
>be.
| |
| Howard Brazee 2007-05-24, 9:55 pm |
| On Thu, 24 May 2007 14:52:40 -0300, Clark F Morris
<cfmpublic@ns.sympatico.ca> wrote:
>I am glad that I survived the 1960's. I am less glad the ALTER heavy
>programs (1 blew a code restructuring program) also survived far
>longer than they should. The payroll programs were replaced by a pack
>that didn't handle some of the bargaining agreements well. The
>marketing programs which were inadequate for the business in the
>1970's survived at least until the 1990's. They should have gotten a
>decent set of specifications and started over because they didn't meet
>business needs having been basic rewrites of a 1401 system and
>probably not right for the business then. In both cases, I would not
>write them the same way given the job to do over again with the IBM
>DOS COBOL D compiler and the 16K partition limitation.
The world changes. The major costs of expensive equipment have
dropped, while the old costs of labor and time have increased. The
cost of energy has pretty much stayed constant, but is increasing
slowly. The cost of inadequate security has gone up very fast. Our
calculations of efficiency have to be based upon the current and
future needs, not our old needs.
Agatha Christie wrote in her autobiography that as a girl she never
thought she'd ever be rich enough to afford a car - or poor enough
that she couldn't afford servants.
(I wonder how many non-CoBOL people have seen this heading and figure
it is an imperative statement).
|
|
|
|
|