CHARON-AXP

[Vladimir Fabecic]

Hello
Does anybody use CHARON-AXP?
How is it working?
Can it really replace AS4100?
Is it stable enough?

[Peter Zeiszler]

Similiar to my question about the freeware one.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1097614

[Vladimir Fabecic]

Hello Peter.
I read this thread. But Personal Alpha offers support for 96 MB of Alpha memory, 1 Ethernet adapter, VT-terminal emulation and 2 disks.
I would like to know can it replace AS4100 with 10 disks and 2 GB RAM.
Did anybody try this?
CHARON-VAX works OK. I tried it.
I also red http://www.softresint.com/pub/SPD/60-15-007.pdf
But does anybody have real experiance with that?

[Hoff]

It's probably not specifically an AlphaServer 4100 emulation, it's some other Alpha system.

But yes, the SRI products and the SIMH freeware can and do work nicely. Whether or not emulation works for your applications depends on exactly what hardware and software is in use. I'd tend to expect it will work, but then I've also seen folks with j-random j-weird PCI card that's central to their processing. That would need to be emulated.

HP is (or was?) supporting OpenVMS on the SRI boxes, and SRI supported the underlying "hardware.". Between SRI and HP, you could acquire configuration support.

My biggest concerns with the emulators is largely independent of the emulator and the emulator vendor, it's the length of time the underlying platform will remain available and supported. For instance, how long will you have ECOs and fixes and such for whatever operating system is underneath the stack, and specifically for the particular version(s) required for the emulator. With classic OpenVMS hardware and software, if and for as long as the box works, you can run it into the ground. That's not quite the same maintenance case with emulation, particularly with typical network connections and environments into the underlying platform.

If you are looking at this approach, I'd take a good look at the DECmigrate, VEST, AEST tools and at recompilation and at moving to OpenVMS I64. I'd also take a serious look at a new or used Alpha, and moving to a newer (new or used) Alpha box. This is a shorter "stack," and may or may not be a more economic approach.

Emulation can be a very good solution. There are business-critical sites using emulation for production. In one case, it saved on power and cooling and floor-space -- that site required VAX for their environment, and that requirement was met through emulation. Just make sure you think through the whole stack and the implications of same, and where you might go "next".

I've certainly reviewed and planned and migrated piles and piles of code from VAX to Alpha and I've ported code and even OpenVMS itself to Integrity. And I've been dealing with emulated environments, too. (Emulation is really "just a VAX" or "just an Alpha," after all.) There are others around that can assist here, too.

Stephen Hoffman
HoffmanLabs

[Volker Halle · Accepted solution]

Vladimir,

there are a couple of customers using CHARON-AXP already. But they can not be publicly used as reference sites without prior arrangements.

Please consider to contact a CHARON-AXP VAR (Value Added Reseller) near you for further information.

Volker.

Invenate GmbH - www.invenate.de
(a CHARON-VAX and CHARON-AXP VAR)

[Ian Miller.]

Note also that you are reliant on the operating system running the emulator and the hardware that is running on - is that stable enough and does it meet your latency requirements?

[Hoff]

>> Note also that you are reliant on the operating system running the emulator and the hardware that is running on - is that stable enough and does it meet your latency requirements? <<

And not just the software "underneath" the emulated hardware, but the hardware parts and spares for the underlying "real" box. Commodity boxes can have three to five year lifecycles, and even within that range some parts can get scarce quite quickly; commodity disks, graphics controllers and CD/DVD devices can have the average lifetime of a fruit-fly, and the associated software is thus a moving target. Enterprise boxes tend to have four to seven year lifecycles, and longer availability of spares, and lower churn.

[Volker Halle]

Vladimir,

the advantage of using an emulator, if your application and workload fits, is that even if you use 'commodity hardware' with a lower life cycle, you could easily switch to the next hardware product generation later after just re-installing the emulator and copying the disk files and off you go...

Volker.

[Art Wiens]

"you could easily switch to the next hardware product generation later"

As long as Hoff said, you're application isn't tied to some obscure hardware that doesn't work in the next generation. If all you really need is disk and network, there should be no issue.

They will eventually stop making Unibus and Qbus controllers ;-)

I haven't tried the AXP product, but if SRI can make a "VAX" work as well as my experiences with it, I would be quite confident they can do the same for an "AXP".

Cheers,
Art

[Stanley F Quayle]

As a CHARON-AXP reseller [Shameless Plug Alert(tm)], let me weigh in here:

> It's probably not specifically an AlphaServer 4100 emulation, it's some other Alpha system.

Depending on the CHARON-AXP product version, it's a AlphaServer 4000/466, AlphaServer 1000/266, or DEC 3000-600. (Details on http://www.stanq.com/charon-alpha.html) There will be more versions in the future.

> I've also seen folks with j-random j-weird PCI card that's central to their processing

There's an API layer in CHARON-VAX to handle other devices, but no published layer in CHARON-AXP so far. There are even "drop-in" emulators that fit in a Q-bus rack. (See http://www.stanq.com/charon-vax.html)

> HP is (or was?) supporting OpenVMS on the SRI boxes

Is. Support for CHARON-AXP systems was added late last year. Oracle announced full support for CHARON-AXP platforms just a couple of weeks ago. And they're doing all their VAX development exclusively on CHARON-VAX.


I agree with Hoff, you need to think through any possible solution.

If you have ALL your source code, you can go to Itanium, usually. And VEST/AEST can be very helpful if you don't have source.

Where I see a lot of CHARON sales is when people want to save hardware support costs. Emulation can be fast and easy. And it's lots cheaper to support a modern Intel box than an ancient VAX.

Reducing downtime on a critical application is another possibility -- you can get hardware RAID, hot-swappable almost everything (even memory!) on modern Intel boxes.

[comarow]

They can save on hardware costs.

But IF you have a problem, HP will insist on gettng problem reprocued on a genuine
HP system.

I don't care if it passes tests, or anything, you depend on the top level of support, wihch you lose.

[Stanley F Quayle]

> But IF you have a problem, HP will insist on gettng problem reprocued on a genuine HP system.

If you're running on a real VAX/Alpha/Integrity system, you're going to have to provide a test case before Engineering can get their arms around the problem.

> [...] you depend on the top level of support, wihch you lose.

Support is the same as before, assuming you're running on HP hardware.

However, less than half of my CHARON-VAX customers are paying for HP support -- they were "orphaned" somewhere along the way. I don't have enough data on CHARON-AXP customers yet.