On 2/17/22 14:50, Simon Clubley wrote:
> On 2022-02-17, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>
>> You mean all those people running zSystems with COBOL, DB2 and CICS
>> that actually make up the largest majority of the money makers in the
>> world? The ones who have been told for at least 4 decades that the
>> mainframe is dead. Oh yeah, and so is COBOL. But then, didn't Byte
>> predict the death of Unix back in September 1992. :-)
>>
>
> Even IBM mainframes have moved on (big time!!!). They don't just run
> COBOL these days.
>

They never ran "just COBOL". Ignoring my IBM 1401 days :-)
when I was doing IBM VM370 I did COBOL, Fortran, PL/I, BASIC
and BAL. As far as I know, the same is true today except you
can add REXX, Python, Java, Javascript, Perl, PHP and god only
knows what else. Maybe I'll find out before I finish the IBM
Education Program, formerly known as "Mastering the Mainframe".
A program apparently aligned with about 3500 schools so far.

bill

On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
> On 2/17/22 14:17, Arne Vajhøj wrote:
>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>> I'd like to know just who and what the "industry" Arne refers to is?
>>> It's always easy to use some nebulous term.  But just what is it?
>>> Perhaps it is a "transfer", as in "transfer your money to us"?
>>
>> It is all those companies using IT. And the decisions they make.
>
> You mean all those people running zSystems with COBOL, DB2 and CICS
> that actually make up the largest majority of the money makers in the
> world?  The ones who have been told for at least 4 decades that the
> mainframe is dead.  Oh yeah, and so is COBOL.

The IT industry also include those.

But in the big picture they are a tiny part of the IT industry. And
not only a tiny part but also a shrinking part.

Arne

In article <j77mkgFl71aU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>You mean all those people running zSystems with COBOL, DB2 and CICS
>that actually make up the largest majority of the money makers in the
>world? The ones who have been told for at least 4 decades that the
>mainframe is dead. Oh yeah, and so is COBOL. But then, didn't Byte
>predict the death of Unix back in September 1992. :-)

Oh boy. COBOL is being discussed; better put on my
asbestos undies.

But everything you said is true: there's a ton of COBOL,
DB2, CICS, etc, out there, much that runs on mainframes.
Something like 80% of the world's credit transactions
hit some COBOL somewhere at some point.

But two things to consider: COBOL on IBM mainframes has
gone from being, in some sense, the median programmer
experience to being a tiny fraction of that experience.
While there may be more mainframes than ever, there's
more compute than ever in total, and as a percentage of
that total, the mainframe asymptotically crawls to zero.
We're never going to see, "Mainframe dead! News at 11!"
in our lifetimes, but so what?

Nevermind considerations of COBOL as a language; those
aren't terribly relevant. What IS relevant are COBOL
programmers, and the number of them again shrinks as a
percentage of the total. Now, in some ways that means
that the remaining COBOL hounds can command their own
paychecks, and that's great for them, but I seriously
want to know: of the N millions of lines of COBOL code
created annually, how many of those are copy-pasted
sequences for existing programs, slightly modified
with new behavior, because without semantically aware
editing tools it's very difficult to understand what
procedures are called from where (lookin' at you, 'THRU'
modifiers on 'PERFORM' statments), especially in large
codebases?

Those systems are there because they work and because
it is economically prohibitive to move off of them.
But I see the changing landscape, particularly the lack
of new COBOL programmers being produced as time goes
on, as a serious risk.

- Dan C.

On 2/17/2022 2:17 PM, Arne Vajhøj wrote:
> On 2/17/2022 1:59 PM, Dave Froble wrote:
>> On 2/17/2022 11:01 AM, Arne Vajhøj wrote:
>>> On 2/17/2022 9:42 AM, Bill Gunshannon wrote:
>>>> On 2/17/22 09:21, Arne Vajhøj wrote:
>>>>> On 2/16/2022 9:41 PM, dthi...@gmail.com wrote:
>>>>>>> On Tuesday, February 15, 2022 at 8:05:01 AM UTC-5, Bill Gunshannon
>>>>>>> wrote: National Computing Group West Mifflin, PA
>>>>>>>
>>>>>>> Document, plan and execute the modernization of Fortran
>>>>>>> applications running on OpenVMS systems to a virtualized Windows
>>>>>>> Server environment.
>>>>>>
>>>>>> I'd like to point out to everyone that this posting specifically
>>>>>> calls out modernizing FORTRAN, which CANNOT be done on OpenVMS, as
>>>>>> the OpenVMS FORTRAN compiler is over 25 years old. The commercial and
>>>>>> scientific FORTRAN code base out there is massive, as is the
>>>>>> commercial COBOL code base. I am aware of many companies modernizing
>>>>>> their FORTRAN code bases to use the new object oriented methods of
>>>>>> the later FORTRAN standards, which can be compiled with the Intel
>>>>>> Fortran compiler and the later gfortran compilers.
>>>>>
>>>>> It talks about "modernization of Fortran applications", which can really
>>>>> be move Fortran code as it to newer platform, upgrade from old Fortran
>>>>> to newer Fortran or rewrite from Fortran to newer language.
>>>>
>>>> This is one of the problems with the term "modernization".
>>>> To some it means use modern capabilities of the original
>>>> language that increase the efficiency and readability of
>>>> a program while to others it means scrap the old program
>>>> and re-write it in the language du jour. The second option
>>>> seldom being necessary or of any added value,
>>>
>>> The industry seems to think otherwise since it is happening
>>> a lot.
>>>
>>>>>> I've complained to both HPE and VSI for years that you can't attract
>>>>>> new developers to the platform, and thus grow your customer base, if
>>>>>> you don't provide modern software development tools and tool chains.
>>>>>
>>>>> Yes.
>>>>>
>>>>> Existing customers need compatibility.
>>>>>
>>>>> New customers needs modern languages, tools, libraries, frameworks
>>>>> etc. that tyhe industry expect today.
>>>>
>>>> Even if the so called "modern languages" actually bring no added
>>>> value to the table?
>>>
>>> The industry thinks they do.
>
>> What I rarely see is practical considerations.
>>
>> Joe wiz kid comes along and tells his employer how they must "upgrade" to
>> modern standards. But, Joe wiz kid isn't going to pay for the effort. That
>> is left to the employer, who just might be rather happy with the fully
>> functional and working current solutions.
>
> If the CTO/CIO is worth his/her salary then the pro's and con's
> of a migration will be analyzed before a decision is made.

1) Is the CIO worth his/her salary?
2) Does the CIO feel he/she must appear to be doing something to justify that
salary?
3) Does the CIO listen to "the industry" because he/she really isn't worth that
salary?
4) Does the CIO place the employers interests above personal (the resume) interests?

> Sometimes the decision is to migrate. Sometimes the decision is
> not to migrate.
>
> Not to migrate is probably the most common.

If it ain't broke, don't fix it.

How many times do things get "fixed" anyway?

> But the question comes up again and again. If the question comes
> up every 3 years and it is 20% migrate 80% keep, then after 24
> years 87% has migrated.

Statistics doesn't work that way. It is not cumulative. If the ratio is 20/80,
then every time it's 20/80.

>> I'd like to know just who and what the "industry" Arne refers to is? It's
>> always easy to use some nebulous term. But just what is it? Perhaps it is a
>> "transfer", as in "transfer your money to us"?
>
> It is all those companies using IT. And the decisions they make.

With many times no bearing on the worth of the decision.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>> I'd like to know just who and what the "industry" Arne refers to is? It's
>>>> always easy to use some nebulous term. But just what is it? Perhaps it is a
>>>> "transfer", as in "transfer your money to us"?
>>>
>>> It is all those companies using IT. And the decisions they make.
>>
>> You mean all those people running zSystems with COBOL, DB2 and CICS
>> that actually make up the largest majority of the money makers in the
>> world? The ones who have been told for at least 4 decades that the
>> mainframe is dead. Oh yeah, and so is COBOL.
>
> The IT industry also include those.
>
> But in the big picture they are a tiny part of the IT industry. And
> not only a tiny part but also a shrinking part.
>
> Arne
>

Arne, when you offer an opinion, please identify it as "opinion".

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2/17/2022 3:28 PM, Dan Cross wrote:
> In article <j77mkgFl71aU1@mid.individual.net>,
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> You mean all those people running zSystems with COBOL, DB2 and CICS
>> that actually make up the largest majority of the money makers in the
>> world? The ones who have been told for at least 4 decades that the
>> mainframe is dead. Oh yeah, and so is COBOL. But then, didn't Byte
>> predict the death of Unix back in September 1992. :-)
>
> Oh boy. COBOL is being discussed; better put on my
> asbestos undies.
>
> But everything you said is true: there's a ton of COBOL,
> DB2, CICS, etc, out there, much that runs on mainframes.
> Something like 80% of the world's credit transactions
> hit some COBOL somewhere at some point.
>
> But two things to consider: COBOL on IBM mainframes has
> gone from being, in some sense, the median programmer
> experience to being a tiny fraction of that experience.
> While there may be more mainframes than ever, there's
> more compute than ever in total, and as a percentage of
> that total, the mainframe asymptotically crawls to zero.
> We're never going to see, "Mainframe dead! News at 11!"
> in our lifetimes, but so what?
>
> Nevermind considerations of COBOL as a language; those
> aren't terribly relevant. What IS relevant are COBOL
> programmers, and the number of them again shrinks as a
> percentage of the total. Now, in some ways that means
> that the remaining COBOL hounds can command their own
> paychecks, and that's great for them, but I seriously
> want to know: of the N millions of lines of COBOL code
> created annually, how many of those are copy-pasted
> sequences for existing programs, slightly modified
> with new behavior, because without semantically aware
> editing tools it's very difficult to understand what
> procedures are called from where (lookin' at you, 'THRU'
> modifiers on 'PERFORM' statments), especially in large
> codebases?
>
> Those systems are there because they work and because
> it is economically prohibitive to move off of them.
> But I see the changing landscape, particularly the lack
> of new COBOL programmers being produced as time goes
> on, as a serious risk.
>
> - Dan C.
>

Where do astronauts come from?

WE TRAIN THEM FOR THE JOB!

And that is true for just about anything on the planet. Yes, we train for
required jobs. But the Cobol (and Basic,Fortran, (hock, spit, gag) C, and
others will define the needs, based upon the entities with those needs.

I have my doubts about the training defining the needs.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

some mainframe COBOL is moving to java (translators) but the primary reason is not to be in Java - the reason is more $$ based. the new mainframes offer intel co processors which do NOT charge by the MIP. the standard IBM mainframe processor still is "pay as you go".

On Thursday, February 17, 2022 at 3:39:55 PM UTC-6, Dave Froble wrote:
> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
> > On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
> >> On 2/17/22 14:17, Arne Vajhøj wrote:
> >>> On 2/17/2022 1:59 PM, Dave Froble wrote:
> >>>> I'd like to know just who and what the "industry" Arne refers to is? It's
> >>>> always easy to use some nebulous term. But just what is it? Perhaps it is a
> >>>> "transfer", as in "transfer your money to us"?
> >>>
> >>> It is all those companies using IT. And the decisions they make.
> >>
> >> You mean all those people running zSystems with COBOL, DB2 and CICS
> >> that actually make up the largest majority of the money makers in the
> >> world? The ones who have been told for at least 4 decades that the
> >> mainframe is dead. Oh yeah, and so is COBOL.
> >
> > The IT industry also include those.
> >
> > But in the big picture they are a tiny part of the IT industry. And
> > not only a tiny part but also a shrinking part.
> >
> > Arne
> >
> Arne, when you offer an opinion, please identify it as "opinion".
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

On 2/17/2022 4:38 PM, Dave Froble wrote:
> On 2/17/2022 2:17 PM, Arne Vajhøj wrote:
>> Sometimes the decision is to migrate. Sometimes the decision is
>> not to migrate.
>>
>> Not to migrate is probably the most common.
>
> If it ain't broke, don't fix it.
>
> How many times do things get "fixed" anyway?

Pretty often. Until something else is broken.

>> But the question comes up again and again. If the question comes
>> up every 3 years and it is 20% migrate 80% keep, then after 24
>> years 87% has migrated.
>
> Statistics doesn't work that way.  It is not cumulative.  If the ratio
> is 20/80, then every time it's 20/80.

Statistics work that way.

20% attrition every 3 years means that after 24 years 87% is gone.

That is a mathematical fact.

Arne

In article <sumfka$spd$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 2/17/2022 3:28 PM, Dan Cross wrote:
>> In article <j77mkgFl71aU1@mid.individual.net>,
>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>> that actually make up the largest majority of the money makers in the
>>> world? The ones who have been told for at least 4 decades that the
>>> mainframe is dead. Oh yeah, and so is COBOL. But then, didn't Byte
>>> predict the death of Unix back in September 1992. :-)
>>
>> Oh boy. COBOL is being discussed; better put on my
>> asbestos undies.
>>
>> But everything you said is true: there's a ton of COBOL,
>> DB2, CICS, etc, out there, much that runs on mainframes.
>> Something like 80% of the world's credit transactions
>> hit some COBOL somewhere at some point.
>>
>> But two things to consider: COBOL on IBM mainframes has
>> gone from being, in some sense, the median programmer
>> experience to being a tiny fraction of that experience.
>> While there may be more mainframes than ever, there's
>> more compute than ever in total, and as a percentage of
>> that total, the mainframe asymptotically crawls to zero.
>> We're never going to see, "Mainframe dead! News at 11!"
>> in our lifetimes, but so what?
>>
>> Nevermind considerations of COBOL as a language; those
>> aren't terribly relevant. What IS relevant are COBOL
>> programmers, and the number of them again shrinks as a
>> percentage of the total. Now, in some ways that means
>> that the remaining COBOL hounds can command their own
>> paychecks, and that's great for them, but I seriously
>> want to know: of the N millions of lines of COBOL code
>> created annually, how many of those are copy-pasted
>> sequences for existing programs, slightly modified
>> with new behavior, because without semantically aware
>> editing tools it's very difficult to understand what
>> procedures are called from where (lookin' at you, 'THRU'
>> modifiers on 'PERFORM' statments), especially in large
>> codebases?
>>
>> Those systems are there because they work and because
>> it is economically prohibitive to move off of them.
>> But I see the changing landscape, particularly the lack
>> of new COBOL programmers being produced as time goes
>> on, as a serious risk.
>>
>> - Dan C.
>>
>
>Where do astronauts come from?
>
>WE TRAIN THEM FOR THE JOB!

True, but kids grow up dreaming about being astronauts.
I don't know anyone who yearns to be a COBOL programmer.

The issue isn't that you can't train people to do it; it's
that almost no one _wants_ to be trained to do it.

Then there's the matter of training materials, educational
venues, etc. Universities used to teach COBOL. High
quality textbooks were produced. These days, not so much.
Most training materials will be second hand books describing
old version of the language, or vendor-supplied materials
of varying levels of quality and erudition.

And who does the training? I guess the vendors provide
courses, or its OJT'ed?

>And that is true for just about anything on the planet. Yes, we train for
>required jobs. But the Cobol (and Basic,Fortran, (hock, spit, gag) C, and
>others will define the needs, based upon the entities with those needs.

Well, good luck finding them.

>I have my doubts about the training defining the needs.

It's not a, "mommy, where do COBOL programmers come from?"
question.

- Dan C.

On 2/17/2022 4:41 PM, Dave Froble wrote:
> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>> I'd like to know just who and what the "industry" Arne refers to
>>>>> is? It's
>>>>> always easy to use some nebulous term.  But just what is it?
>>>>> Perhaps it is a
>>>>> "transfer", as in "transfer your money to us"?
>>>>
>>>> It is all those companies using IT. And the decisions they make.
>>>
>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>> that actually make up the largest majority of the money makers in the
>>> world?  The ones who have been told for at least 4 decades that the
>>> mainframe is dead.  Oh yeah, and so is COBOL.
>>
>> The IT industry also include those.
>>
>> But in the big picture they are a tiny part of the IT industry. And
>> not only a tiny part but also a shrinking part.
>
> Arne, when you offer an opinion, please identify it as "opinion".

That mainframe is a tiny portion of IT today is not an
opinion - it is a fact. You can start by looking at
sales figures.

Arne

In article <sumf59$j67$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 2/17/2022 2:17 PM, Arne Vajhøj wrote:
>> [snip]
>> But the question comes up again and again. If the question comes
>> up every 3 years and it is 20% migrate 80% keep, then after 24
>> years 87% has migrated.
>
>Statistics doesn't work that way. It is not cumulative. If the ratio is 20/80,
>then every time it's 20/80.

Since not many _new_ organizations are adopting mainframes, it
compounds. 1-(4/5)^8 is about 83%. Those that remain may increase
their mainframe investment over time, but as a percentage of the
whole market, they will shrink.

- Dan C.

On 2/17/2022 4:48 PM, JP DEMONA wrote:
> some mainframe COBOL is moving to java (translators) but the primary
> reason is not to be in Java - the reason is more $$ based. the new
> mainframes offer intel co processors which do NOT charge by the MIP.
> the standard IBM mainframe processor still is "pay as you go".

At least Heirloom Computing is running the Java byte code
not on mainframe but cloud.

Arne

In article <620ec8dc$0$697$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/17/2022 4:38 PM, Dave Froble wrote:
>> On 2/17/2022 2:17 PM, Arne Vajhøj wrote:
>>> Sometimes the decision is to migrate. Sometimes the decision is
>>> not to migrate.
>>>
>>> Not to migrate is probably the most common.
>>
>> If it ain't broke, don't fix it.
>>
>> How many times do things get "fixed" anyway?
>
>Pretty often. Until something else is broken.

The "if it ain't broke don't fix it" argument also ignores
externalities.

And it's not like mainframe-based systems aren't being
upgraded; there are costs associated with that. How many
IBM 370/158s are still running in production? 3090s?
9021s?

>>> But the question comes up again and again. If the question comes
>>> up every 3 years and it is 20% migrate 80% keep, then after 24
>>> years 87% has migrated.
>>
>> Statistics doesn't work that way.  It is not cumulative.  If the ratio
>> is 20/80, then every time it's 20/80.
>
>Statistics work that way.
>
>20% attrition every 3 years means that after 24 years 87% is gone.

First cycle in year 0, then 8 more cycles terminating in the 24th
year? Yeah, that's about 87%.

- Dan C.

On 2/17/2022 5:15 PM, Dan Cross wrote:
> In article <sumfka$spd$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/17/2022 3:28 PM, Dan Cross wrote:
>>> Nevermind considerations of COBOL as a language; those
>>> aren't terribly relevant. What IS relevant are COBOL
>>> programmers, and the number of them again shrinks as a
>>> percentage of the total. Now, in some ways that means
>>> that the remaining COBOL hounds can command their own
>>> paychecks, and that's great for them, but I seriously
>>> want to know: of the N millions of lines of COBOL code
>>> created annually, how many of those are copy-pasted
>>> sequences for existing programs, slightly modified
>>> with new behavior, because without semantically aware
>>> editing tools it's very difficult to understand what
>>> procedures are called from where (lookin' at you, 'THRU'
>>> modifiers on 'PERFORM' statments), especially in large
>>> codebases?
>>>
>>> Those systems are there because they work and because
>>> it is economically prohibitive to move off of them.
>>> But I see the changing landscape, particularly the lack
>>> of new COBOL programmers being produced as time goes
>>> on, as a serious risk.
>>
>> Where do astronauts come from?
>>
>> WE TRAIN THEM FOR THE JOB!
>
> True, but kids grow up dreaming about being astronauts.
> I don't know anyone who yearns to be a COBOL programmer.
>
> The issue isn't that you can't train people to do it; it's
> that almost no one _wants_ to be trained to do it.
>
> Then there's the matter of training materials, educational
> venues, etc. Universities used to teach COBOL. High
> quality textbooks were produced. These days, not so much.
> Most training materials will be second hand books describing
> old version of the language, or vendor-supplied materials
> of varying levels of quality and erudition.
>
> And who does the training? I guess the vendors provide
> courses, or its OJT'ed?

Of course people can learn Cobol. All programming
languages can be taught. And Cobol is not even a particular
difficult language.

And people will learn Cobol if there is a real need. That
is how a market economy works. If demand exceed supply, then
price goes up, which cause demand to decrease and supply
to increase and the price continue going up until demand and
supply match. If Cobol developer salaries explode then
people will line up in front of Cobol training courses.
If companies just talk about that they in N years may
see a lack of Cobol developers, then that will not cause
people to learn Cobol.

OK. There is a significant segment of young people in the west
that may prefer to use MEAN stack (cool) for an NGO or green
startup (cool) over using Cobol (not cool) for a big bank (not cool).
But there are other places in the world where such an attitude
is a luxury that cannot be afforded.

Arne

On 2/17/22 17:15, Dan Cross wrote:
> In article <sumfka$spd$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/17/2022 3:28 PM, Dan Cross wrote:
>>> In article <j77mkgFl71aU1@mid.individual.net>,
>>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>> that actually make up the largest majority of the money makers in the
>>>> world? The ones who have been told for at least 4 decades that the
>>>> mainframe is dead. Oh yeah, and so is COBOL. But then, didn't Byte
>>>> predict the death of Unix back in September 1992. :-)
>>>
>>> Oh boy. COBOL is being discussed; better put on my
>>> asbestos undies.
>>>
>>> But everything you said is true: there's a ton of COBOL,
>>> DB2, CICS, etc, out there, much that runs on mainframes.
>>> Something like 80% of the world's credit transactions
>>> hit some COBOL somewhere at some point.
>>>
>>> But two things to consider: COBOL on IBM mainframes has
>>> gone from being, in some sense, the median programmer
>>> experience to being a tiny fraction of that experience.
>>> While there may be more mainframes than ever, there's
>>> more compute than ever in total, and as a percentage of
>>> that total, the mainframe asymptotically crawls to zero.
>>> We're never going to see, "Mainframe dead! News at 11!"
>>> in our lifetimes, but so what?
>>>
>>> Nevermind considerations of COBOL as a language; those
>>> aren't terribly relevant. What IS relevant are COBOL
>>> programmers, and the number of them again shrinks as a
>>> percentage of the total. Now, in some ways that means
>>> that the remaining COBOL hounds can command their own
>>> paychecks, and that's great for them, but I seriously
>>> want to know: of the N millions of lines of COBOL code
>>> created annually, how many of those are copy-pasted
>>> sequences for existing programs, slightly modified
>>> with new behavior, because without semantically aware
>>> editing tools it's very difficult to understand what
>>> procedures are called from where (lookin' at you, 'THRU'
>>> modifiers on 'PERFORM' statments), especially in large
>>> codebases?
>>>
>>> Those systems are there because they work and because
>>> it is economically prohibitive to move off of them.
>>> But I see the changing landscape, particularly the lack
>>> of new COBOL programmers being produced as time goes
>>> on, as a serious risk.
>>>
>>> - Dan C.
>>>
>>
>> Where do astronauts come from?
>>
>> WE TRAIN THEM FOR THE JOB!
>
> True, but kids grow up dreaming about being astronauts.
> I don't know anyone who yearns to be a COBOL programmer.

I still do.... :-)

>
> The issue isn't that you can't train people to do it; it's
> that almost no one _wants_ to be trained to do it.

No, that's not quite accurate. It's because the people who should
be teaching them COBOL refuse to for reasons with no basis in fact.

>
> Then there's the matter of training materials, educational
> venues, etc. Universities used to teach COBOL.

And they are the root of the problem.

> High
> quality textbooks were produced.

Well, can't say I agree with that. The textbook business is mostly
snake oil. One of the most popular COBOL textbooks was written by
a pair of professional textbook writers, not by practitioners of the
art. When I took COBOL in school I bought two additional books to
accompany the chosen textbook. It contributed greatly to how well
I learned the subject.

> These days, not so much.
> Most training materials will be second hand books describing
> old version of the language, or vendor-supplied materials
> of varying levels of quality and erudition.

There are very good books on COBOL available today. And they
cover the language as is currently in use. (That means the
EVALUATE verb rather than 20 level deep IF-THEN-ELSE peices.)
They also cover Database access from COBOL as well as the
old fashioned flat file stuff. I have even considered writing
a COBOL text myself targeted at the use of OpenSource tools.

>
> And who does the training? I guess the vendors provide
> courses, or its OJT'ed?

Right now probably the vendor. GDIT, who has a very large
COBOL IS supporting the DOD used to advertise for interns.
Wanted first or second year students who had taken the
usual two course intro to programming and said they would
provide the COBOL training.

But that is a very limited solution to the problem. Universities
have abdicated their responsibility to prepare students for their
future careers. I think it is time to get the Tech Schools
involved. Many of them are now degree granting institutions
(locally you can get degrees in things like diesel mechanic!)
and have taught low level CIS classes already. This could be
a boon for them.

>
>> And that is true for just about anything on the planet. Yes, we train for
>> required jobs. But the Cobol (and Basic,Fortran, (hock, spit, gag) C, and
>> others will define the needs, based upon the entities with those needs.
>
> Well, good luck finding them.
>
>> I have my doubts about the training defining the needs.
>
> It's not a, "mommy, where do COBOL programmers come from?"
> question.
>

True. the real question that people in the industry should be
asking is just why Universities refuse to meet this particular
need. It's not rocket science and most Universities that have
CS programs usually have CIS program as well. Why do they
refuse to meet this need?

bill

On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
> On 2/17/2022 4:41 PM, Dave Froble wrote:
>> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>>> I'd like to know just who and what the "industry" Arne refers to is? It's
>>>>>> always easy to use some nebulous term. But just what is it? Perhaps it is a
>>>>>> "transfer", as in "transfer your money to us"?
>>>>>
>>>>> It is all those companies using IT. And the decisions they make.
>>>>
>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>> that actually make up the largest majority of the money makers in the
>>>> world? The ones who have been told for at least 4 decades that the
>>>> mainframe is dead. Oh yeah, and so is COBOL.
>>>
>>> The IT industry also include those.
>>>
>>> But in the big picture they are a tiny part of the IT industry. And
>>> not only a tiny part but also a shrinking part.
>>
>> Arne, when you offer an opinion, please identify it as "opinion".
>
> That mainframe is a tiny portion of IT today is not an
> opinion - it is a fact. You can start by looking at
> sales figures.
>
> Arne
>
>

That might depend upon what's being counted.

Total amount of work being done.

or

Total CPUs/computers sold.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2/17/22 21:08, Dave Froble wrote:
> On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
>> On 2/17/2022 4:41 PM, Dave Froble wrote:
>>> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>>>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>>>> I'd like to know just who and what the "industry" Arne refers to
>>>>>>> is? It's
>>>>>>> always easy to use some nebulous term.  But just what is it?
>>>>>>> Perhaps it is a
>>>>>>> "transfer", as in "transfer your money to us"?
>>>>>>
>>>>>> It is all those companies using IT. And the decisions they make.
>>>>>
>>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>>> that actually make up the largest majority of the money makers in the
>>>>> world?  The ones who have been told for at least 4 decades that the
>>>>> mainframe is dead.  Oh yeah, and so is COBOL.
>>>>
>>>> The IT industry also include those.
>>>>
>>>> But in the big picture they are a tiny part of the IT industry. And
>>>> not only a tiny part but also a shrinking part.
>>>
>>> Arne, when you offer an opinion, please identify it as "opinion".
>>
>> That mainframe is a tiny portion of IT today is not an
>> opinion - it is a fact. You can start by looking at
>> sales figures.
>>
>> Arne
>>
>>
>
> That might depend upon what's being counted.
>
> Total amount of work being done.
>
> or
>
> Total CPUs/computers sold.
>

Or what level your on in Candy Crush Saga. Isn't that all that
matters in today's IT world?

bill

On Thursday, February 17, 2022 at 9:15:14 AM UTC-5, Arne Vajhøj wrote:
> On 2/17/2022 5:28 AM, Phillip Helbig (undress to reply) wrote:
> > In article <919fe330-a0dc-4784...@googlegroups.com>,
> > "dthi...@gmail.com" <dthi...@gmail.com> writes:
> >> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
> >> standard, and not a complete implementation of it either). Later FORTRAN
> >> standards (2003, 2008, 2108) have fully embraced object oriented code
> >> practices and C interoperability.
> >
> > Isn't there supposed to be a much more modern, FLANG-based Fortran
> > compiler from VSI (presumably only) on x86?
> >
> > If so, when?
> VSI has stated their intention to go with flang. Which is really saying
> that they have no intention of shoehorning the newer Fortran standards
> into the old compiler. Which makes sense.
>
> And since it will be LLVM based then it must be x86-64 only.
>
> And they will want all existing compilers plus clang running natively on
> VMS x86-64 before they get to flang. Realistically I think it will be
> quite some years before it is available.
>
> Just guessing of course.
>
> Arne
flang isn't ready to be used yet. It is part of the LLVM repo but at this point, it is just a frontend without any connection to LLVM

In article <620e5870$0$701$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/17/2022 5:28 AM, Phillip Helbig (undress to reply) wrote:
>> In article <919fe330-a0dc-4784-bd2e-edea99790dc0n@googlegroups.com>,
>> "dthi...@gmail.com" <dthittner@gmail.com> writes:
>>> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
>>> standard, and not a complete implementation of it either). Later FORTRAN
>>> standards (2003, 2008, 2108) have fully embraced object oriented code
>>> practices and C interoperability.
>>
>> Isn't there supposed to be a much more modern, FLANG-based Fortran
>> compiler from VSI (presumably only) on x86?
>>
>> If so, when?
>
>VSI has stated their intention to go with flang. Which is really saying
>that they have no intention of shoehorning the newer Fortran standards
>into the old compiler. Which makes sense.

Not really. The old DEC GEM compilers were super cool.

>And since it will be LLVM based then it must be x86-64 only.

Why do you say that? Just in the sense that they won't
backport to OpenVMS/Itanium or Alpha? LLVM has backends
for non-x86 architectures. (If I were VSI, I'd be
getting a jump on ports to ARM and RISC-V now.)

- Dan C.

On 2/18/2022 10:12 AM, Dan Cross wrote:
> In article <620e5870$0$701$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/17/2022 5:28 AM, Phillip Helbig (undress to reply) wrote:
>>> In article <919fe330-a0dc-4784-bd2e-edea99790dc0n@googlegroups.com>,
>>> "dthi...@gmail.com" <dthittner@gmail.com> writes:
>>>> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
>>>> standard, and not a complete implementation of it either). Later FORTRAN
>>>> standards (2003, 2008, 2108) have fully embraced object oriented code
>>>> practices and C interoperability.
>>>
>>> Isn't there supposed to be a much more modern, FLANG-based Fortran
>>> compiler from VSI (presumably only) on x86?
>>>
>>> If so, when?
>>
>> VSI has stated their intention to go with flang. Which is really saying
>> that they have no intention of shoehorning the newer Fortran standards
>> into the old compiler. Which makes sense.
>
> Not really. The old DEC GEM compilers were super cool.

The cost.

>> And since it will be LLVM based then it must be x86-64 only.
>
> Why do you say that? Just in the sense that they won't
> backport to OpenVMS/Itanium or Alpha? LLVM has backends
> for non-x86 architectures. (If I were VSI, I'd be
> getting a jump on ports to ARM and RISC-V now.)

I don't see flang/LLVM support Itanium or Alpha.

Maybe ARM or RISC-V some day in the future.

Arne

In article <sumv2s$fav$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
>> That mainframe is a tiny portion of IT today is not an
>> opinion - it is a fact. You can start by looking at
>> sales figures.
>
>That might depend upon what's being counted.
>
>Total amount of work being done.
>
>or
>
>Total CPUs/computers sold.

Honestly, this is where mainframe people go off the rails.

The work done on mainframes is _important_: I don't think anyone
seriously disputes that.

Given the important systems that are tied to mainframes, it
follows that mainframes are similarly _important_.

However, counted as a fraction of the total number of CPU cycles
or CPUs sold, mainframes are a vanishingly small part of the
overall market.

I honestly don't get why mainframe people get so bent about
this. The outsized importance of the platform relative to its
share in the market righlty ought to be a source of pride, not
defensiveness.

- Dan C.

On 2/17/2022 9:08 PM, Dave Froble wrote:
> On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
>> On 2/17/2022 4:41 PM, Dave Froble wrote:
>>> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>>>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>>>> I'd like to know just who and what the "industry" Arne refers to
>>>>>>> is? It's
>>>>>>> always easy to use some nebulous term.  But just what is it?
>>>>>>> Perhaps it is a
>>>>>>> "transfer", as in "transfer your money to us"?
>>>>>>
>>>>>> It is all those companies using IT. And the decisions they make.
>>>>>
>>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>>> that actually make up the largest majority of the money makers in the
>>>>> world?  The ones who have been told for at least 4 decades that the
>>>>> mainframe is dead.  Oh yeah, and so is COBOL.
>>>>
>>>> The IT industry also include those.
>>>>
>>>> But in the big picture they are a tiny part of the IT industry. And
>>>> not only a tiny part but also a shrinking part.
>>>
>>> Arne, when you offer an opinion, please identify it as "opinion".
>>
>> That mainframe is a tiny portion of IT today is not an
>> opinion - it is a fact. You can start by looking at
>> sales figures.
>
> That might depend upon what's being counted.
>
> Total amount of work being done.
>
> or
>
> Total CPUs/computers sold.

Revenue dollars. Money matters.

Arne

In article <j7844nFnlqeU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 2/17/22 17:15, Dan Cross wrote:
>> True, but kids grow up dreaming about being astronauts.
>> I don't know anyone who yearns to be a COBOL programmer.
>
>I still do.... :-)

Ha! I meant to write, "I don't know any kids...", but perhaps
I should just cite you as the exception to the rule. :-)

>>
>> The issue isn't that you can't train people to do it; it's
>> that almost no one _wants_ to be trained to do it.
>
>No, that's not quite accurate. It's because the people who should
>be teaching them COBOL refuse to for reasons with no basis in fact.

Who are those people? University professors? What are their
reasons and, more importantly, why aren't those reasons factual?

>> Then there's the matter of training materials, educational
>> venues, etc. Universities used to teach COBOL.
>
>And they are the root of the problem.

This is turning into a much deeper discussion. My opinion is
that universities should not exist solely to provide vocational
training. At this point, teaching COBOL is entirely vocational.

>> High
>> quality textbooks were produced.
>
>Well, can't say I agree with that. The textbook business is mostly
>snake oil. One of the most popular COBOL textbooks was written by
>a pair of professional textbook writers, not by practitioners of the
>art. When I took COBOL in school I bought two additional books to
>accompany the chosen textbook. It contributed greatly to how well
>I learned the subject.

Who wrote those books? At any rate, perhaps I should have said
that there have been high quality texts on COBOL, regardless of
whether those texts fit a prescribed textbook format.

>
>> These days, not so much.
>> Most training materials will be second hand books describing
>> old version of the language, or vendor-supplied materials
>> of varying levels of quality and erudition.
>
>There are very good books on COBOL available today. And they
>cover the language as is currently in use. (That means the
>EVALUATE verb rather than 20 level deep IF-THEN-ELSE peices.)
>They also cover Database access from COBOL as well as the
>old fashioned flat file stuff. I have even considered writing
>a COBOL text myself targeted at the use of OpenSource tools.

Go for it! That would be a useful addition to the canon.

>> And who does the training? I guess the vendors provide
>> courses, or its OJT'ed?
>
>Right now probably the vendor. GDIT, who has a very large
>COBOL IS supporting the DOD used to advertise for interns.
>Wanted first or second year students who had taken the
>usual two course intro to programming and said they would
>provide the COBOL training.
>
>But that is a very limited solution to the problem. Universities
>have abdicated their responsibility to prepare students for their
>future careers. I think it is time to get the Tech Schools
>involved. Many of them are now degree granting institutions
>(locally you can get degrees in things like diesel mechanic!)
>and have taught low level CIS classes already. This could be
>a boon for them.

I suppose there's a much larger debate to be had about the role
of universities in professional computing. I wouldn't say that
they have "abdicated their responsibility to prepare students
for their future careers", though; certainly not by abandoning
COBOL in their curricula.

In my view, universities exist to for two things: education and
research. The educational mission usually means imparting the
basics and equipping students with the tools necessary to absorb
other information. This naturally means learning things that
are mostly agnostic of any particular technology; in CS, that's
data structures and algorithms, basic coding skills, highlights
of major topics in the field, etc. Particular programming
languages are not among them.

The research side should be pushing the limits of the field ever
outward. If there's any interesting research to do on COBOL, I
imagine it would be some semantic analysis, but mostly automatic
conversion to other languages.

>>> And that is true for just about anything on the planet. Yes, we train for
>>> required jobs. But the Cobol (and Basic,Fortran, (hock, spit, gag) C, and
>>> others will define the needs, based upon the entities with those needs.
>>
>> Well, good luck finding them.
>>
>>> I have my doubts about the training defining the needs.
>>
>> It's not a, "mommy, where do COBOL programmers come from?"
>> question.
>
>True. the real question that people in the industry should be
>asking is just why Universities refuse to meet this particular
>need.

Probably because the need appears less pressing than reality
might indicate, but again, universities aren't vocational
training schools; there's a lot of COBOL out there, but again,
how much of that is copy-pasta because people are scared of
modifying working code? Most of the COBOL work has been
outsourced, and you can't force students to want to learn COBOL.
As a fraction of overall computing, the demand for COBOL
programmers, at least in the United States, is small.

Note that this isn't meant as an elitist/snob thing, rather just
that the mission is different. I suspect the soluton here is to
provide this sort of training via vocational programs; hand in
hand with that, societies really ought to treat those things
with more respect.

>It's not rocket science and most Universities that have
>CS programs usually have CIS program as well. Why do they
>refuse to meet this need?

I would argue that CIS isn't strictly appropriate for a
university, unless it's more of an inter-disciplinary research
center, possibly offering a few survey courses.

- Dan C.

In article <620fb853$0$693$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/18/2022 10:12 AM, Dan Cross wrote:
>> In article <620e5870$0$701$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 2/17/2022 5:28 AM, Phillip Helbig (undress to reply) wrote:
>>>> In article <919fe330-a0dc-4784-bd2e-edea99790dc0n@googlegroups.com>,
>>>> "dthi...@gmail.com" <dthittner@gmail.com> writes:
>>>>> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
>>>>> standard, and not a complete implementation of it either). Later FORTRAN
>>>>> standards (2003, 2008, 2108) have fully embraced object oriented code
>>>>> practices and C interoperability.
>>>>
>>>> Isn't there supposed to be a much more modern, FLANG-based Fortran
>>>> compiler from VSI (presumably only) on x86?
>>>>
>>>> If so, when?
>>>
>>> VSI has stated their intention to go with flang. Which is really saying
>>> that they have no intention of shoehorning the newer Fortran standards
>>> into the old compiler. Which makes sense.
>>
>> Not really. The old DEC GEM compilers were super cool.
>
>The cost.

Which cost? Bolting on a backend for x86_64 wouldn't be that
hard: they already have backends for VAX, MIPS, Alpha, and
Itanium.

Keeping up with evolving language standards? Yeah, that's an
issue.

>>> And since it will be LLVM based then it must be x86-64 only.
>>
>> Why do you say that? Just in the sense that they won't
>> backport to OpenVMS/Itanium or Alpha? LLVM has backends
>> for non-x86 architectures. (If I were VSI, I'd be
>> getting a jump on ports to ARM and RISC-V now.)
>
>I don't see flang/LLVM support Itanium or Alpha.

Alpha support was dropped back in 2011:
https://github.com/llvm/llvm-project/commit/4c9fca99c9a6734bb33c34aeaf40b71c4002757e

IA-64 was removed back in 2009.

Bringing either back would probably be a pretty big lift,
but with commercial support, I imagine the LLVM folks would
be fine with it. There's an MC68k backend, afterall.

But if VSI is cool with GEM on Alpha/Itanium, and LLVM on
x86_64, I guess that's their business.

>Maybe ARM or RISC-V some day in the future.

It seems clear that there's an architectural shift away
from x86 happening. Best to lay the groundwork now to
avoid being caught out.

- Dan C.

On 2/18/2022 10:59 AM, Dan Cross wrote:
> In article <620fb853$0$693$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/18/2022 10:12 AM, Dan Cross wrote:
>>> In article <620e5870$0$701$14726298@news.sunsite.dk>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 2/17/2022 5:28 AM, Phillip Helbig (undress to reply) wrote:
>>>>> In article <919fe330-a0dc-4784-bd2e-edea99790dc0n@googlegroups.com>,
>>>>> "dthi...@gmail.com" <dthittner@gmail.com> writes:
>>>>>> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
>>>>>> standard, and not a complete implementation of it either). Later FORTRAN
>>>>>> standards (2003, 2008, 2108) have fully embraced object oriented code
>>>>>> practices and C interoperability.
>>>>>
>>>>> Isn't there supposed to be a much more modern, FLANG-based Fortran
>>>>> compiler from VSI (presumably only) on x86?
>>>>>
>>>>> If so, when?
>>>>
>>>> VSI has stated their intention to go with flang. Which is really saying
>>>> that they have no intention of shoehorning the newer Fortran standards
>>>> into the old compiler. Which makes sense.
>>>
>>> Not really. The old DEC GEM compilers were super cool.
>>
>> The cost.
>
> Which cost? Bolting on a backend for x86_64 wouldn't be that
> hard: they already have backends for VAX, MIPS, Alpha, and
> Itanium.

????

VSI is already doing that by utilizing LLVM.

But the topic was "shoehorning the newer Fortran standards
into the old compiler".

> Keeping up with evolving language standards? Yeah, that's an
> issue.

Yes.

>>>> And since it will be LLVM based then it must be x86-64 only.
>>>
>>> Why do you say that? Just in the sense that they won't
>>> backport to OpenVMS/Itanium or Alpha? LLVM has backends
>>> for non-x86 architectures. (If I were VSI, I'd be
>>> getting a jump on ports to ARM and RISC-V now.)
>>
>> I don't see flang/LLVM support Itanium or Alpha.
>
> Alpha support was dropped back in 2011:
> https://github.com/llvm/llvm-project/commit/4c9fca99c9a6734bb33c34aeaf40b71c4002757e
>
> IA-64 was removed back in 2009.
>
> Bringing either back would probably be a pretty big lift,
> but with commercial support, I imagine the LLVM folks would
> be fine with it. There's an MC68k backend, afterall.

I don't expect that to happen.

> But if VSI is cool with GEM on Alpha/Itanium, and LLVM on
> x86_64, I guess that's their business.

That is what they say.

>> Maybe ARM or RISC-V some day in the future.
>
> It seems clear that there's an architectural shift away
> from x86 happening. Best to lay the groundwork now to
> avoid being caught out.

Maybe, but even if it does happen then it will take many years.

Arne