And another one bites the dust....

[Bill Gunshannon]

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.
--------

Does anyone watch for these postings and then try to convince them to
not move away from VMS? Or at least find out why they are moving.

bill

[Arne Vajhøj]

It is VSI's job to monitor migrations and argue for keeping VMS.

Why people are moving off VMS are pretty well known. Generally being
on a niche platform is considered a risk. The wording above hint
that not being able to run on VMWare servers is a significant
problem for that company as well.

So if VMS 9.2 has been released 2-3 years ago then maybe (just maybe)
this company would have kept VMS. But it was not.

It would be good for VSI to push info about VMS x86-64. If I were
responsible for marketing at VSI then I would send out an offer
to join the VMS x86-86 field test program to every company that is
using VMS. Not because there necessarily will be any benefits for
them or VSI of them joining, but because it send a strong
signal that VMS x86-64 is just around the corner.

Arne

[Simon Clubley]

By the time a porting effort gets to that stage, it's usually too late
as emotionally they are in a place where they have decided they need
to get rid of the old system and only the details of how that is to
be done needs to be worked out.

What is interesting however, is why now instead of, say, 5 years ago ?

Did they initially wait for VSI to complete the port to x86-64 VMS,
but now, 7.5 years later without a production-ready version of x86-64 VMS,
did they finally decide to move away from VMS ?

I wonder if anything could be done to keep other customers waiting
a little longer, or if it's simply too late and some customers have
decided to finally move from VMS ?

One problem might be that you can't emulate an Itanium system, unlike
an Alpha system, so people might be having concerns around the age of
their Itanium systems.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Simon Clubley]

On 2022-02-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 2/15/2022 8:04 AM, 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.
>> --------
>>
>> Does anyone watch for these postings and then try to convince them to
>> not move away from VMS?   Or at least find out why they are moving.
>
> It is VSI's job to monitor migrations and argue for keeping VMS.
>

I really hope they are doing this.

> Why people are moving off VMS are pretty well known. Generally being
> on a niche platform is considered a risk. The wording above hint
> that not being able to run on VMWare servers is a significant
> problem for that company as well.
>
> So if VMS 9.2 has been released 2-3 years ago then maybe (just maybe)
> this company would have kept VMS. But it was not.
>

I agree with this reasoning.

> It would be good for VSI to push info about VMS x86-64. If I were
> responsible for marketing at VSI then I would send out an offer
> to join the VMS x86-86 field test program to every company that is
> using VMS. Not because there necessarily will be any benefits for
> them or VSI of them joining, but because it send a strong
> signal that VMS x86-64 is just around the corner.
>

This is the kind of thing I was thinking of in my previous posting
when I wondered if there was anything that could be done and I agree
with your reasoning here as well.

This is exactly the kind of thing VSI should be doing, and if they are
not, then it's the kind of thing they should start doing immediately.

[Bill Gunshannon]

On 2/15/22 09:02, Arne Vajhøj wrote:
> On 2/15/2022 8:04 AM, 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.
>> --------
>>
>> Does anyone watch for these postings and then try to convince them to
>> not move away from VMS?   Or at least find out why they are moving.
>
> It is VSI's job to monitor migrations and argue for keeping VMS.

Agreed. But does anyone actually do it?

>
> Why people are moving off VMS are pretty well known. Generally being
> on a niche platform is considered a risk. The wording above hint
> that not being able to run on VMWare servers is a significant
> problem for that company as well.

"virtualized Windows Server" does not necessarily mean VMWare. Windows
has its own virtualization product.

>
> So if VMS 9.2 has been released 2-3 years ago then maybe (just maybe)
> this company would have kept VMS. But it was not.
>
> It would be good for VSI to push info about VMS x86-64. If I were
> responsible for marketing at VSI then I would send out an offer
> to join the VMS x86-86 field test program to every company that is
> using VMS. Not because there necessarily will be any benefits for
> them or VSI of them joining, but because it send a strong
> signal that VMS x86-64 is just around the corner.

Maybe, but the push seems to be for virtualization and I saw a number
of OpenVMS job announcements that seemed to be production floor systems
which probably can't virtualized. I even saw one that involved VAXen
and the description was good enough to know this was real and not just
boilerplate in a vacancy announcement.

bill

[Arne Vajhøj]

On 2/15/2022 9:19 AM, Bill Gunshannon wrote:
> On 2/15/22 09:02, Arne Vajhøj wrote:
>> On 2/15/2022 8:04 AM, 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.
>>> --------
>>>
>>> Does anyone watch for these postings and then try to convince them to
>>> not move away from VMS?   Or at least find out why they are moving.
>>
>> It is VSI's job to monitor migrations and argue for keeping VMS.
>
> Agreed.  But does anyone actually do it?

We will probably never know.

:-)

>> Why people are moving off VMS are pretty well known. Generally being
>> on a niche platform is considered a risk. The wording above hint
>> that not being able to run on VMWare servers is a significant
>> problem for that company as well.
>
> "virtualized Windows Server" does not necessarily mean VMWare.  Windows
> has its own virtualization product.

True.

VMWare or Hyper-V.

>> So if VMS 9.2 has been released 2-3 years ago then maybe (just maybe)
>> this company would have kept VMS. But it was not.
>>
>> It would be good for VSI to push info about VMS x86-64. If I were
>> responsible for marketing at VSI then I would send out an offer
>> to join the VMS x86-86 field test program to every company that is
>> using VMS. Not because there necessarily will be any benefits for
>> them or VSI of them joining, but because it send a strong
>> signal that VMS x86-64 is just around the corner.
>
> Maybe, but the push seems to be for virtualization

That is very common. Virtualization is a must have and
containers is a nice to have.

> and I saw a number
> of OpenVMS job announcements that seemed to be production floor systems
> which probably can't virtualized.

Maybe.

Arne

[Arne Vajhøj]

Another possibility is Oracle.

I found the ad and it said Oracle.

And Oracle announced end of VMS support for Oracle DB
client in October 2020.

October 2020 + problem analysis + budget approval
sort of fits with a project start spring 2022.

On the other side I am not sure about the Fortran support
in Oracle DB client.

Arne

[abrsvc]

On Tuesday, February 15, 2022 at 9:04:13 AM UTC-5, Simon Clubley wrote:
> On 2022-02-15, Bill Gunshannon <bill.gu...@gmail.com> 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.
> > --------
> >
> > Does anyone watch for these postings and then try to convince them to
> > not move away from VMS? Or at least find out why they are moving.
> >
> By the time a porting effort gets to that stage, it's usually too late
> as emotionally they are in a place where they have decided they need
> to get rid of the old system and only the details of how that is to
> be done needs to be worked out.
>
> What is interesting however, is why now instead of, say, 5 years ago ?
>
> Did they initially wait for VSI to complete the port to x86-64 VMS,
> but now, 7.5 years later without a production-ready version of x86-64 VMS,
> did they finally decide to move away from VMS ?

Many of the clients that I have had in the last few years moved from OpenVMS because of specialized hardware requirements.
Some considered using emulators, but without the special hardware, could not.
Others are moving away because of software resources not being available. While the applications are solid and rarely require update, the concern is that there are few who use the older languages or understand that environment any more. I have seen more movement into a hybrid environment where more modern techniques and languages are used for front end (consumer facing) parts of the code with the backend remaining on OpenVMS. I think that this trend will continue.

I am dealing with a client now that is "replicating" their ACMS based system to a Linux based one for the terminal handling via web services. The backend RDB database will remain in place on OpenVMS. This will extend their platform for years. They are still debating the pathway though. Emulation appears to be the easiest and least expensive given the cost for RDB on newer servers.

[Arne Vajhøj]

On 2/15/2022 8:04 AM, Bill Gunshannon wrote:

I found the ad.

And what is puzzling me is that it is not clear whether
they will keep Fortran or not.

<quote>
Document and migrate systems currently running Visual Basic, and older
Java code to a modern .Net framework

Document, plan and execute the modernization of Fortran applications
running on OpenVMS systems to a virtualized Windows Server environment.

...
Software Engineer / Developer with minimum of 1-2 years of experience
developing in Java, C, and C#. Knowledge of the Visual Studio IDE.
Comfortable with both Linux/Unix and Windows environments.

Must be willing to work with OpenVMS and FOTRAN.

Development experience with FORTRAN, .Net Core or SignalR a plus

Experience with Tableau a plus

Experience with SQL and Oracle a plus
...
Experience:

Java: 3 years (Required)
C#: 1 year (Required)
</quote>

It seems pretty clear that client side is changing from
VB6 and Java (AWT or Swing) desktop apps on Windows to
browser and an ASP.NET web app on Windows.

Server side is moving from Fortran on VMS to something
on Windows. But what is something? Not mentioning new language
points to keeping Fortran. But Fortran is really niche on
Windows and there is little emphasis on Fortran skills
in the ad. If I were to hire someone to port Fortran code
from VMS to Windows then I would insist on someone
with Fortran skills, but if porting from Fortran on VMS to
something else (like C# or Java) on Windows, then Fortran
skills are not quite as important.

Lots of speculation.

:-)

Arne

[Dan Cross]

In article <j71r42...@mid.individual.net>,

Bill Gunshannon <bill.gu...@gmail.com> wrote:
>Maybe, but the push seems to be for virtualization and I saw a number
>of OpenVMS job announcements that seemed to be production floor systems
>which probably can't virtualized.

Why not? There are reasons to virtualize systems on-prem.

- Dan C.

[Bill Gunshannon]

They are if he needs to be able to understand Fortran to
do the port. :-)

>
> Lots of speculation.
>
> :-)
>
> Arne

bill

[Bill Gunshannon]

I guess it depends on how you actually communicate with the
devices on the floor. When I think of production floor systems
I think of cables between running machines and computers.
Probably my PDP-11 past seeping through.

bill

[abrsvc]

The experience required depends on the ultimate goal. I have/am involved with clients where my skills are used to explain the current programming to those not familiar with the languages and OpenVMS. This site may already have FORTRAN folks that can provide this.

Dan

[Jan-Erik Söderholm]

Our VMS production support system only talks over the network.
Could just as well be in a VM as on the current Alpha.

[Arne Vajhøj]

You would not translate Fortran code to C#/Java/whatever code 1:1,
so the person would just need to understand what the code does.

Fortran (at least up to 77!) is not a difficult language
to understand.

For reasonable nice Fortran then I would expect a developer
without Fortran experience to be able to deduct in and
out arguments, the main flow and any IO done.

Arne

[Arne Vajhøj]

Also worth mentioning is that VSI has a solution for
the "Oracle problem" - to use the SQLRelay product.

It is actually quite nice. I like it.

But of course not everybody may share my opinion.

Arne

[Bill Gunshannon]

> Fortran (at least up to 77!) is not a difficult languag > to understand.

:-)

>
> For reasonable nice Fortran then I would expect a developer
> without Fortran experience to be able to deduct in and
> out arguments, the main flow and any IO done.

If only there was "reasonable nice Fortran". I used to have
to maintain a half dozen business applications written in
Fortran 66 by bored engineers who needed someting to keep
them busy during the summer off-season at a college. Each
several thousand lines long.

bill

[Bill Gunshannon]

I thought of that afterwards. I guess a lot of it today is PLC's
talking to the bigger iron over the network. But that just leaves
me wondering how one does realtime.

bill

[Simon Clubley]

On 2022-02-15, abrsvc <dansabr...@yahoo.com> wrote:
> Others are moving away because of software resources not being available. While the applications are solid and rarely require update, the concern is that there are few who use the older languages or understand that environment any more. I have seen more movement into a hybrid environment where more modern techniques and languages are used for front end (consumer facing) parts of the code with the backend remaining on OpenVMS. I think that this trend will continue.
>

When I see comments like this Dan, I keep coming back to my previous
suggestion that VSI should implement a VMS version of IBM's Master the
Mainframe program:

https://www.ibm.com/it-infrastructure/z/education/zxplore

IBM's program has succeeded in building a community of people who are
now aware of z/OS and now have the skills to start using it.

A VMS version of this program would be a great way of building a base
of people with general knowledge and awareness of VMS and it would be
a good way of making VMS seem not so alien to people raised purely on
the Unix and Windows way of doing things.

[Bill Gunshannon]

On 2/15/22 13:41, Simon Clubley wrote:
> On 2022-02-15, abrsvc <dansabr...@yahoo.com> wrote:
>> Others are moving away because of software resources not being available. While the applications are solid and rarely require update, the concern is that there are few who use the older languages or understand that environment any more. I have seen more movement into a hybrid environment where more modern techniques and languages are used for front end (consumer facing) parts of the code with the backend remaining on OpenVMS. I think that this trend will continue.
>>
>
> When I see comments like this Dan, I keep coming back to my previous
> suggestion that VSI should implement a VMS version of IBM's Master the
> Mainframe program:
>
> https://www.ibm.com/it-infrastructure/z/education/zxplore
>
> IBM's program has succeeded in building a community of people who are
> now aware of z/OS and now have the skills to start using it.
>
> A VMS version of this program would be a great way of building a base
> of people with general knowledge and awareness of VMS and it would be
> a good way of making VMS seem not so alien to people raised purely on
> the Unix and Windows way of doing things.
>

I only see one likely problem with this idea. What possible incentive
would there be for anyone to do it? VMS hardly has the name value or
recognition of IBM today.

bill

[Arne Vajhøj]

That IBM link claims the 3500 schools are using it.

If just 1% of that number did it for VMS, then it would be progress.

Would it be a hard sell? Probably - but a lot of things are hard -
some people still do them.

Arne

[Chris Townley]

On 15/02/2022 19:36, Arne Vajhøj wrote:

>
> Would it be a hard sell? Probably - but a lot of things are hard -
> some people still do them.
>
> Arne
>

Just like the JFK speech in 1962 announcing the moon mission

That was probably harder than learning a bit about VMS!

--
Chris

[Hans Bachner]

Today, most shop floor equipment communicates over Ethernet. I know of a
few (rather old) machines which use serial communication, but only with
an old DECserver - and Ethernet from there to the VMS nodes, using LAT
or Telnet devices. VMS running under VMware by means of Alpha (in two
cases VAX) emulation.

In fact, most of the emulators I have touched in the last few years
[disclaimer: my company is a Stromasys sales and support partner] run in
virtual machines. Some customers migrated older emulator versions
running on physical servers to current versions on virtual servers.

So: running OpenVMS in a VMware environment is reality today. I'd
personally prefer to run OpenVMS natively in a VM (soon), but not
everyone is able to migrate due to missing source code and/or 3rd party
software dependencies.

Hans.

[Richard Maher]

My guess is the keyword here is "virtualized" if all upgrades,
management etc was in the cloud maybe the OS wouldn't matter?

Definitely if no re-write of legacy technical debt was involved

[David Wade]

If they have decided to move, by the time its got to this stage I think
it highly unlikely they will change their mind. Firstly some one would
have to admit they have made a wrong call. This generally doesn't happen.

Secondly skills set consolidation on the Windows or Linux platform makes
sense. Having to manage VMS and have VMS skills available is expensive
and risky. It will also mean extra expense for new VMS licences, and may
mean extra expense for backups. Virtualized Windows licences are
essentially low cost (free) for small instances. If you have an
enterprise licence on the virtual host then you can run as many virtual
instances of windows as the server will support.

Pretty much the same goes for FORTRAN. Unless there is something special
about FORTRAN that the application needs I would expect it to be moved
to a "modern" language such as C# (its no longer modern, but its current).

So to me remaining on VMS can only be justified when:-

1. There are legal or regulatory reasons to remain. Typically for safety
critical systems in aviation, nuclear energy, train operations etc.

2. You have a lot of VMS and you don't have the funds to move.
-> this means your business is doomed to fail as VMS will get more
expensive.

3. You don't actually understand the business logic in your systems.
I would expect this to fail any audit checks....

.. but these are the challenges facing VMS Software. A key one is
knowing which sites can be persuaded or need to stay on VMS and which
will move any way.

Dave

[Simon Clubley]

On 2022-02-15, Hans Bachner <ha...@bachner.priv.at> wrote:
>
> In fact, most of the emulators I have touched in the last few years
> [disclaimer: my company is a Stromasys sales and support partner] run in
> virtual machines. Some customers migrated older emulator versions
> running on physical servers to current versions on virtual servers.
>

How do you handle customers with Itanium systems who want to move
away from physical Itanium hardware ?

I know there are no free Itanium full system emulators, but are there
any commercial Itanium full system emulation options I have missed ?

[Johnny Billquist]

Throw lots of hardware resources as the problem, and pray. That's what I
usually see... Usually aided by the fact that a lot of situations isn't
hard realtime.

Johnny

[John Dallman]

In article <suj060$sbc$1...@dont-email.me>,

clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> I know there are no free Itanium full system emulators, but are
> there any commercial Itanium full system emulation options I have
> missed ?

HPE seem to have started to produce something for HP-UX. They announced
in 2017 that they would provide a way to run HP-UX in containers on x86
Linux, which obviously requires some kind of emulation. They called this
"Portable HP-UX", sometimes abbreviated "P-UX".

<https://3000newswire.blogs.com/3000_newswire/2017/09/hpe-takes-on-water-a
fter-its-software-flip.html>

This is a beta for it:

https://downloads.linux.hpe.com/SDR/project/c-ux-beta/

The Administration Guide has the most information. However, it is dated
2019, so it looks as if the project has died.

John

[Arne Vajhøj]

On 2/16/2022 10:44 AM, Johnny Billquist wrote:
> On 2022-02-15 18:21, Bill Gunshannon wrote:
>> On 2/15/22 11:00, Jan-Erik Söderholm wrote:
>>> Den 2022-02-15 kl. 16:46, skrev Bill Gunshannon:
>>>> On 2/15/22 10:16, Dan Cross wrote:
>>>>> In article <j71r42...@mid.individual.net>,
>>>>> Bill Gunshannon  <bill.gu...@gmail.com> wrote:
>>>>>> Maybe, but the push seems to be for virtualization and I saw a number
>>>>>> of OpenVMS job announcements that seemed to be production floor systems
>>>>>> which probably can't virtualized.
>>>>>
>>>>> Why not?  There are reasons to virtualize systems on-prem.
>>>>
>>>> I guess it depends on how you actually communicate with the
>>>> devices on the floor.  When I think of production floor systems
>>>> I think of cables between running machines and computers.
>>>> Probably my PDP-11 past seeping through.
>>>

>>> Our VMS production support system only talks over the network.
>>> Could just as well be in a VM as on the current Alpha.
>>>
>>
>> I thought of that afterwards. I guess a  lot of it today is PLC's
>> talking to the bigger iron over the network.  But that just leaves
>> me wondering how one does realtime.
>
> Throw lots of hardware resources as the problem, and pray. That's what I
> usually see... Usually aided by the fact that a lot of situations isn't
> hard realtime.

I would expect the real time characteristics to depend on the OS
and the execution environment (read: if you want good real time
characteristics then avoid GC) not virtualization vs non-virtualization.

Assuming a type 1 (bare metal) hypervisor and no over-commitment of
resources (aka number CPU's in VM's <= physical CPU's present), then
I don't see how virtualization should be a problem.

Arne

[Jan-Erik Söderholm]

Right. We run "real time" against PLCs and have a round-trip time of
10-20 ms including the database processing in the Alpha VMS system.
I do not expect that to be higher in a (modern) VM x86 environment.

[Johnny Billquist]

Except of course if a packet is lost, which do happen. Then what?
How soon will it be detected and retransmitted? Using TCP or UDP?
Basically, throw lots of hardware on it, and pray? :-)
Or it's not really hard realtime. If things occasionally go wrong,
nothing really bad happens.

And Arne - I read the question as related to networks. Not hypervisors
or virtual machines. But of course, we could also talk about those. Yes,
GC is an obvious bad thing. But how do you ensure that something is
scheduled within some limit when a hypervisor is doing things behind the
scene? What about interrupts and processing that happen on the physical
machine. That will have an impact on scheduling of virtual machines. And
resources are more than just pure CPU. Memory and I/O can also cause
impacts that affect other virtual environments running on the same host.
Sure, if you make sure there are enough CPUs for each VM to have its
own, enough memory for each VM to ensure that they can run without
contention, and enough disks that each VM can have its own spindles,
then you can probably get close to ensured response times. But then you
are in fact actually having the number of machines again, and not
getting the economics of VMs, which are in fact designed to take
advantage of the fact that normally systems are not using all their
resources anyway, so you can share resources without negative impact.

Basically the same thing time sharing already did 50 years ago with
computers. Everyone don't need their own computer. Most of the time the
computer is just waiting on the user anyway, so the system can serve
someone else meanwhile. VMs just take it up another level. But nothing
really new.

Johnny

[Arne Vajhøj]

>> Right. We run "real time" against PLCs and have a round-trip time of
>> 10-20 ms including the database processing in the Alpha VMS system.
>> I do not expect that to be higher in a (modern) VM x86 environment.
>
> Except of course if a packet is lost, which do happen. Then what?
> How soon will it be detected and retransmitted? Using TCP or UDP?
> Basically, throw lots of hardware on it, and pray? :-)
> Or it's not really hard realtime. If things occasionally go wrong,
> nothing really bad happens.

For TCP the network software should detect and resend - for UDP the
application logic need to detect and resend.

Whether that delay is acceptable must depend on the specific case.

> And Arne - I read the question as related to networks. Not hypervisors
> or virtual machines.

Well - it sort of started with virtualization (Bill) but has drifted
to network.

> But of course, we could also talk about those. Yes,
> GC is an obvious bad thing. But how do you ensure that something is
> scheduled within some limit when a hypervisor is doing things behind the
> scene? What about interrupts and processing that happen on the physical
> machine. That will have an impact on scheduling of virtual machines. And
> resources are more than just pure CPU. Memory and I/O can also cause
> impacts that affect other virtual environments running on the same host.
> Sure, if you make sure there are enough CPUs for each VM to have its
> own, enough memory for each VM to ensure that they can run without
> contention, and enough disks that each VM can have its own spindles,
> then you can probably get close to ensured response times. But then you
> are in fact actually having the number of machines again, and not
> getting the economics of VMs, which are in fact designed to take
> advantage of the fact that normally systems are not using all their
> resources anyway, so you can share resources without negative impact.

It is obvious that one cannot share resources and not share resources at
the same time.

Not having to wait for shared resources means no over allocation of
resources.

But even with no over allocation then virtualization offers several
advantages in the form of increased flexibility:
- it just take a few minutes to provision a new system with whatever
resources needed instead of having to order new server hardware
- hardware upgrades are a lot easier when one can just install the
new hardware and then move the VM's over

Often there are even hardware resource savings. Because many system
require less resources than the smallest system the IT departments
favorite hardware pusher sell.

Arne

[Simon Clubley]

Interesting. That certainly looks like an Itanium full system emulator.

It's a pity that it's HP-UX specific. I also note it's not available
for download without a warranty/support contract unfortunately.

[Hans Bachner]

Simon Clubley schrieb am 16.02.2022 um 15:02:
> On 2022-02-15, Hans Bachner <ha...@bachner.priv.at> wrote:
>>
>> In fact, most of the emulators I have touched in the last few years
>> [disclaimer: my company is a Stromasys sales and support partner] run in
>> virtual machines. Some customers migrated older emulator versions
>> running on physical servers to current versions on virtual servers.
>
> How do you handle customers with Itanium systems who want to move
> away from physical Itanium hardware ?
>
> I know there are no free Itanium full system emulators, but are there
> any commercial Itanium full system emulation options I have missed ?

I'm not aware of an Itanium full system emulator.

What I am seeing is that (very few) customers who migrated their
software from Alpha to Itanium in the past now consider or even started
moving back to (emulated) Alphas because they can't wait for x86 to
become production ready or are reluctant to follow VSI's new licensing
policies.

Hans.

[Dave Froble]

Well, even with emulated Alphas, one still needs to work with VSI. Using some
old version of VMS with poor networking and other issues is a dead end. While
some uses really don't need anything new, it's still a dead end.

What is needed is better communications and terms with VSI. Whether VSI will be
reasonable is a question. Unless their goal is to milk a few VMS users that
don't have other options, or to hold onto more VMS users, or to get new VMS
customers, what will actually happen remains to be seen.


--
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

[dthi...@gmail.com]

>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.

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.

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.

In the same vein, neither HPE nor VSI have upgraded the C and C++ compilers to the latest ANSI/ISO language standards, which is delaying VSI's efforts to port the latest versions of C++ and LLVM on X86_64.

While I fully understand and agree with VSI's priority of 1) Stabilizing and rebranding the Alpha and Integrity code base, 2) Porting OpenVMS to X86_64, and then 3) modernizing the compilers (and hopefully tool chains), you have to wonder how much further they would be in the port and how many less customers would have been lost if compiler development efforts had been accelerated in parallel.

Kudos to VSI's backers for providing the financial support to start and keep VSI running since 2014. It took HP Non-Stop 10 years to port to X86_64, as they proudly announced to Encompass in an all-Non-Stop issue of the magazine. Let's hope VSI can beat that porting time, before we lose even more of the mostly loyal OpenVMS customer base.

Also Kudos to VSI for trying to modernize OpenVMS development environment just a bit in the interim with the VMS IDE.

[David Wade]

In commercial terms "being reasonable" roughly translates as "can we
make enough profit to justify the investment". VSI is a business not a
charity.

For the users who "really don't need anything new" the question is
"should we invest in VMS or in some other modern platform"

I suspect for many businesses switching to a modern platform is very
attractive as it allows skills sets to be rationalized and avoids
problems later.

Does that amounts to "milking those who have no option"? You might see
it like that, or, as I am sure VSI do "thats the only way we can keep
supporting VMS and make a profit".

Dave

[John Dallman]

In article <sujkmf$ba7$3...@dont-email.me>,

clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> Interesting. That certainly looks like an Itanium full system
> emulator.
>
> It's a pity that it's HP-UX specific. I also note it's not available
> for download without a warranty/support contract unfortunately.

Showed up on another newsgroup today:

LLBT: an LLVM-based static binary translator, 2012
https://dl.acm.org/doi/abs/10.1145/2380403.2380419

"... translates source binary into LLVM IR and then retargets the LLVM IR
to various ISAs by using the LLVM compiler... from ARMv5 to Intel IA32,
Intel x64, MIPS, and other ARMs such as ARMv7"

John

[Phillip Helbig (undress to reply)]

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?

[Arne Vajhøj]

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

[Arne Vajhøj]

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.

> 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.

> 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.

I am slightly surprised that you say Fortran shops embracing OO - I
would sort of have expected most of them to keep existing code
in Fortran but do new stuff not tightly integrated with old stuff
in a different language likely OO.

Arne

[Bill Gunshannon]

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,

>
>> 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?

>
>> 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.
>
> I am slightly surprised that you say Fortran shops embracing OO - I
> would sort of have expected most of them to keep existing code
> in Fortran but do new stuff not tightly integrated with old stuff
> in a different language likely OO.

I was going to comment on this but didn't. Now, however, I will
once again point out that OOP is not a universal panacea. every
thing is not an object. And sometimes the older paradigms are
actually better for the task at hand.

bill

[Arne Vajhøj]

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.

>>> 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.
>>
>> I am slightly surprised that you say Fortran shops embracing OO - I
>> would sort of have expected most of them to keep existing code
>> in Fortran but do new stuff not tightly integrated with old stuff
>> in a different language likely OO.
>
> I was going to comment on this but didn't.  Now, however, I will
> once again point out that OOP is not a universal panacea.  every
> thing is not an object.  And sometimes the older paradigms are
> actually better for the task at hand.

The benefits of OO are pretty widely accepted. And almost everything
can be considered an object.

OOP is obviously not the only valuable approach, but if looking at
the OOP languages actually used then they are usually multi-paradigm:
- practically all support procedural programming
- most support functional programming
- most support generic programming

So it is not like the use of one of those languages only work
if everything is OOP centric - it makes sense if just some of it
is OOP centric.

Arne

[Phillip Helbig (undress to reply)]

In article <620e5870$0$701$1472...@news.sunsite.dk>,

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:

> 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.

Better late than never. :-|

But the equivalent of the Alpha compiler (essentially F95) will be on
x86 from the start?

[Arne Vajhøj]

I believe the I64 hosted cross-compiler is already available
and the native hosted version will be available end of year.

At least that was the message VSI put out last year.

Arne

[Dave Froble]

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.

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"?

I'm not against progress, valuable new things and capabilities. But change,
just for the sake of change, maybe not.

[Simon Clubley]

On 2022-02-17, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 2/17/2022 9:42 AM, Bill Gunshannon wrote:
>>
>> I was going to comment on this but didn't.  Now, however, I will
>> once again point out that OOP is not a universal panacea.  every
>> thing is not an object.  And sometimes the older paradigms are
>> actually better for the task at hand.
>
> The benefits of OO are pretty widely accepted. And almost everything
> can be considered an object.
>

DEC certainly thought so back in the middle/late 1980s.

> OOP is obviously not the only valuable approach, but if looking at
> the OOP languages actually used then they are usually multi-paradigm:
> - practically all support procedural programming
> - most support functional programming
> - most support generic programming
>
> So it is not like the use of one of those languages only work
> if everything is OOP centric - it makes sense if just some of it
> is OOP centric.
>

And this is nothing new. Mica was going to be an object based OS,
but the objects could still be used with procedural languages.

[Arne Vajhøj]

> 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.

Sometimes the decision is to migrate. Sometimes the decision is
not to migrate.

Not to migrate is probably the most common.

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.

> 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.

Arne

[Chris Townley]

Interesting interpolation!

--
Chris

[Bill Gunshannon]

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. :-)

bill

[Bill Gunshannon]

On 2/17/22 14:01, Simon Clubley wrote:
> On 2022-02-17, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/17/2022 9:42 AM, Bill Gunshannon wrote:
>>>
>>> I was going to comment on this but didn't.  Now, however, I will
>>> once again point out that OOP is not a universal panacea.  every
>>> thing is not an object.  And sometimes the older paradigms are
>>> actually better for the task at hand.
>>
>> The benefits of OO are pretty widely accepted. And almost everything
>> can be considered an object.
>>
>
> DEC certainly thought so back in the middle/late 1980s.

Probably a bad example. Look where it took them. :-)

>
>> OOP is obviously not the only valuable approach, but if looking at
>> the OOP languages actually used then they are usually multi-paradigm:
>> - practically all support procedural programming
>> - most support functional programming
>> - most support generic programming
>>
>> So it is not like the use of one of those languages only work
>> if everything is OOP centric - it makes sense if just some of it
>> is OOP centric.
>>
>
> And this is nothing new. Mica was going to be an object based OS,
> but the objects could still be used with procedural languages.
>
> Simon.
>

bill

[Simon Clubley]

On 2022-02-17, Bill Gunshannon <bill.gu...@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.

[Bill Gunshannon]

On 2/17/22 14:50, Simon Clubley wrote:
> On 2022-02-17, Bill Gunshannon <bill.gu...@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

[Arne Vajhøj]

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

[Dan Cross]

In article <j77mkg...@mid.individual.net>,

Bill Gunshannon <bill.gu...@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.

[Dave Froble]

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.

[Dave Froble]

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

[Dave Froble]

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.

[JP DEMONA]

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".

[Arne Vajhøj]

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

[Dan Cross]

In article <sumfka$spd$1...@dont-email.me>,

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.

[Arne Vajhøj]

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

[Dan Cross]

In article <sumf59$j67$1...@dont-email.me>,

Dave Froble <da...@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.

[Arne Vajhøj]

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

[Dan Cross]

In article <620ec8dc$0$697$1472...@news.sunsite.dk>,

Arne Vajhøj <ar...@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.

[Arne Vajhøj]

On 2/17/2022 5:15 PM, Dan Cross wrote:
> In article <sumfka$spd$1...@dont-email.me>,
> Dave Froble <da...@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

[Bill Gunshannon]

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

[Dave Froble]

That might depend upon what's being counted.

Total amount of work being done.

or

Total CPUs/computers sold.

[Bill Gunshannon]

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

bill

[John Reagan]

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

[Dan Cross]

In article <620e5870$0$701$1472...@news.sunsite.dk>,

Arne Vajhøj <ar...@vajhoej.dk> 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.

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.

[Arne Vajhøj]

On 2/18/2022 10:12 AM, Dan Cross wrote:
> In article <620e5870$0$701$1472...@news.sunsite.dk>,
> Arne Vajhøj <ar...@vajhoej.dk> 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.
>
> 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

[Dan Cross]

In article <sumv2s$fav$1...@dont-email.me>,

Dave Froble <da...@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.

[Arne Vajhøj]

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

[Dan Cross]

In article <j7844n...@mid.individual.net>,

Bill Gunshannon <bill.gu...@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.

[Dan Cross]

In article <620fb853$0$693$1472...@news.sunsite.dk>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2022 10:12 AM, Dan Cross wrote:
>> In article <620e5870$0$701$1472...@news.sunsite.dk>,
>> Arne Vajhøj <ar...@vajhoej.dk> 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.
>>
>> 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.

[Arne Vajhøj]

On 2/18/2022 10:59 AM, Dan Cross wrote:
> In article <620fb853$0$693$1472...@news.sunsite.dk>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/18/2022 10:12 AM, Dan Cross wrote:
>>> In article <620e5870$0$701$1472...@news.sunsite.dk>,
>>> Arne Vajhøj <ar...@vajhoej.dk> 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.
>>>
>>> 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

[John Dallman]

In article <suod1l$qrm$1...@reader1.panix.com>,
cr...@spitfire.i.gajendra.net (Dan Cross) wrote:

> Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >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.)

/VSI are not DEC./ They have pretty limited resources, and need to
concentrate on the critical things for their business plan.

ARM and RISC-V server hardware will be better and more readily available
in a few years' time. Those platforms can wait.

John

[David Wade]

It doesn't really matter what they "say", what is important is source
code compatibility. From what I can see the LLVM compiler does not fully
support the DEC extensions there may be issues.

If you need to make changes to stay on VMS then it becomes much harder
to justify it.

>>> 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
>
>

Dave

[Arne Vajhøj]

I think I got that one worded wrong.

VSI use LLVM backend on x86-64.

They use their traditional frontend accepting DEC extensions.

I don't think they have announced what they will do for Fortran/flang
but based on their general direction, then my guess is two compilers:
- Traditional Fortran support Fortran 95 with all DEC extensions aka
100% copmpatible
- flang with uptodate Fortran support and whatever DEC extensions
John Reagan can easily put in aka 98% compatible

Arne

[Simon Clubley]

On 2022-02-18, Dan Cross <cr...@spitfire.i.gajendra.net> wrote:
> In article <620e5870$0$701$1472...@news.sunsite.dk>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>
>>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 GEM was unfortunately the only part of MICA to survive.

However, times move on and the VMS language support is massively behind
the times these days. By moving to LLVM, VSI gets the best of both
worlds, with the GEM to LLVM interface to support the existing GEM
compiler frontends and VMS also gets access to the native LLVM frontends
(clang, etc).

Moving to LLVM is the logical thing for VSI to do.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Bill Gunshannon]

On 2/18/22 10:49, Dan Cross wrote:
> In article <j7844n...@mid.individual.net>,
> Bill Gunshannon <bill.gu...@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?

Yes.

> What are their
> reasons and, more importantly, why aren't those reasons factual?

Because the reason usually given is that COBOL is dead and that
what little COBOL code is left is rapidly being re-written in
Java. A statement totally unfounded. Two recent independent
surveys of companies using COBOL pegged the number of lines of
of existing COBOL code in production running every day at about
800 billion. And also contrary to popular belief among academics
more new code is being written every day.

>
>>> 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.

Yes, but when one learns COBOL in University that is not the only
thing e=they learn. (Well, at least not in a decent University.
I once new a grad from RPI who bragged that he never took any
course other than his engineering and math to get his degree!)
My degree has three concentrations. Comp Sci, Theology and
German. And, believe it or not my Comp Sci concentration
included more Comp Sci course than a Comp Sci Major.

On a side note to your comment above. Congratulations. You are
carrying on an argument that has been going quite steady since at
least 1850. With the backing of people like John Henry Newman
college education was opened up the common man and not just the
gentleman. But the argument still rages on. I worked for
nearly 30 years at a Jesuit University. We went thru a "Self
Examination" where other Jesuits came in to evaluate our work
to see if we were meeting the Jesuit goals for education. We
had one of our examiners (makes me think of the Inquest) who
came right out and said, "Computer Science is a trade and Jesuit
Schools should not be teaching it." Interestingly enough he
was from Georgetown which is famous for turning out lawyers.
Like that's not a trade.

>
>>> 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?

Who wrote which? The original was by Shelly & Cashman. that
was 40 years ago. They are still at it but now it's mostly
Windows Applications like MSOffice. there used to be a Wiki
that even said they were professional textbook writers but I
can't find it at the moment. :-) The others I bought on my
own were references written bu current (at the time) practitioners
of the art. I could find their names as I still have the 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.

That is true. The Murach series are very good although they
are primarily targeted at IBM Mainframe programming. But they
still make excellent desktop references.

>
>>
>>> 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.

I may, but I have learned from experience that it is a lot
more work than most people probably think. And in the
current atmosphere there is very little chance of actually
getting a publisher. O'Reilly seems to be gone.

>
>>> 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.

It goes much deeper than just abandoning curricula. In most
places (at least on my side of the pond) they very vocally
attack it and put in a lot of effort steering students away
from even looking at it.

>
> 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.

I agree up to a point. Other than in a compiler or computer languages
course I agree one could forego actually teaching COBOL in depth. But
then, our last course to use COBOL (and the only one to teach it) was
not really about "programming" at all. It was called File Processing
and COBOL was by far the right language for the job.

>
> 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.

But you have only addressed Comp Sci. There is another side to the
practice. And, like most schools that teach Comp Sci we also had a
degree program called Computer Information Systems. And the specific
target of this is the use of computers in business. Exactly where the
teaching of COBOL as one of the primary languages would have remained.
But it didn't. I once spoke with the IT director for a Fortune 100
Insurance company and told him one of our most distinguished and
experienced professors was telling his students that this company
was re-writing all their COBOL into Java. He was rolling on the
floor laughing. But that is the reality of the situation.

>
>>>> 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;

Actually, they are. Or don't you think future earnings plays a part
in deciding what to study? Well, I guess, sadly, in some cases it
might not. Thus the student loan fiasco. Hard to pay back that loan
when you studied something that doesn't lead to a good paying job
(or in some cases any job!)

> 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?

Copy and paste what? Is that how you see software maintenance?
Or new development? Admittedly, it was probably COBOL with
IT departments maintaining Source Libraries that led the way
for "code re-usability" which was supposed to be one of the
hallmarks for Ada but that hardly equates to copy & paste.

> Most of the COBOL work has been
> outsourced,

Another meaningless industry buzzword. Outsourced to who? I mean
I mentioned GDIT handling a big DOD COBOL system. Is that what you
call "outsourced"? I call it government contracting. :-) Most of
the banks, insurance, financial and credit card companies who are
all still COBOL shops don't outsource. They keep their IT operations
very close at hand.

> and you can't force students to want to learn COBOL.

You don't have to force them to learn. All you have to do is
not go out of your way to discourage it and make the material
available. I used to sit and talk with my students in the labs.
Many of them would have been happy to learn COBOL. Heck, I had
one who learned APL. Not much call for that in the real world
today and certainly was no one pushing it at the University. He
got involved through an internship with a brokerage firm who's
entire in house operations were done in APL. And they had no
intentions to ever re-write it.

> As a fraction of overall computing, the demand for COBOL
> programmers, at least in the United States, is small.

On what do you base this assumption?

>
> 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.

While I think they should still be taught in colleges, I expect if
anything it will fall to the trade schools much to the eventual
dismay of the colleges. Both sides will loose.

>
>> 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.

Your idea of what a University should be is very far from the
reality of things as they have been for 2 centuries. I would
be very interested in where you went to school. Even the
Jesuits who are primarily and mostly interested in Liberal
Arts wouldn't share your opinion. (Well, most of them anyway!)

bill

[Dave Froble]

On 2/18/2022 10:12 AM, Dan Cross wrote:

> In article <620e5870$0$701$1472...@news.sunsite.dk>,

> Arne Vajhøj <ar...@vajhoej.dk> 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.
>
> 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?

VAX, Alpha, and itanic are not VSI's future.

> 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.
>

[Dan Cross]

In article <620fc42f$0$701$1472...@news.sunsite.dk>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2022 10:59 AM, Dan Cross wrote:
>>>> 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.

...at the hidden cost of maintain two separate toolchains
for different architectures, and maintaining common code in
a least-common-denominator dialect of the language, at
least until they cut Alpha and Itanium loose completely.

>[snip]

>>> 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.

Which is why they should get a jump on things now. :-)

- Dan C.

[Dan Cross]

In article <620fdedb$0$704$1472...@news.sunsite.dk>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2022 12:41 PM, David Wade wrote:
>> On 18/02/2022 16:07, Arne Vajhøj wrote:
>>> On 2/18/2022 10:59 AM, Dan Cross wrote:
>>>> 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.
>>
>> It doesn't really matter what they "say", what is important is source
>> code compatibility. From what I can see the LLVM compiler does not fully
>> support the DEC extensions there may be issues.
>>
>> If you need to make changes to stay on VMS then it becomes much harder
>> to justify it.
>
>I think I got that one worded wrong.
>
>VSI use LLVM backend on x86-64.

Ah, that's rather differnet, and makes a lot more sense.

- Dan C.

[Dan Cross]

In article <suot6g$uus$1...@dont-email.me>,

Dave Froble <da...@tsoft-inc.com> wrote:
>On 2/18/2022 10:12 AM, Dan Cross wrote:
>> In article <620e5870$0$701$1472...@news.sunsite.dk>,
>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> And since it will be LLVM based then it must be x86-64 only.
>>
>> Why do you say that?
>
>VAX, Alpha, and itanic are not VSI's future.

Undoubtedly, but I wasn't suggesting that it was.
My comment was motivated by an apparent statement
that LLVM == x86. It does not.

- Dan C.

[Arne Vajhøj]

On 2/18/2022 7:07 PM, Dan Cross wrote:
> In article <620fc42f$0$701$1472...@news.sunsite.dk>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/18/2022 10:59 AM, Dan Cross wrote:
>>>>> 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.
>
> ...at the hidden cost of maintain two separate toolchains
> for different architectures, and maintaining common code in
> a least-common-denominator dialect of the language, at
> least until they cut Alpha and Itanium loose completely.

I think they are reusing what they can.

Based on presentations the model for existing compilers are:

(source)--common frontend--(GEM IR)--GEM--(Alpha/Itanium code)

(source)--common frontend--(GEM IR)--G2L--(LLVM IR)--LLVM--(x86-64 code)

>>>> 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.
>
> Which is why they should get a jump on things now. :-)

If they had enough resources, but VSI is a relative small company.

Arne

[Dan Cross]

In article <j7a9d8...@mid.individual.net>,

Bill Gunshannon <bill.gu...@gmail.com> wrote:
>On 2/18/22 10:49, Dan Cross wrote:
>>> 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?
>
>Yes.

Well, that's an opinion.

>> What are their
>> reasons and, more importantly, why aren't those reasons factual?
>
>Because the reason usually given is that COBOL is dead and that
>what little COBOL code is left is rapidly being re-written in
>Java. A statement totally unfounded. Two recent independent
>surveys of companies using COBOL pegged the number of lines of
>of existing COBOL code in production running every day at about
>800 billion. And also contrary to popular belief among academics
>more new code is being written every day.

I don't know any academics who think that COBOL is dead. But
I also don't know any academics who think about COBOL much at
all.

Everyone who's paying any attention knows there's oodles of
COBOL out there, much of which is quite important.

>>>> 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.
>
>Yes, but when one learns COBOL in University that is not the only
>thing e=they learn. (Well, at least not in a decent University.
>I once new a grad from RPI who bragged that he never took any
>course other than his engineering and math to get his degree!)
>My degree has three concentrations. Comp Sci, Theology and
>German. And, believe it or not my Comp Sci concentration
>included more Comp Sci course than a Comp Sci Major.

But that begs the question: why should _COBOL_ be part of
the cirriculum?

>On a side note to your comment above. Congratulations. You are
>carrying on an argument that has been going quite steady since at
>least 1850. With the backing of people like John Henry Newman
>college education was opened up the common man and not just the
>gentleman. But the argument still rages on.

Incorrect; that's an argument over _who_ should be elligible
for higher education, which I made no statement about. What
we're discussing here is _what_ should be taught in a college
education. You evidently feel that COBOL should be taught.
I can't see much of an argument for that. There's a lot of
COBOL out there, sure; so what? There's a lot of Visual Basic,
and a lot of JavaScript. Probably more HTML is generated on
a daily basis than all COBOL in the world combined. Should
HTML feature in a college education? How about CSS? Etc.
Should universities teach carpentry, plumbing or iron work?
These are all important things; what is the domain of a
university and what is not?

I'd rather that a university education teach fundamentals;
specific skills can be learned in industry.

>I worked for
>nearly 30 years at a Jesuit University. We went thru a "Self
>Examination" where other Jesuits came in to evaluate our work
>to see if we were meeting the Jesuit goals for education. We
>had one of our examiners (makes me think of the Inquest) who
>came right out and said, "Computer Science is a trade and Jesuit
>Schools should not be teaching it." Interestingly enough he
>was from Georgetown which is famous for turning out lawyers.
>Like that's not a trade.

I'm sure I must have heard something about knife fights
with Jesuits somehwere along the way.

>>> 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?
>
>Who wrote which? The original was by Shelly & Cashman. that
>was 40 years ago. They are still at it but now it's mostly
>Windows Applications like MSOffice. there used to be a Wiki
>that even said they were professional textbook writers but I
>can't find it at the moment. :-) The others I bought on my
>own were references written bu current (at the time) practitioners
>of the art. I could find their names as I still have the books.

It's funny, but I've used "textbooks" written by practitioners.
But at this level, we're arguing semantics about what it means
to be a textbook, which is not useful. The point was whether
high quality texts exist suitable for use in a university (or
other) course.

>> 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.
>
>That is true. The Murach series are very good although they
>are primarily targeted at IBM Mainframe programming. But they
>still make excellent desktop references.

Good to go, then. We're in that venerable state of "violent
agreement" on this point.

>>>> 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.
>
>I may, but I have learned from experience that it is a lot
>more work than most people probably think. And in the
>current atmosphere there is very little chance of actually
>getting a publisher. O'Reilly seems to be gone.

I don't know; if there's a market, then someone will publish.
O'Reilly does indeed seem to be out to lunch, but the Rust book
was amazingly good. Like, early-90s O'Reilly quality.

>> 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.
>
>It goes much deeper than just abandoning curricula. In most
>places (at least on my side of the pond) they very vocally
>attack it and put in a lot of effort steering students away
>from even looking at it.

I know a lot of academics and I don't think I've ever heard them
discuss COBOL, either for or against. I don't think there's some
cabal of Univeristy professors conspiring to keep COBOL down.

>> 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.
>
>I agree up to a point. Other than in a compiler or computer languages
>course I agree one could forego actually teaching COBOL in depth. But
>then, our last course to use COBOL (and the only one to teach it) was
>not really about "programming" at all. It was called File Processing
>and COBOL was by far the right language for the job.

Perhaps it would be appropriate to mention in a survey course on
programming language design; there's a lot of useful history there.
For an undergraduate course on compilers, I'd tend towards something
that was easy to parse and had reasonable semantics, so as not to
muddy the topic with too much detail about particular languages.

>> 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.
>
>But you have only addressed Comp Sci. There is another side to the
>practice. And, like most schools that teach Comp Sci we also had a
>degree program called Computer Information Systems. And the specific
>target of this is the use of computers in business. Exactly where the
>teaching of COBOL as one of the primary languages would have remained.
>But it didn't. I once spoke with the IT director for a Fortune 100
>Insurance company and told him one of our most distinguished and
>experienced professors was telling his students that this company
>was re-writing all their COBOL into Java. He was rolling on the
>floor laughing. But that is the reality of the situation.

I have no real experience with CIS; sorry. If there are
professors there poo-pooing COBOL, well, I guess they probably
shouldn't. For that matter, I'm not a computer scientist; I
was trained as a mathematician.

It does strike me that perhaps, in this case, the IT director
should spend less time on the floor and more time talking with
the professor, and the professor should come out of the ivory
tower every now and again. But most of the faculty I interact
with these days have fingers in industry and know the score
for real; but I'm not a business person.

>> Probably because the need appears less pressing than reality
>> might indicate, but again, universities aren't vocational
>> training schools;
>
>Actually, they are. Or don't you think future earnings plays a part
>in deciding what to study?

I'll ask you to please not put words in my mouth, thank you.
I try hard not to do that to others, and hope they'll reciprocate.

>Well, I guess, sadly, in some cases it
>might not. Thus the student loan fiasco. Hard to pay back that loan
>when you studied something that doesn't lead to a good paying job
>(or in some cases any job!)

Again, my view is that a university education should teach
techniques, not specific technologies. The technologies can
probably be picked up on the job as needed. If a competent
computer science graduate can't absorb COBOL in a few months,
then their education has failed them.

>> 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?
>
>Copy and paste what? Is that how you see software maintenance?

Again, please don't put words in my mouth. I don't do that
to you (I hope) and request the same courtesy in return.

>Or new development? Admittedly, it was probably COBOL with
>IT departments maintaining Source Libraries that led the way
>for "code re-usability" which was supposed to be one of the
>hallmarks for Ada but that hardly equates to copy & paste.

What I mean specifically is the danger of "PERFORM ... THRU ..."
style statements. In a large code base, this makes it very
difficult to determine what is invoked from where; in that
sort of environment (and I fully acknowledge that I'm
speculating here) it may be safer to simply copy a section
of code, and modify the copy to fit some new specification,
then branch at an earlier descision point to either the new
or old code.

>> Most of the COBOL work has been
>> outsourced,
>
>Another meaningless industry buzzword. Outsourced to who? I mean

I suspect that even a lot of the fortune x*100 companies
outside to body shops in the BRIC countries.

>I mentioned GDIT handling a big DOD COBOL system. Is that what you
>call "outsourced"? I call it government contracting. :-) Most of
>the banks, insurance, financial and credit card companies who are
>all still COBOL shops don't outsource. They keep their IT operations
>very close at hand.

If that's the case, it's a pretty insular world. The average
age of COBOL programmers in the US is 55; that says something.

>> and you can't force students to want to learn COBOL.
>
>You don't have to force them to learn. All you have to do is
>not go out of your way to discourage it and make the material
>available.

I don't think I've seen anyong actively discourage COBOL in 25
years. For that matter, I don't know that I've seen anyone
actively discuss COBOL in 25 years, either.

>I used to sit and talk with my students in the labs.
>Many of them would have been happy to learn COBOL. Heck, I had
>one who learned APL. Not much call for that in the real world
>today and certainly was no one pushing it at the University. He
>got involved through an internship with a brokerage firm who's
>entire in house operations were done in APL. And they had no
>intentions to ever re-write it.

I'm sure some students would want to learn it on general principle,
and that's great. Same thing with APL, RPG, MUMPS, FORTRAN-77,
UCSD Pascal, and GW-BASIC. I don't think that should be
discouraged; I've found that having breadth in technology gives
useful perspective. I also briefly looked up COBOL jobs in my
area (greater Boston) and the salaries are not competitive. I'm
pretty senior, but still; if people think it's oh-so-important
to attract COBOL programmers, then show me the money: it's not
there.

>> As a fraction of overall computing, the demand for COBOL
>> programmers, at least in the United States, is small.
>
>On what do you base this assumption?

Active job listings in my area. Availability of training
environments, materials, and high-quality open source implementations
and tools.

>> 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.
>
>While I think they should still be taught in colleges, I expect if
>anything it will fall to the trade schools much to the eventual
>dismay of the colleges. Both sides will loose.

Why is that a loss? In my opinion, we're practically forcing
too many kids to go to 4 year colleges when they're not really
all that interested in doing so, and then we're saddling them
with crippling debt after they get out. Part of this is a
level of social contempt for trades; that's very sad. When I
was in the Marine Corps, I worked with a lot of folks who went
into the trades and they were intelligent, motivated, hard-working,
genuinely wonderful people. They shouldn't be penalized or
disrespected for not having a burning desire to deconstruct
Baudrillard.

>>> 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.
>
>Your idea of what a University should be is very far from the
>reality of things as they have been for 2 centuries. I would
>be very interested in where you went to school.

I went to Columbia.

>Even the
>Jesuits who are primarily and mostly interested in Liberal
>Arts wouldn't share your opinion. (Well, most of them anyway!)

I wonder if, perhaps, your interpretation of my idea is
incompatible with what the Jesuits might say, regardless
of what my idea actually is.

- Dan C.

[Bill Gunshannon]

On 2/19/22 21:07, Dan Cross wrote:
> In article <j7a9d8...@mid.individual.net>,
> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> On 2/18/22 10:49, Dan Cross wrote:
>>>> 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?
>>
>> Yes.
>
> Well, that's an opinion.

Maybe, but an opinion based on almost 30 years in academia right thru
the time when all this happened.

>
>>> What are their
>>> reasons and, more importantly, why aren't those reasons factual?
>>
>> Because the reason usually given is that COBOL is dead and that
>> what little COBOL code is left is rapidly being re-written in
>> Java. A statement totally unfounded. Two recent independent
>> surveys of companies using COBOL pegged the number of lines of
>> of existing COBOL code in production running every day at about
>> 800 billion. And also contrary to popular belief among academics
>> more new code is being written every day.
>
> I don't know any academics who think that COBOL is dead. But
> I also don't know any academics who think about COBOL much at
> all.

Then you must not know many currently teaching at American
Universities.

>
> Everyone who's paying any attention knows there's oodles of
> COBOL out there, much of which is quite important.

Then why do you think colleges all removed COBOL from their curriculum?

>
>>>>> 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.
>>
>> Yes, but when one learns COBOL in University that is not the only
>> thing e=they learn. (Well, at least not in a decent University.
>> I once new a grad from RPI who bragged that he never took any
>> course other than his engineering and math to get his degree!)
>> My degree has three concentrations. Comp Sci, Theology and
>> German. And, believe it or not my Comp Sci concentration
>> included more Comp Sci course than a Comp Sci Major.
>
> But that begs the question: why should _COBOL_ be part of
> the cirriculum?

Because it is a skill needed badly in the real world and up until
about two decades ago they had no problem filling that need.

>
>> On a side note to your comment above. Congratulations. You are
>> carrying on an argument that has been going quite steady since at
>> least 1850. With the backing of people like John Henry Newman
>> college education was opened up the common man and not just the
>> gentleman. But the argument still rages on.
>
> Incorrect; that's an argument over _who_ should be elligible
> for higher education, which I made no statement about. What
> we're discussing here is _what_ should be taught in a college
> education. You evidently feel that COBOL should be taught.
> I can't see much of an argument for that. There's a lot of
> COBOL out there, sure; so what? There's a lot of Visual Basic,
> and a lot of JavaScript. Probably more HTML is generated on
> a daily basis than all COBOL in the world combined. Should
> HTML feature in a college education? How about CSS? Etc.

Well, they do teach CSS and HTML and PHP and JavaScript.
Visual Basic not so much any more, but they did teach that,
too.

> Should universities teach carpentry, plumbing or iron work?

Some colleges do, believe it or not. We have at least one locally.
Used to be a trade school. Now it's a college. In a few years if
it grows any more it will likely be a University.

> These are all important things; what is the domain of a
> university and what is not?

Primarily, since at least the early 1900's it has been to
educate white collar workers as well as the educated wealthy
who have no intention of getting a job anyway. (One of my
high school classmates started college right after high school.
He got an undergrad engineering degree. then he got an undergrad
Math degree. Then he got an undergrad English degree. If he
had not been killed in an accident he would probably still be
acquiring undergrad degrees. :-)

>
> I'd rather that a university education teach fundamentals;
> specific skills can be learned in industry.

They do teach fundamentals. But unless you think that college
grads have no need of getting a job when they graduate they will
need to learn a lot more than just fundamentals and theory.

There are some. But the majority are written by professional
textbook writers or professors who have never held a real world
job. Neither of which I consider practitioners.

> But at this level, we're arguing semantics about what it means
> to be a textbook, which is not useful. The point was whether
> high quality texts exist suitable for use in a university (or
> other) course.

They do.

All of academia is a cabal. Just like a lot of the recent arguments
(that most people think are just politics) about "science" Comp Sci
goes the same way. Once a decision is made no one who plans on his
career as a professor continuing will buck them. One bad review on
a paper (or worse still refusal to even review your papers) and your
career is over. Publish or perish is alive and well.

>
>>> 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.
>>
>> I agree up to a point. Other than in a compiler or computer languages
>> course I agree one could forego actually teaching COBOL in depth. But
>> then, our last course to use COBOL (and the only one to teach it) was
>> not really about "programming" at all. It was called File Processing
>> and COBOL was by far the right language for the job.
>
> Perhaps it would be appropriate to mention in a survey course on
> programming language design; there's a lot of useful history there.

Yeah, we had one of them. Taught by one of the learned professors
who was against COBOL. The course called "Programming Languages"
did not mention it at all. It had the students look at and even
write programs Smalltalk and Prolog, both long dead, but failed to
even mention COBOL.

> For an undergraduate course on compilers, I'd tend towards something
> that was easy to parse and had reasonable semantics, so as not to
> muddy the topic with too much detail about particular languages.

Sadly, compiler courses are becoming scarce as well. My Department
dumped their last compiler course almost as long ago as COBOL.

>
>>> 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.
>>
>> But you have only addressed Comp Sci. There is another side to the
>> practice. And, like most schools that teach Comp Sci we also had a
>> degree program called Computer Information Systems. And the specific
>> target of this is the use of computers in business. Exactly where the
>> teaching of COBOL as one of the primary languages would have remained.
>> But it didn't. I once spoke with the IT director for a Fortune 100
>> Insurance company and told him one of our most distinguished and
>> experienced professors was telling his students that this company
>> was re-writing all their COBOL into Java. He was rolling on the
>> floor laughing. But that is the reality of the situation.
>
> I have no real experience with CIS; sorry. If there are
> professors there poo-pooing COBOL, well, I guess they probably
> shouldn't. For that matter, I'm not a computer scientist; I
> was trained as a mathematician.

A number of the professors when I was there had started as
Math Profs and took part in the formation of the Comp Sci
Dept. Did you ever here of Harlan Herrick? He was very
big in the creation of Fortran. He ended his career as a
professor in my Department. He's buried some where here
in Scranton.

>
> It does strike me that perhaps, in this case, the IT director
> should spend less time on the floor and more time talking with
> the professor,

Trust me, it was tried. The company involved used to pay for a
lot of their employees to take Grad classes from us. We had a
Software Engineering Masters Program. When the classes taught
stopped meeting their needs they stopped paying for their
employees to come.

> and the professor should come out of the ivory
> tower every now and again. But most of the faculty I interact
> with these days have fingers in industry and know the score
> for real; but I'm not a business person.

Well, personally, I don't think anyone should be allowed to be a
professor without first having real world experience with what
they plan to teach. Of the 12 Professors I worked with in my
department only two had ever held a job as anything other than
a professor. And one of those had only had one non-academic job.

I guess I just don't get your point with the PERFORM -- THRU
stuff. Don't see how that would differ from begin-end or {}
in other languages. But then, I was taught structured COBOL
from the beginning which stressed good program structure and
design as opposed to the spaghetti code that was common in the
day (and not just in COBOL or BASIC. I have seen some really
scary Fortran as well.)

>>> Most of the COBOL work has been
>>> outsourced,
>>
>> Another meaningless industry buzzword. Outsourced to who? I mean
>
> I suspect that even a lot of the fortune x*100 companies
> outside to body shops in the BRIC countries.

Funny thing about that is if you follow the COBOL world you would be
amazed at how little the locations we usually associate wit "out
sourcing" know of COBOL either.

>
>> I mentioned GDIT handling a big DOD COBOL system. Is that what you
>> call "outsourced"? I call it government contracting. :-) Most of
>> the banks, insurance, financial and credit card companies who are
>> all still COBOL shops don't outsource. They keep their IT operations
>> very close at hand.
>
> If that's the case, it's a pretty insular world. The average
> age of COBOL programmers in the US is 55; that says something.

Yeah, it says that replacements are hard to find and getting harder.
Something that will have to change because the code is not going away.

>
>>> and you can't force students to want to learn COBOL.
>>
>> You don't have to force them to learn. All you have to do is
>> not go out of your way to discourage it and make the material
>> available.
>
> I don't think I've seen anyong actively discourage COBOL in 25
> years.

I watched it for at least the last 15 years I worked at the University.

> For that matter, I don't know that I've seen anyone
> actively discuss COBOL in 25 years, either.

I used to do it all the time. And got good comments from the students
I talked with. Given the opportunity I am sure many of them would have
taken a COBOL course. But again, without a lot of support from the
faculty it would have been a non-starter. When your intent is to get
out of there in the four years allocated there is no room in your
schedule for even one extra 3 credit course.

>
>> I used to sit and talk with my students in the labs.
>> Many of them would have been happy to learn COBOL. Heck, I had
>> one who learned APL. Not much call for that in the real world
>> today and certainly was no one pushing it at the University. He
>> got involved through an internship with a brokerage firm who's
>> entire in house operations were done in APL. And they had no
>> intentions to ever re-write it.
>
> I'm sure some students would want to learn it on general principle,
> and that's great. Same thing with APL, RPG, MUMPS, FORTRAN-77,

MUMPS is still very much in use. Like COBOL you are probably
touched by it more times than you think.

> UCSD Pascal, and GW-BASIC. I don't think that should be
> discouraged; I've found that having breadth in technology gives
> useful perspective. I also briefly looked up COBOL jobs in my
> area (greater Boston) and the salaries are not competitive. I'm
> pretty senior, but still; if people think it's oh-so-important
> to attract COBOL programmers, then show me the money: it's not
> there.

Yeah, I keep hearing that. But then I go out and find 6 figure
COBOL jobs. The one thing I notice the most about these jobs
on places like Indeed and Monster (who pretty much have the
exact same jobs cause all they really do is scrape other places
websites) have "estimated pay" because most of the places that
use COBOL are old school and don't make that kind of igformation
public. And their "estimatees" seem to always be low balled. I
know this from looking at other jobs in fields and with companies
that I have first hand experience with.

>
>>> As a fraction of overall computing, the demand for COBOL
>>> programmers, at least in the United States, is small.
>>
>> On what do you base this assumption?
>
> Active job listings in my area.

Where you live can have a large effect on that. Where I live
the majority of computer jobs are low level Windows jobs. Sadly,
I have watched most of the better computer stuff get moved away.
A number of years ago Mellon Bank bought the biggest local bank.
First action was to move all Data Processing to Pittsburgh. Didn't
even offer the current employees here transfer opportunities.
Procter and Gamble has a large facility here. Mostly an HPUX
shop. While they are constantly hiring factory floor workers
from the local community they have never advertised for people
here to work with the real computers. All of those people are
hired in Cincinatti at HQ. They do have PC monkeys locally but
even the company with that contract is not local.

> Availability of training

That's the big problem. All the local colleges (and we have a good
dozen) used to teach COBOL. None of them do today.

> environments, materials, and high-quality open source implementations
> and tools.

Open Source? Take a look at GnuCOBOL. Full featured. Very stable.
Interfaces well to database systems (including Oracle the last I heard).
Has COBOL specific IDE's but others like Eclipse can handle COBOL as
well.

>
>>> 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.
>>
>> While I think they should still be taught in colleges, I expect if
>> anything it will fall to the trade schools much to the eventual
>> dismay of the colleges. Both sides will loose.
>
> Why is that a loss? In my opinion, we're practically forcing
> too many kids to go to 4 year colleges when they're not really
> all that interested in doing so, and then we're saddling them
> with crippling debt after they get out. Part of this is a
> level of social contempt for trades; that's very sad. When I
> was in the Marine Corps, I worked with a lot of folks who went
> into the trades and they were intelligent, motivated, hard-working,
> genuinely wonderful people. They shouldn't be penalized or
> disrespected for not having a burning desire to deconstruct
> Baudrillard.

There is a value to the liberal arts side of education which
one does not get in a trade school. The students loss.
There is money to be made teaching COBOL. The University's
loss. :-)

>
>>>> 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.
>>
>> Your idea of what a University should be is very far from the
>> reality of things as they have been for 2 centuries. I would
>> be very interested in where you went to school.
>
> I went to Columbia.

Like Georgetown, Columbia's primary function seemed to be turning out
white collar workers. Used to have quite the Comp Sci program there.
I had quite a bit of contact because of the Kermit project. Some
of the Kermit binaries were actually built on system's in my house
by Frank DaCruz. When I lived up at West Point I used to see football
from Columbia on Saturday mornings. Sometimes I was the only one
watching them play. :-)

>
>> Even the
>> Jesuits who are primarily and mostly interested in Liberal
>> Arts wouldn't share your opinion. (Well, most of them anyway!)
>
> I wonder if, perhaps, your interpretation of my idea is
> incompatible with what the Jesuits might say, regardless
> of what my idea actually is.

I have found that if you put 10 Jesuits in a room and asked for
the official standing on any subject you are most likely to get
15 different answers.


bill

[Dave Froble]

On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
> On 2/19/22 21:07, Dan Cross wrote:

Bit of a trim of the old stuff needed ...

To me, a university is there to teach a person how to think and learn.

When my son started school, he asked "what type of job should I learn to do?".
My reply was "You aren't going to learn a job. You're going there to learn how
to learn, and think, and to learn about the world that you haven't seen yet."

As to teaching Cobol, learning computer languages should be a part of
university, if the student chooses. I had a semester of Cobol when I was in
school, maybe 50 some years ago.

What I would not agree with is misinformation. If a professor is misleading
students based upon his/her own bias about how the world should be run, well,
that's dishonest, and it should be "former professor".

As for skills, to me is seems it always comes down to OJT. No school is going
to teach exactly what a particular employer needs. Some basics, and how to
learn, yes. Details, no.

As an example, I was taught about linked lists. I wasn't taught about what I
needed them for, that came later on the job. The school taught the concept, the
job taught the need and design.

[abrsvc]

David,

David,

An refreshing perspective that I share and rarely see. I got in "trouble" with the established professors when I was teaching at the college level years ago. I taught both FORTRAN and assembly language (Macro32 at the time) and my exams were not the usual "write a code segment to do this" type of test. My thoughts at the time were that nowhere in industry would you be given a directive like that. You would be given a task and the reference material available to assist in accomplishing that task. I concentrated more on how to resolve a problem by breaking it down into logical steps. In other words, how to think. In this fashion, the language syntax specifics were more details on how to make it happen rather than problem solving. I had many students return to tell me that their current employment used a different language but that they had no problems adapting to that language because syntax was easy to reference and use. The thought process was more important.

While I believe that languages such as Cobol should be offered and available, concentrating on how to solve a problem and exposing students to MANY language syntax variants is valuable too. Perhaps a course in language similarities and differences would be a good one. Show examples of the advantages of each language and the disadvantages too. Lets face it, some languages are not appropriate for some tasks.

Dan

[Bill Gunshannon]

On 2/20/22 00:17, Dave Froble wrote:
> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>> On 2/19/22 21:07, Dan Cross wrote:
>
> Bit of a trim of the old stuff needed ...
>
> To me, a university is there to teach a person how to think and learn.

That's definitely part of it. BUt, based on observing life around us
today, they appear to have abdicated the part about learning to think
as well as COBOL. :-) They do not teach yo how to learn. It is
pretty much assumed you got that in the schools before you got to
University.

>
> When my son started school, he asked "what type of job should I learn to
> do?".

Bad question. But then, that's probably why so many students end out
taking 5 to 6 years to get that degree because they really don;t know
why they are even there.

> My reply was "You aren't going to learn a job.  You're going there
> to learn how to learn, and think, and to learn about the world that you
> haven't seen yet."

And partly a wrong answer. Colleges are trade schools. They are
trade schools for the white collar class. Bankers, CPA's, chemists,
lawyers, future CEO's and yes, systems analysts (which is actually
a higher level programmer than today's buzzword, "coder".) You are
certainly not going to learn any of that in the local Vo/Tech or even
Community College.

>
> As to teaching Cobol, learning computer languages should be a part of
> university, if the student chooses.  I had a semester of Cobol when I
> was in school, maybe 50 some years ago.

50 years ago? What school and what degree program? Computers were in
their infancy in the University system in those days with only a couple
major colleges offering degrees in it.

>
> What I would not agree with is misinformation.  If a professor is
> misleading students based upon his/her own bias about how the world
> should be run, well, that's dishonest, and it should be "former professor".

But that is what too much of college has become, and especially in CS.
They are no longer satisfied with merely driving the bus they now want
to even tell the riders where they want to go.

>
> As for skills, to me is seems it always comes down to OJT.  No school is
> going to teach exactly what a particular employer needs.  Some basics,
> and how to learn, yes.  Details, no.

That's true up to a point. A new entry level job always includes OJT.
But there is an expectation that the candidate has basic skills for
the tasks they are expected to do. You don't start in the construction
business as a master carpenter but your boss expects you to know which
end of the hammer should strike the nail.

Again, we really come down to the CS/CIS difference. If one is going
for a CIS degree it is expected that they will come arrive at that
first job with the basic knowledge required by the job. That means
COBOL, Databases, including SQL programming, web concepts and probably
HTML, JavaScript and PHP and even UI concepts. They won't design and
code a shopping cart the first day, but they should understand what it
entails. Sadly, all of that is there except for the language needed
for the backend. For some, as yet never explained, reason that part
was dropped. And, the most interesting thing about it is how close
to each other they all dropped it. That is the stuff conspiracy
theories are built on. :-)

>
> As an example, I was taught about linked lists.  I wasn't taught about
> what I needed them for, that came later on the job.  The school taught
> the concept, the job taught the need and design.

Very true. I had been in the business for over 40 years before I
started taking classes for a degree (which I got 4 years before my
somewhat forced retirement!) I got to observe a lot of our upcoming
students in these classes. It was funny listening to chatter among
the Discrete Math students. "Why are we learning about nodes?
What is this Venn Diagram crap? Who cares about Linked Lists? I
just want to learn how to be a programmer." Of course, having done
this for 40 years I knew exactly how all this stuff fit in. Like
it or not, COBOL fits in the same way. It uses a paradigm not quite
the same as the procedural paradigm of Pascal or Ada. And the
students who plan to do this for a living should at least have the
basics under their belt before they hit that first job. At least
a 3 credit course although 6 credits would do them much better in
the real world.

Will it happen again? Who knows. But I am betting it won't happen
at the University level. Another major truism about the academic
world is they never admit to making a mistake. That would be a sign
of weakness.

bill

[Dave Froble]

On 2/20/2022 9:49 AM, Bill Gunshannon wrote:
> On 2/20/22 00:17, Dave Froble wrote:
>> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>>> On 2/19/22 21:07, Dan Cross wrote:
>>
>> Bit of a trim of the old stuff needed ...
>>
>> To me, a university is there to teach a person how to think and learn.
>
> That's definitely part of it. BUt, based on observing life around us
> today, they appear to have abdicated the part about learning to think
> as well as COBOL. :-) They do not teach yo how to learn. It is
> pretty much assumed you got that in the schools before you got to
> University.

Bad assumption. In secondary schools, and grade schools, one is taught facts.
One isn't taught to think much about the facts. After all, onme would need the
facts before being able to think about them. But at some time some more
abstract thought about the world around us is needed, and that should happen at
university. At least, that's how I see it.

>> When my son started school, he asked "what type of job should I learn to do?".
>
> Bad question.

I always say, there is no such thing as a bad question. If someone has a
question, that indicates he/she "doesn't know", and is trying to find out.
However, there can be bad answers.

> But then, that's probably why so many students end out
> taking 5 to 6 years to get that degree because they really don;t know
> why they are even there.

I believe David took 8 years before getting a degree in geology. And you are
correct, many don't know why they are there when going to university. A
university should help students at least partially figure out what they are doing.

>> My reply was "You aren't going to learn a job. You're going there to
>> learn how to learn, and think, and to learn about the world that you haven't
>> seen yet."
>
> And partly a wrong answer. Colleges are trade schools. They are
> trade schools for the white collar class. Bankers, CPA's, chemists,
> lawyers, future CEO's and yes, systems analysts (which is actually
> a higher level programmer than today's buzzword, "coder".) You are
> certainly not going to learn any of that in the local Vo/Tech or even
> Community College.
>
>>
>> As to teaching Cobol, learning computer languages should be a part of
>> university, if the student chooses. I had a semester of Cobol when I was in
>> school, maybe 50 some years ago.
>
> 50 years ago? What school and what degree program? Computers were in
> their infancy in the University system in those days with only a couple
> major colleges offering degrees in it.

I graduated from the University of Pittsburgh in 1973. At that time they didn't
have a CS major. My BS is in math.

>> What I would not agree with is misinformation. If a professor is misleading
>> students based upon his/her own bias about how the world should be run, well,
>> that's dishonest, and it should be "former professor".
>
> But that is what too much of college has become, and especially in CS.
> They are no longer satisfied with merely driving the bus they now want
> to even tell the riders where they want to go.

I may have mentioned over inflated egos in the past ...

>> As for skills, to me is seems it always comes down to OJT. No school is going
>> to teach exactly what a particular employer needs. Some basics, and how to
>> learn, yes. Details, no.
>
> That's true up to a point. A new entry level job always includes OJT.
> But there is an expectation that the candidate has basic skills for
> the tasks they are expected to do. You don't start in the construction
> business as a master carpenter but your boss expects you to know which
> end of the hammer should strike the nail.

Some idea of "how to do", yes, I agree. My CS minor included multiple languages
and subjects. I still remember toggling in a boot loader on the PDP-6. Cobol
and Fortran languages. But it was only on the job that I learned Basic.

[Dennis Boone]

> > As an example, I was taught about linked lists.  I wasn't taught about
> > what I needed them for, that came later on the job.  The school taught
> > the concept, the job taught the need and design.

> It was funny listening to chatter among the Discrete Math students.
> "Why are we learning about nodes? What is this Venn Diagram crap? Who
> cares about Linked Lists? I just want to learn how to be a programmer."

This is why Dave (above) is partly wrong. Stuff they try to teach you
in the abstract is likely to be "why do we need this?" and won't stick,
especially to typical college age kids.

You need to walk out with a handle on what it is, and how you use it,
and the general class of problems you're going to hit with it. If you
get some clue of how to read documentation and where to look for answers
and how to take problems apart in the general sense, and a toolkit full
of stuff like big-O and venn diagrams and linked lists and such, you'll
land on your feet when your boss hands you a deranged-ass task you've
never heard of before.

Or, you can walk out with barely enough skills to ask vague questions on
stackexchange and copypasta incorrect recipes, but get told you
shouldn't do that.

De

[Arne Vajhøj]

On 2/20/2022 12:17 AM, Dave Froble wrote:
> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>> On 2/19/22 21:07, Dan Cross wrote:
>
> Bit of a trim of the old stuff needed ...
>
> To me, a university is there to teach a person how to think and learn.
>
> When my son started school, he asked "what type of job should I learn to
> do?". My reply was "You aren't going to learn a job.  You're going there
> to learn how to learn, and think, and to learn about the world that you
> haven't seen yet."
>
> As to teaching Cobol, learning computer languages should be a part of
> university, if the student chooses.  I had a semester of Cobol when I
> was in school, maybe 50 some years ago.

> As for skills, to me is seems it always comes down to OJT.  No school is
> going to teach exactly what a particular employer needs.  Some basics,
> and how to learn, yes.  Details, no.
>
> As an example, I was taught about linked lists.  I wasn't taught about
> what I needed them for, that came later on the job.  The school taught
> the concept, the job taught the need and design.

Yes.

The software world is quite diverse when it comes to problem
domains, development methodologies, programming languages,
libraries and tools.

It is not realistic for an education to cover what is
going to be used.

Furthermore people will be working 40-45 years after
getting their degree.

Even if what they learn is actually used in their
first job, then it it unlikely to be used in their
last jobs.

They key is to learn to think the right way.

And I think it sort of get proved by the fact that
people with non-IT degrees like math, physics, chemistry,
astronomy etc. tend to get just as good software
developers as those with an IT degree in computer science
or software engineering.

So priorities:
1) Learn to think the right way
2) Learn the general stuff that keeps being relevant
about data structures, algorithms etc. "the Knuth stuff"
...
99) Learn some specific technologies needed by the industry last year.

What programming languages to learn is less important.

I will recommend at least 3 to get a broad perspective.

And they should of course be a bit different to achieve that goal, so:
- both static and dynamic types
- include procedural, object oriented, generic and functional
programming

Popular languages in education has changed over time.

Something like:

Pascal -> C -> C++ and Delphi -> Python, Java and C#

I don't think there is many aspects of Cobol that makes it
relevant in education.

Maybe for something including ISAM files.

Arne

[John Dallman]

In article <suttpa$1i1$1...@dont-email.me>, da...@tsoft-inc.com (Dave Froble)
wrote:

> Bad assumption. In secondary schools, and grade schools, one is
> taught facts. One isn't taught to think much about the facts.

> After all, one would need the facts before being able to think

> about them. But at some time some more abstract thought about the
> world around us is needed, and that should happen at university.
> At least, that's how I see it.

Over here, the political drive to send more of the 18+ age group to
university - up from 10% fifty years ago to 50% now - and the requirement
that most of them actually graduate has rather spoiled that. There wasn't
any corresponding drastic upgrade of secondary education. You get some
bright students at any university, and the highly selective ones have a
higher proportion, but there are a lot of graduates without much in the
way of thinking skills.

My employer selects for being quick at learning, plus decent mathematical
ability. We aren't at all bothered about existing programming skills. We
can teach someone enough programming in a month or so to put them to work.


John

[Arne Vajhøj]

On 2/18/2022 2:12 PM, Bill Gunshannon wrote:
> On 2/18/22 10:49, Dan Cross wrote:
>>                           Most of the COBOL work has been
>> outsourced,
>
> Another meaningless industry buzzword.  Outsourced to who?  I mean
> I mentioned GDIT handling a big DOD COBOL system.  Is that what you
> call "outsourced"?  I call it government contracting.  :-)  Most of
> the banks, insurance, financial and credit card companies who are
> all still COBOL shops don't outsource.  They keep their IT operations
> very close at hand.

JP Morgan, BoA, Wells Fargo, Citibank, Goldmann Sachs, Capital One
and State Street all get IT work done in India.

And it is generally assumed that Cobol work is very much outsourced
to India due to the common model of outsourcing maintenance of
older system and do development of the new systems closer to business.
And a quick check of skill demand seems to confirm it - in the US the
ratio of Cobol to Java jobs is like 1:50 while in India it is just 1:4.

Arne

[Bill Gunshannon]

On 2/20/22 12:29, Dave Froble wrote:
> On 2/20/2022 9:49 AM, Bill Gunshannon wrote:
>> On 2/20/22 00:17, Dave Froble wrote:
>>> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>>>> On 2/19/22 21:07, Dan Cross wrote:
>>>
>>> Bit of a trim of the old stuff needed ...
>>>
>>> To me, a university is there to teach a person how to think and learn.
>>
>> That's definitely part of it.  BUt, based on observing life around us
>> today, they appear to have abdicated the part about learning to think
>> as well as COBOL.  :-)  They do  not teach yo how to learn.  It is
>> pretty  much assumed you got that in the schools before you got to
>> University.
>
> Bad assumption.  In secondary schools, and grade schools, one is taught
> facts. One isn't taught to think much about the facts.  After all, onme
> would need the facts before being able to think about them.  But at some
> time some more abstract thought about the world around us is needed, and
> that should happen at university.  At least, that's how I see it.

I think a bit of confusion. Students learn how to learn before
University. Universities then present information and it is up
to the student to "learn". Professors really don't care if you
learn anything in their class. Not their responsibility. No one
gets individual attention. After all, if you don;t learn the
material the first time around you can always take the class again.

>
>>> When my son started school, he asked "what type of job should I learn
>>> to do?".
>>
>> Bad question.
>
> I always say, there is no such thing as a bad question.  If someone has
> a question, that indicates he/she "doesn't know", and is trying to find
> out. However, there can be bad answers.

There can certainly be bad questions. The question he should have been
asking is what do I want to do with my life. Asking someone else what
kind of job you should get just sets you up for disappointment and a
very stressful life. Learned from experience. :-)

>
>>  But then, that's probably why so many students end out
>> taking 5 to 6 years to get that degree because they really don;t know
>> why  they are even there.
>
> I believe David took 8 years before getting a degree in geology.  And
> you are correct, many don't know why they are there when going to
> university.  A university should help students at least partially figure
> out what they are doing.

Nope, not their job. They are not psychologists and they are not
guidance counselors (although my experience with them in high school
left much to be desired!) One should have made the decision about
what one is going to study even before they have picked the school
they are going to attend. Once you get there they can only recommend
what courses of study they offer. None of them may be the right fit
for any particular student.

>
>>>        My reply was "You aren't going to learn a job.  You're going
>>> there to
>>> learn how to learn, and think, and to learn about the world that you
>>> haven't
>>> seen yet."
>>
>> And partly a wrong answer.  Colleges are trade schools.  They are
>> trade schools for the white collar class.  Bankers, CPA's, chemists,
>> lawyers, future CEO's and yes, systems analysts (which is actually
>> a higher level programmer than today's buzzword, "coder".)  You are
>> certainly not going to learn any of that in the local Vo/Tech or even
>> Community College.
>>
>>>
>>> As to teaching Cobol, learning computer languages should be a part of
>>> university, if the student chooses.  I had a semester of Cobol when I
>>> was in
>>> school, maybe 50 some years ago.
>>
>> 50 years ago?  What school and what degree program?  Computers were in
>> their infancy in the University system in those days with only a couple
>> major colleges offering degrees in it.
>
> I graduated from the University of Pittsburgh in 1973.  At that time
> they didn't have a CS major.  My BS is in math.

Which is where most of the CS Departments came from. I am surprised
they offered COBOL, but then Pitt was at the forefront of CS and is
still a very good bet.

>
>>> What I would not agree with is misinformation.  If a professor is
>>> misleading
>>> students based upon his/her own bias about how the world should be
>>> run, well,
>>> that's dishonest, and it should be "former professor".
>>
>> But that is what too much of college has become, and especially  in CS.
>> They are no longer satisfied with merely driving the bus they now want
>> to even tell the riders where they want to go.
>
> I may have mentioned over inflated egos in the past ...
>
>>> As for skills, to me is seems it always comes down to OJT.  No school
>>> is going
>>> to teach exactly what a particular employer needs.  Some basics, and
>>> how to
>>> learn, yes.  Details, no.
>>
>> That's true up to a point.  A new entry level job always includes OJT.
>> But there is an expectation that the candidate has basic skills for
>> the tasks they are expected to do.  You don't start in the construction
>> business as a master carpenter but your boss expects you to know which
>> end of the hammer should strike the nail.
>
> Some idea of "how to do", yes, I agree.  My CS minor included multiple
> languages and subjects.  I still remember toggling in a boot loader on
> the PDP-6.  Cobol and Fortran languages.  But it was only on the job
> that I learned Basic.

A single 3 credit course in COBOL is barely enough time to learn "how
to do". Today even more so as the functionality of the language has
expanded greatly over the years. There is a lot done with COBOL today
that your professors probably hadn't even anticipated.

[Bill Gunshannon]

Depends very much on the job. I started in COBOL in 1980.
Eventually moved on into many other facets of the IT world
mostly at the system level as opposed to the application
level. In 2012 I took a job as a, you guessed it, a COBOL
programmer. I was able to hit the ground running because
other than some much nicer flow control (EVALUATE instead
of 50 level deep IF-THE-ELSE) nothing had really changed.
The job had remained the same, why should the language
morph into something else (although attempts to do just
that had been tried by academia and soundly rejected by
the real world practitioners.)

>
> They key is to learn to think the right way.
>
> And I think it sort of get proved by the fact that
> people with non-IT degrees like math, physics, chemistry,
> astronomy etc. tend to get just as good software
> developers as those with an IT degree in computer science
> or software engineering.

Nice thought, but my experience has somewhat differed. I have
had to maintain and modify business programs written in Fortran
by engineers.

Don't get me wrong, I am not saying that one needs a degree to
do any of this. I did most of what I did for over 30 years
without a degree. And, at no point did the degree have any
real effect on my ability to do the job. For me, the degree
was like the documentation. Not done until the project has
ended. :-) But it took a lot of learning. I am lucky in
that I have always had excellent learning skills. I learned
Pascal from the Jensen & Wirth book in one week of vacation
reading in order to further my position as a Systems Analyst/
Programmer in the Army. Many people need a more structured
learning environment and that should be provided by the
schools they attend. But the schools should also teach what
the student is likely to need in the future (which, again,
depends on the student actually picking the right track for
their future).

>
> So priorities:
> 1) Learn to think the right way
> 2) Learn the general stuff that keeps being relevant
>    about data structures, algorithms etc.  "the Knuth stuff"
> ...
> 99) Learn some specific technologies needed by the industry last year.

More importantly, unless your degree is in something like Philosophy
or Humanities, learn something you will need today in order to succeed
at what yo plan to do with that degree. Otherwise, might just as well
skip the whole college thing and save the massive debt. :-)

>
> What programming languages to learn is less important.

If your going to have to learn a programming language at all
it should be one that actually applies to where you are planning
on going after college. My department changed from Pascal to
Ada as the introductory language (this was before the advent
of C in the typical CS environment). For some it was their base
language for all four years at the University. I received dozens
of emails from former students bitching about how they had been
forced to learn and use a language that had no value whatsoever
when they got out in the real world.

>
> I will recommend at least 3 to get a broad perspective.
>
> And they should of course be a bit different to achieve that goal, so:
> - both static and dynamic types
> - include procedural, object oriented, generic and functional
>   programming
>

I agree with that. But make sure they are not three that are
totally tied to the same paradigm and only the reserved words
change. And don't tie the students to the language du jour
which is likely to change when they graduate or very shortly
thereafter.

> Popular languages in education has changed over time.
>
> Something like:
>
> Pascal -> C -> C++ and Delphi -> Python, Java and C#

^
|
You forgot Ada. :-)

>
> I don't think there is many aspects of Cobol that makes it
> relevant in education.

The fact that it is different from the other paradigms and still
used extensively in the IT world make it very relevant.

>
> Maybe for something including ISAM files.

Should be included, but there is much more to COBOL today. By the
way, IBM zOS is still very much into VSAM. Maybe that touch of
ISAM would help. :-)

bill

[Dave Froble]

On 2/20/2022 3:46 PM, Bill Gunshannon wrote:
> On 2/20/22 12:29, Dave Froble wrote:
>> On 2/20/2022 9:49 AM, Bill Gunshannon wrote:
>>> On 2/20/22 00:17, Dave Froble wrote:
>>>> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>>>>> On 2/19/22 21:07, Dan Cross wrote:
>>>>
>>>> Bit of a trim of the old stuff needed ...
>>>>
>>>> To me, a university is there to teach a person how to think and learn.
>>>
>>> That's definitely part of it. BUt, based on observing life around us
>>> today, they appear to have abdicated the part about learning to think
>>> as well as COBOL. :-) They do not teach yo how to learn. It is
>>> pretty much assumed you got that in the schools before you got to
>>> University.
>>
>> Bad assumption. In secondary schools, and grade schools, one is taught facts.
>> One isn't taught to think much about the facts. After all, onme would need
>> the facts before being able to think about them. But at some time some more
>> abstract thought about the world around us is needed, and that should happen
>> at university. At least, that's how I see it.
>
> I think a bit of confusion. Students learn how to learn before
> University. Universities then present information and it is up
> to the student to "learn". Professors really don't care if you
> learn anything in their class. Not their responsibility. No one
> gets individual attention. After all, if you don;t learn the
> material the first time around you can always take the class again.

I do remember at least one professor saying "I'm here to present the
information, learning is your job." I also remember that professor, and others,
who would be very helpful in one on one consultations. Quite a bit of
individual attention when it was asked for.

>>>> When my son started school, he asked "what type of job should I learn to do?".
>>>
>>> Bad question.
>>
>> I always say, there is no such thing as a bad question. If someone has a
>> question, that indicates he/she "doesn't know", and is trying to find out.
>> However, there can be bad answers.
>
> There can certainly be bad questions. The question he should have been
> asking is what do I want to do with my life. Asking someone else what
> kind of job you should get just sets you up for disappointment and a
> very stressful life. Learned from experience. :-)

Well, there you go ...

He didn't know to ask that question. Then what. That is why I told him he was
in school to broaden his horizons. And he did.

>>> But then, that's probably why so many students end out
>>> taking 5 to 6 years to get that degree because they really don;t know
>>> why they are even there.
>>
>> I believe David took 8 years before getting a degree in geology. And you are
>> correct, many don't know why they are there when going to university. A
>> university should help students at least partially figure out what they are
>> doing.
>
> Nope, not their job. They are not psychologists and they are not
> guidance counselors (although my experience with them in high school
> left much to be desired!) One should have made the decision about
> what one is going to study even before they have picked the school
> they are going to attend. Once you get there they can only recommend
> what courses of study they offer. None of them may be the right fit
> for any particular student.

I'd choose to partially disagree with that.

>>>> My reply was "You aren't going to learn a job. You're going there to
>>>> learn how to learn, and think, and to learn about the world that you haven't
>>>> seen yet."

The way things worked out is, David took a number of elective classes. There is
that "broaden horizon" thing again. One of the classes was an intro to geology,
not something he'd ever considered, and he really liked the subject. He went on
to get a degree in geology.

So yeah, a university can have much to do with a person choosing what to do with
their life.

And after working in the field for a while, he moved on. Currently a reactor
operator at a nuclear power station. Strange how things change over the years.

But it is certainly enough to get one started, so additional skills can be learned.