One of the recurring attributes I have found in the programmer psychological makeup is a strong reaction in the face of being told something “can’t be done.” One memory from my personal experience that comes to mind occurred when I was working on the BLMPS project while serving in the Air Force. After having first been fully trained on DOS for the IBM System 360 and then retrained on the Burroughs 3500 mainframe (that’s another story that I’ll get to in another installment), I and my oldest friend/programmer extraordinaire Ron Field were trying to get some application code to do something or other when we decided that the Burroughs operating system MCP (Master Control Program) should have a feature for what we were trying to do.
We went through the proper channels and documented the request, going so far as to specify the form of the system routine call that would be used in an application program, be it in assembly language or COBOL. In no time at all, an official response from Burroughs was returned, summarily declaring that what we asked couldn’t be done and we should find another way to do what we were trying to do.
Well, that’s all it took. Due to the gigantic nature of the contract between the Air Force and Burroughs (150+ mainframe computers, plus all the extras that can be charged for in a plum DOD contract), the project programming team had access to the full assembly code source of the MCP. Ron and I proceeded to pore through it until we found an unused executive interrupt vector location. Then we exploited a neat (albeit dangerous) feature that the COBOL compiler guys had put into their implementation of the language. One could place a console command into a working storage variable and, by referencing it from a form of the COBOL PERFORM verb, send operator console commands and receive responses as if you were the operator actually typing at the physical console of the machine. Through a series of these steps, we discovered the relocateable memory location of our COBOL application, poked an entry point address into the unused interrupt vector slot, and triggered an executive mode interrupt to that address, upon which the entire machine was now under control of our COBOL application program in executive mode.
We then, just to be cute and prove that we “owned” the machine, caused the master console lamps to flash in some silly little pattern before executing the very code that we needed and that the gurus at Burroughs told us was impossible to do. Needless to say, when we demonstrated our little trick program, the Burroughs guys demanded to know how we had pulled it off. After feeling mighty proud of ourselves, we drug the concession out of them that they would indeed add the feature to the MCP, in return for which we would disclose the secret to our trick.
There are many times I have seen the tightened jaw and steel in the eye of a programmer who is told something can’t be done. I must admit that it is difficult to harness this energy for sustained productive results, but it is real and must reveal something about the inner workings of the programmer’s mind. I’m sure Ron and I could have gotten our program done without this fun little excursion, but our minds didn’t work that way.
Subscribe to:
Post Comments (Atom)
It's always been a special pleasure to accomplish what someone else says is impossible.
ReplyDeleteAlternatively, I can't tell you how many times a developer has said to me "I don't know how to solve that problem. It will take weeks. It will change the whole architecture. It will never be approved." Give them an hour or so to think about it, and it has become an easy 1-2 hour task.
ReplyDelete