[Info-vax] 1 year.

[already5chosen at yahoo.com]

On Sunday, August 9, 2015 at 6:07:11 PM UTC+3, Stephen Hoffman wrote:
> 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.
> 

You are ignoring the data, provided by IanD. It's ES80, heavily loaded. There is no practical chance that it will meet performance requirements on Charon-AXP.
So, I'd call Charon-AXP risk free, that is, free of risk of working :(

With AEST, on the other hand, there is a significant risk that it wouldn't work at all and a less significant risk that it will work, but wouldn't meet performance requirement, but still, with determined effort, there is a good chance that everything will work and will free them of concerns for the next 5-7 years at least.

As to HW, with Poulson now officially supported, fast hardware (e.g. rx2800 i4) should be relatively affordable. Naturally, I have no idea how affordable.

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