Allan Scherr wrote: > The way Spooling was done on the pre-S/360 systems, to my recollection, > was with a second computer. The 1410 did I/O for the 7010, for > instance. The 1401 was used to to card to tape and tape to printer for > larger computers. The first general multiprogramming capabilities that > I recall were in some of the IBM special purpose systems in the early > 60's like the SABRE airline reservations system or the so called > "defense calculator" project that kept track of radar threats. The > operating systems I used in the 50's (SOS, FMS, IBYSYS) had no > multiprogramming. IBSYS for the 7094 may have picked up this > capability near the end of its life in the early 60's, but I didn't use > it by then. Anyone remember?
the univ. had a 709/ibsys with 1401 front-end program called mpio that handled unitrecord<->tape front-end (card reader->tape, tape->printer/punch). one can imagine the tapes as a kind of spool ... being moved back&forth between the tape drvies on the different computers. as part of the transition to 360, the univ. got a 360/30 replacing the 1401 ... which ran mpio in 1401 emulation mode most of the time. my first student programming job was to re-implement the 1401 mpio program in 360. i got to design my own interrupt handlers, device drivers, storage allocation, task manager, console interface, etc. Basically my own 360 stand-alone monitor that simulated all the 1401 mpio functions (but running in 360 mode rather than 1401 hardware emulation mode). it eventually grew to about a box (2000) assembler statements, i assembled under an os/360 pcp on the 360/30 and then used a bps standalone loader to run the program. I eventually added conditional statements to do a stand-alone version and a os/360 version ... using job control, dcbs, open/close, etc. doing the os/360 version took about 30 minutes longer to assembler under os/360 pcp (i think release 6) on the 360/30 ... and it was almost all expanding the dcb macros ... you could watch the lights on the front panel and they significantly changed when it hit a dcb macro ... taking 5-6 minutes elapsed time for each macro. the 709 was then replaced with a 512kbyte 360/67 supposedly for tss/360 ... and then quickly upgraded to 768kbyte. the 709 had been doing fortran student jobs measured at approx. one/second ... going tape to tape. bare-bones os/360 release 9.5 on the 360/67 was doing student fortran jobs measured in minutes (instead of jobs/second). adding HASP to the system dropped the elapsed time per student fortran job to a little over 30 seconds elapsed. misc. past posts mentioning hasp http://www.garlic.com/~lynn/subtopic.html#hasp I then started looking at system in detail and especially stage-II. Initially as part of doing a rebuild of release 9.5 ... i did a stage-I sysgen and then got the stage-ii punched deck of cards ... and then had them interpreted (printed across the top). I started by trying to re-arrange the sequence of stage-II execution in order to optimally control both dataset placement and order of PDS member placement as means of doing disk arm motion optimization. By os release 11 sysgen ... I was also able to perform the stage-II system in the production jobstream (instead of requiring stand-alone time) and the resulting production system was running reference student fortran job stream at a little over 12seconds/job ... as opposed to over 30seconds/job for an "out-of-the" box system built with standard sysgen process (although both systems using hasp). note that six months or so of PTFs could slow the 12secs/job down to possibly 20secs per job ... as critical pds members were replaced and messed up placement for optimized disk arm motion. the student fortran job workload didn't actually get back to the 709 thruput until after waterloo's watfor was installed at the univ. the 360/67 wasn't actually used for much tss/360 work. the univ. ibm se did get some weekend stand-alone time for doing some tss/360 testing. because tss/360 was taking so long ... the univ. started looking at cp/67. the last week in jan68, three people from the science center http://www.garlic.com/~lynn/subtopic.html#545tech came out to the univ. and installed cp/67. sometime that spring (before i had done much optimization/rewrite) there was some work with doing simulated interactive script representing the student fortran workload. basically the same script was run for four tss/360 users and 30 cp67/cms users (on the same hardware). the interactive response time with workload of four simulated users was well over one second. The same workload script with 30 cms users (on the same hardware) was well under one second (aka cp67/cms had higher thruput and better response running 30 concurrent users ... than tss/360 with the same workload but only four concurrent users). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
