For Programmers: Free Programming Magazines  


Home > Archive > Cobol > July 2007 > Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)









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]

 

Author Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
Richard

2007-07-31, 3:55 am

On Jul 31, 2:38 pm, LX-i <lxi0...@netscape.net> wrote:

> OK - here's a question for you old guy... er, seasoned professionals...
>
> My first experience with the ALTER verb was our shop standards when I
> first got there. "The use of ALTER is strictly forbidden." :) I
> wondered what it did, but didn't bother looking it up at that point.
>
> Later on in my time there, I looked it up - and shuddered. IMO, it's an
> absolutely horrendous construct. It seems to me that if ALTER is the
> answer, the question must not have been phrased correctly. :) I
> understand its use, and the problems that it was supposed to get around
> largely don't exist any more.
>
> Now my curiosity is more theoretical. How does one think to design
> ALTER in a good way?


At the time of Cobol being designed in the late 50s it was quite
common for assembler programmers to use self-modifying code as a way
of avoiding the overhead of testing flags. In fact with the first
machines I used the PERFORM actually did work by modifying a branch at
the end of a PERFORM scope to jump back to after the PERFORM and then
branched to the start of the scope. The 'EXIT' noise word in its own
paragraph was required in very early compilers because that reserved
space for the branch that the PERFORM set.

ALTER was implementing the standard mechanism in common use.

If you want to see something complicated try to get the book 'Early
British Computers' where it describes programming for mercury delay
tubes and gives an example.

Because the cycle time of the memory was much slower than the
instruction execution speed it was necessary to do several
instructions in one memory cycle. So every instruction specified the
next instruction address, it would be far to slow to have to wait for
the next address to come round again. 10 would be, say, an add of
address 15 to the 'mill' and next instruction at 30. The instruction
would be able to complete this and pick up the value, complete the add
and pick up 30. 30 would store the accumulator in 38 and next
instruction 47.

The program had to be laid out in a map and timings done to get it to
work at best speed. Core store allowing sequential instructions and
self-modifying code (eg ALTER) was an enormous improvement in
programming.

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com