Re: Watsonx?
Mycroft as in Adam Selene, Chairman of the Provisional Committee of Free Lunar?
50 publicly visible posts • joined 22 Sep 2015
A first I think! Responding to a comment by my brother responding to a comment referencing me!
Four years before his time, calculators were barely a thing as I went through (the same) grammar school. I think there may have been some - but primarily used for the novelty effect (what can you spell with numerals upside-down). Anyway - totally excluded from any exams without question. Actually, thinking more about it, I do recall in 1975 (after an enforced "gap year") spending a large proportion of my savings on a high-end Texas calculator prior to going up to Leeds University.
At University studying "Computational Science" (don't ask but I was very much better at the computing elements than the Computational bits - I still have flash-backs to the "Numerical Solution of Ordinary Differential Equations exam in the summer of 1977, where my response really wasn't much more than my name at the top of the paper [but see below]). But, I was heavily involved in running a Student Union campaign to establish a clear set of guidelines for using calculators in exams. I don't remember the exact details, but I think that the key point for me was to establish clear and consistent policy for where and when their use was allowed and when not.
[from above] Numerical Solutions of ODEs: Failed the exam - but got a summer job with the department building on previous work to create a visualisation package that allowed users to define ODEs in a BASIC-like languare, associate them with a library of solution methods and graphing facilities to allow students to see how the solutions worked. I believe it was used (and hated) by two or three generations of students until the Leeds DECsystem-10 was decommissioned. See, analysis of the requirements, design, compiler writing, exploitation of system facilities, (primative) UI and IDE, documentation, user training etc. etc.
Yes, I have a lot of sympathy for this approach too - if done effectively and universally. Indeed, it has to be considered as a fundmental building block for most if not all other subjects.
However, are teachers being trained (and re-trained) to be successfult in delivering it?
I've long believed that "Digital Literacy" needs to be treated the same way as the three "Rs" - Reading, wRiting and 'Rithmatic.
Much in the the same way that (in my day at least) English Language O-level/CSE/GCSE was about practical communications skills and English Literature was more focused on the depths of the subject, so Digital Literacy needs to be about dealing with the everyday use of technology and there can then be a seperate in (more) depth study for Computer Science (or whatever you want to call it).
These days it's barely possible to survive without the ability to work technology - and my guess is that there's few if any mainstream kids who can't, but formalising it and making sure that good practice is drilled into them seems to me to be totally necessary as a subject as compulsary as using written and spoken English (your primary language may vary).
So, any suggestions for what this fourth "R" could be called?
On starting work in summer of 1978, first assignment after induction was to go on a course on "Instructing the instructor". Couple of weeks later off to Bristol to run a customer course on BASIC (XEROX Sigma variant of BASIC, whoch I'd not run across before starting this job) - having attended my graduation ceremony in between!
Best bit of that course was the run on the Great Western mainline to Bristol on a then almost brand-new IC125 (High Speed Train) in First Class - no 1st class trips on a student railcard before that!
I'm sure that I've posted this before on here but that was likely many years ago.
When working on a major industrial site in North East England I was introduced to the PDP-11/34 running employee medical records under Digital Standard Mumps (DSM) based in the site medical centre. Physically located above the blood drainage channel in the (decommissioned!) site morgue.
[1] It was explained to me that when the site was buuld in the 1950/60s, it was too far away from the local hospitals' A&E (Emergency Room) locations and so major accident casualties needed to be immediately treated on site - not everybody made it unfortunately. By the time of my visit in the mid-1980s road improvements meant that hospitals could be reached much more quickly and so the trauma unit on site was closed and the need for a mortuary removed.
[2] I also understand that at one time the company's site across the river used to have a "KPI" based on the number of deaths/month due to onsite industrial accidents. (I'm sure that wasn't the term for it at the time but it fits with more recent terminology.) Now how do you feel about the efforts of your local 'elf and satefy team?
>>> Given that these are likely to be 7 kW (slow) chargers, the biggest problem will be obstruction of traffic, as many of these cabinets are sited in places where parking would be a real nuisance to other vehicles. When they just serve telecoms, this is not a consideration, but it will be.
IIRC many of these cabinets have notices on them prohibiting parking nearby as "24 hour access required".
>>> And then there's the DECSYSTEM-2020 which was an 8080-based minicomputer with a 36-bit KS10 co-processor. So kinda a microcomputer in a minicomputer cabinet with a mainframe co-processor. Poor thing must've had an identity crisis.
Ah ... No. The KS20 in the DECSYSTEM-2020 was always the primary processor - the 8080 had (partially) a similar relationship to the KS20 as the PDP-11/40 did to the KL10 in the various KL10 based DECsystem-10 and DECSYSTEM-20 models. That is to say the boot controller and hardware diagnostic manager, but unlike the KL10s it didn't control any IO other than the primary async console / RDC connections and access to the boot devices. No operating system or user code ever ran in either the 8080 or 11/40.
The 2020 may have had an identity crisis when forced to run TOPS-10 but that's a story for some other time. ADP may however disagree ...
(Was responsible for several KL-based systems at the peak of my career but the onsite 2020 had been decommissioned by the time I inherited responsibility for it and I don't think it was ever powered on again.)
In the summer of 1987 or 1988, I remember the H&V failing in the computer room where we ran some of the key IT systems for parts of a major petrochemicals business on Teesside on a collection of large DEC systems (DECSYSTEM-20s, Clustered VAXen etc). Not only did we grab as many fans as we could find/buy, but we had the external doors open and wet towels flapping in whatever breeze was available to try to keep the humidity up and the temprature down.
Fortunately, within a couple of years we were able to relocate the services into the new regional computer centre then being built about 500 metres away. Must have been quite flexible H&V in there as within 20 years all the systems had been removed and it was being used as an archive store for documents and other media!
>>> But looks less impressive on the Chancellor's CV.
No it won't. A University's Chancellor is typically a figure-head. You are probably thinking of the Vice-Chancellor who is more-or-less the University's Chief Executive. (Title may vary at different Universities but the distinction typically remains.)
In my day at Leeds the Chancellor was HRH The Dutchess of Kent, from whom I recieved my own degree diploma. Today it's Professor Dame Jane Francis.
Interesting quote I saw recently. References relative amounts of energy transported by typical distribution vehicles but gives an indication of some of the potential problems for getting H2 to where it will be consumed. While some H2 supply depots will be connected to pipelines, final distribution to the equivalent of "Petrol Stations" will inevitably be by road.
"A hydrogen tube road trailer carries about one tonne of hydrogen, which is 130 billion Joules of energy. In contrast, a diesel tanker carries typically 40,000 litres of diesel, which is 1,800 billion Joules."
David Shirres, quoted by Roger Ford, Modern Railways, December 2022
Of course, denser tankage for H2 will be developed, but its a long way from 130 to 1,800 Billion Joules!
Funnily enough, my current car is a Volvo V90 and after finding that out the hard way on the first day I picked it up, not really a problem - but as it's a PHEV only filled it up four or five times in the last eight months. It's one of the few remaining physical buttons and not controlled by the touchscreen.
At least on the V90, the (electronic) handbrake button is more or less in the conventional spot under my left hand on the centre console - on my previous V70 it was on the righthand side of the dashboard!
Similar experience some 30+ years ago - probably 1990 or 1991.
During the economic crisis in the early 1990s I'd been summoned for a meeting with the European Corporate Computer Services Group HoD to 'discuss' the budget for the Open Systems strategy programme I was responible for. HQ offices were in Cheshire and I was based on Teesside.
Company concerned (global/empire-wide manufacturing Chemicals, Pharmaceuticals etc) was more concerned with employee safety with so many employees and contractors driving between the Northeast and Cheshire/Manchester/Merseyside each day than environmental impact so had arranged a regular commuter flight (Jetstream 31 typically) several times each day between Manchester and Teesside airports.
So, I booked the standard package of day return flights and hire car from Manchester Airtport General Aviation terminal (then roughly where T3 is today). Arriving off the plane at lunch time I was greeted by the car rental guy handing out keys to the various travellers with something along the lines of "who's the luckly one today!" and instead of pointing me to the typical Ford Orion or Vauxhall Cavilier he showed me over to a Rover 800 Sterling - at that time must have been worth roughly the value of my mortgage!
Off I go for my meeting with Eddie in Wilmslow, feeling very guilty about the potentual cost of the car hire (although in retrospect I expect that it was charged at the booked level rate), get chewed out as expected about programme time and budget overrun and make my way back to the airport, stopping off at a filling station around a mile away (company policy was always to top up cars before return, even where the mileage was low - in this case around 15 miles). Pulling up to the pump I started looking for the filler release: there must have been 30+ small buttons on the central console (no touchscreens in those days, nor Google!). Could I find the relevant one? Nothing I could see looked at like the right one, and I didn't fancy pressing any at random on a car like that, nor was there a manual in the car. Even got out to see if the filler flap was just press to open. Nothing!
By this time there's a queue starting to build behind me and horns are starting to be pressed. Well reader, what could I do? Yes, I got back in the car drove off and returned it without topping off.
Fortunately never got a car as fancy as that one again!
Even more fortunately I never heard any complaints about either the cost of the car or the need for it to be refueled by the hire company.
Following your line - which actually seems to be 180 degrees away from the previous post i.e. DEC OS running TCP/IP rather than still active DECnet situations - worth remembering that the DEC 36-bit family were some of the very earliest ARPAnet hosts. Indeed, one of the DECSYSTEM-20 family options was for a specifically ARPAnet attached system - although I'm unaware of any being installed in the UK or Europe. The KL10- based systems used a dedicated PDP-11 as a TIP (IIRC) - but I don't recall howthe 2020 (KS10) were supported. Never had access to an Ethernet connected DEC-20 so can't recall whether that was an option.
ARPAnet (I'm sure implying IP stack) capabilities were built into the TOPS-20 operating system (I know that I mis-apprpriated the ARPAnet capability bit to implement a more limited security override for academic service support staff than WHEEL or OPERATOR around 1981 for the Polytechnic I was working for at the time.)
PS: not including the non-Digital OS (e.g. TENEX) for the DEC-10 family in this discussion, but most were key early ARPAnet building blocks.
I was an administrator of various types of DEC kit from 1978 to the turn of the millenium. Supported "DECnet" on many of them ranging from VAXen and DECSYSTEM-20s at the high end through various PDP-11 (RSX) and PC systems as well as Ultrix and Tru64/Digial UNIX. Also worked with several third-party implementations for various flavours of UNIX - but never Linux. Saw three/four generations of the DECnet protocols (phases II, III, IV and V/OSI. Was a founder of, and part of, the oversight team for ICI's (remains of ICI form part of AstraZeneca today) world-wide DECnet network for several years.
In my opinion the real inflection point for DECnet was in 1987 with the announcement of DECnet/OSI (or Phase V). Previous versions were relatively straight-forward to implement and support, but were significantly limited in the number of nodes that could be incorporated into the network (63 "areas" earch containing a maximum of 1023 members - routing being either within an area (level 1) or between areas (level 2). However, the OSI implementation seemed to me to be far more complex (at the DECnet level) and introduced (baffleing ?) multi-protocol capabilities (anybody else recall those swines called the DECnis 500/600 family?) including IP support that caused much extra work and needed (IMHO) a significantly higher level of training and understanding to implement a large network.
I'm not saying that the move to Phase V wasn't necessary - if the world had adopted OSI rather then the IP stack then DEC would have been worlds ahead of virtually everybody - with the possible exception of ICL! But it didn't and IP became dominant as we all know, and DECnet was sidelined and effectively died with the corporation in the Compaq and ultimately HP takeovers.
Do I care that support for DECnet (I assume Phase V from the article) support is being removed from the Linux kernal ? To be honest - No; mostly because I left that part of my working life behind more than 20 years ago and left work itself behind seven years back, but also because it's irrelevant in today's IT infrastructure world - with I guess very minor legacy exceptions.
However it's place in IT history should be recognised as an approach to networking in the 1970s and 1980s that was a robust and commercial alternative to IBM's rigid SNA hiearchy. I can't be pedantic about it, but I do believe that for many organisations, their DECnet environment formed a pre-cursor to moving to IP rather than their IBM networks. I know it was for ICI in the late 1980s and early 1990s - even through as the corporate strategy architect in 1990/91 for "Open Systems" I backed OSI in my recommendations rather then IP as the direction for future networks. Clearly I was wrong - but at least I did recommend a tactical adoption of, and full support for, a corporate global IP network until OSI was more widely available - which of course never happened.
RIP DECnet - you did a sterling job but your time is well passed.
The role that wasn't to be...
Shortly after being outsourced to one of the big US IT firms in the early 2000s I was asked would I be interested in a role that basically would have involved spending time hanging around the water coolers (!) with the world-wide pharmaceutical Research and Development centres IT thought leaders and influencers to pick up emerging trends and requirements so that my employer could get involved early and thus ensure that they picked up the business - with appropriate resources and kit bids as and when the project firmed up. NB Pharma R&D IT was almost never the run of the mill off-the-shelf stuff in more commercial situations seen in outsourcing contracts!
So, basically three months of the year in Sweden, three in the US, three in the UK - and I guess three months recovering, training and holiday - all on the corporate dollar!
Sadly, family situation meant that this was never a realistic prospect for me, so had to turn it down. But one can always dream of what might have been.
I was never a PDP-11 specialist, although working with a number of models over the years with RSX, RSTS and UNIX so my memory and the following recollections may not be 100% accurate.
I don't believe that Digital ever produced a SCSI interface for UNIBUS and hence for the PDP-11. There were certainly third-party products (EMULEX?) and I can well believe that an 11/84 (which was a relatively late model) could very well have been supplied with such through an integrator (e.g. SYSTIME in the UK but far from unique). Any systems with an RM03/05 and TU77 would probably date from the mid- or late- 1970s contemporary with PDP-10s and 11-7xx series VAXen, and would likely have been "larger" models (11/70 quite possibly) given the size of the MASSBUS interface.
MASSBUS was a pretty horrible interface anyway, and at my first job the US-parent had invested in third-party equipment to connect strings of IBM 3330 equivalent drives to their PDP-10s (KI and KL models). In many ways quite glad to see the heavy and inflexible cables superceeded by the quite effective UDA and HSC connected RA/TA series disks and tapes with much thinner and very flexible cables.
Recall the time when working for the previous identity of a now well known Covid Vaccine Manufacturer, one of the systems - IIRC one recording adverse drug reactions - needed a significant (for then mid-1990s and just before SANs became generally available) storage upgrade. Kit was ordered by the application team and consisted of a significantly large (48U? and very wide) cabinet stuffed full of StorageWorks controller shelves, disk shelves and circa 150 4GB (could have been 9 or 36 its that long ago) disks - so you can imagine the weight of it. Muggins here was assigned to take delivery and arrange installation and commissioning.
Anyway, come the day I'm waiting for the delivery all afternoon and eventually the truck turns up sometime after about 6 or 7 o'clock in the evening. Met the crew and directed them to the back entrance of the relevant computer suite and pointed out the doors through which the unit will need to be pushed. So, the crew parked up the truck and started to remove the packaging so that the unit can be rolled on its castors. They then pushed the unit onto the tail lift, fired up the engine and started to manoeuvrer the whole ensemble up the access road (backwards) towards the doors. Unanticipated consequence by the crew is that the storage unit is swaying side-to-side through frightening angles.
Watching from a not-very-safe distance I'm by now having visions of the whole lot toppling over, falling off the tailgate and ending up with the mother-and-father of all disk crashes. So I'm shouting at the delivery crew to stop but to no effect. I can't now recall whether somebody jumped up and tried to stabalise the cabinet or what but somehow it didn't topple off and delivery was eventually completed, and the truck and it's crew departed - after me telling them their fortunes if the kit is damaged.
Naturally, we kicked up a bit of a stink with the distributors over this incident and if I recall correctly it turns out we'd applied so much pressure for a quick delivery that they had had to use a non-specialist transport company and hadn't briefed them appropriately.
We made sure that we ran a very full set of diagnostics and bedding in on all the kit before final commissioning!
Actually, there's quite a good record of third-party applications picking up data provided by Network Rail and other parties in the railway operations sector. The success of apps such as "Real Time Trains" (and many others) is a good example.
As once a frequent traveller into and out of London Euston, it was very useful to know which (changed) platform a train would be using before it went up on the indicator boards and thereby avoid the masssed crowds waiting in the main station area for the service to be called. Many's the time I was able to be right at the front of the queue at the barriers when they opened (or even on the train before they did!)
Recent developments in RTT I believe even give data on the actual operaton of individual services and can show why they are being delayed by the running of the train in front (very limited areas or the network right now).
It's been a while since I was an insider with IBM GTS, but I think that while there were some very troubled contracts within the GTS parts of IBM (I should know as I was part of the team that did performance reviews on SO and ITS contracts for ten years) - and indeed a few that went really sour and were terminated and / or ended up in court - they typically were not the deals that are occasionally reported here in El Reg.
In most cases these big contracts were systems integration, application development or managed process services contracts that would have been led by parts of the organisation that are being retained within what remains of IBM. Sometimes they would use GTS as internal subcontractors but my take is what mostly went wrong was at levels above the core infrastructure that GTS would have been involved in delivering.
And, for what it's worth, in my experiecene (and YMMV) there were many, many GTS contracts which were simply successful for both IBM and the customer. There are not many good Register headlines in deals that delivered what the customer wanted, at a cost that they were willing to pay and to acceptable levels of service.
>>> our tale takes place some decades ago
Even the best and worst outsourcers had to learn from their experience. Having worked on both sides of the story, going far enough back (some decades?) the service was generally "all inclusive" of routine and stuff that could be considered day-to-day support and maintenance - which was what you expected as a customer of a managed service.
As time went by - and I guess little projects got larger and larger - they realised that this was a revenue stream they should exploit. Working for ten years before I retired from one of the big outsource players, in a bid and contract review team I knew most of the cash generating "arrangements" that could be used in outsourcing contracts! Many customers' buyers got wise to this in second (and later, if you can belive it) generation contacts which led to some "interesting" negotiations - and subsequent disputes!
Personally, when TUPEd to one of the big players in 2001 it took a lot of "eductation" to convince me of the way that the Request for Service process should work, as previously I'd been part of a central team delivering consultancy, service development and project management to the various businesses in the group as part of corporately-funded overhead.
Looking for pennies in the coat pocket to pay for the extra services ...
I'll post it as nobody else seems to have done yet.
Network Rail's recent proposals for Traction Decarbonisation (PDF - link below) proposes only about 1,300 Single Track Kilometeres (STK) of the network would be served by hydrogen fuelled passenger trains, as against 13,000 STK proposed for electrification For the rest of the currently un-electrified network, perhaps 800 STK for battery operation and 300 STK where they can't make their minds up yet.
Energy density means that hydrogen is unlikely to be viable for main-line freight and future shunting locomotives are likely to be plug-in electric and battery.
https://www.networkrail.co.uk/wp-content/uploads/2020/09/Traction-Decarbonisation-Network-Strategy-Interim-Programme-Business-Case.pdf
And then came the Alpha .... but not in a sensible rack-mount for a couple of generations. Not until the AlphaServer 4x00 series if I remember correctly. While HP's rackmounts for the D- and K- series were a bit of a fudge Digital Equipment's approach was only a bastardised shelf-mount for the smaller boxes (headless workstations, 3000 AXP and AS 800) and possiblly the 2000. No way the 2100 or 4000 (Cobra family) could be mounted in any standard rack. Of course I'm discounting those models that were built into their own cabinet (7000 AXP and later).
Back in the day (1970s) and on a Computational Science (!!) degree there was a requirement to take a subsid subject each year, so in my first year I opted for the Data Processing module, which included an introduction to COBOL as a fairly major component. TBH it was much of a doddle as a course and (thanks to a copy of "Teach yourself COBOL" studied during a gap year) I was really quite bored and on occasion was fairly somnolent during the lectures. On being woken from my slumbers by the lecturer and taken aside after the session to be told off, I remember saying how poor the module was - and that I'd get a first without effort. And I did: mind you, the only module over the three years that I did!
Having graduated I started work at a Timesharing Services Company which had recently been spun off from a major engineering consultancy based in the south London area and which had been acquired by one of the middle sized US computer bureaus and was transitioning from Xerox SIgma systems to DECsystem-10s (which I'd been hired to primarily support). Anyway, they were also looking to broaden their business and landed a contract to implement a booking system for one of the UK Holiday Camp firms. A contractor was hired to write the central portion of the system (interfacing with remote Datapoint terminals in the camps and company offices) in COBOL. Not one to break code into sensible sized modules, he created a massive main COBOL module running into '000s of lines. Took overnight to compile though! Not one to shirk from a challenge I offered to try to get this down. Turns out that the DEC compiler writers had made use of a remarkably inefficient algorithm for sorting the internal symbol table - which for various reasons it seemed to do in each of the several passes it made through the source COBOL. Replacing that sort module with one rather more efficient (bubblesort replaced by shellsort if I remember correctly) cut overall compilation time from several hours to about 20 minutes. Job Done! Very grateful that I'd kept my Knuth and a couple of other similar text books.
Later working at a midlands Polytechnic I was to come to despise the COBOL class work brought along to the program advisory desk run by the Computing Services team to support teaching across the institution - but that's another set of stories.
Sadly been there back in the early 1980s being responsible for the systems support of a timesharing mainframe at a UK higher education establishment and had to spend considerable effort trying to address activities such as these by 'enthusiatic' (and in some cases 'malicious') members of the student body. While ultimate discipline was down to the academic authorities (not Computer Services) it was necessary to identify the core offenders and generally to take them aside and explain the impacts of their misdemeanours on others. Bearing in mind the very limited resources available (2 x 76 MB disk drives (RP04 formatted for 36 bit use) supporting a community of 20K plus students - yes you read that correctly : two sub-one hundred megabyte disk exchangable disk drives - any mis-use had an immediate impact. What was equally apparant was the distress on other (shall we say less clued up) students if their account was 'taken over' and they were unable to complete coursework. Sometimes more drastic action was needed of course but generally trying to deny access to the system was non-productive as they would generally have access to multiple accounts as a result of their actions.
Of course, now of that would have applied to the activities under taken while a student myself a few years earlier at a different establishment with an even smaller and more limited system.
Close but not quite. APT was designed by BR Research at Derby (significantly by people recruited from outside the rail industry) - The IC125 (HST) was the product of the established engineering teams (BREL if you like) and was indeed an internal industry development as a fallback as it wasn't clear if the APT would ever make it into service. When introduced in the mid-1970s it was as fast as the Japanese bullet trains and (I think) still holds the world speed record for a diesel-powered production train.
The IC225 (Class 91) was actually an evolution of the APT power car and experience by then had shown that it could safely be positioned at one end of the train in a push-pull configuration with a driving trailer at the other. If you look carefully at the Mark 4 train-sets you'll see that while they don't tilt (as the APT designed to) the profile was such that it could have been added or included in later builds. However, 225 KPH (140 MPH) was never authorised and so they've never run at the nominal design speed.
Agree very much that access to administration systems should have been better controlled; however so rusty that I cannot recall if it was possible to restrict access to sub-sets of members of a single VAXcluster with a single UAF. I suspect that something could and should have been implemented to keep user accounts to their authorised systems!
Brings to mind a situation at one of what is now a Russell Group University back in the mid-1970s when parts of the student body took it into their heads to occupy the administration block over some political matter (Overseas Student Fees, if I recall correctly). Anyway, there we were in the middle of the night in various parts of the admin area (based in what was then said to be the longest corridor in Europe) when I realised that a small bunch of hot-heads had broken into the administration computer suite and were about to cause significant physical damage to the disc packs they found in the room (some variety of mid-sized ICL 1900). As a computing mainstream student I could see the potential for many types of 'own goal' if they went any further. Thankfully, with a bit of 'persuasion' I managed to get them to leave things alone and cause no further damage.
Spent the rest of the night re-fighting the Wars of the Roses (Kingmaker-plus) in the Vice Challencor's office - while carefully not inhaling the various substances being passed around.
And the rest.
Back in my first job (late 1970s) was working in a time-sharing bureau (sort of cloud on a single machine) which also had an application development department, and had a colleague developing an early client/server booking application for a holiday camp company. Grand programmer, but not in favour of writing code in separate compilable modules - umpteen thousand lines in a single COBOL program generally took the best part of overnight to compile! Clearly, he's not happy and I guess neither were management or the client. As in those days it was quite normal for the source code of the system programs (including the COBOL compiler) to be distributed, I spent some time profiling how the compiler was working and concluded that the bulk of the time was being spent sorting and re-sorting (virtually every time a new overlay of the compiler was brought into memory) the symbol table for the being compiled code.
Looking at the coding of the sort routine, I saw that it was the most basic sort possible (Order n^2 or worse) - so looked out my recently discarded University textbooks and re-coded it using a much more efficient algorithm in what I thought was really neat machine code exploiting the machine architecture in some "interesting" ways. Compile time for the application dropped from several hours to circa 20 minutes. Still not brilliant (breaking up into modules was really required) but at least several compile runs became possible each work session, rather than the one or two previously.
I did submit the revised compiler code to the manufacturer (Digital Equipment) as a "bug"(sorry, Software Performance Report) but I was never sure if it was incorporated into the production compiler as I never ran across such daft sizes of application design in the remaining ten or so years I continued working with DECsystem-10/20s.
Queen's Belfast used to do a similar thing. A script allocated 200(?) new accounts at the beginning of the year, of the form "aaaannnn', and assigned passwords through a predictable algorithm. If there were only 160 new students that year you knew the alphabetically last 40 accounts & their resources were there for the taking by whoever changed the password first. After a while, most of the hackers had 10-20 extra accounts available.
Been on both sides of this one. As a student in the mid-1970s it was fair game to collect as many PPNs (can you guess which OS?) as possible to extend the miserable CPU and storage allowances handed out to even full degree Computational Science undergrads - things got better in the final year when I unaccountably failed to close down the staff account I'd been allocated for working on a departmental project over the summer vacation; pissed-off the post-grads when they realised that I'd also been allocated a full Electronic Computing Labs (ie support staff) account on the ICL 1906A (:ECLAJG) running George 4.
Later, working for Trent Poly, I wrote the system that took extracts from the student course registration database and pre-loaded the accounts at the start of each course year. I'm hoping that I'm remembering correctly that the default was to allocate a pseudo-randomly generated password. However, whatever it was any degree of security would have been negated by the fact that each student was given a card with their username and password printed on it! I know for a fact that these were (mis)appropriated by all sorts of nefarious characters from various departments! (We had ways of watching you...)
Once upon a time the August Bank Holiday was uniform across the UK on the first Monday in the month, then for some in-explicable reason (something to do with evening out the bank holidays through the year) in England and Wales it was moved to the last Monday.
I know this for I was born on the bank holiday Monday when it was in the right place in August. Mind you, my late Mother used to claim that I'd never done a stroke of work since ...
Total Baloney! Platform allocations are easily available to the general public from the likes of RealTimeTrains.co.uk (*) and have been for several years - RTT even flags up changes from the standard plan. Used to be very useful at major stations like London Euston where announcements were made only a few minutes before departure - if you were in the know you could be at the front of the queue at the barrier (or, in fact, sometimes able to wander straight on to the platform as the gates were open from a previous arrival!).
(*) other similar services are available.
Reminds me of the occasion (circa 1982 or 83) when Trent Poly in Nottingham relocated its Computer Room into a converted college Library over the summer vaccation. Kit being moved included the single-decker bus sized DECSYSTEM-20 timesharing mainframe, with associated free standing disk and tape drives, all of which required a specialised County-level DEC LCG Field Service Engineer to supervise.
Anyway, the relocation project was planned in detail and the lifting gear etc planned to turn up with the heavy gang with a limited amount of time and, of course, on a fairly tight budget. Time factors also quite critical as the old room had to be handed over to have asbestos cleared out.
So, said LCG engineer turns up day before the big move and comes in to check out the new computer room. Looking around he's generally satisfied with the room - and then he tells us to lift up some floor tiles to check the under-floor void. Suddently he turns round to the Head of Department and sundry others with him and says: "No way is that machine moving in here with that floor!". He bends down and wipes his finger across the real floor and it comes up covered in dust to demonstrate what he means.
Turns out that when the room was convered, the existing parquet flooring was sanded flat, cleaned and vaccumed and then left in that state.
Rapid discussions came up with a plan that the floor could be sealed by varnishing it. Shortly after that four or five of us are piling into a car and haring off to a nearby DIY store and buying up almost all of its stock of large tins of floor varnish and brushes. In the mean time others in the department are busy starting to lift all the floor tiles.
By now its mid-afternoon and M-day starts first thing the next morning.
Teams of members of the department work through the night - with the bulk of it being done by the head of Application Services - and the whole job is just about finished by dawn the next morning. Mind you, anybody spending too long in the room would be high as a kite for the next few days with the vapours given off by the drying varnish.
So, actually a happy ending to the story. All systems were moved during the planned window and we were able to get the service up in time to prepare for the new term. That was until several weeks into running in the new centre, when it was discovered that the "wrong type of air conditioning had been installed" and we had to have a kettle boiling in the room at times to increase the humidity to a level that worked for the kit ... but that's a story for another time!
Actually, while one obviously hopes that there's no basis for worries about interaction between public-facing Wifi and internal train management systems, it has to be said that recent rolling stock is heavily reliant on digial systems rather than older (physical or analogue) controls. Examples of this type of train would include the Thameslink class 700 (but that's safe 'cos DfT excluded Wifi from the specification), the Crossrail (Elizabeth Line) class 345 Aventra from Bombadier and the various classes 800/801/802 Hitachi electric / bimodes on GWR and to be introduced on the East Coast Mainline, TransPennine Express and Hull Trains over the next few years.
In addition, we're seeing the first stages of ETCS (level 2 and above) implementations starting to introduce on-board electronic signalling which will in time replace the conventional line side colour light signals across Network Rail. On the Thameslink core route (between St. Pancras International and Blackfriars) ATO (Automatic Train Operation) will be "driving" the trains in order to meet the planned increase in throughput in the next year or so. Not that ATO is in anyway new as its been used on metro systems throughout the world, and in a simplistic form since its opening in 1967 on the London Undergroud Victoria line.
Not in a position to comment on how much security has been baked into the designs of these highly complex systems. Doubtless there will be those amoung this community who may be able to comment further.
Yes, I've seen a tape drive go up in smoke.
Trouble was that it was a full cabinet 9-track, reel-to-reel TU77 or TU78 (DIGITAL Equipment OEM of a Pertec drive) which literally went "BANG!" and flames and smoke started pouring out of the back of the cabinet. This was back in the 1980s when infrastructure in computer rooms was somewhat less sophisticated than now. Despite this being one of the UK's largest manufacturing companies, conditions in that room were at the time hardly state-of-the-art and each device (CPU cabinet, disk/tape drive etc) in the computer room was wired to an individual isolation switch on the wall of the room - no such thing as a REPO or even very much in the way of fire detection in the room. And I was alone in the room at the time (although there were operators in the adjacent room).
Actually, not much damage was done as I managed to throw the however many power switches there were to turn everything off and grab a reasonably appropriate fire extinguisher and had the fire under control before the on-site fire brigade (well, it was a major petrochemicals site on the banks of a large river in north-east England) arrived. I cannot remember if there was an active Halon (or similar) system but I don't think that it was used, or whether it was installed after this event.
Investigations by DEC Field Service found that a large, power smoothing capacitor had exploded in the three-phase (?) power supply which was the root cause and the insulation on the cables had caught fire - hence the volumes of smoke.
Shortly after this we started installing "proper" power distribution units and had one of the first VESDA systems in the UK installed. We also ended up getting some extensive fire training based on that provided across the production site.
While management were happy that the incident was contained rapidly and damage limited (the computer room contained several DECSYSTEM-20 and VAX systems vital for various areas of the production site and the division's commercial operation), I ended up on (not in!) the carpet for exposing myself to unnecessary risk by tackling the incident rather than retreating to safety and waiting for the professionals.
Funny thing is that much later in my working life I ended up as a risk manager for one of the international IT companies...
(Icon based on content rather than being p....d off etc!)
Are there really only eight major communting routes into London? No mention of any of the Kent Lines (including as already noted in another comment, HS1) nor Chilton, North Thamesside (C2C), Overground, Great Northern or the northern Thameslink services to Bedford. Are they better or worse than Waterloo to Southamption (and what about the many branches off the old LSWR mail line)?
And since when was Euston to Glasgow considered as any kind of commuting route to London? At several hundred miles long there must be a significantly variable service - although I do seem to recall that WTWC arehave providing some kind of additional mobile signal boost in their trains when they were refurbished.
Seems either sloppy reporting, or that the origional survey didn't think through how to describe its work across the national rail network.
Or even the similar floating-point problem with the DEC VAX (8600/Venus family I think) circa 1988? Recollections of my then employer's chemical engineering department having to re-run significant amounts of safety-critical design related computations over a period of weeks and months on alternative (slower) VAX models. In the support teams we ended up scheduling low-priority batch jobs running tasks with known results set up to flag re-occurances of the problem as it wasn't failing consistently.
DOGS (Design Office Graphics System) from PAFEC.
I oversaw commissioning of the system circa 1983; previously Trent ran a similar system on a PDP-11/40 under RSM-11M.
Personally had moved on from Trent Poly by 1986 to ICI who ran multiple PDP-10s, mainly under TOPS-20 as DECSYSTEM-20s.
From a different era ... when ICI (for that is the company of which I write) built the site after WW2, safety standards were not what they are today and part of the risk acceptance involved in building and operating plant was the fatality rate - I understand that pre-war in other Teesside plants this was measured on a weekly basis. Given that the road network in the area meant that transit times to the town hospital would have been 20-30 minutes, the site had a medical centre capable of handing quite major trauma incidents, and sadly this had to be included.
Having served (prior to recent retirement) as a project / contract risk assessment and quality assurance manager for one of the major IT services companies, it was sometimes salutatory to remind solution development teams that risk sometimes involves more that just financial impact. One of my favorite stories (from a colleague originating from the site discussed earlier) was her discussion with a team solutioning a new IT-based site-wide toxic gas alarm system (I forget for which company). Going through a risk identification brain storming session with the team she asked the question of the team : "what's the most significant risk involved in this project?" Back came the typical responses: late delivery, cost overrun, dissatisfied customer and the usual stuff; until she pointed out that if the system failed to work reliably what about the dead bodies across the site when they were not alerted to an incident?
Obviously there's more to safety critical systems than this, but an area of increasing concern with current developments in the industry.
When working for large chemical company on Teesside in the mid-1980s we had a PDP-11/34 (running Mumps possibly appropriately) installed in the site Medical Centre - in the no longer used mortuary. Positioned directly over the blood drain channel.
Just think what the BOFH might make of those opportunities!