[Info-vax] And another one bites the dust....

[Bill Gunshannon]

On 2/17/22 17:15, Dan Cross wrote:
> In article <sumfka$spd$1 at dont-email.me>,
> Dave Froble  <davef at tsoft-inc.com> wrote:
>> On 2/17/2022 3:28 PM, Dan Cross wrote:
>>> In article <j77mkgFl71aU1 at mid.individual.net>,
>>> Bill Gunshannon  <bill.gunshannon at 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