Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > i had done heavy modification of VMFPLC2 (for all sorts of reasons) > and called it VMXPLC and used it to implement a backup/archive > system. this was deployed at research, hone (vm/370 world-wide, sales,
much larger blocking was done ... and also combining the FST record with data records as single physical record (for small files you could have majority of the tape as inter-record gaps, combinting the FST record with the data block record would cut in half the inter-record gaps). i had done page-mapped filesystem for cms way back in cp67 ... along with being able to define shared page stuff from the cms exectuable. i would map the original cms filesystem semantics ontop of page-mapped operations. later, i also modified the CMS edf filesystem semantics ontop of page-mapped operations. misc. cms paged mapped filesystem postings http://www.garlic.com/~lynn/subtopic.html#mmap if you had cms filesystem in a page mapped area ... and dealing with old applications (that didn't deal in page-sized records aligned on page boundaries) ... the implementation would push & pull the data around so that it was transparent to the application that it was dealing with a paged mapped filesystem. however, there were all sorts of thruput and performance things that went on if filesystem i/o happened to be in page record sizes and aligned on page boundaries. so part of the changes for VMXPLC included doing some of that. note that the basic filesystem changes were never included as part of any mainframe shipped product (some of it was incorporated into some version of xt370). in the morph from cp67 to vm370, the standard system mechanism for dealing with shared pages (shared segments) was to define them in a special kernel paging area. the definitions were specified in a kernel assembler module, DMKSYS. the process was to initialize an image in virtual address space and issue a (privileged) "SAVESYS" command to write an image from the virtual address space to the saved system area. Access to these "named" systems was by specifying the DMKSYS name in the CP IPL command. the port of all the memory mapped stuff from cp67 to vm370 included a bunch of stuff about handling all sorts of virtual address space stuff ... shared segments, non-shared segments ... dynamically loaded, etc. While all the page mapped filesystem stuff wasn't picked up and shipped ... there was a small subset of the vm370 kernel changes picked up and released as DCSS (discontiguous shared segments). This allowed loading of sections of virtual memory from a DMKSYS named system w/o having to go thru the IPL command semantics. one of the heavy users of the paged map stuff was HONE http://www.garlic.com/~lynn/subtopic.html#hone not so much because they needed the filesystem performance enhancements ... but they needed the capability of having shared segments w/o using the IPL command (that reset the whole virtual machine). most of HONE applications (like configurators, as things evolved, eventually all mainframe orders had to be run thru a hone configurator before it was submitted) were implemented in APL ... and the systems were heavily processor limited. APL interpreter was large amount of code ... and prior to DCSS, the approach was to initialize a virtual address space with cms along with the APL interpreter and save it as something like CMSAPL named system. branch office logons would then have automatic IPL of CMSAPL throwing them directly into the HONE APL environment. so all of that is standard system stuff ... except that they were starting to find possibly 100:1 performance improvement by recoding some of the APL stuff into compiled fortran. this required dropping out of APL, running a cms fortran program and then reentering the CMSAPL environment. this was a practical impossibility if the ipl command had to be issued by the branch sales people for the transition into and out of APL. so the paged map filesystem support was installed at hone and rather than having an IPL named system CMSAPL defined in DMKSYS, the APL interpreter was a standard cms executable in cms page mapped filesystem (with the appropriate indicators for shared page operations ... which were added to GENMOD command, recorded in new module field and supported by LOADMOD). then dropping into and out of APL to run fortran applications became simple CMS application execution. this was all before a subset of the shared page kernel changes were picked up for DCSS and remapped to DMKSYS named systems. -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
