This system was capable of running 8-10 barch jobs and 120 timesharing users concurrently.
My work on this system was writing operating system hooks and patches primarily to improve system efficiency, job scheduling, and user usability. The hook routines classified users and controlled the machine resources that that particular type of user could consume. This was accomplished by batch job scheduling based upon user limits on resources (which were inforced) and processor dispatching with time slice control and dispatching priority based on job history i. e. how much processor time it required on previous time slices. This allowed time sharing users to get good response time at the same time as compute bound jobs were running. I know this sounds obvious by today's standards, but back then few vendor supplied operating systems did a good job of it.
Most of the user interface utilities that I did were to give the user the ability to find out how the system was loaded and when he could expect his job to finish. GCOS had very good job logging facilities which were used from past history to predict the future of a job.
One very large project that I developed for the Honeywell system was an online master mode debugger that was built upon the "Boff" debugger that was part of a "B" development system from the Univerisity of Waterloo. It allowed a systems programmer to check out his master mode code without having to get block time to debug it on the real machine. It basicly was an interpreter for the 66/60 instruction set that was added into boff. A virtual memory system was also added that could be used against an hstar file (executable) or a core dump. This allowed the interpreter to be used as a dump analyzer as well. A later enhancement was added that allowed it to be used against real memory by a priviledged userid that could peek at real memory. You could then use the functions developed for dump analysis against the real live system tables. This made system patches as easy to debug as a user program using an on line debugger.
In August of 1981 I wrote a computer language translater (xlate) which has the ability to translate one language into another. It reads a file that contains instructions on how to translate and applies that to an input language file and produces an output file for another language. It can, for example, translate FORTRAN into C. It was originally written in B, but was translated into C (using itself) and ported to later C capable systems such as unix, VMS, and Mac.
In December of 1982 I wrote a full screen forms package for graphics terminals. See The A T & T Years for a full description.
Back to Glenn's Home Page