From Newsgroup: comp.lang.cobol

As an aside to the "some numbers to consider" thread I received some
private mail.

Obviously, I would not betray the trust of the poster by publishing information which might identify him/her, but at least one of the points he/she raised made me think some more, so I am sharing it here.

PP = Private Poster
PD = me (Pete Dashwood).

================= transcript of excerpt from private mail ============

PP: ...I would go so far as to say that ROI is not as inexorable as
laziness, selfishness and pretending that problems don't exist.

PD: Those are all certainly contributing factors to the decline of
things, but, in and of themselves, they donrCOt actually force change. :-)

PP: Sin isn't just about doing bad things and not doing good things,
it's also about a power within us all that militates against our desire
to change ourselves and the world around us.

PD: I understand your position, but I believe we can overcome that evil
in our nature. Whether we do it through a belief system or a Religion,
or just by deciding we will make things better, or because of events in
our Life experience which changed our mind about something, there is the
same potential for good in Human Beings as there is for evil. I have
seen, time and again, such goodness in people and there have been many
times in my life when I was thankful for the kindness of strangers; we
should not let the bad just blind us to the good.

PP: At present I am in my XXth year. I expect to see COBOL alive and
well when I am XX. Given my family's medical history I do not see this
body lasting until I am 77. Nevertheless, I expect COBOL to outlast me.

PD: Surprisingly perhaps, I agree. There will be places where COBOL will
be used for some decades to come. But that is not my argument. The point
is that COBOL is NOT the answer to everything and the rCLonly game in
townrCY as it was back in the 1970s. There are very sound reasons for the rCLdecline of COBOLrCY and they have nothing to do with inadequacy in the language. (COBOL is a very adequate and capable language and served us
well for half a century...) The world has changed and the people in it
have different expectations from the people of the 1970s. The ways in
which we do business and commerce have changed radically and a different paradigm from the one that COBOL is based on is required to handle
modern commerce.

PP: Perhaps those sites that still use COBOL will start their own
internal schools to train up the next generation of maintenance
programmers. They would do well to gather the Tiffins, Trembleys,
Gunshannons, Dashwoods and Doc Dwarfs of the world before all that
knowledge and wisdom dies but again, I don't see human nature making
that good move likely.

PD: It is easy to be discouraged, but it isnrCOt human nature that will
lead to the loss of expertise. There is a natural evolution of knowledge
and experience and what is no longer relevant, gets archived, or
transferred to someone else, or it gets lost.

After 52 years in IT (much of it involving COBOL), I can think of many
things I learned and for which there is no longer any use. Hours spent, studying and considering, then, within a few years, it is rendered
pointless or obsolete. I could be embittered by it, or I can accept the reality and get stuck into learning something that is currently more pertinent, even in the almost certain knowledge that that too will be
rendered pointless at some time, by the changes enforced by the
continuing march of technology and civilization. It is neither rCLgoodrCY
nor rCLbadrCY; it is just the nature of things.

I console myself with the observation that the action of learning
something makes it easier to learn stuff and improves the ability to
learn. These days I can teach myself anything I want (or need) to know,
far more easily than I could 30 or 40 years ago. (And almost the sum
total of human knowledge is available to us...) It may be true that
teaching an old dog new tricks is difficult, but if what the dog learned
was how to learn, then it is not so difficult.

I donrCOt believe there is any such thing as rCLuseless knowledgerCY. (There is much in my head for which I havenrCOt found a use yet, but it keeps me
from being bored on long plane flights or sitting in waiting rooms... :-))

Knowledge is the key to wisdom.

Having said that, I have reached a point now where it gets tiresome to
have the same arguments, especially when no minds are likely to be
changed (including mine...). So I have taken the option which the
technology provides, and brain dumped my position on COBOL to the
COBOL21 side of the PRIMA website. There you can find WHY I believe in
Objects and Layers, WHY I think Embedded SQL is an abomination, WHY I
believe the best rCLProject ManagementrCY system will involve interaction
and iteration, and (through the Lounge) you can prod me on anything else
you might want my opinion on... :-) I will be happy to discuss any of
the many arguable positions posted there, but please, do me the courtesy
of reading the background to what I think, before contesting it.

(IrCOm arranging for the web site to continue after IrCOm gone; a trust will pay for it to continue, but IrCOd be interested to hear from anyone whorCOd like to manage it...)

Hopefully, I'll be good for a few years yet and I'll be contributing as
long as I can see and type... :-)

But, eventually, as for all of us, the time will come when the posts
must stop.

Pete.
--
I used to write COBOL; now I can do anything...

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 11/26/2017 6:27 PM, pete dashwood wrote:

As an aside to the "some numbers to consider" thread I received some
private mail.

Obviously, I would not betray the trust of the poster by publishing information which might identify him/her, but at least one of the points he/she raised made me think some more, so I am sharing it here.

PP = Private Poster
PD = me (Pete Dashwood).

================= transcript of excerpt from private mail ============
(snip)
PP: Perhaps those sites that still use COBOL will start their own
internal schools to train up the next generation of maintenance
programmers. They would do well to gather the Tiffins, Trembleys, Gunshannons, Dashwoods and Doc Dwarfs of the world before all that
knowledge and wisdom dies but again, I don't see human nature making
that good move likely.

PD: It is easy to be discouraged, but it isnrCOt human nature that will
lead to the loss of expertise. There is a natural evolution of knowledge
and experience and what is no longer relevant, gets archived, or
transferred to someone else, or it gets lost.

I guess this means I am not the "Private Poster"! It's nice to be
thought of as knowledgeable, but I'm sure there are many people out
there who know COBOL better than I do. Tom Ross and Don Nelson, for
example.

I like COBOL. That's why I work with GnuCOBOL even though I've been
retired for over a year. I think there's a place for COBOL for many
years to come, but I wouldn't want to write a GUI in it, or an Operating System, or a low-level network driver. I still see some of my former co-workers socially, and occasionally I get a phone call asking how the
old system worked, which I am happy to answer.

Someday COBOL will probably fade away completely, when there truly is no
need for it any more. I don't miss punch cards but they were critically important for data processing from about 1890 to about 1970. They were
made obsolete by magnetic tape and disk. Now magnetic tape is almost obsolete, being replaced by disk, cache, and SSD. What will replace
COBOL? I have no idea. I don't think it will be Java, Python, SQL,
SAP, or C#, but anything is possible.

If a particular technology truly becomes obsolete, it will be forgotten,
and that's okay. Nothing lasts forever.

Kind regards,

Arnold

(rest snipped)

--
http://www.arnoldtrembley.com/

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 11/26/2017 11:34 PM, Arnold Trembley wrote:

On 11/26/2017 6:27 PM, pete dashwood wrote:

As an aside to the "some numbers to consider" thread I received some
private mail.

Obviously, I would not betray the trust of the poster by publishing
information which might identify him/her, but at least one of the
points he/she raised made me think some more, so I am sharing it here.

PP = Private Poster
PD = me (Pete Dashwood).

================= transcript of excerpt from private mail ============
(snip) PP: Perhaps those sites that still use COBOL will start their
own internal schools to train up the next generation of maintenance
programmers. They would do well to gather the Tiffins, Trembleys,
Gunshannons, Dashwoods and Doc Dwarfs of the world before all that
knowledge and wisdom dies but again, I don't see human nature making
that good move likely.

PD: It is easy to be discouraged, but it isnrCOt human nature that will
lead to the loss of expertise. There is a natural evolution of
knowledge and experience and what is no longer relevant, gets
archived, or transferred to someone else, or it gets lost.

I guess this means I am not the "Private Poster"!-a It's nice to be
thought of as knowledgeable, but I'm sure there are many people out
there who know COBOL better than I do.-a Tom Ross and Don Nelson, for example.

I like COBOL.-a That's why I work with GnuCOBOL even though I've been retired for over a year.-a I think there's a place for COBOL for many
years to come, but I wouldn't want to write a GUI in it, or an Operating System, or a low-level network driver.-a I still see some of my former co-workers socially, and occasionally I get a phone call asking how the
old system worked, which I am happy to answer.

Someday COBOL will probably fade away completely, when there truly is no need for it any more.-a I don't miss punch cards but they were critically important for data processing from about 1890 to about 1970.-a They were made obsolete by magnetic tape and disk.-a Now magnetic tape is almost obsolete, being replaced by disk, cache, and SSD.-a What will replace COBOL?-a I have no idea.-a I don't think it will be Java, Python, SQL,
SAP, or C#, but anything is possible.

If a particular technology truly becomes obsolete, it will be forgotten,
and that's okay.-a Nothing lasts forever.

Kind regards,

Arnold

(rest snipped)

This thread reminded me of something that I was thinking about the other
day: here in Canada there is a major kerfuffle about the federal
government's huge Payroll system failure. The Phoenix Payroll system

<https://www.itworldcanada.com/article/phoenix-payroll-system-timeline-of-the-governments-problems/396407>

was a project started by a previous government (around 2009) in
conjunction with IBM who 'won' the contract with a proposal to use a PeopleSoft-based replacement system.

As government projects often do, this went off the rails and continues
to be a disaster: many government employees are overpaid (literally) or underpaid or not paid at all (!)

In the article linked above there is a quote "Federal government
encountered 'unanticipated complexity' in rolling out payroll system".

LMAO.

Recent news about the current situation made me shudder, but then I
started to think about this question: If you were to write a payroll
system today what language would you use?? Certainly not C++ or Python
or ? Nevermind the folly of writing ones own payroll system (no idea
why they didn't just farm it out to any of a number of commercial
payroll processing firms - oh, right, THE GOVERNMENT has unique and insurmountable special requirements....hahahaha

I thought about COBOL and of course the discussions here. Then I thought
about writing a payroll program in Java, then I decided to stop thinking
and find some single malt.

Cheers all.

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 28/11/2017 3:58 AM, Kerry Liles wrote:

On 11/26/2017 11:34 PM, Arnold Trembley wrote:

On 11/26/2017 6:27 PM, pete dashwood wrote:

As an aside to the "some numbers to consider" thread I received some
private mail.

<snipped>

This thread reminded me of something that I was thinking about the other day: here in Canada there is a major kerfuffle about the federal government's huge Payroll system failure. The Phoenix Payroll system

<https://www.itworldcanada.com/article/phoenix-payroll-system-timeline-of-the-governments-problems/396407>

was a project started by a previous government (around 2009) in
conjunction with IBM who 'won' the contract with a proposal to use a PeopleSoft-based replacement system.

As government projects often do, this went off the rails and continues
to be a disaster: many government employees are overpaid (literally) or underpaid or not paid at all (!)

We had a very similar problem here with the Teachers' payroll a couple
of years back. Everyone continues to underestimate the criticality of a Payroll system... If it fails, it can disrupt lives, families, and communities.

In the article linked above there is a quote "Federal government
encountered 'unanticipated complexity' in rolling out payroll system".

In other words, they didn't do proper design. Had they done so, they
would have realized the complexity and anticipated it...

LMAO.

Yep, anyone who has ever worked on a Payroll system KNOWS that it is the
most sensitive and often the most complex system to computerize.

In the old days when the new mainframes arrived, everyone was keen to
get working with them and people rushed to develop applications that
would justify having them. The lesson was very soon learned that Payroll should be the LAST application you computerize, because it is far and
away the most difficult, and requires the most careful design and
analysis before you even start to write anything.

In the early 1970s I was the Chief programmer at Auckland Hospital,
which was an ICL 1900 shop running COBOL. We had a major success
computerizing the dispensaries (cut the number of drugs dispensed being
either the wrong drug or the wrong dose, from something like 18% to
.1%), and, flushed with this success, the decision was taken to
implement Payroll...

It isn't immediately obvious, but Hospitals employ a huge diversity of
Trades and Professions on all kinds of bases (full-time, part-time,
contract, consultancy, etc.). Everything from gardeners to brain
surgeons, all with their own awards and bonuses and Unions... You would
think that with around 4000 people on the payroll it should be a walk in
the park; hey, you could pay them with a ball point pen and a team of
clerks, couldn't you? (That was pretty much how it worked at the time...)

It was expected to take 9 months and after 3 years it was kind of
working... The people involved were all very competent, good analysts,
good programmers and good management. It's just a bitch of a system to build...

I have never forgotten that experience and I shudder every time I hear "Payroll" to this day... We all learned some good lessons but, for me,
the main one was "Use a Package for Payroll"...(And make the vendor demonstrate it can meet your requirements before handing cash over...)

Recent news about the current situation made me shudder, but then I
started to think about this question: If you were to write a payroll
system today what language would you use??

A really good question, Kerry, but I believe you are asking it at the
"wrong" time. The worst thing to do would be to select a language then
design your payroll to suit that language. Get a decent functional
analysis first (language independent) then decide what processes could
be interactive and what processes could best be batch processed.

(You might want online collection of hours worked, from mobile phones,
and calculation of salary and direct transfer to bank accounts run as
batches, for example.)

Certainly not C++ or Python

or ?

I don't think you can exclude any language or prefer any language for
this. It is likely to need scripting and programming in more than one language... But the thing to be focused on is the Functionality.
Interact with the users and get it agreed.

(Then buy a package that can demonstrate its ability to implement what
is required... :-))

Nevermind the folly of writing ones own payroll system (no idea

why they didn't just farm it out to any of a number of commercial
payroll processing firms - oh, right, THE GOVERNMENT has unique and insurmountable special requirements....hahahaha

Sure, it never ceases to amuse me when discussing the business with
senior people and middle managers, how they all believe that THEIR implementation of selling hamburgers or renting cars or writing
insurance policies or keeping bank accounts, is DIFFERENT and SPECIAL
from every one of their competitors... :-)

Of course there will be company-specific aspects of it that are very important, but their competitors have similar company specific things too.

I thought about COBOL and of course the discussions here. Then I thought about writing a payroll program in Java, then I decided to stop thinking
and find some single malt.

A right and proper conclusion, in my opinion... :-)

Cheers!

Pete.
--
I used to write COBOL; now I can do anything...

SEEN-BY: 154/30 2320/100 0 1 227/0