On 2022-02-15, Hans Bachner <hans@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 ?

Simon.

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

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 <j71r42Fh9vsU1@mid.individual.net>,
>>>> Bill Gunshannon  <bill.gunshannon@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.
>>>
>>> bill
>>>
>>
>> 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.

Johnny

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 <j71r42Fh9vsU1@mid.individual.net>,
>>>>> Bill Gunshannon  <bill.gunshannon@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

Den 2022-02-16 kl. 16:58, skrev 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 <j71r42Fh9vsU1@mid.individual.net>,
>>>>>> Bill Gunshannon  <bill.gunshannon@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
>
>

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.

On 2022-02-16 17:32, Jan-Erik Söderholm wrote:
> Den 2022-02-16 kl. 16:58, skrev 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 <j71r42Fh9vsU1@mid.individual.net>,
>>>>>>> Bill Gunshannon  <bill.gunshannon@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
>>
>>
>
> 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.

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

On 2/16/2022 12:53 PM, Johnny Billquist wrote:
> On 2022-02-16 17:32, Jan-Erik Söderholm wrote:
>> Den 2022-02-16 kl. 16:58, skrev 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 <j71r42Fh9vsU1@mid.individual.net>,
>>>>>>>> Bill Gunshannon  <bill.gunshannon@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.
>>
>> 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

On 2022-02-16, John Dallman <jgd@cix.co.uk> wrote:
> 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.
>

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.

Simon.

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

Simon Clubley schrieb am 16.02.2022 um 15:02:
> On 2022-02-15, Hans Bachner <hans@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.

On 2/16/2022 4:36 PM, Hans Bachner wrote:
> Simon Clubley schrieb am 16.02.2022 um 15:02:
>> On 2022-02-15, Hans Bachner <hans@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.

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: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

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

On 16/02/2022 22:34, Dave Froble wrote:
> On 2/16/2022 4:36 PM, Hans Bachner wrote:
>> Simon Clubley schrieb am 16.02.2022 um 15:02:
>>> On 2022-02-15, Hans Bachner <hans@bachner.priv.at> wrote:
>
> 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.
>
>

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

In article <919fe330-a0dc-4784-bd2e-edea99790dc0n@googlegroups.com>,
"dthi...@gmail.com" <dthittner@gmail.com> writes:

> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
> standard, and not a complete implementation of it either). Later FORTRAN
> standards (2003, 2008, 2108) have fully embraced object oriented code
> practices and C interoperability.

Isn't there supposed to be a much more modern, FLANG-based Fortran
compiler from VSI (presumably only) on x86?

If so, when?

On 2/17/2022 5:28 AM, Phillip Helbig (undress to reply) wrote:
> In article <919fe330-a0dc-4784-bd2e-edea99790dc0n@googlegroups.com>,
> "dthi...@gmail.com" <dthittner@gmail.com> writes:
>> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
>> standard, and not a complete implementation of it either). Later FORTRAN
>> standards (2003, 2008, 2108) have fully embraced object oriented code
>> practices and C interoperability.
>
> Isn't there supposed to be a much more modern, FLANG-based Fortran
> compiler from VSI (presumably only) on x86?
>
> If so, when?

VSI has stated their intention to go with flang. Which is really saying
that they have no intention of shoehorning the newer Fortran standards
into the old compiler. Which makes sense.

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

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

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

On 2/17/2022 9:42 AM, Bill Gunshannon wrote:
> On 2/17/22 09:21, Arne Vajhøj wrote:
>> On 2/16/2022 9:41 PM, dthi...@gmail.com wrote:
>>>> On Tuesday, February 15, 2022 at 8:05:01 AM UTC-5, Bill Gunshannon
>>>> wrote: National Computing Group West Mifflin, PA
>>>>
>>>> Document, plan and execute the modernization of Fortran
>>>> applications running on OpenVMS systems to a virtualized Windows
>>>> Server environment.
>>>
>>> I'd like to point out to everyone that this posting specifically
>>> calls out modernizing FORTRAN, which CANNOT be done on OpenVMS, as
>>> the OpenVMS FORTRAN compiler is over 25 years old. The commercial and
>>> scientific FORTRAN code base out there is massive, as is the
>>> commercial COBOL code base. I am aware of many companies modernizing
>>> their FORTRAN code bases to use the new object oriented methods of
>>> the later FORTRAN standards, which can be compiled with the Intel
>>> Fortran compiler and the later gfortran compilers.
>>
>> It talks about "modernization of Fortran applications", which can really
>> be move Fortran code as it to newer platform, upgrade from old Fortran
>> to newer Fortran or rewrite from Fortran to newer language.
>
> This is one of the problems with the term "modernization".
> To some it means use modern capabilities of the original
> language that increase the efficiency and readability of
> a program while to others it means scrap the old program
> and re-write it in the language du jour.  The second option
> seldom being necessary or of any added value,

The industry seems to think otherwise since it is happening
a lot.

>>> I've complained to both HPE and VSI for years that you can't attract
>>> new developers to the platform, and thus grow your customer base, if
>>> you don't provide modern software development tools and tool chains.
>>
>> Yes.
>>
>> Existing customers need compatibility.
>>
>> New customers needs modern languages, tools, libraries, frameworks
>> etc. that tyhe industry expect today.
>
> Even if the so called "modern languages" actually bring no added
> value to the table?

The industry thinks they do.

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

In article <620e5870$0$701$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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?

On 2/17/2022 12:27 PM, Phillip Helbig (undress to reply) wrote:
> In article <620e5870$0$701$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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?

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

On 2/17/2022 11:01 AM, Arne Vajhøj wrote:
> On 2/17/2022 9:42 AM, Bill Gunshannon wrote:
>> On 2/17/22 09:21, Arne Vajhøj wrote:
>>> On 2/16/2022 9:41 PM, dthi...@gmail.com wrote:
>>>>> On Tuesday, February 15, 2022 at 8:05:01 AM UTC-5, Bill Gunshannon
>>>>> wrote: National Computing Group West Mifflin, PA
>>>>>
>>>>> Document, plan and execute the modernization of Fortran
>>>>> applications running on OpenVMS systems to a virtualized Windows
>>>>> Server environment.
>>>>
>>>> I'd like to point out to everyone that this posting specifically
>>>> calls out modernizing FORTRAN, which CANNOT be done on OpenVMS, as
>>>> the OpenVMS FORTRAN compiler is over 25 years old. The commercial and
>>>> scientific FORTRAN code base out there is massive, as is the
>>>> commercial COBOL code base. I am aware of many companies modernizing
>>>> their FORTRAN code bases to use the new object oriented methods of
>>>> the later FORTRAN standards, which can be compiled with the Intel
>>>> Fortran compiler and the later gfortran compilers.
>>>
>>> It talks about "modernization of Fortran applications", which can really
>>> be move Fortran code as it to newer platform, upgrade from old Fortran
>>> to newer Fortran or rewrite from Fortran to newer language.
>>
>> This is one of the problems with the term "modernization".
>> To some it means use modern capabilities of the original
>> language that increase the efficiency and readability of
>> a program while to others it means scrap the old program
>> and re-write it in the language du jour. The second option
>> seldom being necessary or of any added value,
>
> The industry seems to think otherwise since it is happening
> a lot.
>
>>>> I've complained to both HPE and VSI for years that you can't attract
>>>> new developers to the platform, and thus grow your customer base, if
>>>> you don't provide modern software development tools and tool chains.
>>>
>>> Yes.
>>>
>>> Existing customers need compatibility.
>>>
>>> New customers needs modern languages, tools, libraries, frameworks
>>> etc. that tyhe industry expect today.
>>
>> Even if the so called "modern languages" actually bring no added
>> value to the table?
>
> The industry thinks they do.
>
>>>> 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
>

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.

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

On 2022-02-17, Arne Vajhøj <arne@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.

Simon.

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

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

> What I rarely see is practical considerations.
>
> Joe wiz kid comes along and tells his employer how they must "upgrade"
> to modern standards.  But, Joe wiz kid isn't going to pay for the
> effort.  That is left to the employer, who just might be rather happy
> with the fully functional and working current solutions.

If the CTO/CIO is worth his/her salary then the pro's and con's
of a migration will be analyzed before a decision is made.

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

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

Interesting interpolation!

--
Chris

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

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

On 2/17/22 14:01, Simon Clubley wrote:
> On 2022-02-17, Arne Vajhøj <arne@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

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

Even IBM mainframes have moved on (big time!!!). They don't just run
COBOL these days.

Simon.

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