Lit. Buffer overruns 1689

basically that was stage1 sysgen. you punched up the parameters of your installation (including device specification) on maybe 100 cards ... which were macro statements that were run thru the buttembler. The buttembler expansion of those macros punched about 2000 cards referred to as stage2 sysgen. this was job control and other stuff to actually build your customized system .... including buttembling the i-o configuration specification ... which was included then in build of the kernel. most of the rest of stage2 was copying all the files needed for the configuration you had specified (like which compilers).

on 360-30 ... os-360 release 6 or so, stage1 might take 30-60 minutes ... and then stage2 could take 8hrs or so. This was all done "stand-alone" using a special system called a "starter" system (which had a little bit of magic code that didn't need i-o sysgen, aka the same starter system was shipped to all customers, and was booted on all machines ... for building the customers real system).

i got interested in the process and took some stage2 punch card output and had them interpreted (had the punch codes actually printed on the top line) and had a good look at it.

by os-360 release 11, the university had a 360-67 which was mostly run in 360-65 mode for batch work and it was my responsibility to build and support the system (when they brought in cp-67 in jan. '68, i also got responsibility for that ... i never had any responsibility for tss-360 ... other than watching some of the ibm'ers play with it on weekends).

One of the os-360 issues was that running batch work tended to be very disk intensive ... especially student jobs which tended to be almost all job control and program loading of the fortran compiler and almost immediate failure of one sort another if by some chance it compiled clean and actually went to completion.

fortran student jobs on the 709 were done with tape-to-tape fortran monitor that took a second or two per student job. initially on 360-65 the job scheduling process and various program loading overhead was driving student jobs was well over half a minute per.

after some more analysis ... i decided that i could significantly improve the thruput of the workload by optimizing the disk arm thrashing ... and to optimize the disk arm thrashing, i had to carefully order the files on disk, and to carefully order the files on disk ... i had to control the order that they were placed on disk. That drove me back to stage2 sysgen process. First I figured out how to run the sysgen process on a currently running production system (so that i didn't really need stand-alone, dedicated time). I then tore apart a stage2 sysgen deck and carefully reodered all the statements so that there was a careful ordering of the statements that moved files onto the new system disks.

the result was such a freshly built system ran the student job workload three times faster ... a little over 12secs per student job rather than well over 30secs (still slower than the 709)

In the spring and summer of '68 I also rewrote a bunch of cp-67 kernel pathlength code ... and got to do a presentation on the cp-67 kernel pathlength changes and the mft14 reorganization and optimization at the aug. 68 share meeting in boston.

after the presentation, some senior vp of dataprocessing at amex asked me to lunch across the street at the playboy club.

random past posts on the subject.

--