Why these original FORTRAN quirks?
in [Fortran]
|
From: Richard Maine on 1 Dec 2006 21:41 Terence <tbwright(a)cantv.net> wrote: > Restating original title. (again) Restating original answers. :-) -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Gene Wirchenko on 2 Dec 2006 16:04 Steve O'Hara-Smith <steveo(a)eircom.net> wrote: >On Wed, 29 Nov 2006 12:10:01 -0800 >Gene Wirchenko <genew(a)ocis.net> wrote: > >> jmfbahciv(a)aol.com wrote: >> >> >In article <1428.554T2490T5455895(a)kltpzyxm.invalid>, >> > "Charlie Gibbs" <cgibbs(a)kltpzyxm.invalid> wrote: >> >> [snip] >> >> >>Malaproptimism n. The belief that everything will come out >> >>all right in the wash. >> > >> >Is that before or after the dye is cast? >> >> Please do not be so mordant. > > I was looking for a pun that sounded good but I came up short. You want good sound? Someone should tan your hide for you. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices.
From: Anne & Lynn Wheeler on 7 Dec 2006 19:03 Status report on project activities mentioned in email from 12dec73 in this post http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks? involving porting various functions that had been implemented in cp67 with additional enhancements. shortly after this email was written, I enhanced the PAM filesystem support so for "small" files (with only a single data block) for the FST to point directly at the data block rather than the FST point at a (200 byte) hyperblock ... which in turn pointed at the data block. This not only cut the physical disk space requirement in half (for small files), but also allowed them to be accessed in a single disk operation, rather than having to first access the hyperblock. The changes to move the EXEC command processer and the CMS editor (and other functions) into a shared segment was later picked up for vm370 release 3 and called DCSS. However, DCSS only incorporated a very small subset of the CSC/VM virtual memory management changes, i.e. for instance shared segments could only be loaded at fixed location (could not float or be relocated) and w/o page mapped file system support, the ability to directly map executable images ("MODULE") in the CMS filesystem to shared segments was lost. past discussions of cms page mapped file system support http://www.garlic.com/~lynn/subtopic.html#mmap From: wheeler Date: Jan. 2, 1975 Subject: CSC/VM SYSTEM STATUS This is to bring you up to date on the current status of the CSC/VM system. The updates to create the CSC/VM system have been converted to the latest system available from Burlingtion, Release 2, PLC9/ICR, with R22 monitor/THI support. Completed and in production use are the scheduling /dispatching /paging changes described in C.S.C. report; Also running in production use is multiple shared system/segments. We currently only have a test version of VM/APL which makes use of the extended sharing support. By the end of January the test VM/APL should become the standard production version. A minor CMS change has been made to support an alternate module format. This was necessary to support 'shared modules', like VM/APL. Also in the production system is the CP support for a Paging Access Method (PAM). Unfortunately PAM has one drawback; some of the bits in the CP SWAPTABLE have been redefined and are in conflict with the VMA microcode support. I consider the VMA microcode change to support PAM to be minor. In addtion such a modified VMA would be completly transparent to distributed versions of VM/370. Undergoing final production testing are page and swap table migration, both of which have been described in C.S.C. report. Swap table migration involves the writing of some of the page management tables onto disk and freeing up the main storage that they occupied. Page migration has been generalized over the drum to disk page migration described in the report to handle all preferred paging areas. Page migration will move low refererenced pages from the preferred paging areas to non-preferred areas. Additional changes are being made to page allocation on preferred paging disks to distribute pages evenly across all disks of the same type. A version of CMS/PAM is undergoing testing, but it has a drawback of requiring a minimum of two 4k page records for each file. The first 4k record contains a 200 byte file control information record and the rest is unused. This implementation puts a high price on users with many small files. (A 5 cylinder 3330 PAM area will contain a maximum of 140 files compared to the current maximum of about 700 files). Advantages include a five fold increase in maximum file size and mini-disk size (a full 3330-11 disk accesable as one mini-disk). Also a mini-disk is supported on any device that CP supports for paging, including the 2305 drum. The current implementation involves few CMS changes and continues to support the current mini-disk formats. For large system users it becomes possible (and feaseable with page migration) to use part of a 2305 drum for a CMS system disk. The most higly used parts of the CMS system disk will fit in 1000 page records (about the equiv. of 20 3330 cylinders) which is about 40 per-cent of the drum. The increase in the CMS nucleus size will enable highly used modules, like the EXEC processor and the EDITOR, to be placed in a shared nucleus segment. This implementation will be transparent to current user programs. During CMS ipl the additional nucleus segments will be relocated (via a VMM diagnose function) to the end of the user's virtual machine memory. .... snip ... The "relocation" of shared segments (having the same r/o, protected shared segments appear at different virtual addresses in different virtual address spaces) has been discussed in some past posts ... collection of those posts are pointed to here http://www.garlic.com/~lynn/subtopic.html#adcon The items mentioned as "swaptable migration" and "page migration" was released as part of my "resource manager". http://www.garlic.com/~lynn/subtopic.html#fairshare http://www.garlic.com/~lynn/subtopic.htmL#wclock
From: Anne & Lynn Wheeler on 7 Dec 2006 20:39
Attached is overview for CSC/VM system distribution (from 1975, sent out to a large number of internal locations). In the past, I've semi-facetiously joked that at one point I was directly distributing to as many (internal) locations (from the 4th flr, 545 tech sq) as there were total Multics installations (from the 5th flr, 545 tech sq) during its whole lifetime. recent refs http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks? The distribution overview also makes mention of including SPM from POK which is referenced here http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history In the above reference, there is a copy of old email making mention that an "official" copy of SPM had been distributed to me on 8/12/75. However, as can be seen in the following 4/30/75 overview, I was included an "unofficial" version of SPM in my distribution much earlier in the year. From: wheeler Date: 4/30/75 Subject: CAMBRIDGE VM/370 SYSTEM (based on vm rel2, plc15) Contained on the Cambridge VM/370 distrubution tape is a set of updates which provide performance and functional enhancements to CP-CMS. File 1 contains CP changes. They compromize a set of updates to existing CP source and macros. Also included are new source files, new cntrl, and a new load exec. File 2 contains changes and additions to CMS and CMS/APL. File 3 contains CMS changes to support disks in paging access method (PAM) format. Detailed documentation for any of these changes will probably not be forthcoming for some time. Reference will have to be made to the individual changes for a description of how they work. For instance, the CP support for page migration is almost totally contained in the new module DMKPGM. The CP support for PAM is contained in DMKPAM. The installation of the changes from file 1 should prove to be relatively easy. They are essientially a 'black box' addition to the existing system. If none of the new functions are to be utilized, then all that is required is a reassembly of the affected modules. No understanding of their operation is necessarily reqired. IMPORTANT: The VIRT=REAL option has never been tested and probably contains many bugs. Also SET FAVORED with a per-centage has not been implemented. In file 1, there are UPDTC001 and UPDTSPM update files and AUXCMB files for DMK modules and new assemble files. There are also changes to maclib files. The CMB CNTRL and CMBLOAD EXEC are the control file and load list. Also included is a CMBMAC MACLIB which contains the updated macros. These changes comprise support for the following enhancements; 1) fair share scheduler, 2) shared module support, 3) paging access method (PAM), 4) page migration, 5) the autolog command and 6) the special message function from POK. File 2 also contains optional CP changes for new page device format. The updates are UPDTCV3 and are applied after CMB. DMKFMT UPDTCV3 changes the spacing between records on the paging and spooling devices (3330 to 110 bytes and 2305-2 to 500 bytes). DMKPAG UPDTCV3 contains changes to specify the corresponding sector addresses. These are included for compatability with the previous CSC/VM release. The performance problems which lead to the increased spacing have been rectified with PLC-15. .... snip ... The six major items listed in the above 1) fair share scheduler (shipped in my resource manager) 2) shared module support (extremely small subset shipped in vm370 release 3 as DCSS) 3) paging access method (not shipped in standard product) 4) page migration (shipped in my resource manager) 5) "autolog" command 6) the special message function from POK I had originally created the "autolog" command as part of automating benchmarks (along with the feature that automatically started processes at initial boot) http://www.garlic.com/~lynn/subtopic.html#bench however, the feature proved so useful for general vm370 operations, it eventually came into wide use as part of standard processing and was shipped in the standard release 3 vm370 product. again, lots of past resource manager posts http://www.garlic.com/~lynn/subtopic.html#fairshare http://www.garlic.com/~lynn/subtopic.html#wsclock The fair share scheduler, including various paging and performance items, I had originally create as enhancements to cp67 as an undergraduate in the 60s. Many of the features had been dropped in the morph from cp67 to vm370. By the time, the resource manager was ready to ship, I had added an implementation supporting "SET FAVORED". |