Edward E Jaffe wonders: > ... "old" programs with many hard-coded offsets and lengths > ... why [was this] such common practice back then[?]
Younger and newer programmers followed the habits of those who came before them. Many of those who first ventured into "OS" extensions and "neat, useful programs" did so on what today would be considered unusably slow computers (mostly due to I/O). In addition, output was to a line printer, and hundred-page Assembler program listings were to be avoided. Today we save such things in various places on disk drives, and only rarely actually kill trees. In the very early days "OS" macros were not easily or directly available, and most folks didn't bother to create their own versions of DSECTs for things that you could not get out of IBM in the first place. Fewer pages and fewer expanded -- not to mention, printed -- DSECT macros were virtues. All knew where the CVT pointer was; nobody bothered with the CVT DSECT macro, much less the PSA DSECT -- which did not then even exist. It was just a habit, really. Stuff that got done for some sort of "external" distribution (SHARE Program Library, and the like) was, on the whole, constructed "better" in this regard, but some of the most famous and widespread "mods" were as haphazardly coded as private, in-house RYO stuff. All of these are just excuses, however. Everyone except the idiots knew better, even then. But all of those bad habits were simply too readily adopted as purportedly valid excuses for sloppy work. Few had the time to tilt at windmills or hit the mattresses to bring light and order into that world. So we're still fixing the mistakes of the past today, albeit motivated to do so by considerations that would have been considered valid even back then when this type of sloppy programming was originally being done. But, aside from excuses, the original reasons were: 1. Slow machines (for the most part, 360/65 and below) - with slow memories (but that was to be expected) 2. Slow software: Assembler (F) [I/O limited] 3. Slow DASD I/O: 2311 and 2314 4. Slow printers: 1403-N1 5. Small memories: Assembler F had to execute in small partitions [but it did not benefit from large ones] 6. Non-existent/unavailable control block DSECT macros The above reasons meant there was a purported advantage to write that type of code. But they were reinforced by these reasons: 7. Already long-established, bad Assembler language coding Habits. Assembler F was light years ahead of anything else available at the time. New programming habits and good conventions had yet to be established, recognized and promulgated to the community. Many good programmers were actually put off by code that used DSECTs & USINGs (it was not mainstream). 8. The community was smaller; the potential confusion due to such poor practice was unrecognized & unappreciated because we were used to reading and using such code -- even (or especially) code in IBM software (see Note 1) -- and had no trouble deciphering what it was doing to what (or so we deluded ourselves). So, all was well, even if we were able to recognize "slick, tight, beautiful code" when we saw it (if we did not write it ourselves). Years later, other considerations (such as maintainability) started to become much more important. -- WB Note 1: I remember POK IBMers showing up at GUIDE and SHARE asking us to look at the source for some element involved in processing the START command. Nobody in POK could determine what, exactly, it did -- but they were afraid to touch it or take it out. The original coder had included not the first comment anywhere of any substance, didn't use macros, and if I remember correctly used only a few DSECTs (this was a 10- or 15-page Assembly listing). What was left of one of the original OS/360 elements after it was denuded for OS/VS2 was just an obscure golden oldie. In fact, if you look at OS/360 source code today you can easily see that most of it was what we'd describe as junky code, devoid of useful comments or any documentation. This element happened to be one that lived on, somewhat touched but still working, well into MVS/XA and ESA days. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
