Installing the Emulator: Ahoy, the Disruptor
Looking for MPE Expertise

Running a Freeware Emulator: Just Ducky

Editor's Note: I asked several HP 3000 veterans to see how well the installation of the new freeware version of the Charon HPA/3000 emulator worked for them. In yesterday's article, Alan Yeo of ScreenJet led us through a weekend-long journey to get the right VMware and a 2GB Player-ready file onto a server, rather than a desktop. A genuine HP 3000 played a key role. Now with an ISL> prompt on his screen, Yeo plunges forward.

By Alan Yeo

Second of two parts

Okay, so with no documentation at hand (as of last weekend), let’s try ISL>START NORECOVERY

This starts the MPE launch, I get prompted for date and time which I correct, and it continues with a normal 7.5 launch, right the way through to starting JINETD and logging on as OPERATOR.SYS.

You know what they say. "If it looks like a Duck and quacks like a Duck, it’s probably a Duck," and this thing looks like an HP 3000 and would have probably quacked like one if it could.

As far as I can tell I'm sitting at the console of an HP 3000! I’m running in a Putty Terminal, so I'm not going to be able to do any block mode stuff, but it’s good enough to run a whole load of MPE commands and have a look at the created environment. Yes, it still quacks!

I don't want to try doing too much perched on my stool in front of a rack in the computer room, so can I access this thing from our network? Immediate answer, is No. It is configured with some strange IP address, so I need to reconfigure it for our network. On an HP 3000 easy just go into NMMGR, but that's in block mode and I'm connected via Putty. 

Looking around the screen I see another icon, which turns out to be for xhpterm (a nearly usable HP Terminal Emulator). I launch it, up pops a colon prompt and I logon as Manager Sys. So far so good, let’s try NMMGR; it loads and runs and I do some basic network configuration, validate and exit — and darn I have lost my connection as the IP address has changed. Now what do I do? as I don't seem to have any way to change the IP address that xhpterm is using, and my Putty window has disappeared somewhere.

Let’s try connecting from a real terminal; nope no luck, looks like I have broken this, maybe this demo version only works with its fixed IP? Anyway back to the i7, and decide that I'll shut down the VM and maybe reload. It may have been me but I couldn't find a way to shut down the VM without saving changes, which I didn't really want to do as I had obviously screwed something. So I saved changes. 

I thought maybe I'd have to blow the files away and re-extract the CHARON files again, but I thought, well let’s just launch it again! I did, it went through the boot sequence again, during which I spotted that the new IP I had set had taken effect, and magically when I launched xhpterm again it connected. They must have configured it to use the current IP address of the emulator.

Can I get to it externally via Reflection now? Yes! Okay, now we are "Cooking with Gas." (For those non UK readers you'll have to Google that). File transfer a bunch of stuff, and everything works!

Think I'll finish tidying up in NMMGR, but it won't run from Reflection! Why not? What normally stops NMMGR running? Yep, hptypeahead was turned on, but how — I hadn't done it and it’s not a default. A quick search shows that this box has a whole bunch of SYSTEM UDCs set including:

option logon
setvar hpsysname 'CHARON-DEMO'
setvar tz 'PST8PDT'
if hpjobtype='S'
  setvar hptypeahead true

Now fine and dandy if I had actually been in Pacific Time, and if I had wanted hptypeahead set (I NEVER have hptypeahead set!).

Bit of a cleanup job to get rid of UDCs and replace with a set from one of our HP 3000s. Driving an HP 3000 with someone else's UDCs is rather like walking around in someone else's oversize boots. They are still boots, they keep the water out, but it just feels a bit uncomfortable, and you can't run!

I do a bunch of file transfers and restores, some COBOL and Transact compiles, restored a database, ran some programs, everything worked. And to be honest I didn't expect it not to!

For those of you thinking of trying the emulator, don't waste your time trying to find something in MPE that doesn't work properly, or a program that gives different results, You won't. I know this sounds too good to be true, but it isn't. 

I was fortunate enough to have Mike Marxmeier explain to me a year ago how a hardware emulator works, and basically if you can get the OS to boot, it’s a done deal and anything that runs on that OS hasn't the faintest idea that the hardware has changed. And this is the real MPE we are booting, not an emulated MPE. 

The only thing that is emulated is the hardware, so the only place where there might be problems would be in handling peripherals, or possibly the interpretation of error codes from them. Believe me, way beyond my capabilities or desire to go investigating.

So we now have a virtualised MPE 7.5 HP 3000 running on an Intel i7 server (which we have called "Sharon"). It only permits two concurrent users (hey, this is the free version) and I'd defy most people to logon and know that it wasn't a real HP 3000. 

I don't know what the final hobbyist version of the CHARON-HPA 3000 package will look like, as I was just being used as a guinea pig tester by Ron. However, this 7.5 box came with all the subsystems I needed to do anything I wanted. If the final hobbyist version doesn't, then unless you already have a 7.5 box with an MPE license then it will be virtually useless to you. 

CHARON-HPA 3000 is exclusively 7.5, so you won't be able to take subsystems of your aging 6.0/6.5 9x7/9x8 and use them. My opinion is that for the Hobbyist Licensed version this shouldn't be a problem, as it’s restricted to two users so it’s not like HP would be opening the floodgates on the use of unlicensed subsystems. What’s more, anyone moving from an earlier version of MPE already has a licensed version of them anyway. However, HP is a strange company these days, so I guess we just wait and see what happens.

Commercially, I'm sorry it works, as it will give people more excuses to homestead instead of using ScreenJet's software to migrate. Personally, I like it, as it sticks two fingers up in the air at HP and says "see, if you had wanted to keep all those HP 3000 customers you lost it was technically possible.” And who knows — as ScreenJet's Transact and VPlus migration products also run on MPE, and we now have a new MPE platform, maybe there may be emulator customers interested in advanced versions of Transact or VPlus with all the bugs fixed. And versions that are far more capable than the original HP versions, and are supported!