| PLEX86 | ||
IBM 610 workstation computer 3417
IBM 610 workstation computer 3420 i don't think it is necessarily gender limited. there may be actually be two separate issues ... one is the different thinking styles and... background batch was software scheduling of workload. LCS was memory hardware. They are totally independent constructs. A typical 360-50 might have 256kbytes of 2mic, 2byte storage. A typical 360-65 might have 512kbytes of 750ns, 8byte storage (i.e. fetches 8bytes at a time in 750ns). You could add 8mbytes of 8mic LCS memory ... which ran slower than regular memory ... sort of an early numa (non-uniform memory architecture). the straight-forward process with numa is just strictly treat it as normal memory and ignore the different in thruput-performance. A little more sophisticated was to carefully allocate frequently used stuff in higher-speed memory and less frequently used stuff in LCS ... but allow it to execute as normal instructions-data when it was used. Alternatively, there were some strategies that would have things "staged" in LCS (typically small pieces of system code) that would be copied from LCS to higher-speed memory before actual use-end. another strategy was to use LCS as a sort of electronic disk ... data that was normally located and used on disk ... would be staged into LCS ... and treated as if it was still resident on disk. IBM 610 workstation computer 3419 it isn't that memory technology has lagged. there are certain physical constant issues that existing... IBM 610 workstation computer 3422 that was something akin to the original cp67 10 level scheduler (some of which may have even been inherited... so for topic drift ... a story about extreme background batch. I've mentioned this before in connection with the 370-195 in bldg. 28 (sjr). PASC had this job that would run an a couple hrs on the 370-195 ... however, the backlog of work on the 370-195 was such that PASC's application had a 3month turnaround (i.e. from the time it was submitted to the time it was run was 3months). PASC had a 370-145 which had about 1-30th the thruput of peak 370-195 thruput ... which they used for normal vm-cms interactive workload. This is also the machine they they developed apl-cms and the apl 370-145 microcode buttist on. So they configured this machine to run the PASC application in background ... along with doing periodic check-pointing (so it could be restarting after any system reboot). It would typically get little or no thruput during 1st shift ... but typically would get all of the 145 during 3rd shift. It might take a month or more elapsed time to run on the 370-145 ... but that was still better turn-around than the 3 months they were getting from the 370-195 at sjr (typically background batch got resources to run when there was nothing else using the resources). misc. other topic drift, the original port of apl-360 to cms-apl was done at the cambridge science center then PASC did the morph from cms-apl to apl-cms (as well as the 370-145 apl microcode buttist). misc. posts mentioning apl ... including cms-apl, apl-cms, apl use at HONE (after the consolidation of all the US HONE datacenters, the US hone datacenter was across the back packing lot from PASC) IBM 610 workstation computer 3418 OK. But this scheduling was site specific, was it not? No two site, probably no two systems, had exactly the same schedules. Thus the software was tweaked for each installation based on the the experience... --
|
||||
IBM 610 workstation computer 3418 Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||