Always wondered what the cops used when dusting for fingerprints.
Now I know - and it's good to know.
Welcome to the latest issue of On Call, where readers share their tech support crises and triumphs. And, since it's Día de Muertos and we've just passed Halloween, El Reg thought we'd pick out a few tales for a spooky special. Computer conjuring First up, we meet "Jonathan", who recalls a scary call during his time as IT …
I wish I'd known this after I was burgled - the scrotes nicked some random items including yoghurts, of all things, and a power drill, but left before taking the valuable VCR (this was some years ago). The enthusiastic cops with their aluminium powder caused far more damage to this one item than the thieves managed in total.
Aaaah, depends on whether it was hot-fuse or cold fuse.. (IBM, hot, Seimens cold AFAICR)
When working for a bank as an operator in the late 80s, we often had to refill IBM and Siemens laser line printers, with large plastic bottles of the black stuff. the Seimens refill hatch was on top of the printer and used to have a vibrating system which emptied the bottles. Impatient operators would sometimes assist, giving the bottle a good shake. This often resulted in a big black cloud, and even blacker operator. looked impressive on the white lab coats we had to wear tho..
I used to get the job of refilling some (Fujitsu / Konica?) copiers at our office some 8-10 years ago. I'm not IT or a technician, but know my way around so they were happy to show me and leave me to it.
One day someone else decided it must be easy if a bozo like I could manage it and took it upon themselves. Getting the replacement black toner out from the cupboard, they saw what they thought was a plastic tab to pull out prior to inserting the drum, a la laser printer, except on these printers the toner was designed to be securely placed over the hopper, with the tab releasing the lid allowing toner to fall into the hopper.
The dust cloud, the mess and the stains will forever be emblazoned on my memory as it will the carpet and walls.
Coming up the stairs to the office I met the secretary coming down towards the washroom, with her entire face blackened by toner except a streak under each eye cleared by tears.
The (very old) copier was refilled by spooning the toner into it. The toner had got clogged up. She had realised an instant too late that the way to deal with this is NOT to bend down close to the toner holder and blow hard.
I was wondering how that exec could possibly believe you needed to open the toner cartridge. Still seems like you should know it wasn't intended to be opened and poured in given that it didn't have a simple shape like a jug of milk, but at least his theory about pouring toner might have had some basis in his previous experience had he encountered such a copier - never heard of this sort of thing myself.
People do most stupid things... long ago, a co-worker had to run a program from a 5 1⁄4-inch disk.
The instructions were simple, take the disk out of its envelope and insert in in the drive and then start the program.
He managed to pry the magnetic disk out of its casing and wondered why it didn't work as intended...
@John Brown (no body), @Solo Owl - I once saved a student's thesis by combining those techniques. Student's husband spills coffee on 5.25" floppy, desperate student brings it to tech support (me) for help. Carefully slice open floppy, remove disc, wash gently with distilled water then alcohol, allow to dry, slice open a new floppy, insert washed disc in new case, copy data (it survived!) to another new floppy, return to grateful student with a reminder to keep multiple backups.
I think I have told this story before. Working for IBM, one of the big laser printers installed in the office had a big hopper of toner - like an a3 width Tupperware box with probably a pound of toner in it that you had to remove, take the new one, peel the alu foil off the top exposing the Black Death, and replace in the printer. It’s all fun and games until one of the Printing System Division techs walked back to the support office in blackface and black shirt after sneezing into the hopper mid replace... The director’s secretary was none too pleased about the impromptu printing room redecoration either.
Try working in a building that's still under construction....
After being told to install a couple of computers in a couple of offices located at the other side of the bulding...
I found myself walking down a darkened hallway...
At the end of the hallway was a door I thought led to another office...
After opening it... taking a step forward... and being blinded by sunlight...
I suddenly realised there was no floor underneath my feet...
Only a 60 foot drop onto the concrete pavement...
It turned out it was a fire-escape door... and the ladder wasn't installed yet...
Luckily I managed to firmly grasp the doorhandle and pull myself back in...
Now THAT scared the crap out me !
"“I did, and as I turned around, I realised he was covered in black toner powder from the neck up… I don't know how he did it but he managed to pry open the toner cartridge and blasted toner into his face. He thought the powder went into the printer.”"
This reminds me of a quite recent story.
Small office, single printer, and of course, the recycling cartridge was full. And no, the office manager had only planned for *toner* cartridges, not recycling cartridge.
So, not being an expert, I pointed out to her we need to dispose properly of this full cartridge (it was even written in big red letters "don't throw away in the wild") via the support contract.
But she would have none of it and explained we will dispose "the usual way" and proceeded to show me.
She would go to the men room (yes, men, not women), and dump the whole content in the sink (fumes everywhere) and proceed to flush all out.
I was like, speechless.
users tend not to understand how things work. I worked at a lab for 20 years, one day a senior scientist rang to say the printer on the 3rd floor wasn't printing very well. I just said ok have you tried shaking it you'll get several thousand more prints from it. The response "what the printer?" ermmmm noooo just the toner. Wish I'd said yes and went to see him try and shake a HP4300DTN!
Not as good a story as some of the other toner related ones but it's on topic.
I've been familiar with laser printers/copies since I was the only one who knew how to operate the office copier at my Saturday job. As a result I was unofficially appointed the main point of contact to resolve problems plus do light to moderate maintenance/unjamming. I was also the only one, other than the service technician, who knew how to get in to the maintenance screens but that's another story...
Fast forward to a few years ago in the current Paulf & co. The main A3 colour laser printer/copier device (serving a building with about 200 engineers) was reporting a full waste toner bottle so all printing was blocked. The usual trick of jiggling it about to try and lift it off the weight based trip switch didn't work. I turned to the receptionist/admin and asked if we had a new waste toner bottle. She asked what colour needed replacing? I then had a very painful five minutes trying to explain to her that there was one waste toner bottle for all four colours, with an extended remix of yes you do throw it away when it's full and put an empty one in.
Icon - don't inhale the waste toner.
In my first programming job I wrote code for image-analysed microscopy both for the Department of Medical Microbiology and for the Department of Dermatology at our University Medical Centre. Both departments had a PC with a Matrox MVP-AT/NP board both as frame grabber and accelerator of the image processing we were doing. My code ran flawlessly at Medical Microbiology, but whenever I used the accelerator options of the neighbourhood processor (the NP in MVP-AT/NP), it became erratic at Dermatology. It frequently crashed or froze. After much research, I found the source was the HUGE, clunky Leica power supply for the mercury lamp used for fluorescence imaging at the latter department. It was throwing out so much RFI and polluting the mains supply with a variety of spikes, that the card simply became unreliable. The much smaller, and far more modern power supplies of the Olympus microscopes (for the same type of mercury lamp) used in Medical Microbiology did not cause this trouble. No manner of shielding prevented the problems (probably because the computer had to be close to the microscope), so I had to maintain a special version of the code which avoided the use of the NP unit of the Matrox card. Even then we had to instruct users to switch on the mercury lamp first, and only then boot the computer up. I was so pleased when they got an update to their microscope so they could ditch that horrible power supply, and I could maintain just a single code base of the MVP-AT/NP machines.
Ah, I was waiting for a story where the answer was in electromagnetism. Though I suppose that the EGA monitor which killed its host PC qualifies, although that's self-harming and it doesn't feel "right". And ideally the interfering equipment is on the other side of a wall, and preferably an outside wall. But still... thank you.
"After much research, I found the source was the HUGE, clunky Leica power supply for the mercury lamp used for fluorescence imaging at the latter department."
Was this the stabilized one? Make sure all nearby electronics are switched off before firing it up. It's along time since I used one of those but remember it being a brute.
When I was in college writing the executive for the Dartmouth time sharing system we had delivered an RCA RACE unit for storage. I was told to hook it into the system as a low-priority task when I had time. So I did but whenever I configured the unit into the system (via a configuration punched card) the system would always give an immediate "transfer timing error". The field engineers would run their diagnostics at night and never saw that fault. Eventually we decided that we should get together and figure out what was going on. I knew exactly which card in the card deck (the configuration card) the system would fail so I didn't bother to load the rest of the cards after it. When the system read the configuration card everything worked perfectly and the system asked for the remainder of the card deck!?
I was about to repeat the experiment with the complete deck when the field engineer (who was very good) stopped me and reached over to the card reader and pulled back the hopper and said, " do you hear that whine?" He then ran his diagnostics with the card reader on and pulled back the hopper on the card reader when the diagnostics were running. Instant transfer timing errors.
It turned out that the field engineers ran their diagnostics from tape with the card reader off as it was too noisy. Investigation showed that the speed of a brush vacuum motor was controlled by SCRs and someone had put capacitors across the motor windings to "eliminate" noise. When the SCR fired it put the capacitor across the utility supply line causing 70 volt spikes. This got into the peripheral wires and caused the errors.
We quietly removed the capacitors and things worked better. The RACE unit never did work reliably - shooting out springs and crumpled cards but at least we solved one problem.
In IBM's PCOMMS API, at least the aged version my illustrious employer still uses, there are functions that return phantom "true" values that do not trigger "if Blah= True then" statements.
But... they aren't strings, or ints, or anything else you might see kicking around pretending to be a boolean. They're very explicitly Boolean values. You can see this clear as day in your Locals, they happily work with declared Boolean variables, but they remain unholy ghost-values.
I mean, when they're False, they can be tested for "= False" like you'd expect. But if they're True, they can't be tested for "= True". I spent hours trying to work out what I'd done wrong - surely that had to be a mistake - maybe I wasn't declaring the type properly, or had misspelled "true" in the test or something - but nothing made it behave.
So now, buried in some of my old automation code next to some rather explicit comments is:
If Cbool(Cstr([foo])) != False then ...
As a guess, False is defined as zero and True as anything non-zero. The boolean constant value "True" is probably defined as 1, so if a routine returns, say, 2 then "Blah != False" will be true (if you see what I mean), but "Blah = True" will still not be true.
Maybe the test should just have been "if (Blah) then"?
Just because your compiler and debugger knows it is a boolean, does not mean that the storage for it is only a single bit, it is going to be at least a byte and can hold a range of values. Assuming that False is 0, True is anything that is not False. ie there are many, many values that will evaluate to True. So testing for = True is always going to be a gamble and should never be done. != False is the only safe option, or just use the value as is without the test, let the compiler evaluate it to be being true or not.
"Just because your compiler and debugger knows it is a boolean, does not mean that the storage for it is only a single bit, it is going to be at least a byte and can hold a range of values."
You know, that probably is what was happening. I don't mess with bytes much myself, so it never occurred to me! Thanks for the insight there.
No it is NOT logical. If the compiler "knows" it is dealing with a logical data item, and it does according to everyone involved in the discussion, why in Lovelace's name would the compiler deal with it in a non-Boolean two-state manner?
I get that the data location can hold more than one value. I've been doing computers long enough to have seen real core memory and know how binary numbers work.
But what I DON'T get is why, having decided to allow a programmer to define such a piece of storage for Boolean use, it would then structure a test for true against an unknown exact arithmetic value rather than the one it knows will work against a definable template: "non-zero". The assembly language involved would lean one toward that solution in any event.
And yes I know that in certain one's compliment architectures you can have two non-identical values for zero. Testing against two possible values versus testing against 2 to the power of $BITCOUNT values? Should have been a no-brainer.
Assembler library code is a likely culprit.
That or porting code from a language with strong data typing such as PASCAL in which booleans have exactly 2 values (TRUE and FALSE) to one that defines TRUE as any non-zero value.
Optimizing compilers (particularly early ones) can do strange and unanticipated things to code. Best practice is simply to never explicitly test for a TRUE condition.
I've mentioned it before but the IBM Fortran H optimizing compiler had a neat trick. If you wrote a loop with a rand function within the loop, and didn't change the argument of the rand function within the loop, the optimizing compiler carefully optimized the rand function outside the loop! So it became constant within the loop, which wasn't usually what you wanted.... It wasn't a very good rand function, but making it constant tended to produce odd results!
Biting the hand that feeds IT © 1998–2019