• Re: Some COBOL-related observations...

    From docdwarf@panix.com@21:1/5 to dashwood@enternet.co.nz on Sun Nov 14 01:07:31 2021
    In article <ivb3saFolqnU1@mid.individual.net>,
    pete dashwood <dashwood@enternet.co.nz> wrote:

    [snip]

    A recent browse of COBOL jobs showed that COBOL
    alone is not really enough to get you employed. There are still
    mainframe jobs and knowledge of that environment is good, but they will
    be much more interested if you have network knowledge as well.I saw ads
    for PHP, Java and COBOL, C# and COBOL, and Windows scripting that were
    marked as "desirable".

    Every so often I'll get an email from someone asking for The Usual
    Suspects (for an IBM shop that's five-to-seven years' of COBOL, VSAM,
    CICS, DB2, FileAid and the like). I have two 'kepboard macros' that I use
    to respond to such folks:

    1) 'Sounds interesting. What kind of rate are they offering?'

    ... and if a response comes - and they rarely do - the hourly rates
    offered are the same ones I used to see in 1985. This triggers the net keyboard macro:

    2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
    kind of rate are they offering almost forty years later?'

    DD

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pete dashwood@21:1/5 to All on Sun Nov 14 13:34:19 2021
    I am currently working on the PRIMA Web Site to make it reflect a change
    in direction of the business.
    (https://primacomputing.co.nz)

    We had a run of bad luck where our ISP died then, after I managed to get everything transferred to a new host, a short time after the site was
    settling down, that ISP sold out to a different one and that has meant a
    few trivial but annoying changes.

    I wrote the site originally in ASP.NET and it has proven to be excellent
    for web development. The later versions of Visual Studio allow me to
    develop pages with a design surface just like Win Forms or WPF and it is
    very easy to wire them to the C# code-behind that drives all the events,
    then FTP them to the server with Filezilla.
    Everything runs as compiled code on the server and it is much more
    secure than interpreting client side scripts.

    It allows me to retain a "hand-made" look and feel which may not be as
    slick as a templated WordPress site, but which makes us a little
    different from most of the sites out there.

    Anyway, recently I put the final touches and end-point processes into
    the PRIMA Tools. It has taken me 13 years... :-)

    The last processes for PowerCOBOL to Dot.NET are integrated and I am
    satisfied with the testing.

    The onset of Covid affected the demand for migration (or maybe our niche
    was closing anyway... I'll never know) so the Company has had to be run
    on its reserves to keep going.

    I decided that if we are to encourage any remaining people to move their standard COBOL from indexed files into RDB, or their PowerCOBOL GUI applications into .NET, it is counter-productive to sell them the tools
    and help them learn how to use them. Much quicker and cheaper for
    everybody, if we just do it for them.

    So I am moving PRIMA to be a service company where you have a shopping
    list of what you need and I am writing an online calculator that will
    give you a "ballpark quote" based on what you want done.

    This arose after there was a recent pricing enquiry here and the OP
    really didn't get that the price will vary depending on a number of
    factors and quantities. I gave him a fairly accurate ball-park but, in
    fact, it could have been less expensive if some other factors had been
    added in. Hence, an algorithm that will work like a calculator on the
    web page and give people a good idea of what THEIR specific cost is
    likely to be if they go with our solution.

    I've also taken a bit of time to reflect on the tool development and I
    have a few observations that might be of consideration to those of you developing applications in COBOL. The following is opinion, based on experience, so it is arguable:

    1. Go with a modular design.
    The overall design should have 3 tier design if it is for the Network. Presentation Layer, Business Logic Layer, and Database Access Layer.
    (Our tools generate all of the code for these layers, salvaging the
    COBOL Business Logic from your legacy, creating the DAL Layer and (for PowerCOBOL...) converting the Presentation layer to .NET Forms.
    Each of these functions will be on the new shopping list...

    If you are doing Batch Processing in COBOL and simply moving to a modern RDBMS, it is very tempting to integrate everything into
    monolithic application programs, then go through and simply change all
    the indexed IO to be Embedded SQL... My advice: DON'T DO IT! I've
    covered it here: https://primacomputing/PRIMAMetro/RDBandSQL3.aspx
    (Again, we can offer you a service where we analyze all your existing
    COPY books and design an optimized Relational Database, along with a DAL
    Layer to handle it (if required). We can also do the code conversion of
    your Legacy so that it uses the DAL Layer.

    BOTTOM LINE: Small is beautiful. Isolate functionality into components
    and use layered collections of these components. This has minimal
    disruption when it needs maintenance, and it is much quicker and easier
    to locate problem code.

    Objected Oriented Programming (in COBOL or any other OO language)
    facilitates this approach.

    2. Be careful with TABBED controls in your software.
    (There are a number of "COBOL PlugIns" that provide a GUI facility. We
    deal mostly with PowerCOBOL from Fujitsu.)

    It is very easy to let tabbed functionality get out of control. You design a new function; add a new TAB... all well and good but don't let
    it go too far...

    One of our tools has more than 10 TABs in it and some of these are for functionality that is no longer used. You'd think it would be pretty
    easy to simply cut out the unnecessary ones... I worked out it would
    take me 1 - 2 days to do this properly. Who has days available for "cosmetics"...? (as we are no longer selling the tools, I immediately
    picked up 1 - 2 days.... :-))

    3. I have been doing quite a bit of COBOL manipulation using Visual
    Studio Code. It has many of the advantages of VS (like Intellisense and Bookmarks...) and I think it does make COBOL coding easier. It's a free
    tool and it will deal with ANY Version of COBOL that is at least COBOL
    '85 compliant. (I should think it would be very good for GNU COBOL...,
    but I'm sure Eclipse is also good.)

    4. Back in the 1990s I suggested that COBOL people should expand their
    toolbox. Sadly, there was an attitude that "Everything I want to do, I
    can do in COBOL..." (I always thought it showed limited aspiration as to
    what you want to do...). A recent browse of COBOL jobs showed that COBOL
    alone is not really enough to get you employed. There are still
    mainframe jobs and knowledge of that environment is good, but they will
    be much more interested if you have network knowledge as well.I saw ads
    for PHP, Java and COBOL, C# and COBOL, and Windows scripting that were
    marked as "desirable".

    I would recommend that if you are still interested in expanding your
    skill set, take a look at Rust and JavaScript. I have only had limited
    exposure to Rust but it really impressed me. On my list for when I get
    time... :-)

    I'd be interested to hear what people are actually doing, in terms of
    COBOL, if there are still people writing COBOL every day.. Why not post
    a summarized response? And, of course, any comments on the opinions
    expressed above would be acknowledged and/or discussed.

    Cheers,

    Pete.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pete dashwood@21:1/5 to docdwarf@panix.com on Mon Nov 15 13:14:13 2021
    On 14/11/2021 14:07, docdwarf@panix.com wrote:
    In article <ivb3saFolqnU1@mid.individual.net>,
    pete dashwood <dashwood@enternet.co.nz> wrote:

    [snip]

    A recent browse of COBOL jobs showed that COBOL
    alone is not really enough to get you employed. There are still
    mainframe jobs and knowledge of that environment is good, but they will
    be much more interested if you have network knowledge as well.I saw ads
    for PHP, Java and COBOL, C# and COBOL, and Windows scripting that were
    marked as "desirable".

    Every so often I'll get an email from someone asking for The Usual
    Suspects (for an IBM shop that's five-to-seven years' of COBOL, VSAM,
    CICS, DB2, FileAid and the like). I have two 'kepboard macros' that I use
    to respond to such folks:

    1) 'Sounds interesting. What kind of rate are they offering?'

    ... and if a response comes - and they rarely do - the hourly rates
    offered are the same ones I used to see in 1985. This triggers the net keyboard macro:

    2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
    kind of rate are they offering almost forty years later?'

    DD


    Hi Doc,

    that is amazing (and pretty disappointing...).

    It seems that COBOL skill continues to be undervalued as it always was.

    Pete.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Hudson@21:1/5 to docdwarf@panix.com on Mon Nov 15 14:32:36 2021
    In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:

    2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
    kind of rate are they offering almost forty years later?'

    Presumably one warranted by the productivity of a programmer using the language.

    As the productivity (as measured by those paying for the production) of
    COBOL programming diminishes relative to the productivity of python / go /
    C# / whatever, the rates offered also languish. To improve rates for those skilled in a particular tool, improve the productivity of the programmers
    using the tool.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe@21:1/5 to Randy Hudson on Mon Nov 15 16:34:32 2021
    On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), ime@panix.com (Randy Hudson) wrote:

    In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:

    2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
    kind of rate are they offering almost forty years later?'

    Presumably one warranted by the productivity of a programmer using the >language.

    As the productivity (as measured by those paying for the production) of
    COBOL programming diminishes relative to the productivity of python / go /
    C# / whatever, the rates offered also languish. To improve rates for those >skilled in a particular tool, improve the productivity of the programmers >using the tool.

    Do you have anything to support this claim? Additionally, are you talking about modules or systems? Are you taking TCO into
    consideration?

    My experience differs depending on the requirement. There appears to be a tendency for developing MVP's, something a halfway decent
    Cobol developer doesn't consider to be a viable deliverable. MVP's are fine for throw-away systems, not for core bussiness
    applications. "The old stuff" or "legacy" is disguised by management and architects even though operationally it is cheap and has a
    low incidence rate. It's just not sexy.

    FYI: My scope encompasses many languages and technical platforms.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From docdwarf@panix.com@21:1/5 to Randy Hudson on Mon Nov 15 16:36:06 2021
    In article <smtr24$1en$1@reader1.panix.com>,
    Randy Hudson <ime@panix.com> wrote:
    In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:

    2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
    kind of rate are they offering almost forty years later?'

    Presumably one warranted by the productivity of a programmer using the >language.

    Hey, good joke! How does one measure the productivity of 'learning where
    to hit the machine'?

    As the productivity (as measured by those paying for the production) of
    COBOL programming diminishes relative to the productivity of python / go /
    C# / whatever, the rates offered also languish. To improve rates for those >skilled in a particular tool, improve the productivity of the programmers >using the tool.

    Decisions about COBOL and the platforms on which it runs are, nowadays,
    not made by considering productivity - in my experience, of course - but
    are instead made by someone hollering 'DO SOMETHING NOW!' when a
    meetingful of Corporate Equals explodes into that 'you still have a
    MAINFRAME?' laughter designed to shrivel one's sensitive regions as does sitting on a winter-chilled Albany bus-bench.

    DD

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Hudson@21:1/5 to none@nowhere.whereo on Mon Nov 15 17:25:56 2021
    In article <tf25pg5pt7mo2arhlpdvc914jjb708dh7d@4ax.com>,
    Joe <none@nowhere.whereo> wrote:

    On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), ime@panix.com (Randy Hudson) wrote:

    In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:

    2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what >>> kind of rate are they offering almost forty years later?'

    Presumably one warranted by the productivity of a programmer using the
    language.

    As the productivity (as measured by those paying for the production) of
    COBOL programming diminishes relative to the productivity of python / go / >> C# / whatever, the rates offered also languish. To improve rates for those >> skilled in a particular tool, improve the productivity of the programmers
    using the tool.

    Do you have anything to support this claim?

    The claim that rates track perceived productivity of the worker using the
    tools of his choice? No; it's probably just a fantasy, and rates are chosen
    by throwing 20-sided dice.

    Additionally, are you talking about modules or systems? Are you taking TCO into
    consideration?

    "as measured by those paying..."

    TCO is unknown at the time the rates are determined, though of course
    attempts are made to estimate it closely.

    My experience differs depending on the requirement. There appears to be a tendency for developing MVP's, something a halfway decent Cobol developer doesn't consider to be a viable deliverable. MVP's are fine for
    throw-away systems, not for core bussiness applications. "The old stuff"
    or "legacy" is disguised by management and architects even though operationally it is cheap and has a low incidence rate. It's just not
    sexy.

    End-user experience is easier for non-technical executives to themselves observe than "back-end" performance. That may lead to mispricing those deliverables, not because of sexiness, but because their effectiveness is easier to evaluate.

    FYI: My scope encompasses many languages and technical platforms.

    Probably more than mine; the last time I was paid for programming, I was writing in BAL.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe@21:1/5 to Randy Hudson on Tue Nov 16 16:50:42 2021
    On Mon, 15 Nov 2021 17:25:56 -0000 (UTC), ime@panix.com (Randy Hudson) wrote:

    In article <tf25pg5pt7mo2arhlpdvc914jjb708dh7d@4ax.com>,
    Joe <none@nowhere.whereo> wrote:
    FYI: My scope encompasses many languages and technical platforms.

    Probably more than mine; the last time I was paid for programming, I was >writing in BAL.

    Nice one ;-) Haven't done that for a while....

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pete dashwood@21:1/5 to Randy Hudson on Mon Nov 22 20:51:55 2021
    On 16/11/2021 03:32, Randy Hudson wrote:
    In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:

    2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
    kind of rate are they offering almost forty years later?'

    Presumably one warranted by the productivity of a programmer using the language.

    As the productivity (as measured by those paying for the production) of
    COBOL programming diminishes relative to the productivity of python / go /
    C# / whatever, the rates offered also languish. To improve rates for those skilled in a particular tool, improve the productivity of the programmers using the tool.

    That sounds reasonable and you make a fair point.

    For myself I am at least twice as productive in C# than I am in COBOL.

    This has nothing to do with the language, but rather with the fact that
    Visual Studio is MUCH more powerful than the Fujitsu IDEs for COBOL or PowerCOBOL.

    It is also undeniable that COBOL is more verbose than the other
    languages and requires more writing. (Especially if you want it to be maintainable...)

    I tried using Visual Studio Code (another free version of VS, that can
    support most dialects of COBOL), and it was definitely better. But I
    didn't do prolonged trials with it because I stopped using COBOL
    (almost) altogether and for the small amounts I do use it, the IDEs are acceptable.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pete dashwood@21:1/5 to Joe on Mon Nov 22 20:57:00 2021
    On 16/11/2021 05:34, Joe wrote:
    On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), ime@panix.com (Randy Hudson) wrote:

    In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:

    2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what >>> kind of rate are they offering almost forty years later?'

    Presumably one warranted by the productivity of a programmer using the
    language.

    As the productivity (as measured by those paying for the production) of
    COBOL programming diminishes relative to the productivity of python / go / >> C# / whatever, the rates offered also languish. To improve rates for those >> skilled in a particular tool, improve the productivity of the programmers
    using the tool.

    Do you have anything to support this claim? Additionally, are you talking about modules or systems? Are you taking TCO into
    consideration?

    My experience differs depending on the requirement. There appears to be a tendency for developing MVP's, something a halfway decent
    Cobol developer doesn't consider to be a viable deliverable. MVP's are fine for throw-away systems, not for core bussiness
    applications. "The old stuff" or "legacy" is disguised by management and architects even though operationally it is cheap and has a
    low incidence rate. It's just not sexy.

    FYI: My scope encompasses many languages and technical platforms.


    If you look at TCO, COBOL is way behind at the end of the field.

    COBOL Compilers continue to be exorbitant with mandatory updates and
    service chanrges also required.

    C#, VB.NET, RUST, Java, and Python are all FREE! And support is
    available with a mouse click from a a community of millions.

    Pete.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pete dashwood@21:1/5 to pete dashwood on Tue Nov 23 12:12:10 2021
    On 22/11/2021 20:57, pete dashwood wrote:
    On 16/11/2021 05:34, Joe wrote:
    On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), ime@panix.com (Randy Hudson)
    wrote:

    In article <smpngj$i2a$1@reader1.panix.com>,  <docdwarf@panix.com>
    wrote:

    2)  'Hey, good joke!  Seriously, I was billing that rate in 1985...
    what
    kind of rate are they offering almost forty years later?'

    Presumably one warranted by the productivity of a programmer using the
    language.

    As the productivity (as measured by those paying for the production) of
    COBOL programming diminishes relative to the productivity of python /
    go /
    C# / whatever, the rates offered also languish.  To improve rates for
    those
    skilled in a particular tool, improve the productivity of the
    programmers
    using the tool.

    Do you have anything to support this claim?  Additionally, are you
    talking about modules or systems?  Are you taking TCO into
    consideration?

    My experience differs depending on the requirement.  There appears to
    be a tendency for developing MVP's, something a halfway decent
    Cobol developer doesn't consider to be a viable deliverable.  MVP's
    are fine for throw-away systems, not for core bussiness
    applications.  "The old stuff" or "legacy" is disguised by management
    and architects even though operationally it is cheap and has a
    low incidence rate.  It's just not sexy.

    FYI: My scope encompasses many languages and technical platforms.


    If you look at TCO, COBOL is way behind at the end of the field.

    COBOL Compilers continue to be exorbitant with mandatory updates and
    service chanrges also required.

    C#, VB.NET, RUST, Java, and Python are all FREE! And support is
    available with a mouse click from a a community of millions.

    Pete.

    I just wanted to add something in response to:

    MVP's
    are fine for throw-away systems, not for core business
    applications. "The old stuff" or "legacy" is disguised by management
    and architects even though operationally it is cheap and has a
    low incidence rate. It's just not sexy.

    MVPs are NOT just for throwaway systems. They are the basis of an
    evolving system that is responsive to changing user needs. Typically,
    this will involve an Agile style of Project Management, where there are iterations of development against user established priorities. (When I
    do it, it is also timeboxed...)

    This is far removed from the traditional COBOL Waterfall development and
    that's why most COBOL people don't really understand it.

    The overall concept is that a system evolves from the bare minimum
    facilities into something that is very useful and forms a core business solution. And this is driven by 2 factors:

    1. Iteration.
    2. Interaction.

    The interaction ensures that end users are involved throughout the
    process, and it is THEIR priorities which are addressed.

    Progress is incremental and can be easily backed out if it is found to
    be flawed.

    If a system is completely designed and signed off before production of
    it starts, it will not be timely. Users will get what they signed off 9
    months ago... and you will hear the familiar delivery/acceptance phrase:
    "It's great, but could we just have this ONE small change..."

    With the MVP/Agile approach, instead of the IT Department resisting
    changes and waving sign-offs at users, change is embraced and
    implemented immediately. The attitude is different and users respond to it.

    The "old stuff" or "legacy" has never been "cheap", operationally or in
    any other way. The maintenance of existing systems has always been the
    most expensive cost for traditional COBOL systems. The procedural nature
    of the code (rather than encapsulated OO Classes) means there are knock
    on and downstream errors that require more expensive regression testing
    and investigation.

    Legacy code is not "unpopular" because it isn't "sexy"; it is unpopular
    because it is not responsive to the changing requirements of the
    marketplace, and costs users large amounts to get change.
    (This without even considering the emotional cost of having to go to IT,
    cap in hand, and beg for new functionality... then be told: "We are
    really busy right now... we'll look at it in 6 months...")

    Management don't care whether a programming language is "sexy" or not;
    that is something for programmers.

    The focus SHOULD be on delivering useful functionality to the users, not
    on what a programmer's career CV needs to have...

    Modern DevOps using things like MVP and Agile style procedures, deliver
    that, and the cost is way less than traditional mainframe procedural development.

    Pete.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)