Re: Fwd: Linux on a small memory PC

325 views
Skip to first unread message

Charlie Gibbs

unread,
Jul 17, 2022, 4:59:54 PMJul 17
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 PMJul 18
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 PMJul 18
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 PMJul 18
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
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 PMJul 19
to
Yep, why would they? The flowchart was the documentation.

--
Dan Espen

Dan Espen

unread,
Jul 19, 2022, 11:31:48 PMJul 19
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 PMJul 19
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 PMJul 19
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 AMJul 20
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 AMJul 20
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 AMJul 20
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 AMJul 20
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 AMJul 20
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 AMJul 20
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 AMJul 20
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 PMJul 20
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 PMJul 20
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 PMJul 20
to
The Natural Philosopher <t...@invalid.invalid> wrote:
I occasionally still do both.

--
Pete

Peter Flass

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

--
Pete

Charlie Gibbs

unread,
Jul 20, 2022, 1:16:39 PMJul 20
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 PMJul 20
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 PMJul 20
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 PMJul 20
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