[Info-vax] 1 year.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> already5chosen at yahoo.com
> Sent: 09-Aug-15 5:28 AM
> To: info-vax at info-vax.com
> Subject: Re: [New Info-vax] 1 year.
> 
> On Sunday, August 9, 2015 at 6:30:06 AM UTC+3, Kerry Main wrote:
> > > -----Original Message-----
> > > From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf
> Of
> > > Stephen Hoffman
> > > Sent: 08-Aug-15 6:39 PM
> > > To: info-vax at info-vax.com
> > > Subject: Re: [New Info-vax] 1 year.
> > >
> > > On 2015-08-08 19:54:35 +0000, already5chosen at yahoo.com said:
> > >
> > > > Yes, more or less. Except that AEST appears to be a static translator,
> > >
> > > Incremental translation and instruction emulation are necessarily
> > > performed.  Details are in the previously-linked documentation.
> > >
> > > Using application translation for the environment that IanD has
> > > described is likely more expensive, with no improvements in their
> > > current results and quite possibly with a reductions in stability or
> > > availability or maintainability.   It's unclear why emulation would be
> > > acceptable to responsible managers here, either.  Particularly given it
> > > hasn't already been deemed acceptable some time over the past
> decade
> > > or
> > > so.
> > >
> > > This particular translation case also involves moving to a platform
> > > where Kittson as the last Itanium processor being discussed for
> > > OpenVMS
> > > itself, and where VSI has already picked the follow-on architecture
> > > with OpenVMS porting to x86-64.
> > >
> > > Management wants to migrate and has a replacement environment
> and
> > > wants
> > > this particular environment gone, so -- in the absence of a viable
> > > financial justification to the contrary, and quite possibly even with
> > > such a justification -- that's the target here.   Build a financial case
> > > to stay with OpenVMS.  Or get going on the migration.
> > >
> >
> > Would building an Alpha HW emulator on OpenVMS/X86-64 not be a
> > more preferred option?
> 
> I see no advantages over existing Stromasys products and numerous
> disadvantages.
> The biggest one - OpenVMS/X86-64 does not exist.
> The second biggest - when it finally exists, drivers availability will always
> remain far behind Windows Server. Running host VMS OS in para-
> virtualization mode under VMWare or under its Winduws or Linux
> counterparts can partially alleviate the issue, but only partially and at cost
> of making already slow solution even slower.
> 

Stromasys exists today, but they are not cheap - typically 4+ digits.

> On the other hand, application-level binary translation demonstrated
> very good performance. IA32EL claimed, on average, 50-60% of native
> (i.e. the same sources recompiled for Itanium) performance for apps
> that spend almost no time in syscalls. Applications that spend more time
> in syscalls and native libraries calls will fare even better.
> 

I am all for this if it can be done in a timely, and cost effective timeframe,
but from what I understand, application level binary translation is
also many numerous of magnitude more complex to build/support.

I also recall binary translation was/is primarily targeted on user mode 
applications, so it would reduce the number of potential use cases.

> >
> > Future VAX HW emulators???
> >
> > From a Customer perspective, standardize on one X86-64 platform and
> > move older environments to new platform with zero (or low) impact?
> >
> > Latest OpenVMS running on V9.x/X86-64 and older env's running on
> > same server running OpenVMS Alpha .. similar to VMware.
> >
> > Course, the mix would depend on performance requirements.
> >
> > Big benefit would be to get all those Alpha/VAX systems on new HW
> > (HP ProLiants?) and under monthly service support contracts to VSI.
> >
> > Would certainly help monthly revenue stream.
> >
> > There is also quite a bit of experience with building HW emulators via
> > other vendors, so perhaps, one could be contracted separately to do
> > this?
> 
> Yes, Stromasys emulators work, but they are far from speed demons.
> 

True, but from what I have seen, most existing VAX/Alpha environments 
are running less than 30% in peak times anyway. As long as the perf was
"as good", then it would be "good enough".

Yes, there are big Alpha and likely some bigger VAX env's but these are 
the exception - not the norm.

The draw for Custs moving to Alpha/VAX HW emulators on OpenVMS/
X86-64 would be a move to current HW with minimal/no changes to their 
App environment e.g. OpenVMS V8.4. Same draw as what VMware has
when they support older versions of Windows/Linux on their most 
current versions of VMware.

The draw for VSI would be to get additional monthly support revenue.

Yes, some VAX/Alpha systems have HW and/or timing dependencies 
that may make them ineligible for this use case.

Kerry