Well, in answer to a few private e-mails, I guess I should really give you guys the $0.02 rundown on who I am, and what I do for a living. Probably not interesting to most folks, but it may make it clearer where my background is, and why I am so intensely interested in simulation.
I'm just a newbie in the industry compared to some of you guys - I got involved in the civilian computer work around 1984. Before that I bounced around the Atlantic ocean in a Navy P-3 aircraft looking for submarines.
In 1984, I entered the civilian world, and went to work on flight simulators for Singer -Link, Simulation Systems Division. Loved it, but decided I wanted to program, so they moved to programming the simulators. Loved that, but I really wanted to work on the software out in the fleet, so I went to work for Systems Development Corp. As a side benefit, I got to fly my own software with the fleet upon occasion. Best of both worlds. Never looked back. :)
During the period I worked for SDC, (which was owned by Burroughs, and became Unisys..) I got the wonderful opportunity to work on dozens of projects, some of which I even got management experience with. This included converting fleet software production off punched cards - which was my first task. Also found myself running the data center, buying and using Suns, Vaxen, BTOS, and other odd machines, as well as doing real-time Ada programming, assembler programming, designing and implementing an image system, Nextgen Weather Radar, and oh yeah - writing a computerized tax refund system. Don't know how that last one snuck in there...
Really guys - I was *lucky* beyond belief. I worked on dozens of projects, everything from replacing the onboard P-3/S-3 computer to building a new building for the office, and everything in between. But eventually they docked the Russian fleet, and while I have no compunctions at all about self defense, I do have moral and religious convictions that make me queasy about working on purely offensive systems, and that is without any question, where I was heading.
Fast forward a decade or so, and having wandered through several industries, including being the VP for Software Production for a nice sized publishing company, writing software to manage alarm installations, a bit of COBOL for a life insurance company, and writing some nicely profitable software that does recurring billing and such.
Mot of all, I really love being a consultant, and moving from job to job always finding something new, challenging, and interesting. However, I do NOT like the ugly task of collecting monies from customers who think "Due on receipt" means pay about 120 days later.
So I looked through the available job offers,and we landed here in Texas.
I really didn't like the huge corporation attitude bit, and I really chafed at some of the stuff going on there, so I decided to find another job- and, purely by luck, walked into the job I have now.
I work for a medium sized insurance company down here, and my official title is 'Sr. Software Engineer.' What that really means though, is I do everything from manage the acquisition of most of our IT hardware, to design and install the networks, to program in Mainframe Assembler, to well - you guessed it.
Originally I came on board here to just convert and old Wang to a system running on an RS/6000 based simulation system. I even told em that was only staying around for about a year. :)
Well, once I got there, it turned out that what we really needed was a mainframe configured under some special circumstances. My VP said "No! We will NEVER have an IBM system in this building." The CEO said "We WILL NEVER have an IBM Mainframe in this building..." I said, "Okay guys... but... "
Anyway, I installed the mainframe back in November of 2003. Took me 18 months to talk them into it, and to get IBM to sell it to me... <grin>
Here's the interesting part: I do have a lot of mainframe background, but in OUR shop, we needed more of a interactive system than a typical z/OS system will provide. Also, we didn't want to pay the overhead hassle and cost of a full time z/OS system programmer.
Actually, an HP3K would have been an ideal computer for us, but there was one little problem, the applications were running on a Wang, which is an IBM mainframe, processor wise. And, there are a couple million lines of application code - all written in *assembler*. That meant I had to have an IBM mainframe compatible processor, or an emulator, for that code to run on. Obviously, I checked out all the mainframe emulators, and decided that if we used one, Hercules would be it. Open source, darn near PERFECT emulation, and the guys who really started it, Roger Bowler, is a nice guy.
But IBM came up with a really sweet deal, and we purchsed the very first mainframe that was sold to run only Linux.
Today, we run multiple instances of Linux on the mainframe, using z/VM, which is a fantastic hypervisor; it leaves Xen and VMWare and Parallels in the dust.
What we did is very similar to what Peter suggests; we built an application framework that supported all the existing application code. With a few very minor changes in the existing code we were able to move code over the mainframe to run.
A lot of those changes were easy to automate too.
But - we had to write a terminal handing package. Sure Linux has a GUI and a TUI based system (curses), but those run over pure telnet (or ssh) protocols, and you find that sometimes a screen will refresh in a jerky manner, or pause, or do other unacceptable stuff. So we wrote drivers for the application code to use 3270 green screen terminals. That was a lot more work than you might think. :)
Then we had to write indexed and sequential file handling- because as you know, Linux doesn't really have a clue about record based file formats. File opening, sharing, locking, and so forth are all possible under Linux, but they don't always fit the model that you are coming from. And application software can be so finicky, just because someone else deleted the file it was using without warning... tch!
And there are literally dozens of other issue involved too, such as process control, inter process communications, message queues, console, batch processing, etc. All of which Linux does have answers for, but we needed to put a spin on to support all those lines of application code, that expected things to happen the Wang way...
We succeeded of course (you didn't have any doubts did you? :) and the system is faster than greased lightening, and easily capable of supporting 10 to 20 thousand simultaneous users, as well as batch processing, dynamic Web processing with assembler language CGI programs that even drive Ajax based screens... :) And it runs image processing, the web/ftp servers, DNS for the company, and more as well.
The system is well proven, we took on eight times the processing data we started with due to an acquisition. The mainframe, the application framework, and the applications all handled the dramatically increased load without a problem.
----
And conversely, we also purchased a Wang emulator that runs on a PC box on top of Linux. The emulator runs a Wang OS and Wang binaries perfectly, and emulates all the hardware on the Wang - in software - and interfaces to the Linux services and devices. But it carries with it the limitations of the Wang, which the home grown system we developed does not.
We ran into a problem deciding how we wanted to implement alternate indexes on the Linux framework, and then we ran into an acquisition and SOX and a few other things, so it turned out cheaper to buy an emulator to run some of the programs for the next year or so. It also gave us breathing room.
So I have both types of systems running in my shop today. The full emulation is definitely easier to deal with, and kinda cool to use.
However, the framework we built supports extending our applications into capabilities we had never thought of before - such as supporting hundreds of hand held devices in the field.
The framework is far more valuable, but also, far different from the original Wang system. Hardly any of the original managment techniques for the Wang will work with the IBM. That is both a plus and minus point. :)
------
Anyways, that of course does not really cover a fraction of the details, but it is a great example of a success story doing what Peter proposes.
Again, my limited HP3K take, is that it might be better to build a full function emulator, and then start expanding the OS by calls to the underlying Linux system through the emulator. It would be much more familiar to most people.
But doing a "framework" port straight to Linux would also be very VERY cool, and a lot of fun.
The Xen idea is great, but I would personally tend toward (if it were possible) porting the entire OS to x86 and then hosting it inside a VMWare ESX Virtual Machine. This would allow for only a very limited number of necessary hardware drivers, and yet still take great advantage of every new platform. I suppose XEN does something like this also, but I am not as familar with it.
I just ported our software to run on OpenVMS last year, and it has been a good choice for me, as I can put highly reliable machines out in the field, and depend upon them working for year without the usual Windows problems.
I think an emulated, simulated, or framework based HP3K product would be a natural fit into the vertical markets for some industries myself. Take a lot of encouragement and work to make it happen and then be sucessful though.
-Paul
Yours,
-Paul
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
