A tale of mainframes and students being too clever by far
- Reference: 1596438127
- News link: https://www.theregister.co.uk/2020/08/03/who_me/
- Source link:
While some who lived through the 1980s remember it as a freewheeling time of Knight Rider, Magnum PI and, er, Worzel Gummidge, for Register reader Sam it was a period of hard work and code wrangling.
In those carefree days Sam could be found working at a bank as well as attending college through a workplace reimbursement program.
"This bank," he recalled, "ran fairly sophisticated and cutting-edge programs to help maintain a financial advantage over competitors."
Many banks did the same, and Sam told us: "There were several very intelligent and innovative programmers who came up with solutions that involved instructing the computer to do things not envisioned by the IBM engineers of the time."
The problem was that Sam's on-the-job education aimed at squeezing every last drop of performance out of big hunks of IBM metal did not sit too well with what was being taught in college.
The wheels finally came off when, having already annoyed his COBOL instructor "through the use of those new-fangled structured programming techniques", Sam was tasked to write some code requiring the use of tables.
The college expected that some looping code would be used to initialise the table ready for use. Sam knew better: "Through my work I had been shown an easy way to do this using a simple move statement."
Far more efficient but, alas, while the bank ran on IBM hardware, Univac ruled the roost at the college, and the machines did not work in quite the same way.
At the bank, the process would have been handled flawlessly. At the college... less so.
"The result," said Sam, "was to continue writing through memory until the operating system itself was overwritten and the mainframe shutdown nearly immediately and without warning."
When the mainframe recovered, the program request list (including Sam's move of doom) was run again. Again, everything fell over.
"Since everything in memory was essentially initialized," he explained, "it made debugging by the college IT staff impossible."
"I was told they had to bring in the computer vendor's team to figure out what was happening."
Sam's co-workers at the bank, who had shown him the trick, were not overly surprised to learn of the borkage. The hardware was incompatible, after all, but Sam was a tad too green to understand the implications.
And his course?
"The college IT administration was not happy. My instructor was even more unhappy since he felt it reflected upon him personally."
"I did not finish that class. I did not continue my education at that college."
Ever rolled out a nifty trick, only to have it explode messily in your face? Or poked a bit of memory that maybe you shouldn't have? Share your experience with an email to [2]Who, Me? ®
Get our [3]Tech Resources
[1] https://www.theregister.com/Tag/who-me
[2] mailto:whome@theregister.com
[3] https://whitepapers.theregister.com/
Clearing storage may not be good for you
I remember a newish programmer working on a mainframe subsystem, getting a lot of storage (1 GB) and being a good programmer decided to clear it all using one instruction. This was very expensive, as it meant the OS had to allocate the pages on the paging data sets etc. Then because we were constrained for RAM the OS had to page in (and out) all of the storage as it was used. The performance people looked into why start-up was so slow and found this clearing was causing a problem
They found
1) It only actually used about 10KB of storage - not 1GB
2) If you allocate on a page boundary, the storage is cleared for you by the OS - so making the clearing unnecessary.
The "best practices" taught at college were not always the best, more like guidance.
The first best practice is understanding the environment you're working in, not blindly repeating lessons you have been taught.
I'm a Notes programmer. I have been for most of my career now. Back in the 90s, the documentation indicated that, when looping through documents in a view, the old document would be removed from memory.
I believed that and programmed accordingly until one day I was working on a database that had a really large amount of documents that I had to loop through. Somehow, my code was never able to get to the end. I debugged several times, thinking maybe there was a document corruption issue, but the code never failed on the same document. It was incomprehensible.
Until I had a thought : what if all these documents were still in memory and not being removed as I had been taught ? I toyed with that idea for a few minutes and then thought, what do I have to lose ? So I changed the loop structure to not just drop the previous document, but delete it from memory (not from the database, from memory). I tried my code again and it worked flawlessly.
Lesson learned : even official documentation can get it wrong sometimes.
Re: (not from the database, from memory)
ah yes, I remember sometime ago a coworker learning that deleting records from an in-memory array meant it could also delete them from the database, depending on the parameters used for creating the damn thing.... not a fun weekend for him, recovering information from backups and transaction logs.... at least he learned (as did others - natch - by example) that everything should be thoroughly tested before deploying in production, even seemingly small changes.
"even official documentation can get it wrong sometimes."
Or maybe not keep up with changes. Too much trouble....
A question for 'Sam'
Did failure to complete the course impede your employment progress, or did it actually prove beneficial?
Re: A question for 'Sam'
Seemed a bit harsh to remove 'Sam' - unless he decided to stop going himself. Clearly not deliberate sabotage. Could have been a good learning point about machine arch differences &c
Icon: used to work in FE. Have taught day release (not IT). Usually committed students.
The support "get out"
> and the machines did not work in quite the same way.
Which leads to one of the most popular responses from software support teams, when faced with an irate developer who has just wiped their (only copy) entire disk.
"Well it works OK on our system"
Strange association
After high school, I did not want to go to University, instead I did a 2 years technical degree in computer stuff. At the end of the two years we had a couple of months of internship that I did in a lab developing digital cameras for the television. My task was to interface a math coprocessor to a machine running a Motorola CPU, design the hardware, program the driver all in assembler... The students were assigned a professor who was in charge of following what work was being made by the student. For some reason known only to the university administration, the professor working with me was the person in charge of teaching us COBOL. No need to say that he never really understood what I was doing.
Colleges vs. Real world.
Back in the day, we got sent to the local poly to attend a DSP course, mainly so the company we worked for at the time could put an 'Investor in People' sign up in the foyer. Anyway, your man is excitedly telling us how DSP finite impulse response filters work, insisting that it's the only way to make a linear phase response filter. So, I asked him how my 1970's PAL colour TV extracted the colour signal from the luminance signal without using DSP. After I'd taught him about surface acoustic wave filters, I was allowed to sign in each week and then go off to the pub for the afternoon. Cheers --->
Fairly certain I've posted this, but..
Back in the olden days, when I used to run a computer lab dedicated to the then trendy (and always rather vaguely defined) subject of "Multimedia". We had 40 good (for the time) spec machines, and 10 really high spec (again, for the time) machines. The really high spec machines were primarily used for video editing, so each machine had a good sound card, good cpu, and a video capture card with it's own 4 Gig SCSI drive.
All was running well, until one day, several of the applications we'd installed started failing due to missing files. Thinking we had a virus, I started investigating one of the machines. As policy dictates, I pulled it from the network, logged in with the local administrator account. Found that all the image files were missing. Unfortunately some of our software required those JPEGs, GIFS and PNGs, so failed. The virus scan came up clean. Not being one to entirely trust the virus scanner (after all, how did I know that the scanner itself wasn't infected and reporting a false negative?), I put the machine back on the network, wiped it and rei-installed the software.
Sure enough, the next day, the machine had all the software installed, and was working. So, I allowed students to use it. The day after, the problem came back.
I discussed it with my colleagues, one of whom looked sheepish, and said "I know what's causing the problem". Apparently, in an effort to keep the disk usage down, he'd written a script that, overnight, logged on to every student machine, searched for every conceivable kind of image, copied every image to his own HDD, then cleared out both those images and any student browser caches left on the machine. He said he copied the images to his machine because it's *ahem* evidence. We eventually came up with a solution to the problem, in that we adapted his script to ignore the folders that the broken software was installed in.
Thankfully, the 4 gig drives for the capture cards were never made available on the network, so his script could not access them even if it tried to.
Which brings me to a second story. Those capture cards made there drives available to the OS as what appeared to be a normal HDD. I say appaeared, because the user couldn't directly access the data, and it had quite a rigid file system. The root of the drive had folders with various file types (JPG, WAV, AVI etc), and in each folder were the project folders for user work. The weird (and I actually think quite nifty) part is the the folder structure in each of these root folders was exactly the same. The root folders all gave access to the same data, it was just converted on the fly to the data type shown in the root folder. So, your captured video file would be in the AVI folder, and you could access the individual frames in the JPG, PNG and GIF folders, with the audio track(s) being in the WAV folder. Obviously, the conversion, took a finite amount of time, so where as Premiere might take 10 milliseconds to open a JPG file on a conventional HDD, it would probably take a second to open a JPG on this drive (because the card was extracting it from the video on demand).
A student complained to me that his project was taking > 20 minutes to open on Premiere. I thought that was odd , so went to investigate. Now, on opening, Premiere checked all the media in each project, and what he'd done was to import the entire JPEG folder on the drive into his project, then put that on the timeline (Premiere will treat consecutively numbered images as frames in a video) and imported the WAV for the audio track. I explained what was wrong, deleted both the JPEG and WAV folders from his project, then imported the video file from the AVI folder. All of a sudden, Premiere was able to open the project in seconds, because it wasn't asking the capture card to extract and convert thousands of frames.
Ah, the days before memory protection seemed necessary...
VAXen have a block-move assembler instruction MOVC3, which works much like the C function memcpy(). I remember trying to debug a program that would fall over occasionally, and when it did the resulting memory image made no sense. I eventually found that I had the arguments to the MOVC wrong, and when executed it shifted my entire executable program address space by 8 bytes. After that none of the symbols matched, and the debugger had no idea what was where.
At least that would only have affected my local program memory space, VAX/VMS having good memory protection. Way back in Uni we used ICL systems with a home-grown OS. It had an 'ALTER' command that worked much like a POKE in BASIC, and would allow you to read/change locations in your local address space, you could pause a running program & poke around in it. There was also an assembler instruction which would allow you to send a command to the OS from within a program, a la "system()" in modern C. Both useful, but no-one had tried combining them until one of my fellow students did. Turned out that the system() function was treated as I/O, and handled asynchronously, the command was queued and the program paused until it was executed, then resumed with the result of the command. Of course, on a busy system a paused program could be swapped out and another scheduled until the async operation completed. If you passed an ALTER command like that, since the system didn't have virtual memory, when the ALTER command was run there was no guarantee that the address it was changing belonged to the calling program any more...
My fellow student ran his program, and shortly afterwards every terminal in the room hung. Odd, he thought, but crashes weren't uncommon. We went for coffee, and when we returned the system was back, so he tried again. Same result... At that point he had the wit to call the computer centre and say "umm, I think that might have been me", so the end result was a thank-you from the sysadmin and credit for finding a bug, and not any punishment for crashing the main undergrad system twice in an hour.