Re: "Why a copy of Office is needed on a PC tasked with showing line information is anyone’s guess"
Nope, at London Victoria it would have to be third-rail power point.
18 posts • joined 22 Sep 2015
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!
Biting the hand that feeds IT © 1998–2019