8-Bit Software Online Conversion

A hopefully diverting piece from Chris Robbins - K4U This is something I wrote years ago when I was still usefully and gainfully employed in the world of mainstream computing, when Bill Gates had only a few millions to his name and most windows were still of the glass variety. It was written with other programmers in mind (but hopefully will nevertheless prove of interest to other members of 8 Bits) and concerns my even earlier experiences as a mainframe programmer, back in the days of punched cards, paper tape, and large air conditioned computer rooms where the mighty mainframe e.g. IBM 360s and 370s were housed in almost clinically clean comfort. These now antique monsters consumed vast amounts of electrical power, but had a performance that Clive Sinclair's or Alan Sugar's electronic offerings would have laughed at. SOFTWARE ARCHAEOLOGY Writing new software is a creative process, under the control (to a greater or lesser extent) of the programmer writing that software. They are in a position to exercise their own judgement, and control the way in which the software is constructed. It's this very creativity that makes writing new software so interesting, and the reason why, given the chance, most programmers, would opt for creating new programs rather than maintaining old ones. Certainly I've found that people new to programming, find it easier and a lot more enjoyable to write something that they've devised, rather than modify an existing piece of software. But for all of us, there comes a time when we have to maintain somebody else's code. The first occasion is seldom a pleasant experience. But given sufficient time and exposure to software maintenance, it's almost possible to get to like it. Well written, documented, and controlled software, doesn't usually present any problems. It may be a bore to modify it, and to go through the subsequent validation and re-issue process, but it's usually fairly painless and straightforward. No, the problems arise with old (and sometimes not so old) code that's never been properly controlled, and has little if any documentation associated with it. There is unfortunately a lot of it about, as most programmers will agree. The carefully controlled and well documented variety is not as prevalent as it might be. Faced with the prospect of modifying such poorly supported software, one might be excused feelings of irritation, annoyance, or even on occasion, complete apathy. But there are other ways of looking at it. You could try treating it as an intellectual puzzle, a cross between a jigsaw and a crossword, perhaps. Or, more appropriately for the senior programs, a sort of software equivalent to archaeology. After all, it's much the same sort of job, digging into the code, seizing on any clues you can find, and trying to fathom out how it works. It's a bit like digging up the left over odds and ends of an ancient civilisation, and trying to work out what it was like. A pottery shard here, a piece of broken bone there, a post hole or three; all these can provide clues to the daily life of the people in those times long past. Valuable clues, which in the absence of any written history, are the only guide. A skilled software archaeologist, will have acquired a nose for clues, almost a sixth sense, that will enable them to unravel the mystery of an obscure piece of code. By examining fragmentary comments, variable names, programming techniques, and exposing the underlying foundations of the code layer by layer, an experienced archaeologist can, given a bit of luck, come up with some useful information. I can still remember my feelings, when many years ago, I was presented with the task of modifying an ancient Fortran program. They were a combination of panic and despair. The program was one of a suite used to generate control tapes for a wire-wrap machine. The machine was from America, and we'd bought the source code of the associated software many years previously, to enable us to customise it to our own needs. If there had been any documentation to start with, there was certainly none left when I came to look for it. Everyone who knew anything about it had long since left the company, and needless to say there was no support in this country for the system. I also had the minor problem of knowing nothing about Fortran. Although the engineers who designed the circuit boards to be wired up by the machine, knew how to specify what pins were to be connected to what, they had no idea how it was done, or how the control tapes were compiled. Every so often they would submit a batch job to produce the required tape, using as a basis a previous job they'd submitted. Having worked so well for so long, they now wanted to make a 'minor change' to the way in which pins were wired up. This necessitated a 'small change' to the format of the tapes needed to drive the machine, and hence the tape preparation software. And I was the person 'lumbered' with doing it. My mood changed to one of irritation when I discovered the general level of ignorance surrounding the system. That feeling was as useless as panic. I resolved to find out how it worked, and hid myself away for several days while I pored over the source listings. The code was obscure to say the least, but it was possible to trace the broad outlines of its history from the various programming styles. Much like tracing the rise and fall of an ancient city, from the various building materials and techniques employed. Having worked out which was the original code and which the subsequent customising, really didn't help too much. Not at that stage anyway. What I really needed, was a sort of Rosetta Stone to enable me to relate the engineers wire wrap instructions to the coded commands on the machine control tapes. After a bit more careful excavation I found what I was looking for. A set of translation tables. But they were all empty, and there didn't appear to be any code to initialise them. More patient work scraping away with the programmers trowel, revealed the use of an obscure subroutine written in assembler, and used to load the translation tables from an even more obscurely named file. I was obviously getting somewhere! From that point on it was all down hill. Within a few days I'd worked out where and what needed changing, and had made the appropriate modifications. Needless to say I didn't get any thanks for it, merely criticism from the engineers for taking so long. After all it was only a very small change to a working program that they had used for ages, wasn't it? And Fred, who'd previously looked after it (he'd left two years previously) could have done it by the very next day! Obviously the size of the code to be excavated, will determine how easy or otherwise the task will be, how many exploratory trenches you'll have to dig, and how long it will take. The wire wrap program was fairly small by comparison with one I had to tackle a year or so later. I hadn't been at the installation very long, when I was given an extremely ancient invoicing system to look after. It had been written originally (so I was told), for one of the first generation business computers, a LEO or some such. They may have been kidding me (I never did find out), but it was certainly old, and very very large. It was more patches than original code, and if some of the amendment dates were to be believed, COBOL and it grew up together. By now I'd become somewhat inured to the pain involved in digging through compacted layers of antique software, and I'd also acquired a certain amount of skill in locating important finds. Preparation was essential, so I set about a systematic search through the pile of listings I'd obtained. Fortunately for me (and unlike a number of other large programs I'd had to maintain) it was highly modularised and fairly well structured. I managed within a week to locate some of the more important areas. These would be worth more detailed investigation later. I also managed to produce a useful ground plan. Soon afterwards, I was asked to make a minor change (why are all changes considered to be minor?) to the system. I was thankful that I'd spent so much time studying it, and particularly thankful for the ground plan. For, far from being minor, the change required nearly every module in the system to be modified in some way! They must have been expecting me to have trouble, despite calling the change minor. For, a few days later when I reported that I'd made the changes, I was greeted with exclamations of disbelief. Previous programmers, I was told, had usually taken two or three weeks and numerous attempts, to do similar modifications. When I explained what I'd done, and mentioned in passing the similarity with archaeology, I got some funny looks. Apparently no one had previously thought of being systematic about maintenance, or of doing any preparatory work. And programming was programming wasn't it? What had it to do with archaeology? Computers were new and shiny, and archaeology was about old and dusty things. Despite the initial scepticism, it soon became apparent that the changes had been duly incorporated, and that they worked. In solving my own particular maintenance problem, I'd merely applied what I'd thought was a common sense approach. It would nice to be able to say that my approach was seen as amazingly efficacious ( a bit like Lily the Pink's Medicinal Compound), was applied universally, and solved everybody else's problems as well. But alas it was not to be. Maintenance in general was still carried out on a hit and miss basis. Strangely enough though, one or two of the other members of the maintenance team, started to take a keen, if surreptitious interest in archaeology. When caught reading the odd book on Early Dynastic Egypt, or the collected works of Sir Mortimer Wheeler for instance, they became embarrassed, and would attempt to casually slide it under a listing, and out of sight. Curious wasn't it? THE END