On 22/02/09 01:31, John Little wrote:
>
>
> On Feb 21, 12:02 am, Tony Mechelynck<[email protected]>
> wrote:
>> So the
>> criminal offence, if any (which remains to be seen), might be _teaching_
>> COBOL or _requiring_ its use, but not _using_ it.
>
> Normal coding is not use in isolation, one is always in communication
> with whoever gets to maintain the code.
>
>> If you say COBOL-74 was different from "my" COBOL in crippling terms, I
>> have to defer to you. Was COBOL-74 freeform already?
>
> Yes, but it still had no end-if, an unusable call statement, and the
> all-variables-global data division. Cobol-85 cleaned things up a lot,
> enabling logic to coded straightforwardly. But the cripples I
> referred to were so enamoured of their copy books with GO TO paragraph-
> exit they enshrined it in the coding standards. go tos are bad, but
> when they're in copy books (included code), going to places in other
> copy books, I find the notion of brain damage inescapable. That might
> have been one shop going off on a tangent, but I encountered the same
> practice (among other heinousness) on another unrelated project.
> (That included something that was arguably criminally negligent,
> because it concealed a back door that could be used to affect money
> transfers.)
>
> This may seem off-topic, but IMO is relevant to vim-dev at least.
> Vim's developers might be aware of some aspects of the "house-style".
>
> Regards, John
Hm. When I learnt programming, "structured programming" wasn't yet "the
only way to go". Of course we called subroutines using PERFORM, but
nothing prevented using GO TO within a single routine, especially to go
to the EXIT paragraph at the end of the subroutine (a "return" in the
middle of a function, or a "break" in the middle of a while-loop, do the
same in C or in vim-script under another guise, don't they?). And since
the DEPENDING clause could only be used with GO TO, another GO TO might
be necessary when coming back. Self-modifying code (the ALTER statement)
was used only in very special and well-documented cases.
As for money transfers, I never worked for a bank. At first I was in a
servicebureau, where we programmers made programs for various clients
(mostly accounting OT1H and payrolls OTOH), but code from any programmer
belonged to the firm and could be seen and worked on by any other
programmer if necessary (for instance, if the original "author" went ill
or left the firm). Later I worked for a subsidiary of Electrolux, where
I converted an existing production database to an SQL-based system from
some outside software maker. Here, money transfers didn't even enter the
program's workings IIRC.
As for the CALL statement, it wasn't invented when I first learnt COBOL
(subroutines were called using PERFORM, which, whatever you might think,
was perfectly usable). Later, CALL was added as a non-ANSI extension to
call assembly-language subprograms as in
ENTER COMMUNICATION-MODE.
CALL external-name [USING data-name-1 ... data-name-n].
ENTER COBOL.
which an even later ANSI standard would simplify to
ENTER language-name external-name [USING data-name-1 ... data-name-n].
(where, on the system where I worked then, language-name was required
but documentary only, couldn't be COBOL, and didn't influence the
generated code). This was one of the reasons I got an interest in
assembly language: to do some things which weren't reasonably feasible
in COBOL, such as translating input from 9-track tapes, read by the
hardware into two characters per byte, to the 6-bit characters of that
processor; or later to improve the performance of the critical parts of
some programs which did what they had to do, but much too slowly. Also
to circumvent the fact that the INDEXED BY clause hadn't yet been
invented, which meant that subscripts had to be in decimal while the
hardware (which couldn't do binary multiplication) addressed memory in
binary.
Best regards,
Tony.
--
No man may purchase alcohol without written consent from his wife.
[real standing law in Pennsylvania, United States of America]
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
