| Re: COBOL and tricks [message #415325 is a reply to message #415315] |
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 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
|
|
|
|
| Re: COBOL and tricks [message #415326 is a reply to message #415316] |
Wed, 20 July 2022 13:04 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415327 is a reply to message #415289] |
Wed, 20 July 2022 13:16 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415328 is a reply to message #415310] |
Wed, 20 July 2022 13:16 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415329 is a reply to message #415283] |
Wed, 20 July 2022 13:16 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415330 is a reply to message #415313] |
Wed, 20 July 2022 13:16 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415339 is a reply to message #415328] |
Wed, 20 July 2022 15:09 |
Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415341 is a reply to message #415339] |
Wed, 20 July 2022 15:30 |
|
|
Originally posted by: Lew Pitcher
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"
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415348 is a reply to message #415185] |
Wed, 20 July 2022 18:41 |
|
|
Originally posted by: J. Clarke
On Mon, 18 Jul 2022 21:26:23 -0400, "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.
And now some poor schmuck in India has to deal with it all.
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415350 is a reply to message #415226] |
Wed, 20 July 2022 18:43 |
|
|
Originally posted by: J. Clarke
On Tue, 19 Jul 2022 10:48:20 -0700, Peter Flass
<peter_flass@yahoo.com> 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.
Good luck with that. Figuring out the spec from the code can be an
immense undertaking.
|
|
|
|
| Re: COBOL and tricks [message #415353 is a reply to message #415341] |
Wed, 20 July 2022 19:09 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-20, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> 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.
All too often, users don't know what they want - although when
you give them something, they know immediately that it's _not_
what they want. Insert a sales rep between you and the user
and it gets much worse.
--
/~\ 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 #415363 is a reply to message #415316] |
Wed, 20 July 2022 20:44 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> 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 IBM COBOL compilers had an option that could slow binary arithmetic
to a crawl. So, you could change a compiler option and see an 80% change.
--
Dan Espen
|
|
|
|
|
|
| Re: COBOL and tricks [message #415374 is a reply to message #415353] |
Thu, 21 July 2022 01:00 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 20 Jul 2022 23:09:16 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> All too often, users don't know what they want - although when
> you give them something, they know immediately that it's _not_
> what they want.
This is the main reason incremental development is such a good
idea. I'm just not sure how we got from feature driven incremental
development to "Scaled Agile" with it's nested iteration cycles and
constant "ceremonies" with user stories that must fit in a sprint and epics
that must fit in an iteration and an implicit theory that any developer can
take any task.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
|
|
|
|
| Re: COBOL and tricks [message #415401 is a reply to message #415374] |
Thu, 21 July 2022 13:42 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-21, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Wed, 20 Jul 2022 23:09:16 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> All too often, users don't know what they want - although when
>> you give them something, they know immediately that it's _not_
>> what they want.
>
> This is the main reason incremental development is such a good
> idea. I'm just not sure how we got from feature driven incremental
> development to "Scaled Agile" with it's nested iteration cycles and
> constant "ceremonies" with user stories that must fit in a sprint and
> epics that must fit in an iteration and an implicit theory that any
> developer can take any task.
Sounds like a lot of pomp and ceremony. People love that.
Death marches are so romantic - if you're not the one doing it.
--
/~\ 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 #415402 is a reply to message #415373] |
Thu, 21 July 2022 13:42 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-21, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Wed, 20 Jul 2022 18:43:30 -0400
> J. Clarke <jclarke.873638@gmail.com> wrote:
>
>> Good luck with that. Figuring out the spec from the code can be an
>> immense undertaking.
>
> One which will inevitably lead to asking whether something is a bug
> or a feature with no guidelines to help.
At this point it's time to talk to the users, find out what they
actually need, and make an executive decision. This is time-consuming
and politically hazardous, but it's the only clean solution.
Beware of cargo-cult programming!
--
/~\ 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 #415404 is a reply to message #415401] |
Thu, 21 July 2022 14:28 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 21 Jul 2022 17:42:28 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2022-07-21, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> On Wed, 20 Jul 2022 23:09:16 GMT
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>
>>> All too often, users don't know what they want - although when
>>> you give them something, they know immediately that it's _not_
>>> what they want.
>>
>> This is the main reason incremental development is such a good
>> idea. I'm just not sure how we got from feature driven incremental
>> development to "Scaled Agile" with it's nested iteration cycles and
>> constant "ceremonies" with user stories that must fit in a sprint and
>> epics that must fit in an iteration and an implicit theory that any
>> developer can take any task.
>
> Sounds like a lot of pomp and ceremony. People love that.
> Death marches are so romantic - if you're not the one doing it.
It is a lot of pomp and ceremony. The iteration planning meeting
that happens every eight weeks and involves *everyone* in all the teams on
the project in *one* room and is supposed to resolve all the inter-team
dependencies has to be the most unproductive waste of two days I have ever
seen. It creates jobs for quite a few "agile practitioners" too.
Oh yes one of the four two week sprints in the iteration is supposed
to be for tech debt, tool sharpening and overflow from the other three.
Guess which of the three fill it up *every* time.
My PPOE was adopting this just before I bailed and found someone
saner to work for.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415408 is a reply to message #415402] |
Thu, 21 July 2022 14:52 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 21 Jul 2022 17:42:29 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2022-07-21, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> On Wed, 20 Jul 2022 18:43:30 -0400
>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>
>>> Good luck with that. Figuring out the spec from the code can be an
>>> immense undertaking.
>>
>> One which will inevitably lead to asking whether something is a
>> bug or a feature with no guidelines to help.
>
> At this point it's time to talk to the users, find out what they
> actually need, and make an executive decision. This is time-consuming
Discover that 70% have no idea, 20% find it an irritating bug that
they've been working round for decades and 10% depend on it and couldn't
get their work done without it.
> and politically hazardous, but it's the only clean solution.
> Beware of cargo-cult programming!
Ho yus!
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
|
|
|
|
| Re: COBOL and tricks [message #415425 is a reply to message #415262] |
Fri, 22 July 2022 01:54 |
|
|
Originally posted by: 25B.Z959
On 7/19/22 7:20 PM, D.J. wrote:
> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
> <peter_flass@yahoo.com> wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>
>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> > On 19/07/2022 18:48, Peter Flass wrote:
>>>> >> 25B.Z959 <25B.Z959@nada.net> wrote:
>>> [snip]
>>>> >>> Amazing how many institutions STILL run COBOL apps writ
>>>> >>> during the 60s by the guys with skinny ties. They work
>>>> >>> very well, they're too expensive to re-do, so ....
>>>> >>>
>>>> >>> There's probably a COBOL->C++ or JAVA translator out
>>>> >>> there somewhere ... but money's so tight these days
>>>> >>> and so many of those legacy apps are so super-critical
>>>> >>> that they just can't/won't.
>>>> >>>
>>>> >>
>>>> >> Maybe these are better than translators I have seen, but old ones produced
>>>> >> unreadable code, and they might well miss some litte tricks that the old
>>>> >> guys put in, and so leave time-bombs in the translated program. Much more
>>>> >> expensive, but a lot better, is to extract the specs from the existing
>>>> >> code, and there are re-engineering programs that can probably do a lot of
>>>> >> that work, and then rewrite in the new language using programmers skilled
>>>> >> in that language.
>>>> >>
>>>> >>
>>>> > TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>> > language is 'do it by the book, and write the book as documentation, as
>>>> > well'
>>>> >
>>>>
>>>> How much would you like to bet? Yes, the language encourages
>>>> straightforward programming, but I’ve seen things…
>>>
>>> A long time ago, I worked on many COBOL applications, including a
>>> client (PC) / server (MVS) communications application. I've seen
>>> things that I cannot unsee, coded things that I cannot uncode.
>>>
>>>
>>
>> I think I remember reading that someone once coded a compiler in COBOL.
>
> My senior year at university I had two classes; one a compiler i VAX
> PASCAL and an assembler in VAX PASCAL.
>
> Oh the sounds of joy from the computer room. Well, there were yells.
Pascal is a GOOD language - and with modern extensions
can do anything 'C' can do ... but more readably. I use
Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
compiler and write stuff in it for fun (and potential
function) sometimes.
Now olde-tyme by-the-book Wirth Pascal ... that'd be a
bit harder to write a compiler with ...
|
|
|
|
| Re: COBOL and tricks [message #415429 is a reply to message #415425] |
Fri, 22 July 2022 05:48 |
|
|
Originally posted by: Tauno Voipio
On 22.7.2022 08:54 AM, 25B.Z959 wrote:
> On 7/19/22 7:20 PM, D.J. wrote:
>> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
>> <peter_flass@yahoo.com> wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>
>>>> > The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> >> On 19/07/2022 18:48, Peter Flass wrote:
>>>> >>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> [snip]
>>>> >>>> Amazing how many institutions STILL run COBOL apps writ
>>>> >>>> during the 60s by the guys with skinny ties. They work
>>>> >>>> very well, they're too expensive to re-do, so ....
>>>> >>>>
>>>> >>>> There's probably a COBOL->C++ or JAVA translator out
>>>> >>>> there somewhere ... but money's so tight these days
>>>> >>>> and so many of those legacy apps are so super-critical
>>>> >>>> that they just can't/won't.
>>>> >>>>
>>>> >>>
>>>> >>> Maybe these are better than translators I have seen, but old ones
>>>> >>> produced
>>>> >>> unreadable code, and they might well miss some litte tricks that
>>>> >>> the old
>>>> >>> guys put in, and so leave time-bombs in the translated program.
>>>> >>> Much more
>>>> >>> expensive, but a lot better, is to extract the specs from the
>>>> >>> existing
>>>> >>> code, and there are re-engineering programs that can probably do
>>>> >>> a lot of
>>>> >>> that work, and then rewrite in the new language using programmers
>>>> >>> skilled
>>>> >>> in that language.
>>>> >>>
>>>> >>>
>>>> >> TBH you cant do many tricks in COBOL and the whole thrust of the
>>>> >> bloody
>>>> >> language is 'do it by the book, and write the book as
>>>> >> documentation, as
>>>> >> well'
>>>> >>
>>>> >
>>>> > How much would you like to bet? Yes, the language encourages
>>>> > straightforward programming, but I’ve seen things…
>>>>
>>>> A long time ago, I worked on many COBOL applications, including a
>>>> client (PC) / server (MVS) communications application. I've seen
>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>>
>>>>
>>>
>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> My senior year at university I had two classes; one a compiler i VAX
>> PASCAL and an assembler in VAX PASCAL.
>>
>> Oh the sounds of joy from the computer room. Well, there were yells.
>
>
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...
Urs Ammann, Kesav Nori and Christian Jacobi did exactly that.
They coded the original ETH Pascal compiler in Pascal and
bootstrapped it to compile itself.
I think that I may still have the listings somewhere.
--
-TV
|
|
|
|
| Re: COBOL and tricks [message #415437 is a reply to message #415425] |
Fri, 22 July 2022 09:03 |
scott
Messages: 4239
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
"25B.Z959" <25B.Z959@nada.net> writes:
> On 7/19/22 7:20 PM, D.J. wrote:
>> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> My senior year at university I had two classes; one a compiler i VAX
>> PASCAL and an assembler in VAX PASCAL.
>>
>> Oh the sounds of joy from the computer room. Well, there were yells.
>
>
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...
Yet our college undergraduate compiler coure built a Pascal
compiler using pretty-close-to-by-the-book Wirth Pascal
(although the more advanced students realized that since
we were using VAX Pascal, one could use those features
to make things a bit simpler).
|
|
|
|
| Re: COBOL and tricks [message #415439 is a reply to message #415425] |
Fri, 22 July 2022 10:20 |
|
|
Originally posted by: G.K.
On 7/22/22 00:54, 25B.Z959 wrote:
>
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...
With freepascal it is now possible to compile EFI / PE executables so
you can write bootable applications.
Does anyone know of any FPC tools for easing the creations of both BIOS
and EFI bootloaders? I wouldn't know the first thing about FPC syntax
for handing boot and ring 0 to a kernel program.
--
G.K.
|
|
|
|
| Re: COBOL and tricks [message #415440 is a reply to message #415425] |
Fri, 22 July 2022 10:21 |
D.J.
Messages: 821
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 22 Jul 2022 01:54:08 -0400, "25B.Z959" <25B.Z959@nada.net>
wrote:
> On 7/19/22 7:20 PM, D.J. wrote:
>> 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.
>
>
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...
We didn't deal with real numbers, just integers and text. This was
about 1988/89. And for the assembler, a limited list. It still took us
the entire time to write it. Not much, just a few thousand lines of
code, and a big chunk of comments as the professor wanted to see if we
understood what we had done. :-)
--
Jim
|
|
|
|
| Re: COBOL and tricks [message #415446 is a reply to message #415425] |
Fri, 22 July 2022 19:41 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"25B.Z959" <25B.Z959@nada.net> writes:
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...
(IBM) Los Gatos VLSI lab was doing a lot of language stuff with
Metaware's TWS ... and then used it for mainframe pascal compiler for
VLSI tool development ... eventually released as VS/PASCAL, was also
used to the original mainframe TCP/IP support.
Releasing mainframe TCP/IP support was big battle with the (SNA)
communication group ... they eventually decided it had to be released
through them which got 44kbyte/sec aggregate throughput using nearly
whole 3090 CPU. I then did the support for RFC1044 and in some turning
tests at Cray Research, between 4341 and Cray, got sustained 4341
channel throughput using only modest amount of 4341 cpu (something like
500 times improvement in bytes moved per instruction executed). I've
often commented the VS/pascal implementation had none of the
buffer/length problems that were epidemic in c language implementations.
After leaving IBM in the early 90s ... during IBM downturn, a lot of
stuff was being offloading ... including lots of chip tool applications
to industry tool vendors ... however industry standard platform was SUN
.... so all these apps had to be ported to SUN platform.
LSG hires me to port a 50,000 VS/PASCAL statement app to SUN. Enormous
amount of problems 1) I don't think SUN pascal had ever been used for
anything other than educational/instructional and 2) SUN had outsourced
pascal support to organization 12 times zones away on the opposite of
the world (easy drive to drop into SUN hdqtrs ... but didn't do much
good since had to wait until the following day for response, I did get a
billcap from "space city"). In retrospect, it would have been much
easier to have rewritten it in C.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: COBOL and tricks [message #415455 is a reply to message #415429] |
Sat, 23 July 2022 01:35 |
|
|
Originally posted by: 25B.Z959
On 7/22/22 5:48 AM, Tauno Voipio wrote:
> On 22.7.2022 08:54 AM, 25B.Z959 wrote:
>> On 7/19/22 7:20 PM, D.J. wrote:
>>> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
>>> <peter_flass@yahoo.com> wrote:
>>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>> > On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>> >
>>>> >> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> >>> On 19/07/2022 18:48, Peter Flass wrote:
>>>> >>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> > [snip]
>>>> >>>>> Amazing how many institutions STILL run COBOL apps writ
>>>> >>>>> during the 60s by the guys with skinny ties. They work
>>>> >>>>> very well, they're too expensive to re-do, so ....
>>>> >>>>>
>>>> >>>>> There's probably a COBOL->C++ or JAVA translator out
>>>> >>>>> there somewhere ... but money's so tight these days
>>>> >>>>> and so many of those legacy apps are so super-critical
>>>> >>>>> that they just can't/won't.
>>>> >>>>>
>>>> >>>>
>>>> >>>> Maybe these are better than translators I have seen, but old
>>>> >>>> ones produced
>>>> >>>> unreadable code, and they might well miss some litte tricks that
>>>> >>>> the old
>>>> >>>> guys put in, and so leave time-bombs in the translated program.
>>>> >>>> Much more
>>>> >>>> expensive, but a lot better, is to extract the specs from the
>>>> >>>> existing
>>>> >>>> code, and there are re-engineering programs that can probably do
>>>> >>>> a lot of
>>>> >>>> that work, and then rewrite in the new language using
>>>> >>>> programmers skilled
>>>> >>>> in that language.
>>>> >>>>
>>>> >>>>
>>>> >>> TBH you cant do many tricks in COBOL and the whole thrust of the
>>>> >>> bloody
>>>> >>> language is 'do it by the book, and write the book as
>>>> >>> documentation, as
>>>> >>> well'
>>>> >>>
>>>> >>
>>>> >> How much would you like to bet? Yes, the language encourages
>>>> >> straightforward programming, but I’ve seen things…
>>>> >
>>>> > A long time ago, I worked on many COBOL applications, including a
>>>> > client (PC) / server (MVS) communications application. I've seen
>>>> > things that I cannot unsee, coded things that I cannot uncode.
>>>> >
>>>> >
>>>>
>>>> I think I remember reading that someone once coded a compiler in COBOL.
>>>
>>> My senior year at university I had two classes; one a compiler i VAX
>>> PASCAL and an assembler in VAX PASCAL.
>>>
>>> Oh the sounds of joy from the computer room. Well, there were yells.
>>
>>
>> Pascal is a GOOD language - and with modern extensions
>> can do anything 'C' can do ... but more readably. I use
>> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
>> compiler and write stuff in it for fun (and potential
>> function) sometimes.
>>
>> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
>> bit harder to write a compiler with ...
>
> Urs Ammann, Kesav Nori and Christian Jacobi did exactly that.
>
> They coded the original ETH Pascal compiler in Pascal and
> bootstrapped it to compile itself.
>
> I think that I may still have the listings somewhere.
I love languages/systems written in themselves - it's
such a neat concept :-)
However modern object Pascal - it WOULD be a lot easier.
I liked IBM/MS-Pascal - the old multi-pass compiler/linker
in the pink manuals with the 5-1/4 floppies inside. Something
about the overall philosophy/structure was SO much more
appealing than FORTRAN or PL/I and such (but K&R-ish 'C' -
that's a special class unto itself and I write it often -
still have the actual K&R book on the shelf).
Then came Philippe Kahn and the world changed. Gen-2
RAD/IDE environments vastly sped up development. Gen-3
IMHO is kinda the pinnacle - drag and drop yer GUI and
then customize function. Lazarus/Delphi (ok, Del kinda
priced itself out of the market).
In any case, if you want a nice GUI for an app like
TODAY - use Lazarus. 99% portable to Winders too (it's
usually the damned fonts that don't quite fit).
But once in awhile, I still write a little utility
in FORTRAN or BASIC or COBOL ... just for fun.
Let my successors suffer a bit :-)
Oh yea ... a Linux-ish question ... has anyone found
a decent Modula-3 compiler that'll actually install
and run properly in Deb ??? I've had zero success.
They'll SAY it'll work - and then there's a zillion
confounding error messages. A native compiler is
more to my liking than 'translators' like the 'G__'
family.
(and any language where the word 'lambda' shows up
often and/or has lots and LOTS of nested brackets ...
no,no,no :-)
|
|
|
|
| Re: COBOL and tricks [message #415460 is a reply to message #415283] |
Sat, 23 July 2022 15:18 |
|
|
Originally posted by: 25B.Z959
On 7/19/22 10:50 PM, Lew Pitcher wrote:
> 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."
Sometimes that IS a factor ... you have to have people who
can write it. But 1990 ... IMHO it should have been 'C'.
>> Yea, you could do it in BASIC too ... with lots of
>> DATA statements. I remember converting a Fortran
>> pgm to IBMPC BASIC, but had to work that newfangled
>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>
>> COBOL was deliberately made to do "business stuff" in a
>> super-wordy fashion that was SUPPOSED to be "self documenting".
>
> Agreed. That was the defining component of COBOL, and perhaps it's
> saving grace.
Ummmmm ....
Mostly I like "terse" languages - less typing and lots
of room left over for comments at the ends of the lines.
'C' fits the bill pretty well. But you DO need the
comments because the syntax doesn't lend itself to a
quick read. 2/3rds of every 'C' program I do is comments,
from brief to expositions. That way I can come back to
it a few years later and sort-of figure out what I
was doing.
>> Maybe the only language requiring more text than Java :-)
>
> Those of us who coded COBOL for a living kept a boilerplate^W
> template program handy, just so we didn't have to fill in all that
> language /just/ to get a program started.
Now we just cut and paste from the internet :-)
The fine detail and complexity of what we do with
computers now has long since reached the point where
nobody can know it all. We have to go to 'the library'
and find various templates - and build upon them.
|
|
|
|
| Re: COBOL and tricks [message #415462 is a reply to message #415460] |
Sat, 23 July 2022 15:32 |
|
|
Originally posted by: Lew Pitcher
On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:
> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>> 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."
>
>
> Sometimes that IS a factor ... you have to have people who
> can write it. But 1990 ... IMHO it should have been 'C'.
As was mine, at the time. But, in that corporate environment,
C was almost unknown.
>>> Yea, you could do it in BASIC too ... with lots of
>>> DATA statements. I remember converting a Fortran
>>> pgm to IBMPC BASIC, but had to work that newfangled
>>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>>
>>> COBOL was deliberately made to do "business stuff" in a
>>> super-wordy fashion that was SUPPOSED to be "self documenting".
>>
>> Agreed. That was the defining component of COBOL, and perhaps it's
>> saving grace.
>
> Ummmmm ....
>
> Mostly I like "terse" languages - less typing and lots
> of room left over for comments at the ends of the lines.
> 'C' fits the bill pretty well. But you DO need the
> comments because the syntax doesn't lend itself to a
> quick read. 2/3rds of every 'C' program I do is comments,
> from brief to expositions. That way I can come back to
> it a few years later and sort-of figure out what I
> was doing.
This development occurred in a large (1000+ branch) banking environment.
When we got specs from the users, they were along the lines of
you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
giving the INTEREST ADJUSTMENT.
you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
giving the ADJUSTED ACCOUNT BALANCE.
which a programmer might convert into
MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
The convenience was that the user's description /was/ the program code.
>>> Maybe the only language requiring more text than Java :-)
>>
>> Those of us who coded COBOL for a living kept a boilerplate^W
>> template program handy, just so we didn't have to fill in all that
>> language /just/ to get a program started.
>
> Now we just cut and paste from the internet :-)
Yah. Sad, that.
> The fine detail and complexity of what we do with
> computers now has long since reached the point where
> nobody can know it all. We have to go to 'the library'
> and find various templates - and build upon them.
--
Lew Pitcher
"In Skills, We Trust"
|
|
|
|
| Re: COBOL and tricks [message #415464 is a reply to message #415462] |
Sat, 23 July 2022 17:48 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-23, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:
>
>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>
>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>> template program handy, just so we didn't have to fill in all that
>>> language /just/ to get a program started.
>>
>> Now we just cut and paste from the internet :-)
>
> Yah. Sad, that.
https://en.wikipedia.org/wiki/Cargo_cult_programming
--
/~\ 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 #415465 is a reply to message #415460] |
Sat, 23 July 2022 18:23 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>> 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."
>
>
> Sometimes that IS a factor ... you have to have people who
> can write it. But 1990 ... IMHO it should have been 'C'.
>
IMNSHO, COBOL. C is a terrible language for those types of language. Things
that are so dimple in COBOL, like moving a character string with blank
fill, or formatting numeric output, requires calling subroutines in C, and
lack of length checking on string moves is a recipe for disaster.
I have used both languages quite a bit, perhaps COBOL more, years ago, but
neither is my preferred language, so I have no dog in this fight.
…
>
> Mostly I like "terse" languages - less typing and lots
> of room left over for comments at the ends of the lines.
Sounds like assembler ;-)
It’s too easy to write tricky code with side-effects in C. COBOL might not
be as self-documenting as advertised, but the operation of each statement
is pretty obvious and easily understood.
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415466 is a reply to message #415465] |
Sat, 23 July 2022 18:26 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>> 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."
>>
>>
>> Sometimes that IS a factor ... you have to have people who
>> can write it. But 1990 ... IMHO it should have been 'C'.
>>
>
> IMNSHO, COBOL. C is a terrible language for those types of language. Things
> that are so dimple in COBOL, like moving a character string with blank
> fill, or formatting numeric output, requires calling subroutines in C, and
> lack of length checking on string moves is a recipe for disaster.
>
> I have used both languages quite a bit, perhaps COBOL more, years ago, but
> neither is my preferred language, so I have no dog in this fight.
> …
>
>>
>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>
> Sounds like assembler ;-)
>
> It’s too easy to write tricky code with side-effects in C. COBOL might not
> be as self-documenting as advertised, but the operation of each statement
> is pretty obvious and easily understood.
>
“ types of language” should have been “ types of application.”
“dimple”->”simple”, etc. typing balancing my ipad unsteadily on my lap.
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415467 is a reply to message #415462] |
Sat, 23 July 2022 19:50 |
|
|
Originally posted by: Allodoxaphobia
On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>
> This development occurred in a large (1000+ branch) banking environment.
> When we got specs from the users, they were along the lines of
> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
> giving the INTEREST ADJUSTMENT.
> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
> giving the ADJUSTED ACCOUNT BALANCE.
> which a programmer might convert into
> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>
> The convenience was that the user's description /was/ the program code.
Good luck finding white collar droids
now-a-days that can write that clearly!
Ya, a couple hundred years ago I was a programmer in a corporate-captive
service company that did the data processing for 25 or so branch banks.
Did PL/1 and assembler -- mostly on the systems side versus applications.
The specs that came down for projects was always well defined and detailed.
I don't think that's the case these days.
Jonesy
|
|
|
|
| Re: COBOL and tricks [message #415474 is a reply to message #415462] |
Sat, 23 July 2022 23:08 |
|
|
Originally posted by: 25B.Z959
On 7/23/22 3:32 PM, Lew Pitcher wrote:
> On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:
>
>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>> 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."
>>
>>
>> Sometimes that IS a factor ... you have to have people who
>> can write it. But 1990 ... IMHO it should have been 'C'.
>
> As was mine, at the time. But, in that corporate environment,
> C was almost unknown.
The K&R bible on the language came out in 1978, 2nd
ed about a decade later. Still have the 2nd ed on my
shelf and DO look up stuff in it from time to time.
Most of my code still has a very K&R look and feel.
I was writing 'C' on the original IBM-PCs in the mid
80s, and with Aztec 'C' for CP/M-80 around the same
timeframe (that's when IBM-PCs came with a DOS *and*
a CP/M-86 floppy :-) So, the language and its strengths
surely weren't UNKNOWN.
Admittedly 'C' was originally kind of part of the
Unix & PDP-11 sphere, more 'academia', so if yer bosses
didn't use or pay attention to anything like that then
it really might have escaped their notice. Pointy-haired
know-nothing bosses aren't anything new alas.
>>>> Yea, you could do it in BASIC too ... with lots of
>>>> DATA statements. I remember converting a Fortran
>>>> pgm to IBMPC BASIC, but had to work that newfangled
>>>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>>>
>>>> COBOL was deliberately made to do "business stuff" in a
>>>> super-wordy fashion that was SUPPOSED to be "self documenting".
>>>
>>> Agreed. That was the defining component of COBOL, and perhaps it's
>>> saving grace.
>>
>> Ummmmm ....
>>
>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>> 'C' fits the bill pretty well. But you DO need the
>> comments because the syntax doesn't lend itself to a
>> quick read. 2/3rds of every 'C' program I do is comments,
>> from brief to expositions. That way I can come back to
>> it a few years later and sort-of figure out what I
>> was doing.
>
> This development occurred in a large (1000+ branch) banking environment.
I can understand the conservatism ... and having lots
of COBOL programmers around.
> When we got specs from the users, they were along the lines of
> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
> giving the INTEREST ADJUSTMENT.
> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
> giving the ADJUSTED ACCOUNT BALANCE.
> which a programmer might convert into
> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>
> The convenience was that the user's description /was/ the program code.
For straightforward lines ... but, kinda like with FORTRAN, when
you start to get into formatting the output PICs can get pretty
cryptic and un-intuitive and the sheer wordiness makes typos
more likely. "X++" is less wordy than "ADD 1 TO X" and you
can "x++" or "++x" instead of structuring it in in a COBOL pgm
I do notice that COBOL-related forums and help pages and
such are still kinda busy, so it's not remotely a dead
language. People are still writing/updating COBOL code.
FORTRAN is still pretty widely used also, esp in academic
and engineering environments, mostly due to the huge volume
of proven hard-core math routines which nobody wants to
re-write. Now BASIC ... does ANYBODY use BASIC anymore ?
USED to be THE introductory language ......
Anyway, I basically dropped COBOL and FORTRAN in favor of 'C'
(and Pascal) a long time ago. I think the 2nd version of Turbo
Pascal had straight-up math-coprocessor support and at the time
I was translating a lot of old FORTRAN statistics routines over
to the IBM-PCs for scientifics and stat-mongers. IBM-PC 'C' also
had 8087 libraries, but the TP environment made development a
LOT faster. Time a Fourier Transform with, and without, a math
coprocessor sometime :-)
After that, various micro-controller projects - 8051s/PICS, later
Arduino's and such ... mix of assembler and compiler-generated
code (esp for the very annoying serial-comm stuff).
>>>> Maybe the only language requiring more text than Java :-)
>>>
>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>> template program handy, just so we didn't have to fill in all that
>>> language /just/ to get a program started.
>>
>> Now we just cut and paste from the internet :-)
>
> Yah. Sad, that.
I still sometimes buy actual BOOKS ... hard to hold three
different pages open at the same time on the net and flip
back and forth. Just ain't the same. I think the tangibility
of paper enhances memory too, multi-sensory association.
A lot easier to scribble notes circles and arrows on it too.
A lot of the code snippets you find on the net are kind of
defective too - or ONLY intended as demos. Takes a lot of
spiffing-up and expansion to put them into something real
but at LEAST you have a template to work with.
>> The fine detail and complexity of what we do with
>> computers now has long since reached the point where
>> nobody can know it all. We have to go to 'the library'
>> and find various templates - and build upon them.
>
|
|
|
|
| Re: COBOL and tricks [message #415476 is a reply to message #415464] |
Sun, 24 July 2022 00:07 |
|
|
Originally posted by: 25B.Z959
On 7/23/22 5:48 PM, Charlie Gibbs wrote:
> On 2022-07-23, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>
>> On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:
>>
>>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>>
>>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>>> template program handy, just so we didn't have to fill in all that
>>>> language /just/ to get a program started.
>>>
>>> Now we just cut and paste from the internet :-)
>>
>> Yah. Sad, that.
>
> https://en.wikipedia.org/wiki/Cargo_cult_programming
Been there :-)
Though I usually figure out pretty quick what's
necessary and what's not because I like terse
programs.
I do have my own little library of handy functions
in several languages - and tend to just paste it
all into new programs whether all of the bits are
used or not. However I see this as "preservation
through replication" ... I'll always be able to
find them by looking in an old program. Recently
rendered some of them in FORTRAN and ADA too, just
in case.(no, I do NOT like ADA - WAY too anal, Lady
Lovelace was probably much more fun)
|
|
|
|
| Re: COBOL and tricks [message #415478 is a reply to message #415467] |
Sun, 24 July 2022 01:31 |
|
|
Originally posted by: 25B.Z959
On 7/23/22 7:50 PM, Allodoxaphobia wrote:
> On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>>
>> This development occurred in a large (1000+ branch) banking environment.
>> When we got specs from the users, they were along the lines of
>> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
>> giving the INTEREST ADJUSTMENT.
>> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
>> giving the ADJUSTED ACCOUNT BALANCE.
>> which a programmer might convert into
>> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
>> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>>
>> The convenience was that the user's description /was/ the program code.
>
> Good luck finding white collar droids
> now-a-days that can write that clearly!
>
> Ya, a couple hundred years ago I was a programmer in a corporate-captive
> service company that did the data processing for 25 or so branch banks.
> Did PL/1 and assembler -- mostly on the systems side versus applications.
> The specs that came down for projects was always well defined and detailed.
Ah ... PL/I ... one of the great "and the kitchen sink too"
languages. Not awful - usually several ways to accomplish
the same thing ... ie "flexibility". A bit odd though, like
a mutant hybrid of Algol and BASIC
> I don't think that's the case these days.
NOT - for sure. Now it's more "Dilbert" and the
bosses don't know dick and the project initiators
mostly like to APPEAR to know stuff.
HOWEVER ... "fuzzy" specs CAN lead to significant
innovation. Too-tight specs lead to tight, but oft
unimaginative, solutions. The old white-shirt/
narrow-tie crowd DID have a very useful place (and
I wish we still had a few more of them), but so do
the addled hacks with little guidance.
I like programming to be FUN - never "just a JOB"
like some assembly line - and have always found
places where that can be realized. Smaller outfits,
less pay, but WORTH it and always interesting.
I've got one boss now who thinks that anything
with "Microsoft" on the label is the greatest
most wonderful thing EVER, mostly because some
other outfits are all-MS shops and that's "biz-
standard", beyond critique. I know better.
I'll keep that a secret until I hand in my
retirement notice. Besides, they'd have to throw
out the printers, monitors, routers, hubs, iPads/Phones
and NASs, Google and pretty much everything to avoid
Unix/Linux products. Scuttlebutt is that Win-12 will
be just like OS-X ... a Winders-looking face on top
of a Unix core because "real Winders" has just become
such an unmanagable/un-securable MESS - dead end. If you
don't know Unix/Linux then you can't be an I.T. pro
because it's EVERYWHERE, in EVERYTHING.
And when they call about an EMERGENCY - they'll just
get the "Gone Fishin'" message ........ :-)
Charlie Gibbs signs off with :
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <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.
If it's REALLY IMPORTANT - I'd suggest Free/Open-BSD Unix
instead. If it's BIG too - IBM z-OS. After decades of
real-world experiences, "-IX/UX" has proven itself superior.
Though such a pity VMS died out ... still have the 3-1/2
inch thick small-print manual ......... :-)
|
|
|
|
| Re: COBOL and tricks [message #415479 is a reply to message #415467] |
Sun, 24 July 2022 01:44 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 23 Jul 2022 23:50:45 GMT
Allodoxaphobia <trepidation@example.net> wrote:
> Ya, a couple hundred years ago I was a programmer in a corporate-captive
> service company that did the data processing for 25 or so branch banks.
> Did PL/1 and assembler -- mostly on the systems side versus applications.
> The specs that came down for projects was always well defined and
> detailed.
The problems started when the well defined and detailed specs were
also wrong which tended to happen when projects moved from well defined
data processing to less well defined operational support and even less well
defined customer facing products.
> I don't think that's the case these days.
Very rarely, most of the well defined problems have been done
decades ago.
Most modern software development is done in an environment of
shifting priorities and vaguely defined changing goals. For this reason
feature driven incremental development (give them something fast, then see
what they want next and give it to them - iterate last step until done)
tends to be the only successful approach (these days with a lot of window
dressing courtesy of the "Agile Foundation"). This sort of development also
favours rapid development tools, highly readable code, extensive unit and
functional testing and a short horizon. It's fun too.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
|
|
|
|
| Re: COBOL and tricks [message #415491 is a reply to message #415467] |
Sun, 24 July 2022 16:13 |
Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On 23 Jul 2022 23:50:45 GMT
Allodoxaphobia <trepidation@example.net> wrote:
> On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>>
>> This development occurred in a large (1000+ branch) banking environment.
>> When we got specs from the users, they were along the lines of
>> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
>> giving the INTEREST ADJUSTMENT.
>> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
>> giving the ADJUSTED ACCOUNT BALANCE.
>> which a programmer might convert into
>> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
>> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>>
>> The convenience was that the user's description /was/ the program code.
>
> Good luck finding white collar droids
> now-a-days that can write that clearly!
>
Even in those days it might have been
SET 0800-INTADJ = IFILE-ACCTBAL * MIR
SET OFILE-ADJACCTBAL = IFILE-ACCTBAL + 0800-INTADJ
or somesuch "standard"
> Ya, a couple hundred years ago I was a programmer in a corporate-captive
> service company that did the data processing for 25 or so branch banks.
> Did PL/1 and assembler -- mostly on the systems side versus applications.
> The specs that came down for projects was always well defined and detailed.
>
> I don't think that's the case these days.
>
> Jonesy
--
Bah, and indeed Humbug.
|
|
|
|
| Re: COBOL and tricks [message #415497 is a reply to message #415491] |
Sun, 24 July 2022 19:49 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
> On 23 Jul 2022 23:50:45 GMT
> Allodoxaphobia <trepidation@example.net> wrote:
>
>> On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>>>
>>> This development occurred in a large (1000+ branch) banking environment.
>>> When we got specs from the users, they were along the lines of
>>> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
>>> giving the INTEREST ADJUSTMENT.
>>> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
>>> giving the ADJUSTED ACCOUNT BALANCE.
>>> which a programmer might convert into
>>> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
>>> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>>>
>>> The convenience was that the user's description /was/ the program code.
>>
>> Good luck finding white collar droids
>> now-a-days that can write that clearly!
>>
>
> Even in those days it might have been
>
> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
> SET OFILE-ADJACCTBAL = IFILE-ACCTBAL + 0800-INTADJ
>
> or somesuch "standard"
I can't recall seeing code that bad.
The language lends itself to using very consistent naming.
Most places I worked you could predict character for character what a
block of code would look like.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415499 is a reply to message #415491] |
Sun, 24 July 2022 22:25 |
|
|
Originally posted by: drb
> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
More like
MULTIPLY IFILE-ACCTBAL BY MIR GIVING 0800-INTADJ.
or
COMPUTE 0800-INTADJ = IFILE-ACCTBAL * MIR.
De
|
|
|
|
| Re: COBOL and tricks [message #415501 is a reply to message #415491] |
Mon, 25 July 2022 00:02 |
|
|
Originally posted by: 25B.Z959
On 7/24/22 4:13 PM, Kerr-Mudd, John wrote:
> On 23 Jul 2022 23:50:45 GMT
> Allodoxaphobia <trepidation@example.net> wrote:
>
>> On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>>>
>>> This development occurred in a large (1000+ branch) banking environment.
>>> When we got specs from the users, they were along the lines of
>>> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
>>> giving the INTEREST ADJUSTMENT.
>>> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
>>> giving the ADJUSTED ACCOUNT BALANCE.
>>> which a programmer might convert into
>>> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
>>> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>>>
>>> The convenience was that the user's description /was/ the program code.
>>
>> Good luck finding white collar droids
>> now-a-days that can write that clearly!
>>
>
> Even in those days it might have been
>
> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
> SET OFILE-ADJACCTBAL = IFILE-ACCTBAL + 0800-INTADJ
>
> or somesuch "standard"
Heh heh .... yea, we all get sick of writing out
long "descriptive names" and "self documenting"
code. Something about it just grates on the soul,
impedes the creative impulse.
|
|
|
|
| Re: COBOL and tricks [message #415502 is a reply to message #415465] |
Mon, 25 July 2022 00:08 |
|
|
Originally posted by: 25B.Z959
On 7/23/22 6:23 PM, Peter Flass wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>> 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."
>>
>>
>> Sometimes that IS a factor ... you have to have people who
>> can write it. But 1990 ... IMHO it should have been 'C'.
>>
>
> IMNSHO, COBOL. C is a terrible language for those types of language. Things
> that are so dimple in COBOL, like moving a character string with blank
> fill, or formatting numeric output, requires calling subroutines in C, and
> lack of length checking on string moves is a recipe for disaster.
>
> I have used both languages quite a bit, perhaps COBOL more, years ago, but
> neither is my preferred language, so I have no dog in this fight.
Sorry, I like 'C' - and have writ little functions, MY way,
to do a lot of the things you were talking about.
Only ASM gives you more control - and I've done my share of
that over the years too.
>
>>
>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>
> Sounds like assembler ;-)
YES ! :-)
ASM ... MMmmmmmmm !
> It’s too easy to write tricky code with side-effects in C. COBOL might not
> be as self-documenting as advertised, but the operation of each statement
> is pretty obvious and easily understood.
So ... COBOL is for BAD PROGRAMMERS who can't foresee
downstream consequences hmmm ??? ;-)
|
|
|
|
Members
Search
Help
Register
Login
Home
