• Where I stand on COBOL

    From pete dashwood@1:2320/100 to comp.lang.cobol on Mon Nov 27 13:27:17 2017
    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 Arnold Trembley@1:2320/100 to comp.lang.cobol on Sun Nov 26 22:34:14 2017
    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 Kerry Liles@1:2320/100 to comp.lang.cobol on Mon Nov 27 09:58:04 2017
    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 pete dashwood@1:2320/100 to comp.lang.cobol on Tue Nov 28 10:27:24 2017
    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