10 posts • joined Thursday 30th December 2010 10:46 GMT
Actually no. It was the other way round. The Turbomotive (LMS 6202, BR 46202) was first rebuilt as a conventional locomotive and was then wrecked in the crash at Harrow and Wealdstone.in 1952.
It is widely understood that the loss of 46202 (named 'Princess Anne') led to the decision that one class 8P locomotive could be added to the Riddles designed BR standard programme. And so Duke of Gloucester (71000) was authorised. Many debates on how effective and efficient 71000 was in its BR form and post preservation a number of flaws in the original build have been addressed - or not depending on your bias / point of view.
Try looking here http://www.5at.co.uk/
There are several areas where 'Advanced' steam has been taken well beyond where British main-line steam ended in the 1960's (and most of North American steam locomotion several decades before that).
Having said that, I think that there are too many obstacles relating to infrastructure (water supply for one) and maintenance that would make a return to steam non-viable in the 21st Century as a front line method of mainline traction.
And the I.T. angle is ... ?
DEC legacy kit
Picture 5 is certainly, as it proclaims, a KL-10 (A or B model) which is the CPU unit of, in this case, a DECsystem-10 which was the blue variant running TOPS-10, as distinct from the orange version which ran TOPS-20 (DECSYSTEM-20) - (KL-10E). KL-10 based DEC-10s also were different from DEC-20s in that they booted from DECtape where -20s booted from RX01 (5 inch) floppies - in both cases using a PDP-11/40 as the primary front-end computer, and -10s had external memory busses while -20s had internal memory. (Exception for the purists who remember these things, the 1091 was indeed a blue 2060 and did boot from floppy - I think that there was also a -1095 with the same relationship to the 2065.)
If picture 8 isn indeed the central backplane wire-wrap of a KL-10, then I have an enduring memory of having this Field Replacable Module' being replaced not once but twice on a DECSYSTEM-20 (2060) in the mid/late 1980s for ICI on Teesside. Shipment on a pallet some 3m x 1.5m x 2m as I recall!
In addition, Digital eventually shipped us a 2065 (and then downgraded it to 2060 because I'd never go round to upgrading the OS - failing to maintain n-1 is nothing new!) diverted from initial installation to keep us running until the main machine was eventually fixed.
PS: If anybody wants a picture of it, I have part of a KI-10 control console in my garrage!
A maze of twisty little titles all alike
Not on the main point ... but Tru64 and the associated TruCluster products never ran on VAX hardware ... it was always an OS for the Alpha platform, and to the best of my knowledge never successfully ported to any other architecture - despite HP's worst efforts!
And in any case - who cares about HP-UX any more - post the Oracle debacle isn't it going the same way as Tru64 anyway.
And BTW - anticipate that the reference to September 2009 update should read 2011?
DECsystem-10/DECSYSTEM-20 : the argument was never settled
"Decsystem-20 -- the poor man's Dec-10, running Tops-20 (Tops-10 with a different hat on)."
There was of course considerable rivalry between the supporters of the two (mainstream) operation systems for the "PDP-10" family. (Other operating systems were available - but not from DEC). There is a recorded view that the DECSYSTEM-20 was indeed marketed at a smaller customer than the equivalent -10, and the -20 never evolved to support multiprocessing as the -10 did in the 1088/1099 models (two KL10As back to back). Where identical hardware (1091/2060 KL10-E) was deployed, you could probably attach more terminals to a TOPS-10 system. But perhaps that was the blue paint.
However, the two operating systems were significantly different. TOPS-20 was perhaps one of the most interesting Operating Systems of its generation and the internals were completely different from TOPS-10. TOPS-20 was perhaps even more thread and process driven than UNIX, and exploited virtual memory and mapping techniques that were not seen in other systems for another 20 years. There are a number of accounts available of the evolution of early versions of TOPS-10 into TENEX (with the addition of university developed paging hardware for the KA-10), and then ultimately into TOPS-20 at the hands of Digital themselves with the introduction of the early KL-10 - but -10 and -20 models ran different microcode to provide the different virtual memory management required (-10s were an evolution of the KI-10, -20s had the full native mode).
What is true is that many utilities and applications (including many DEC products) were shared between the two platforms and the availability of a compatibility package (PA1050) provided with TOPS-20 allowed aspects of the TOPS-10 stack to run under TOPS-20. To the best of my knowledge, native TOPS-20 code could never run under TOPS-10.
Both TOPS-10 and TOPS-20 were however evolutionary dead ends, sad to say. My memory is beginning to fail, but my recollection of TOPS-20 was that the bulk of the OS code was written in MACRO-20 and was highly tailored to the unique PDP-10 architecture with its 36-bit word structure. Extending memory addressing beyond the 18 bits provided in pre-KL and on the KS models always appeared to me to be a real kludge. (I generally found extended sections to be more trouble than they were worth.) It was this dependence on the hardware architecture that would have really prevented movement to other hardware architectures - as was proven as UNIX developed. It is perhaps sobering to recall that VMS went through several major re-writes during its lifetime, and that the OpenVMS that was ported across to originally the Alpha architecture by Digital and later to Itanium under HP (I'm still waiting to hear if it evers makes it to x64) bears little source code resemblance to the V1.0 version VMS that shipped for the VAX-11/780 in 1977.
(mines the one with 36 pockets)
No sorry, the KL-10 was by no means 'cool'. How many times did we find our DEC on-site Field Services rep curled up having a kip in the KL-10E (2060 ie an orange one) expansion cabinet? Very nice warm comfortable spot if I remember correctly among all that ECL logic!
Talking of KL-10's, was the 'Massbus' replacement CI and Ethernet option the most expensive NIC ever? My memory is of the order of $36K (Thirty Six Thousand US dollars) in the late 1980s.
DEC's contribution to storage and other memories
Yes, many interesting memories over the years. Here's one that few people may have realised was possible. Back in the late 1980s a certain large British (nay imperial) chemicals company was implementing a 'market intelligence' system based around the ALL-IN-1 products. Availability was wanted fairly much 24x7 (yes, it was on a VAXcluster) however as anyone who has designed infrastructure to support ALL-IN-1 will recall, it was necessary to ensure that the whole of the file store was backed up while fully consistent. That really meant shutting down the system and trowing all the users off while the backups were performed. Our solution was to use the (RA8x) disk mirroring capability of the HSC storage controllers to break out a member of the mirror-set(s), mount it up and run the backups against those volumes ... then of course re-sysnc them back into the mirror sets. EMC BCVs eat your hearts out - this was when EMC2 (remember the 2 superscript?) was still a bit player selling add on RAM and other boards. I still have the glass tankard given me by an EMC2 salesperson to prove it!
I guess that alongside the other great Digital systems I've worked on from DECsystem-10 and DECSYSTEM-20 of various flavours (including having a Jupiter order canceled under my future employer when the LCG part of DEC was killed in 1983 - does any body in the UK remember the York meeting when this was commincated?), a number of PDP-11 hardware variants and operating systems, virtually all types of VAX system (save the 9000 which ought to be explicitly called out in the list of DEC super-losers) and through into many flavours of Alpha with both VMS and Unix, I stayed an advocate of Digital storage through to the end of the true StorageWorks era and participated in the Digital Storage Fellowship programme.
So, like many others on this and other threads I too owe a considerable debt to Digital Equipment Company. Although I have never worked for the company, the skills and attitudes have left me well positioned to meet many career challenges. Even today, working in an outsourcing business it is still fun to run through asset lists from contracts to see how many VAX and Alpha boxes are still running out there. It's far more than many people might expect.
Actually, that could be a real pain if you had a mixed bag of a cluster. Our first (V4) cluster included a 11/785, 11/750, an 8600 and an 8700. You didn't want the 750 to own any of the master capabilities (including mastering any distributed locks) if you wanted any decent performance!
Happy (and simpler) days!