Loading ...
Sorry, an error occurred while loading the content.

Re: Using GVim instead of Vim on Windows

Expand Messages
  • Tony Mechelynck
    ... almost: ALTER procedure-name-1 TO [PROCEED TO] procedure-name-2. where PROCEED and the second TO were (IIRC) not required by the language but we always
    Message 1 of 13 , Feb 24, 2009
    • 0 Attachment
      On 22/02/09 03:05, _sc_ wrote:
      > On Saturday 21 February 2009 6:31 pm, John Little wrote:
      >> On Feb 21, 12:02 am, Tony Mechelynck<antoine.mechely...@...>
      >> 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".
      > this sounds like a fun rant -- i can't not jump in, forgive me
      > you haven't lived until you've been required to modify an old cobol
      > program that made liberal use of altered gotos
      > eg: ALTER A210 TO GO TO B103.


      ALTER procedure-name-1 TO [PROCEED TO] procedure-name-2.

      where PROCEED and the second TO were (IIRC) not required by the language
      but we always used them, if only because (in those times) COBOL source
      was supposed to be "better" if it resembled English language, so some
      verbosity was preferred over hardly-understandable terseness.

      procedure-name-1 had to be a paragraph with nothing else than a GO TO
      statement in it.

      > that is what the paragraph names were like -- a letter and a number
      > -- they came from the flow charts on which the programs were
      > initially designed, made no sense whatsoever without the flow
      > charts, and of course the flow charts were nowhere to be found

      Where I worked, flow charts had to be religiously kept with the
      program's documentation, and anyway, any of us programmers was quite
      adept at reconstituting a missing flowchart from the source code. But
      finding that a flowchart was missing was a good reason for a serious
      look at the AUTHOR paragraph of the IDENTIFICATION DIVISION --
      well-fleshed-out IDENTIFICATION DIVISIONs were part of the "house style"
      which our senior programmers insisted on when teaching newbies --
      programming degrees didn't exist when I started, and most of the
      learning was done on the job. Another part of that house style was fixed
      columns in the DATA DIVISION, such as VALUE, OCCURS, REDEFINES and
      similar clauses in column 40 and the word PICTURE written in full
      starting in column 52 (so that the "picture" itself always started in
      column 60). (This was fixed-form COBOL on 80-character Hollerith cards,
      remember? It could be saved onto tape, and usually was, but still with
      80-character fixed-length lines.)

      However, what often happened was that bugfixes to the source code
      weren't always mentioned in the flowcharts: if the code and the
      flowcharts don't agree, the code tells you what the program is doing
      now, the analyst's specs (usually) tell you what it ought to do, and the
      flowchart on file usually tells you how the original programmer thought
      the specs should be implemented. When trying to find a bug, all three
      are complementary, plus (for instance in case of a crash) the memory
      dump we got from the operator when a UEP error (Unusual End of Program)
      happened, usually for out-of-range subscript, which in turn most often
      was a symptom of an off-by-one error in the bounds of a PERFORM VARYING
      statement. (No stack trace, we didn't use that, recursive subroutines
      were an unknown thing on those OSes.)

      > now, while trying to wrap your mind around that, imagine the
      > program processes lab results in a hospital, and you either get the
      > modification right or people could wind up dying because the result
      > of their lab test came from some other patient

      :-) Happily for me, maybe, I never worked for a hospital. What I did
      work on was one program for a simulation of a marshalling yard for the
      International Railways Union, various accounting jobs within
      (well-documented) software packages written by other people of the firm,
      some job over a production database, and also (but not in COBOL) keeping
      an eye on the system software (which, in those times, was distributed
      with its source) and writing some assembly-language modules to be called
      from COBOL.

      > i was never quite so glad as when i got out of that hospital and
      > into a nice safe insurance company doing new c++ development
      > oh wait -- yes i was -- when my financial advisor told me i could
      > retire any time now -- tee hee
      > sorry for the bandwidth,

      well, I guess I used much more than you did over the whole of this thread.

      > sc

      Best regards,
      Never let your sense of morals prevent you from doing what is right.
      -- Salvor Hardin, "Foundation"

      You received this message from the "vim_use" maillist.
      For more information, visit http://www.vim.org/maillist.php
    Your message has been successfully submitted and would be delivered to recipients shortly.