[Info-vax] 1 year.

[Stephen Hoffman]

On 2015-08-09 13:57:37 +0000, already5chosen at yahoo.com said:

> On Sunday, August 9, 2015 at 4:05:05 PM UTC+3, Kerry Main wrote:
>>> -----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.
>>> 
>> 
>> 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 never did either, but from common knowledge it seems the opposite is 
> true. Emulating just a CPU sounds far easier than emulating the whole 
> machine, with all quirks of peripheral devices. And in this particular 
> case you don't even have to emulate the full Alpha ISA, all system-only 
> stuff can be omitted.
> The only aspect that is harder is a much higher performance bar that 
> you are aiming at.

For cases such as what IanD is referencing, which is least-changes for 
the end-user?  Translation, or emulation?  Translation involves 
purchasing an Itanium and the rest of the baggage that entails, and 
then translating the individual hunks of the existing environment.  
(I'd not expect to see anything approaching Rosetta here, either.  Not 
for Alpha to Itanium.)   Emulation means creating a disk image of the 
old environment and transferring it and the licenses over to the new 
environment, and then using logical names to redirect device references 
where necessary.  Neither approach is risk free, of course.


>> I also recall binary translation was/is primarily targeted on user mode 
>> applications, so it would reduce the number of potential use cases.
> 
> Not by much. There are far fewer shops with their own kernel drivers 
> than those that has their own applications.

For simple and isolated application cases, you're quite correct: 
inner-mode code is rare.  But with the usual sorts of "accreted" 
configurations arising from a decade or two of usage, it's common to 
find user-written system services and other inner-mode code around — 
whether to manage privileges or otherwise — and various layered 
products and third-party dependencies also have inner-mode code.  I've 
found $cmkrnl calls lurking in some surprising places.

But for an existing site that wants off of OpenVMS and has a parallel, 
target application environment already operational, translation and 
emulation are unlikely choices.  Not without some very viable 
justification.  Translation is not likely that justification.


>> 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.
> 
> I'd guess, that sort of mentality (do no changes anything, including 
> not applying fixes to known OS bugs and vulnerabilities) is the reason 
> behind negative reaction of Mr. Hoffman.

I'd suggest experimenting with both, if you've not already done so.

Platform emulation tends to be the lowest-cost and least-bad and 
least-changes approach, for cases involving substantially-lost source 
code and/or unavailable or allocated-elsewhere staffing and/or 
insufficient revenue stream, or are otherwise are not in a position to 
port your code natively.   Yes, translation does work and is viable for 
some cases and particularly for cases where you have most of the source 
code but not all of it.   But it's also almost inherently more work on 
the end-user.

Unfortunately, few operating system vendors have the time and budget 
for translation tools of the scale of and the transparency of Rosetta, 
for that matter.

For a case such as IanD is reporting, spending anything here that's not 
strictly necessary usually requires some form of justification.  
Justifying a move to Itanium will not be easy.

Short of paravirtualization — calls through from the emulated OpenVMS 
environment into the native OpenVMS environment — there's no obvious 
advantage of hosting OpenVMS on OpenVMS, outside of having one less 
operating system involved.  And in various cases such as the one IanD 
is referencing — which is what my remarks here are targeting — the 
folks involved would clearly rather have fewer instances of OpenVMS 
around, and are using other operating system(s) as their preferred 
environment.

It's the revenues and the expenses and the opinions of the senior 
managers that drive these choices, and then the technology and staffing 
and tools that supports those goals.   Or that does not support those 
goals.   Removing redundancies and reducing the numbers of operating 
systems and platforms is a common preference.  This usually means fewer 
data centers, fewer software and fewer hardware permutations, reduced 
staffing and reduced staffing requirements, increased automation, 
lower-priced staffing and lower-priced software, etc.   Many managers 
are measured on fixed costs, and on reducing fixed costs, and on 
maintaining service level goals.  On getting folks off of a platform or 
an application that's become visible, and that's viewed as undesirable 
or legacy.  for whatever reason  Managers are less often measured on 
the details of whether some particular emulation uses IA-32 execution 
layer or some other form of translation or emulation.




-- 
Pure Personal Opinion | HoffmanLabs LLC