Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Fwd: Linux on a small memory PC

377 views
Skip to first unread message

Charlie Gibbs

unread,
Jul 17, 2022, 4:59:54 PM7/17/22
to
[Cross-posted to alt.folklore.computers]

On 2022-07-17, Dan Espen <dan1...@gmail.com> wrote:

> Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:
>
>> On 2022-07-17, 25B.Z959 <25B....@nada.net> wrote:
>>
>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>
>>>> "25B.Z959" <25B....@nada.net> writes:
>>>>
>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>> anymore. Not so in the past - they just assumed 19xx. Saved a
>>>>> little space, easier calx.
>>>>
>>>> There you go, true to form. Now people use 2 digit dates because
>>>> they are cheap.
>>>
>>> You are neglecting Computers Past ..... low speed, low
>>> capacity. You simplified calx, you squeezed-down the data anywhere
>>> you could. I know, I had to do it.
>>
>> Me too. My first job was in an all-card shop. To squeeze things onto
>> an 80-column card, we stored dates in 5 columns as ddmmy. That's
>> right, we only kept the last digit of the year. I started there in
>> 1970, and one of my first assignments was to go through all report
>> programs and change the '6' they inserted in front of the year to '7'.
>
> In an all card shop having more than 1 card for a logical record is a
> problem. Not insurmountable but difficult. I've heard the one digit
> year story in that context but never had to deal with it.

We used two cards for customer name data, but they didn't have dates
in them, just long names. You're right, having more than one card
for a logical record is a pain in the ass. I use the present tense
because I'm still faced with such files today.

For aged accounts receivables, we needed half a dozen cost fields.
To accomodate this, we punched the packed decimal fields into the
cards without unpacking them. The decks were noticeably flimsier
than a normal deck, thanks to all those 12-0-1-8-9 punches.

> Clearly a case of the employer being cheap because he didn't use
> larger cards.

:-)

There were always those Remington-Rand 90-column cards...

Maybe that's why IBM came up with 96-column cards on the
System/3. They wouldn't do it to be incompatible, would
they? Nah...

Fun fact: 96-column cards are exactly as long as 80-column cards
are wide. That probably simplified things for factories that
made both..

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgi...@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

25B.Z959

unread,
Jul 18, 2022, 9:26:30 PM7/18/22
to
Yep - the past IS present ... old records never die, they
just become more inconvenient. :-)

Amazing how many institutions STILL run COBOL apps writ
during the 60s by the guys with skinny ties. They work
very well, they're too expensive to re-do, so ....

There's probably a COBOL->C++ or JAVA translator out
there somewhere ... but money's so tight these days
and so many of those legacy apps are so super-critical
that they just can't/won't.


> For aged accounts receivables, we needed half a dozen cost fields.
> To accomodate this, we punched the packed decimal fields into the
> cards without unpacking them. The decks were noticeably flimsier
> than a normal deck, thanks to all those 12-0-1-8-9 punches.
>
>> Clearly a case of the employer being cheap because he didn't use
>> larger cards.
>
> :-)
>
> There were always those Remington-Rand 90-column cards...
>
> Maybe that's why IBM came up with 96-column cards on the
> System/3. They wouldn't do it to be incompatible, would
> they? Nah...
>
> Fun fact: 96-column cards are exactly as long as 80-column cards
> are wide. That probably simplified things for factories that
> made both..

Surprised they didn't make them one or two millimeters
larger, just to ensure incompatibility :-)

In any case, punch-cards ruled for a long time and you
DID have to squeeze a lot to get yer record to fit on
one of the things. Lots of corners cut, assumptions
made. Tomorrow ? They're paying me for TODAY.

Charlie Gibbs

unread,
Jul 18, 2022, 9:48:25 PM7/18/22
to
On 2022-07-19, 25B.Z959 <25B....@nada.net> wrote:

> On 7/17/22 4:59 PM, Charlie Gibbs wrote:
>
>> We used two cards for customer name data, but they didn't have dates
>> in them, just long names. You're right, having more than one card
>> for a logical record is a pain in the ass. I use the present tense
>> because I'm still faced with such files today.
>
> Yep - the past IS present ... old records never die, they
> just become more inconvenient. :-)

Actually, I'm working with brand-new records. But there are still
many cases where for one reason or another, it takes several physical
records to represent one logical record.

> Amazing how many institutions STILL run COBOL apps writ
> during the 60s by the guys with skinny ties. They work
> very well, they're too expensive to re-do, so ....
>
> There's probably a COBOL->C++ or JAVA translator out
> there somewhere ... but money's so tight these days
> and so many of those legacy apps are so super-critical
> that they just can't/won't.

We must be careful not to sell those guys with the skinny ties short.
Some of them were pretty smart. Newer is not necessarily better -
and wise people won't break a working system for fashion's sake.

25B.Z959

unread,
Jul 18, 2022, 10:29:16 PM7/18/22
to
On 7/18/22 9:48 PM, Charlie Gibbs wrote:
> On 2022-07-19, 25B.Z959 <25B....@nada.net> wrote:
>
>> On 7/17/22 4:59 PM, Charlie Gibbs wrote:
>>
>>> We used two cards for customer name data, but they didn't have dates
>>> in them, just long names. You're right, having more than one card
>>> for a logical record is a pain in the ass. I use the present tense
>>> because I'm still faced with such files today.
>>
>> Yep - the past IS present ... old records never die, they
>> just become more inconvenient. :-)
>
> Actually, I'm working with brand-new records. But there are still
> many cases where for one reason or another, it takes several physical
> records to represent one logical record.


Hmmm ... that big ? ... including photographs/video or the
like ? The traditional solution is to just point to an
external file in yer db record. That has plusses and
minuses though.


>> Amazing how many institutions STILL run COBOL apps writ
>> during the 60s by the guys with skinny ties. They work
>> very well, they're too expensive to re-do, so ....
>>
>> There's probably a COBOL->C++ or JAVA translator out
>> there somewhere ... but money's so tight these days
>> and so many of those legacy apps are so super-critical
>> that they just can't/won't.
>
> We must be careful not to sell those guys with the skinny ties short.
> Some of them were pretty smart. Newer is not necessarily better -
> and wise people won't break a working system for fashion's sake.

They were VERY smart ... built the foundations of what we
all use today. Well-organized too. Sometimes lacking in
'innovation'/'imagination' however ... there are niches
for people like Jobs and I think we gained more on the
hardware level from mere GAMERS than anybody else - their
numbers funded hardware that's proven to be very useful
now for "AI", physical sims and such.

But yes, wise people won't break a working system. I've
seen what happens when un-wise people, eager to follow
the latest fads and buzzwords, get involved.

If you want to see how it all goes bad - just read "Dilbert".

A lot of that old institutional software though, it's
REALLY a case of "We can't afford"/"We don't DARE" -
accounting/scheduling stuff - where "broken" means
You're Dead. That's why "Wally" keeps his job :-)

Oooh ! "Robot Apocalypse" on the tube ! One of my
new favorite "B" flix :-)

Peter Flass

unread,
Jul 19, 2022, 1:48:22 PM7/19/22
to
Maybe these are better than translators I have seen, but old ones produced
unreadable code, and they might well miss some litte tricks that the old
guys put in, and so leave time-bombs in the translated program. Much more
expensive, but a lot better, is to extract the specs from the existing
code, and there are re-engineering programs that can probably do a lot of
that work, and then rewrite in the new language using programmers skilled
in that language.


--
Pete

The Natural Philosopher

unread,
Jul 19, 2022, 2:44:30 PM7/19/22
to
TBH you cant do many tricks in COBOL and the whole thrust of the bloody
language is 'do it by the book, and write the book as documentation, as
well'

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

Peter Flass

unread,
Jul 19, 2022, 2:58:34 PM7/19/22
to
How much would you like to bet? Yes, the language encourages
straightforward programming, but I’ve seen things…

--
Pete

Lew Pitcher

unread,
Jul 19, 2022, 3:49:00 PM7/19/22
to
On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:

> The Natural Philosopher <t...@invalid.invalid> wrote:
>> On 19/07/2022 18:48, Peter Flass wrote:
>>> 25B.Z959 <25B....@nada.net> wrote:
[snip]
>>>> Amazing how many institutions STILL run COBOL apps writ
>>>> during the 60s by the guys with skinny ties. They work
>>>> very well, they're too expensive to re-do, so ....
>>>>
>>>> There's probably a COBOL->C++ or JAVA translator out
>>>> there somewhere ... but money's so tight these days
>>>> and so many of those legacy apps are so super-critical
>>>> that they just can't/won't.
>>>>
>>>
>>> Maybe these are better than translators I have seen, but old ones produced
>>> unreadable code, and they might well miss some litte tricks that the old
>>> guys put in, and so leave time-bombs in the translated program. Much more
>>> expensive, but a lot better, is to extract the specs from the existing
>>> code, and there are re-engineering programs that can probably do a lot of
>>> that work, and then rewrite in the new language using programmers skilled
>>> in that language.
>>>
>>>
>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>> language is 'do it by the book, and write the book as documentation, as
>> well'
>>
>
> How much would you like to bet? Yes, the language encourages
> straightforward programming, but I’ve seen things…

A long time ago, I worked on many COBOL applications, including a
client (PC) / server (MVS) communications application. I've seen
things that I cannot unsee, coded things that I cannot uncode.


--
Lew Pitcher
"In Skills, We Trust"

Peter Flass

unread,
Jul 19, 2022, 3:53:21 PM7/19/22
to
I think I remember reading that someone once coded a compiler in COBOL.


--
Pete

David W. Hodgins

unread,
Jul 19, 2022, 4:30:01 PM7/19/22
to
On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter...@yahoo.com> wrote:
> I think I remember reading that someone once coded a compiler in COBOL.

The strangest trick I encountered was a COBOL program, where the header
for a report was redefined, so the letter C in a character field was
redefined for use as constant with the value +1. That and a few other
characters with similar usage.

All done to keep the executable size under some limit for a mid 1960's system.

I encountered that in the 1980's when I was tasked with debugging why another
persons minor changes caused the program to fail to produce correct results in
testing.

Regards, Dave Hodgins

Dan Espen

unread,
Jul 19, 2022, 4:53:53 PM7/19/22
to
I did a full screen editor in COBOL. It was pretty neat and the code
was good.

The worst COBOL programs were the 10K+ line monsters.

A lot of early COBOL was written from flowcharts full of GOTOs with
little or no structure. Even though the language statements were simple
you still had a mess.


--
Dan Espen

Dan Espen

unread,
Jul 19, 2022, 4:58:00 PM7/19/22
to
I have yet to see an optimizer optimize the literal pool with that
trick. I don't see why.

Why do literals of 'DATE' and 'UPDATE' take 10 bytes when only 6 are needed.


--
Dan Espen

Scott Lurndal

unread,
Jul 19, 2022, 5:22:26 PM7/19/22
to
The disk compression utility on Burroughs Medium Systems mainframes
(called SQUASH) was written in COBOL68. Granted, the compiler was
extended to support inline assembler...

D.J.

unread,
Jul 19, 2022, 7:20:56 PM7/19/22
to
My senior year at university I had two classes; one a compiler i VAX
PASCAL and an assembler in VAX PASCAL.

Oh the sounds of joy from the computer room. Well, there were yells.
--
Jim

Peter Flass

unread,
Jul 19, 2022, 7:32:10 PM7/19/22
to
One of the best things to happen in programming is that (at least some)
programmers learned how to write clean, straightforward, well-documented
code. I’ve looked at some early FORTRAN programs, too, and they’re the
same. Control jumps all over the place, and no one ever, ever, wrote a
comment.

--
Pete

Peter Flass

unread,
Jul 19, 2022, 7:32:11 PM7/19/22
to
Interesting, I don’t do that either, although I think I’ll optimize when
the first characters are the same. Maybe it’s more trouble than it’s worth
to scan the entire literal pool for matches, and, if course if DATE is
encountered first, you’d have to do a lot of rearranging.

These days, of course, we’re awash in memory and it’s not worth doing a lot
of work to save a few bytes; not like the old days.

--
Pete

Anne & Lynn Wheeler

unread,
Jul 19, 2022, 8:26:47 PM7/19/22
to
Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
> A long time ago, I worked on many COBOL applications, including a
> client (PC) / server (MVS) communications application. I've seen
> things that I cannot unsee, coded things that I cannot uncode.

around turn of the century was brought into look at performance of 450K
Cobol statement application that ran on 40+ max configured IBM
mainframes (@$30M, >$1B, number needed to finish batch settlement in
overnight window). They had large group responsible for the performance
care & feeding, but got somewhat myopically focused.

I used some other analysis tools from the IBM science center in the
early 70s and found 14% improvement.

There was another performance consultant that was brought in and found a
different 7% improvement. In the early 70s, there was a CMS\APL-based
analytical system model done at the science center ... which was made
available on the world-wide, branch office, sales & marketing support
online HONE systems as the "Performance Predictor"; branch people could
enter customer's configuration and workload profiles and ask "what-if"
questions about changes in configuration and/or workload. During the IBM
troubles in the early 90s and lots of stuff was being unloaded, the
consultant managed to obtain the rights to a descendant of the
"Performance Predictor", ran it through an APL->C language converter and
was using in for performance consulting business (not just large IBM
mainframes, but other vendors also).

a few past archived a.f.c. posts mentioning the 450k cobol statement app
http://www.garlic.com/~lynn/2006u.html#50 Where can you get a Minor in Mainframe?
http://www.garlic.com/~lynn/2007u.html#21 Distributed Computing
http://www.garlic.com/~lynn/2008c.html#24 Job ad for z/OS systems programmer trainee
http://www.garlic.com/~lynn/2008d.html#73 Price of CPU seconds
http://www.garlic.com/~lynn/2008l.html#81 Intel: an expensive many-core future is ahead of us
http://www.garlic.com/~lynn/2009d.html#5 Why do IBMers think disks are 'Direct Access'?
http://www.garlic.com/~lynn/2009e.html#76 Architectural Diversity
http://www.garlic.com/~lynn/2009f.html#55 Cobol hits 50 and keeps counting
http://www.garlic.com/~lynn/2017k.html#57 When did the home computer die?
http://www.garlic.com/~lynn/2018d.html#2 Has Microsoft commuted suicide
http://www.garlic.com/~lynn/2018f.html#13 IBM today
http://www.garlic.com/~lynn/2019e.html#155 Book on monopoly (IBM)

reference to IBM having one of the largest corporate losses in US
history and was being reorganized into 13 "baby blues" in preparation to
breaking up the company gone behind paywall, but mostly lives free at
wayback machine.
http://web.archive.org/web/20101120231857/http://www.time.com/time/magazine/article/0,9171,977353,00.html
may also work
http://content.time.com/time/subscriber/article/0,33009,977353-1,00.html

--
virtualization experience starting Jan1968, online at home since Mar1970

Charlie Gibbs

unread,
Jul 19, 2022, 8:27:35 PM7/19/22
to
On 2022-07-19, David W. Hodgins <dwho...@nomail.afraid.org> wrote:

> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter...@yahoo.com> wrote:
>
>> I think I remember reading that someone once coded a compiler in COBOL.
>
> The strangest trick I encountered was a COBOL program, where the header
> for a report was redefined, so the letter C in a character field was
> redefined for use as constant with the value +1. That and a few other
> characters with similar usage.

I wrote an assembly language subroutine that I called from the COBOL
program that produced pay cheques for dozens of customers (each on
a unique form, of course). The subroutine found the printer's DDname
in the COBOL program and changed it, so I could have it run cheques
for all customers in a single run without defining a ridiculous number
of printer files. (I still needed a line in the JCL for each one, though.)

Charlie Gibbs

unread,
Jul 19, 2022, 8:27:36 PM7/19/22
to
On 2022-07-19, Dan Espen <dan1...@gmail.com> wrote:

> The worst COBOL programs were the 10K+ line monsters.

I took a look at one of those once. The listings took up almost
a box of paper, spread across dozens of modules. I would have
loved to have gotten my hands on the thing for a few days, but
I had to content myself with changing all the subscripts from
COMP-3 (packed decimal) to COMP-4 (binary), which knocked 30%
off its execution time.

Charlie Gibbs

unread,
Jul 19, 2022, 8:27:37 PM7/19/22
to
On 2022-07-19, Peter Flass <peter...@yahoo.com> wrote:

> One of the best things to happen in programming is that (at least some)
> programmers learned how to write clean, straightforward, well-documented
> code. I’ve looked at some early FORTRAN programs, too, and they’re the
> same. Control jumps all over the place, and no one ever, ever, wrote a
> comment.

Mind you, at the height of the Structured Programming craze, there were
fanatics who would write programs whose control jumped all over the
place - into and out of a ridiculous number of subroutines whose length
varied from 1 to 10 lines. There wasn't a single GOTO, but remember
that a subroutine call is just a GOTO paired with a "come from".
It's still spaghetti code, just with double strands.

Charlie Gibbs

unread,
Jul 19, 2022, 8:27:38 PM7/19/22
to
On 2022-07-19, Peter Flass <peter...@yahoo.com> wrote:

BTDTGTS (been there, done that, got the scars)

I once wrote a COBOL program that built and parsed terminal control
sequences. And this was before STRING and UNSTRING.

> I think I remember reading that someone once coded a compiler in COBOL.

A friend of mine wrote an 8080 cross-assembler in COBOL.
It ran rings around the Univac-issued cross-assembler -
which was written in FORTRAN.

Charlie Gibbs

unread,
Jul 19, 2022, 8:27:38 PM7/19/22
to
On 2022-07-19, Peter Flass <peter...@yahoo.com> wrote:

> These days, of course, we’re awash in memory and it’s not worth doing
> a lot of work to save a few bytes; not like the old days.

In _The Mythical Man-Month_, Fred Brooks describes the decision to save
100 bytes by not having the date routine handle leap years.

Peter Flass

unread,
Jul 19, 2022, 9:10:44 PM7/19/22
to
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2022-07-19, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>
>> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter...@yahoo.com> wrote:
>>
>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> The strangest trick I encountered was a COBOL program, where the header
>> for a report was redefined, so the letter C in a character field was
>> redefined for use as constant with the value +1. That and a few other
>> characters with similar usage.
>
> I wrote an assembly language subroutine that I called from the COBOL
> program that produced pay cheques for dozens of customers (each on
> a unique form, of course). The subroutine found the printer's DDname
> in the COBOL program and changed it, so I could have it run cheques
> for all customers in a single run without defining a ridiculous number
> of printer files. (I still needed a line in the JCL for each one, though.)
>

Lots of games. I did something similar for PL/I to read all members of a
PDS. i read the directory and then modified the member name in the JFCB for
each. The SHARE TAPECOPY program scanned the TIOT to determine how many
copies to make.

--
Pete

Peter Flass

unread,
Jul 19, 2022, 9:10:44 PM7/19/22
to
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>> A long time ago, I worked on many COBOL applications, including a
>> client (PC) / server (MVS) communications application. I've seen
>> things that I cannot unsee, coded things that I cannot uncode.
>
> around turn of the century was brought into look at performance of 450K
> Cobol statement application that ran on 40+ max configured IBM
> mainframes (@$30M, >$1B, number needed to finish batch settlement in
> overnight window). They had large group responsible for the performance
> care & feeding, but got somewhat myopically focused.
>
> I used some other analysis tools from the IBM science center in the
> early 70s and found 14% improvement.
>
> There was another performance consultant that was brought in and found a
> different 7% improvement.

I’m not a performance guru, but it seems like only 15-20% improvement in
old code that’s probably been beat up for years would indicate the code was
fairly decent to begin with. I would expect that, properly written - no
USAGE IS DISPLAY for computational fields, etc. - COBOL would be a pretty
efficient language. C used to be lean and mean, too, but (IMO) a lot of
cruft has been added to GCC. COBOL would have to be an order of magnitude
faster than any object-oriented stuff, but efficiency has never been a top
goal for OO languages, far behind ease of coding and maintenance.

--
Pete

Peter Flass

unread,
Jul 19, 2022, 9:10:45 PM7/19/22
to
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2022-07-19, Dan Espen <dan1...@gmail.com> wrote:
>
>> The worst COBOL programs were the 10K+ line monsters.
>
> I took a look at one of those once. The listings took up almost
> a box of paper, spread across dozens of modules. I would have
> loved to have gotten my hands on the thing for a few days, but
> I had to content myself with changing all the subscripts from
> COMP-3 (packed decimal) to COMP-4 (binary), which knocked 30%
> off its execution time.
>

A few simple things might give 75% of the possible improvement.

--
Pete

25B.Z959

unread,
Jul 19, 2022, 10:34:48 PM7/19/22
to
Got any of it on a floppy or print-out anywhere ? I'd
love to see how to do client/server only using COBOL.

Yea, you could do it in BASIC too ... with lots of
DATA statements. I remember converting a Fortran
pgm to IBMPC BASIC, but had to work that newfangled
8087 the hard way using DATA. 8087s are weird. Yuk !

COBOL was deliberately made to do "business stuff" in a
super-wordy fashion that was SUPPOSED to be "self documenting".
Maybe the only language requiring more text than Java :-)

Lew Pitcher

unread,
Jul 19, 2022, 10:51:03 PM7/19/22
to
Both client and server used the same COBOL codebase, but with
different compilers and operating environments.

The client was coded in Microfocus "Visual Object (VISOC)" COBOL
and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
(terminal communications) connection.

The server was coded in IBM COBOL and ran under IMS DC on an MVS
system, using an SNA terminal LU as it's communications endpoint.

As this was an in-house "inner platform" project (3 tier client/server
architecture, circa 1990), I did not keep personal copies of any
of the code. Suffice it to say that my first question to the architect,
my first day on that project, was "Why COBOL?" The answer was "Because
that's what the coders know."

> Yea, you could do it in BASIC too ... with lots of
> DATA statements. I remember converting a Fortran
> pgm to IBMPC BASIC, but had to work that newfangled
> 8087 the hard way using DATA. 8087s are weird. Yuk !
>
> COBOL was deliberately made to do "business stuff" in a
> super-wordy fashion that was SUPPOSED to be "self documenting".

Agreed. That was the defining component of COBOL, and perhaps it's
saving grace.

> Maybe the only language requiring more text than Java :-)

Those of us who coded COBOL for a living kept a boilerplate^W
template program handy, just so we didn't have to fill in all that
language /just/ to get a program started.

Dan Espen

unread,
Jul 19, 2022, 11:21:22 PM7/19/22
to
Yep, why would they? The flowchart was the documentation.

--
Dan Espen

Dan Espen

unread,
Jul 19, 2022, 11:31:48 PM7/19/22
to
Peter Flass <peter...@yahoo.com> writes:

> Dan Espen <dan1...@gmail.com> wrote:
>> "David W. Hodgins" <dwho...@nomail.afraid.org> writes:
>>
>>> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter...@yahoo.com> wrote:
>>>> I think I remember reading that someone once coded a compiler in COBOL.
>>>
>>> The strangest trick I encountered was a COBOL program, where the header
>>> for a report was redefined, so the letter C in a character field was
>>> redefined for use as constant with the value +1. That and a few other
>>> characters with similar usage.
>>>
>>> All done to keep the executable size under some limit for a mid 1960's system.
>>>
>>> I encountered that in the 1980's when I was tasked with debugging why another
>>> persons minor changes caused the program to fail to produce correct results in
>>> testing.
>>
>> I have yet to see an optimizer optimize the literal pool with that
>> trick. I don't see why.
>>
>> Why do literals of 'DATE' and 'UPDATE' take 10 bytes when only 6 are needed.
>
> Interesting, I don’t do that either, although I think I’ll optimize when
> the first characters are the same. Maybe it’s more trouble than it’s worth
> to scan the entire literal pool for matches, and, if course if DATE is
> encountered first, you’d have to do a lot of rearranging.

Here's a first try:

Sort largest stuff first.
Then from the back, look from the front to find targets.
When you find a target at a higher address stop.
Remove the gaps at the end.

> These days, of course, we’re awash in memory and it’s not worth doing a lot
> of work to save a few bytes; not like the old days.

Yeah but an optimizer is supposed to save space and a smaller literal
pool is good for the cache.

--
Dan Espen

Dan Espen

unread,
Jul 19, 2022, 11:37:24 PM7/19/22
to
Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:

> On 2022-07-19, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>
>> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter...@yahoo.com> wrote:
>>
>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> The strangest trick I encountered was a COBOL program, where the header
>> for a report was redefined, so the letter C in a character field was
>> redefined for use as constant with the value +1. That and a few other
>> characters with similar usage.
>
> I wrote an assembly language subroutine that I called from the COBOL
> program that produced pay cheques for dozens of customers (each on
> a unique form, of course). The subroutine found the printer's DDname
> in the COBOL program and changed it, so I could have it run cheques
> for all customers in a single run without defining a ridiculous number
> of printer files. (I still needed a line in the JCL for each one, though.)

Current mainframe COBOL will let you call dynalloc.

--
Dan Espen

Dan Espen

unread,
Jul 19, 2022, 11:40:48 PM7/19/22
to
Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:

> On 2022-07-19, Peter Flass <peter...@yahoo.com> wrote:
>
>> Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
>>
>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>
>>>> The Natural Philosopher <t...@invalid.invalid> wrote:
>>>>
>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>> well'
>>>>
>>>> How much would you like to bet? Yes, the language encourages
>>>> straightforward programming, but I’ve seen things…
>>>
>>> A long time ago, I worked on many COBOL applications, including a
>>> client (PC) / server (MVS) communications application. I've seen
>>> things that I cannot unsee, coded things that I cannot uncode.
>
> BTDTGTS (been there, done that, got the scars)
>
> I once wrote a COBOL program that built and parsed terminal control
> sequences. And this was before STRING and UNSTRING.

You can do wonders with OCCURS DEPENDING ON, pretty much any kind of
string processing you want.

--
Dan Espen

Ahem A Rivet's Shot

unread,
Jul 20, 2022, 2:00:02 AM7/20/22
to
On Wed, 20 Jul 2022 00:27:35 GMT
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:

> Mind you, at the height of the Structured Programming craze, there were
> fanatics who would write programs whose control jumped all over the
> place - into and out of a ridiculous number of subroutines whose length
> varied from 1 to 10 lines. There wasn't a single GOTO, but remember
> that a subroutine call is just a GOTO paired with a "come from".
> It's still spaghetti code, just with double strands.

This approach has reached it's zenith in some "Enterprise Java"
houses where it isn't tiny subroutines but classes that proliferate madly.

Firstly everything is an Enterprise Java Bean - which means that it
is an object with set and get functions for all member variables (that
*must* be used) and some conventional methods. Secondly everything has to
follow a "design pattern" and wear this on it's sleeve in the form of
paragraph long class names. For anything like a data type there will be
data access, transfer and model objects (at least) and there will be
interface classes, facade classes and at least one implementation class
for everything. Thirdly all methods must be short, mindlessly simple and
independently testable - complexity *must* live in the object structure not
the method code. Finally logging, tracking, performance measuring, etc
hooks are routinely levered into the code using aspect weaving.

Most programmers use IDEs that are basically code generators with
GUIs so they never have to think about all the boilerplate.

Debugging can be frustrating.

Oh yes testing - automated unit testing is required usually with
very high line and branch coverage. Sounds great right ? But the simplicity
of the routines and the requirement that tests be true unit tests with every
external dependency mocked means that the tests are usually tightly coupled
to the code and have to be changed for every code change which rather
defeats the point.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

Richard Kettlewell

unread,
Jul 20, 2022, 3:25:22 AM7/20/22
to
Dan Espen <dan1...@gmail.com> writes:
> "David W. Hodgins" <dwho...@nomail.afraid.org> writes:
>
>> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter...@yahoo.com> wrote:
>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> The strangest trick I encountered was a COBOL program, where the header
>> for a report was redefined, so the letter C in a character field was
>> redefined for use as constant with the value +1. That and a few other
>> characters with similar usage.
>>
>> All done to keep the executable size under some limit for a mid 1960's system.
>>
>> I encountered that in the 1980's when I was tasked with debugging why another
>> persons minor changes caused the program to fail to produce correct results in
>> testing.
>
> I have yet to see an optimizer optimize the literal pool with that
> trick. I don't see why.

GCC and Clang both do it.

--
https://www.greenend.org.uk/rjk/

Kerr-Mudd, John

unread,
Jul 20, 2022, 5:06:24 AM7/20/22
to
On Wed, 20 Jul 2022 02:50:57 -0000 (UTC)
Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
[]
>
> Those of us who coded COBOL for a living kept a boilerplate^W
> template program handy, just so we didn't have to fill in all that
> language /just/ to get a program started.
>
Ah that old chestnut: "I'll start coding, you go and find out what the user
wants".


--
Bah, and indeed Humbug.

The Natural Philosopher

unread,
Jul 20, 2022, 6:42:41 AM7/20/22
to
On 19/07/2022 19:58, Peter Flass wrote:
> The Natural Philosopher <t...@invalid.invalid> wrote:
>> On 19/07/2022 18:48, Peter Flass wrote:
>>> 25B.Z959 <25B....@nada.net> wrote:
>>>> On 7/17/22 4:59 PM, Charlie Gibbs wrote:
>>>>> [Cross-posted to alt.folklore.computers]
>>>>>
>>>>> On 2022-07-17, Dan Espen <dan1...@gmail.com> wrote:
>>>>>
>>>>>> Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:
>>>>>>
>>>>>>> On 2022-07-17, 25B.Z959 <25B....@nada.net> wrote:
>>>>>>>
>>>>>>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>>>>>>
>>>>>>>>> "25B.Z959" <25B....@nada.net> writes:
>>>>>>>>>
>>>>>>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>>>>>>> anymore. Not so in the past - they just assumed 19xx. Saved a
>>>>>>>>>> little space, easier calx.
>>>>>>>>>
>>>>>>>>> There you go, true to form. Now people use 2 digit dates because
>>>>>>>>> they are cheap.
>>>>>>>>
>>>>>>>> You are neglecting Computers Past ..... low speed, low
>>>>>>>> capacity. You simplified calx, you squeezed-down the data anywhere
>>>>>>>> you could. I know, I had to do it.
>>>>>>>
>>>>>>> Me too. My first job was in an all-card shop. To squeeze things onto
>>>>>>> an 80-column card, we stored dates in 5 columns as ddmmy. That's
>>>>>>> right, we only kept the last digit of the year. I started there in
>>>>>>> 1970, and one of my first assignments was to go through all report
>>>>>>> programs and change the '6' they inserted in front of the year to '7'.
>>>>>>
>>>>>> In an all card shop having more than 1 card for a logical record is a
>>>>>> problem. Not insurmountable but difficult. I've heard the one digit
>>>>>> year story in that context but never had to deal with it.
>>>>>
>>>>> We used two cards for customer name data, but they didn't have dates
>>>>> in them, just long names. You're right, having more than one card
>>>>> for a logical record is a pain in the ass. I use the present tense
>>>>> because I'm still faced with such files today.
>>>>
>>>>
>>>> Yep - the past IS present ... old records never die, they
>>>> just become more inconvenient. :-)
>>>>
>>>> Amazing how many institutions STILL run COBOL apps writ
>>>> during the 60s by the guys with skinny ties. They work
>>>> very well, they're too expensive to re-do, so ....
>>>>
>>>> There's probably a COBOL->C++ or JAVA translator out
>>>> there somewhere ... but money's so tight these days
>>>> and so many of those legacy apps are so super-critical
>>>> that they just can't/won't.
>>>>
>>>
>>> Maybe these are better than translators I have seen, but old ones produced
>>> unreadable code, and they might well miss some litte tricks that the old
>>> guys put in, and so leave time-bombs in the translated program. Much more
>>> expensive, but a lot better, is to extract the specs from the existing
>>> code, and there are re-engineering programs that can probably do a lot of
>>> that work, and then rewrite in the new language using programmers skilled
>>> in that language.
>>>
>>>
>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>> language is 'do it by the book, and write the book as documentation, as
>> well'
>>
>
> How much would you like to bet? Yes, the language encourages
> straightforward programming, but I’ve seen things…
>
COBOL IME was generally written by teams of coders after the analysts
had written the specification, to strict coding standards which if not
adhered to got you the sack.


--
“But what a weak barrier is truth when it stands in the way of an
hypothesis!”

Mary Wollstonecraft

The Natural Philosopher

unread,
Jul 20, 2022, 6:47:31 AM7/20/22
to
On 20/07/2022 01:27, Charlie Gibbs wrote:
> remember
> that a subroutine call is just a GOTO paired with a "come from".
> It's still spaghetti code, just with double strands.
LOL!

It's just another example of 'rules are for the guidance of wise ,men,
and the obedience of idiots'

The goal was clear understandable program flow. Sometimes an 'Go
immediately to jail, do not collect $200' is in fact easier to understand

--
"And if the blind lead the blind, both shall fall into the ditch".

Gospel of St. Mathew 15:14

The Natural Philosopher

unread,
Jul 20, 2022, 7:00:20 AM7/20/22
to
On 20/07/2022 02:10, Peter Flass wrote:
> but efficiency has never been a top
> goal for OO languages, far behind ease of coding and maintenance.

You might say that, I couldn't possibly comment.

But I will.
In many cases OO is a round hole into which far too many square
procedural pegs are forced.

This makes it very slow to code, and very hard to maintain/.

The beauty of C for me is that you could write it like assembler for
speed, or you could use its ability to limit lexical scope to write what
were essentially objects.
The ability to create efficient local storage using te stack, was
superb. Of course the downside of overwriting buffers and thesreturn
address with ugly unchecked code was not great.
But if you want to use a chainsaw, dont fuck around., Follow the basic rules

Todays OO is like to days suburban streets. Slow suspension smashing
fuel guzzling dangerous nightmares designed to force people to adopt
what good drivers do anyway. Take care not to kill other people.

So that complete idiots can now write code, And, I am afraid, it shows.
The quality of public websites is execrable.,: I cant recount the number
of minutes I have wasted on the phone with a person struggling at the
other end to make the 'new computer system' find my records, by
searching on one of up to ten different screens...only to find that
whilst the code to add new customers has been finely optimised, the code
to remove on does not even exist.

I think that writing a flow chart or a state diagram is a discipline
that programmers might well learn, instead of creation a dictionary of
objects..

Scott Lurndal

unread,
Jul 20, 2022, 9:50:56 AM7/20/22
to
Peter Flass <peter...@yahoo.com> writes:
>Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>>> A long time ago, I worked on many COBOL applications, including a
>>> client (PC) / server (MVS) communications application. I've seen
>>> things that I cannot unsee, coded things that I cannot uncode.
>>
>> around turn of the century was brought into look at performance of 450K
>> Cobol statement application that ran on 40+ max configured IBM
>> mainframes (@$30M, >$1B, number needed to finish batch settlement in
>> overnight window). They had large group responsible for the performance
>> care & feeding, but got somewhat myopically focused.
>>
>> I used some other analysis tools from the IBM science center in the
>> early 70s and found 14% improvement.
>>
>> There was another performance consultant that was brought in and found a
>> different 7% improvement.
>
>I’m not a performance guru, but it seems like only 15-20% improvement in
>old code that’s probably been beat up for years would indicate the code was
>fairly decent to begin with.

Or it would indicate that the code was so poorly written that it would
take a complete rewrite to make it perform better.

Peter Flass

unread,
Jul 20, 2022, 1:04:42 PM7/20/22
to
The Natural Philosopher <t...@invalid.invalid> wrote:
> On 20/07/2022 01:27, Charlie Gibbs wrote:
>> remember
>> that a subroutine call is just a GOTO paired with a "come from".
>> It's still spaghetti code, just with double strands.
> LOL!
>
> It's just another example of 'rules are for the guidance of wise ,men,
> and the obedience of idiots'
>
> The goal was clear understandable program flow. Sometimes an 'Go
> immediately to jail, do not collect $200' is in fact easier to understand
>

I usually try to write structured code, but sometimes a GOTO is the best
way to get out of someplace several levels deep.

--
Pete

Peter Flass

unread,
Jul 20, 2022, 1:04:42 PM7/20/22
to
Maybe in some places, but that wasn’t the rule as I’ve seen it. Most shops
had programmer/analysts where one individual was assigned to work with the
customers, design the system, and do the programming, testing, conversion,
etc. I worked one place that had a separate analyst group, and that
engendered a lot of griping among the programmers. Fortunately by that time
I was a sysprog and didn’t have to deal with that foolishness.

--
Pete

Peter Flass

unread,
Jul 20, 2022, 1:04:43 PM7/20/22
to
The Natural Philosopher <t...@invalid.invalid> wrote:
I occasionally still do both.

--
Pete

Peter Flass

unread,
Jul 20, 2022, 1:04:44 PM7/20/22
to
There’s always that, too.

--
Pete

Charlie Gibbs

unread,
Jul 20, 2022, 1:16:39 PM7/20/22
to
Who needs a flow chart? "My {program|language} is so readable
that you don't need comments."

Charlie Gibbs

unread,
Jul 20, 2022, 1:16:39 PM7/20/22
to
Been there, done that - although I was on the receiving end of:
"You start coding, I'll find out what the user wants."

Charlie Gibbs

unread,
Jul 20, 2022, 1:16:40 PM7/20/22
to
On 2022-07-20, Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:

> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>
>> Got any of it on a floppy or print-out anywhere ? I'd
>> love to see how to do client/server only using COBOL.

<snip>

> As this was an in-house "inner platform" project (3 tier client/server
> architecture, circa 1990), I did not keep personal copies of any
> of the code.

Indeed, that wasn't common practice in those days. Besides, before
personal computers, what would you keep it on that you could read
at home? Mind you, if I look hard I might be able to find a COBOL
program I wrote to convert a report to PostScript, which we sent
to an Apple Laserwriter we had lying around.

> Suffice it to say that my first question to the architect,
> my first day on that project, was "Why COBOL?" The answer was "Because
> that's what the coders know."

The only reason everyone uses COBOL is that everyone uses COBOL.
-- me

>> COBOL was deliberately made to do "business stuff" in a
>> super-wordy fashion that was SUPPOSED to be "self documenting".
>
> Agreed. That was the defining component of COBOL, and perhaps it's
> saving grace.

One day, our inside sales manager, Al Tannock (a bit of a wit -
in his own mind, at least), walked in and said to our new DP manager
(more than a bit of a wit in reality): "Say something in COBOL."

Without hesitation our guy shot back:

EXAMINE ROOM REPLACING ALL TANNOCKS WITH SPACES.

>> Maybe the only language requiring more text than Java :-)
>
> Those of us who coded COBOL for a living kept a boilerplate^W
> template program handy, just so we didn't have to fill in all that
> language /just/ to get a program started.

Heck, I still do that today in C.

Charlie Gibbs

unread,
Jul 20, 2022, 1:16:41 PM7/20/22
to
On 2022-07-20, The Natural Philosopher <t...@invalid.invalid> wrote:

> COBOL IME was generally written by teams of coders after the analysts
> had written the specification, to strict coding standards which if not
> adhered to got you the sack.

I once wrote some programs in a shop where I was given specs that were
so detailed that I could probably have written a compiler for them.
Unfortunately, I identified a number of cases that the specs didn't cover.
When I asked about this, I was given the answer which is now at the top
of my list of Famous Last Words: "Oh, don't worry about that - it'll
never happen." Since I had enough experience by this time to know that
"never" is usually about six months, I refused to proceed until all
cases were accounted for. Beware of nasal demons!

As for coding standards, this shop's standards were so inefficient
that it would take a job half an hour just to schedule, let alone run.
I threw their precious standards into the trash can and wrote the system
my way, which scheduled and ran in 30 seconds. When I was met with
the predictable howls of anguish, I told them that I wanted to get things
tested in a reasonable amount of time, and if they really wanted their
standards that badly they could change it back when I was done.
I doubt they ever did.

Kerr-Mudd, John

unread,
Jul 20, 2022, 3:09:36 PM7/20/22
to
On Wed, 20 Jul 2022 17:16:37 GMT
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:

> On 2022-07-20, Kerr-Mudd, John <ad...@127.0.0.1> wrote:
>
> > On Wed, 20 Jul 2022 02:50:57 -0000 (UTC)
> > Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
> > []
> >
> >> Those of us who coded COBOL for a living kept a boilerplate^W
> >> template program handy, just so we didn't have to fill in all that
> >> language /just/ to get a program started.
> >
> > Ah that old chestnut: "I'll start coding, you go and find out what the user
> > wants".
>
> Been there, done that - although I was on the receiving end of:
> "You start coding, I'll find out what the user wants."
>
I may have mis-remembered; your phrasing sounds better.

Lew Pitcher

unread,
Jul 20, 2022, 3:30:57 PM7/20/22
to
Shops differ. We had a very involved user community, and no lack
of requirements and specifications. Our task, as architects,
designers, and developers, was to keep up with our users. It didn't
hurt that we had both regulatory and fiduciary requirements and
deadlines to satisfy as well. Such is life in a big bank.

J. Clarke

unread,
Jul 20, 2022, 6:42:01 PM7/20/22
to
On Mon, 18 Jul 2022 21:26:23 -0400, "25B.Z959" <25B....@nada.net>
And now some poor schmuck in India has to deal with it all.

J. Clarke

unread,
Jul 20, 2022, 6:43:35 PM7/20/22
to
>Maybe these are better than translators I have seen, but old ones produced
>unreadable code, and they might well miss some litte tricks that the old
>guys put in, and so leave time-bombs in the translated program. Much more
>expensive, but a lot better, is to extract the specs from the existing
>code, and there are re-engineering programs that can probably do a lot of
>that work, and then rewrite in the new language using programmers skilled
>in that language.

Good luck with that. Figuring out the spec from the code can be an
immense undertaking.

Charlie Gibbs

unread,
Jul 20, 2022, 7:09:18 PM7/20/22
to
All too often, users don't know what they want - although when
you give them something, they know immediately that it's _not_
what they want. Insert a sales rep between you and the user
and it gets much worse.

Dan Espen

unread,
Jul 20, 2022, 8:44:49 PM7/20/22
to
sc...@slp53.sl.home (Scott Lurndal) writes:

> Peter Flass <peter...@yahoo.com> writes:
>>Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>>> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>>>> A long time ago, I worked on many COBOL applications, including a
>>>> client (PC) / server (MVS) communications application. I've seen
>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>
>>> around turn of the century was brought into look at performance of 450K
>>> Cobol statement application that ran on 40+ max configured IBM
>>> mainframes (@$30M, >$1B, number needed to finish batch settlement in
>>> overnight window). They had large group responsible for the performance
>>> care & feeding, but got somewhat myopically focused.
>>>
>>> I used some other analysis tools from the IBM science center in the
>>> early 70s and found 14% improvement.
>>>
>>> There was another performance consultant that was brought in and found a
>>> different 7% improvement.
>>
>>I’m not a performance guru, but it seems like only 15-20% improvement in
>>old code that’s probably been beat up for years would indicate the code was
>>fairly decent to begin with.
>
> Or it would indicate that the code was so poorly written that it would
> take a complete rewrite to make it perform better.

The IBM COBOL compilers had an option that could slow binary arithmetic
to a crawl. So, you could change a compiler option and see an 80% change.

--
Dan Espen

Ahem A Rivet's Shot

unread,
Jul 21, 2022, 1:30:03 AM7/21/22
to
On Wed, 20 Jul 2022 18:43:30 -0400
J. Clarke <jclarke...@gmail.com> wrote:

> Good luck with that. Figuring out the spec from the code can be an
> immense undertaking.

One which will inevitably lead to asking whether something is a bug
or a feature with no guidelines to help.

Ahem A Rivet's Shot

unread,
Jul 21, 2022, 1:30:03 AM7/21/22
to
On Wed, 20 Jul 2022 23:09:16 GMT
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:

> All too often, users don't know what they want - although when
> you give them something, they know immediately that it's _not_
> what they want.

This is the main reason incremental development is such a good
idea. I'm just not sure how we got from feature driven incremental
development to "Scaled Agile" with it's nested iteration cycles and
constant "ceremonies" with user stories that must fit in a sprint and epics
that must fit in an iteration and an implicit theory that any developer can
take any task.

Charlie Gibbs

unread,
Jul 21, 2022, 1:42:30 PM7/21/22
to
Sounds like a lot of pomp and ceremony. People love that.
Death marches are so romantic - if you're not the one doing it.

Charlie Gibbs

unread,
Jul 21, 2022, 1:42:31 PM7/21/22
to
On 2022-07-21, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

> On Wed, 20 Jul 2022 18:43:30 -0400
> J. Clarke <jclarke...@gmail.com> wrote:
>
>> Good luck with that. Figuring out the spec from the code can be an
>> immense undertaking.
>
> One which will inevitably lead to asking whether something is a bug
> or a feature with no guidelines to help.

At this point it's time to talk to the users, find out what they
actually need, and make an executive decision. This is time-consuming
and politically hazardous, but it's the only clean solution.
Beware of cargo-cult programming!

Ahem A Rivet's Shot

unread,
Jul 21, 2022, 2:30:03 PM7/21/22
to
On Thu, 21 Jul 2022 17:42:28 GMT
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:

> On 2022-07-21, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> > On Wed, 20 Jul 2022 23:09:16 GMT
> > Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> >
> >> All too often, users don't know what they want - although when
> >> you give them something, they know immediately that it's _not_
> >> what they want.
> >
> > This is the main reason incremental development is such a good
> > idea. I'm just not sure how we got from feature driven incremental
> > development to "Scaled Agile" with it's nested iteration cycles and
> > constant "ceremonies" with user stories that must fit in a sprint and
> > epics that must fit in an iteration and an implicit theory that any
> > developer can take any task.
>
> Sounds like a lot of pomp and ceremony. People love that.
> Death marches are so romantic - if you're not the one doing it.

It is a lot of pomp and ceremony. The iteration planning meeting
that happens every eight weeks and involves *everyone* in all the teams on
the project in *one* room and is supposed to resolve all the inter-team
dependencies has to be the most unproductive waste of two days I have ever
seen. It creates jobs for quite a few "agile practitioners" too.

Oh yes one of the four two week sprints in the iteration is supposed
to be for tech debt, tool sharpening and overflow from the other three.
Guess which of the three fill it up *every* time.

My PPOE was adopting this just before I bailed and found someone
saner to work for.

Ahem A Rivet's Shot

unread,
Jul 21, 2022, 3:00:02 PM7/21/22
to
On Thu, 21 Jul 2022 17:42:29 GMT
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:

> On 2022-07-21, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> > On Wed, 20 Jul 2022 18:43:30 -0400
> > J. Clarke <jclarke...@gmail.com> wrote:
> >
> >> Good luck with that. Figuring out the spec from the code can be an
> >> immense undertaking.
> >
> > One which will inevitably lead to asking whether something is a
> > bug or a feature with no guidelines to help.
>
> At this point it's time to talk to the users, find out what they
> actually need, and make an executive decision. This is time-consuming

Discover that 70% have no idea, 20% find it an irritating bug that
they've been working round for decades and 10% depend on it and couldn't
get their work done without it.

> and politically hazardous, but it's the only clean solution.
> Beware of cargo-cult programming!

Ho yus!

25B.Z959

unread,
Jul 22, 2022, 1:54:15 AM7/22/22
to
On 7/19/22 7:20 PM, D.J. wrote:
> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
> <peter...@yahoo.com> wrote:
>> Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>
>>>> The Natural Philosopher <t...@invalid.invalid> wrote:
>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>> 25B.Z959 <25B....@nada.net> wrote:
>>> [snip]
>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>
>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>> there somewhere ... but money's so tight these days
>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>> that they just can't/won't.
>>>>>>>
>>>>>>
>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>> in that language.
>>>>>>
>>>>>>
>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>> well'
>>>>>
>>>>
>>>> How much would you like to bet? Yes, the language encourages
>>>> straightforward programming, but I’ve seen things…
>>>
>>> A long time ago, I worked on many COBOL applications, including a
>>> client (PC) / server (MVS) communications application. I've seen
>>> things that I cannot unsee, coded things that I cannot uncode.
>>>
>>>
>>
>> I think I remember reading that someone once coded a compiler in COBOL.
>
> My senior year at university I had two classes; one a compiler i VAX
> PASCAL and an assembler in VAX PASCAL.
>
> Oh the sounds of joy from the computer room. Well, there were yells.


Pascal is a GOOD language - and with modern extensions
can do anything 'C' can do ... but more readably. I use
Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
compiler and write stuff in it for fun (and potential
function) sometimes.

Now olde-tyme by-the-book Wirth Pascal ... that'd be a
bit harder to write a compiler with ...

Tauno Voipio

unread,
Jul 22, 2022, 5:48:26 AM7/22/22
to
Urs Ammann, Kesav Nori and Christian Jacobi did exactly that.

They coded the original ETH Pascal compiler in Pascal and
bootstrapped it to compile itself.

I think that I may still have the listings somewhere.

--

-TV

Scott Lurndal

unread,
Jul 22, 2022, 9:03:50 AM7/22/22
to
"25B.Z959" <25B....@nada.net> writes:
>On 7/19/22 7:20 PM, D.J. wrote:
>> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass

>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> My senior year at university I had two classes; one a compiler i VAX
>> PASCAL and an assembler in VAX PASCAL.
>>
>> Oh the sounds of joy from the computer room. Well, there were yells.
>
>
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...

Yet our college undergraduate compiler coure built a Pascal
compiler using pretty-close-to-by-the-book Wirth Pascal
(although the more advanced students realized that since
we were using VAX Pascal, one could use those features
to make things a bit simpler).

G.K.

unread,
Jul 22, 2022, 10:19:30 AM7/22/22
to
On 7/22/22 00:54, 25B.Z959 wrote:
>
>   Pascal is a GOOD language - and with modern extensions
>   can do anything 'C' can do ... but more readably. I use
>   Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
>   compiler and write stuff in it for fun (and potential
>   function) sometimes.
>
>   Now olde-tyme by-the-book Wirth Pascal ... that'd be a
>   bit harder to write a compiler with ...

With freepascal it is now possible to compile EFI / PE executables so
you can write bootable applications.

Does anyone know of any FPC tools for easing the creations of both BIOS
and EFI bootloaders? I wouldn't know the first thing about FPC syntax
for handing boot and ring 0 to a kernel program.

--

G.K.


D.J.

unread,
Jul 22, 2022, 10:21:55 AM7/22/22
to
On Fri, 22 Jul 2022 01:54:08 -0400, "25B.Z959" <25B....@nada.net>
wrote:
We didn't deal with real numbers, just integers and text. This was
about 1988/89. And for the assembler, a limited list. It still took us
the entire time to write it. Not much, just a few thousand lines of
code, and a big chunk of comments as the professor wanted to see if we
understood what we had done. :-)

--
Jim

Anne & Lynn Wheeler

unread,
Jul 22, 2022, 7:42:00 PM7/22/22
to
"25B.Z959" <25B....@nada.net> writes:
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...

(IBM) Los Gatos VLSI lab was doing a lot of language stuff with
Metaware's TWS ... and then used it for mainframe pascal compiler for
VLSI tool development ... eventually released as VS/PASCAL, was also
used to the original mainframe TCP/IP support.

Releasing mainframe TCP/IP support was big battle with the (SNA)
communication group ... they eventually decided it had to be released
through them which got 44kbyte/sec aggregate throughput using nearly
whole 3090 CPU. I then did the support for RFC1044 and in some turning
tests at Cray Research, between 4341 and Cray, got sustained 4341
channel throughput using only modest amount of 4341 cpu (something like
500 times improvement in bytes moved per instruction executed). I've
often commented the VS/pascal implementation had none of the
buffer/length problems that were epidemic in c language implementations.

After leaving IBM in the early 90s ... during IBM downturn, a lot of
stuff was being offloading ... including lots of chip tool applications
to industry tool vendors ... however industry standard platform was SUN
... so all these apps had to be ported to SUN platform.

LSG hires me to port a 50,000 VS/PASCAL statement app to SUN. Enormous
amount of problems 1) I don't think SUN pascal had ever been used for
anything other than educational/instructional and 2) SUN had outsourced
pascal support to organization 12 times zones away on the opposite of
the world (easy drive to drop into SUN hdqtrs ... but didn't do much
good since had to wait until the following day for response, I did get a
billcap from "space city"). In retrospect, it would have been much
easier to have rewritten it in C.

--
virtualization experience starting Jan1968, online at home since Mar1970

25B.Z959

unread,
Jul 23, 2022, 1:35:30 AM7/23/22
to
I love languages/systems written in themselves - it's
such a neat concept :-)

However modern object Pascal - it WOULD be a lot easier.

I liked IBM/MS-Pascal - the old multi-pass compiler/linker
in the pink manuals with the 5-1/4 floppies inside. Something
about the overall philosophy/structure was SO much more
appealing than FORTRAN or PL/I and such (but K&R-ish 'C' -
that's a special class unto itself and I write it often -
still have the actual K&R book on the shelf).

Then came Philippe Kahn and the world changed. Gen-2
RAD/IDE environments vastly sped up development. Gen-3
IMHO is kinda the pinnacle - drag and drop yer GUI and
then customize function. Lazarus/Delphi (ok, Del kinda
priced itself out of the market).

In any case, if you want a nice GUI for an app like
TODAY - use Lazarus. 99% portable to Winders too (it's
usually the damned fonts that don't quite fit).

But once in awhile, I still write a little utility
in FORTRAN or BASIC or COBOL ... just for fun.
Let my successors suffer a bit :-)

Oh yea ... a Linux-ish question ... has anyone found
a decent Modula-3 compiler that'll actually install
and run properly in Deb ??? I've had zero success.
They'll SAY it'll work - and then there's a zillion
confounding error messages. A native compiler is
more to my liking than 'translators' like the 'G__'
family.

(and any language where the word 'lambda' shows up
often and/or has lots and LOTS of nested brackets ...
no,no,no :-)

25B.Z959

unread,
Jul 23, 2022, 3:18:48 PM7/23/22
to
On 7/19/22 10:50 PM, Lew Pitcher wrote:
> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>
>> Got any of it on a floppy or print-out anywhere ? I'd
>> love to see how to do client/server only using COBOL.
>
> Both client and server used the same COBOL codebase, but with
> different compilers and operating environments.
>
> The client was coded in Microfocus "Visual Object (VISOC)" COBOL
> and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
> (terminal communications) connection.
>
> The server was coded in IBM COBOL and ran under IMS DC on an MVS
> system, using an SNA terminal LU as it's communications endpoint.
>
> As this was an in-house "inner platform" project (3 tier client/server
> architecture, circa 1990), I did not keep personal copies of any
> of the code. Suffice it to say that my first question to the architect,
> my first day on that project, was "Why COBOL?" The answer was "Because
> that's what the coders know."


Sometimes that IS a factor ... you have to have people who
can write it. But 1990 ... IMHO it should have been 'C'.


>> Yea, you could do it in BASIC too ... with lots of
>> DATA statements. I remember converting a Fortran
>> pgm to IBMPC BASIC, but had to work that newfangled
>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>
>> COBOL was deliberately made to do "business stuff" in a
>> super-wordy fashion that was SUPPOSED to be "self documenting".
>
> Agreed. That was the defining component of COBOL, and perhaps it's
> saving grace.

Ummmmm ....

Mostly I like "terse" languages - less typing and lots
of room left over for comments at the ends of the lines.
'C' fits the bill pretty well. But you DO need the
comments because the syntax doesn't lend itself to a
quick read. 2/3rds of every 'C' program I do is comments,
from brief to expositions. That way I can come back to
it a few years later and sort-of figure out what I
was doing.

>> Maybe the only language requiring more text than Java :-)
>
> Those of us who coded COBOL for a living kept a boilerplate^W
> template program handy, just so we didn't have to fill in all that
> language /just/ to get a program started.

Now we just cut and paste from the internet :-)

The fine detail and complexity of what we do with
computers now has long since reached the point where
nobody can know it all. We have to go to 'the library'
and find various templates - and build upon them.

Lew Pitcher

unread,
Jul 23, 2022, 3:32:11 PM7/23/22
to
As was mine, at the time. But, in that corporate environment,
C was almost unknown.

>>> Yea, you could do it in BASIC too ... with lots of
>>> DATA statements. I remember converting a Fortran
>>> pgm to IBMPC BASIC, but had to work that newfangled
>>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>>
>>> COBOL was deliberately made to do "business stuff" in a
>>> super-wordy fashion that was SUPPOSED to be "self documenting".
>>
>> Agreed. That was the defining component of COBOL, and perhaps it's
>> saving grace.
>
> Ummmmm ....
>
> Mostly I like "terse" languages - less typing and lots
> of room left over for comments at the ends of the lines.
> 'C' fits the bill pretty well. But you DO need the
> comments because the syntax doesn't lend itself to a
> quick read. 2/3rds of every 'C' program I do is comments,
> from brief to expositions. That way I can come back to
> it a few years later and sort-of figure out what I
> was doing.

This development occurred in a large (1000+ branch) banking environment.
When we got specs from the users, they were along the lines of
you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
giving the INTEREST ADJUSTMENT.
you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
giving the ADJUSTED ACCOUNT BALANCE.
which a programmer might convert into
MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.

The convenience was that the user's description /was/ the program code.

>>> Maybe the only language requiring more text than Java :-)
>>
>> Those of us who coded COBOL for a living kept a boilerplate^W
>> template program handy, just so we didn't have to fill in all that
>> language /just/ to get a program started.
>
> Now we just cut and paste from the internet :-)

Yah. Sad, that.

> The fine detail and complexity of what we do with
> computers now has long since reached the point where
> nobody can know it all. We have to go to 'the library'
> and find various templates - and build upon them.

Charlie Gibbs

unread,
Jul 23, 2022, 5:48:33 PM7/23/22
to

Peter Flass

unread,
Jul 23, 2022, 6:23:59 PM7/23/22
to
IMNSHO, COBOL. C is a terrible language for those types of language. Things
that are so dimple in COBOL, like moving a character string with blank
fill, or formatting numeric output, requires calling subroutines in C, and
lack of length checking on string moves is a recipe for disaster.

I have used both languages quite a bit, perhaps COBOL more, years ago, but
neither is my preferred language, so I have no dog in this fight.


>
> Mostly I like "terse" languages - less typing and lots
> of room left over for comments at the ends of the lines.

Sounds like assembler ;-)

It’s too easy to write tricky code with side-effects in C. COBOL might not
be as self-documenting as advertised, but the operation of each statement
is pretty obvious and easily understood.

--
Pete

Peter Flass

unread,
Jul 23, 2022, 6:26:46 PM7/23/22
to
“ types of language” should have been “ types of application.”
“dimple”->”simple”, etc. typing balancing my ipad unsteadily on my lap.

--
Pete

Allodoxaphobia

unread,
Jul 23, 2022, 7:50:48 PM7/23/22
to
On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>
> This development occurred in a large (1000+ branch) banking environment.
> When we got specs from the users, they were along the lines of
> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
> giving the INTEREST ADJUSTMENT.
> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
> giving the ADJUSTED ACCOUNT BALANCE.
> which a programmer might convert into
> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>
> The convenience was that the user's description /was/ the program code.

Good luck finding white collar droids
now-a-days that can write that clearly!

Ya, a couple hundred years ago I was a programmer in a corporate-captive
service company that did the data processing for 25 or so branch banks.
Did PL/1 and assembler -- mostly on the systems side versus applications.
The specs that came down for projects was always well defined and detailed.

I don't think that's the case these days.

Jonesy

25B.Z959

unread,
Jul 23, 2022, 11:08:46 PM7/23/22
to
The K&R bible on the language came out in 1978, 2nd
ed about a decade later. Still have the 2nd ed on my
shelf and DO look up stuff in it from time to time.
Most of my code still has a very K&R look and feel.

I was writing 'C' on the original IBM-PCs in the mid
80s, and with Aztec 'C' for CP/M-80 around the same
timeframe (that's when IBM-PCs came with a DOS *and*
a CP/M-86 floppy :-) So, the language and its strengths
surely weren't UNKNOWN.

Admittedly 'C' was originally kind of part of the
Unix & PDP-11 sphere, more 'academia', so if yer bosses
didn't use or pay attention to anything like that then
it really might have escaped their notice. Pointy-haired
know-nothing bosses aren't anything new alas.


>>>> Yea, you could do it in BASIC too ... with lots of
>>>> DATA statements. I remember converting a Fortran
>>>> pgm to IBMPC BASIC, but had to work that newfangled
>>>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>>>
>>>> COBOL was deliberately made to do "business stuff" in a
>>>> super-wordy fashion that was SUPPOSED to be "self documenting".
>>>
>>> Agreed. That was the defining component of COBOL, and perhaps it's
>>> saving grace.
>>
>> Ummmmm ....
>>
>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>> 'C' fits the bill pretty well. But you DO need the
>> comments because the syntax doesn't lend itself to a
>> quick read. 2/3rds of every 'C' program I do is comments,
>> from brief to expositions. That way I can come back to
>> it a few years later and sort-of figure out what I
>> was doing.
>
> This development occurred in a large (1000+ branch) banking environment.


I can understand the conservatism ... and having lots
of COBOL programmers around.


> When we got specs from the users, they were along the lines of
> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
> giving the INTEREST ADJUSTMENT.
> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
> giving the ADJUSTED ACCOUNT BALANCE.
> which a programmer might convert into
> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>
> The convenience was that the user's description /was/ the program code.


For straightforward lines ... but, kinda like with FORTRAN, when
you start to get into formatting the output PICs can get pretty
cryptic and un-intuitive and the sheer wordiness makes typos
more likely. "X++" is less wordy than "ADD 1 TO X" and you
can "x++" or "++x" instead of structuring it in in a COBOL pgm

I do notice that COBOL-related forums and help pages and
such are still kinda busy, so it's not remotely a dead
language. People are still writing/updating COBOL code.
FORTRAN is still pretty widely used also, esp in academic
and engineering environments, mostly due to the huge volume
of proven hard-core math routines which nobody wants to
re-write. Now BASIC ... does ANYBODY use BASIC anymore ?
USED to be THE introductory language ......

Anyway, I basically dropped COBOL and FORTRAN in favor of 'C'
(and Pascal) a long time ago. I think the 2nd version of Turbo
Pascal had straight-up math-coprocessor support and at the time
I was translating a lot of old FORTRAN statistics routines over
to the IBM-PCs for scientifics and stat-mongers. IBM-PC 'C' also
had 8087 libraries, but the TP environment made development a
LOT faster. Time a Fourier Transform with, and without, a math
coprocessor sometime :-)

After that, various micro-controller projects - 8051s/PICS, later
Arduino's and such ... mix of assembler and compiler-generated
code (esp for the very annoying serial-comm stuff).


>>>> Maybe the only language requiring more text than Java :-)
>>>
>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>> template program handy, just so we didn't have to fill in all that
>>> language /just/ to get a program started.
>>
>> Now we just cut and paste from the internet :-)
>
> Yah. Sad, that.

I still sometimes buy actual BOOKS ... hard to hold three
different pages open at the same time on the net and flip
back and forth. Just ain't the same. I think the tangibility
of paper enhances memory too, multi-sensory association.
A lot easier to scribble notes circles and arrows on it too.

A lot of the code snippets you find on the net are kind of
defective too - or ONLY intended as demos. Takes a lot of
spiffing-up and expansion to put them into something real
but at LEAST you have a template to work with.

25B.Z959

unread,
Jul 24, 2022, 12:07:59 AM7/24/22
to
On 7/23/22 5:48 PM, Charlie Gibbs wrote:
> On 2022-07-23, Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
>
>> On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:
>>
>>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>>
>>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>>> template program handy, just so we didn't have to fill in all that
>>>> language /just/ to get a program started.
>>>
>>> Now we just cut and paste from the internet :-)
>>
>> Yah. Sad, that.
>
> https://en.wikipedia.org/wiki/Cargo_cult_programming

Been there :-)

Though I usually figure out pretty quick what's
necessary and what's not because I like terse
programs.

I do have my own little library of handy functions
in several languages - and tend to just paste it
all into new programs whether all of the bits are
used or not. However I see this as "preservation
through replication" ... I'll always be able to
find them by looking in an old program. Recently
rendered some of them in FORTRAN and ADA too, just
in case.(no, I do NOT like ADA - WAY too anal, Lady
Lovelace was probably much more fun)

25B.Z959

unread,
Jul 24, 2022, 1:31:25 AM7/24/22
to
Ah ... PL/I ... one of the great "and the kitchen sink too"
languages. Not awful - usually several ways to accomplish
the same thing ... ie "flexibility". A bit odd though, like
a mutant hybrid of Algol and BASIC


> I don't think that's the case these days.


NOT - for sure. Now it's more "Dilbert" and the
bosses don't know dick and the project initiators
mostly like to APPEAR to know stuff.

HOWEVER ... "fuzzy" specs CAN lead to significant
innovation. Too-tight specs lead to tight, but oft
unimaginative, solutions. The old white-shirt/
narrow-tie crowd DID have a very useful place (and
I wish we still had a few more of them), but so do
the addled hacks with little guidance.

I like programming to be FUN - never "just a JOB"
like some assembly line - and have always found
places where that can be realized. Smaller outfits,
less pay, but WORTH it and always interesting.

I've got one boss now who thinks that anything
with "Microsoft" on the label is the greatest
most wonderful thing EVER, mostly because some
other outfits are all-MS shops and that's "biz-
standard", beyond critique. I know better.

I'll keep that a secret until I hand in my
retirement notice. Besides, they'd have to throw
out the printers, monitors, routers, hubs, iPads/Phones
and NASs, Google and pretty much everything to avoid
Unix/Linux products. Scuttlebutt is that Win-12 will
be just like OS-X ... a Winders-looking face on top
of a Unix core because "real Winders" has just become
such an unmanagable/un-securable MESS - dead end. If you
don't know Unix/Linux then you can't be an I.T. pro
because it's EVERYWHERE, in EVERYTHING.

And when they call about an EMERGENCY - they'll just
get the "Gone Fishin'" message ........ :-)

Charlie Gibbs signs off with :

/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgi...@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

If it's REALLY IMPORTANT - I'd suggest Free/Open-BSD Unix
instead. If it's BIG too - IBM z-OS. After decades of
real-world experiences, "-IX/UX" has proven itself superior.

Though such a pity VMS died out ... still have the 3-1/2
inch thick small-print manual ......... :-)

Ahem A Rivet's Shot

unread,
Jul 24, 2022, 2:00:12 AM7/24/22
to
On 23 Jul 2022 23:50:45 GMT
Allodoxaphobia <trepi...@example.net> wrote:

> Ya, a couple hundred years ago I was a programmer in a corporate-captive
> service company that did the data processing for 25 or so branch banks.
> Did PL/1 and assembler -- mostly on the systems side versus applications.
> The specs that came down for projects was always well defined and
> detailed.

The problems started when the well defined and detailed specs were
also wrong which tended to happen when projects moved from well defined
data processing to less well defined operational support and even less well
defined customer facing products.

> I don't think that's the case these days.

Very rarely, most of the well defined problems have been done
decades ago.

Most modern software development is done in an environment of
shifting priorities and vaguely defined changing goals. For this reason
feature driven incremental development (give them something fast, then see
what they want next and give it to them - iterate last step until done)
tends to be the only successful approach (these days with a lot of window
dressing courtesy of the "Agile Foundation"). This sort of development also
favours rapid development tools, highly readable code, extensive unit and
functional testing and a short horizon. It's fun too.

Kerr-Mudd, John

unread,
Jul 24, 2022, 4:13:33 PM7/24/22
to
On 23 Jul 2022 23:50:45 GMT
Allodoxaphobia <trepi...@example.net> wrote:

> On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
> >
> > This development occurred in a large (1000+ branch) banking environment.
> > When we got specs from the users, they were along the lines of
> > you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
> > giving the INTEREST ADJUSTMENT.
> > you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
> > giving the ADJUSTED ACCOUNT BALANCE.
> > which a programmer might convert into
> > MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
> > ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
> >
> > The convenience was that the user's description /was/ the program code.
>
> Good luck finding white collar droids
> now-a-days that can write that clearly!
>

Even in those days it might have been

SET 0800-INTADJ = IFILE-ACCTBAL * MIR
SET OFILE-ADJACCTBAL = IFILE-ACCTBAL + 0800-INTADJ

or somesuch "standard"

> Ya, a couple hundred years ago I was a programmer in a corporate-captive
> service company that did the data processing for 25 or so branch banks.
> Did PL/1 and assembler -- mostly on the systems side versus applications.
> The specs that came down for projects was always well defined and detailed.
>
> I don't think that's the case these days.
>
> Jonesy


--
Bah, and indeed Humbug.

Dan Espen

unread,
Jul 24, 2022, 7:49:08 PM7/24/22
to
"Kerr-Mudd, John" <ad...@127.0.0.1> writes:

> On 23 Jul 2022 23:50:45 GMT
> Allodoxaphobia <trepi...@example.net> wrote:
>
>> On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>> >
>> > This development occurred in a large (1000+ branch) banking environment.
>> > When we got specs from the users, they were along the lines of
>> > you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
>> > giving the INTEREST ADJUSTMENT.
>> > you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
>> > giving the ADJUSTED ACCOUNT BALANCE.
>> > which a programmer might convert into
>> > MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
>> > ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>> >
>> > The convenience was that the user's description /was/ the program code.
>>
>> Good luck finding white collar droids
>> now-a-days that can write that clearly!
>>
>
> Even in those days it might have been
>
> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
> SET OFILE-ADJACCTBAL = IFILE-ACCTBAL + 0800-INTADJ
>
> or somesuch "standard"

I can't recall seeing code that bad.
The language lends itself to using very consistent naming.
Most places I worked you could predict character for character what a
block of code would look like.

--
Dan Espen

Dennis Boone

unread,
Jul 24, 2022, 10:26:05 PM7/24/22
to
> SET 0800-INTADJ = IFILE-ACCTBAL * MIR

More like

MULTIPLY IFILE-ACCTBAL BY MIR GIVING 0800-INTADJ.

or

COMPUTE 0800-INTADJ = IFILE-ACCTBAL * MIR.

De

25B.Z959

unread,
Jul 25, 2022, 12:02:21 AM7/25/22
to
On 7/24/22 4:13 PM, Kerr-Mudd, John wrote:
> On 23 Jul 2022 23:50:45 GMT
> Allodoxaphobia <trepi...@example.net> wrote:
>
>> On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>>>
>>> This development occurred in a large (1000+ branch) banking environment.
>>> When we got specs from the users, they were along the lines of
>>> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
>>> giving the INTEREST ADJUSTMENT.
>>> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
>>> giving the ADJUSTED ACCOUNT BALANCE.
>>> which a programmer might convert into
>>> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
>>> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>>>
>>> The convenience was that the user's description /was/ the program code.
>>
>> Good luck finding white collar droids
>> now-a-days that can write that clearly!
>>
>
> Even in those days it might have been
>
> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
> SET OFILE-ADJACCTBAL = IFILE-ACCTBAL + 0800-INTADJ
>
> or somesuch "standard"


Heh heh .... yea, we all get sick of writing out
long "descriptive names" and "self documenting"
code. Something about it just grates on the soul,
impedes the creative impulse.

25B.Z959

unread,
Jul 25, 2022, 12:08:31 AM7/25/22
to
Sorry, I like 'C' - and have writ little functions, MY way,
to do a lot of the things you were talking about.

Only ASM gives you more control - and I've done my share of
that over the years too.

>
>>
>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>
> Sounds like assembler ;-)


YES ! :-)

ASM ... MMmmmmmmm !


> It’s too easy to write tricky code with side-effects in C. COBOL might not
> be as self-documenting as advertised, but the operation of each statement
> is pretty obvious and easily understood.

So ... COBOL is for BAD PROGRAMMERS who can't foresee
downstream consequences hmmm ??? ;-)

25B.Z959

unread,
Jul 25, 2022, 12:24:03 AM7/25/22
to
On 7/20/22 1:16 PM, Charlie Gibbs wrote:
> On 2022-07-20, The Natural Philosopher <t...@invalid.invalid> wrote:
>
>> COBOL IME was generally written by teams of coders after the analysts
>> had written the specification, to strict coding standards which if not
>> adhered to got you the sack.
>
> I once wrote some programs in a shop where I was given specs that were
> so detailed that I could probably have written a compiler for them.
> Unfortunately, I identified a number of cases that the specs didn't cover.
> When I asked about this, I was given the answer which is now at the top
> of my list of Famous Last Words: "Oh, don't worry about that - it'll
> never happen." Since I had enough experience by this time to know that
> "never" is usually about six months, I refused to proceed until all
> cases were accounted for. Beware of nasal demons!


The Bosses NEVER really understand what they're asking
for. That's not their function. They are task-masters,
not sages. THEIR bosses are even MORE oblivious, and
vengeful.

GET OUT of such establishments as FAST as possible even
IF it means less money. At least you'll still have your
pride and soul.

As I've said - what started as a Good Thing very quickly
became 'Dilbert' once Big Corporate got involved.

I always have this vision of a young Van Gogh getting a
steady job at "Popular Art (Amsterdam) Inc" ............



> As for coding standards, this shop's standards were so inefficient
> that it would take a job half an hour just to schedule, let alone run.
> I threw their precious standards into the trash can and wrote the system
> my way, which scheduled and ran in 30 seconds. When I was met with
> the predictable howls of anguish, I told them that I wanted to get things
> tested in a reasonable amount of time, and if they really wanted their
> standards that badly they could change it back when I was done.
> I doubt they ever did.

"Procedure" gives the Bosses an excuse for their paychecks.
Doing things fast and efficiently cuts them out - makes them
look as useless as they really are.

I was always able to find smaller outfits where Fast,
Efficient and Creative was coveted and appreciated.
I could identify Needs they didn't know existed and
act on them. The checks weren't quite as big - but ....

25B.Z959

unread,
Jul 25, 2022, 1:02:53 AM7/25/22
to
On 7/19/22 8:27 PM, Charlie Gibbs wrote:
> On 2022-07-19, Peter Flass <peter...@yahoo.com> wrote:
>
>> These days, of course, we’re awash in memory and it’s not worth doing
>> a lot of work to save a few bytes; not like the old days.
>
> In _The Mythical Man-Month_, Fred Brooks describes the decision to save
> 100 bytes by not having the date routine handle leap years.

Well, it's only wrong 25% of the time ... :-)

And hey, depending on the era and hardware, 100 bytes
MIGHT be critical.

Program micro-controllers ? I've done a number of apps
for them. You DO have to cut corners. 64-128 BYTES of RAM,
1k to 4K of EEPROM (or UV-Erase PROM) if you were lucky.

I still have a fondness for the PIC12-xxx series - 8-pin
wonders. Forget 'C' - go all ASM. ATMELs or AVRs might be
a little better these days. PIC32s - supercomputers ! :-)

Anyway, the bosses/taskmasters have to justify their
existence/paychecks ..... stupid decisions that SOUND
good gets them that. THEIR bosses are 10x MORE
oblivious - buzzword driven, dazzled by cost/profit
projection charts ...

CorpComp - it's all 'Dilbert' now. No wonder Winders
sucks - indeed is a National Security Threat.

Still have my UV-C box for erasing "JW" PIC chips.
That smell of ozone and NOx......

Charlie Gibbs

unread,
Jul 25, 2022, 1:36:05 AM7/25/22
to
On 2022-07-24, 25B.Z959 <25B....@nada.net> wrote:

> FORTRAN is still pretty widely used also, esp in academic
> and engineering environments, mostly due to the huge volume
> of proven hard-core math routines which nobody wants to
> re-write.

Many rivals, with the benefit of hindsight, have crossed
swords with the old workhorse! Yet FORTRAN gallops on,
warts and all, more transportable than syphilis, fired
by a bottomless pit of working subprograms.
-- Stan Kelly-Bootle: The Devil's DP Dictionary

--

Charlie Gibbs

unread,
Jul 25, 2022, 1:45:29 AM7/25/22
to
On 2022-07-25, 25B.Z959 <25B....@nada.net> wrote:

> I was always able to find smaller outfits where Fast,
> Efficient and Creative was coveted and appreciated.
> I could identify Needs they didn't know existed and
> act on them. The checks weren't quite as big - but ....

I've always gravitated toward smaller outfits . When I left $BIGCORP
for a smaller one, the hiring personnel director was baffled that
I would come to a job that paid less. But I got my sanity back,
and since the new establishment was closer to home, I saved $200
per month on gas plus a lot of commute time.

(Ten years later that outfit went Dilbert too, but that's another story.)

Jack Strangio

unread,
Jul 25, 2022, 6:56:12 AM7/25/22
to
"25B.Z959" <25B....@nada.net> writes:
>
> Heh heh .... yea, we all get sick of writing out
> long "descriptive names" and "self documenting"
> code. Something about it just grates on the soul,
> impedes the creative impulse.
>
I was probably a bit different from most people in that I went from BASIC to
COBOL within a very short period of time back in the 1980s.

I still have some source files from that time.I have no idea what the BASIC
programs were doing and, more the point, *how* they did it. When you get lines
like:

740 !#H9 TAB(10),C$," ",E$,A$,TAB(22),D$,A$,E$
745 K7$=" "+D$+"M"+A$+E$\ WRITE#5,K7$\!">>>",K7$,"<"
750 GOTO460
760 READ#1%L,&X
770 M5=(X+O+1)
780 A=A7(M5)\B=B7(M5)
790 A$=A7$(2*M5-1,2*M5)
800 B$=B7$(10*M5-9,10*M5)
810 B$=B$(1,(B8(M5)))
820 RETURN

and then find COBOL lines like this:

0352 NEW-ORDER.
0353 DISPLAY SCREEN-CLEAR LINE-FEEDS LINE-FEEDS.
0354 PERFORM TYPE-CUST.
0355
0356 MOVE " * ORDER FROM " TO PAPER-TYPE.
0357 MOVE CUST-NAME TO ORGANISATION-D.
0358 MOVE CUST-CODE TO WHO.
0359 MOVE MONTH-S TO WHEN-MONTH.
0360 MOVE YEAR-S TO WHEN-YEAR.
0361 OPEN OUTPUT ORDER-FILE.
0362 MOVE HEADER-TYPE TO HEADER-TYPE-D.
0363 MOVE " * O/No " TO FORM-TYPE.
0364 PERFORM NEW-ORD-1.


it's easy to know which language's source-code I prefer to read after not
seeing them for years.


Jack


--
Why do meteorites always land in craters?

Johnny Billquist

unread,
Jul 25, 2022, 7:37:40 AM7/25/22
to
On 2022-07-24 00:23, Peter Flass wrote:
> 25B.Z959 <25B....@nada.net> wrote:
>> Sometimes that IS a factor ... you have to have people who
>> can write it. But 1990 ... IMHO it should have been 'C'.
>>
>
> IMNSHO, COBOL. C is a terrible language for those types of language.
Things
> that are so dimple in COBOL, like moving a character string with blank
> fill, or formatting numeric output, requires calling subroutines in
C, and
> lack of length checking on string moves is a recipe for disaster.
This is one of the weirder arguments I've ever seen:
"requires calling a subroutine in C". As if that somehow is a problem?
Not to mention it's a function, and not a subroutine. Any claim of "used
the language quite a bit" sounds hollow after that.

A statement to move a character string in COBOL will in the end be a
subroutine call as well.

And lack of length checking depends on the function. Nothing prevents
you from using strncpy in C. Or write your own, with whatever
characteristic you want. It will actually be pretty efficient.
Comparable to the provided functions.

> I have used both languages quite a bit, perhaps COBOL more, years
ago, but
> neither is my preferred language, so I have no dog in this fight.
> …
Seems like your C is both rusty and bad.

>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>
> Sounds like assembler ;-)
>
> It’s too easy to write tricky code with side-effects in C. COBOL
might not
> be as self-documenting as advertised, but the operation of each statement
> is pretty obvious and easily understood.
What kind of side effects are we talking about? The operation of each
statement in C is very obvious and easy to understand.
Most people get into trouble because of memory handling. Not the
language semantics.
But that is where you get to the point where things gets even harder to
even do in COBOL. And if you manage to do it, it won't be easily understood.

Johnny

Allodoxaphobia

unread,
Jul 25, 2022, 8:54:44 AM7/25/22
to
I can envision change requests and new development requirements
being *text'ed* into the programming departments these days.

Jonesy
--
Marvin L Jones | Marvin | W3DHJ.net | linux
38.238N 104.547W | @ jonz.net | Jonesy | FreeBSD
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm

Scott Lurndal

unread,
Jul 25, 2022, 9:52:21 AM7/25/22
to
Or,

1150-CK-TIME.
IF KLINGONS > 0
ACCEPT WS-TIME FROM TIME
MOVE WS-MIN OF WS-TIME TO DS-MIN
PERFORM 1145-CK-FLAG THRU 1145-EXIT
MOVE WS-SEC OF WS-TIME TO DS-SEC
MOVE DS-TABLE TO S-DATE
ELSE
GO TO 1150-EXIT.
COMPUTE T-STORE = DS-DATE - S-DATE.
IF T-STORE < 90 AND NOT KLINGONS-ATTACKING
MOVE 14 TO MAX-NO
COMPUTE W = ((HQ2 - 1) * 14)
COMPUTE Z = ((HQ1 - 1) * 14)
INSPECT MASTER-TBL REPLACING ALL "K" BY " "
MOVE 0 TO RX
PERFORM 1170-MOVE-ON-HQ THRU 1170-EXIT
VARYING KCTR FROM 1 BY 1 UNTIL KCTR > KLINGONS
MOVE 1 TO ATTACK-FLAG
PERFORM 5900-TRANS THRU 5900-EXIT
IF (Q1 NOT = HQ1 OR Q2 NOT = HQ2)
DISPLAY "WARNING - STAR DATE: " S-DATE
DISPLAY "SCIENCE OFFICER SPOCK ADVISES"
DISPLAY "YOU NAVIGATE TO QUADRANT " HQ1 "," HQ2
DISPLAY "TO DEFEND STAR FLEET HEADQUARTERS".
IF NOT TOO-LATE
MOVE DS-DATE TO WS-DATE.
IF S-DATE > WS-DATE AND Q1 = HQ1 AND Q2 = HQ2 AND NOT TOO-LAT
- E
MOVE 1 TO TOO-LATE-FLAG
ADD 230 TO WS-DATE
ELSE
IF S-DATE > WS-DATE
MOVE 1 TO INDICATE-X
PERFORM 8200-CK-DONE THRU 8200-EXIT.
1150-EXIT. EXIT.

:-)

Scott Lurndal

unread,
Jul 25, 2022, 10:13:55 AM7/25/22
to
Johnny Billquist <b...@softjar.se> writes:
>On 2022-07-24 00:23, Peter Flass wrote:
> > 25B.Z959 <25B....@nada.net> wrote:
> >> Sometimes that IS a factor ... you have to have people who
> >> can write it. But 1990 ... IMHO it should have been 'C'.
> >>
> >
> > IMNSHO, COBOL. C is a terrible language for those types of language.
>Things
> > that are so dimple in COBOL, like moving a character string with blank
> > fill, or formatting numeric output, requires calling subroutines in
>C, and
> > lack of length checking on string moves is a recipe for disaster.
>This is one of the weirder arguments I've ever seen:
>"requires calling a subroutine in C". As if that somehow is a problem?
>Not to mention it's a function, and not a subroutine. Any claim of "used
>the language quite a bit" sounds hollow after that.

I suspect the poster was indicating that COBOL will generate the call
under the covers, while in C the programmer must code the call explicitly.

>
>A statement to move a character string in COBOL will in the end be a
>subroutine call as well.

Not on all systems, for example:

INSPECT COURSE-B REPLACING ALL " " BY ZEROS. 531 CARD 1 65864
01 065864 MVN 110607 000774 100008 CODE
01 065882 SEA 39B101 400000 600000 050384 CODE
01 065906 NEQ 25 0C065962 CODE
01 065916 MVA 10A202 F0F0F0 400000 CODE
01 065934 INC 01A107 200000 100008 CODE
01 065952 BUN 27 0C065882 CODE
or
MOVE "THIS IS A TEST" TO TEST-STRING. 235 CARD 1 109910
01 109910 MVA 101420 211148 213500 CODE

MVN -> Move numeric (moves 1 to 100 digits or zoned-digit bytes, truncating or padding)
MVA -> Move alpha (moves 1 to 100 bytes, truncating or padding the receiving field)
SEA -> Search memory (in this case, for the single byte EBCDIC space (0x40) character).
NEQ -> Branch if SEA didn't find search string.
INC -> Increment receiving field (by 2 in this case)
BUN -> Branch unconditionally.

Kerr-Mudd, John

unread,
Jul 25, 2022, 3:57:45 PM7/25/22
to
That'd be about right!

Peter Flass

unread,
Jul 25, 2022, 4:55:55 PM7/25/22
to
No, COBOL is for the NEXT poor bastard who has to look at your code and
try to figure out what the heck you were trying to do. The more “concise” a
language is, the more write-only it tends to be.

--
Pete

Peter Flass

unread,
Jul 25, 2022, 4:55:56 PM7/25/22
to
25B.Z959 <25B....@nada.net> wrote:
> On 7/19/22 8:27 PM, Charlie Gibbs wrote:
>> On 2022-07-19, Peter Flass <peter...@yahoo.com> wrote:
>>
>>> These days, of course, we’re awash in memory and it’s not worth doing
>>> a lot of work to save a few bytes; not like the old days.
>>
>> In _The Mythical Man-Month_, Fred Brooks describes the decision to save
>> 100 bytes by not having the date routine handle leap years.
>
> Well, it's only wrong 25% of the time ... :-)

Not really, because the operator had to set the date and time at each IPL,
and many shops IPLed often enough that it wasn’t a problem. We used to IPL
every night at the end of third shift.

--
Pete

Peter Flass

unread,
Jul 25, 2022, 4:56:23 PM7/25/22
to
If I had a programmer working for me who coded like that,be having a talk.
I HAVE seen code like that, usually written by someone who thought
programming was beneath him and was bored. Such people were usually
promoted to management, where they fit right in.



--
Pete

Peter Flass

unread,
Jul 25, 2022, 4:57:21 PM7/25/22
to
+1

--
Pete

Scott Lurndal

unread,
Jul 25, 2022, 5:45:55 PM7/25/22
to
Speak to Kurt.

IDENTIFICATION DIVISION.
PROGRAM-ID. STREK.
AUTHOR. KURT WILHELM.
INSTALLATION. OAKLAND UNIVERSITY.
DATE-WRITTEN. COMPLETED SEPTEMBER 1, 1979.
*
*******************************************************
* STAR_TREK SIMULATES AN OUTER SPACE ADVENTURE GAME *
* ON A REMOTE TERMINAL. THE USER COMMANDS THE U.S.S. *
* ENTERPRISE, AND THRU VARIOUS OFFENSIVE AND DEFEN- *
* SIVE COMMANDS, TRAVELS THROUGHOUT THE GALAXY ON A *
* MISSION TO DESTROY ALL KLINGONS, WHICH ALSO MANEU- *
* VER AND FIRE ON THE ENTERPRISE. *
*******************************************************

Charlie Gibbs

unread,
Jul 25, 2022, 6:52:33 PM7/25/22
to
Ah yes, the good old days before computers had battery-backed time-of-day
clocks (or anything to set them from). One of the trade rags ran an ad
that showed a teaspoonful of ICs, accompanied by the statement: "Soon
you'll have an IBM 3090 in your wristwatch!" Someone quipped: "Yeah,
you'll boot MVS on it and the first thing it'll do is ask you the time."

Charlie Gibbs

unread,
Jul 25, 2022, 6:52:34 PM7/25/22
to
I've cleaned up some pretty horrid COBOL code. Overly-verbose and
convoluted code can be just as bad as something overly concise.

A sufficiently determined programmer can write unreadable code
in any language. Convoluted code with no comments is even worse.
Convoluted code with outdated, incorrect comments is worse still.

Dan Espen

unread,
Jul 25, 2022, 7:27:50 PM7/25/22
to
Being a game, I'm not surprised. Business code would not look like that.

--
Dan Espen

Dan Espen

unread,
Jul 25, 2022, 7:42:20 PM7/25/22
to
Johnny Billquist <b...@softjar.se> writes:

> On 2022-07-24 00:23, Peter Flass wrote:
>> 25B.Z959 <25B....@nada.net> wrote:
>>> Sometimes that IS a factor ... you have to have people who
>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>
>>
>> IMNSHO, COBOL. C is a terrible language for those types of
> language. Things
>> that are so dimple in COBOL, like moving a character string with blank
>> fill, or formatting numeric output, requires calling subroutines in
> C, and
>> lack of length checking on string moves is a recipe for disaster.
> This is one of the weirder arguments I've ever seen:
> "requires calling a subroutine in C". As if that somehow is a problem?
> Not to mention it's a function, and not a subroutine. Any claim of
> "used the language quite a bit" sounds hollow after that.
>
> A statement to move a character string in COBOL will in the end be a
> subroutine call as well.

And why do you think that?

I've sure seen lots of COBOL MOVE instructions generate a single
hardware instruction.

--
Dan Espen

Peter Flass

unread,
Jul 25, 2022, 9:55:12 PM7/25/22
to
Well, in that case naming a variable klingons makes perfect sense. Maybe
not in a payroll program.

--
Pete
It is loading more messages.
0 new messages