In article ,
Doug Miller wrote:
In article ,
(Robert Bonomi) wrote:
In article ,
Doug Miller wrote:
In article , lgb
wrote:
Back in the early days, I had at least one job that required writing
Cobol programs. I was told my Cobol looked like Fortran :-).
Apparently most people didn't even know Cobol had a COMPUTE statement.
No, we just *wish* it didn't. Destroys readability. Except for Fortran
programmers. :-)
Some COBOL code is _intrinsically_ virtually unreadable. without COMPUTE.
Yeah, and a lot of it was written by Fortran or assembler programmers. :-)
Try to imagine what data-decompression algorithms look like in COBOL.
Thank you, I'd rather not.
(It _wasn't_ a matter of choice, that was the *only* language that that
shop used. CICS command-level COBOL, in fact.)
I've always preferred environments where the programmers could use the
appropriate tools for the job.
No choice in this situation. Smallish shop, IBM 4381, 3 'applications'
programers, *zero* 'systems' programmers. COBOL was the only language
product they had licensed.
I was a contractor, that they brought in to 'do the impossible'. Because
I could do d*mn near anything with whatever 'less than appropriate' tools
were available.
Variable width bitfield data is all *sorts* of fun.
To win a bet a number of years ago with a co-worker who claimed it couldn't be
done, I wrote a Cobol-85 program to manipulate individual bits in a
doubleword. It was an interesting intellectual exercise, but one with no
reasonable practical application other than winning a bet.
*GRIN* I had a reputation of "If you want something done, hunt up Bonomi,
tell him it's 'impossible', and stay out of his hair for a couple of weeks."
line after line of
DIVIDE foo INTO bar GIVING baz, REMAINDER quux.
with various
MULTIPLY something BY power_of_two,
ADD this TO that GIVING result.
thrown in, 'as needed'.
Looks familiar.
It's _all_ scratch-pad temporary variables, there's *NO* way to assign
'meaningful' names.
Plus, 'bit twiddling' is an utterly foreign concept to COBOL programmers
in the first place.
Probably why my colleague said it couldn't be done. OTOH, I began my career in
DP with four years in an assembler shop. Wrote two Cobol programs the entire
time; everything else was ALC. So I was intimately familiar with the concept,
and practice, of bit twiddling.
Yuppers. The primary reason it's foreign to COBOL programmers is that the
relevant verbs ('shift', 'mask', 'bitwise and', 'bitwise or', etc.) simply
do not exist in the COBOL vocabulary. If you don't have the concepts, you
can't think in those terms. You have to have been exposed to the concepts
elsewhere, internalized them, and then find 'equivalent functionality'
work-arounds. Knowing about 'modulo' (another verb that doesn't exist in
COBOL) helps greatly in getting down to the 'equivalent functionality'.
There is simply _nothing_ you can do to make that code 'readable' by anyone
other than a systems "guru". And _they_ have to puzzle over it for quite
a while, because it would *never* occur to them to try to do that kind of
thing in _that_ language.
Comments help... if the programmer knows how to write them. :-)
"sometimes". I once had to write an entire page of documentation for
one line of program code. That line of program code reduced to *one*
machine instruction. a 'shift' operation.
The comments were *utterly* lucid, including 'pictures' of exactly what
was going on, and why.
But people couldn't cope with the fact that this shift operation was being
done on a character string and *not* in a multiple of the bits-per-character.
Take a character string, shift it 'x and one-half' characters, and use the
result in an arithmetic comparison was just "too strange" to be believable.
The _internal_ documentation for _what_ that module was doing was six or
seven times the size of the of the functional parts of the PROCEDURE and
DATA divisions combined. And management _still_ put a declaration on the
front of that module forbidding *anyone* but the author to modify it.
I wrote a couple of modules like that myself... including one, in Cobol-85,
that performed closest-match searches of a thousand-element internal table.
The actual search code is only some two dozen lines IIRC, but with comments it
runs around four pages.
My record is that full page, documenting a single line, a single machine
instruction.
And then there's the fun when you get into 'fuzzy' math -- where the precise
value used simply *doesn't* matter.
Example: you have the Julian day-number of the first of this month, you
want the day-number of the first of next month. How do you get it?
The 'obvious' way is to convert to Gregorian, bump the month number
(remembering to handle overflow), and convert the result back to Julian.
Twice as fast, however, is to add 50 to day number, convert that to
Gregorian, and subtract the indicated 'day' of the month less one from the
unconverted day-number. Note: the number '50' is meaningless. _any_ value
between 31 and 59 works. every time.
Now, given the 1st of the month day-number, and you want the 1st of the
month 3 months out. you can do *exactly* the same thing. just using
100 as the number added, instead of 50. Again, '100' is meaningless. any
value between 90 and 120 works.
Lastly, if you have a parameter that is '1' if you want '1 month' out,
and '2' if you want '1 calendar quarter' out. you can simply use
'50*period' as what you add to the day-number. Even scarier, if you define
the values for that parameter as binary flags, then the next value
'4', gets you '6 months', and the successor ('8') gets you 'one year')
This is _amazingly_ useful in all sorts of bookkeeping applications.
But trying to explain _how_ that trivial little "50*period" incantation
accomplishes that magic is *very* involved.
|