Tech support chap solved knotty disk failure problem by staring at the floor
- Reference: 1724398030
- News link: https://www.theregister.co.uk/2024/08/23/on_call/
- Source link:
This week, meet a reader we'll Regomize as "Emmett" who taught us something new by sending us a story about the time in the early 1980s when he worked on a machine made by a British company called "Trivector".
Despite The Register being very fond of British retro-tech, it appears we have never mentioned Trivector in our long and storied history. We did manage to dredge up this ad for it in the Financial Times, circa 1982.
[1]
Ad for Trivector computer circa 1982 from the FT via Archive.org – Click to enlarge
Emmett told us the Trivector he worked on was acquired thanks to a UK government programme called IT82 that encouraged small business to adopt computing.
IT82 was [2]totally a thing and was named for the year 1982 – a grand one for the British tech scene. It saw the debut of Sinclair's legendary [3]ZX Spectrum .
[4]
Emmett's employer developed medical practice management software that produced the very first printed prescriptions. One of Emmett's clients ran that software on a Trivector that had been acquired under the IT82 program.
[5]
[6]
Emmett described the computer as "a magnificent beast … about the size of a roller suitcase just a bit too large to carry onto an aircraft, and way too heavy to lift into an overhead locker. It had a single terminal and printer attached and was backed up and updated by old fashioned floppy disks."
The machine also had a hard disk – and at one of Emmett's clients that component kept breaking.
[7]
"Trivector sent an engineer to replace the disk three times, and the client was getting very tetchy," he told On Call. "So I was sent from our office in London to investigate."
[8]Client tells techie: You're not leaving the country until this printer is working
[9]Techie told 'Bill Gates' Excel is rubbish – and the Microsoft boss had it fixed in 48 hours
[10]Techie told 'Bill Gates' Excel is rubbish – and the Microsoft boss had it fixed in 48 hours
[11]Customer bricked a phone – and threatened to brick techie's face with it
This was no simple journey. The client was in the city of Belfast, then beset by "Troubles" – the term used to describe years of sectarian violence.
"It was not a place to visit as a tourist," Emmett wrote, and English folk such as himself didn't always feel welcome. When his rental car was checked for explosives on his way into a hotel carpark, his nervousness escalated.
He eventually found the client's surgery, in a tastefully converted Edwardian town house that featured dark-stained bare floorboards.
There, Emmett found the Trivector – on the floor, under a desk that was nestled against a wall.
[12]
"It didn't take long to identify the problem," he told On Call. "Across the room was a bank of filing cabinets housing the patient records which were accessed every time a patient came for an appointment."
As Emmett surveyed the situation, he noticed that every time a file was retrieved from a filing cabinet, the drawer slammed shut and caused the floorboard on which it rested to jump into the air.
The Trivector sat at the other end of the room – on the same floorboard.
"In those days, hard disks were very sensitive – movement and vibration had to be avoided at all costs," Emmett pointed out. It was therefore unsurprising that the Trivector proved troublesome.
"The solution was simple: I got them to move the computer to an area with a solid floor," Emmett told On Call. The client complied, the problem went away, and Emmett made it home safely.
What's the strangest cause of computer errors you've encountered, and how did you fix it? [13]Click here to send On Call your story so we can feature it on a future Friday. ®
Get our [14]Tech Resources
[1] https://regmedia.co.uk/2024/08/23/screenshot_archive_org.jpg
[2] https://www.computinghistory.org.uk/det/49343/Information-Technology-Year-1982/
[3] https://www.theregister.com/2022/04/22/spectrum_at_40/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZshdxixwD3vAPIL68YNY5wAAARM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZshdxixwD3vAPIL68YNY5wAAARM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZshdxixwD3vAPIL68YNY5wAAARM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZshdxixwD3vAPIL68YNY5wAAARM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2024/08/16/on_call/
[9] https://www.theregister.com/2024/08/09/on_call/
[10] https://www.theregister.com/2024/08/09/on_call/
[11] https://www.theregister.com/2024/07/26/on_call/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZshdxixwD3vAPIL68YNY5wAAARM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] mailto:oncall@theregister.com
[14] https://whitepapers.theregister.com/
But luckily, Emmett got to the bottom of the problem quickly
Whoever designed it must have been as thick as two short planks
Did the issue go all the way up to board level?
If he's called Emmett does that mean he was a tourist visiting Cornwall?
Today's breakfast pint is a Betty Stogg's -->
Presumably the garden variety of beer.
The strangest problem I encountered was when the code of an image processing system which worked happily on a (for the day) powerful PC (486 @ 66 MHz, 8MB RAM, and a Matrox MVP-AT/NP image capture and processing board) in the microbiology lab where I worked next to an Olympus fluorescence microscope, borked when running on essentially identical hardware, and same MS-DOS version, in the department of dermatology, next to their very fancy Leica fluorescence microscope. Mysteriously, a previous version of my code worked fine on both. The bad behaviour only showed up when the mercury UV lamp used for fluorescence microscopy was switched on, and only on the Leica microscope. I suspected an RFI problem, but the mystery was why it only hit the new code. Switching back to the old release solved the problem, but the old release was for a Matrox MVP-AT board. The MVP-AT/NP version had an additional "Neighborhood Processor" (hence the additional NP) which was essentially a hardware accelerator for image processing tasks. Not using it caused a significant slow-down in processing speed. The "solution" was to replace the image capture part of the code (when the fluorescence microscope had to be switched on) with the MVP-AT version of the code, and do the offline processing of the data with the faster MVP-AT/NP version of the code.
This was far from ideal, as switching the Leica UV lamp on and off could cause the computer to crash anyway, so the protocol became: switch the computer off before switching the fluorescence lamp on, start the computer up, do your image capture, switch the computer off, switch the UV lamp off, switch the computer on and do the offline analysis.
Interesting.
I did some Terahertz spectroscopy in my MSc, and guess what we used as the broadband Terahertz source for our interferometer? A Mercury UV Lamp..
Electronics have certainly come a long way as far as durability under stress is concerned, but electromagnetism can still throw a monkey wrench into the workings from time to time. I wonder how a modern PC would resist in such conditions.
In those days, hard disks were very sensitive
That reminded me of the first time I moved a computer with needing to park the disk heads first...now that makes me feel old
Came here to say the same. The first PC we got in the lab looked suitably hi-tech apart from the handwritten labels at the top of the monitor and by the power button saying "Park the disc before turning off!".
Same here, I remember having to park the heads before switching off on our first PC (an old 386). I did however rename the executable that did this from the rather boring "DPARK" to "BYE". I was easily amused as a teenager...
>>That reminded me of the first time I moved a computer with needing to park the disk heads first.
was there a bolt in the bottom to fix the spindle as well?
Forgetting to remove said bolt and powering up the drive might have resulted in the escape of magic smoke... I couldn't possibly say.
No... wait... you said "moved a computer" not "moved a hard disk".... as you were.
Icon - it looks like magic smoke to me!
Sandy, Beds
Always caused a chuckle by primary-school-me when receiving info from the RSPB.
M.
Re: Sandy, Beds
I still giggle at 45...
Had a site visit donkeys years since upon - pre PC days, in fact. The client, a research bit of a major oil company, had an ISC3651 colour desktop computer. 8080 based, with a staggering 16k of plug in ROM for the operating system on the A3 sized mainboard and a 50 way parallel expansion port on the back, which we'd plugged into our interface.
This is a similar beast: [1]https://vintagecomputer.ca/intecolor-3600-series-computer/
The client had been complaining of random crashing and muggins was sent up to have a firkle.
Disconnected the expansion cable and extracted the mainboard. Had a close look and no obvious issues. Maybe it was one of the myriad connectors. Reassembled the machine, tested and crash. Rinse and repeat several times, increasing the scope of connector unplugging/reseating.
Crash, crash, crash.
After the umpteenth time I had just reassembled and was powering up when I realised I'd forgot the expansion cable. I reached across the top of the machine to plug it in (ok to do live). As I leant on the top of the case - crash. Lift off hand - back to life. Repeat with the same outcome.
Interesting.
Pulled mainboard again and got a magnifier. Started scrutinizing the board with a really intense scrute.
Found one data pin in one of the plugin ROM holders had never ever been soldered. The pin was just pressed against the side of the plated thru hole
30 seconds with a soldering iron and it was fixed.
And that thing had been running an engine test bed for 2 years like that.
[1] https://vintagecomputer.ca/intecolor-3600-series-computer/
"Started scrutinizing the board with a really intense scrute."
Is that you, Seagoon?
He's fallen in the water
And Join the River Police?
Little JIM!
I had a VCR that was similar - I never did track down the faulty connection (it wasn't as simple as just not being soldered and I couldn't spot any dry joints) but a cassette case wedging the middle of the board down slightly cured it.
about the size of a roller suitcase just a bit too large to carry onto an aircraft, and way too heavy to lift into an overhead locker.
Sounds like a PDP-11 ?
They were Z-80 based. Each terminal had its own CPU, and a "master" CPU to handle the I/O. The removable disk(s) were DRI 4000 series[0], the fixed disks were Diablo something-or-others. The whole thing was almost entirely British Built.
[0] Data Recording Instrument Company, a part of ICL if I remember correctly.
Back in the dark ages when a 486 was the dog's doo-doos, our analysis lab (large chemical company) bought a top of the range IBM tower case. As the bench top was too cluttered for this beast (nearly 30" tall and about 24" deep plus space for the cables) it was installed under a desk. This thing was connected to a set of analysis machines which periodically made the processor run at 100% CPU for 10-15 minutes at a time processing the analysis data.
Then it started throwing wobblies and producing various random errors. It was removed to the IT dept where it worked fine. It went back & forth between the lab and the IT bods for several weeks.
Chatting to the lab manager whish waiting for some results from said machine I realised that it was located up against the hot air duct that provided heating to the lab. The heating would turn itself on and off based on the room thermostat and in this case the computer was sucking hot air into the CPU which was getting it hot enough to start producing errors. This only happened when the machine was running at 100% CPU and the heating was operating at the same time, hence the randomness of the problem.
Moving the PC to the other side of the desk stopped the problem.
Stand back....
To be fair, I think the 486 was the dog's doo-dahs, only becoming the doo-doos when it hit the fan?
We used to blow VAX 11/780 cards regularly
We had a then very new VAX 11/780 installed in 1980. It powered the designed and engineering office, but also extended a terminal to the lab, on the factory floor. This used to run all sorts of funky electronic test equipment. The VAX kept blocking one of the async terminal cards. The engineer kept coming in, humming, harring, but replaced the card. We must have had 4 or 5 in the ifrst year.
The lab was a fair distance from the VAX. Rather than invest in long-line remote options for the async terminal from digital, the machine room manager decided to wire up a very long belden cable which was slung from the window of the computer room, over the heavy machine room, in tough another window to the lab. Fairly cheap, but definitely NOT in the Digital approved way to connect a terminal.
For reasons I didn't understand they used unearthed power leads to their oscilloscopes. All such plugs were colour red to alert people. They also had red painted un-earthed extension leads. And yes, it was into one of these that their RS-232 asynch terminal was plugged. The cable tended to float high, not being earthed. And eventually the high voltage would flash over to the other parts of the terminal concentrator board and blow its TTL circuits.
The solution was to plug the terminal into a properly earthed supply. We never did tell Digital why the problem went away!
Sadly, the computer room, lab, engineering workshop are all destroyed and are now a nice little housing estate on the banks of the Manchester Ship Canal.
Re: We used to blow VAX 11/780 cards regularly
Unearthed 'scopes were often used when working on live-chassis equipment like TVs. Clipping an earthed scope probe onto the chassis of such a device could have spectacularly expensive results.
The correct solution was to feed the equipment under test via an isolating transformer, but they cost money...
I had a PC turn up for a demonstration session. It had been packed in a shipping crate and flown over from the US to the UK. Let's just say it rattled when I took it out of the case. After plugging back in various cards that had fallen out of slots, the machine booted up but flagged errors on the disk. One disk check/repair later, the system booted up OK. So I shut down the computer, stood it upright, powered it on and I saw more errors. Now I don't know why, but I decided to lay the machine back on its side, re-run the check/repair, and all was OK. The system booted fine. Put it back on its base, and I'd get errors. So I ended up leaving the machine on its side for the demonstration session (2 days long). How it made it through I'll never know!
Sounds to me like there was a microscopic crack in a trace in a circuit board, or a break in a wire - depending on whether gravity was working for or against it, according to the angle of the case, influenced whether it wanted to behave or not.
Or a stand-off under the motherboard busted in transit, causing a short to the case on one (or more) of the pins that only manifested itself when oriented "properly".
To be fair, this would be exceedingly rare ... I've only seen it twice.
It sounds like there was a floor in that room's design...