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

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 :-)

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"

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

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

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

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

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/

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/

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.

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

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

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

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.

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

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

The Natural Philosopher <tnp@invalid.invalid> wrote:
> 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..

I occasionally still do both.

--
Pete

Scott Lurndal <scott@slp53.sl.home> wrote:
> 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.
>

There’s always that, too.

--
Pete

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

> Peter Flass <peter_flass@yahoo.com> writes:
>
>> 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.

Who needs a flow chart? "My {program|language} is so readable
that you don't need comments."

--
/~\ 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-20, Kerr-Mudd, John <admin@127.0.0.1> wrote:

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

Been there, done that - although I was on the receiving end of:
"You start coding, I'll find out what the user wants."

--
/~\ Charlie Gibbs | 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-20, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

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

<snip>

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

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

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

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

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

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

Without hesitation our guy shot back:

EXAMINE ROOM REPLACING ALL TANNOCKS WITH SPACES.

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

Heck, I still do that today in C.

--
/~\ Charlie Gibbs | 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-20, The Natural Philosopher <tnp@invalid.invalid> wrote:

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

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

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

--
/~\ 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 Wed, 20 Jul 2022 17:16:37 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> On 2022-07-20, Kerr-Mudd, John <admin@127.0.0.1> wrote:
>
> > 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".
>
> Been there, done that - although I was on the receiving end of:
> "You start coding, I'll find out what the user wants."
>
I may have mis-remembered; your phrasing sounds better.

--
Bah, and indeed Humbug.

On Wed, 20 Jul 2022 20:09:34 +0100, Kerr-Mudd, John wrote:

> On Wed, 20 Jul 2022 17:16:37 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> On 2022-07-20, Kerr-Mudd, John <admin@127.0.0.1> wrote:
>>
>> > 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".
>>
>> Been there, done that - although I was on the receiving end of:
>> "You start coding, I'll find out what the user wants."
>>
> I may have mis-remembered; your phrasing sounds better.

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

--
Lew Pitcher
"In Skills, We Trust"