The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
re: http://www.garlic.com/~lynn/2007m.html##47 Capacity and Relational Database for some additional past history .... the university i was at was selected to be beta-test for original CICS ... it was an ONR, online library funded project. It also got a 2321, datacell as part of the project. One of my responsibilities got to be shooting bugs in this early CICS (before first official product ship). One specific bug I remember was that the customer installation that CICS had grown out of had been using a specific set of BDAM options. For whatever reason, the university library chose to use some other combination of BDAM options ... resulting in CICS failures. ... misc. past posts mentioning cics &/or bdam (and having to shoot CICS and BDAM bugs) http://www.garlic.com/~lynn/subtopic.html#bdam one of the IMS things in the mid-70s was transition to virtual memory environment. The science center http://www.garlic.com/~lynn/subtopic.html#545tech had done much of the early stuff on virtual memory as part of both CP67 and VM370. Some of the work involved extensive performance monitoring, performance modeling, workload profiling and the early stuff leading to capacity planning. http://www.garlic.com/~lynn/subtopic.html#benchmark One of these efforts was instruction tracing and modeling virtual memory useage. This was used extensively in many applications moving from real storage environment to virtual memory operation. One of the earliest was in was significant benefit as part of rewritting the whole APL storage management when the science center did the port of apl\360 to cms\apl (and expanding APL workspaces from typical 16k-32k real memory to allow maximum virtual memory sizes) ... various past posts mentioning APL and/or one of its heaviest users ... the HONE system http://www.garlic.com/~lynn/subtopic.html#hone In the mid-70s, one of the major internal users of this tracing and modeling application (from the science center) was the IMS group ... tracing and monitoring both general IMS performance operation ... as well as optimization for virtual memory operation. The science center also added semi-automated program re-organization to the application and the science center announced it as "VS/REPACK" product in 1976. And here is old email reference about getting pushed as general consultant to the IMS development group in STL (mentions luncheon with the IMS deevelopment people) http://www.garlic.com/~lynn/2007.html#email801016 this independent of the previous mention about working on some of system/r ... the original relational/sql implementation http://www.garlic.com/~lynn/subtopic.html#systemr for other drift ... lots of past posts about doing lots of stuff for virtual memory optimization and replacement algorithms http://www.garlic.com/~lynn/subtopic.html#wsclock Now, when my wife was con'ed into going to POK to be in charge of loosely-coupled architecture ... she originated "peer-coupled shared data" architecture (and a lot of the mainframe distributed/global locking stuff) http://www.garlic.com/~lynn/subtopic.html#shareddata which saw very little uptake until sysplex ... except for IMS and especially IMS hot-standby effort for somewhat other topic drift ... lots of past posts about being allowed to play disk engineer in bldg. 14&15 http://www.garlic.com/~lynn/subtopic.html#disk at one time there was joke about working 4hr shift week, 1st shift in bldg28/sjr, 2nd shift in bldgs. 14&15, 3rd shift in bldg90/stl, and 4th shift (aka weekends) at HONE. later when we were doing our HA/CMP product http://www.garlic.com/~lynn/subtopic.html#hacmp and scaleup for distributed databased operation ... along with scaleup for distributed lock manager (as well as massive distributed recovery) ... some email references here http://www.garlic.com/~lynn/lhwemail.html#medusa and minor reference in these posts http://www.garlic.com/~lynn/95.html#13 http://www.garlic.com/~lynn/96.html#15 the people in STL complained that if we were allowed to ship the support for the commercial DBMS stuff ... we would be at least five yrs ahead of where they were. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
