[Cross-posted to alt.folklore.computers]

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

> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>
>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>
>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>
>>>> "25B.Z959" <25B.Z959@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.
\ / <cgibbs@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.

On 7/17/22 4:59 PM, Charlie Gibbs wrote:
> [Cross-posted to alt.folklore.computers]
>
> On 2022-07-17, Dan Espen <dan1espen@gmail.com> wrote:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>
>>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>>
>>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>>
>>>>> "25B.Z959" <25B.Z959@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.

> 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.

On 2022-07-19, 25B.Z959 <25B.Z959@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.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@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.

On 7/18/22 9:48 PM, Charlie Gibbs wrote:
> On 2022-07-19, 25B.Z959 <25B.Z959@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 :-)

25B.Z959 <25B.Z959@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 <dan1espen@gmail.com> wrote:
>>
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>
>>>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>
>>>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>>>
>>>>>> "25B.Z959" <25B.Z959@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.

--
Pete

On 19/07/2022 18:48, Peter Flass wrote:
> 25B.Z959 <25B.Z959@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 <dan1espen@gmail.com> wrote:
>>>
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>>
>>>>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>>
>>>>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>>>>
>>>>>>> "25B.Z959" <25B.Z959@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'

--
“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

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 19/07/2022 18:48, Peter Flass wrote:
>> 25B.Z959 <25B.Z959@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 <dan1espen@gmail.com> wrote:
>>>>
>>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>>>
>>>>>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>>>
>>>>>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>>>>>
>>>>>>>> "25B.Z959" <25B.Z959@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…

--
Pete

On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:

> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 19/07/2022 18:48, Peter Flass wrote:
>>> 25B.Z959 <25B.Z959@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"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>> 25B.Z959 <25B.Z959@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.

--
Pete

On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter_flass@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

Peter Flass <peter_flass@yahoo.com> writes:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>> 25B.Z959 <25B.Z959@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.

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

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter_flass@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.

--
Dan Espen

Peter Flass <peter_flass@yahoo.com> writes:
>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>
>>>
>>> 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.
>

The disk compression utility on Burroughs Medium Systems mainframes
(called SQUASH) was written in COBOL68. Granted, the compiler was
extended to support inline assembler...

On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>> 25B.Z959 <25B.Z959@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.
--
Jim

Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>
>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>> 25B.Z959 <25B.Z959@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.
>
> 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.
>
>

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

Dan Espen <dan1espen@gmail.com> wrote:
> "David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
>
>> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter_flass@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.

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

Lew Pitcher <lew.pitcher@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

On 2022-07-19, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter_flass@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 | Microsoft is a dictatorship.
\ / <cgibbs@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.

On 2022-07-19, Dan Espen <dan1espen@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 | Microsoft is a dictatorship.
\ / <cgibbs@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.

On 2022-07-19, Peter Flass <peter_flass@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 | Microsoft is a dictatorship.
\ / <cgibbs@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.

On 2022-07-19, Peter Flass <peter_flass@yahoo.com> wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>
>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>
>>> The Natural Philosopher <tnp@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.

> 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 | Microsoft is a dictatorship.
\ / <cgibbs@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.

On 2022-07-19, Peter Flass <peter_flass@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.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@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.

Anne & Lynn Wheeler <lynn@garlic.com> wrote:
> Lew Pitcher <lew.pitcher@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

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2022-07-19, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>
>> On Tue, 19 Jul 2022 15:53:19 -0400, Peter Flass <peter_flass@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

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2022-07-19, Dan Espen <dan1espen@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