• There is a future for COBOL

    From Gilberto Junior@1:2320/100 to comp.lang.cobol on Mon Apr 3 04:23:59 2017
    From Newsgroup: comp.lang.cobol

    Hello all,

    There is a future for COBOL ?

    How many COBOL language vendors are there today?

    Writing new COBOL programs using webservice, xml, sql db is good choice?

    What is everyone's option?

    Regards

    Gilberto Junior

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From docdwarf@1:2320/100 to comp.lang.cobol on Tue Apr 4 11:37:43 2017
    From Newsgroup: comp.lang.cobol


    [posted and emailed]

    In article <63b6c123-a02a-4957-ba25-1b7aee99d363@googlegroups.com>,
    Gilberto Junior <gilbertojunior0010@gmail.com> wrote:
    Hello all,

    There is a future for COBOL ?

    How many COBOL language vendors are there today?

    Please do your own homework.

    DD

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Rick Smith@1:2320/100 to comp.lang.cobol on Tue Apr 4 08:01:17 2017
    From Newsgroup: comp.lang.cobol

    On Monday, April 3, 2017 at 7:24:01 AM UTC-4, Gilberto Junior wrote:
    Hello all,

    There is a future for COBOL ?

    How many COBOL language vendors are there today?

    Writing new COBOL programs using webservice, xml, sql db is good choice?

    What is everyone's option?

    Regards

    Gilberto Junior
    "Grandpa COBOL ainrCOt goinrCO away any time soon"
    < http://federalnewsradio.com/tom-temin-commentary/2017/04/grandpa-cobol-aint-goin-away-any-time-soon/ >

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Vince Coen@1:2320/100 to Gilberto Junior on Tue Apr 4 23:48:38 2017
    From Newsgroup: comp.lang.cobol

    Hello Gilberto!

    Monday April 03 2017 12:23, Gilberto Junior wrote to All:

    Hello all,

    There is a future for COBOL ?

    How many COBOL language vendors are there today?

    Writing new COBOL programs using webservice, xml, sql db is good
    choice?

    What is everyone's option?

    More than a few and less that was.

    . but more than enough.


    Vince

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Richard@1:2320/100 to comp.lang.cobol on Thu Apr 6 15:41:22 2017
    From Newsgroup: comp.lang.cobol

    On Monday, April 3, 2017 at 11:24:01 PM UTC+12, Gilberto Junior wrote:

    How many COBOL language vendors are there today?

    The important point to note is that they are _vendors_. This means that COBOL is, in general, expensive to use or learn, and especially to deploy because of run-time costs.

    There is OpenCOBOL/GNUCOBOL which is free, but is of a 30 year old standard (1985) with extensions. Most other modern popular languages are available for free in the latest standards.

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Arnold Trembley@1:2320/100 to comp.lang.cobol on Fri Apr 7 01:18:23 2017
    From Newsgroup: comp.lang.cobol

    On 4/6/2017 5:41 PM, Richard wrote:
    On Monday, April 3, 2017 at 11:24:01 PM UTC+12, Gilberto Junior wrote:

    How many COBOL language vendors are there today?

    The important point to note is that they are _vendors_. This means that COBOL
    is, in general, expensive to use or learn, and especially to deploy because of run-time costs.

    There is OpenCOBOL/GNUCOBOL which is free, but is of a 30 year old standard
    (1985) with extensions. Most other modern popular languages are available for free in the latest standards.


    It's a little better than 1985 ANSI COBOL. From the FAQ: https://open-cobol.sourceforge.io/faq/index.html

    "GnuCOBOL 2.0 implements a more substantial portion of the COBOL 85
    Dialect, COBOL 2002 and a growing number of vendor extensions. Some
    proposed COBOL 2014 features have also been implemented."

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

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Bruce Axtens@1:2320/100 to comp.lang.cobol on Fri Apr 7 16:30:15 2017
    From Newsgroup: comp.lang.cobol

    Assuming human beings are still here in 50 years time, I expect COBOL
    also to be here.

    Bruce/bugmagnet

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Vince Coen@1:2320/100 to Richard on Fri Apr 7 15:00:31 2017
    From Newsgroup: comp.lang.cobol

    Hello Richard!

    Thursday April 06 2017 23:41, Richard wrote to All:

    On Monday, April 3, 2017 at 11:24:01 PM UTC+12, Gilberto Junior wrote:

    How many COBOL language vendors are there today?

    The important point to note is that they are _vendors_. This means
    that COBOL is, in general, expensive to use or learn, and especially
    to deploy because of run-time costs.

    There is OpenCOBOL/GNUCOBOL which is free, but is of a 30 year old
    standard (1985) with extensions. Most other modern popular languages
    are available for free in the latest standards.

    Not correct - as of v2.0 rc-3 and earlier it uses (like all vendors)
    various extentions as issued in 2014 from document :

    INCITS/ISO/IEC 1989:2014 [2014]

    and a fair few that are not in above doc.

    Updates | mods | Extra features, occur daily and the souces are available immediately.

    Now tell me what other compiler developer supplies sources (or binaries)
    that quick even remotely ?



    Vince

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Tue Apr 11 12:23:14 2017
    From Newsgroup: comp.lang.cobol

    On 8/04/2017 2:00 a.m., Vince Coen wrote:
    Hello Richard!

    Thursday April 06 2017 23:41, Richard wrote to All:

    > On Monday, April 3, 2017 at 11:24:01 PM UTC+12, Gilberto Junior wrote:

    >> How many COBOL language vendors are there today?

    > The important point to note is that they are _vendors_. This means
    > that COBOL is, in general, expensive to use or learn, and especially
    > to deploy because of run-time costs.

    > There is OpenCOBOL/GNUCOBOL which is free, but is of a 30 year old
    > standard (1985) with extensions. Most other modern popular languages
    > are available for free in the latest standards.

    Not correct - as of v2.0 rc-3 and earlier it uses (like all vendors)
    various extentions as issued in 2014 from document :

    INCITS/ISO/IEC 1989:2014 [2014]

    and a fair few that are not in above doc.

    Updates | mods | Extra features, occur daily and the souces are available immediately.

    Now tell me what other compiler developer supplies sources (or binaries)
    that quick even remotely ?



    Vince


    And you use these sources How, Vince?

    Have you moved into compiler maintenance in C for your hobby
    programming? :-)

    Seriously, GNU COBOL is an excellent project and I'd use it in a
    heartbeat if it supported OO COBOL and a COM interface.

    Pete.

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

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Tue Apr 11 12:45:13 2017
    From Newsgroup: comp.lang.cobol

    On 3/04/2017 11:23 p.m., Gilberto Junior wrote:
    Hello all,

    There is a future for COBOL ?

    How many COBOL language vendors are there today?

    Not as many as there once were... However, it is a Marketplace and the
    current players are spending and making large amounts of money in it.


    Writing new COBOL programs using webservice, xml, sql db is good choice?

    No, writing webservices in COBOL is NOT a good choice (especially if you
    are still using SOAP), XML in COBOL is painful compared to LINQ to XML, Embedded SQL in COBOL using ODBC (as is usual for Fujitsu, for example)
    is obsolete and an order of magnitude slower than LINQ to SQL (which
    doesn't need ODBC, although you CAN do it that way). Our tests showed
    that replacing ESQL with LINQ increased performance by up to 5 times.
    There's no contest.

    LINQ and C# are a FREE download; COBOL is.... NOT.


    What is everyone's option?

    My opinion is as expressed above. I have never regretted moving off
    COBOL as my main development language, (although I still enjoy coding in
    it when the need arises for clients). Attachment to it is usually
    emotional rather than logical. Sometimes people have no choice because
    of history, sometimes there is no obvious or easy migration path to help
    you move on, sometimes people are so resistant to change that they won't embrace the challenge of learning new techniques and languages.

    It would be a very brave (or foolish...) IT Director or CTO who would
    tie the Company's cyber future to COBOL.

    Pete.

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

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Richard@1:2320/100 to comp.lang.cobol on Mon Apr 10 20:59:07 2017
    From Newsgroup: comp.lang.cobol

    On Tuesday, April 11, 2017 at 12:45:19 PM UTC+12, pete dashwood wrote:
    No, writing webservices in COBOL is NOT a good choice (especially if you
    are still using SOAP), XML in COBOL is painful
    IBM came up with a scheme to process XML in COBOL using COBOL data structures. I disliked that idea but it may have made XML processing reasonably easy. Otherwise, reading XML in COBOL is just a matter of using a suitable module or library. Calling the module should result a data table of the names and values.
    Fortunately when I did need to read XML I had an open-source module that did this well enough and easily.
    Writing XML (or HTML, JSON, CSV, PDF, or just about anything else) should, in my opinion, be done using templates. In that way the program need not know, nor
    care, what the actual output looks like, that is the responsibility of the template. I have done this in COBOL, C, Python, and others. The program only needs to supply a set of data that includes the tag names and data values and call the templating module for the required sections.
    (granted my PDF writing in COBOL requires a 2 stage process).
    compared to LINQ to XML,
    What has been learned and often used to is always easier than something not done before.
    Embedded SQL in COBOL using ODBC (as is usual for Fujitsu, for example)
    is obsolete and an order of magnitude slower than LINQ to SQL (which
    doesn't need ODBC, although you CAN do it that way). Our tests showed
    that replacing ESQL with LINQ increased performance by up to 5 times.
    In my tests ODBC is always slower than directly accessing the database directly. The alleged advantage of ODBC is that it provides a common access to all manner of databases. The downside is that it is several layers of interpreting, rewriting, and reformatting. I am not surprised that you found it
    5 times slower.

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From bwtiffin@1:2320/100 to comp.lang.cobol on Tue Apr 11 02:32:20 2017
    From Newsgroup: comp.lang.cobol


    On Monday, April 10, 2017 at 8:45:19 PM UTC-4, pete dashwood wrote:
    LINQ and C# are a FREE download; COBOL is.... NOT.
    Hey, wait a minute. :-)
    You aren't allowed to say that anymore, Peter. Because, yes, COBOL *is* a FREE
    download. Not only cost free, but freedom free as well.
    Does GnuCOBOL currently integrate seamlessly in your (I'm going to say relatively narrow **) view of the computing world? Nope, not really.
    Does GnuCOBOL integrate with (I just counted the other day) 45 other programming languages, over a dozen large frameworks, and nearing one hundred libraries? Yes. Proven to, with FREE download sources, ready to be modified and put to use on the task at hand.
    **: explaining the relatively narrow view thing. Of the billions and billions of lines of COBOL running right now, how many are LINQ ready, or even care that
    they are or are not LINQ ready?
    COBOL has a a very strong position within certain domains of use. Stepping outside those domains, and you might as well use Python, or Perl, or Java or C#
    or (hundreds of language and environment choices). But do you really want the internals of the world commerce system running on Windows? Serious question.
    I find that GnuCOBOL offers a little bit of an in/out for COBOL usage. You can
    take existent COBOL and compile it on lots of different platforms with very little change, if the platform is the sore point. You can then directly link to the whizz bang trend of the minute for features that COBOL is not designed for. Or you can directly link the whizz bang trend of the moment into a rock solid, very well understood, core of COBOL transaction processing with decimal form penny wise accuracy.
    The future may be; Android based gorilla glass interfaces in front of users and
    console, text based, servers in the back room. Do you want COBOL on the gorilla glass? Not really. Do you want Windows or X11 on the core servers? Not really. In between is just the desktop, and all you may really need out of
    those in the near future is a terminal and something that can render graphics.
    Data entry systems that can ship code up to a server, either for processing or for distribution to the small glass screens. If that trend continues then I see Dalvik/Java and COBOL have a solid 50 year+ future, C# maybe/maybe not, unless it finds a place on the phone or on the frame/server farm.
    Of course my crystal ball is not very powerful, and for now there are very few choices that can't end in success to some extent in the short term. Computing is still that young, just about everything produced can be and is used.
    Due to the fragmentation. there will always be more people laughing or scoffing
    at the choices of others as not worthy than the people that understand that it is worthy, and use it productively. And that is simply because a lot of us have favourites and there are hundreds of favourites to choose from. Any given one view has ninety-nine competitors that will scoff, in a great huge rock-scissors-paper circle, with no single clear right answer.
    Point of example, Peter. I happen to think my Rock of COBOL beats your Scissors of C#. :-) But I'm guessing that we both realize that that is a pretty circular argument when you look at the game from above. We both beat the
    Paper of Perl, except, crap, the Perl just covered my Rock.
    Have good, make well,
    Brian

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From docdwarf@1:2320/100 to comp.lang.cobol on Tue Apr 11 11:43:37 2017
    From Newsgroup: comp.lang.cobol

    In article <5f4eb8f9-c00b-4461-afa8-03462695c83e@googlegroups.com>,
    <bwtiffin@gmail.com> wrote:


    On Monday, April 10, 2017 at 8:45:19 PM UTC-4, pete dashwood wrote:
    LINQ and C# are a FREE download; COBOL is.... NOT.

    Hey, wait a minute. :-)

    You aren't allowed to say that anymore, Peter. Because, yes, COBOL *is*
    a FREE download. Not only cost free, but freedom free as well.

    Mr Dashwood... wrong? How might such a thing be possible?

    DD

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Vince Coen@1:2320/100 to pete dashwood on Tue Apr 11 17:55:42 2017
    From Newsgroup: comp.lang.cobol

    <17a365bf-d33f-45ca-86b9-8b2f9efbda63@googlegroups.com> <1491573631@f1.n250.z2.fidonet.ftn> <el2lvkFos6uU1@mid.individual.net>
    Hello pete!

    Tuesday April 11 2017 01:23, pete dashwood wrote to All:

    And you use these sources How, Vince?

    Use them to build the current version on my systems takes all of 2 - 3
    minutes as fully automated these days.

    Have you moved into compiler maintenance in C for your hobby
    programming? :-)

    Not if I can avoid it but had to, for some MySQL interfaces.

    Seriously, GNU COBOL is an excellent project and I'd use it in a
    heartbeat if it supported OO COBOL and a COM interface.

    Coming soon, I believe the term is but I doubt this year as the source for
    it will be from GC v2.0 or 2.2 then from the C++ Branch of said versions.



    Vince

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Thu Apr 13 19:23:13 2017
    From Newsgroup: comp.lang.cobol

    On 11/04/2017 9:32 p.m., bwtiffin@gmail.com wrote:


    On Monday, April 10, 2017 at 8:45:19 PM UTC-4, pete dashwood wrote:
    LINQ and C# are a FREE download; COBOL is.... NOT.

    Hey, wait a minute. :-)

    You aren't allowed to say that anymore, Peter. Because, yes, COBOL *is* a
    FREE download. Not only cost free, but freedom free as well.

    Fair point :-)

    I'll qualify that statement to exclude GNU COBOL in the future.


    Does GnuCOBOL currently integrate seamlessly in your (I'm going to say
    relatively narrow **) view of the computing world? Nope, not really.

    Does GnuCOBOL integrate with (I just counted the other day) 45 other
    programming languages, over a dozen large frameworks, and nearing one hundred libraries? Yes. Proven to, with FREE download sources, ready to be modified and put to use on the task at hand.

    **: explaining the relatively narrow view thing. Of the billions and
    billions of lines of COBOL running right now, how many are LINQ ready, or even care that they are or are not LINQ ready?

    It's not fair to say my view and usage is "narrow" because your
    particular COBOL doesn't meet it, and I have never said that. I HAVE
    asked when it might support OO and COM. The claim that there are
    billions of lines of it running (which even Gartner actually withdrew)
    has nothing to do with whether it suits my purpose or not. Until people
    try something they can't really know whether it will suit them. I like
    LINQ. It is simple, consistent, and VERY useful for accessing and
    manipulating data. Until I tried it, I could not know that. And as long
    as I was tied to COBOL I would never get to try it.

    COBOL has a a very strong position within certain domains of use. Stepping
    outside those domains, and you might as well use Python, or Perl, or Java or C#
    or (hundreds of language and environment choices). But do you really want the internals of the world commerce system running on Windows? Serious question.

    An increasing proportion of the World's commerce IS running on Windows,
    so there is no question about it. My Bank moved to windows networking
    some years ago (from COBOL mainframe) and the services I get today are
    the best I have ever had. The core mainframes are increasingly being
    used only for "big data" analyses and the day to day working is being
    done on the network (with Windows).

    But I don't think it really matters. I don't personally care WHAT hardware/software the World's financial institutions use as long as I
    get the functionality I want.

    I find that GnuCOBOL offers a little bit of an in/out for COBOL usage. You
    can take existent COBOL and compile it on lots of different platforms with very
    little change, if the platform is the sore point. You can then directly link to the whizz bang trend of the minute for features that COBOL is not designed for. Or you can directly link the whizz bang trend of the moment into a rock solid, very well understood, core of COBOL transaction processing with decimal form penny wise accuracy.

    The future may be; Android based gorilla glass interfaces in front of users
    and console, text based, servers in the back room. Do you want COBOL on the gorilla glass? Not really. Do you want Windows or X11 on the core servers? Not really. In between is just the desktop, and all you may really need out of
    those in the near future is a terminal and something that can render graphics.
    Data entry systems that can ship code up to a server, either for processing or for distribution to the small glass screens. If that trend continues then I see Dalvik/Java and COBOL have a solid 50 year+ future, C# maybe/maybe not, unless it finds a place on the phone or on the frame/server farm.

    Time will tell.

    Of course my crystal ball is not very powerful, and for now there are very
    few choices that can't end in success to some extent in the short term. Computing is still that young, just about everything produced can be and is used.

    Due to the fragmentation. there will always be more people laughing or
    scoffing at the choices of others as not worthy than the people that understand
    that it is worthy, and use it productively.

    I don't laugh or scoff at anything people do with IT. I relay my own experience in the hope that it can be helpful and I am happy to discuss
    pros and cons and why I took the choices I did.


    And that is simply because a lot of us have favourites and there are hundreds of favourites to choose from. Any given one view has
    ninety-nine competitors that will scoff, in a great huge
    rock-scissors-paper circle, with no single clear right answer.

    An answer is "right" if it delivers what you want and need. What you
    want and need depends on vision and perception.




    Point of example, Peter. I happen to think my Rock of COBOL beats your
    Scissors of C#. :-) But I'm guessing that we both realize that that is a pretty circular argument when you look at the game from above.

    I see no point in that contest. I enjoy both languages but I'm more
    productive in C# and it empowers me to do things I can't easily do in COBOL.
    We both beat the Paper of Perl, except, crap, the Perl just covered my
    Rock.

    There are many useful IT tools and languages. It will be interesting to
    see the machines programming themselves and whether they will invent
    their own languages to do that...

    Cheers,

    Pete.

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

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From bwtiffin@1:2320/100 to comp.lang.cobol on Thu Apr 13 02:39:43 2017
    From Newsgroup: comp.lang.cobol

    On Thursday, April 13, 2017 at 3:23:20 AM UTC-4, pete dashwood wrote:
    On 11/04/2017 9:32 p.m., bwtif...@....com wrote:


    On Monday, April 10, 2017 at 8:45:19 PM UTC-4, pete dashwood wrote:
    LINQ and C# are a FREE download; COBOL is.... NOT.

    Hey, wait a minute. :-)

    You aren't allowed to say that anymore, Peter. Because, yes, COBOL *is* a
    FREE download. Not only cost free, but freedom free as well.

    Fair point :-)

    I'll qualify that statement to exclude GNU COBOL in the future.

    Add Raincode as well. Royalty free, free download. I'm pretty sure the compiler is Object COBOL ready for .NET as well. *But for that, I'm going on glancing at web pages, not experience or trials.*
    To the rest, I'm just going to keep calling Rock Scissors Paper. Any choice we
    make in the field is worthy, you will win some, lose some, tie some, depending at were you stand in the circle. And from the the right point of view, we probably aren't lying to people when we say any particular choice is win/win/tie. And another's opinion probably isn't lying when they call that same stance a lose/lose/tie.
    Confirmation bias is awesome. As it stands, my cognitive filters find it hard to believe that a bank is running Windows in the back room, but I'm willing to admit that there might be a reverse Halo effect (and other prejudice) at play setting the tone of that belief. Front facing? Sure. Back office? hrrmm, can't turn off the filters of suspicion.
    I'm also firmly in the camp that believes COBOL has a solid future and is worthy of consideration for new development, especially in certain domains of use.
    On three; 1, 2, ROCK. :-)
    Have good,
    Brian

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Sat Apr 15 12:38:17 2017
    From Newsgroup: comp.lang.cobol

    On 13/04/2017 9:39 p.m., bwtiffin@gmail.com wrote:
    On Thursday, April 13, 2017 at 3:23:20 AM UTC-4, pete dashwood wrote:
    On 11/04/2017 9:32 p.m., bwtif...@....com wrote:


    On Monday, April 10, 2017 at 8:45:19 PM UTC-4, pete dashwood wrote:
    LINQ and C# are a FREE download; COBOL is.... NOT.

    Hey, wait a minute. :-)

    You aren't allowed to say that anymore, Peter. Because, yes, COBOL *is* a FREE download. Not only cost free, but freedom free as well.

    Fair point :-)

    I'll qualify that statement to exclude GNU COBOL in the future.


    Add Raincode as well. Royalty free, free download. I'm pretty sure the
    compiler is Object COBOL ready for .NET as well. *But for that, I'm going on glancing at web pages, not experience or trials.*

    Never heard of Raincode...

    To the rest, I'm just going to keep calling Rock Scissors Paper. Any choice
    we make in the field is worthy, you will win some, lose some, tie some, depending at were you stand in the circle. And from the the right point of view, we probably aren't lying to people when we say any particular choice is win/win/tie. And another's opinion probably isn't lying when they call that same stance a lose/lose/tie.

    Confirmation bias is awesome. As it stands, my cognitive filters find it
    hard to believe that a bank is running Windows in the back room, but I'm willing to admit that there might be a reverse Halo effect (and other prejudice) at play setting the tone of that belief. Front facing? Sure. Back office? hrrmm, can't turn off the filters of suspicion.

    I think the important thing here is that "Back Office" is changing as a concept. With more and more devices accessing and updating account
    details in real time, it makes sense to use distributed network
    databases. There is no "Back Office" as the term was once understood,
    with delayed transactions applied by overnight batch processing. I'm not
    sure, but I imagine they still use mainframes for consolidating and
    analyzing the on-line databases (Big Data). One thing I have noticed is
    that now if I buy something with EFTPOS (which is what most people do
    here) my account reflects that transaction within minutes. In the "old
    days" it was 24 hours. I can download electronically all transactions on
    a given account for the past 4 years (longer if I pay for it), within
    seconds, and I can get all statements for the same period. Paper
    statements are not required and I haven't had one for several years
    now... (You CAN get them if you really want them, but it is pretty unnecessary; you can request a statement for any period and download it immediately (doesn't have to be monthly). There is much more, affecting
    other areas of Banking, but my point is that none of it was available
    until on-line Banking and phone banking, and we didn't have that with
    the centralized mainframes. There are very few COBOL sites remaining in
    New Zealand, even in the traditional areas like Banking and Insurance.
    The world is changing the way it does business and the Network is
    replacing the centralized systems.

    Sometimes, it saddens me that I am running a company connected with
    COBOL migration and there is no call for it in NZ; all of our client
    base is around the World.


    I'm also firmly in the camp that believes COBOL has a solid future and is
    worthy of consideration for new development, especially in certain domains of use.

    I'm not entirely outside that camp but I believe that the number of
    those domains is decreasing as other options become available. It isn't
    that you CAN'T do things in COBOL; it is just that it is more ponderous
    than other options which have better infrastructure and support
    libraries, and require much less writing.

    On three; 1, 2, ROCK. :-)

    Have good,
    Brian



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

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From docdwarf@1:2320/100 to comp.lang.cobol on Sat Apr 15 13:32:54 2017
    From Newsgroup: comp.lang.cobol

    In article <eld8btFqtolU1@mid.individual.net>,
    pete dashwood <dashwood@enternet.co.nz> wrote:

    [snip]

    There is no "Back Office" as the term was once understood,
    with delayed transactions applied by overnight batch processing.

    Mr Dashwood, you've made this assertion before and you've ignored the
    examples of National Tax Systems, State Tax Systems, Retirement Benefits Systems, Insurance Claim Systems and sundry other multi-billion-US$
    systems which prove this assertion to be wrong.

    I'm not
    sure, but I imagine they still use mainframes for consolidating and >analyzing the on-line databases (Big Data).

    'There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy.' - some Auld Blighty blighter.

    DD

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From ck@1:2320/100 to comp.lang.cobol on Sun Apr 16 15:11:13 2017
    From Newsgroup: comp.lang.cobol

    On 04/04/2017 16:01, Rick Smith wrote:
    On Monday, April 3, 2017 at 7:24:01 AM UTC-4, Gilberto Junior wrote:
    Hello all,

    There is a future for COBOL ?

    How many COBOL language vendors are there today?

    Writing new COBOL programs using webservice, xml, sql db is good choice?

    What is everyone's option?

    Regards

    Gilberto Junior

    "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?


    < http://federalnewsradio.com/tom-temin-commentary/2017/04/grandpa-cobol-aint-goin-away-any-time-soon/ >


    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Rick Smith@1:2320/100 to comp.lang.cobol on Mon Apr 17 16:58:25 2017
    From Newsgroup: comp.lang.cobol

    On Sunday, April 16, 2017 at 10:11:07 AM UTC-4, ck wrote:
    On 04/04/2017 16:01, Rick Smith wrote:
    [snip]
    "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?

    < http://federalnewsradio.com/tom-temin-commentary/2017/04/grandpa-cobol-aint-goin-away-any-time-soon/ >
    The choice of words was made by Tim Temin. While I don't know his
    intent in using 'Grandpa', it seems to me that it was more in the
    sense of two generations removed from the present. He used 'grandfather'
    in another article on COBOL. "I canrCOt find the obituary for COBOL".
    < http://federalnewsradio.com/tom-temin-commentary/2015/11/cant-find-obituary-cobol/ >
    Quotes: -----
    "The common business-oriented language (COBOL) debuted in 1959. Like
    the B-52, the programming language has evolved a lot during its many iterations. Experts have been complaining about it almost since its
    inception, but COBOL programs persist."
    "When you hear, as we do every filing season, that the IRS runs
    'systems from the Kennedy administration,' critics are trying to say,
    although they donrCOt know it, that the original logic written in some
    early version of COBOL is still running. The hardware, of course, has
    been replaced multiple times and IrCOd guess the code has been refreshed.
    IRS programmers rework it every year because the tax laws change."
    "In the meantime, while itrCOs true current pilots might be flying the
    same planes their grandfathers flew, theyrCOre not using the same
    avionics or electronic warfare systems."
    "The government relies on some old stuff, like the B-52 and COBOL applications." [Caption under image of B-52.]
    -----
    If "two generations removed" was the intent and understood, then
    using "Grandma" would have been fine. Unfortunately, grandpa and
    grandma could be inferred to mean 'old man COBOL' or 'old woman
    COBOL' and, to some, 'old woman COBOL' might be construed jocularly!
    I would have preferred that Mr Temin not have used 'Grandpa' and
    trust that GMH would have agreed.

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Sun Apr 23 13:14:15 2017
    From Newsgroup: comp.lang.cobol

    On 16/04/2017 1:32 a.m., docdwarf@panix.com wrote:
    In article <eld8btFqtolU1@mid.individual.net>,
    pete dashwood <dashwood@enternet.co.nz> wrote:

    [snip]

    There is no "Back Office" as the term was once understood,
    with delayed transactions applied by overnight batch processing.

    Mr Dashwood, you've made this assertion before and you've ignored the examples of National Tax Systems, State Tax Systems, Retirement Benefits Systems, Insurance Claim Systems and sundry other multi-billion-US$
    systems which prove this assertion to be wrong.

    I'm not
    sure, but I imagine they still use mainframes for consolidating and
    analyzing the on-line databases (Big Data).

    'There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy.' - some Auld Blighty blighter.

    DD

    Probably because I don't live in the United States.

    I have never claimed that there are not still large mainframe based
    systems running archaic code with archaic processes. However, most of
    them are based in the USA. There are good reasons for this; it is much
    harder to evolve your systems when you are dealing with hundreds of
    millions of clients (like the systems you note) than it is when you are not.

    The fact that these systems are alive and well, however, does NOT "prove
    my assertion to be wrong". They are not the class of systems I was
    discussing.

    There was a time, when EVERYBODY ran their businesses with such systems.
    My point is that that time is gone.

    In 1969, in Auckland NZ there were around 50 IBM mainframes running
    mostly COBOL. Today there are less than 3 (my estimate - IBM are
    reticent on the figures and the job search sites show NOTHING for
    COBOL.) NZ doesn't appear to use it any more. Why not? Because, with a population of 4 million, we don't HAVE to... Even the core "heavy
    lifting" systems like banking and insurance are migrating (or have
    already migrated) away from it. Commerce outside this core has either
    migrated to the network or replaced the previous systems with packages
    that can run on the network. The same trend is apparent across the
    World. (Maybe not in the USA...)

    In Europe during the time I worked there (around 25 years) I SAW people
    moving to networked processing, almost from the time PCs were introduced (early 1980s), although there was strong resistance at first. (I worked
    in the U.K., Spain, and Germany.)

    What were the "early adopters" and the "cutting edge" are now considered
    to be the "norm"...

    So, let's drop this tedious argument and "take it as read" than when I
    discuss these things I am NOT referring to the IRD in the USA, I am
    referring to "normal" commercial businesses.

    And there are many things in MY philosophy that neither you nor Hamlet
    nor Horatio could dream of.

    Cheers,

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

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Sun Apr 23 13:20:27 2017
    From Newsgroup: comp.lang.cobol

    On 18/04/2017 11:58 a.m., Rick Smith wrote:
    On Sunday, April 16, 2017 at 10:11:07 AM UTC-4, ck wrote:
    On 04/04/2017 16:01, Rick Smith wrote:

    [snip]

    "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?

    < http://federalnewsradio.com/tom-temin-commentary/2017/04/grandpa-cobol-aint-goin-away-any-time-soon/ >

    The choice of words was made by Tim Temin. While I don't know his
    intent in using 'Grandpa', it seems to me that it was more in the
    sense of two generations removed from the present. He used 'grandfather'
    in another article on COBOL. "I canrCOt find the obituary for COBOL".
    < http://federalnewsradio.com/tom-temin-commentary/2015/11/cant-find-obituary-cobol/ >

    Quotes: -----
    "The common business-oriented language (COBOL) debuted in 1959. Like
    the B-52, the programming language has evolved a lot during its many iterations. Experts have been complaining about it almost since its inception, but COBOL programs persist."

    "When you hear, as we do every filing season, that the IRS runs
    'systems from the Kennedy administration,' critics are trying to say, although they donrCOt know it, that the original logic written in some
    early version of COBOL is still running. The hardware, of course, has
    been replaced multiple times and IrCOd guess the code has been refreshed.
    IRS programmers rework it every year because the tax laws change."

    "In the meantime, while itrCOs true current pilots might be flying the
    same planes their grandfathers flew, theyrCOre not using the same
    avionics or electronic warfare systems."

    "The government relies on some old stuff, like the B-52 and COBOL applications." [Caption under image of B-52.]
    -----

    If "two generations removed" was the intent and understood, then
    using "Grandma" would have been fine. Unfortunately, grandpa and
    grandma could be inferred to mean 'old man COBOL' or 'old woman
    COBOL' and, to some, 'old woman COBOL' might be construed jocularly!

    I would have preferred that Mr Temin not have used 'Grandpa' and
    trust that GMH would have agreed.

    I like "Grandpa COBOL". It conjures an image of a feisty tough ol' coot sittin' on the porch in his long johns, chawin' his chewin' baccy and
    taking potshots at the vermin.

    I also think the quoted article is pretty fair in describing the US
    Government situation.

    You are right that COBOL should not be associated with "Old Women"...

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

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From bwtiffin@1:2320/100 to comp.lang.cobol on Sun Apr 23 18:25:22 2017
    From Newsgroup: comp.lang.cobol


    "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?

    You are right that COBOL should not be associated with "Old Women"...

    As the group manager of the Grace Hopper Appreciation Society on LinkedIn, I'd just like to remind everyone what ck was getting at.
    When she retired in 1986, she was, at the time, the oldest active service member in the U.S. Navy, being 80; so yeah, I think it's more than ok that COBOL is associated with Old Women. :-)
    Cheers,
    Brian

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Rick Smith@1:2320/100 to comp.lang.cobol on Sun Apr 23 21:00:40 2017
    From Newsgroup: comp.lang.cobol

    On Sunday, April 23, 2017 at 9:25:23 PM UTC-4, bwti...@gmail.com wrote:
    "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?

    You are right that COBOL should not be associated with "Old Women"...


    As the group manager of the Grace Hopper Appreciation Society on
    LinkedIn, I'd just like to remind everyone what ck was getting at.
    I think what ck was getting at is that Grace Hopper is known as the "Grandmother of COBOL". Calling it "Grandma COBOL" would honor her.
    It was about (grand) parentage.
    When she retired in 1986, she was, at the time, the oldest active
    service member in the U.S. Navy, being 80; so yeah, I think it's more
    than ok that COBOL is associated with Old Women. :-)
    All of which is irrelevant! My comment (elided) and Pete's agreement
    with that comment was about the connotation of the term "old woman".
    Here's a definition from < http://www.dictionary.com/browse/old-woman >.
    "2. a timid, fussy, or cautious person." This has nothing to do with
    (grand) parentage and a lot to do with perception.
    Would you want COBOL associated with "timid, fussy, or cautious"
    (or worse)?

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Gary Scott@1:2320/100 to comp.lang.cobol on Mon Apr 24 08:16:58 2017
    From Newsgroup: comp.lang.cobol

    On 4/23/2017 11:00 PM, Rick Smith wrote:
    On Sunday, April 23, 2017 at 9:25:23 PM UTC-4, bwti...@gmail.com wrote:
    "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?

    You are right that COBOL should not be associated with "Old Women"...


    As the group manager of the Grace Hopper Appreciation Society on
    LinkedIn, I'd just like to remind everyone what ck was getting at.

    I think what ck was getting at is that Grace Hopper is known as the "Grandmother of COBOL". Calling it "Grandma COBOL" would honor her.
    It was about (grand) parentage.

    When she retired in 1986, she was, at the time, the oldest active
    service member in the U.S. Navy, being 80; so yeah, I think it's more
    than ok that COBOL is associated with Old Women. :-)

    All of which is irrelevant! My comment (elided) and Pete's agreement
    with that comment was about the connotation of the term "old woman".
    Here's a definition from < http://www.dictionary.com/browse/old-woman >.
    "2. a timid, fussy, or cautious person." This has nothing to do with
    (grand) parentage and a lot to do with perception.

    Would you want COBOL associated with "timid, fussy, or cautious"
    (or worse)?

    https://en.wikipedia.org/wiki/Fauja_Singh

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From Rick Smith@1:2320/100 to comp.lang.cobol on Mon Apr 24 09:07:10 2017
    From Newsgroup: comp.lang.cobol

    On Monday, April 24, 2017 at 9:17:00 AM UTC-4, Gary Scott wrote:
    On 4/23/2017 11:00 PM, Rick Smith wrote:
    On Sunday, April 23, 2017 at 9:25:23 PM UTC-4, bwti...@gmail.com wrote:
    "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?

    You are right that COBOL should not be associated with "Old Women"...


    As the group manager of the Grace Hopper Appreciation Society on
    LinkedIn, I'd just like to remind everyone what ck was getting at.

    I think what ck was getting at is that Grace Hopper is known as the "Grandmother of COBOL". Calling it "Grandma COBOL" would honor her.
    It was about (grand) parentage.

    When she retired in 1986, she was, at the time, the oldest active
    service member in the U.S. Navy, being 80; so yeah, I think it's more
    than ok that COBOL is associated with Old Women. :-)

    All of which is irrelevant! My comment (elided) and Pete's agreement
    with that comment was about the connotation of the term "old woman".
    Here's a definition from < http://www.dictionary.com/browse/old-woman >. "2. a timid, fussy, or cautious person." This has nothing to do with (grand) parentage and a lot to do with perception.

    Would you want COBOL associated with "timid, fussy, or cautious"
    (or worse)?

    https://en.wikipedia.org/wiki/Fauja_Singh
    https://en.wikipedia.org/wiki/Grandma_Moses

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From docdwarf@1:2320/100 to comp.lang.cobol on Tue Apr 25 12:14:50 2017
    From Newsgroup: comp.lang.cobol

    In article <em2dfaFubt9U1@mid.individual.net>,
    pete dashwood <dashwood@enternet.co.nz> wrote:
    On 16/04/2017 1:32 a.m., docdwarf@panix.com wrote:
    In article <eld8btFqtolU1@mid.individual.net>,
    pete dashwood <dashwood@enternet.co.nz> wrote:

    [snip]

    There is no "Back Office" as the term was once understood,
    with delayed transactions applied by overnight batch processing.

    Mr Dashwood, you've made this assertion before and you've ignored the
    examples of National Tax Systems, State Tax Systems, Retirement Benefits
    Systems, Insurance Claim Systems and sundry other multi-billion-US$
    systems which prove this assertion to be wrong.

    I'm not
    sure, but I imagine they still use mainframes for consolidating and
    analyzing the on-line databases (Big Data).

    'There are more things in heaven and earth, Horatio, than are dreamt of in >> your philosophy.' - some Auld Blighty blighter.

    Probably because I don't live in the United States.

    I have never claimed that there are not still large mainframe based
    systems running archaic code with archaic processes. However, most of
    them are based in the USA. There are good reasons for this; it is much >harder to evolve your systems when you are dealing with hundreds of
    millions of clients (like the systems you note) than it is when you are not.

    The fact that these systems are alive and well, however, does NOT "prove
    my assertion to be wrong". They are not the class of systems I was >discussing.

    Your assertion as quoted above is 'There is no "Back Office" as the
    term was once understood, with delayed transactions applied by overnight
    batch processing.'

    When the flat wrongness of this is pointed out you reply 'The fact that
    these systems are alive and well, however, doe NOT "prove my assertion to
    be wrong."

    That which does-not-exist can be alive-and-well in the same way as a dead
    man can bleed.

    DD

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Fri Apr 28 18:49:45 2017
    From Newsgroup: comp.lang.cobol

    On 24/04/17 1:25 PM, bwtiffin@gmail.com wrote:

    "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?

    You are right that COBOL should not be associated with "Old Women"...


    As the group manager of the Grace Hopper Appreciation Society on LinkedIn,
    I'd just like to remind everyone what ck was getting at.

    When she retired in 1986, she was, at the time, the oldest active service
    member in the U.S. Navy, being 80; so yeah, I think it's more than ok that COBOL is associated with Old Women. :-)

    Cheers,
    Brian

    I'm smiling.

    At the time I wrote the above I thought: "I bet someone will mention
    Grace Hopper...", and was going to qualify the statement to exclude
    her... :-)

    Never mind; she earned her place...

    Pete.

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

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Fri Apr 28 18:54:37 2017
    From Newsgroup: comp.lang.cobol

    On 25/04/17 1:16 AM, Gary Scott wrote:
    On 4/23/2017 11:00 PM, Rick Smith wrote:
    On Sunday, April 23, 2017 at 9:25:23 PM UTC-4, bwti...@gmail.com wrote: >>>>>>> "Grandpa COBOL ainrCOt goinrCO away any time soon"

    Don't you mean Grandma?

    You are right that COBOL should not be associated with "Old Women"...


    As the group manager of the Grace Hopper Appreciation Society on
    LinkedIn, I'd just like to remind everyone what ck was getting at.

    I think what ck was getting at is that Grace Hopper is known as the
    "Grandmother of COBOL". Calling it "Grandma COBOL" would honor her.
    It was about (grand) parentage.

    When she retired in 1986, she was, at the time, the oldest active
    service member in the U.S. Navy, being 80; so yeah, I think it's more
    than ok that COBOL is associated with Old Women. :-)

    All of which is irrelevant! My comment (elided) and Pete's agreement
    with that comment was about the connotation of the term "old woman".
    Here's a definition from < http://www.dictionary.com/browse/old-woman >.
    "2. a timid, fussy, or cautious person." This has nothing to do with
    (grand) parentage and a lot to do with perception.

    Would you want COBOL associated with "timid, fussy, or cautious"
    (or worse)?

    https://en.wikipedia.org/wiki/Fauja_Singh


    Have to admit, I fell for this one. A total non sequitur, but it was interesting nonetheless. I don't quite understand why someone witnessing personal tragedy in their life is then prompted to become a marathon
    runner, but I may be lacking imagination and we all deal with grief in different ways.

    Pete.

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

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