[Info-vax] Unix on A DEC Vax?

[Stephen Hoffman]

On 2013-01-18 14:36:07 +0000, David Froble said:

> Stephen Hoffman wrote:
>> On 2013-01-18 03:49:30 +0000, Howard S Shubs said:
>> 
>>> In article <kda3ji$9a0$1 at dont-email.me>,
>>> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>> 
>>>> As for the emulation market, the folks that are choosing emulation will
>>>> likely continue to use it until the application(s) age out, or the
>>>> management involved ages out, or the organization gets clobbered by
>>>> competition.  But those folks are probably not going to be doing very
>>>> much with the applications running under emulation, as that's usually
>>>> viewed as a dead-end for new investments, even within the organizations.
>>>> 
>>>> Hardware emulation is computing's version of the cover band.  Sometimes
>>>> fun.  Variously useful.  But not really what most folks want.
>>> 
>>> Perhaps not, but sometimes it's all you can have.  Such as when the
>>> software manufacturer has gone defunct, or might as well have (VMS port
>>> to x86, anyone?).  Unless someone can get HP to release source code.
>> 
>> Or in another way of looking at this, your organization decided to use 
>> non-portable features and/or platform-specific software, and for your 
>> own code you decided not to isolate the use of platform-specific 
>> features, and you decided to not invest in maintaining and updating and 
>> portability; you decided that an external dependency was an acceptable 
>> risk.
>> 
>> You're asking about DSSI disks for VAX servers in another recent 
>> posting.  If that's related to this, then consider the proverbial 
>> writing was on the wall for VAX in 1992 or so, with the advent of 
>> Alpha.  There's very little business-critical "stuff" that can't be 
>> ported in twenty years.
>> 
>> Sure.  Folks get themselves into this condundrum, and with various 
>> associated justifications.  Which is why we're having this discussion.  
>> And this is why there's a market for emulators, even though few folks 
>> really want to use those.
>> 
>> Steve Jobs wasn't fond of dependencies on outside organizations and 
>> entities, as the other vendors could choose to cancel or retarget the 
>> products[1], or potentially held ransom.  If your dependencies are more 
>> portable or are available from multiple sources, you're much harder to 
>> derail.  Is that the cheapest approach over the short term?  No.  But 
>> is this the cheapest over a longer term?  Very possibly yes.
>> 
>> Look at how you got where you are with the old gear, and why, and 
>> consider if repeating that same decision process is a sequence you 
>> would want to repeat going forward, or if you would have preferred a 
>> different (non-emulated) outcome.  Then look at what your business is 
>> going to encounter going forward, and what you have for resources.  
>> Like jack-posts and scaffolding and temporary bracing used in 
>> construction, emulation is a temporary stop-gap or intermediate 
>> measure.  It's not going to be a preferred end-state.  OK; so now 
>> you're running emulation.  How do you get out of that configuration, 
>> and into a simpler and more maintainable configuration?  How do you 
>> avoid adding more emulation?  How do you migrate your data, or your 
>> apps?
>> 
>> ————
>> [1]Haven't folks been commenting on the Windows 8 UI?  That Microsoft 
>> is seemingly not headed where you want to be today?
>> 
>> 
> 
> That's one hell of a rationalization !!!!!!!!!!!!!!

What?  Pay attention to what's going on, chart your course accordingly, 
and try to avoid getting "cornered"?

> We should not have lived in caves because houses are better ...

Nope.  If you're in a cave and you discover a house, maybe you should 
investigate whether there are benefits.

> We should not have used sod roofs on houses ...

If you had thatch or sod or whatever available and it worked, great.  
If you then encounter asphalt shingles or corrugated roofing or slate 
or..., might some upkeep of your roof be in order?  Maybe not 
immediately, but when your roof next needs maintenance.

> We should not be living on planet Earth because sooner or later Sol 
> will go nova ...

Watching for earth-crossing asteroids and related rubbish is probably a 
good idea.  As for a nova or supernova, there's a longer runway for 
software migration prior to an exit from the main sequence.  The likely 
red giant phase would provide a robust planetary cleanup, too.  There's 
been one ~325 meter rock known as 99942 Apophis that's recently 
wandered past— closer than the orbits of the geosynchronous satellites 
— recently.  Comet C/2012 S1 is forecast to potentially provide a show 
this year, and nothing more.  There's also the chance of a repeat of 
the Carrington Event — the solar storm of 1859 — which would play havoc 
with systems.

But some of those possibilities are sufficiently nasty that very few 
folks are likely to be looking at your business continuity plans.

> Specifically about computers:
> 
> We should never have used any DEC product, and most other 
> manufacturer's products, because they (the companies) weren't going to 
> survive ...

That's not what I wrote.

> We should never have used any language besides C since they were not 
> going to survive ...

If the compilers aren't widely available — the Bliss compiler is an 
obvious example of this— then your options are constrained.

Or you get to create or maintain or acquire the tools needed.

In this case, if you're "cornered", then a BASIC compiler — probably 
built upon LLVM — would be a feasible option.  Or a port to an 
available BASIC compiler.

Not cheap.  Not fun.  But feasible.

And yes, emulation works here, until you figure out what you're going to do.

> We should never have used 4, 8, 16, and 32 bit computers since for the 
> most part they weren't going to survive ...

I've seen some COBOL and some Fortran that looked like it originated on 
16-bit, if not before, and some Macro32 that dated back to the earliest 
days of VAX.  The COBOL and the Fortran was reasonably portable.  The 
Macro32 code was going to be trapped on VMS, either assembled on VAX or 
compiled on Alpha and Itanium.  For now, it worked well enough.  Had 
there been more of that Macro32 around, or had there a requirement to 
port that Macro32, there can be other options.  Or a rewrite.  But I 
digress.

> DEC didn't survive because of management, not the products.  Many of 
> the products and ideas developed by DEC are still in wide use today, 
> just not produced by DEC any more.

Ignoring DEC here, consider how mismanagement or inattention can lead 
to an organization — any organization — to miss a market — or to miss a 
market migration — going forward.

A sufficiently nasty "branch mis-prediction" fault here can lead to 
emulation.  To gnashing of teeth.  Or to a corporate butt-clenching 
moment, if a key vendor cancels something your organization is 
centrally dependent on.

> The problem with things such as VMS, DEC BASIC, and others is that the 
> current owner of the products has little regard for them.  It didn't 
> have to end this way.

Nope.  But then vendors can and do make different choices than the 
customers might want.  Which gets back to that earlier comment about 
watching your external dependencies, and having contracts for required 
deliverables, preferably several sources, and all this irrespective of 
the vendor and the product.

> Now, it's easy today to embrace some things such as Unix and Linux 
> because there is not a single entity that can deprecate them the way HP 
> is doing with some (all?) of the former DEC products.  I'm beginning to 
> see that light.  Not saying I like it.  But would such exist today 
> without that which preceded it?  I have my doubts.

Reversing the temporal view, will current hardware and software — from 
any vendor — continue to be available.  In what form?  For how long?

Or will what's available now be replaced, or augmented?

Or what can do the job better and easier than what you're using now?

> To me, the real problem was the lack of insistence by customers in the 
> past that they have some protection.  A refusal to purchase VMS (and 
> therefore DEC computers) without some assurance that the software could 
> survive the company might have provided a totally different outcome. 
> Using 20/20 hindsight, I can imagine this software being available for 
> maintenance, development, and such similar to today's "open" software.

I'm aware of various projects which have had escrow requirements.

IIRC, DEC did offer a VMS source code license an aeon or two ago, but 
that was reportedly very expensive; around US$25,000.  Whether anybody 
bought one, or what the terms might be?


-- 
Pure Personal Opinion | HoffmanLabs LLC