| Re: Fwd: Linux on a small memory PC [message #415128] |
Sun, 17 July 2022 16:59  |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
[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.
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415185 is a reply to message #415128] |
Mon, 18 July 2022 21:26  |
|
|
Originally posted by: 25B.Z959
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.
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415186 is a reply to message #415185] |
Mon, 18 July 2022 21:48 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415188 is a reply to message #415186] |
Mon, 18 July 2022 22:29 |
|
|
Originally posted by: 25B.Z959
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 :-)
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415226 is a reply to message #415185] |
Tue, 19 July 2022 13:48 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415231 is a reply to message #415226] |
Tue, 19 July 2022 14:44 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415233 is a reply to message #415231] |
Tue, 19 July 2022 14:58 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415236 is a reply to message #415233] |
Tue, 19 July 2022 15:48 |
|
|
Originally posted by: Lew Pitcher
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"
|
|
|
|
| Re: COBOL and tricks [message #415241 is a reply to message #415236] |
Tue, 19 July 2022 15:53 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415245 is a reply to message #415241] |
Tue, 19 July 2022 16:25 |
|
|
Originally posted by: David W. Hodgins
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
|
|
|
|
| Re: COBOL and tricks [message #415246 is a reply to message #415241] |
Tue, 19 July 2022 16:53 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415247 is a reply to message #415245] |
Tue, 19 July 2022 16:57 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"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
|
|
|
|
| Re: COBOL and tricks [message #415254 is a reply to message #415241] |
Tue, 19 July 2022 17:22 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
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...
|
|
|
|
| Re: COBOL and tricks [message #415262 is a reply to message #415241] |
Tue, 19 July 2022 19:20 |
D.J.
Messages: 821
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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 Ive 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
|
|
|
|
| Re: COBOL and tricks [message #415263 is a reply to message #415246] |
Tue, 19 July 2022 19:32 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415264 is a reply to message #415247] |
Tue, 19 July 2022 19:32 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415267 is a reply to message #415236] |
Tue, 19 July 2022 20:26 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.co m/time/magazine/article/0,9171,977353,00.html
may also work
http://content.time.com/time/subscriber/article/0,33009,9773 53-1,00.html
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: COBOL and tricks [message #415268 is a reply to message #415245] |
Tue, 19 July 2022 20:27 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415269 is a reply to message #415246] |
Tue, 19 July 2022 20:27 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415270 is a reply to message #415263] |
Tue, 19 July 2022 20:27 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415272 is a reply to message #415241] |
Tue, 19 July 2022 20:27 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415273 is a reply to message #415264] |
Tue, 19 July 2022 20:27 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415278 is a reply to message #415267] |
Tue, 19 July 2022 21:10 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415279 is a reply to message #415268] |
Tue, 19 July 2022 21:10 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415280 is a reply to message #415269] |
Tue, 19 July 2022 21:10 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415282 is a reply to message #415236] |
Tue, 19 July 2022 22:34 |
|
|
Originally posted by: 25B.Z959
On 7/19/22 3:48 PM, Lew Pitcher 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.
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 :-)
|
|
|
|
| Re: COBOL and tricks [message #415283 is a reply to message #415282] |
Tue, 19 July 2022 22:50 |
|
|
Originally posted by: Lew Pitcher
On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
> On 7/19/22 3:48 PM, Lew Pitcher 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.
>
>
> 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."
> 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.
--
Lew Pitcher
"In Skills, We Trust"
|
|
|
|
| Re: COBOL and tricks [message #415289 is a reply to message #415263] |
Tue, 19 July 2022 23:21 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> 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.
Yep, why would they? The flowchart was the documentation.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415290 is a reply to message #415264] |
Tue, 19 July 2022 23:31 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> 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.
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
|
|
|
|
| Re: COBOL and tricks [message #415291 is a reply to message #415268] |
Tue, 19 July 2022 23:37 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> 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.)
Current mainframe COBOL will let you call dynalloc.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415292 is a reply to message #415272] |
Tue, 19 July 2022 23:40 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> 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.
You can do wonders with OCCURS DEPENDING ON, pretty much any kind of
string processing you want.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415297 is a reply to message #415270] |
Wed, 20 July 2022 01:48 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 20 Jul 2022 00:27:35 GMT
Charlie Gibbs <cgibbs@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/
|
|
|
|
| Re: COBOL and tricks [message #415306 is a reply to message #415247] |
Wed, 20 July 2022 03:26 |
Arne Luft
Messages: 321
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> "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.
GCC and Clang both do it.
--
https://www.greenend.org.uk/rjk/
|
|
|
|
| Re: COBOL and tricks [message #415310 is a reply to message #415283] |
Wed, 20 July 2022 05:06 |
Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 20 Jul 2022 02:50:57 -0000 (UTC)
Lew Pitcher <lew.pitcher@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.
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415313 is a reply to message #415233] |
Wed, 20 July 2022 06:42 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 19/07/2022 19:58, 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:
>>>> 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…
>
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
|
|
|
|
| Re: COBOL and tricks [message #415314 is a reply to message #415270] |
Wed, 20 July 2022 06:47 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415315 is a reply to message #415278] |
Wed, 20 July 2022 07:00 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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..
--
"And if the blind lead the blind, both shall fall into the ditch".
Gospel of St. Mathew 15:14
|
|
|
|
| Re: COBOL and tricks [message #415316 is a reply to message #415278] |
Wed, 20 July 2022 09:50 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> 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.
Or it would indicate that the code was so poorly written that it would
take a complete rewrite to make it perform better.
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415323 is a reply to message #415313] |
Wed, 20 July 2022 13:04 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 19/07/2022 19:58, 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:
>>>> > 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…
>>
> 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.
>
>
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
|
|
|
|
| Re: COBOL and tricks [message #415324 is a reply to message #415314] |
Wed, 20 July 2022 13:04 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
The Natural Philosopher <tnp@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
|
|
|
|
Members
Search
Help
Register
Login
Home
