[email protected] (William H. Blair) writes: > 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.
the folklore is that the person doing opcode lookup in os/360 assembler (including F) was told they had 256 bytes to do the implementation ... as a result the table was kept on disk ... requiring rereading the table for each assembler statement. i had 2000 statement assembler program that took nearly 30 minutes to assembler under os/360 release 6 on 64kbyte 360/30. It it had conditional assembly for either "standalone" ... included its own interrupt handler, monitor, device drivers, error recovery, etc ... or "os/360" mode ... used five DCB macros. If assembled for os/360 mode it took nearly an hour elapsed time ... with the assembler taking six minutes elapsed time per DCB macro. In any case, a later performance boost for assembler F ... was to keep the opcode table in storage. It wasn't so much that I/O was slow ... it was that an enormous amount of I/O was being done to compensate for lack of real storage. Univ. had 709 running tape-to-tape ibsys monitor (1401 doing UR<->tape front end) that took approx. second per student job. Moved to 768kbyte 360/65 (actually 67 running in 65 mode) os/360 mft14 with HASP ... took over half a minute for same student job ... using 3-step fortran G, link-edit, and go. Much of it was job-scheduler for each step loading an enormous number of different PDS members from disk (each time). With os/360 release 11, I had started doing product "job-stream" stage-2 sysgens ... where I carefully re-ordered the stage-2 sysgen statements to optimize placement of files & PDS members on disk ... getting approx. 300% elapsed time improvement for the student job workload (because everything was so disk intensive ... so there was significant benefit in optimizing arm seek with careful location of files & members on disks). Almost all of the univ. workload was done with os/360 running on bare hardware (360/67 as a 360/65 w/o virtual memory) ... although they let me play with the machine on the weekend as 360/67 using (virtual machine) cp67. This old post has part of presentation that I did at the aug68 share meeting in boston: http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14 it discusses a bunch of cp67 that I had rewritten to improve pathlengths and other things, mentions comparing MFT14 running under cp67 ... with & w/o the cp67 pathlength rewrite ... but also mentions that the workload under vanilla os/360 MFT14 on bare machine ran about the same elapsed time as the optimized MFT14 ran under unmodified cp67. with increase in real storage ... it was possible to reduce the intensity of disk activity (keeping more stuff in real storage). recent posts mentioning by early 80s ... that the relative system disk I/O thruput had declined by (better than) ten times from late 60s (i.e. ratio of disk i/os per millions of instructions executed had to dramatically descrease) http://www.garlic.com/~lynn/2010c.html#1 "The Naked Mainframe" (Forbes Security Article) http://www.garlic.com/~lynn/2010h.html#70 25 reasons why hardware is still hot at IBM http://www.garlic.com/~lynn/2010l.html#31 Wax ON Wax OFF -- Tuning VSAM considerations http://www.garlic.com/~lynn/2010l.html#32 OS idling old post with (late 60s/early 80s) comparison http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door which eventually resulted in B874 @ SHARE 63 ... referenced here: http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?) -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- 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
