[Info-vax] 1 year.

[Stephen Hoffman]

On 2015-08-09 03:28:56 +0000, Kerry Main said:

>> 
>> -----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? Future VAX HW emulators???

Short of adding paravirtualization or some other features, there's no 
obvious advantage over the existing emulators.  Unless you're 
consolidating onto OpenVMS, and — at present — that's not common.   In 
IanD's case, they're not consolidating onto OpenVMS.    Probably three 
years before this is even an option, too.

> From a Customer perspective, standardize on one X86-64 platform and  
> move older environments to new platform with zero (or low) impact?

Customers already have this option, and with standardization.  Often 
with the emulation running on a platform that they're using elsewhere.  
Whether that's RHEL or otherwise.

> Latest OpenVMS running on V9.x/X86-64 and older env's running on same 
> server running OpenVMS Alpha .. similar to VMware.

Ayup, but it's also probably three to five years out.   This 
configuration involves getting OpenVMS ported and stable, then getting 
the emulators working — whether with paravirtualization support or not 
— and stable, and then getting the hardware and emulation installed and 
configured and the applications re-hosted over onto the emulation.

Obviously VMware is a virtual machine and does not include an emulator, 
which means a locally-installed copy of RHEL or otherwise, or one of 
those "bare metal" emulators that are pre-packaged with a Linux distro, 
and now you're dealing with something little different than what's 
available now — that OpenVMS x86-64 can coexist as another guest is 
largely irrelevant here.   Unless you're running the emulation on 
OpenVMS x86-64, with paravirtualization or otherwise, and that's 
entirely slideware at best.

> Course, the mix would depend on performance requirements.

Also on what sorts of speed-ups are possible with the next generation 
or three of hardware and of software, too.

> Big benefit would be to get all those Alpha/VAX systems on new HW (HP 
> ProLiants?) and under monthly service support contracts to VSI.

Or SuperMicro, or one of the other vendors.   But various of these 
long-time old-release environments won't be under HP or VSI support, 
though — it's common for these sites to drop off support, and nobody's 
figured out a good way to extract some revenue doing per-call software 
support, in the absence of an annual support contract.   It's also been 
problematic getting servers onto support contracts.

But it's been my experience that folks that have a migration and 
consolidation plan to a different application product and that are 
making statements such as IanD has posted here are not usually 
interested in expending more than minimally necessary on the old 
configuration.  Not without a financial case, and sometimes not even 
then.  Emulation becomes an option when the existing hardware becomes 
more costly to maintain and to run than the cost of the switch over to 
emulation.  This when some non-trivial part of the application source 
code is missing and which means that anything short of translation or 
emulation can be viewed as cost-prohibitive, and particularly when 
there's already a viable target to migrate folks available here.




-- 
Pure Personal Opinion | HoffmanLabs LLC