VSI and embedded VAX/Alpha support

[Stanley F. Quayle]

It's been mentioned that emulating a VAX or Alpha could be a feature in the x86 VMS product, "downshifting" to the the VAX or Alpha instruction set. That could be doing a VEST/AEST on the fly.

While this would be cool, most of my emulator customers are stuck on a specific version of VMS -- whether it's non-existent source code for a port, validation/certification by government agencies, or just plain inertia. They're dependent on layered products, too. Some of those products might not work in a VEST/AEST fashion.

I suppose that the "downshift" could actually be one or more emulated environments specified by the customer, running an emulator like CHARON-VAX. (Shameless Plug Alert(tm) -- I am a Stromasys reseller).

There needs to be a way for the emulated system to communicate with the x86 VMS host. You can't use clustering because VAX V5.5-2 can't cluster with VMS 8.x. You can't depend on DECnet or TCP/IP being present. VSI has some serious design work to do.

This doesn't depend on HP, since they already have a mechanism to license emulators, and there are several emulator manufacturers. HP is just one of a number of resellers of CHARON.

--Stan Quayle

[JF Mezei]

On 14-12-27 15:32, Stanley F. Quayle wrote:

> There needs to be a way for the emulated system to communicate with the x86 VMS host.

The emulator could provide different run-times depending on the version
the executable expects to run on. So while the instance would be 9.x on
8086, the application would see system services compatible with 5.5-2 or
with 7.3 depending on what it was linked against (or some flag in the .exe).

On the other hand, moving any app from a real vax to an 8086 that runs
VMS natively with the VAX .EXE running under emulation would require
testing /certification anyways.

So if you are going to be doing that work, why not just provide the 7.3
run time emulation ?

[terry+go...@tmk.com]

On Saturday, December 27, 2014 6:18:25 PM UTC-5, JF Mezei wrote:
> The emulator could provide different run-times depending on the version
> the executable expects to run on. So while the instance would be 9.x on
> 8086, the application would see system services compatible with 5.5-2 or
> with 7.3 depending on what it was linked against (or some flag in the .exe).

With the emulator I am most familiar with (AlphaVM) and the others I've looked at, the emulator just provides an Alpha (or VAX) processor and peripherals - the customer provides the VMS image (usually by importing the original system disk as a virtual disk image).

Of course, there's no technical reason (there may be licensing issues) why you couldn't run multiple emulator instances on the same host, and those instances could be running different VMS versions. But that gets back to version restrictions on clustering, etc.

[JF Mezei]

On 14-12-27 20:22, terry+go...@tmk.com wrote:

> With the emulator I am most familiar with (AlphaVM) and the others I've looked at,

What was being discussed is not a hardware emulator, but rather a code
translator à la VEST that would allow VAX or Alpha executables to run on
an x86 version of VMS.


It might be easier to make application such as simh or the Alpha
emulator run as applicatiosn on the 8086 VMS, with a facility to make
the true VMS disks available to the emulated instance.

[David Froble]

Stanley F. Quayle wrote:
> It's been mentioned that emulating a VAX or Alpha could be a feature
> in the x86 VMS product, "downshifting" to the the VAX or Alpha
> instruction set. That could be doing a VEST/AEST on the fly.
>
> While this would be cool, most of my emulator customers are stuck on
> a specific version of VMS -- whether it's non-existent source code
> for a port, validation/certification by government agencies, or just
> plain inertia. They're dependent on layered products, too. Some of
> those products might not work in a VEST/AEST fashion.
>
> I suppose that the "downshift" could actually be one or more emulated
> environments specified by the customer, running an emulator like
> CHARON-VAX. (Shameless Plug Alert(tm) -- I am a Stromasys reseller).
>
> There needs to be a way for the emulated system to communicate with
> the x86 VMS host. You can't use clustering because VAX V5.5-2 can't
> cluster with VMS 8.x. You can't depend on DECnet or TCP/IP being
> present. VSI has some serious design work to do.

Uh ... why not DECnet? DECnet IV has been available since maybe the
beginning of VMS. DECnet is task to task communications, with lots of
useful utilities provided, such as FAL.

[David Froble]

JF Mezei wrote:
> On 14-12-27 20:22, terry+go...@tmk.com wrote:
>
>> With the emulator I am most familiar with (AlphaVM) and the others I've looked at,
>
>
> What was being discussed is not a hardware emulator, but rather a code
> translator à la VEST that would allow VAX or Alpha executables to run on
> an x86 version of VMS.

Reading back, hardware emulators seem to part of the discussion.

> It might be easier to make application such as simh or the Alpha
> emulator run as applicatiosn on the 8086 VMS, with a facility to make
> the true VMS disks available to the emulated instance.

Well, unless you're running a cluster, which at this time doesn't seem
to be feasible, you cannot share the data, since the DLM won't be in
play on both (or more) instances of VMS.

Even if the emulator disk was also an LD disk on the native VMS, you
would not want shared access. And even in a cluster, each device must
have a unique name for the DLM, not sure how that would work with an LD
disk which was also a disk for the emulator.

Not sure that this discussion isn't sliding down the slippery slope of a
solution to a non-existent problem ...

Seems to me that DECnet would solve any issues. FAL for file access.
Task to task communications for whatever ...

Then, there would be the possibility of a new version of VAX VMS that
could cluster with V9.0 on x86. Just a thought for those who ask why
anyone would want a new version of VAX VMS.

[JF Mezei]

On 14-12-28 01:13, David Froble wrote:

> Well, unless you're running a cluster, which at this time doesn't seem
> to be feasible, you cannot share the data, since the DLM won't be in
> play on both (or more) instances of VMS.

If the eemulator offers a simulated disk to the emulated instance which
grants access to the real VMS disk, then the emulator can do the native
locking when the emulated instance accesses files on that synthetized
disk presented to the emulated instance.

[Stanley F. Quayle]

On Sunday, December 28, 2014 12:55:33 AM UTC-5, David Froble wrote:
> Uh ... why not DECnet? DECnet IV has been available since maybe the
> beginning of VMS. DECnet is task to task communications, with lots of
> useful utilities provided, such as FAL.

Sure, if the emulated system had DECnet installed and running. If it wasn't installed, or not configured, or not started, that would be a change to the system. Definitely violates the "don't mess with what works" concept.

If you don't have a DVNET* or NET_APP_SUP* license, but only a UCX license, DECnet won't start. Checked pricing on those licenses recently? They are way expensive. DEC, Compaq, and HP never lowered the price of VAX (or Alpha) licenses once their platforms went EOL.

[David Froble]

Well, if we're looking at the effort to provide some form of
communication, just about anything will be more work than lowering the
license fees for DECnet. Don't need to do any re-inventing of the wheel
here.

I'm hoping one lesson VSI takes to heart is that excessive license fees
doesn't mean more revenue, but less, as in maybe none.

It is my understanding that RedHat does not sell licenses, actully
cannot, and provides their enterprise version free, but can only be used
when a support contract is active. Seems they are getting away with
this, and seems they are getting enough revenue to stay in business.

Maybe not a bad act to follow ...

[Phillip Helbig (undress to reply)]

In article <m7qh1h$f98$1...@dont-email.me>, David Froble

<da...@tsoft-inc.com> writes:

> It is my understanding that RedHat does not sell licenses, actully
> cannot, and provides their enterprise version free, but can only be used
> when a support contract is active. Seems they are getting away with
> this, and seems they are getting enough revenue to stay in business.

I think they are REQUIRED to provide their enterprise version free, due
to GPL or whatever.

Their model is "we sell support". Would this work for VMS? I don't
know. There are other versions of Linux around, even from RedHat, but
not other versions of VMS.

[glen herrmannsfeldt]

Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
> In article <m7qh1h$f98$1...@dont-email.me>, David Froble
> <da...@tsoft-inc.com> writes:

>> It is my understanding that RedHat does not sell licenses, actully
>> cannot, and provides their enterprise version free, but can only be used
>> when a support contract is active. Seems they are getting away with
>> this, and seems they are getting enough revenue to stay in business.

> I think they are REQUIRED to provide their enterprise version free, due
> to GPL or whatever.

Well, as usual they can copyright the specific aggregate, and also
use trademarks.

Scientific Linux compilers the RH source, after changing all the
trademarks.

> Their model is "we sell support". Would this work for VMS? I don't
> know. There are other versions of Linux around, even from RedHat, but
> not other versions of VMS.

-- glen

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Phillip Helbig (undress to reply)

Expensive up front life time licenses are typically considered "CAPEX"
costs on Cust books. CAPEX costs typically require high level VP approvals
which carries lots of internal visibility from a financials perspective.

Internally to vendors like HP, IBM, up front licensing works better
because the Eng groups focus on the licensing $'s revenue, while the
Support org focuses on the support revenues. Imho, it's one of the
challenges OpenVMS had over the years as decisions were made based
on licensing $'s - not the much larger support revenues. One would be
naïve to think these internal groups made decisions based on what was
best for the company vs. what was best for their own organization. This
is not unique to any company as I am sure the same internal culture is
in play at IBM, Microsoft and other large companies.

Annual subscription based licensing is considered part of OPEX expenses
required to maintain the IT Operations side of the business. Cust OPEX
expenses get buried in many lines of Operations budgets that are only
reviewed by the IT Operations mgmt. teams. If the OPS budget gets any
review, it is typically staffing related as that is almost always the biggest
slice of the OPS budget. Hence, OPS managers are much more able to
make their own decisions without getting senior VP approvals.

It's no coincidence that Microsoft came up with Office365 as a means to
get around all of the visibility associated with its high costs for MS Office
suite.

Annual subscriptions also provide the capability to get closer to your
Customers to build up their Cust DB as each annual renewal requires
an update to contact info, cust surveys, getting closer to Customer etc.

Red Hat's model is actually very practical (for RH). While still much less
than OpenVMS's current costs, the RH Linux pricing model is not as
cheap as one is led to believe. Especially given it is host based and the
current VM sprawl challenges plays very well into their annual
subscription model because Custs buy the high end subscription p/n's
so they do not have to worry about number of VM's.

Check out the RH pricing model: (assume 5 year license cycle for costs)
https://www.redhat.com/apps/store/server/rhel.html

In future, I suspect having a subscription "option" in parallel to the
one time licenses on X64 would be a very good move. Imho, since
OpenVMS will be on the same HW as commodity OS's, the annual
subscription pricing would need to be competitive (not necessarily
cheaper) with Linux/Windows offerings on the same HW.

Regards,

Kerry Main
Back to the Future IT Inc.
.. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com