Nuke plants to rely on PDP-11 code UNTIL 2050! The venerable PDP-11 minicomputer is still spry to this day, powering GE nuclear power-plant robots - and will do so for another 37 years. That's right: PDP-11 assembler coders are hard to find, but the nuclear industry is planning on keeping the 16-bit machines ticking over until 2050 – long enough for a couple of generations …
These types of deal aren't that unusual. If it ain't broken you don't fix it.
Come 2020 I'll bet there will still be sites getting VMS support.
Just reach for your cheque book.
Government contracts often have very long support plans built into them.
I remember being asked to provide HP-UX internals training in the run up to Y2K for a release than had been phased out in the 80s, because there was still a customer who was on contract.
He who pays the piper calls the tune.
"If it ain't broken you don't fix it."
Bingo. It's the same reason why the computers and processors on deep space probes are frigging ancient by today's standards. The technology may be old and slow but it is *reliable*. Reliable counts for a lot when you're a million miles from Earth or when you're nuts deep in nuclear crap.
It's not the GHz clock cycle that is the problem. It's the smaller feature size of the transistors that increases the single event upset (SEU) rate. Yes, the two are inter-related, but one could conceivably build multi-core, chip symmetric multiprocessors based on the PDP-11 at today's feature sizes and not have GHz clock cycle times (and still end up with significant SEU rates.)
A couple of years ago, a NASA/JPL scientist pointed out that the alpha particles (helium nuclei) from lead solder were causing interesting issues with current x86_64 I/O pins -- radiation issues on commodity hardware.
They're "ancient" even before launch. We routinely handle new kit with rad-hardened CPUs that would have been considered "state of the art" on desktops in 2001.
If it was possible to economically fly core memory, it would still be done. The environment outside earth's magnetosphere is mindbogglingly hostile to electronics (and biologicals)
I would imagine that if these things are bing used to control robotic systems in nuclear power plants, those are the systems which are on the 'hot' side of containment, such as the fuel loading robots and things like that. You could go about replacing the systems that control these, but you'd need to build a robot to do it, because radiation poisoning is apparently quite bad for even field service engineers.
So, you either have a choice of leaving the current system in place until the end of life of the plant, and trying to find some bods who know how to work it, or building a more complex and expensive system to perform a one-off maintenance job inside a sealed reactor at phenomenal expense, and not-insignificant risk.
> inside a sealed reactor
No, they are surely not using a PDP-11 inside a "sealed" reactor. It will be in a human-friendly control room somewhere.
> fuel loading robots
While those are inside the containment vessel, they are not in any sense inside a "sealed" reactor; the radiation level is not unfriendly when everything is functioning correctly.
Okay, my example may be a little contrived, I'm not a nuclear engineer after all. It isn't beyond the realms of possibility, however, that these systems are used to controls parts of the reactor that are not accessible once it becomes hot. If not the robots loading fuel, then maybe those transferring spent fuel to cooling ponds. A properly encased rod of U-235 might be safe to handle before it has spent some time inside the core, but certainly not afterwards!
Although the control systems are obviously not going to be inside the reactor, they have to be connected to these parts. Refitting, testing, and properly certifying any changes to these has got to be a hugely expensive logistical challenge, and I can see where this might cost significantly more than employing people who can maintain the existing working control system, even if that involves training them from scratch and paying them well over the going rate.
I *think* that's the correct sequence, but it has been nearly 20 years...
Should restart a sleeping PDP-11/73 via the serial port - useful if it's been shut off and you're working via a modem.
Supporting a call logger on PDP-11 on RSTS 8.x was where I started in 1994, I'd have expected them to be all gone by now although I think the US air traffic guys had some until after 2000!
Oh, crud. Now I remember ICL VME. I think there are still councils still running VME, although Series 39 has long given way to OpenVME on an x64 host.
To quote the Fujitsu website "2020 is no longer an issue for VME Applications." Not sure if they mean it will work past 2019, or nobody will be using it by then.
Not a zombie OS, exactly. More a sort of... isolated hill tribe of savages that hasn't been seen since the year dot and is barely civilised?
Not just byte sequencing but the bit pattern of floating point numbers. Digital had their own format before the IEEE standard became standard. Sun Microsystems produced a library that would enable VAXes to talk to SPARCs, but I forget its name. It was available on Linux X86 systems which I had talking to SPARCs.
While not a PDP11 issue, the longevity of computers is a concern - and not just for people who want to flog us replacements. At this rate (maybe even exacerbated by the financial crisis) there could well be numbers of old, 32-bit Unix system running stuff when the 32-bit clock counter rolls over and we find ourselves back in the 1970's. With the popularity of small, cheap Linux embedded systems, some of these could be quite difficult to find - literally.
I just hope none of *them* are running nuclear plants
when the 32-bit clock counter rolls over and we find ourselves back in the 1970's.
Depends. Real-time systems don't necessarily need to be aware of the current wall-clock time. "There's an item coming down the assembly line, it needs to be sprayed/welded/have a barcode stuck on/whatever", is not a task that requires the robot to know whether it's 19-jun-2013, 1-jan-1970 or 19-jan-2038.
In the run-up to Y2K, I was told several routers had to be replaced because their firmware was not Y2K-compliant and they couldn't be upgraded to handle the then-current firmware version that was. After a brief check I reported that the longest-running router had still 42 months to go before *it* would hit that particular date which was roughly half a year away on our calender, and that one which had just been rebooted happily lived in late 1993 with no ill effects. From which I deduced that if any of them would ever reach their Y2K-rollover, the worst that would happen was that they wouldn't be routing for a few minutes until they had finished rebooting, just as with any other interruption, the chance of which occurring would be way greater.
No routers were replaced that year.
I mean integers on most archtectures are cyclic, so you might not have any problem. Let me give you an example with a hypothetic 8 bit time.
Imagine it's 250, 10 seconds later it'll be 260-256=4.
Now imagine you want to have the difference between those times. That's 4-250=-246 which will overflow to 10.
So despite of having multiple integer overflows, time differences will still be OK. The only problem exists when you convert it into some other system.
> A well understood, rock solid, stable industrial control system...
Indeed. Few people think of upgrading the control system for their washing machine, why would you risk an "upgrade" (are you going to get more features added to your nuclear reaction?) when there is so much to lose?
Most of the board would be empty apart from traces, and all the work would be done by a small FPGA
DEC already had single-chip PDP CPU's; you could put a large part of what was then still needed as external support circuitry on the die with it today without much effort.
"I've seen circuit boards that are in use well beyond their supported life. Some of them do not survive power cycling as the capacitors have leaked."
SOP for reconditioning/repair services (at least in the contracts we have with a few nuke plants) is to replace *all* electrolytic caps on the board, regardless of condition, with new ones. No part substitutions without engineering approval, of course. From what I've heard, we just get the non-critical (pardon the expression!) stuff that's not involved with the safety of the reactor itself.
Dealt with some stuff that clearly went in when the plants were built. Deal with their spares as they rotate them through the stockroom. Just don't try and get an answer from anyone there during a refueling or maintenance shutdown, seems to be a rather ...active time at the plants.
"I've seen circuit boards that are in use well beyond their supported life. Some of them do not survive power cycling as the capacitors have leaked.
Not a problem as the original Leyden Jars have a service life of 250 years if you rattle them every now and again with a broom handle.
I hear that broom handle replacement is budgeted for until 2025, after which they have plans to poke the jars with a recycled Dyson.
running it, sure it's not a problem
but as the fine article points out, finding people that are able to "well understand" the system to add new features and find obscure bugs (there are only obscure bugs left after 40 years in the field) is a problem
and there's also the problem of longevity of the hardware itself, I don't consider running nuclear power plants using hardware found on a garbage dump safe
Yes, I still have a VM running RT-11/TSX Plus more for curiousity these days. As far as languages cant go past the venerable DIBOL a bastard cross between Basic/Fortran and Cobol. :-)
Loved DCL on VMS, back where 2400ft tapes were new and 450mb drives to 16 hours to backup.
Now are my MACRO-11 skills up to scratch.. hmm
Also the OS lineage for DEC went TOPS - TSS - RT-11 - RSTS/E - RSX and VMS
I wrote comms software for RSX-11S, including a device driver, back in the 80s. That whole structured overlay concept in RSX-11M to be able to run bigger programs was fairly mind-boggling. Luckily I never had to get to grips with it in anger. Thank <deity> for VM these days. I learned a lot about embedded software and general software design on that job.
"Also the OS lineage for DEC went TOPS - TSS - RT-11 - RSTS/E - RSX and VMS"
Well, I can agree that these were all DEC operating systems, but they never ran on the same hardware architectures.
TSS/RT11/RSTS/E and the IAS/RSX families (and various flavours of UNIX as noted by others) all ran on the 16-bit PDP-11 systems, VAX/VMS ran on the 32-bit VAX family in its first incarnation (later Alpha and subsequently IA64 as OpenVMS) .
The TOPS family was of course a very different world of 36-bit systems ... but I'm sure that I have mentioned that before in other posts (!)
Quote
while VMS was born of the multiuser version of PDP.
Ths seems to imply that PDP-11 systems were not multi-user.
This is so far from the truth that it really shames me the level to which accuracy of the El-Reg hacks has sunk to in revcent weeks.
Can't you get anything right? A few google searched would have told you the real facts.
The PDP-11 range of computers was sold with a number of different operating systems
RT-11
RSTS/E
RSX-11M/M-Plus
and a few older ones such as DOS.
RSTS/E & RSX-11M/M-Plus were most certainly multi-user operating systems.
One RSX-11/M-Plus customer had 128 users logged in to one PDP-11/70 with 256KWords on memory doing Transaction Processing (as we used to call it in them far off distant days)
Yes, I worked for DEC (20 years).
I was going to say exactly the same.
And you've missed out UNIX, which was definitely multuser on the PDP-11.
I think the hack was confusing PDP with RSX-11M Plus, which really is the ancestor of VMS.
I was the primary technical support for RSX-11M on a SYSTIME 5000E (actually a PDP11/34e with 22-bit addressing and 2MB of memory - a strange beast) between 1982 and 1986. We had 12 terminals working relatively well on a system that on paper was little more powerful than a PC/AT.
I think I can still do PDP-11 assembler. At one time, I used to be able to decode PDP-11 machine code in my head, although this was mainly because the instruction set was extremely regular. I still would recommend people looking at the instruction set to see how to design one. It's a classic.
>>"Quote"
>> >>"while VMS was born of the multiuser version of PDP."
>>"This seems to imply that PDP-11 systems were not multi-user."
To me it would imply that there were multiuser PDP OSs for VMS to be some kind of successor to, though 'the multiuser version of PDP' does look like a poor choice of words, or a mistake in writing/editing.
> controlled digitally, but this will also have an analogue back-up system
My understanding is that they require N independent control systems that have no possibilities of common failure modes. So they might implement one using digital electronics, one using analogue electronics, and one using hydraulics. This isn't directly because those other systems are "old", but simply because they are "different".
"My understanding is that they require N independent control systems that have no possibilities of common failure modes."
That was the pan-European regulatory stance for many years. The contractors at Olkiluoto didn't like that approach and wanted a variety of shared resources, shared sensors, etc (which obviously introduce the possibility of common failure modes).
Don't know what is currently being proposed at Olkiluoto, or what the current regulatory stance is.
@AC 16:33
>The contractors at Olkiluoto didn't like that approach and wanted a variety
> of shared resources, shared sensors, etc (which obviously introduce the
> possibility of common failure modes).
I got goosebumps after reading that.
I think somebody needs their engineering licence revoked.
>Shit that works, works.
Yes and I am sure the guy that loved vacuum tubes and core memory said the same thing the generation before (or mercury tube memory the generation before that although that wasn't reliable at all). At some point it no longer is economical to build old shit. Yes you can even keep your 1950's Chevy's running for 60 years like Cuba if you have to, but that is not always the best long term plan.
@asdf
< Yes and I am sure the guy that loved vacuum tubes and core memory said the same thing the generation before >
have a look on ebay at 2nd hand valve hifi amps, however if you want a quality one I hope you expect a large bonus this year !
True, but there were still enough oddities (and DEC documentation was still good enough quality) for various issues of the PDP11 Processor Handbooks to have appendices detailing differences between the various implementations. They weren't the kind of thing any normal programmer would ever encounter.
With variations.
They removed the odd-address trap from the PDP11/23. That was a microprocessor architecture, and I guess they ran out of logic gates and had to trim something. Meant that kind of program bug was not immediately detected.
I suppose that's one reason why I liked the PDP11. Just when you thought it couldn't go any further, there it was again in a new place doing its thing. I honestly didn't expect that something like this would happen again after all these years away, but it's a sign of exactly what good design can do for you.
. Just when you thought it couldn't go any further, there it was again in a new place doing its thing
Down in boreholes in Arizona, together with a Device Under Test: a nuclear bomb. Connected to another one topside, equipped with core memory. Even if that one was not expected to survive being tossed about, they could still try and read out the data in memory in another system.
Being asked whether they wanted service contracts on those PDPs (11/23 or 11/03 IIRC), the answer was "Nah, they're just consumables".
Anyone who read the RSX11M sources (driver writers especially) realised that Dave Cutler was a very very good programmer long before he worked on VMS and later Windows NT. He managed to get a multiuser protected general purpose operating system to work with a minimum memory footprint of under 32kbytes on machines with about the same CPU power as the chip on a credit card. (A 96kByte PDP 11/40 (1/3 mip) with 2 RK05 disks (2.4Mbyte each) could support 2 concurrent programmers - a PDP 11/70 (1 mip) with 1Mbyte and 2 RM03 disk packs (65Mbyte each) could support 10 or more.) During the many years that the CEGB used PDP-11 computers with RSX11M, I did not hear of a single OS failure that was not caused by a hardware fault - I wish that current systems were as good.
A few years ago I had RSX11 running in SIMH, so I'm wondering if that's an option for these kinds of embedded and SCADA systems. After all, it's not the software that's likely to fail - it's the ancient hardware, and although there is at least one company out there producing PDP-11 clones it's surely easier to use a simulator that can be modified if an overlooked hardware quirk crops up.
Of course, that was several years after there was a protected, multi-user timesharing system running on the PDP-8, TSS/8. And it would run in 8K of memory, although you had to spring for 12K for decent performance. Swapped off a fixed-head 256K word disk.
You PDP-11 kids get off my lawn!
Why not migrate to QNX ? If remaining on old kit and OS, the biggest issue is hardware replacement. I assume they must have piles of old kit in back of warehouse.. Even then, capacitors age and leak, resistors drift, transformers let smoke out etc. Hardware unreliability will take the best of OS and apps.
I do acknowledge these old machines were built to last. Still remember the only VAX I had to support. Only an anti-tank shell could have hurt it.
It depends on the model, but many of the UNIBUS PDP-11s were built out of TTL (even the CPU and FPU). This means that it should still be able to source and fit almost any of the silicon parts, although I suspect that the most difficult parts to source would be the memory chips.
If they were F11 or J11 systems, you would have to rely on existing parts.
But I suspect that with the state of current chip baking technology and the simplicity of the chips back then, it may be possible to create a pin compatible memory chip using an FPGA relatively easily if it were really necessary.
Hmmm. What a project. Keep PDP-11 alive using FPGAs!
The Soviet Union used to produce PDP-11 clones: the SM-4. I actually first encountered Unix on one of those. It was running at the Helsinki University of Technology in the 1980's. The Unix version was odd, my instructor described it as being halfway between 6. and 7. edition Unix. (I'm not sure if it also came via the SU, or was hacked together at the University).
Wouldn't it be easier to make a hard/software PDP-11 emulator that was power plug and I/O plug compatible with the PDP-11? It would be a lot smaller for a start.
(In the late '70s, as a student engineer, it was my task to boot up a Nova-820 (?) every morning by setting toggle switches and similar retro activities. Ahhhh, those were the days.)
"Wouldn't it be easier to make a hard/software PDP-11 emulator that was power plug and I/O plug compatible with the PDP-11? It would be a lot smaller for a start."
Brilliant idea. There must be a good use for the space saved, and if it wasn't 100% compatible, why - what's the worst that could happen?
"Why not migrate to QNX ?"
Because then the application would have to be rewritten and recertified?
Hardware is probably not the big problem in this picture, PDP11 hardware was generally of sufficient quality and sufficiently well documented that replicating old PDP11 in new silicon (or even via software emulation e.g. via SIMH) would not be a big challenge in general. But in the nuclear industry, special care might be needed (SIMH might not be acceptable, for instance).
Depending on the application, there might even be a master/standby setup to protect against routine hardware failures.
But re-doing the application from scratch, just so it can run under QNX?
Where's the benefit (in these particular circumstances)? There would certainly be lots of cost.
There is replacement hardware available. NuPDP replacment CPU's including QBUS support and peripheral cards. Also NuVAX for the new kids.
The Reviver boards for PDP-11 and HP1000.
The Osprey PDP-11 and Kestral HP1000 hardware from Strobe Data.
There are also the Stromasys/Charon software emulators VAX/AXP/HP3000.
WRT "resistors drift" - that hasn't been an issue since carbon stopped being used - unless you smoke 'em of course.
My experience of transformers smoking is "only if left switched off for long periods - it's usually water which does 'em in and one in use is invariably warm enough to stay dry.
There's a hell of a lot to be said for keeping spares in sealed baggies, or even better in sealed baggies with an inert atmosphere.
In the old days ESR on electrolytics was so high that you'd always slug 'em with a small ceramic nearby. Cost saving/"better design" means that's no longer done, plus they're run a lot closer to their voltage rating (Generally one would use 25V parts on a nominal 12V line to ensure switching spikes didn't take 'em out.) and I believe _that_ is a major contributor to modern failure rates.
Vintage electronics is a field all to itself. There are as many (or more) failures from poorly made joints or crudded up connector pins as there are down to actual genuine faulty components (although I have seen a 1972-vintage audio IC which succumbed to the Purple Plague - once in my entire career of servicing thousands of the bloody things.)
"is still in revenue service"
Well, it was bound to catch on eventually. Did they ever stop it throwing away all the diagnostic info when the stack overflowed? Cheapest panic dump printouts ever.
When ICL were trying to sell it it was notable that almost everyone using a 2900 was running DME, which looked like George.
This post has been deleted by its author
George 3 was excellent......Automatic off-loading when the Filestore was getting crowded, perfect for job control which was much more powerful than IBM's JCL. When ICL replaced the 24-bit 1900 range with the 32-bit 2900 range running VME/B many outfits continued to use George 3 under DME emulation to keep their old programs running.
VME/B was so resource hungry that 1900 programs actually ran much faster than native 2900 ones. Rumour had it that ICL had built in delay loops in the DME emulation to slow it down so as to encourage the move to the native VME/B environment. (But it possibly was just a rumour).
I remember as a senior high school student when my school was given a PDP 8 when the donor - The HydroElectric Commission (Tasmania) if my memory serves me, upgraded to a PDP 11. Ahhhh the heady days of nerds with rolls of paper tape in their pockets so that they could list the first 100 primes, calculate pi to several hundred decimal places and calculate f-stop for other camera parameters. I jest of course but they really were heady days. Scientific calculators cost several fortnights pay, people still knew what a slide rule was and knew how to use one ...........
If the tool still works there is no need to upgrade - just hope there are some ageing programmers from my old school to help out when/if the reactor fails.
The PDP 11 (like the PARC Alto) had a main processor built from standard 4 bit TTL "ALU" parts and their companion "register file." So 2nd, 3rd,4th sourced. I'm not sure how many mfg still list them on their available list in the old standard 0.1" pin spacing.
El Reg ran a story that Chorus (formerly British Steel) ran them for controlling all sorts of bits of their rolling mills but I can't recall if they are
I think the core role for this task is the refueling robots for the CANDU reactors. CANDU allows "on load" refuelling. The robots work in pairs locked onto each end of the pressurized pipes that carry the fuel and heavy water coolant/moderator. They then pressurize their internal storage areas, open the ends and one pushes new fuel bundles in while the other stores the old ones, before sealing the ends. However CANDU have been working on new designs with different fuel mixes (CANDU's special sauce (C Lewis Page) is that it's run with unenriched Uranium, which is much cheaper and does not need a bomb making enrichment facility) and new fuel bundle geometries, so time for a software upgrade.
And 128 users on a PDP 11/70. Certain customers ran bespoke OSes in the early 90s that could get 300+ when VMS could only support about less than 20 on the same spec.
Note for embedded use this is likely to be RSX rather than VMS, which also hosted the ICI developed RTL/2, which was partly what hosted the BBC CEEFAX service for decades.
Yes, it's an anorak.
"The PDP 11 (like the PARC Alto) had a main processor built from standard 4 bit TTL "ALU" parts and their companion "register file." "
Before my time, but I know enough to know that your description applies to a particular model of PDP11 whose number I forget.
Didn't ICI have their own PDP11 RTOS used with RTL in really time-critical applications (such as controlling inputs to a paint-mixing vessel where an exothermic reaction was to take place under tightly controlled conditions, or else)?
Yes, ICI Engineering had various real-time systems involved in plant supervision and/or control environments running on PDP-11 hardware - some of which mutated into wider scope applications running on VAXen.
Ex-colleagues from ICI may be able to shed more light on whether these were running as real-time OS alternates, or under RT-11 or one of the RSX flavours. I recall several VMS applications but not whether any of the real time stuff was ever delivered on the real-time VAX OS 'VAXeln'.
And IIRC correctly these systems were available to the open market - I can remember many visits to the ICI subsidiary (whose name escapes me) in central Middlesbrough in the late 1980s.
Most real-time systems stayed as PDP-11 when the industry realised that the interupt latency on VAX/VMS was too slow for a lot of applications. You could improve it with a ccustomised VMS kernel but, in most cases, it was cheaper to stick with the devil you knew. Similarly, a friend worked for a measuring company that were using embedded PDP-8 systems as controllers well into the end of the 90s. used to drive round with a clip-on PDP-8 front panel in the boot of his car.
Phil.
ICI ran a series of multi-tasking systems written in RTL/2, mainly MTS and SMT. IIRC such a system was built as 'executive' + application tasks as a single image that could be loaded onto the target machine and run from the bootstrap loader. I'm pretty sure the development tools included a pre-assembly linker.
The emphasis at the time was on predictability - typically a refinery or other major plant was closed down for 2 weeks once a year, and all system updates had to be installed & accepted within that period, otherwise it had to be removed and wait for the next year.
RTL/2 was to my knowledge widely used in radar systems, defence (esp Holland for some reason), and what you might call serious civil engineering areas such as nuclear. It failed to survive the GUI revolution.
{ but if anyone knows of any RTL/2 work going... }
Worked at ICI Wilton in the mid 80's on a DEC-20 running TOPS-20 mainframe that took realtime readings of I think the Nylon manufacturing unit (memory is hazy). The machine was 36-bit, and consequently in COBOL you had a choice of defining 6-bit, 7-bit or 9-bit characters (not 8-bit as that would waste too much memory). I was told at the time that there was only one other DEC-20 in the country.
@Tristram Shandy (not PRIME 20!)
I was the Technical Support Manager for the DECSYSTEM-20s at Wilton from 1984 to 1990. You are referring to the PMS system running on HQ2. This application was an early attempt to move up a level from SCADA and other Plant Control layer systems to provide management information at a higher layer. PMS formed the foundation for a later application known initially as PMC and later as 'QUESTAR' which was implemented on VMS and widely used across the ICI group in the later 1980s and 1990s.
PMS took readings (over RS232 async terminal type ports) from some control systems but primarily from VTx00 terminals from plant operators. It was only ever implemented on the Wilton Nylon Inters and North Tees Aromatics plants.
ICI ran three DECSYSTEM-2060 systems at Wilton and a further one in the NETCC at Billingham - there were also a couple of DECSYSTEM-2020s which were more or less inactive by the time I arrived. Before ICI I worked for an East Midlands Polytechnic supporting their 2060 so I do not know where your suggestion that there was only one other in the UK came from. The population (at peak) was at least 30 and they were widespread in the Higher Education sector, including (IIRC) :
Trent Polytechnic
Liverpool Polytechnic
Polytechnic of South Wales
Robert Gordon's Institute of Technology, Aberdeen
Glasgow College of Technology
Bournemouth Institute of Technology (? name)
The Open University (3 sites)
and that is not taking into account the many other organisations that ran DECsystem-10s (including ICI!)
The architecture of the PDP-10 family (including all models of -10 and -20) was indeed 36-bit an d implemented a variable byte length of anywhere between 1 and 36 bits, depending on the byte descriptor.
Its a certainly a CANDU reactor and its fuel bundle loader robots from what it looks like.
CANDU is a different type of reactor than what gets built most of the time, they can burn just about anything, from some unenriched uranium with some slightly enriched uranium at the same time, to thorium, to Mixed Oxide fuels partially from decommissioned nuclear weapons, to "fun" transuranic actinides and also (as a proliferation concern) some quite nasty fuel mixes which can breed massive (relatively speaking of course) amounts of Plutonium if the reactor isn't properly safeguarded. Thats where India and probably Pakistan bred most of their Special Materials.
And what's cool about this is if the PDP-11 is what GE is using in Canada for their loaders, then its probably what they're using in India, South Korea, Romania, Argentina and China as well, as they also have CANDU reactors or designs derived from CANDU.
It's been a while since I was involved in applications on any PDP-11 - although in my time I've supported various models running operating systems including RSX-11S/M/M+/uRSX/20F (that's a give away!), RSTS, RT-11, Unix etc. It comes as no surprise to me that SCADA systems will be using this architecture for many years to come, having had considerable exposure to industrial control systems in the period 1985-2000.
While original hardware configurations must be well advanced in years by now I do recall that rights to develop and manufacture ongoing products using the PDP-11 architecture were sold off by Digital Equipment even before they were acquired by Compaq - let alone HP.
Guess that it's a case of if it works - don't fix it.
BTW: Sad that a Register author could be so confused as to suggest that VMS was the successor to the PDP-11. Somebody needs to understand the difference between software and hardware methinks. Agree that VAX/VMS was (in part at least) the successor of the RSX family - although the RSX emulation/comparability was dropped somewhere in the mid-1980s and was certainly never carried forward into OpenVMS (VAX, Alpha or IA64), it was the VAX-11 (Virtual Address Extension) that was the follow on to the various PDP-11 hardware families. BUT - harking back to 'Soul of a New Machine' - there was an 'emulation bit' between PDP-11 and VAX. (Incidentally, who else remembers attending VMS training where that virtual address space of 4GB [32-bit] was considered so massive nobody would ever have to worry about addressing limits again?)
Okay, writing this from memory (and too lazy to look it up -- apologies). I recall that PDP11 clones are still sold for automation and such -- their architecture is really well suited to controlling peripherals. And to answer a previous response, new h/w+s/w is trivial compared to certification.
IIRC early editions of VMS included 16-bit RSX apps that had been recompiled/linked to support the tree of named directories in the VMS file system, as opposed to the [group number, user number] directories in RSX. This came to an end, I think, with VMS V4 in the mid-eighties.
Windoows 95 did analogous things to get the product out of the door; possibly with Cutler's connivance.
The PDP-11's (and PDP-8's) did not (at least in the late 70's) run VMS, they ran a group of OS's named RTS/E, RSX and Ultrix. Ultrix was a clone of Unix, which was born on At&t 3B systems, which were clones of PDP's.
The PDP (Peripheral Data Processors) were used in process control and industrial automation. They succeeded TI 960 in these applications. Universities and others used the larger boxes to run data centers, and there was a two-chip implementation called LSI-11 that was one the first "personal" computers. The process control application is what the Nuke industry is using them for, controlling the pumps, control rods, indicators and alarms of the melters.
VMS was a creature of the 1980's, living in VAX hardware. I am not even sure there was a PDP version of VMS, but I cannot say because I had moved on to the IBM 370 architecture, or at least the 43xx air-cooled variants. VMS was really for running data processing, either a data center or a PC ("everybody needs a little VAX"). When M$ abandoned OS/2, VMS was cloned into WindowsNT, later Windows2000 and WindowsXP.
You have not been corrected previously because all the programmers from that age who were not teenage hackers are Alzheimers or dead. You are an ignorant GenXY moron. Whine about the Boomers some more, we were Men with Wooden Pencils and Slide Rules who wrote for the Big (and Small) Iron.
What's the saying about no one knows for sure you're a fool if you keep your mouth shut?
Anyway, here we have someone who doesn't know where he's wrong.
Duly noted for future reference.
Bad start was (paraphrased) "PDP8s ran RSTS, RSX and Ultrix". PDP8s ran lots of OSes but not those. And thereafter it didn't get better, even if some of it was nearly right.
"You are an ignorant GenXY moron."
Is herbert a moron? Don't know. Are there memory errors? For sure.
The PDP-11's (and PDP-8's) did not (at least in the late 70's) run VMS, they ran a group of OS's named RTS/E, RSX and Ultrix. Ultrix was a clone of Unix, which was born on At&t 3B systems, which were clones of PDP's.
Total and utter bollocks. With a hulahoop and bells on.
None of the PDP families ever ran VMS. And neither did they ever run Ultrix, because those are 32-bit OSes and none of the PDP families had that amount of data bits.
AT&T 3b's were late to the party, appearing in the late '70's when the groundwork for Unix goes back to 1969. They also were 32-bit systems, implying that they can't have been a clone of any of the PDPs.
Now shut the fuck up, or I'll find a Massbus cable and thread it through your intestine so that it sticks out either end.
Careful! Mostly correct, but aiui there actually *was* an Ultrix11 (a V7 derivative). It may not have been very well known, and you can be forgiven for not knowing about it. So, forgiven you are, and here's a link for anyone interested, back from the days when computers came with real manuals, not just "man pages":
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/ultrix-11/2.0/AA-X342B-TC_ULTRIX-11_SoftwTechDescr_1984.pdf
There was also a PDP11 version of Venturcom's Venix.
"I'll find a Massbus cable and thread it through your intestine so that it sticks out either end."
tee hee.
Systime Computers, the UK vendor of clone DEC kit (definitely VAX, maybe PDP) used to build their stuff around commercial rather than DEC parts where appropriate. You could drive a fork lift truck over a DEC Massbus cable without effect. More importantly you could trap it in between two computer room floor tiles without effect.
The Systime equivalent cable was standard commercial rainbow ribbon cable, which you could barely sneeze at without risking damage, and don't even think about using it in a high risk area (e.g. a tiled computer room floor :().
http://www.brouhaha.com/~eric/retrocomputing/dec/pdp10/photos/2000.10.22/i28.html
Are we bored yet?
Back in 2002 I rescued a PDP-11 that was about to go into the skip. It was a in a large, beige plastic case that looked like an enormous PC, but inside that was a steel chassis fully enclosing the backplane and drive bays. Two massive fans were mounted in the bottom, which seemed a bit odd as they would only be able to draw air through small slots between the case and the stand it was mounted on. I never got the thing working, and in the end I put it up on eBay. The winner drove all the way from Brighton to Oxford to collect it, accompanied by his wife and children. His wife was absolutely livid when she discovered their day out to sight see in Oxford was really an excuse to collect an ancient computer. Turned out the reason why I couldn't get the machine working was that there was no memory card installed (doh!) - what I'd assumed was the RAM turned out to be some sort of daughter board for a multiple serial port card.
The BA23 enclosure, used for some MicroPDP11 and MicroVAX systems.
My favourite memory of it, potentially even relevant here, is that it was one of DEC's first volume systems based around switched mode power supplies (SMPS). One of the less well known features of a typical SMPS is that it may not operate successfully if it is very lightly loaded. Where I was, we sometimes used BA23s with a single card PDP11 (KXT11 something, aka Falcon - processor, boot ROM, RAM, serial comms, etc all on one dual height card) and some data acquisition kit. People used to be puzzled why they sometimes wouldn't power up. Answer: Insufficient load to make the SMPS switch/oscillate. If the SMPS doesn't switch, the system doesn't power up.
A VT103 (a PDP11 in a VT100). Now that's something.
The BA23 enclosure, used for some MicroPDP11 and MicroVAX systems.
Just looked up a DEC service manual online, and you're correct - it's the pedestal mounted one. I'd always thought the BA23 was the squarer enclosure like the one housing the MicroVAX II at my first employer.
Possibly could. be a BA123. BA123 was big brother of BA23, with more slots for cards, more space for storage, but in the absence of hard info, tricky to say which was really described earlier.
BA23: http://hampage.hu/dr/ba23.html
BA123: http://hampage.hu/dr/ba123.html
Two years back we were offered a PDP11 that was kindof stuck in a cellar. It had to be moved out, as the house was being sold (and as the owner was unable to take it with him, it was either to whoever wanted it, or scrap). It turned out to be an 11/44 in a half-height cabinet, with a second cabinet with a 67MB Control Data disk drive with 5 disk packs to go with it, and a Kennedy tape drive.
We had to severely disassemble the lot, until the parts were of a size and weight that you could manhandle up the spiral cellar stairs (they must have been straight when the system was put there; several of the nuts and bolts we _had_ to loosen had never been loosened before). Fortunately one of the guys who came to rescue the system had been a DEC FS tech, and knew which bolts, brackets and other fastening-type hardware had to be undone to get the lumps of iron to separate into chunks that had a chance of getting up those stairs.
It's now reassembled and waiting refurbishing of the diskdrive. The tape drive at least needs its vacuum system adjusted, but that's not as essential. The system itself is about ready to go.
I wonder how many of these "PDP11s" are actually MINC-11s or other instrumentation systems based on the LS!11-series processors?
In a previous role I was responsible for a number of MINC-11s that were interfaced to various things-nuclear, as well as using LSI11/23 processors to control CAMAC crates that again had things-nuclear on the other end.
There's actually a lot of old hardware still out there in embedded industrial applications - someone I know in the 'states still runs a wind-tunnel that has instrumentation systems controlled by a number of 1960s-era Honeywell H-516 minis (Honeywell's equivalent of the PDP-11) and there's still a paper-mill whose process-maagement depends on an IBM Series/1 or three.
One of my freinds graduated in '87. The company that hired him did so to have him write an IBM Series/1 emulator to run on the PS/2. The old IBM machines ran time and attendance software interfacing to some even older timeclocks. Yes this was/is a union shop w/ 30k employees and absolutely reliable timekeeping was required and they were attempting to lower their support contract costs.
I may have said this in an earlier article.
First machine I ever used was a PDP11-45 in my fathers research unit.
Learned FORTRAN programming at a very tender age (which may explain a lot about my subsequent career, and programming!)
Makes me feel good though - who knows I might still have a job at retirement age resurrecting those skills!
We have test systems still running 21MX, and A series machines. Even a few mylar tape readers around. RTE/6 and RTE/A with Fortran apps mostly, some of the apps are in bedrock basic though. 9882A terminals with the tape cassettes and 2621A terminals.
Also have a collection of various HP-9000 family machines. Series 100, 200, and 300. The 100 and 200's are mostly using Basic Workstation or Pascal Workstation (PAWS). The 300's are on HP-UX 6 or 7.
About 30 years ago I worked for a big company as part of my student training. They maintained a bunch of really old computers, and one job I had was to write some code for a dinosaur where you had to boot the machine using paddle switches on the front to load a couple of instructions to read the OS off a 2' wide unsealed Winchester disk. You knew about computer crashes in those days, because you got a bloody great scratch on the disk where the head had run into it.
There were several ancient HP machines, and while I was there, one died. The HP repair man turned up and asked if HP could buy it for their museum. The response was "No, we're still using it!"
The company built stuff which was still in service, and they needed the original machines to test it when it came back for service, without constantly suffering format creep and the introduction of errors from new code.
Like an earlier commenter said, that shit still works, so why change it?
"They maintained a bunch of really old computers, and one job I had was to write some code for a dinosaur where you had to boot the machine using paddle switches on the front to load a couple of instructions to read the OS off a 2' wide unsealed Winchester disk. "
Ah, you almost had me. If you'd have said EDS instead of Winchester I'd have believed you really had worked on a really old computer.
Winchesters were and are new-fangled nonsense that will never catch on. Now load the paper tape into the reader, press the green button and type GO XKYE 20 on the Westrex so we can get some work done, please.
Given the nature of the application, committing to use PDP-11's until 2050 is a really big thing.
I therefore wonder whether GE Canada has done a deal with HP to gain full access (and rights?) to PDP-11 essentials eg. OS source code, circuit board drawings etc.
The follow on question is whether GE Canada will keep such assets private or release them under some sort of open source license...
They don't need to do a deal for the hardware - Each machine came new with a set of circuit diagrams, board layouts and a plentiful array of manuals. Source code - well you usually got a microfilm copy but you had to pay a fairly big sum for a copy on mag tape or disc. Not sure with the RSX OSs but a lot of VMS was written in BLISS-32. I think there was a BLISS-16 but I don't know how much it was used in PDP OSs.
Phil.
Although Mentec now own the PDP11 business on the surface, the original deal was such that there are restrictions on what they can do with the former DEC intellectual property. I can't remember the exact details but e.g. it seems they would be unlikely to be able to open source RT11 even if they wanted to.
Looks as if we're all out of date: Mentec died back in 2005!
There has been much discussion in the dedicated PDP forums about this and it seems that the company XX2247 LLC based in Colorado may possess whatever rights/assets Mentec had - according to 'Johnny Billquist '. However, very little is known about this company and about the only real reference to the company (ignoring company registration) is on David Carroll's LinkedIn page < www linkedin com/pub/david-carroll/13/791/a07 >, but even here no attention is drawn to what xx2247 is about and the PDP commercial assets it may have.
However, it also seems that the exact status of the PDP-11 software is 'murky' and that HP do have an interest in it, but finding someone at HP who understands the situation and can make a decision...
So perhaps Richard Chirgwin (article author) could go back to GE Canada and ask a few more questions.
A nice man from AECL came by one day to talk about the nuclear industry. Essentially, keeping the old stuff running is far far cheaper than swapping in new hardware. New stuff means an extended shutdown and recertification. This is not cheap at all, especially the recertification process. So if some bit of hardware beaks, remanufacture the part.
"New stuff means an extended shutdown and recertification."
This is the biggie with certain embedded tasks, space, defense, nuclear and transport being the main ones.
It's why jet engine controllers still run with Z80s for example.
It's good enough to get the job done (but the devs may have had to use some very clever tricks to a) Handle complex tasks with the available processing power and required response times and b) Prove their solution meets the task constraints.
The trouble really starts when the documentation goes "missing."
One of the reasons I ended up in batch operations (from being a tape ape) was a PDP11/75 in a bank that none of the batch operators wanted to know about since they were too busy trying to figure out the brand spanking new Unisys box (how the bank managed to believe it could replace the Amdahl box I've no idea)
It was cranky. It was "ugly" (in context of the Unisys box). It was "slow". But, in the 18 months I was on that contract it never missed a deadline, never barfed up a failed batch. If there was an error, dammit, that error was in the manual, along with precisely what to do to recover from that error. The single biggest issue with that was keeping the freeping tape drive clean.
On my last week on the contract they asked me why the data transfers between the unisys box and the rest of the farm were so terrible. I noted that they were using "telephone" style cabling instead of something that could actually carry data. They'd gone with the lighter cable since it was 75% cheaper. But no one had checked the run length limits. As a result the data transfers from the PDP11/75 over serial port null modem connections were beating the pants off the Unisys box.
Can agree -- "that shit just works"
It's the underlying bits of physics which are a problem, (i.e. all the bod's who dabbled knowingly at the uranium front are even older than PDP-11 programmers). Theory counts but not blowing something up from experience counts more.
RSX-11 was in no way a multi-user version of RT-11.
Their internals were like chalk and cheese.
the VAX Architecture used a new instruction set. Ok, there were a number of similar instructions but it was all 32bit and 15 General Purpose Registers instead of 8 plus hardware separation of I & D spaces.
The VMS Operating system had (until at least V4) the ability to run RSX-11M/M-Plus binaries. There was no way it would run RT-11 binaries. The image activation procedures were totally different.
I've written device drivers for RT-11, RSX-11(D,S,M,m-Plus) and more latterly, VMS and Ultrix/Tru-64 on VAX and Alpha Hardware si I think I do know a little bit about how they all operate. I still have all my engineering notebook for the period 1978-1999 when I worked at DEC plus a full set of PDP-11/45 schematics.
The Interrupt processing of those really nice bits of hardware (and a whole lot more besides) made them a real pleasure to work on. X86 on the other-hand is a total disaster.(IMHO). I'm so glad that I don't get anywhere near the hardware these days.
Oh, and the BA-123 cabinet made a fine seat. The prototype versions had wooden tops covers. how neat was that.
(Design Engineer of the VAX-11/730 Compact Vax (the one with the TSU05 front loading Tape drive in the top))
There's a story I want to share with you.
I was sent out to fix a VAX11/725, that would quite frequently halt (as in, couple of times per week) for no apparent reason. No crashes, and they would find the poor thing in the morning, powered off I went, checked, found no probable faulty component, replaced a sensor board, but the problem persisted. I replaced a power harness. No dice. We hooked up a logic probe and it, after yet another of those halts, pointed to the airflow sensor. Which was clean, but still, it _had_ triggered the power controller. The intake filters were OK, not squeaky-clean, but I have seen much worse, and those systems didn't trip.
We got a swap unit in (an 11/730) and I took the 725 away to the PRC. Took it apart, cleaned it, replaced every bit of harness that even just looked scuffed, replaced the temp and airflow sensors, and I think I replaced the sensor board yet again, for good measure. Then ran it, without a single hiccup, for two weeks.
So back to the customer it went, the very cleanest 11/725 in all of Europe, and lo, it was halted again the next bloody day. Something that the 11/730 had not suffered from, even though being in the same place, connected to the same power and everything.
Now the time of the halts as seen from the last opcom message would seem to implicate the cleaners, but the system was in a recessed space with its power cord plugged in somewhere behind it, and there was a free wallsocket in plain view for the cleaners to use. They would have to reach over and behind the system to unplug its cord, and plug it back in afterwards; one could think that the 730, being higher, made that more difficult. If that was the modus operandi in the first place, which was rather unlikely. Still, the correlation was unmistakeable.
Dirty power and other such causes had been ruled out in the meantime, so finally a colleague went and sat there, thermosflask of coffee with him, waiting for the cleaners to enter and reveal their nefarious ways. and sure enough, the cleaners came, one plugged the vacuum into the visible wallsocket and started vacuuming, the other emptied the wastebaskets, then took the waste bag from the paper shredder, tied it up and put it aside.
Right in front of the poor 11/725's air intake. Fwump. Clack.
"Right in front of the poor 11/725's air intake. Fwump. Clack."
How much did you get to charge the customer for a self-inflicted problem?
We don't allow cleaners in any of our server rooms because of the risks they pose. The server monkeys have to do the vacuuming, or fully supervise a cleaner seconded for the task and bin emptying is tasked to whoever's working in there at the time (bags go out the door, immediately.)
I've heard a similar story about a 10Mb disk drive which kept shutting down due to the cleaners discovering that the floor mounted air intake was an effective vacuum cleaner for dustpans. What amazes me is that you can have that much dirt in a server room in the first place. I'm pretty anal about making sure they're spotless before anything is installed (including the plenums!) and that seems to go a long way towards ensuring that they only need cleaning a couple of times a year at most. (dirty servers (ie, have served time somewhere else) are "not allowed" in until thoroughly cleaned).
The single biggest problem seems to be a small amount of mud tracked in, and a decent floormat outside plus cleanroom foor-mounted stickypads (imagine a 6 *3 foot piece of flypaper) takes care of that.
We don't allow cleaners in any of our server rooms
Fair enough, but this was not a server room. This was somewhat of an annex to the administration and planning office, with maybe 10 people working there and using that system, the only one around. Mind, this was 1986, give or take a year..
The 11/725 was somewhat of a predecessor of the MicroVAX line, systems meant to be put in an office, next to one's desk. Internally it was as good as identical to the 11/730, but where the 730 was a rackmount system with a cabinet that could take a diskdrive and a particular tapeunit, the 725 had a BA123-like cabinet, with a Rsomething25 disk unit (fixed disk and cartridge combined, somewhere around 25MB each). I can't recall what that cabinet was called.
The real BA123 however was better suited to office environments, with no single air intake that could get blocked by bin bags and such.
The stuff I work on doesn't have that option (You can't tootle off to orbit/venus/saturn/mars/etc to reboot a probe).
Our best programmers are OCD about reliability and with good reason (most problems are caused by power problems or memory errors). It's doable to teach this to modern grads, but it takes about a decade of training before we let 'em near real equipment (vs flight spares and simulators)
Someone above said "Shit that works - works."
Quite right. I worked at a place a few years ago - their HR and payroll ran on a 32 bit x86 based VMS machine. It weighed about 60 pounds and it's uptime was more than 6 years.
Would you run a nuclear power plant on Windows? Mac OS 10? Even Linux? I would not: too many crashes or kernel panics for my nuke plant.
Quite right. I worked at a place a few years ago - their HR and payroll ran on a 32 bit x86 based VMS machine. It weighed about 60 pounds and it's uptime was more than 6 years.
So, the porting _has_ been done, but no-one's been told about it until now.
Are you sure that this wasn't just running VMS on the Charion emulator under Windows? That seems to be more-or-less the way forward that I am seeing in a number of situations where VMS applications have to be re-platformed to something reasonably modern.
No port involved - unless somebody from HP willing to break ranks and confirm speculation that there was a skunkworks project to port OpenVMS from IA64 to standard 64-bit Intel architecture ...
"somebody from HP willing to break ranks and confirm speculation that there was a skunkworks project to port OpenVMS from IA64 to standard 64-bit Intel architecture ."
The rumour is that all those who knew about it directly were forced to agree never to reveal whether or not it existed, on pain of losing employment, retirement benefits, etc.
It can't be true though as no "world class" employer would do that kind of thing would they.
Would you run a nuclear power plant on Windows? Mac OS 10? Even Linux?
No, but I'd give strong consideration to QNX
There are VMS clusters with 20+ year uptimes. (Individual machines are a lot lower than that). No *nix cluster comes close - and a lot of that has to do with the fact that even the most stringent X86/sparc/whatever hardware checking fails occasionally.
Suspension of disbelief is important in such situations. Here are a few more like it:
1. The on-board redundant computers for the space shuttle were 16-bit 2901 bit slice products designed in the 70's. They took an age to program, using toggle switches, and had the compute power of a wristwatch, but they were radiation hardened after 17 years of testing. Now you know why astronauts carried iPads!
2. The air-traffic control systems in the US use computers developed in the 60's to drive the system. Every attempt to fix this has failed because the planners attempted to create new grandiose Star Wars displays etc, instead of focusing on reliable replacement.
3. Well into the 80's, the ATM systems on the East Coast ran off old NCR mainframes. Most PCs are faster today. I'll bet they mainframes are still there. I heard a rumor that the app source code was lost!
4. Speaking of lost code, I did a program for the CIA in the 80s to deliver a write-only printer-shredder. They had a super-secret app that ran a print job once a day, and they didn't want the printout to be seen. With no source code, the only option was to print the report and feed the paper directly into a shredder. The unit met Tempest standards!
thanks for one of the most informative article comment posts ever
my take on this, is that the more you add, i.e. complicate a system then the more it can fuck up
maybe this could be the future (it's probably patented by apple to be fair)
Why not simplify it all to make it foolproof "going forward"?
What are nuclear plants anyway? tumbleweed???
When I did my degree about ten years ago (as a 30 year old - a perfectly mistimed career change if ever there was one), my final year summer placement was at a telecoms firm in Reading. I worked on the billing systems which polled all their main switches for call data records. All this ran on VAX / VMS. Two things struck me about my time there - one that they let me loose on their live billing systems and the other that this VMS stuff was pretty eye-watering and a bit archaic (although fun to work on at a very basic level).
Everything hung on the mainframe (and its failover mirror at IBM in Handford) - I wonder if they still run this system now (wouldn't surprise me - it just seemed to 'do the job').
Never forget that PDP-11 was not the only significant player in real-time systems. The SDS/Xerox Sigma series was a leader in real-time research and control as well as time sharing. Many of the best SDS software developers on CP-V, CP-R, XOS, and RBM ended up on the VMS team. Comshare Corporation made its living on the Sigma 9 for many years, and even resorted to manufacturing their own after Honeywell pulled the plug. Many Sigma 5 and Sigma 7 systems launched Gemini and Apollo missions, and Sigma 5 and Sigma 9 systems were the basis of CUBIC Air Combat Maneuvering Instrumentation systems that revolutionized Air Combat Training and put the visual zing in the movie "Top Gun".
I am one of the few who can still fix one if it breaks, and they are still out there. Call me.
Great boxes. Superior real-time ability. Amazing what you can get done in a small footprint. I was in charge of a machine that had only 80k bytes, and we did LOTS of stuff.
Nowdays, a laptop has more processing power, but doesn't come close to the real-time interfaces.
As for another subject: The time in Unix/Linux is (most of the time) a signed 32 bit number. When it overflows in 2038, it will go negative the other way, and with the given epoch of Jan 1, 1970, will go back 68 years or so to 1902. It will be exciting!
I worked in flight simulation in te late 80's and wrote assemblers for SIGMAs 2, 3, 5 and 7.
Very nice reliable old computers, size of a fridge freezer.
Bet alot are still working away, doing stuff correctly using binary scaling to do stuff we would noe do in floating point
a bit faster, but actaully with less precision...
I designed, partially wrote and helped to implement a system that took over from a PDP-11. They were curiously able machines. However, the system that replaced them was significantly better and allowed continuity that would otherwise be impossible.
Like another poster here, I am not comfortable with a mission critical system running on a PDP-11 even now, let alone decades from now.
Sadly, in practical terms it is a tough call how you would realistically transition out of this particular situation. Stuff built on Microsoft's buggy shifting sands would be a disaster waiting to happen and it would not be that long a wait.
I would be inclined to hire hardened embedded C programmers and a manager and testing team that knew how to build mission critical systems *plus* I would design a failover and failover-failover to be on the safe(r) side.
I would look to purchase a huge indemnity policy on the work to force an insurance company to inspect the system close enough to bet their money on it. That would be very expensive, but considering the downside of failure, I would pay for it.
I would resist the urge to connect the system to the Internet :)
Vaguely recall working on code for a messaging system for Continental Grain on a PDP-11/70 circa 19, uh, 78, maybe. 64KB address space, with another 64KB available in another mode. Very foggy on this...
Then I did IBM Series/1 assembler for a few years. No OS initially, just some utilities called CPS and BPPF. Reboot to start text editor, type disk sector addresses. Reboot to run assembler, similar drill. Debug with membrane keyboard and sixteen bit indicators. Develop a branch banking system. Develop a brokerage trading system. Develop a commincations switch. Get real good with hexadecimal and binary patterns. Ahh... ZZZZZ
Where is the cobweb icon?
"PDP-11/70 circa 19, uh, 78, maybe. 64KB address space, with another 64KB available in another mode. "
11/70 and similar high end members of the family had hardware capability to have 64kB of instructions and a separate 64kB of data. The processor and memory logic knew the difference between instructions and data, and so did software in those days (trickier these days).
The high end PDP OSes let you use it - RSX11M+, and its close friend, IAS.
Alternatively, since the 11/70 and friends could have a whole 4MB of physical memory, then given the right software you could re-map your given 64kB address space into different parts of the physical memory. (RSX called this PLAS for Program Logical Address Space, or something like that).
Real men used overlays, though that wasn't much help with Big Data (meaning >> 64kB of data :))
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/rsx11/RSX11M_V3.2_Jun79/1_Introduction/AA-2555D-TC_Introduction_to_RSX-11M_Jun79.pdf
Kids today, they don't... er how does it finish, I've forgotten.
I learnt to program in Macro-11 on an LSI-23 (and 73) running RT-11 whilst working on an ultrasonic inspection system for material inspection back in the 1983 as a student (sandwich placement). The documentation was excellent, so you could just teach yourself most stuff. I had a superb supervisor (Norman!) who new just about everything there was to know about PDPs. With Macro-11 you could use the assembler to check the args passed to erradicate a huge amount of sillies as assembly time for constant values. So if the calling program passed a value that was outside the expected range (constant), it would error at link time.
I used overlays as well to swap in code required for each particular phase of the program (e.g signal anaysis routines I wrote). Created Macro-11 libraries for each flavour of hardware so we could eliminate the need to change the high level Fortran application (which I also wrote the initial applications for)... Also had to write code to verify the memories in the graphics controller (group designed) for displaying ultrasound scans. It was like VGA performance (actucally better) but about 5 years before VGA was invented...
That system was ROCK solid... Never crashed and just did its job over and over again flawlessly.
Apparently for PDP-8s you had to resort to self modifying code to squeeze more code into the system (e..g. use same loop structure for a count up sequence for a count down sequence)... fun stuff!
The first program I ever wrote was on a 6502 in machine code at college... hex key pad to type it in .. no disk/tape to save it... it took me all weekend to write out on foolscap paper working out all the jumps etc in my head... machine code NOT assembler!...took my 1 hour to type it into the computer by hand on hex key pad... worked first time no errors.. (task was to print out on a dot matrix 7 pin head thermal printer a page of a book ... sw had to pulse the stepper motor correctly and energise the 7 pin head relays....and work out CRs etc..and cope with upper and lower case characters and numbers/punctuation... I had to design my own character set as well on paper over that weekend as well....
We did amazing things back then on very limited hardware ... but you could keep for most part the whole application in your brain and understand what it was all doing... You can't really do that any more...
I started out my computing career programming in a superb decision table language called RPL on a PDP-11, don't remember any RSTS now, but I reckon I could still maintain the RPL code given a day or two to get back into the swing of it. Shame that IIRC RPL didn't make it past the Y2K thing
CompuServe kept their 36-bit PDP-10 computers in production late into the 2000s. By then most of them were clones that were produced for CompuServe's specifications decades after Digital Equipment Corporation stopped making the machines.
They were finally turned off and disposed of in 2009, far outliving most of the line's VAX successors.
"HP has taken issue with my brief mention of VMS's EOL schedule."
I think there have been some mis-communication going on. The article and GE Canada's advertisement was about PDP-11 and RSX-11M, not VAX-11 and VMS.
Perhaps Richard you can get back to HP and get the URL to the webpage containing the support chart for RSX-11M. Also would you kindly get an update from GE Canada about where they are getting support from (see the comment thread concerning Mentec and XX2247).
They should focus their efforts on software to read the PDP11 and convert it to another platform and language. Create a PDP11 simulator to allow testing the old software against the new software running in a newer VM that is sent the same signal combinations to compare outputs. Test behaviour when equipment fails, sensors fail (wrong or missing readings) and human errors. Create tools to assist system design and rule making so it's easier to develop, maintain and migrate in the future.
DEC could have won a major battle with IBM/Microsoft by simply deploying the PDP-LSI 11/73 (like the Falcon board they had at the time) in a Personal Computer form factor and marketing it as an OFFICE COMPUTER. They had a mountain of PDP-11 software to support it. RT-11 would have been an excellent choice to start with. Simple and easy to learn. They could have also offered RSX for their "AT" model. After all most IBM PCs at the time were actually board for offices and research departments. Real personal computers of that time were 6502/Z80 based machines..
Price match IBM and move coorporate customers to the VAX range from PDP.
Then eventually roll out microvax as the "386" range....
the 11/73 as an office computer was the Pro 380 (at least in basic hardware terms).
You never heard of it? Not a surprise really.
RT11? Tick. Worked and was even supported (iirc) eventually.
M-Plus? Tick. Worked (iirc), not sure about supported.
P/OS? Tick. M(Plus?) with a GUI, rebadged as P/OS (no, not that POS, it's for Pro OS).
There's a Pro emulator around somewhere, if you fancy a closer look.
The Pro350 emulator is xhomer. The 350 is based around F11 chipset (11/23 etc) rather than the 380's J11 chipset (11/73 etc). xhomer is based around the multiplatform multitarget SIMH emulator. xhomer is packaged in a build for Linux/x86. Source is available for both SIMH and x86. SIMH runs under Android too; maybe xhomer might run too with a little work.
You can get freely downloadable disk images for DEC's RT11 and P/OS operating systems at the xhomer website, and also for Venturcom's Venix11 which, in case you hadn't guessed, was a UNIX-style OS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
