The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Ben Alford) writes: > I worked with an IBM 360/65 that had one MB of IBM LCS and later 2 MB > of LCS from some other OEM when I was a student. This 360/65 had 3 > frames of main storage, each with 256 KB of storage. The way I > remember it, we could ask for more LCS than main, but it was much slower. > You could specify that data in COMMON as well as data buffers reside > in the LCS under OS MVT. The LCS slowdown was noticable because the CPU > had to wait longer for all data coming in/out of LCS and, of course, the > CPU time was still ticking. I don't know if it slowed down channel > access much. i believe had cornell had 360/75 with 8mbytes of ampex lcs. standard 360/75 (and 360/65) storage was 750 nsec for 8byte interleaved access (some claim that 360/75 was a "hardwired" 360/65 to get extra thruput). some installations setup LCS as extension of (executable) main memory ... that just ran slower. other installations used it for "emulated" electronic disks ... with emulated data transfers; this could be things like "hasp" buffer records and/or executable images. i believe the ampex lcs had 8msec access (better than 10 times slower). if you look in 360/65, 360/67, and 360/75 functional characteristic instruction timings ... one of the things will be a prorated part of 750 nsecs for (the 8byte) instruction fetch i.e. 2byte instructions will include 1/4th of 750nsecs for instruction fetch, 4byte instructions will include 1/2th of 750nsecs for instruction fetch, and 6byte instructions will include 3/4th of 750nsecs for instruction fetch. this can be somewhat inaccurate for branch operations ... a double-word aligned (2byte) BR instruction ... will incur the full 750nsecs instruction fetch ... since the rest of the double word won't be used for any other instruction operations. LCS was both an issue of slower electronic memory as well as longer physical signal latency. by comparison 3090 expanded storage was the same electronic memory but physical packaging resulted in longer signal latency. as a result, it was purely packaged as sort of emulated i/o transfer ... but with a much wider bus (so the latency was amortized over much larger amount of data) and syncronized transfer instructions ... to eliminate the significant pathlength overhead in MVS for asynchronous i/o operations. later physical packaging (and improved caching infrastructure) eliminated the need for expanded storage ... however, emulated expanded storage (as part of LPAR configuration) lingered on, compensating for other system issues. ---------------------------------------------------------------------- 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
