From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 24 Oct 2000 14:40:28 GMT

The 6000 group had done effectively their own version of escon ... called SLA (serial link adapter) ... it was about 10% faster than escon and used components that were something like 1/10th the cost of the escon components.

However, there was nobody else in the world that supported SLA ... so at best, one 6000 box could talk to another 6000 box.

To make it more interoperable ... we con'ed the company that produced HYPERchannel and very high-end tcp/ip routers to support a SLA card in their product line (they had a full set of directly attached boxes supporting a wide range of vendor supercomputers and mainframes, in addition to high-end, high-performance routers). With their support of SLA ... it gave the 6000 high-truput attachment directly into every kind of computer supported by their product line.

another random hsdt ref (rios in the following ref is rs/6000)
https://www.garlic.com/~lynn/99.html#67

random other hsdt refs:
https://www.garlic.com/~lynn/94.html#22
https://www.garlic.com/~lynn/94.html#33b

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Wed, 25 Oct 2000 14:55:19 GMT

There are various variations ... in systems with single hardware reference bit ... the software can emulate multiple bits in software ... effectively "shifting" the value of a hardware bit into software. Multiple bits then represent the settings of multiple sweeps of resetting the bit (and longer reference history).

The problem with clock and other similar implementations approximating LRU is that it degrades to FIFO under all sorts of conditions i.e. at some point all pages have their reference bits on ... the test & reset sweep thru all pages. At the end of that full sweep, all pages have their reference bit off and the algorithm replaces the page it started with. Then there is a very high probability that the next several pages examined in the fixed order will continue to have their reference bit off ... so the algorithm makes a sweep replacing several pages in a fixed order.

THe '71 simulation work found that LRU appoximation algorithms as well as simulated "true" LRU algorithm (across lots of different live load trace data) found that LRU replacement frequently degenerated to FIFO (LRU and FIFO were indistinguishable).

What was discovered was that with a minor coding hack ... CLOCK and misc. other LRU approximatins could be made to degenerate to nearly RANDOM instead of degenerating to FIFO ... i.e. in the situations that caused true LRU to degenerate to FIFO ... RANDOM replacement performed much better than FIFO.

My line from '71 was something to the effect that if the algorithm couldn't distinguish between pages (effectively the situation where nearly all page reference bits where all on or all off and led to LRU replacement degenerating to FIFO) that it was better to choose pages randomly for replacement than to choose pages for replacement in a fixed order (FIFO).

In simulation, true LRU tended to avg. 10-15% better than the normal CLOCK and other LRU approximation algorithms. The variation that had LRU approximation degenerate to RANDOM tended on the avg. to be 10-15% better than true LRU.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Wed, 25 Oct 2000 15:02:43 GMT

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Wed, 25 Oct 2000 16:13:41 GMT

In the literature at the time, there was stuff on fixed working set size stuff with local LRU that executed on a fixed time basis.

The problems with what was in the literature was that it was significantly sub-optimal, overhead was independant relationship to contention and/or demand for pages, and didn't dynamicly adapt to different configurations & load (amount of storage, replacement latency, queuing delay, contention, etc).

The clock-type algorithms both dynamically adapted the overhead processing and interval to demand/contention.

I was able to show that global LRU and adaptive working set size significantly outperformed what was in the literature at the time.
https://www.garlic.com/~lynn/99.html#18
https://www.garlic.com/~lynn/93.html#4

In '71, I had somewhat accidentally stumbled across LRU degenerating to RANDOM instead of FIFO (and outperforming true LRU on the avg bas as much as true LRU outperformed clock-like LRU approximations) when i was trying various rearrangements of the clock code to make it much more efficient in an SMP environment (reduce lock contention, etc with multiple processors all contending for the page replacement supervisor).

other random refs:
https://www.garlic.com/~lynn/94.html#49
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/93.html#7
https://www.garlic.com/~lynn/99.html#104
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/94.html#01
https://www.garlic.com/~lynn/94.html#2
https://www.garlic.com/~lynn/94.html#4
https://www.garlic.com/~lynn/94.html#10
https://www.garlic.com/~lynn/94.html#14
https://www.garlic.com/~lynn/93.html#6
https://www.garlic.com/~lynn/93.html#5

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Why IBM use 31 bit addressing not 32 bit?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why IBM use 31 bit addressing not 32 bit?
Newsgroups: bit.listserv.ibm-main
Date: Wed, 25 Oct 2000 16:38:02 GMT

the 370/etc princ-of-ops was a script/gml document that was a subset of the architecture "red-book". The architecture "red-book" had a bunch of "conditional" sections that gave a lot of justification & trade-offs of why things were done they way they were.

For instance, t\he original 370 architecture "red-book" gave a complete virtual memory and addressing architecture (before virtual memory was announced). Coming up on the time to announce 370 virtual memory ... there was a big battle over what would be announced and shipped. Both the 155s & 165s in the field needed significant hardware upgrade to support relocation. One of the points finally came down to announcing & releasing the full 370 virtual memory architecture (as embodied in the red-book) would take a significant additional redesign and rewire of the virtual memory retrofit for the 165 delaying the virtual memory announcement by six months.

There was various escalation meetings with all parties concerned and finally it was decided to go with a subset of 370 virtual memory architecture. One of the deciding factors was that the POK SVS group stated that SVS only had a single address space and customer installations would peak at max. of five page I/O per second and therefor the additional features would see no benefit in a SVS environment.

random refs:
https://www.garlic.com/~lynn/93.html#14
https://www.garlic.com/~lynn/2000c.html#84
https://www.garlic.com/~lynn/2000e.html#57

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Wed, 25 Oct 2000 20:57:55 GMT

when i got to ship some of this stuff in products ... I had the benefit of a lot of work by others in simulation plus workload profiling that had been collected across hundreds of different configurations & loads over a period of a number of years.

As a result was able to construct some synthetic benchmarks that could be configured along the edges of the configuration/load envelopes, statistical points within the nominal configuration/load envelope, and various severe outlyers ... way beyond the edge of observed configuration/load envelopes.

Several thousand synthetic benchmarks was then devised that covered the observed configuration/load envelope (interior, boundary conditions, extreme outlyers, etc) that took three months elapsed time to execute.

The information was then used to validate all kinds of stuff I was doing in dynamic adaptive & feedback/feedforward stuff across a broad range of different configurations & loads ... not just page replacement, but various thrashing controls, scheduling and dispatching controls, "scheduling to the bottleneck" adaptation, etc. Scheduling to the bottleneck attempting to identify the bottleneck thruput resources and adjust scheduling based on the consumption of bottleneck resources (which might or might not be cpu or storage or i/o or page i/o, etc).

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 03 Nov 2000 05:43:03 GMT

Instruction source/destination operands had various attributes (possibly 3-5 levels of attributes). The FS microcode was responsible for doing the magical DWIM based on the attributes. Source/Destination operands with attributes associated with I/O was much less well defined for the microcode "do what i mean" magic (than most other parts of the FS architecture)

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Ethernet efficiency (was Re: Ms employees begging for food)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet efficiency (was Re: Ms employees begging for food)
Newsgroups: comp.os.linux.advocacy,comp.os.ms-windows.nt.advocacy,comp.arch,comp.os.netware.misc
Date: Fri, 03 Nov 2000 13:35:06 GMT

There was a 3mbit/sec early '80s version that didn't listen before transmit. Analytical modeling of a 3mbit thick-net (w/o listen before transmit) with several hundred stations I believe showed efficiencies dropping below 30%. Part of this was due to lack of listen before transmit. Probability of collisions was purely based on amount of contention.

With listen before transmit, collisions become function of both contention and network transmission latency. Worst case in thin/thick net were/are the stations at the futherst ends of the cable (and total distance/latency is somewhat proportional to number of stations since it is the sum of all the segments).

Hub-based twisted pair tends to better bound the worst case latency because it is proportional to the two longest segments and independant of the number of segments.

I got into deep dudo including twisted-pair solutions when I introduced 3-layer architecture to IS executives of large multinational corporation. The 16mbit T/R guys had been using a analytical model with 3mbit/sec ethernet w/o listen before transmit & comparing it to 16mbit T/R (and showing around 1mbit/sec ethernet effective thruput). Quoting the sigcomm paper made T/R guys even less happy.

random refs:
https://www.garlic.com/~lynn/2000e.html#45
https://www.garlic.com/~lynn/2000b.html#11
https://www.garlic.com/~lynn/99.html#33
https://www.garlic.com/~lynn/94.html#22

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Ethernet efficiency (was Re: Ms employees begging for food)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet efficiency (was Re: Ms employees begging for food)
Newsgroups: comp.os.linux.advocacy,comp.os.ms-windows.nt.advocacy,comp.arch,comp.os.netware.misc
Date: Fri, 03 Nov 2000 14:35:43 GMT

"Measured Capacity of Ethernet: Myths and Reality" in proceedings of ACM SIGCOMM, 8/16-19, 1988, V18N4

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Famous Machines and Software that didn't

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Famous Machines and Software that didn't
Newsgroups: alt.folklore.computers
Date: Sat, 04 Nov 2000 00:13:56 GMT

random refs:
https://www.garlic.com/~lynn/2000f.html#16
https://www.garlic.com/~lynn/2000f.html#17
https://www.garlic.com/~lynn/2000f.html#18
https://www.garlic.com/~lynn/2000f.html#19
https://www.garlic.com/~lynn/2000f.html#26
https://www.garlic.com/~lynn/2000f.html#27
https://www.garlic.com/~lynn/2000f.html#28
https://www.garlic.com/~lynn/2000f.html#29
https://www.garlic.com/~lynn/2000f.html#30
https://www.garlic.com/~lynn/2000f.html#31
https://www.garlic.com/~lynn/2000f.html#37

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Reason Japanese cars are assembled in the US (was Re: American bigotry)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Reason Japanese cars are assembled in the US (was Re: American bigotry)
Newsgroups: alt.folklore.military,rec.autos.driving,alt.autos.honda,rec.autos.makers.toyota,rec.autos.makers.honda
Date: Sun, 05 Nov 2000 15:12:08 GMT

In the late '80s, the industry did finally take a better crack at reinventing itself. For instance, up until then the avg. development cycle time in the US for a new product was approx. seven years (from concept to delivery). The Japanese had shorten that to three years for the lexus, infinity, etc, products. The result was that the Japanese could adapt nearly two & half times faster to changing customer circumstances (than the US). The C4(?) project helped turn out the initial S10 in three years and also supposedly vastly improved quality.

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

IBM 3340 help

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3340 help
Newsgroups: alt.folklore.computers
Date: Mon, 06 Nov 2000 20:34:26 GMT

I remember 3380s coming in A & B boxes ... where (I think) "A" boxes where "head of string" and contained the logic allowing attachment to multiple controllers (an "A" box and three "B" boxes for 16 drives in a string?).

The I/O architecture had misc problems with string switches. Standard architecture provided for channel-busy, controller-busy, and device-busy indications. String-switch wasn't a resource concept provided for in the i/o architecture ... so string-switch effectively used multiple device-busies to simulate a string-switch busy.

Data transfers & things like search operations would "busy" shared resources (i.e. channel, controller, string-switch). Any device in a string doing something like a multi-track search (worst case about 1/3 sec. for a 3330) would cause the related string-switch to be busy and all other devices (i.e. up to 15) on the same string to be unavailable (regardless of additional controllers or channels).

random refs (alta vista)
http://www.storagetek.com/State_of_Texas/item_code_non_93921/3370_307.html
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Reason Japanese cars are assembled in the US (was Re: American bigotry)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Reason Japanese cars are assembled in the US (was Re: American bigotry)
Newsgroups: alt.folklore.military,rec.autos.driving,alt.autos.honda,rec.autos.makers.honda
Date: Mon, 06 Nov 2000 23:49:41 GMT

I only saw some of the C4 stuff at GM and didn't really see the other manufactures. However, with seven year cycle, you would tend to have 2-3 concurrent overlapping efforts with staggered offset of 2-4 years so new products were coming to market on more frequent bases. Also, early in a cycle, you might have two or more competing teams since predictions out seven years could be open to interpretation and you would want to cover contingencies. Moving from 7 year cycle to 3 year cycle might result in 80% reduction in the number of required engineers (competitive forces w/military for the top 10-50 engineers in the country could still be a factor tho).

I do know that i bought a malibu for over $5k in '76 and it was around $13k something like 8 years later (and that represented closer to the avg. price of US car sold). Of course, inflation accounted for some of the change but I think that during this period, finance periods increased from 3 year to 5 year (possible indication of prices increasing faster than wages, also would have helped precipitated the 5 year warranties that started to show up in the early '80s).

C4 addressed radical changes in the end-to-end process ... not so much what was being done ... but how they went about doing it (as well as the cost of doing it). Drastic reductions in cost/time also implied reductions in number of people. I would expect that just quantity of engineers would tend to result in longer cycles, larger number of different models and fewer common components.

One example given C4 was corvette design because the skin/surface done by the designers tended to have tight volume tolerances. Seven year cycle resulted in several re-engineering & re-design activities because of minor modifications of basic components done by other divisions and/or suppliers (change in delco battery during the cycle required modifications to the exterior surface).

With respect to foriegn exchange in one of the following refs, I remember being in tokyo when exchange rate was 300/$ and since seen it drop below 100/$ (the relative cost of their products in the US market increased by a factor of 3 over a period of 25-30 years).

In some of the following there are references to a benefit of the purchase of AMC to Chrysler because AMC had already started takeup of Honda/Japanese manufacturing techniques.

misc. refs (many have since gone 404, so replaced with wayback machine URLs):
https://web.archive.org/web/20010204034500/http://www.media.chrysler.com/wwwhome/hist.htm
https://web.archive.org/web/20010222205419/http://www.inu.net/davidstua/chrysler_case_part1.htm
https://web.archive.org/web/20010217003458/http://www.michiganinbrief.org/text/appendix/append-J.htm
http://mrtraffic.com/millennium.htm
https://web.archive.org/web/20000829050939/http://www.sbaer.uca.edu/docs/proceedingsII/97sma228.txt
https://web.archive.org/web/20010222203823/http://www.rindsig.dk/viden/3-sem/Rising-sun.html
https://web.archive.org/web/20010104022000/http://www.iitf.nist.gov/documents/committee/cat/breaking_barriers_conf.html

from the above iitf/nist ref:
General Motors took a different tack by replacing the dissimilar hardware and software that existed throughout the corporation and creating an integrated system known as C4 (computer-aided design, computer-aided manufacturing, computer-integrated manufacturing and computer-aided engineering). As part of its C4 program, GM linked the design, manufacturing and assembly teams that were previously unable to communicate with each other. GM made the decision that although its legacy systems represented a sizable capital investment, it was important that the entire manufacturing process be overhauled to ensure interoperability and interconnectivity among all the players on the new network, including suppliers.


http://www-personal.umich.edu/~afuah/cases/case3.html

misc pieces from the above
The Rise of Foreign Competition (1970-1980)

By the early 1970s American automakers were facing strong global competition both at home and abroad. Japanese automakers in particular made a significant impact on the industry by introducing smaller, less expensive, and more fuel-efficient cars to the American market. This coincided with the oil crisis, which resulted in higher gasoline prices and a shift in consumer tastes toward greater fuel efficiency. Other advantages of the Japanese automakers resulted from their use of just-in-time (JIT) inventory controls, modern manufacturing techniques, and quality control and management practices.

By 1980, American carmakers had lost about one-fourth of the fastest growing segment of the domestic market - small cars - to Japanese producers. In response to pressure from the United States government, Japanese automobile producers implemented voluntary export restraints (VER) on their auto exports to United States. This VER agreement limited Japanese imports to not more than 1.68 million vehicles per year.

Restructuring of American Automobile Production (1980-1990)

While under the limitation of VER in the early 1980s, Japanese (and other) automobile companies shifted their strategies to foreign direct investment, setting up new facilities to produce cars locally in United States. Leaders were Honda, Mazda, Nissan, and Toyota, which collectively invested $5.3 billion in North American-based automobile assembly plants between 1982 and 1991.2 This was viewed as a response to VER - the Japanese automobile firms wanted to circumvent the threat of protectionist trade legislation. However, it was also a response to higher production costs at home and the sharp rise in the value of the Japanese Yen against the U.S. dollar during 1987, which dramatically increased the cost of exporting both automobiles and component parts from Japan to other markets.

To halt further erosion of their position, protect their remaining share of the domestic market, and prepare for competition in the global economy, the American automakers implemented programs to duplicate the world's best manufacturing practices. This included efforts to apply Japanese-style manufacturing practices such as JIT inventory control and leaner production systems to reduce costs. Yet, there were still important differences.

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: comp.society.futures,alt.folklore.computers
Date: Tue, 07 Nov 2000 04:05:25 GMT

Also, there was extensive drive in the early '90s to get programs off the gov. dole, extensive incentive to get gov. contractors to find commercial funding/ooutlets for large portions of their activities, migration to COTS offerings and other initiatives (ARPA's TRP technology reinvestment program, startup funding to migrate all possible gov. developed technologies into commercial sector; NIST ATP ... advanced technology program, NASA AITP, etc)

NSFNET was in large respect to demonstrate feasability of high-speed service offering. Once that was demonstrated, it would have consistant with all the other technology activities of the period to transition to COTS/commercial offerings.

Other instances were a number of conferences in the early to mid-90s where the national labs were attempting to "sell" a lot of technology to the medical industry.

There use to be lots of technology reuse program references on the web current alta-vista search turns up
http://www.stanford.edu/group/scip/sirp/US-NII-slides.html

"ARPA TRP" turns up a few more ... sample
http://www.eng.auburn.edu/~ding/emc/emc.html
https://web.archive.org/web/20010222212533/http://www.eng.auburn.edu/~ding/emc/emc.html
http://sebulba.mindtel.com/21698/nasa/ames.html
https://web.archive.org/web/20010225040040/www.quasar.org/21698/nasa/ames.html
http://www.uscar.org/pngv/progplan/9_0.htm
https://web.archive.org/web/20010217102712/http://www.uscar.org/pngv/progplan/9_0.htm
http://me.mit.edu/groups/lmp/industry.htm
http://logic.stanford.edu/cit/commercenet.html

including
http://nii.nist.gov/cat/tp/t940707.html
https://web.archive.org/web/20010222211057/http://nii.nist.gov/cat/tp/t940707.html

the following from the above
Information Infrastructure Project (IIP)

Brian explained that the IIP is part of the Kennedy School's Science, Technology and Public Policy Program, which is directed by Lewis Branscomb. IIP began in 1990 addressing issues in the commercialization of the Internet and the development of the NREN. It now encompasses a wide variety issues related to the NII.

IIP addresses issues by bringing together experts in an interdisciplinary setting. Strategies to protect intellectual property, industrial extension networking, CALS, public access to the Internet, and standards are some of the topics that have been addressed. Brian's group publishes quarterly, a two-volume Information Infrastructure Sourcebook. The project also runs the Information Infrastructure Forum, which is hosted in Washington by the Annenberg Washington Program. This year they have held fora on competition policy, interoperability, and enabling interconnection -- and next, long term economic issues.

for "NIST ATP", alta vista turns up maximum number (20pages/200)

federal technology transfer web site:
http://www.federallabs.org/

technology transfer legislative history web site (going back to 1980)
http://www.dtic.mil/techtransit/refroom/laws/

some of the entries from above
Small Business Technology Transfer (STTR) Program 1992 (PL 102-564)

Established a 3 year pilot program - Small Business Technology Transfer (STTR), at DoD, DoE, HHS, NASA, and NSF. Directed the Small Business Administration (SBA) to oversee and coordinate the implementation of the STTR Program. Designed the STTR similar to the Small Business Innovation Research SBIR program. Required each of the five agencies to fund cooperative R&D projects involving a small company and a researcher at a university, federally-funded research and development center, or nonprofit research center.

National Department of Defense Authorization Act for 1993 (PL 102-25)

Facilitated and encouraged technology transfer to small businesses.

National Department of Defense Authorization Act for FY 1993 (PL 102-484)

Established the DoD Office of Technology Transition Extended the streamlining of small business technology transfer procedures for non-federal laboratory contractors. Directed DoE to issue guidelines to facilitate technology transfer to small businesses. Extended the potential for CRADAs to some DoD-funded Federally Funded Research and Development Centers (FFRDCs) not owned by the government.

National Department of Defense Authorization Act for 1994 (PL 103-160)

Broadened the definition of a laboratory to include weapons production facilities of the DoE.

National Technology Transfer and Advancement Act of 1995 (PL 104-113) [also known as the "Morella Act"]

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: comp.society.futures,alt.folklore.computers
Date: Tue, 07 Nov 2000 15:45:19 GMT

The Federal Laboratory Consortium for Technology Transfer (FLC) was organized in 1974 and formally chartered by the Federal Technology Transfer Act of 1986 to promote and to strengthen technology transfer nationwide. Today, more than 700 major federal laboratories and centers and their parent departments and agencies are FLC members.

sample listing of technology transfer success stories is at:
http://www.federallabs.org/servlet/LinkAreaFramesetServlet?LnArID=SuccessStories&LnArRegion=National

one of the "stories" titled "The Great Government Giveaway"
http://www.businessweek.com/smallbiz/0006/te3685116.htm
https://web.archive.org/web/20010109054800/http://www.businessweek.com/smallbiz/0006/te3685116.htm

and a couple more entries from the legislative history web site ...
Stevenson-Wydler Technology Innovation Act of 1980 (PL 96-480)[15 USC 3701-3714]

Focused on dissemination of information. Required Federal Laboratories to take an active role in technical cooperation. Established Offices of Research and Technology Application at major federal laboratories. Established the Center for the Utilization of Federal Technology (in the National Technical Information Service).

Bayh-Dole Act of 1980 (PL 96-517)

Permitted universities, not-for-profits, and small businesses to obtain title to inventions developed with governmental support. Provided early on intellectual property rights protection of invention descriptions from public dissemination and FOIA. Allowed government-owned, government-operated (GOCO) laboratories to grant exclusive licenses to patents.

Federal Technology Transfer Act of 1986 (PL 99-502)

Made technology transfer a responsibility of all federal laboratory scientists and engineers. Mandated that technology transfer responsibility be considered in employee performance evaluations. Established principle of royalty sharing for federal inventors (15% minimum) and set up a reward system for other innovators. Legislated a charter for Federal Laboratory Consortium for Technology Transfer and provided a funding mechanism for that organization to carry out its work. Provided specific requirements, incentives and authorities for the Federal Laboratories. Empowered each agency to give the director of GOCO laboratories authority to enter into cooperative R&D agreements and negotiate licensing agreements with streamlined headquarters review. Allowed laboratories to make advance agreements with large and small companies on title and license to inventions resulting from Cooperative R&D Agreements (CRDAs) with government laboratories. Allowed Directors of GOGO laboratories to negotiate licensing agreements for inventions made at their laboratories. Provided for exchanging GOGO laboratory personnel, services, and equipment with their research partners. Made it possible to grant and waive rights to GOGO laboratory inventions and intellectual property. Allowed current and former federal employees to participate in commercial development, to the extent there is no conflict of interest.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: comp.society.futures,alt.folklore.computers
Date: Tue, 07 Nov 2000 16:05:20 GMT

another organization at harvard that has participated &/or assisted in studies is the Program on Information Resources Policy
http://pirp.harvard.edu/
https://web.archive.org/web/20010202091600/http://pirp.harvard.edu/

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: comp.society.futures,alt.folklore.computers
Date: Tue, 07 Nov 2000 16:55:00 GMT

by comparison, a (simple grep) list of just the com domains from Oct. 1990 domain list
https://www.garlic.com/~lynn/2000e.html#20

it only picks up some of the non-us "coms" and doesn't pick up edu, org, net, etc domains ... but it still lists 1742 com domains.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Famous Machines and Software that didn't

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Famous Machines and Software that didn't
Newsgroups: alt.folklore.computers
Date: Tue, 07 Nov 2000 22:08:56 GMT

Introduction to the iAPX 432 Architecture (171821-001) copyright 1981, Intel iAPX 432 Object Primer (171858-001, Rev. B) iAPX 432 Interface Processor Architecture Reference Manual (171863-001)

out of the introduction
The B5000 architecture had the right approach; it attempted to raise the level of the archtecture using the best available programming methodology, (c. 1960), which largely reduced to "use Algol", and the architecture supported Algol very effectively. But in the 1970s and 1980s problems have arisen for which Algol and the programming methodology of the early 1960s offer no solution.

These problems have led other manufactuers, whose earlier computers had more conventional architectures, to recognize the wisdom of raising the level of the hardware-software interface. Consider, for example, the IBM System 38, IBM's most recent architecture. Not only have the designers of the System 38 followed the Burroughs approach to architecture support for high-level languages, they have also included most of the operating system in the hardware as well. It seems inevitable that the fundamental problems facing the computer industry will force more and more manufactuers to take this approach.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: alt.folklore.computers
Date: Fri, 10 Nov 2000 15:42:48 GMT

In any case, I believe that it was the government/PUCC that was telling the phone company that it wasn't necessary to upgrade the central office that served the cupertino area ... since nobody really wanted things like high-speed internet access (i.e. it wouldn't be allowed a rate increase to cover the cost of the equipment upgrade since the existing central office equipment was good for another 20 years and nobody really cared about high-speed internet access).

As pointed out, for people that really wanted high-speed internet access, they could really get it with the existing central office equipment ... but instead of 512kbit access costing $49/month it would only cost something like $1200/month (a silly 24 times more, after all its just money).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: alt.folklore.computers
Date: Sat, 11 Nov 2000 16:14:24 GMT

Given a high-speed technology service demonstration of known duration it is highly likely that commercial entities donated the majority of the resources to make the NSFNET demonstrations a success. Possibly motivation for this strategy was creating a demand for bandwidth that would later be migrated to real world environment.

In the mid-80s there was enormous amounts of dark fiber putting the telecommunication industry in real chicken & egg bind; bandwidth intensive applications wouldn't be developed w/o lowered tariffs, but it would take bandwidth intensive applications several years to appear, mature, and propagate into the market place. Across the board reduction of tariffs by factors of 5-10 times w/o corresponding increase in use would put the industry at severe financial risk.

A solution was a controlled incubator environment (like NSFNET and supercomputing centers) where embryonic high bandwidth applications could emerge and acquire some maturity. Once out of the embryonic stage, there would be migration from the incubator to the real world (while maintaining an economically viable telecommunication industry).

The relationship between commercial contributions and gov. funding is possibly clearer in state of cal. situation where pacbell created an internet program for educational and non-profit institutions. Rather than doing a special tariff for non-profit internet services ... they tariffed the non-profit internet connections at the going rate and then provided a grant program that non-profit institutions could apply to and receive funding to cover the costs of their internet connectivity (and it was probably also easier to provide supporting documentation with regard to non-profit tax deductions).

As a result, I would claim that there was much less economic confusion surrounding the nature of free services.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: alt.folklore.computers
Date: Sat, 11 Nov 2000 16:39:39 GMT

by 1992, the number of NSFNET sites was only up to 16 ... ref:
https://www.garlic.com/~lynn/2000d.html#73

the people with direct access to NSFNET would have been numbered in the tens of thousands at best (i.e. much less than the sum of all possible individuals at each of the 16 institutions).

In general, gov grants (like NSF) are to aid in technology research and development and not usually to create government service buearacracies (especially that would be in competition with commercial entities).

misc. other history
https://www.garlic.com/~lynn/2000d.html#72

from the above reference:
In 1987, BITNET and CSNET merged to form the Corporation for Research and Educational Networking (CREN). A key feature of CREN and its predecessors is that they were entirely dependent on voluntary user fees; BITNET from the beginning and CSNET after the expiration of its initial five year NSF grant.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

TSS ancient history, was X86 ultimate CISC? designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS ancient history, was X86 ultimate CISC?  designs)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: Wed, 15 Nov 2000 23:54:50 GMT

Lots of production work was done with CP/67 by a wide variety of different kinds of customers ...

misc ref:
https://www.garlic.com/~lynn/2000.html#1

other random refs:
https://www.garlic.com/~lynn/2000f.html#6
https://www.garlic.com/~lynn/2000e.html#0
https://www.garlic.com/~lynn/2000e.html#15
https://www.garlic.com/~lynn/2000e.html#16
https://www.garlic.com/~lynn/2000d.html#30

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
Newsgroups: alt.folklore.computers
Date: Thu, 16 Nov 2000 00:01:44 GMT

some extracts from melinda's paper ...
https://www.garlic.com/~lynn/99.html#126
https://www.garlic.com/~lynn/99.html#127

also misc. other references (also refs from reply to tss posting)
https://www.garlic.com/~lynn/2000.html#1
https://www.garlic.com/~lynn/2000f.html#6
https://www.garlic.com/~lynn/2000e.html#0
https://www.garlic.com/~lynn/2000e.html#15
https://www.garlic.com/~lynn/2000e.html#16
https://www.garlic.com/~lynn/2000d.html#30

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
Newsgroups: alt.folklore.computers
Date: Thu, 16 Nov 2000 00:33:47 GMT

In fact, one relatively recent observation regarding the two things considered primarily responsible for 100% uptime of a critical financial service since approx. 1992 were

ims hot standby (i.e. a fault fall-over technology) automated operater (getting the human element totally out of the loop).

random refs:
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/94.html#2
https://www.garlic.com/~lynn/99.html#107
https://www.garlic.com/~lynn/99.html#136a

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: Thu, 16 Nov 2000 10:55:28 GMT

There was also a battle over implementing the full 370 relocation architecture. The 165 engineers said that it would take an extra six months to do the full 370 relocation architecture hardware for the 165 ... and so there was eventually a decision made to drop various things from the 370 virtual memory relocation architecture in order to speed the hardware retrofit package out the door.

The 135/145 then had to have an update to the microcode load that corresponded to the 370 relocation architecture hardware subset that was being supported by the 155 & 165.

138 & 148 were later enhancements to the 135 & 145 (which somewhat correspond to the 158 & 168 enhancments).

The 138/148 also introduced the concept of microcode operating system performance assists for VS1 & VM/370. Basically the 138/148 engines were simulating 370 instructions at about a 10:1 emulation. Much of operating instruction code could be moved directly to microcode at one microcode instruction for every 370 instruction (giving a 10:1 performance boots). There were also some special cases that saw much larger than 10:1 ... typically associated with not having to save/restore 370 registers for a subfunction (i.e. microcode could do it using its own domain bypassing the traditional save/restore function call paradigm if it was all within the same 370 domain).

misc. url
https://www.garlic.com/~lynn/2000.html#12
https://www.garlic.com/~lynn/94.html#21

there was also a pentagon papers like event ... before the relocation announcement, a copy of a document was leaked & made it to the press that contained the description of the new relocate hardware features. after a lengthy investigation ... eventually all the copier machines in the company were retrofitted with little serial number under the glass that would show up on all copies made with that machine.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

TSS ancient history, was X86 ultimate CISC? designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS ancient history, was X86 ultimate CISC? designs)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: Thu, 16 Nov 2000 11:19:27 GMT

The aggregate of all the related 360/67 time-sharing activities (tss/360, cp/67, etc ) may not seem significant compared to the 360 batch market which so dwarfed them ... and yet at the same time .. the total resources poured into those "insignificant" time-sharing activities were possibly as large as the aggregate of all other resources going into time-sharing activities going on at the time (independent of the issue of the effectiveness of those resources).

random refs:
https://www.garlic.com/~lynn/2000.html#64
https://www.garlic.com/~lynn/2000f.html#18
https://www.garlic.com/~lynn/99.html#2
https://www.garlic.com/~lynn/99.html#64
https://www.garlic.com/~lynn/94.html#46
https://www.garlic.com/~lynn/94.html#53
https://www.garlic.com/~lynn/95.html#1
https://www.garlic.com/~lynn/98.html#11
https://www.garlic.com/~lynn/98.html#12

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive  designs)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: Fri, 17 Nov 2000 00:59:26 GMT

they did a special microcode load ... which implemented in microcode a periodic sampling event that would wake up on regular intervals and check the PSW. A counter was incremented based on what it observed as to the PSW activity. The table of where the CPU was spending its time was used to compliment the work that is referenced in

In the following reference ...
https://www.garlic.com/~lynn/94.html#21

the person that wrote the 145 microcode for the APL assist and the above mentioned microcode address sampler was in the same group as the person that I worked with to do the analysis in the indicated reference i.e. two methods were used to do the kernel analysis, one was a microcode address sampler and the other was software changes that hooked into the inter-module call routine which created time-stamped record whenever the inter-module call function was invoked ... giving the current time value (64 370 tod clock), call-frome/return address, and call-to address. The above reference gives the data reduction from the software inter-module call analysis.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
Newsgroups: alt.folklore.computers
Date: Fri, 17 Nov 2000 16:17:50 GMT

Many of the batch efforts were also significantly independent (big difference between the DOS & PCP efforts).

some of them had better commercial success than others.

the migration from existing commercial batch operations (things like payroll) tended to be a lot more straight-forward (compared to the existing batch, commercial market take-up of a new paradigm) ... and also tended to have a significant amount of business process value dependency associated with it (frequently much easier to see the downside of not getting out payroll on time).

As a student, I had done a HASP hack on MVT18 that supported 2741&tty terminals with a CMS editor syntax (which can be traced back to CTSS) for CRJE functions (i.e. conversational remote job entry ... i.e. editing simulated card decks that would be submitted as a file to the batch processer ... as if the file had been created by reading cards).

IBM did go thru various CRJE-like offerings ... including TSO showing up late in the MVT product cycle.

I would claim that it wasn't that IBM didn't offer time-sharing in addition to batch ... but various other factors shaped the market:

1) things were still maturing and numerous factors constrained not being able to offer batch and time-sharing as a single package (it was even difficult to offer a single batch packaged offering ... witness 360 DOS & PCP and their descendants still around today).

2) majority of the existing market was commercial batch dataprocessing and upgrade to a batch paradigm was more straightforward for the majority of the market than a paradigm switch (like lots of ibsys cobol to 360 cobol translation went on).

3) online, interactive can be viewed as quite anti-thetical to a number of the commercial batch business processes ... where there is a strong motivation to eliminate all human-related vaguries from consistent delivery of the functions supported.

I've even posted a number of times

1) that the various "interactive" derived platforms tend to have an implicit design point that if something goes wrong ... you send a message to the person ... and the person figures out what to do (or maybe just throw it away totally, because people wouldn't be able to fiure it out).

2) 7x24 operations (including emerging web server industry) requires an implicit design point that a person doesn't exist ... and that all deviations have to be trappable programatically at several levels, default system, application, etc. This is a design point that batch oriented services have addressed significantly better than the interactive-derived platforms.

3) simple example I encountered a number of instances during the late '80s and early '90s of not being able to trap various ICMP packets at the application level and appropriately handle ... something that was doing in the '70s in a totally different environment providing 7x24 online, unattended services.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
Newsgroups: alt.folklore.computers
Date: Fri, 17 Nov 2000 23:07:49 GMT

various things extracts
CP-40 and CMS

In the Fall of 1964, the folks in Cambridge suddenly found themselves in the position of having to cast about for something to do next. A few months earlier, before Project MAC was lost to GE, they had been expecting to be in the center of IBM's time-sharing activities. Now, inside IBM, "time-sharing" meant TSS, and that was being developed in New York State. However, Rasmussen was very dubious about the prospects for TSS and knew that IBM must have a credible time-sharing system for the S/360. He decided to go ahead with his plan to build a time-sharing system, with Bob Creasy leading what became known as the CP-40 Project. The official objectives of the CP-40 Project were the following:

1. The development of means for obtaining data on the operational characteristics of both systems and application programs;

2. The analysis of this data with a view toward more efficient machine structures and programming techniques, particularly for use in interactive systems;

3. The provision of a multiple-console computer system for the Center's computing requirements; and

4. The investigation of the use of associative memories in the control of multi-user systems. 22

The project's real purpose was to build a time-sharing system, but the other objectives were genuine, too, and they were always emphasized in order to disguise the project's "counter-strategic" aspects. Rasmussen consistently portrayed CP-40 as a research project to "help the troops in Poughkeepsie" by studying the behavior of programs and systems in a virtual memory environment. In fact, for some members of the CP-40 team, this was the most interesting part of the project, because they were concerned about the unknowns in the path IBM was taking. TSS was to be a virtual memory system, but not much was really known about virtual memory systems. Les Comeau has written: Since the early time-sharing experiments used base and limit registers for relocation, they had to roll in and roll out entire programs when switching users....Virtual memory, with its paging technique, was expected to reduce significantly the time spent waiting for an exchange of user programs.

...
Creasy and Comeau were soon joined on the CP-40 Project by Dick Bayles, from the MIT Computation Center, and Bob Adair, from MITRE. Together, they began implementing the CP-40 Control Program, which sounds familiar to anyone familiar with today's CP. Although there were a fixed number (14) of virtual machines with a fixed virtual memory size (256K), the Control Program managed and isolated those virtual machines in much the way it does today. 28 The Control Program partitioned the real disks into minidisks and controlled virtual machine access to the disks by doing CCW translation. Unit record I/O was handled in a spool-like fashion. Familiar CP console functions were also provided.

This system could have been implemented on a 360/67, had there been one available, but the Blaauw Box wasn't really a measurement tool. Even before the design for CP-40 was hit upon, Les Comeau had been thinking about a design for an address translator that would give them the information they needed for the sort of research they were planning. He was intrigued by what he had read about the associative memories that had been built by Rex Seeber and Bruce Lindquist in Poughkeepsie, so he went to see Seeber with his design for the "Cambridge Address Translator" (the "CAT Box"), which was based on the use of associative memory and had "lots of bits" for recording various states of the paging system. Seeber liked the idea, so Rasmussen found the money to pay for the transistors and engineers and microcoders that were needed, and Seeber and Lindquist implemented Comeau's translator on a S/360 Model 40.

Comeau has written:

Virtual memory on the 360/40 was achieved by placing a 64-word associative array between the CPU address generation circuits and the memory addressing logic. The array was activated via mode-switch logic in the PSW and was turned off whenever a hardware interrupt occurred. The 64 words were designed to give us a relocate mechanism for each 4K bytes of our 256K-byte memory. Relocation was achieved by loading a user number into the search argument register of the associative array, turning on relocate mode, and presenting a CPU address. The match with user number and address would result in a word selected in the associative array. The position of the word (0-63) would yield the high-order 6 bits of a memory address. Because of a rather loose cycle time, this was accomplished on the 360/40 with no degradation of the overall memory cycle.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
Newsgroups: alt.folklore.computers
Date: Sat, 18 Nov 2000 17:48:03 GMT

however, there were a number of 360/67s that had been sold to customers on the basis of the (relatively) massive tss/360 effort ... a product which was encountering difficulties. There were some number of CP/67 success stories which were being presented and talked about at the various user group meetings (share & to lesser extent guide).

Customers could strong-arm marketing & sales people to get a copy ... or could effectively bypass them ... and order cp/67 directly or even get a copy from another customers. At the time, the software wasn't charged for and shipped with full source as part of the standard distribution.

I was an undergraduate at a university that went through that cycle, had bought a 360/67 on the basis of TSS/360 time-sharing marketing pitch ... and eventually had to do various other things because of all the difficulties that TSS/360 was having.

Through various iterations, contact was made with the CP/67 group and in Jan. of 1968, some of the group came out to the university to do an "installation" (up until that CP/67 was only being used in Cambridge by the development group and out at Lincoln Labs). Then at the spring Share user group meeting in Houston, CP/67 had an "official" product announcement ... using the university as a "reference" instllation.

I got to play with CP/67 through-out 1968 ... rewriting many pieces, developing fast-path and cutting critical pathlengths by a factor of 10 (or in some cases a 100), redoing scheduling & dispathing (introducing fair share scheduling and dynamic feedback algorithms), redoing the virtual memory manager (new page replacement algorithms, vastly reduced path length, a thrashing control mechanism that was an alternative to the working set stuff in the literature at the time ... which provided significantly improved thruput), fixing a lot of bugs associated with production systems, etc.

I also put in the TTY/ASCII terminal support ... an implementation that Tom Van Vleck writes up as crashing his system 20-30 times in a single day.
http://www.lilli.com/360-67 (corrected)
https://www.multicians.org/thvv/360-67.html

It was during this period that various of the people that had been involved in CP/67 (both at Cambridge and Lincolng Labs) put together two different start-up spin-offs for offering commercial time-sharing services based on CP/67.

random refs:
https://www.garlic.com/~lynn/99.html#44
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/93.html#2
https://www.garlic.com/~lynn/93.html#26
https://www.garlic.com/~lynn/93.html#31
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/94.html#2
https://www.garlic.com/~lynn/94.html#4
https://www.garlic.com/~lynn/94.html#5
https://www.garlic.com/~lynn/94.html#7
https://www.garlic.com/~lynn/94.html#12
https://www.garlic.com/~lynn/94.html#18
https://www.garlic.com/~lynn/94.html#28
https://www.garlic.com/~lynn/94.html#46
https://www.garlic.com/~lynn/94.html#47
https://www.garlic.com/~lynn/94.html#48
https://www.garlic.com/~lynn/94.html#49
https://www.garlic.com/~lynn/94.html#52
https://www.garlic.com/~lynn/94.html#54

VM/370 was the follow-on product to CP/67 adapted for the 370 product line (conversion from 360/67 to 370 which had virtual memory on almost all processors eventually).

I had made some observation that the internal corporate deployment of VM/370 was rather large (for instance the majority of the internal network nodes were vm/370 and that was larger than arpanet/internet up thru about 1985) ... but smaller than the number of VM/370 customer installations. I was also doing custom modifications support of VM/370 that I shipped to (mostly) a very limited number of internal sites (although it had leaked out to ATT longlines at one point) ... The very limited number of internal installation that I directly supported was still larger than the total number of Multics installations.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
Newsgroups: alt.folklore.computers
Date: Sat, 18 Nov 2000 17:59:33 GMT

This was a CERN benchmark ... however the copy of the benchmark report that was provided to IBM was immediately classified "IBM Confidential Restricted" (distributed on need to know basis only, the only higher classification was registered, where each copy is numbered and regular, frequent security audits requiring copies kept in double lock cabinets).

The strategic forces inside IBM had moved from TSS/360 time-sharing to MVS/TSO (sort-of time-sharing) ... with CP/67 and VM/370 always being odd-man-out.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
Newsgroups: alt.folklore.computers
Date: Sat, 18 Nov 2000 20:35:53 GMT

even stranger was that the hdqtrs planning & forecasting functions were based on cp/67 (and then later vm/370). When EMEA hdqtrs moved from the US to Paris ... I hand carried a clone over and installed it.

HONE (field, sales, & marketing support) was first implemented on a CP/67 platform during the early '70s and then migrated to vm/370.

by the end of the 70s, HONE was primary vehicle for sales & marketing support (world-wide) ... many orders couldn't even be placed until they were first run thru a HONE "configurator" (and sales & marketing were still treating the vm/370 product as non-strategic offering).

In the late '70s, the online HONE installation was possibly the largest single system image operation in the world (supporting the tens of thousands of field, sales, & marketing people in the US).

random refs:
https://www.garlic.com/~lynn/97.html#4
https://www.garlic.com/~lynn/98.html#23
https://www.garlic.com/~lynn/99.html#38
https://www.garlic.com/~lynn/99.html#149
https://www.garlic.com/~lynn/99.html#150
https://www.garlic.com/~lynn/2000e.html#6
https://www.garlic.com/~lynn/2000e.html#22
https://www.garlic.com/~lynn/2000f.html#30

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

TSS ancient history, was X86 ultimate CISC? designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS ancient history, was X86 ultimate CISC? designs)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: Sun, 19 Nov 2000 04:12:11 GMT

The 370 line was later enhanced with models 138, 148, 158, and 168 (all with virtual memory).

some extracts concerning 360/40 & cp/40.
https://www.garlic.com/~lynn/2000f.html#59

other recent postings to alt.folklore.computers
https://www.garlic.com/~lynn/2000f.html#56
https://www.garlic.com/~lynn/2000f.html#58
https://www.garlic.com/~lynn/2000f.html#60
https://www.garlic.com/~lynn/2000f.html#61

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Cryptogram Newsletter is off the wall?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cryptogram Newsletter is off the wall?
Newsgroups: sci.crypt
Date: Sun, 19 Nov 2000 16:02:14 GMT

two issues ... 1) was the person actually presented what they were signing and 2) how close a correlation is there between the person's intent and the application of a signature.

in the digital world ... there is a lot larger gap in case #1 and #2.

for instance, when a person is using a pen to apply a signature to a paper document ... the probability of that pen wondering off and signing other pieces of paper at the same time is relatively low.

basically digital signature technology is method of authenticating digital information ... there has to be a lot of additional infrastructure wrapped around it to establish correlation between the digital signature authentication technology and a person's intent.

digital signature likely reduces the probability that there is counterfeit/fraud once the signature is applied. however, digital signature infrastructure widesn the gap between what the person sees and the actual signing operations (opening up new avenues for fraud).

random refs:
https://www.garlic.com/~lynn/aadsmore.htm#schneier

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Cryptogram Newsletter is off the wall?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cryptogram Newsletter is off the wall?
Newsgroups: sci.crypt
Date: Sun, 19 Nov 2000 16:30:23 GMT

trusted computer can be something you have ... tieing intent to a digital signature probably means more, something like each & ever digital signature has to carry with it some way of prooving that some combination of 3-factor authentication was used for each & every application of that digital signature (including that a something you have trusted computer was used for the actual operation)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
Newsgroups: alt.folklore.computers
Date: Mon, 20 Nov 2000 14:54:31 GMT

one group implemented a extension on a 360/50 supporting virtual machine like function using the emulation hardware base/bound support. That and a 360/65 version ... supposedly could run on a majority of the 360/50s & 360/65s in customer shops (it was done mostly by one person out of the seattle boeing sales office). However, it didn't include swapping batch regions.

The CP? (senior moment here) ... the PL/I conversational time-sharing system done on an 360/50 base that ran on top of OS/MFT. For performance, it also offered a 360/50 microcode enhancement (hardware) that put a lot of the PL/I interpreter into machine language. This may have used the base/bound hardware support also (I don't remember for sure).

As noted in Melinda's paper, IBM had extensive support at MIT for 7094 and CTSS. After project mac went with GE ... the ibm boston programming (on the 3rd floor of 545 technology sq) ... developed the PL/I conversational time-sharing system for the 360/50 (that ran as subregion under standard ibm batch system). This was almost totally unrelated to the CP-40, CP/67, virtual machine time-sharing work that went on at ibm cambridge scientific center on the 2nd & 4th floors of 545 technology sq.

random note, jean sammet was at the boston programming center (
https://www.garlic.com/~lynn/2000d.html#37).

Slightly different work ... but huntsville labs. (& Brown Univ?) did a custom version of OS/MVT (release 13 ... circa '67) that used the 360/67 relocation hardware but not for paging ... simply for managing storage fragmentation. They had bought a two-processor 360/67 (another of the TSS promises) with multiple 2250s (large display screen) for online design application. The problem was that each 2250 effectively ran as a (very) long running batch region under MVT and after some interval ran into severe storage fragmentation problems. OS/MVT (release 13, running on duplex 360/67) was modified to dispatch application regions in virtual memory mode. No paging was supported, but it greatly simplified supporting contiguous regions of application execution code & data.

OT ... in late '68 (very early '69?_, when BCS was formed ... the huntsville duplex was shutdown and shipped to seattle. Some of the people may have came with it ... and I believe one of the people from the university (brown?).

Spring break '69 I taught a 40hr cp/67 class to the core BCS technical team (I was still an undergraduate taking classes) ... there may have been 10 people (both BCS and ibm team assigned to BCS). BCS by that time had possibly 30 people total (it sort of had been initially formed as a adjunct to corporate hdqtrs data processing ... which had primarily been payroll on a single 360/30).

By that time, supposedly airospace computing center reported to BCS; hdqtrs was barely out of being a 360/30 ... and they joked that aerospace during a 2-3 year period had $100m worth of 360 equipment continuely sitting in hallways at the renton data center waiting to be installed, i.e. 360 equipment was arriving faster than ibm could install it so it was continuely being staged in the hallways ... at any one time, there might be 10-20 360/65 & 360/75 and associated stuff sitting around in the hallways (i.e. goldfish swallowing a whale ... little corporate politics went on).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Building so big it generates own weather?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Building so big it generates own weather?
Newsgroups: alt.folklore.military,alt.folklore.science,alt.folklore.urban,alt.aviation.safety,alt.fan.cecil-adams,seattle.general,sci.skeptic,rec.aviation.military,sci.physics
Date: Tue, 21 Nov 2000 02:32:50 GMT

... 707 would have predated seafair ... would have still been goldcup, if i remember right ... mid-50s was slow-moe era (slow-moe 4? and slow-moe 5? taking first place).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

TSS ancient history, was X86 ultimate CISC? designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS ancient history, was X86 ultimate CISC? designs)
Newsgroups: comp.arch
Date: Tue, 21 Nov 2000 15:06:55 GMT

there was simpson's brand new operator system (but i don't remember if it was called ASPEN or not) ... sort of derivative of the RASP work he did while at IBM (there were some litigation, and people checking the code that there was zero RASP code, RASP was sort of a name hack on HASP which something that simpson did in the '60s). simpson/dallas work going on about the same time as gold. my suggestion was that the dallas work be used as underlying platfrom for Au (something like the TSS/unix thing did for AT&T ... from my standpoint there seemed to be quite a bit of nih & competition between dallas and sunnyvale).

random refs:
https://www.garlic.com/~lynn/2000c.html#81
https://www.garlic.com/~lynn/2000.html#76
https://www.garlic.com/~lynn/2000.html#64

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

TSS ancient history, was X86 ultimate CISC? designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS ancient history, was X86 ultimate CISC? designs)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 21 Nov 2000 15:22:25 GMT

more info on keykos
http://www.cis.upenn.edu/~KeyKOS
https://web.archive.org/web/20010301032856/www.cis.upenn.edu/~KeyKOS/

from some long forgotten archive see aspen ref in the attach ... (4th paragraph).

Start-Up Firm To Test MVS Replacement

From November 25, 1985 issue of Information Week

Byline: Paul E. Schindler, Jr.

Key Logic's system said to support 500 transactions per second

The first radically new IBM-mainframe operating system in years is now being tested in Cupertino, Calif. And the company that's preparing it for market is looking for just a few transaction-processing users to act as beta sites.

Just seven months after its founding, Key Logic is asking prospective users whether they want to achieve higher performance on IBM mainframes by replacing the MVS and VM operating systems with its new KeyKOS program.

Early benchmarks show that the firm's operating system supports as many as 500 transactions per second. That's faster than transaction processors from industry leaders Tandem Computers Inc., Cupertino, Calif., and Stratus Computer Inc., Marlboro, Mass. According to the Gartner Group Inc., a consulting firm in Stamford, Conn., Tandem offers about 150 transactions per second, Stratus about 50, and IBM's CICS peaks at 70 transactions per second.

Key Logic's early users will get the chance to run one of the few alternatives to the basic IBM mainframe operating system. Although Amdahl Corp. sells a mainframe Unix called UTS, and may someday release a souped-up MVS-like operating system developed under the code-name Aspen, UTS is not new to the market and Aspen is not a radical departure.

KeyKOS is both. It offers high performance, reliability, security, and programmer productivity, the company says. It should be ideally suited for remote operations, since it was itself developed remotely. According to Steve Gimnicher, Key Logic's development manager, "The original architects never saw the machine it ran on." They were in Cupertino developing KeyKOS by communicating with a mainframe in Dallas.

The KeyKOS transactional operating system was written from scratch, but it wasn't all done in the seven months Key Logic has been in business. KeyKOS stems from a decade's work on the system at Tymnet's Tymshare service, now part of McDonnell Douglas Corp.

Key Logic consists of 11 employees who have a total of 200 years of experience. Despite that, says Vincent A. Busam, vice president of development, KeyKOS isn't being generally released yet. However, the firm is ready to support a handful of selected installations while it improves its documentation and builds its service and support organization.

In addition to supporting as many as 500 transactions per second on an IBM 3083 JX, or 130 transactions per second on an IBM 4381, benchmarks show that KeyKOS reduces elapsed time for some heavy input/output programs by 71% compared with IBM's VM/CMS. It cuts CPU resources by 30% for the same programs.

The risk of trying KeyKOS is relatively low, since KeyKOS runs as a guest under VM, and any VM/CMS program can run under KeyKOS. In the guest mode, its high performance is not realized, but all functionality can be tested.

Busam believes he knows who Key Logic's first customers will be: those in the transaction-processing gap. Although IBM's TPF2 (formerly the Airline Control Program) can handle as many as 1,000 transactions per second, it is not cost-effective below 300 transactions per second. That leaves a performance gap in the 150-to-300 transactions per second range, where KeyKOS should fit well, Busam believes.

Gimnicher notes that there are other advantages as well, especially in all-IBM shops that hesitate to move to a radically different architecture.

Programmers continue to deal with the same hardware they have used for years. In a three-week course, they can learn how to program efficiently under KeyKOS using standard IBM programming languages. Experience indicates that programmers writing applications for KeyKOS produce 40% less code than do programmers for other operating systems, including IBM's MVS and VM.

This kind of productivity is made possible by two new computing principles upon which KeyKOS is based. The first principle deals with communications. Programs, tasks, files, or even guest operating systems are all known as objects that communicate via messages. Objects cannot communicate with each other unless given the "keys" (Key Logic calls them capabilities) to do so. This ensures both security and reliability. A failure in one object cannot affect any other object, ensuring continued operation.

The other principle deals with memory. As with IBM's System/38, for example, KeyKOS treats all main memory and disk storage as one virtual memory. Programmers do not have to deal with disk I/O routines or file management -- KeyKOS does.

On the West Coast, analysts predict Key Logic will give IBM and Tandem competition in the transaction-processing market. But not everyone is so enthusiastic. Mike Braude, a Gartner Group analyst, says: "The big problem, of course, is vendor viability." In short, users want to know if Key Logic will be around. But users should note that the same concern was expressed about Tandem in 1974 and Stratus in 1980.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

TSS ancient history, was X86 ultimate CISC? designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS ancient history, was X86 ultimate CISC? designs)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 21 Nov 2000 16:28:47 GMT

A big problem for (at least mainframe) operating systems has been hardware support with device error & anomaly handling .. typically 10 or more code than the straightline device drivers & i/o supervisor. That was in part, UTS deployment as a CP guest (vm/cms) ... relying on cp error & anomaly code. UTS platformed on the low-level pieces of ASPEN would have been able to rely on the ASPEN error & anomaly handling code. This would have been similar to the TSS/Unix deployment for AT&T ... with somewhat better job of eliminating function & pathlength duplication between the low-level micro-kernel and the unix subsystem.

random refs:
https://www.garlic.com/~lynn/2000c.html#69

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

HASP vs. "Straight OS," not vs. ASP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP vs. "Straight OS," not vs. ASP
Newsgroups: bit.listserv.ibm-main
Date: Wed, 22 Nov 2000 01:16:17 GMT

misc. asp stuff from earlier this year:
https://www.garlic.com/~lynn/2000.html#76
https://www.garlic.com/~lynn/2000.html#77

misc. stuff on hasp/JES2 networking
https://www.garlic.com/~lynn/99.html#33

OT:
https://www.garlic.com/~lynn/2000f.html#68
https://www.garlic.com/~lynn/2000f.html#69
https://www.garlic.com/~lynn/2000f.html#70

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

SET; was Re: Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SET; was Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Wed, 22 Nov 2000 16:00:04 GMT

one of the data elements is the hash of the order details ... but not the actual order details.

the x9.59 standard doesn't actually specify messages ... but there has been work on mapping the x9.59 signed data elements within existing financial standards messages and protocols (supporting deployment of x9.59 in both currently non-existent financial infrastructures as well as existing financial infrastructures).

x9.59 shopping can be done via SSL web ... then sending off a purchase request message and getting a reply. x9.59 shopping can be also done from offline cdrom and an x9.59 purchase request email and getting an x9.59 purchase request reply email (i.e. one requirement on the x9.59 standard definition was that it could be done in a single round-trip). Or x9.59 shopping could be done at point-of-sale ... i.e. the x9.59 standard was not defined to be an Internet-specific standard ... but the requirement on the work group was a standard for all electronic account-based retail transactions preserving the integrity of the financial infrastructure (it is rather difficult to enforce ssl-based shopping experience when physically present in a merchant's store).

x9.59 does specify that the account number is used in "authenticated" transactioons, i.e. non-x9.59 transactions with the x9.59 account-number are not to be approved. many/most issuers support mapping multiple account-numbers to the same account i.e. various implementations might include x9.59 only accounts, accounts with mixture of x9.59 account-numbers and non-x9.59 account-numbers, family member account-numbers, etc. Rather than having to keep the x9.59 account-number secret in order to prevent fraudulent transactions ... fraudulent x9.59 transactions are prevented by requiring that they all be end-to-end strong integrity and authenticated.

work as also been done on authenticated X9.59-like transactions using AVS for hardgood drop shipment ... signed transaction goes to shipper authorizing address and gets a transaction code supplied to the merchant. merchant applies the transaction barcode to the package. the shipper reads the bar-code and looksup the routing code. Eventually shipper applies real address label for final drop. The hardgood shipping authorization can be piggybacked in the same transaction/email with the payment instruction (which the merchant has to forward to the shipping service for fulfillment). Again this could be a web-based experience, something like a cdrom/email based experience, and/or physically in the store and wanting the goods shipped back home.

Also, x9.59 & x9.59-like definitions are privacy neutral ... not divulging any privacy information ... while still providing end-to-end strong integrity.

work is also going on to advance it to ISO international standard as well as define support within existing ISO 8583 (i.e. international payment card protocol standard). ABA (american bankers association) servers as the secretaiat of both X9 (US) and TC68 (iso/internation) financial standards organization.

there is also the trade-off between BBB/consumer-report certification using certificates vis-a-vis something like an online BBB web-site. Trust tends to come in many forms; brand, advertisement, word-of-mouth, prior experience, certification, etc. when influencing directing the shopping experience. One of the trust issues is that in terms of number of transactions ... the vast majority of transactions (possibly approaching 90+% are brand, advertisement, word-of-mouth, and/or prior experience based-trust). For the remaining that involve people actually performing some sort of certification checking ... various certification entities have expressed interest in on-line web-based certification service ... since that creates a tighter binding between them and their relying parties (the old saw about the thing called certificates being an offline paradigm ... targeted for operations that need to work in an offline environment).

misc. refs:
http://www.x9.org/ US financial standards body
http://www.tc68.org/ ISO financial standards body
https://www.garlic.com/~lynn/ ... some information on x9.59

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Cryptogram Newsletter is off the wall?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cryptogram Newsletter is off the wall?
Newsgroups: sci.crypt
Date: Wed, 22 Nov 2000 16:06:50 GMT

to some extent the existing prevalent smartcard paradigm is left over from the mid-80s defining portable computing capability using the technology trade-offs that existing at that point in time. to large extent the mid-80s trade-offs that resulting in smartcard paradigm were replaced in the early 90s with PDAs and cellphones ... i.e. mid-80s had relatively inexpensive complex computing chips that could be packaged in portable form-factors ... but cost-effective portable input/output capability didn't really exist.

The PDAs and cellphone technologies have largely obsoleted the technology trade-off decisions from the mid-80s that gave rise to much of the existing smartcard paradigm.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Metric System (was: case sensitivity in file names)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Metric System (was: case sensitivity in file names)
Newsgroups: alt.folklore.computers
Date: Wed, 22 Nov 2000 17:28:02 GMT

going back further ... when ibm declined to buy the university 709 (serial number was less than five, possibly three) for a museum, it was sold for scrap (vaquely remember that it required 20ton rated air condition unit). guy that bought it, set it up in a barn ... and would run it on cold days with the doors open and big industrial fans.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Florida is in a 30 year flashback!

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Florida is in a 30 year flashback!
Newsgroups: alt.folklore.computers
Date: Thu, 23 Nov 2000 19:36:06 GMT

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

8086 Segmentation (was 360 Architecture, Multics, ...)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 8086 Segmentation (was 360 Architecture, Multics, ...)
Newsgroups: alt.folklore.computers,comp.arch
Date: Thu, 23 Nov 2000 19:38:14 GMT

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Reading wireless (vicinity) smart cards

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Reading wireless (vicinity) smart cards
Newsgroups: alt.technology.smartcards
Date: Thu, 23 Nov 2000 19:41:00 GMT

then there is bluetooth for 1m-2m.
http://www.bluetooth.com

... also try search engines on iso 14443 & bluetooth

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

TSS ancient history, was X86 ultimate CISC? designs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS ancient history, was X86 ultimate CISC? designs)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: Fri, 24 Nov 2000 16:09:54 GMT

random refs:
https://www.garlic.com/~lynn/2000.html#8
https://www.garlic.com/~lynn/2000.html#63
https://www.garlic.com/~lynn/2000.html#86
https://www.garlic.com/~lynn/2000b.html#51

from melinda's web site
https://www.leeandmelindavarian.com/Melinda#VMHist
In the Fall of 1964, the folks in Cambridge suddenly found themselves in the position of having to cast about for something to do next. A few months earlier, before Project MAC was lost to GE, they had been expecting to be in the center of IBM's time-sharing activities. Now, inside IBM, "time-sharing" meant TSS, and that was being developed in New York State. However, Rasmussen was very dubious about the prospects for TSS and knew that IBM must have a credible time-sharing system for the S/360. He decided to go ahead with his plan to build a time-sharing system, with Bob Creasy leading what became known as the CP-40 Project. The official objectives of the CP-40 Project were the following:

1. The development of means for obtaining data on the operational characteristics of both systems and application programs;

2. The analysis of this data with a view toward more efficient machine structures and programming techniques, particularly for use in interactive systems;

3. The provision of a multiple-console computer system for the Center's computing requirements; and

4. The investigation of the use of associative memories in the control of multi-user systems.

The project's real purpose was to build a time-sharing system, but the other objectives were genuine, too, and they were always emphasized in order to disguise the project's "counter-strategic" aspects. Rasmussen consistently portrayed CP-40 as a research project to "help the troops in Poughkeepsie" by studying the behavior of programs and systems in a virtual memory environment. In fact, for some members of the CP-40 team, this was the most interesting part of the project, because they were concerned about the unknowns in the path IBM was taking. TSS was to be a virtual memory system, but not much was really known about virtual memory systems. Les Comeau has written: Since the early time-sharing experiments used base and limit registers for relocation, they had to roll in and roll out entire programs when switching users....Virtual memory, with its paging technique, was expected to reduce significantly the time spent waiting for an exchange of user programs.

22 R.J. Adair, R.U. Bayles, L.W. Comeau, and R.J. Creasy, A Virtual Machine System for the 360/40, IBM Cambridge Scientific Center Report 320-2007, Cambridge, Mass., May, 1966.

================

What was most significant was that the commitment to virtual memory was backed with no successful experience. A system of that period that had implemented virtual memory was the Ferranti Atlas computer, and that was known not to be working well. What was frightening is that nobody who was setting this virtual memory direction at IBM knew why Atlas didn't work. 23

Creasy and Comeau spent the last week of 1964 24 joyfully brainstorming the design of CP-40, a new kind of operating system, a system that would provide not only virtual memory, but also virtual machines. 25 They had seen that the cleanest way to protect users from one another (and to preserve compatibility as the new System/360 design evolved) was to use the System/360 Principles of Operations manual to describe the user's interface to the Control Program. Each user would have a complete System/360 virtual machine (which at first was called a "pseudo-machine"). 26

The idea of a virtual machine system had been bruited about a bit before then, but it had never really been implemented. The idea of a virtual S/360 was new, but what was really important about their concept was that nobody until then had seen how elegantly a virtual machine system could be built, with really very minor hardware changes and not much software.

------------------------------------------------------------

23 L.W. Comeau, "CP-40, the Origin of VM/370", Proceedings of SEAS AM82, September, 1982, p. 40.

24 Creasy had decided to build CP-40 while riding on the MTA. "I launched the effort between Xmas 1964 and year's end, after making the decision while on an MTA bus from Arlington to Cambridge. It was a Tuesday, I believe." (R.J. Creasy, private communication, 1989.)

25 R.J. Creasy, General Description of the Research Time-Sharing System with Special Emphasis on the Control Program, IBM Cambridge SR&D Center Research Time-Sharing Computer Memorandum 1, Cambridge, Mass., January 29, 1965. L.W. Comeau, The Philosophy and Logical Structure of the Control Program, IBM Cambridge SR&D Center Research Time-Sharing Computer Memorandum 2, Cambridge, Mass., April 15, 1965.

26 For the first few weeks, the CSC people referred to their concept as a "pseudo-machine", but soon adopted the term virtual machine after hearing Dave Sayre at IBM Research use it to describe a system he had built for a modified 7044. Sayre's M44 system was similar to CP-40, except for the crucial difference of not providing a control program interface that exactly duplicated a real machine. The CP-40 team credited Sayre with having "implanted the idea that the virtual machine concept is not necessarily less efficient than more conventional approaches." (L. Talkington, "A Good Idea and Still Growing", White Plains Development Center Newsletter, vol. 2, no. 3, March, 1969.) "The system built by Dave Sayre and Bob Nelson was about as much of a virtual machine system as CTSS---which is to say that it was close enough to a virtual machine system to show that 'close enough' did not count. I never heard a more eloquent argument for virtual machines than from Dave Sayre." (R.J. Creasy, private communication, 1990.)

27 "Dick Bayles was not only a great programmer, he was also the fastest typist I have ever seen." (W.J. Doherty, private communication, 1990.) "When Dick Bayles sat down [at a keypunch], he wrote code as fast as it could punch cards. Yes, the machine was slower than Bayles composing code on the fly." (R.J. Creasy, private communication, 1989.)

==================

One of the fun memories of the CP-40 Project was getting involved in debugging the 360/40 microcode, which had been modified not only to add special codes to handle the associative memory, but also had additional microcode steps added in each instruction decoding to ensure that the page(s) required for the operation's successful completion were in memory (otherwise generating a page fault).

The microcode of the 360/40 comprised stacks of IBM punch card-sized Mylar sheets with embedded wiring. Selected wires were "punched" to indicate 1's or 0's. Midnight corrections were made by removing the appropriate stack, finding the sheet corresponding to the word that needed modification, and "patching" it by punching a new hole or by "duping" it on a modified keypunch with the corrections. 32

Back during that last week of 1964, when they were happily working out the design for the Control Program, Creasy and Comeau immediately recognized that they would need a second system, a console monitor system, to run in some of their virtual machines. Although they knew that with a bit of work they would be able to run any of IBM's S/360 operating systems in a virtual machine, as contented users of CTSS they also knew that they wouldn't be satisfied using any of the available systems for their own development work or for the Center's other time-sharing requirements. Rasmussen, therefore, set up another small group under Creasy to build CMS (which was then called the "Cambridge Monitor System"). The leader of the CMS team was John Harmon. 33 Working with Harmon were Lyndalee Korn and Ron Brennan. Like Multics, CMS would draw heavily on the lessons taught by CTSS. Indeed, the CMS user interface would be very much like that of CTSS.

Since each CMS user would have his own virtual machine, CMS would be a single-user system, unlike CTSS. This was an important factor in the overall simplicity and elegance of the new system. 34 Creasy has written that one of the most important lessons they had learned from their CTSS experience was "the necessity of modular design for system evolution. Although [CTSS was] successful as a production system, the interconnections and dependencies of its supervisor design made extension and change difficult." 35

------------------------------------------------------------

32 R.U. Bayles, private communication, 1989. "The Model 40 was a Hursley (UK) product, announced in 1964. It used the first programmable ROS (invented by Tony Proudman, I believe) called Transformer Read-Only Storage (developed in 1961/2). In the Model 40 the circuit on the Mylar sheets wound around 60 cores, hence allowing the storage of 60-bit words; the Model 40 had 4096 60-bit words. It was this re-programmable storage that made the Model 40 modifiable, as you describe." (M.F. Cowlishaw, private communication, 1990.)

33 J.B. Harmon, General Description of the Cambridge Monitor System, IBM Cambridge SR&D Center Research Time-Sharing Computer Memorandum 3, Cambridge, Mass., May 12, 1965.

34 Bob Creasy has commented, "Simplicity was important because of our limited resource. I didn't expect the design [of CMS] to hold for more than a couple of years. We recognized the importance of multiple processes in a single-user environment, but we could not afford the complexity. To put it another way, we weren't smart enough to make it simple enough." (R.J. Creasy, private communication, 1990.) 35 R.J. Creasy, "The Origin of the VM/370 Time-Sharing System", IBM Journal of Research and Development, vol. 25, no. 5, September, 1981, p. 485.

================

CP-40 would be far more modular than CTSS, in that it would be divided into two independent components. In the words of Bob Creasy:

A key concept of the CP/CMS design was the bifurcation of computer resource management and user support. In effect, the integrated design was split into CP and CMS. CP solved the problem of multiple use by providing separate computing environments at the machine instruction level for each user. CMS then provided single user service unencumbered by the problems of sharing, allocation, and protection. 36 As the weeks went by and the real power of the virtual machine concept unfolded before them, their excitement grew. In discussing the decision to create exact replicas of real machines, Les Comeau has written, "It seems now that the decision to provide a Control Program interface that duplicated the System/360 architecture interface was an obvious choice. Although it was, given our measurement objective, it wasn't, given our in-house interactive system objective." 37 He credits "the strong wills and opinions of the group" for providing further motivation for selecting such a well-defined interface 38 between the CP and CMS components:

I think that most designers recognize the need for good separation of function in programming system design, but compromise becomes the rule very early in the effort. With the particular group assembled to build CP/CMS, the personalities reinforced that design principle, rather than compromising it.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Cryptogram Newsletter is off the wall?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cryptogram Newsletter is off the wall?
Newsgroups: sci.crypt
Date: Fri, 24 Nov 2000 16:14:58 GMT

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

next, previous, subject index - home