Article View: comp.arch
Article #22942Re: IBM 360 memory
From: glen herrmannsfeldt
Date: Sun, 21 Mar 2004 03:51
Date: Sun, 21 Mar 2004 03:51
31 lines
3094 bytes
3094 bytes
Anne & Lynn Wheeler wrote: (snip) > tss/360 had concept of virtual memory and one-level store ... but > almost not concept of performance techniques and dynanic adaptive > anything. besides tss/360 horribly long pathlengths there were some > static things that they just didn't stop and think about. CMS used a > lot of compilers and other applications from os/360 which were > optimized for memory constrained environment ... i.e. overlays of > 50kbytes ot 100kbytes with efficient transistion from one overlay to > the next. TSS/360 would just lay such stuff out in virtual memory and > do simple 4k, single page fault at a time. So under CMS, it would > attempt to bring in the 50k-100k piece of the compiler ... and then at > change of phase bring in the next 50k-100k segment (attempting to do > as a single I/O each time). TSS/360 might have it all as a 1mbyte, and > have to individual page fault, each individual 256 4k page. When > running on 512kbyte real machine ... it might have to page fault > various of the 256 4k pages multiple times. (snip) My understanding is that when running under MVS it is better to run the compilers without overlays. One can, for example, load the Fortran H compiler into the link editor, and write it out again without any overlay statements. This will remove the overlay structure that it would otherwise have. That may depend on a sufficient amount of real memory, though. -- glen
Technical Details
Message-ID:
<Xi87c.52018$KO3.179594@attbi_s02>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!news.glorb.com!wn51feed!worldnet.att.net!attbi_s02.POSTED!not-for-mailReferences:
<2de13727.0403170551.830d050@posting.google.com> <uish31o5f.fsf@mail.comcast.net> <405875B5.9080200@prodigy.net> <405B4E58.43B57F32@earthlink.net> <3DR6c.56693$H44.1048115@bgtnsc04-news.ops.worldnet.att.net> <u4qsjimyc.fsf@smtp.comcast.net> <slrnc5oodj.nj9.jmaynard@thebrain.conmicro.cx> <89po5014gki8tgmdaqfkkqsr82nlt6582n@4ax.com> <slrnc5oq0h.nlr.jmaynard@thebrain.conmicro.cx> <uvfkzh40g.fsf@smtp.comcast.net>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fd705,6e80f3f01eb41450 X-Google-Attributes: gidfd705,public X-Google-Thread: 102b75,695a3f924dc00251 X-Google-Attributes: gid102b75,public X-Google-Thread: 103c88,16e4a17bee898890 X-Google-Attributes: gid103c88,public X-Google-ArrivalTime: 2004-03-20 19:51:20 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!news.glorb.com!wn51feed!worldnet.att.net!attbi_s02.POSTED!not-for-mail From: glen herrmannsfeldt <gah@ugcs.caltech.edu> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l Subject: Re: IBM 360 memory References: <2de13727.0403170551.830d050@posting.google.com> <uish31o5f.fsf@mail.comcast.net> <405875B5.9080200@prodigy.net> <405B4E58.43B57F32@earthlink.net> <3DR6c.56693$H44.1048115@bgtnsc04-news.ops.worldnet.att.net> <u4qsjimyc.fsf@smtp.comcast.net> <slrnc5oodj.nj9.jmaynard@thebrain.conmicro.cx> <89po5014gki8tgmdaqfkkqsr82nlt6582n@4ax.com> <slrnc5oq0h.nlr.jmaynard@thebrain.conmicro.cx> <uvfkzh40g.fsf@smtp.comcast.net> In-Reply-To: <uvfkzh40g.fsf@smtp.comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 32 Message-ID: <Xi87c.52018$KO3.179594@attbi_s02> NNTP-Posting-Host: 24.18.177.15 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s02 1079841079 24.18.177.15 (Sun, 21 Mar 2004 03:51:19 GMT) NNTP-Posting-Date: Sun, 21 Mar 2004 03:51:19 GMT Organization: Comcast Online Date: Sun, 21 Mar 2004 03:51:19 GMT