re: http://www.garlic.com/~lynn/2011p.html#106 SPF in 1978 http://www.garlic.com/~lynn/2011p.html#107 SPF in 1978
I had originally done extended sharing on cp67 along with paged-mapped CMS filesystem ... which I then converted to vm370 ... some old email http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 with respect to "csc/vm" in the above ... one of my hobbies was making enhanced operating systems available to internal datacenter ... first with cp67 and then later with vm370. during the "future system" period ... some old posts http://www.garlic.com/~lynn/submain.html#futuresys I continued to do 360/370 stuff (even when future system was killing off 370 efforts) ... and periodically would ridicule future system activities. after the demise of future system, there was mad rush to get stuff back into 370 product pipelines ... which motivated decision to release various bits & pieces of stuff that I had been doing. A small subset of the sharing stuff (w/o the paged mapped filesystem support) was including in vm370 release 3 as DCSS. the following is exchange with the SPF group about trying to map SPF into a "shared module" (as opposed to DCSS sharing). Date: 11/07/79 14:53:27 From: wheeler To: somebody in GBURG SPF group The SPF module starts (begins) at location x'20000' and end somewhere close to x'70000' (actually around x'6a000'). If I load and genmod SPF it ordinarily creates a MODULE which starts at location x'20000' and ends around x'6a000', i.e. those core locations are written to disk. When I invoke SPF the SPF MODULE file is read into locations starting at the start of the module (x'20000') and ending at the end of the module (x'6a000'). -- Shared module support is an enhancement to VM and CMS which allows specification at GENMOD time which segments (16 page groups) are to be shared. The segments to be shared must be occupied by the module being genmod'ed (i.e segment 2: x'20000' thru x'30000'; segment 3: x'30000' thru x'40000', etc.). -- Ordinarily I would LOAD SPF GENMOD SPF -- for shared modules I LOAD SPF reset module ending address to x'70000' GENMOD SPF (share 2 3 4 5 6 -- Now at loadmod time, in addition to reading the SPF MODULE file into the specified core locations (i.e. x'20000' thru x'70000') it also identifies to CP that segments 2, 3, 4, 5, and 6 are SPF shared segments. For all other programs that I have been involved with, that works satisfactory (i.e. the same code runs in discontiguous shared segments, runs in modules, runs in shared modules) and modules which did not change internal code locations while a discontiguous shared module also do not change internal code locations while a module and/or a shared module. As I read your reply, SPF is altering 8 bytes of core at absolute location x'20000' independently of whether or not that location is contained within the module. If I were to: LOAD SPF (origin 30000 reset module ending address to x'80000' GENMOD SPF (share 3 4 5 6 7 there would not be any problems? since SPF is not storing into a relative module core location (i.e. start of the 1st SPF module + x'0' bytes) but into absolute location x'20000'. ... snip ... and the response about why there were still problems: as an aside ... 1979 GBURG SPF group appeared to still be using all upper case Date: 11/07/79 To: wheeler From: somebody in GBURG SPF group LYNN, THANKS FOR SENDING THE DESCRIPTION OF SHARED MODULES. I HAVEN'T STUDIED IT IN DETAIL, BUT DID READ THROUGH IT. VERY INTERESTING. YOUR IDEA OF STARTING SPF AT 30000 INSTEAD OF 20000 WOULD AVOID THE "SHARED" VIOLATION AS WE STORE INTO LOCATION 20000. HOWEVER, THAT WILL NOT SOLVE ALL THE PROBLEMS. IN SPF, THE WAY WE DETERMINE WHETHER WE ARE RUNNING IN THE USER AREA (TEST MODE) OR IN DCSS, IS TO COMPARE THE ADDRESS OF THE FIRST PROGRAM (HAPPENS TO BE NAMED SPF) TO THE VALUE '20000'. IF IT IS NOT THERE, IT IS ASSUMED THAT WE ARE IN DCSS. THE IMPLICATION IS THAT SPF WILL NOT RELOAD ITSELF FOLLOWING A FOREGROUND COMPILE, OR CMS COMMAND THAT USES THE USER AREA. IF MY UNDERSTANDING OF "SHARED MODULES" IS CORRECT, I AM AFRAID THAT, AT LEAST IN THE NEAR TERM, THERE IS NOTHING I CAN DO THAT WILL PERMIT SPF TO OPERATE CORRECTLY IN YOUR SPECIAL ENVIRONMENT. FEEL FREE TO WRITE OR CALL. REGARDS, XXXXXXX ... snip ... later exchange about SPF being a real "pig" of an application: Date: 02/21/80 12:59:12 To: wheeler Hi, Lynn, Do you have SPF/CMS installed, or know anybody that does ???? ... snip ... Date: 02/21/80 14:42:09 From: wheeler SPF/CMS installed and running, but it is a pig tho. ... snip ... In this time-frame there were a number of internally developed CMS full-screen editors ... early one that had been released to customers was EDGAR ... as well as simple full-screen extensions to pre-3270 CMS editor ... all were significantly better than SPF. recent post in ibm-main menioning some of this http://www.garlic.com/~lynn/2011m.html#44 with this old email http://www.garlic.com/~lynn/2011m.html#email810629 earlier post in same thread http://www.garlic.com/~lynn/2011m.html#41 giving some old (jun79) benchmarks of cms-edit, red, zed, edgar, spf, xedit, and ned ... although spf isn't nearly as bad as xedit or ned ... but much worse than my favorite RED (wasn't just processor time, but also significant larger code size) move (ibm-main) mention of ispf in same thread http://www.garlic.com/~lynn/2011m.html#42 -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
