2002 Newsgroup postings (12/18 - 12/31) Lynn Wheeler

2002 Newsgroup Postings (12/18 - 12/31)

misc recent somewhat VM-related threads in other n.g
Linux paging
Linux paging
Vector display systems
Vector display systems
AMP vs SMP
Sci Fi again was: THIS WEEKEND: VINTAGE
Big Brother -- Re: National IDs
Sci Fi again was: THIS WEEKEND: VINTAGE
Big Brother -- Re: National IDs
radix sort
computers and alcohol
Possible to have 5,000 sockets open concurrently?
Big Brother -- Re: National IDs
computers and alcohol
Possible to have 5,000 sockets open concurrently?
cost of crossing kernel/user boundary
Difference between AAA and Radius?
Difference between AAA and Radius?
Beyond 8+3
Cost of CPU second
Beyond 8+3
20th anniversary of the internet (fwd)
Free Desktop Cyber emulation on PC before Christmas
Vector display systems
Beyond 8+3
LISTSERV Discussion List For USS Questions?
Beyond 8+3
Origin of XAUTOLOG (x-post)
Collating on the S/360-2540 card reader?
System Hang
Collating on the S/360-2540 card reader?
Collating on the S/360-2540 card reader?
Star Trek: TNG reference
Star Trek: TNG reference
HASP:
HASP:
HASP:
ibm time machine in new york times?
HASP:
ibm time machine in new york times?
ibm time machine in new york times?
ibm time machine in new york times?
Star Trek: TNG reference
System vs. application programming?
ibm time machine in new york times?
ibm time machine in new york times?
myths about Multics
myths about Multics
myths about Multics
myths about Multics
windows office xp
Big Brother -- Re: National IDs
MVS History
cost of crossing kernel/user boundary

misc recent somewhat VM-related threads in other n.g

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: misc recent somewhat VM-related threads in other n.g.
Newsgroups: bit.listserv.vmesa-l
Date: Wed, 18 Dec 2002 10:23:04 -0700

misc. recent vm relateds threads in comp.arch and bit.listserv.ibm-main

https://www.garlic.com/~lynn/2002p.html#43 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002p.html#44 Linux paging
https://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
https://www.garlic.com/~lynn/2002p.html#59 AMP vs SMP
https://www.garlic.com/~lynn/2002p.html#62 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary

Linux paging

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux paging
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 19 Dec 2002 03:29:24 GMT

SEYMOUR.J.METZ@CUSTOMS.TREAS.GOV (Shmuel Metz , Seymour J.) writes:
Maybe Kevin was thinking of a shared saved segment. Contrast I CMS with a full CMS IPL.

VM has generalized saved memory images (aka "named systems") ... where it is also possible to specify some number of the segments that have been saved as "shared" (r/o shared and everybody that "IPL" CMS gets the image of the saved system ... plus sharing the same segments that have been specified by everybody that has IPL'ed the same CMS. Simulated "ipl by device" takes significantly longer ... than "ipl by name" ... since the saved image is done at a point after some amount of the normal ipl operation has been performed. Furthermore (at least for CMS) some amount of the memory image is already present in the shared segment image portions.

It is also possible to specify "IPL" of almost any memory image that has been saved. Back in the days of MVT ... many shops on both CP/67 and later VM/370 ... created MVT saved images ... for fast MVT ipls (bypassing some amount of the ipl by device processing ... but w/o the r/o shared segment specification found in CMS).

For release 3 of VM/370 a subset of my generalized virtual memory management stuff was released as "discontiguous named systems". This allowed other types of memory images to be saved and loaded into a process virtual memory on the fly (possibly nothing shared, all shared, or some mix of shared and non-shared pages). Pretty much all of the CMS code that I had changed was released for dynamic shared images (except for the paged mapped file system stuff). Only about half of the CP code that I had changed was included in the discontiguous named system support. CMS is able to execute a kernel API that remaps parts of the virtual machine address space with memory images that have been saved (along with remapping of segment table entries to r/o shared page tables as specified in the CP control information).

The full blown function provided for shared segments to be loaded at arbritrary and possibly even the same shared segments to be located at different addresses in different virtual address space. This allowed more efficient packing of name memory applications in the days of 24bit (16mbyte) virtual addressing. CMS eventually built up a sizeable number of standard saved memory applications. W/o the ability for a individual address space to arbritrarily pack applications at any available address ... resulted in an installation having to choose a globally unique address for each application ... across the library of all applications. This actually became impossible as the number of different named applications got large resulting in some number of applications having to same virtual addresses. This then resulted in such applications unable to co-exist at the same time in the same address space.

The other part of the infrastructure was the paged mapped file system for CMS ... with virtual memory paging capabiilty supported by (CP) kernel API. Among other things this allowed CMS to implement all the functions available in the discontiguous-named-systems functions but mapped to normal cms files (i.e. the saving and naming of dicontiguous-named-systems was a cp privileged operation, however the page mapped file system implementation supported all the same capability ... but w/o requiring cp privileged operations ... just normal CMS file system operations).
https://www.garlic.com/~lynn/submain.html#mmap

In any case ... if there was some "safe-point" after Linux ipl-by-device ... where it was possible to save some or all of the linux virtual memory image (say corresponding to a checkpoint kind of operation ... ala what a lot of installations did with MVT) ... then it would be possible to IPL by device. Furthermore, if it could be determine that some large portion of that memory image was r/o ... never changed ... then segments corresponding to the r/o areas of that memory image could be specified as "shared". Then all instances of virtual machines IPL-by-name that save image (with those specified shared segments) would share common code & data across all virtual space instances.

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

Linux paging

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux paging
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 19 Dec 2002 03:53:18 GMT

Anne & Lynn Wheeler writes:
It is also possible to specify "IPL" of almost any memory image that has been saved. Back in the days of MVT ... many shops on both CP/67 and later VM/370 ... created MVT saved images ... for fast MVT ipls (bypassing some amount of the ipl by device processing ... but w/o the r/o shared segment specification found in CMS).

it wasn't just mvt ... is was also done for various PCP and MFT versions also. somebody from union carbide had written a CMS-like shell that they ran with a "saved" image of PCP (under cp/67) ... writing/reading from PCP's (virtual) operator's console.

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

Vector display systems

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vector display systems
Newsgroups: alt.folklore.computers
Date: Thu, 19 Dec 2002 06:19:38 GMT

Morten Reistad writes:
After a couple of episodes where DEC and IBM disqualified themselves "forever", Prime had a chance; and it helped a lot with the Multics heritage of the OS, the networking and the aggressiveness of the company.

They did make duds like the 2250; but I'll forgive them for trying to make a low end effort. . They made it alright up until the crash in '87, but the next 6 months they went very stale. They went right over to milking the market. They milked the 9955 far too long. They got stuck in proprietary networks just when OSI and TCP/IP were battling for world surpremacy. They went from aggressive entrant to market milker almost overnight.

i would claim that the mini market was starting to go by 1985. The following from IDC report on world-wide vax shipments
https://www.garlic.com/~lynn/2002f.html#0

I don't have comparible numbers of comparable mid-range 370s shipments ... but i believe that they were starting to be similarly impacted.

Both PC and workstation shipments were starting to significantly impact the whole mini/midrange market in that period (along with the movement to less proprietary).

I also frequently take exception with all the OSI statements ... figment of a whole lot of peoples' imagination. misc. past refs:
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

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

Vector display systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vector display systems
Newsgroups: alt.folklore.computers
Date: Thu, 19 Dec 2002 15:15:51 GMT

Morten Reistad writes:
<more topic drift>

Some of us knew we wanted TCP/IP, and betted a career on it. Others went for OSI and squandered public money on that. You are right, in a sense OSI never was; it ran best on a 35mm slide projector. Smoke and mirrors. Some of the smoke made it's way into bids and proposals though. ISP's ran X.400 servers for a while. Then it died.

</topic drift>

but OSI didn't have an IP layer. It was '85 that the size of the internet (in large part because of pc, unix & workstation based implementations) had surpased the size of the internal network (effectively all mainframes). I've claimed that was because of the introduction of the IP-layer and gateways with the 1/1/83 switchover (as well as the protocol on entry level machines) ... see more 20th anv refs
https://www.garlic.com/~lynn/rfcietff.htm

part of the reason that the internal network had grown so well in the '70s and the early '80s was it effectively had a sort of gateway layer support in every node.

OSI was traditional copper point-to-point protocol. The ISO standards stuff was a facade .... a big issue being ISO standards could be passed w/o ever having an implementation. Doing some work in both IETF and ANSI X3S3.3 (us standards body for networking in the area of layers 3&4 of OSI model) on HSP (high speed protocol) ... ANSI statement was that a protocol for standards work could not be considered that violated the OSI model aka internet & ip-layer, and related gateways wouldn't be a ANSI/ISO standard because it violated OSI model.

The other area that internet succeeded was in the area of LAN support. ISO was somewhat schizo in this area ... with IEEE establishing a standard and IEEE is ISO-chartered standards body. LAN violates OSI model by collapsing levels 1, 2 and part of 3 into a single layer. All the grief we got on HSP in X3S3.3 and ISO about HSP ... which was bridging the gap between top of layer 4 directly to the top of LAN interface (aka middle of OSI layer 3).

At the time of interop '88 ... there was all sorts of noise about OSI (as earlier) ... the only real content was tcp/ip based stuff.
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

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

AMP vs SMP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AMP  vs  SMP
Newsgroups: bit.listserv.ibm-main
Date: Thu, 19 Dec 2002 15:26:29 GMT

broidoj@gti.net (Jeffrey R. Broido) writes:
pointed out that the 360/91 had an active console years earlier, backed by an embedded 360/40. They dismissed that by saying that the 360/91 was not a production system, IBM having only built twenty two of them. Then, we walked them over to our 370/158 and showed them the console. They looked. They blinked. We said, "so, how about the KI-10 having the first intelligent, interactive console?" The answer, "It's IBM. You can't count IBM."

i ran into something similar when a major lab was claiming that they had the best performing vm/370 timesharing system in the world. I pointed out to them that on similar workload and hardware ... their 90 percentile interactive response was twice one of my custom modified systems at SJR. They said its not fair to include a wheeler system in the comparison

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

Sci Fi again was: THIS WEEKEND: VINTAGE

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Sci Fi again was:  THIS WEEKEND: VINTAGE
Newsgroups: alt.folklore.computers
Date: Thu, 19 Dec 2002 16:06:52 GMT

hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins) writes:
I have encountered very few time-travel stories ever; most are just plain dumb, or cheesy, or poorly thought out (most common idiocy: that the mission is critical, or that a limited amount of time is available, with no explanation of why another mission couldn't start seconds ahead and divert the first (known to fail), or why the characters must return to the same point in time, or the same point plus time spent).

i ahve somewhat the same reaction to the transporter on st ... i've asserted that possibly hundreds of years before the scanning & computer technology reached the level of enabling transporter ... that simpler version of scanning/computers would have made bridge type configurations obsolete. use the scanning/computers technology focused on the brains with various related feedback technology and hook everybody together ... w/o requiring them all to be in a bridge configuration required by traditional voice-communication. such technology application possibly hundreds of years earlier than transporter capability ... whould have had significant impact on all forms of human activity. of course from a st entertainment standpoint for current cultures ... the depiction of such infrastructures would probably have little or no meaning (or at least little or no entertainment value).

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

Big Brother -- Re: National IDs

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big Brother -- Re: National IDs
Newsgroups: alt.folklore.computers
Date: Thu, 19 Dec 2002 16:24:21 GMT

hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins) writes:
We are far more productive than we were 50 years ago. Some political groups like to portray the predominance of housewives at the time as a form of oppression, but it was really a matter of America being wealthy enough that one worker could support a family in a comfortable lifestyle--and on a 40 hour workweek!

What leaves me utterly baffled is that as we've become more productive, the norm has become two jobs per family, each more than 40 hours, rather than cutting back on the number of hours worked per family.

one could also claim that there was some significant amount of capital accumulation during the 40s ... with a quite a bit of it not being distributed (aka significant manufacturing plants built for one reason or another) ... that such accumulated capital could then be lived off of during the 50s & 60s ... including the part about not re-investing until quite a bit of the "banked" capital depleated by the 70s with aging infrastructures.

one of the cases that stick in my mind are reports of various railroads paying out significant dividends and executive bonuses during the early '60s ... and then finding in the early 70s that they had been doing things like deferring yearly track maintenance operations since the early 50s.

Another assertion is that during the '60s the economy significantly leveraged the difference in the cost of oil vis-a-vis the price of oil ... aka the standard of living was significantly enhanced by being able to buy gasoline which possibly has a value of $10-$15/gal at $.20/gal.

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

Sci Fi again was: THIS WEEKEND: VINTAGE

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Sci Fi again was:  THIS WEEKEND: VINTAGE
Newsgroups: alt.folklore.computers
Date: Thu, 19 Dec 2002 19:20:45 GMT

"Rupert Pigott" <darkboo-remove-this-ng.@hotmail.com> writes:
Isn't that what the Borg have ? :)

all sorts of implants ... the scanning/computer technology in transporter w/feedback wouldn't have needed any implants/augmentation (just sense what the brain wanted ... and communicate it or do it).

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

Big Brother -- Re: National IDs

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big Brother -- Re: National IDs
Newsgroups: alt.folklore.computers
Date: Thu, 19 Dec 2002 19:32:44 GMT

Anne & Lynn Wheeler writes:
Another assertion is that during the '60s the economy significantly leveraged the difference in the cost of oil vis-a-vis the price of oil ... aka the standard of living was significantly enhanced by being able to buy gasoline which possibly has a value of $10-$15/gal at $.20/gal.

i think there was some sort of gov. economic report in the 99/2000 timeframe that made some statement to the effect that half of all manufacturing jobs were "subsidized" (aka the value of what employee produced was less than their salary/benefits) .. and the percentage was increasing.

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

radix sort

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: radix sort
Newsgroups: bit.listserv.ibm-main
Date: Fri, 20 Dec 2002 15:17:49 GMT

gah@UGCS.CALTECH.EDU (glen herrmannsfeldt) writes:
The best example I always use for radix sort is the algorithm used on the IBM card sorter, such as:

http://www.users.nwark.com/~rcmahq/jclark/cardsrt.htm

This is what IBM sold before they got into the computer business. That probably makes it older than quicksort.

-- glen

luther put a lot of thot into radix sort as part of the tree instructions, course they didn't make it into hardware before the pc

https://www.garlic.com/~lynn/2001.html#2 A new "Remember when?" period happening right now
https://www.garlic.com/~lynn/2001d.html#28 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001h.html#73 Most complex instructions
https://www.garlic.com/~lynn/2002.html#14 index searching
https://www.garlic.com/~lynn/2002d.html#18 Mainframers: Take back the light (spotlight, that is)

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

computers and alcohol

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: computers and alcohol
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 20 Dec 2002 20:02:36 GMT

thread cross-ever between mainframes scids and the a.f.c. thread about computers and food.

back in my undergarduate days when scids (Society for Continuous Inebriation During Share) was still self-serve bar .... i was taught to never let scids close w/o having a 5th or two under your coat.

so there was one of these asilomar acm sigcops meetings where one dinner they served wine (my hazy memory was that it was the first pressing by some stanford computer people called ridge). Anyway dinner was big round tables sitting 12 per table and the waiters were instructed to serve three bottles per table. The algorithm turned out to be they would open a bottle and when that bottle was empty they would open another. They would stop when there was three bottles on the table. Given my SCIDS background .... I was the only one putting empty bottles under the table (our table finished with 12 empties instead of three).

Another acm sigops tale ... i remember it as the year that the guys presented on all the reasons that the 432 couldn't be successful ... I used my SCIDS training to get a full case of beer under my coat before the bar closed.

past scids refs:
https://www.garlic.com/~lynn/2000d.html#5 Definition of SHARE & SCIDS Requested
https://www.garlic.com/~lynn/2000d.html#6 Definition of SHARE & SCIDS Requested
https://www.garlic.com/~lynn/2001k.html#20 OT: almost lost LBJ tapes; Dictabelt
https://www.garlic.com/~lynn/2001l.html#12 mainframe question
https://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#60 IBM-Main Table at Share
https://www.garlic.com/~lynn/2002o.html#31 Over-the-shoulder effect

part of a.f.c. thread
https://www.garlic.com/~lynn/2002p.html#24 I'll see your deep-fried mars-bar
https://www.garlic.com/~lynn/2002p.html#25 I'll see your deep-fried mars-bar
https://www.garlic.com/~lynn/2002p.html#35 I'll see your deep-fried mars-bar

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

Possible to have 5,000 sockets open concurrently?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Possible to have 5,000 sockets open concurrently?
Newsgroups: comp.protocols.tcp-ip
Date: Sat, 21 Dec 2002 04:25:58 GMT

"frickrb" writes:
Forgive me if I'm way off base here as I don't have much experience in this field. Maybe you can think of a scenerio that would allow a maximum number of clients to access services behind a firewall where each of the clients was using a different filter to validate a trusted relationship between client and server. I.e. each client is unique and a filter has been set up for each client that will allow only that particular client to traverse the firewall. Also, I'm assuming that 2 different filters can't be used on the same port so please let me know if that is a wrong assumption.

in the early days of netscape ... they started with ftp server for downloading all software ... and began replicated them as the load increases. They got up to something like 12-15 such servers ftp1, ftp2, ftp3, ... ftp12, ftp13, etc. this was before firewall/routers that rotated incoming, load-balancing requests across the backend servers (one of the first that this was done with was google).

at some point netscape installed a large sequent configuration as ftp20 ... and shifted all load to that one machine. at the time, sequent was claiming regular configurations with 20,000 connections.

this was in the days when many implementations still had linear finwait list implementations ... and some larger web configurations were experiencing 95% cpu utilization tied up in just running finwait lists. This wasn't a directly an issue with the number of connections ... this was an issue with the number of dropped connections within the finwait window (the number of dropped connections on the finwait list).

the standard scale-up scenario went with rotating multipe-A record dns ... giving multiple ip addresses for firewall/router interfaces ... and the firewall/router interfaces doing load balancing rotation across all of the backroom servers.

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

Big Brother -- Re: National IDs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big Brother -- Re: National IDs
Newsgroups: alt.folklore.computers
Date: Sat, 21 Dec 2002 17:17:21 GMT

hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins) writes:
It may have had that value for a limited number of applications, but at that price, people certainly wouldn't be able to afford commuting by car.

Also, after adjusting for inflation, gas prices are about the same now as then. Add on increased real wages, and they may be significantly lower.

my assertions is that it has that value ... independent of the application; however some people may squander it for random recreational uses (because the price and the value are so different) ... aka some people only place high value on things that cost a lot.

so one claim would be that significant portion of current lifestyles are based on the big difference between the value and the price ... and if the price was changed to reflect the value ... there would be significant adjustments that would need to be made.

also during the period ... one could claim that oil &/or oil-based technologies significantly change the ratio of food production workers (farmers, packaging, transportion, etc). I think there was some statement that between 1900 and 1950 the percentage of people involved in food production dropped significantly from half(?) to one out of 50.

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

computers and alcohol

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: computers and alcohol
Newsgroups: alt.folklore.computers
Date: Sun, 22 Dec 2002 00:18:37 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Never mix alcohol, work and youth. In fact keep beery establishments as far away from places of work as possible (maybe this explains a few things about organisations which may not be named, which have bars on the premises) Maybe "drunk whilst in charge of a computer" should also be an offence, but I suppose I'm older and wiser now anyway!

first floor of 545 tech sq had both brkfst/lunch operation and lounge/bar. science center data center was on the 2nd floor; other things were on 3rd & 4th floor ... and multics was on upper floors.

thread drift is reckless operation of unsafe computer
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2002p.html#27 Secure you PC or get kicked off the net?

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

Possible to have 5,000 sockets open concurrently?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Possible to have 5,000 sockets open concurrently?
Newsgroups: comp.protocols.tcp-ip
Date: Sun, 22 Dec 2002 21:10:32 GMT

Anne & Lynn Wheeler writes:
in the early days of netscape ... they started with ftp server for downloading all software ... and began replicated them as the load increases. They got up to something like 12-15 such servers ftp1, ftp2, ftp3, ... ftp12, ftp13, etc. this was before firewall/routers that rotated incoming, load-balancing requests across the backend servers (one of the first that this was done with was google).

sorry, brain check, /google/yahoo/ ... yahoo was the first big load balancing project that i knew of.

and for a little trivia ... 20th anv of internet ref at:
https://www.garlic.com/~lynn/rfcietff.htm

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

cost of crossing kernel/user boundary

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: cost of crossing kernel/user boundary
Newsgroups: comp.arch,comp.programming.threads
Date: Mon, 23 Dec 2002 14:58:45 GMT

"Andy Glew" writes:
Lynn: will you ever write a book? Please?!?

that sounds too much like hard work.

at one time i had accumulated large number of draft research reports .... working with professional tech writer and it was very painful process. making it even more painful we would periodically submit them to company approval process (approving that they could be subbmitted for publication) and get turned down. finally after a number of years the tech writer retired and sent me all of his files of stuff we had been working on. there was some conjecture that i wasn't getting approval for publication because of some impression that i had been associated with something called tandem memos. random refs:
https://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
https://www.garlic.com/~lynn/2001j.html#31 Title Inflation
https://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells

some years later .... an executive told me that they could forgive me for being wrong but they could never forgive me for being right.

and for something completely different (but similar):
https://www.amazon.com/exec/obidos/ASIN/0316881465/qid%3D1037135329/sr%3D11-1/ref%3Dsr_11_1/104-1355456-9727942
https://www.garlic.com/~lynn/subboyd.html#boyd

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
internet trivia 20th anv: https://www.garlic.com/~lynn/rfcietff.htm

Difference between AAA and Radius?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Difference between AAA and Radius?
Newsgroups: comp.security.misc
Date: Mon, 23 Dec 2002 16:14:06 GMT

des_riv@hotmail.com (Desmond Rivet) writes:
I have been attempting to get up to speed on these two technologies (Radius and AAA), but I haven't had much luck. I know what a Radius server does, more or less, but I'm less sure about an AAA server. And how exactly do the two operate together? What is the mechanism? I see AAA/Radius servers advertised all the time. What protocol is actually being sent over the wires?

I know you're all busy, but any clarification on the matter would be much appreciated :) Thanks.

RFCs are radius standard. start with
https://www.garlic.com/~lynn/rfcietff.htm

and under RFCs listed by select Term (term->RFC#)

then select RADIUS in the Acronym fastpath

i.e:
remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058

then scroll back towards the top of the same term frame to:
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3127 2989 2977 2906 2905 2904 2903

Clicking on the various RFC numbers will bring up a summary of each RFC. Clicking on the "txt=" field in the RFC summary will fetch the actual RFC.

RADIUS started out as a product of livingston for their modem terminal concentrator .... would handle users dialing into the system. it was introduced as IETF standard and was picked up by large number of other vendors and is used now for all types of network oriented userid/password operations (and not just dial-in modems). It also supports other authentication protocols like challenge/response in addition to password. In addition to routers and terminal concentrators it is possible to do things like hook webserver authentication stubs for RADIUS protocol ... and use the same infrastructure for network connectivity authentication as well as webserver (and other types of) authentication. The choice of the authentication function can be done on a account by account basis ... and there are additional features that can provide authorization information in addition to authentication.

Within IETF ... AAA is basically involved with more generalization of such infrastures ... as the referenced RFCs will explain.

also see work at
https://www.garlic.com/~lynn/x959.html#aads
https://www.garlic.com/~lynn/subpubkey.html#radius

Another IETF AAA technology is kerberos (as above, scroll to kerberos in the TERM frame:
kerberos
see also authentication , security
3244 3129 2942 2712 2623 1964 1510 1411

which is found in a number of products but is somewhat more oriented towards internal/campus distributed type operation as opposed to external internet connection operation.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
internet trivia 20th anv: https://www.garlic.com/~lynn/rfcietff.htm

Difference between AAA and Radius?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Difference between AAA and Radius?
Newsgroups: comp.security.misc,alt.folklore.computers
Date: Mon, 23 Dec 2002 16:28:46 GMT

ref:
https://www.garlic.com/~lynn/2002q.html#17 Difference between AAA and Radius?

raise your hand if you've configured radius on real livingston box.

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

Beyond 8+3

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Beyond 8+3 ...
Newsgroups: alt.folklore.computers
Date: Mon, 23 Dec 2002 19:34:49 GMT

Pete Fenelon writes:
Standard Pascal is unusable for anything other than trivial pegagogical exercises, or writing Standard Pascal compilers.

For 99.999% of systems programming tasks, I'd take a good macro-assembler over a (standard) Pascal compiler any time. Standard Pascal's a toy language, with no real modularity, lousy I/O, objectionable syntax, no well-defined interface to the OS, no hope, no escape.

The more a programming task resembles a CS101 exercise, the more suitable it starts to look for implementing in (standard) Pascal. And even then, back in my day we only did CS assessments in Pascal because it was mandated - most of us were teaching ourselves useful languages on the side.

This does not apply to people who've extended Pascal and made it useful - DEC, for example, or even Borland. Hell, even Wirth with the Modula/Oberon families.

I once had the opportunity to port a 60,000 statement vs/pascal (on aix) application to another platform. It was a daunting task ... made more so by the vendor having outsourced their pascal support to someplace that was close to the opposite side of the planet.

vs/pascal had started out as pascal/iup on cms by pickens & weber at the los gatos VLSI lab ... having made heavy use of metaware's tws (which was written in pascal). it had all sorts of extensions by the time it was also available on the 6000.

I got the strong opinion that no other vendor had a pascal that had ever before been used with something like a 60,000 statement production program.

random metaware:
https://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History

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

Cost of CPU second

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cost of CPU second
Newsgroups: bit.listserv.ibm-main
Date: Mon, 23 Dec 2002 22:08:24 GMT

Bob.Richards@SUNTRUST.COM (Richards.Bob) writes:
I hate asking this, but does anyone have a metric or ROT for the cost of a CPU second for a z900 or for service units on same?

issue is whether they are attempting to recover fully loaded capital, expense, head-count, licenses, hardware software, power, space, profit, etc ... just based on CPU-sec pricing. basically take the fully loaded annual/monthly costs possibly plus factor for profit .... and divide it by the expected billable cpu-seconds for the revenue period.

the price paid for the processor might represent less than ten percent of an operation's fully loaded costs and the number of expected billable cpu-seconds could be less than a 1/4th the total number of seconds available in the revenue period.

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

Beyond 8+3

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Beyond 8+3 ...
Newsgroups: alt.folklore.computers
Date: Tue, 24 Dec 2002 00:30:41 GMT

ararghNOSPAM writes:
Way back, when I was designing an OS, I (re?)invented the idea of storing very short files (up to 63 bytes) actually in the inode, in the area where file block numbers are usually stored. However, I n never got much beyond the boot loader stage.

in cms it was called the MFD & hyperblocks. i did similar things in cms filesystem in the early to mid 70s when i did the mapping for cms filesystem to page mapped layer.

random refs:
https://www.garlic.com/~lynn/submain.html#mmap

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

20th anniversary of the internet (fwd)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 20th anniversary of the internet (fwd)
Newsgroups: alt.folklore.computers
Date: Tue, 24 Dec 2002 03:47:57 GMT

TCP/IP Digests from google

First TCP/IP Digest after the cut-over because of "mail difficulties"

Vol2#1 26 Feb 1983
http://groups.google.com/groups?selm=bnews.brl-bmd.517&oe=UTF-8&output=gplain

previous TCP/IP Digest

Vol1#28 17 Dec 1982
http://groups.google.com/groups?selm=bnews.brl-bmd.493&oe=UTF-8&output=gplain

vol1#27 5 Dec 1982
http://groups.google.com/groups?selm=bnews.brl-bmd.479&oe=UTF-8&output=gplain

other things on google around that time:

List of Currently Active (USENET) Newsgroups (20 Jan 1983)
http://groups.google.com/groups?selm=bnews.alice.1412&oe=UTF-8&output=gplain

The USENET Corporation (30 Dec 1982)
http://groups.google.com/groups?selm=bnews.crystal.149&oe=UTF-8&output=gplain

LIST-OF-LISTS (10 Feb 1983)
http://groups.google.com/groups?selm=bnews.unc.4615&oe=UTF-8&output=gplain

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Free Desktop Cyber emulation on PC before Christmas

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Free Desktop Cyber emulation on PC before Christmas
Newsgroups: comp.sys.cdc,alt.folklore.computers
Date: Tue, 24 Dec 2002 04:53:38 GMT

jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
For archival purposes, this is certainly true; OTOH, if you're talking about a tape (or DASD, in Hercules) image you're using on a regular basis, compression has two benefits:

i was picking around in vmshare looking for something else and found in:
http://vm.marist.edu/~vmshare/browse.cgi?fn=HISTORY&ft=MEMO
Append on 09/13/94 at 13:12 by David Boyes ( dboyes@vma.cc.nd.edu, 219 631 9448

Update on the 360/67:

Since I'm no longer in Houston, I'm not able to work much on it. I bumped into one of the support people from NASA JSC (in the grocery store, of all places) and she mentioned that NASA still had copies of the OS/360 distribution in permanent storage as part of the moon shot material. So, a few phone calls later, I was down at JSC (wearing my "I Like HASP" button) with an armload of blank tapes and a pocket full of dimes copying install instructions and tapes. The JSC folks were kind enough to let me copy the distribution tapes (after all, it's for educational purposes, right?), and we did the install a few nights before Share in Boston. The machine runs the final release of OS/360 with the JSC HASP mods.

According to Dick Newsom and Larry Chace (at SCIDS), this is the first new OS/360 install in 30+ years. I wonder what would happen if I tried to call the support center? ...8-). (I did resist the urge to run up and down the hall yelling "It's Alive!", though... Gene Wilder would have been disappointed in me.)

Sigh. It was a neat project.

APPENDED 09/13/94 13:12:16 BY UDM/DBOYES

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Vector display systems

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vector display systems
Newsgroups: alt.folklore.computers
Date: Tue, 24 Dec 2002 05:06:12 GMT

also picking around in
http://vm.marist.edu/~vmshare/browse.cgi?fn=HISTORY&ft=MEMO
Append on 05/16/94 at 12:36 by Gabe Goldberg, Computers and Publishing, Inc.:

Ah, the University of Grenoble. One of my first VM/370 tasks was converting their support for the IBM 2250 display from CP/67 CMS to VM/370 CMS. The documentation and code comments were in French; my high school French (somewhat studied in a French chemistry textbook) was of limited help. But we got it working, and Mitre flew many miles of air traffic control simulations using it. And several other sites eventually used the VM/370 support.

I never connected with anyone there to properly thank them; they clearly did great things with VM.

APPENDED 05/16/94 12:36:24 BY +GG/GABE

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Beyond 8+3

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Beyond 8+3 ...
Newsgroups: alt.folklore.computers
Date: Tue, 24 Dec 2002 14:37:02 GMT

jmfbahciv writes:
If the contents of file is stored in the disk accounting areas (where accounting implies the specs of the OS filesystem and physical disk device layouts), weren't there problems with tranferring files from one computer system to another? Even with homogeneous soft/hardware platforms, not all blocking factors were alike. I vaguely recall TW worrying about this when he also considered storing the file contents that way (to "save" disk space). I think he finally punted the idea.

the backup/transfer supported this. the original CMS filesystem from mid-60s was designed with 800byte (logical) fixed block for everything (even tho mapped to 2311 ckd device). the transfer/backup format could handle different sized files into & out of the filesystem (except for disk image backup, which wasn't a file based operation but a physical block operation of all disk blocks).

in the mid-70s, support was added in cms for EDF (aka extended) filesystem (which co-existed with the "regular" filesystem). EDF had support for 1k, 2k, & 4k logical fixed blocks ... and file level operations worked between EDF filesystems in different sized format.

I remapped but the regular CMS filesystem (with its nominal 800byte logical fixed block records) to page mapped format (handling the necessary stuff to figure out 4k logical block size instead of 800byte) as well as 4k-EDF (which was much easier task since the block sizes were the same).

One of the big differences touted for EDF against regular CMS file system from the mid-60s was the way it updated the master disk record. In the old CMS file system this was always physical record 4 on the disk. In EDF, this alternated between record 4 & 5. The issue was that the CKD disks of the period had a peculiar failure mode that if power failed exactly as a record was being written ... it was possible that the record was corrupted and you would loose the filesystem. The regular CMS filesystem used effectively shadow changes and then careful replace of record 4. Nominally a fatal interruption could occur at any moment and on recovery you would always see a consistent view ... either before the update or after the update. The exception was if a power outage happened to occur just as record 4 was being rewritten to switch from the before image to the after image. EDF fixed this failure mode by alternating rewriting record 4 and record 5 (and effectively keeping version number in the record).

I also did the first couple version of an internal backup/archive system (deployed at a number of internal data centers). Which then evolved into WDSF (workstation datasave facility) product ... and then into ADSM (adstar storage manager) ... and finally has been renamed TSM (tivoli storage manager).

misc. backup/etc
https://www.garlic.com/~lynn/submain.html#backup

LISTSERV Discussion List For USS Questions?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: LISTSERV Discussion List For USS Questions?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 24 Dec 2002 15:51:50 GMT

IBM-MAIN@ISHAM-RESEARCH.COM (Phil Payne) writes:
Just like VS/PC ..

which was originally going to be called PCO ... until somebody did some checking around various countries in europe.

the vs/pc group tied the cms development in knots for possible six months or more. they had a couple people that had implemented a performance model of "vs/pc" and would run it for various kinds of workloads .... claiming that the performance of vs/pc was going to be ten times the (then) vm370/cms performance.

the vm370/cms group were then required to duplicate these modeled workloads with real live benchmarks. the models and the benchmarks performance tended to turn out to be similar. when vs/pc finally shipped it was something like 1/10th the performance of the model (and 1/10th the performance of vm370/cms comparable workload .... a long ways from the claims that it would be ten times the performance of vm370/cms; aka claims off by two orders of magnitude).

vs/pc was low/mid range product ... and when the low/mid range did the microcode assists ... as well as the vm handshaking for the guest operating systems ... that pretty much put any further justification for vs/pc to rest. the initial marketing/product strategry for the m'code assists and handshaking ... was that the low/mid range would always ship with vm (&cms) as part of the box ... in much the same that LPAR currently ships.

misc. past posts:
https://www.garlic.com/~lynn/2000.html#1 Computer of the century
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
https://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Beyond 8+3

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Beyond 8+3 ...
Newsgroups: alt.folklore.computers
Date: Tue, 24 Dec 2002 20:21:31 GMT

Dave Daniels writes:
One manufacturer of PBXs wrote all of the PBX software in Pascal. This was a large PBX with all the mid-1990s bells and whistles in the software too. I never saw the code, but I should imagine that there were a few tens of thousands of lines of it.

Changing the subject slightly, wasn't the original version of the IBM TCP/IP stack for VM written in Pascal?

same vs/pascal.

i did rfc1044 for the original product. standard offering used a 8232 (basically a pc/at with an ibm channel interface card) and got about 44kbytes/sec consuming nearly a full 3090 engine. i was able to hit ibm channel thruput (1mbyte/sec) testing between a 4341 clone and a cray at cray research with rfc1044 support.

it used some cp api "diagnose" instructions. for the port to MVS ... basically it was the same code with a stub layer that emulated the necessary CP API on MVS.

there was a later version for MVS that implemented tcp/ip support inside of VTAM. The initially cut had tcp thruput significantly faster thru VTAM than LU6.2 thruput thru VTAM. That was fixed prior to release as product (and is one of those out-of-school stories).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Origin of XAUTOLOG (x-post)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Origin of XAUTOLOG (x-post)
Newsgroups: alt.folklore.computers
Date: Wed, 25 Dec 2002 15:20:10 GMT

lots of automated benchmarks were done over period of year or two leading up to the three month period (mentioned in x-post) involving 2000 benchmarks for validating and calibrating the resource manager prior to release.

and of course my favorite "performance envelope" person (although he applied to things like training fighter pilots and the design of the f15, f16, f18, etc):
https://www.garlic.com/~lynn/subboyd.html#boyd

from vmeesa-l

I don't know about XAUTOLOG ... but I did AUTOLOG internally on a VM370 Release 2 system for the automated bench marking process ... and then CSC adapted it for production operation. It then was made available in release 3 (along with subset of virtual memory management for discontinuous shared segments and misc. other stuff).

The automated bench marking used synthetic workload ... and for the resource manager .... defined a suite of approx. 2000 benchmarks that took something like 3 months elapsed time to run. These were run on CSC's 370/155 ... mostly on weekends and 2nd/3rd shift. The first several hundred automated benchmarks were pretty static, predefined .... selecting workload, configuration, and system parameters (including system rebuild) and would automatically reboot between each benchmark, run the benchmark, collect the data, select the next benchmark perform the necessary operations and then reboot again. After we established the overall operational data points across what we believe to be a fairly complete operational envelope (varying workload, configuration, and system parameters) when the selection of further benchmarks was automated with an APL program.

People at CSC were also responsible for the performance predictor that was available to the field on HONE (CSC had pioneered a lot of the work turning performance modeling and tuning into capacity planning). A variation of this APL program was used to look at all the previous benchmarks datapoints (in approximately six space envelope, aka benchmark characterized by six major axis) and select the next benchmark point in the operational space.

>From the original data collection and modeling work ... the initial several hundred benchmarks were defined to be along the surface of the observed operational envelopes along with distributed sample of points within the six-space sphere of observed real operational data. After the initial operational characteristics were established by the initial several hundred benchmarks ... the APL program was modified to start searching the operational space for places where the resource manager might behave in anomalous manner.

There were also several benchmarks defined that lay well outside any observed real operational environment ... primarily extremely heavily loaded characteristics. When the whole process was initially started ... there were numerous benchmarks that would reliably crash the system because of various timing related failures. Eventually, I rewrote the whole internal serialization functions in order to eliminate all such instances of system failure. This was included as part of the resource manager (not only did it eliminate all observed system failures ... but also all instances of hung/zombie users).

past autolog posting
https://www.garlic.com/~lynn/2001l.html#32 mainframe question

misc. recent thread on virtual memory management functions that went into release 3:
https://www.garlic.com/~lynn/2002o.html#25 Early computer games
https://www.garlic.com/~lynn/2002q.html#1 Linux paging
https://www.garlic.com/~lynn/2002q.html#2 Linux paging

misc postings on benchmarking, workload profile, and capacity planning
https://www.garlic.com/~lynn/submain.html#bench

misc. HONE or APL related postings:
https://www.garlic.com/~lynn/subtopic.html#hone

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Collating on the S/360-2540 card reader?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Collating on the S/360-2540 card reader?
Newsgroups: alt.folklore.computers
Date: Thu, 26 Dec 2002 16:20:32 GMT

hancock4@bbs.cpcn.com (Jeff Nor Lisa) writes:
We added the "Power" spooling system to our S/360-40 DOS. It was pretty easy to install and the productivity gain was enormous. Basically, our computer was limited by the "slow" speeds of the printer and card reader, you could watch the panel and see the CPU WAIT light on most of the time. The printer and reader seemed to a human to be operating very fast at 1,000 units per minute, but it was actually slow.

our university went thru a transation. it had 709 (tubes) & 1401. The 1401 was used primarily for unit-record<->tape front-end for the 709. student fortran jobs go card->tape .... the tape moved over to the 709 and executed there, producing output on tape, that tape moved back to 1401, and the output printed.

360/30 was initially brought in and ran in 1401 emulation mode doing the same thing. I got my first programming job .... redoing the 1401 ur<->tape program in 360. All in assembler, I got to design & write my own monitor, interrupt handlers, device drivers, console interface, etc (I had to handle a lot of column binary).

The 30/709 was replaced with 360/67 (running mostly in 360/65 with OS/360). The student fortran workload was disaster ... the 360/65 was spending most of its time handling (effectively synchronous) unit record. Thruput went from a couple a second on the 709 to maybe one per minute on the 360/65.

Helping save the day was first HASP (houston spooling) that changed unit record from synchronous to asynchronous ... which got the thruput up to about two per minute. I then did a bunch of os/360 optimizations and got it up to maybe six per minute. The thing that saved the day was watfor. With HASP, the thruput limit of vanilla fortran g compile, link-edit, and go changed from unit-record to effectively spending all its time in the job scheduler and program loading. With watfor, workload basically executed the job scheduler and watfor program load once ... and then it would process 30-60 student programs in one batch (basically having its own submonitor). This finally got student workload thruput back up to level of the 709.

Also, during this period ... the people from CSC came out and installed CP/67 the end of january '68 (we were the first "outside" installation after csc itself and lincoln labs). There was still a lot of work needed on CP/67 and the university let me play with it on weekends .... while still be responsible for production OS/360 during the week.

One of the things I did on HASP .... was inside HASP implement 2741 & TTY terminal support and the CMS editor command syntax ... for method of terminal job input.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

System Hang

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System Hang
Newsgroups: comp.unix.internals,comp.arch
Date: Thu, 26 Dec 2002 16:31:19 GMT

Maneesh Singhal writes:
Just got the following doubt ----

. How can we define that system is hung ??

. If at all system is hung , how can it be detected (through software / and through hardware support) ?

standard for HA configurations for a long time has been heartbeats.

note that HAs have had additional constraints regarding exactly what is actually is preventing the heartbeat and in take-over situations how to shoot the offending processor .... or at least fence it off ... (in the event that it was some temporary suspension and all of a sudden it comes back to life). the failure scenarios have been assume that the processor is just suspended on something like a critical I/O write instruction ... and then wakes up (after take-over); and will the write succeed or not.

hardware support for fencing may be more important than for sensing.

random refs:
https://www.garlic.com/~lynn/subtopic.html#hacmp

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Collating on the S/360-2540 card reader?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Collating on the S/360-2540 card reader?
Newsgroups: alt.folklore.computers
Date: Thu, 26 Dec 2002 23:39:06 GMT

"Russ Holsclaw" writes:
> (I'll bet you didn't work on the clutch mechanism on the 2540 very > often, or you would have remembered that it wasn't a helical-spring > type.) In my recollection, the number of non-PM service calls on a > 2540 was in direct proportion to the number of paper-clips someone had > tried to feed through them.

i do remember that operators (&/or I) had to take the mechanism for both punch and reader sides apart once a shift and clean the brushes and then put it all back together. It got to be a habit with me that the first thing I'd do when they would turn the machine over to me was clean all the tape drives and clean the reader/punch brushes.
> Actually, the software that made the reader-clutch chatter a lot on the 2540 > was OS/360, when it was interpretting JCL. It read SYSIN datastreams at a > smooth 1000 cps, but the intervening JCL would slow things right down. The > main exception was in systems running HASP for spooling. That was because > HASP put the cards (JCL and all) into its own spool files, and then > interpreted JCL when it read the jobs back off the disk. The interpretation > of them was just as slow, but users were less aware of how slow it was > because the disk-drive didn't have a chattering clutch. The speed-up caused > by HASP was largely an illusion. One of our customers (the USDA) actually > proved this in a benchmark, and refused to install HASP, despite the > recommendations of the SE's from the Marketing branch. Most software-support > CE's knew this about HASP, too, but got shouted down by the marketing folks. > It was a case of showmanship vs. actual throughput.

speed-up from hasp was both on the input side reading the cards ... but also on the output side printing .... allowing both card input and print output to not be synchronous with job execution. at least for the university workload on a vanilla system ... this doubled the thuput. I then got another three times thruput increase by heavy optimization of data layout on disk (six times total increase in input with combination of disk arm optimization and hasp ... which wouldn't have been possible w/o either). When we got WATFOR ... for student JOBs ... a combination of WATFOR and HASP almost made the student workload disappear. WATFOR processed (on the 360/65) at something like 20,000 "cards" per minute ... aka student job card input & print output could be overlapped essentially for free with standard workload (using HASP) and the actually (WATFOR) program processing/execution became essentially inconsequential.

The issue was that a lot of workloads tended to intermix periods of unit record intensive operation followed by little or no unit record utilization. W/o hasp the unit record intensive periods would serialize the actual workload processing. W/HASP it allowed unit record intensive periods to be overlapped with periods that were less unit record intensive. For instance, intensive print output periods didn't have to slow down the processing of other work (the job could finish and the printing could proceed asynchronously with other workload activity).
> Us software-support CE's hated HASP because it was a really ugly hack. It > installed itself in a manner that would have been described as a "virus" > except that computer viruses hadn't been invented yet.

it started out by stealing the svc new psw (unprotected supervisor storage) and creating a intercept for various types of operating system I/O operations. Later when os/360 added storage protection ... hasp needed a special type1 svc (i.e. hasp svc routine given system privilege) which would hook the interrupt handler (somewhat analogous to bios int13 intercept).
> In MVS, the viral aspects of HASP had been exorcised, and it was renamed > "JES2".

Simpson, crabtree & hasp were main stay of share user group meetings ... and the thursday night hasp songfest at scids (and the hasp song book). I have a copy of "SHARE" songbook .... but with an image of a lock "hasp".

group was created in gburg ... and they consolidated both HASP and ASP there .... HASP being renamed JES2 and ASP being renamed JES3. I'm not sure Simpson was ever part of the group ... he went to Harrison and the white plains data center and worked on RASP ... and then left and became a Amdahl fellow in Dallas. Crabtree ("crabby") was one of the people that went to gburg (my wife worked for them for awhile ... when she had part of the responsibility for being the "JES3" catcher for ASP being thrown over the wall). Unger was another in the gburg group ... I ran into him a couple months ago when I gave a talk at YKT research on the hardware token I've been doing some work on.

The majority of JES2 stayed as is .... down to JES2 messages still using the HASP message prefix. Also the original JES2 NJE/NJI networking support still was all HASP design&implementation .... down to there possibly still being "TUCC" in cols 68-71 (aka some amount of the original network code was the HASP changes made by triangle university computing center). The whole HASP design was based on psuedo/virtual (unit record) devices ... and HASP had a table of 255 possible entries (one byte index implementation). The TUCC implementation defined network nodes in the unused psuedo unit record device table.

This carried over into the official JES2 NJE/NJI networking support ... and was one of the reasons that MVS/JES2 had such a peripherial role in the IBM internal network. A standard MVS/JES2 environment tended to have something like 60-80 psuedo devices defined leaving less than 200 entries for network node definitions. The internal network quickly exceeded 256 nodes .... making it so that no MVS/JES2 system was able to have a definition of the whole network. Furthermore, JES2 would trash any network traffic that it didn't have both the origin and destination nodes defined (if JES2 was an intermediate node and had the destination node defined and could deliver the traffic ... but didn't have the original origin node in its table ... it would still trash the traffic).

The other big mistake that JES2 networking support made was that it really confused the JES2 header ... intermixing networking layer related stuff, transport layer related stuff, and application layer related stuff. It was entirely possible to upgrade one JES2 in a network which had slightly different header definition and the traffic between JES2 nodes at different release levels would result in crashing the MVS system.

For the internal network ... that met that everything but peripherial nodes had to be VM-based. Not only were VM-based nodes were the only ones to handle the complete network definition ... but VM-based networking implementation had correctly separated network, transport, and application issues. In fact, what tended to happen was a whole family of VM-based NJE drivers evolved. A NJE line driver would be started that corresponded to the release level of the JES2 on the other end of the line. It was the responsibility of the VM-based NJE line driver to provide canonical header field translation to prevent JES2 systems at different release levels from crashing each others MVS operating systems (while in theory ... it was possible for a JES2 system to network directly to another JES2 system .... the shortcomings in the networking implementation frequently required that there be an intermediate VM node just to keep them from crashing each other systems).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Collating on the S/360-2540 card reader?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Collating on the S/360-2540 card reader?
Newsgroups: alt.folklore.computers
Date: Fri, 27 Dec 2002 01:16:53 GMT

"Russ Holsclaw" writes:
Well, I was addressing the period (during and after OS Release 15/16) when MFT II was available, as well as MVT, and spooling was built in to the core operating system. HASP could outperform "naked OZ" at spooling when the default DCB parameters were used, and both input and Sysout spool datasets were unblocked. This could be cured by simple JCL changes in the stored procedures. HASP itself owed much of its relative speed to the use of interleaved record formatting of its spooling tracks. But even more speedup could be accomplished by simple use of FB blocking on both input and output. To be sure, the interleaved output technique was a significant contribution. I don't know how often it might have been used before. (Well, I guess you could call the optimizing assembler for the 650 to be an example of DASD interleaving, eh?)

HASP made a lot more sense when the system lacking spooling facilities of its own. As I understand it, the program was created at the request of NASA to fill the gap until OS could do proper spooling. When that was added, it could have either killed HASP, or HASP could have been properly integrated into the OS without all the unnatural acts. Instead, it took on a separate life of its own, partly because of the cult-like culture being built around it by Mssrs S&C, and partly because of the NIH attitude shown by people in P'keepsie.

I first installed HASP with os/370 release 11, mft ... didn't have it at time of 9.5 (and i wasn't responsible for the university's system at that moment).

One might claim that operating system native spooling was too little too late. I installed HASP on MFT 11 (as in os/370 release 11, not MFT-2), MFT 14, MVT 15/16 and then MVT 18. First to market can have lasting effect ... even when less than optimal. The other was that HASP was real source distribution (i.e. many installations actually assembled all the source as part of standard HASP build). This contributed to to lots of customer enhancements (like the TUCC networking support).

I don't know of customer that ever did a from scratch os/360 system build by assembling all the source. I've even heard of one rumor about some agency's request to get ALL the exact source for a specific system ... so they could. After supposedly spending $5m on researching the issue ... the answer came back as not possible (presumably so difficult to not be pactical).

Also, the NIH isn't unusual. something similar happened in database. STL totally rejected relational somewhat resulting in an almost religious schism. system/r did technology transfer from bldg. 28 to endicott for sql/ds ... and it wasn't until sql/ds (and other relational products) were making headway in the industry that there was a technology transfer of sql/ds back to stl (sjr/28 and stl/90 are maybe ten miles distant) for DB2.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Star Trek: TNG reference

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Star Trek: TNG reference
Newsgroups: alt.folklore.computers
Date: Fri, 27 Dec 2002 01:41:55 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Given the "concepts of management" that they seem to teach today's managers, it sounds like a positive advantage to remain uncontaminated by such concepts. Rather Captain Kirk than Captain David Brent (the latter of whom is quite tame when it comes to genuinely bad managers)

and of course my favorite is boyd's somewhat parody title

The Organic Design for Command and Control

some slightly tongue in cheek about concepts of management. part of the thesis was that major management techniques from at least the 80s onward were the army officers from WW-11 coming of age as corporate executives. the thesis was that the management training that was instilled in these people at an early age as part of WW-11 ... is that the vast majority of the people are untrained and the major issue is establishing an extremely rigid, top-down, management/control infrastructure (to leverage the skills of the extremely few skilled individuals available ... but that basic permise may have gotten lost in the fog of the years ... and only the methodology/paradigm survived). one claim was that this was the result of vast increasem from extremely small standing army (and little civilian skill base).

one of boyd's counter-examples was Guderian's verbal orders only for the blitzkrieg (aka the person on the spot was suppose to make the decision and not worry that some post-battle auditor would go around assigning blame for things that aren't perfect). In any situation that has the possibility of the unexpected (i.e. it isn't exactly the same thing you've done day-in, day-out, for the past 30 years) ... things aren't going to be perfect (aka the only people that never make mistakes are the people that never do anything). The issue was that person on the spot was the best to make the decisions (Guderian had large cadre of trained people) and they shouldn't be worried about being punished if things weren't perfect.

misc. Guderian refs:
https://www.garlic.com/~lynn/99.html#120 atomic History
https://www.garlic.com/~lynn/2001.html#29 Review of Steve McConnell's AFTER THE GOLD RUSH
https://www.garlic.com/~lynn/2001m.html#16 mainframe question
https://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002d.html#38 Mainframers: Take back the light (spotlight, that is)

and of course the standard boyd refs:
https://www.garlic.com/~lynn/subboyd.html#boyd

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Star Trek: TNG reference

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Star Trek: TNG reference
Newsgroups: alt.folklore.computers
Date: Fri, 27 Dec 2002 02:21:22 GMT

Anne & Lynn Wheeler writes:
and of course my favorite is boyd's somewhat parody title

The Organic Design for Command and Control

and the punch line on the very last foil was something about doesn't it seem that instead of command and control that it would be more appropriate

leadership and appreciation

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

HASP:

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP:
Newsgroups: alt.folklore.computers
Date: Fri, 27 Dec 2002 06:05:16 GMT

nospam@nowhere.com (Steve Myers) writes:
Another point. The development of NJE.

ASP - The systems had to be JES3 and at exactly the same level. The second generation NJE hacked the JES2 code into JES3. And JES3 still needs an expensive helper product (BDT) to play NJE and RJE in a big boy (e.g., VTAM) network.

TUCC NJE - There was an attempt to eliminate the ASP problem, but I understand it was not entirely successful

VM RSCS - I remember looking at some of that code, and it looked to me like it had been hacked from JES2 RJE. For a long time, HASP supported stuff - like multiple readers and printers on one connection - that RSCS was very late to support,

JES2 NJE - I cannot argue that there are some problems with the job headers. As for comments about some of the information, I want remind folks that JES2 NJE was originally for bisync only networks, and JES2 was trying to stick stuff in to play like the future big boys. In a big boy only network, JES2 is now wrong, but the situation was awfully fluid in the late 70s and early 80s.

JES2 and RSCS incompatibilities - I suspect the real problem was an unwillingness to sit down and hash out, and follow, standards in the early days of NJE. The Wheelers are VM bigots, too, and they are reluctant to admit VM can be wrong. Of course, I'm an OS/360 / MVS / z/OS person, and I'm reluctant to admit we're wrong!

RJE and NJE counts - JES2 was too hung up on numbers in its routing tables. A one byte number is 255, and for a long time, JES2 used a two byte routing code, one byte for a numeric node ID, and one byte for an RJE ID. It's fixed now, but this is one area where JES2 screwed up. And, don't forget I'm a JES2 person.

actually i did lots of work on HASP and OS/360.

My wife never worked on VM ... she was in the JES group and then jimmy con'ed her into going to pok to be responsible for loosely-coupled architecture. at that time ... ricky baum had tightly-coupled architecture and ricky and my wife reported to the same manager. While in charge of loosely-coupled architecture she originated peer-coupled shared data ... which was the basis for IMS hotstandby and later sysplex (sysplex also drew on a project called system memory & lock memory that was going on in ykt research). You can't hardly get more mainstream POK & MVS than that.

VM networking had its whole own set of infrastructure and line driver protocol that had nothing at all to do with NJE ... VMB, VMT, VMX, etc and was much more efficient that NJE with a lot of other kinds of operational characteristics. There was also a FDX line driver that could drive a full-duplex telco link in full-duplex mode instead of traditional IBM half-duplex operation (it achieved concurrent media limit thruput in both directions .... instead of NJE traditional aggregate thruput that was some fraction of single direction bandwidth).

There was once an attempt at a load sharing project between STL and Hursley .... over a high bandwidth satellite link (since peek workload tended to be 1st shift correlated ... and 1st shifts at STL and Hursley were off-shift). They tried to bring up the link with JES2/NJE on both ends and it couldn't establish a connection (but had no descriptive diagnostics). Somebody suggested that they then try and bring up both ends using a native VM line drivers because it had much better diagnostic messages. The link was brought up with VM networking and VM native drivers .... with no errors. This somewhat dumbfounded the JES2 people. It turns out that VM native drivers could dynamically adapt to the double hop satellite delay between west coast US and england ... while the NJE drivers weren't able to.

The VM networking NJE drivers were indeed originally adopted kludge code from some version of HASP. It was obvious that JES2/NJE was totally incapable of speaking any other protocol than JES2/NJE ... even to the situation that different versions of JES2/NJE couldn't even communicate with each other ... and could even result in the crashing of the other's MVS system. The only way to provide reasonable wide-area networking for JES2/NJE ... was to kludge a (non-native) NJE driver into VM .... even to the extent of evolving families of such kludged NJE drivers that would compensate for the fact that different JES2/NJE systems had difficult time interoperating.

The interesting thing was that the actual JES2/NJE got things wrong more wrong than (arpanet) NCP .... in terms of requiring a homogenous environment. The peculiar thing about VM network support is that it did (correctly) differentiate the link, routing, transport, and application layers from the start ... with the ability to effectively gateway (internet getting this in the NCP/IP cut-over on 1/1/83, see 20th anv reference). An example of being able to gateway was the actual ability to have a (non-VM native) NJE line driver and provide routing & gateway functions to (non-VM native) JES2/NJE hosts.

All of this was primarily internal networking related. However, I do know that the original JES2/NJE product announcement was also roadblocked and it appeared that it was never going to happen until it got the assistance from VM networking people .... along with kludged non-native VM NJE driver in VM. This resulted in the announcement of NJE as a joint JES2/VM product offering (aka the original NJE product announcement was not a JES2 announcement it was NJE as a joint JES2/VM product announcement). During this period the guy responsible for VM networking and getting around the JES2/NJE announcement roadblock ... also had extensive discussions with the NJE people about how wrong the homogeneous (totally messed up & confusing header fields) network requirement and the server node limit actually was. The constant refain from the JES2 group was that no real customer would ever have more than a couple nodes (the size of the corporate internal network was a total fluke and would never be repeated any place else).

To the extent that JES2 enhanced their JES2-based NJE drivers ... and such enhancements lagged in the (non-VM native) versions of NJE drivers is a corporate resource priority issue. While there was possible some resistance & NIH to JES2 along the way ... they didn't have to contend with the workers being constantly told that the current release of VM is the absolute last ... and if you ever want to get a promotion or raise in the IBM company you had to transfer to some "mainstream" product activity; aka the issue of the features and support level of the NJE line driver inside of VM was something that was primarily a JES2 issue ... not a native VM networking issue.

The corporate decision to stop shipping the VM networking offering with native line drivers .... and only ship with NJE driver(s) .... could be realisticly construed as eliminating any comparison about how poorly NJE compared to the "native" line drivers.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

HASP:

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP:
Newsgroups: alt.folklore.computers
Date: Fri, 27 Dec 2002 15:58:21 GMT

https://www.garlic.com/~lynn/2002q.html#35 HASP

and "why was nge announced as a joint JES2/VM product?" somebody asks.

HINT 1:

for some reason I/resource-manager was chosen to be the guinea pig (aka first) for SCP priced/charged-for products. I got to spend six months or so with business people establishing the rules/criteria for charging for SCP software.
2001e.html#45 VM/370 Resource Manager

HINT 2:

a possible price for a charged-for SCP software product had to (at least) meet the criteria that the price times all of people willing to buy the product at that price exceeded the total product development costs

HINT 3:

some number of SCP products got caught in the transition from free SCP products (or at least not charged for) to priced SCP products ... aka for some there was no possible price that met the criteria in HINT2.

HINT 4:

The part time for the person that did the NGE driver for VM networking and the part time for the person that did all the rest of VM networking were considered essentially negligible costs by JES2 NGE development cost standards.

HINT 5:

it wasn't the only time this sort of thing happened to VM.

answer in some future edition.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

HASP:

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP:
Newsgroups: alt.folklore.computers
Date: Fri, 27 Dec 2002 16:02:01 GMT

oh, and i forgot

HINT 6:

it involved a very large number of vm networking sales

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

ibm time machine in new york times?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ibm time machine in new york times?
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main,comp.protocols.time.ntp,rec.arts.sf.science,alt.sci.time-travel
Date: Sat, 28 Dec 2002 13:57:24 GMT

"Kevin Koehler" writes:
I don't know if those who wrote the previous post will read this. I saw something about IBM Plant site San Jose - I'm not trying to spoil anyones fun or jepardize any matter of national security. But I used to deliver mail on that plant site and had access to just about every room on the site to deliver mail. You know I don't think that plant site has a single building on that it with a basement. Nor does the research center. There was a freight elevator that had a cool bumper sticker I snagged one day after seeing it for nearly two years that said "You are Now Entering the Twilight Zone!"! Maybe someone here knows different and can prove me wrong.

it was a parody probably 20 some years ago .... sort of the reverse of the NYT thing .... that there were decisions being made that would only be logical if they knew they had a time machine and were able to go back and change things (as opposed to making wrong decisions ... then going back and changing the decisions). originally claimed for basement of bldg 12. can't remember if it was in the context of tandem memos or not.
https://www.garlic.com/~lynn/2002q.html#16 cost of crossing kernel/user boundary

during seismic refit of bldg 12 .... most of it was emptied ... except for the wireless stuff on the top ... and some stuff in the basement. employee credit union was also in the basement of bldg 12 ... until moved to bldg just south for a while (i think that bldg is now orchard supply hardware hdqtrs?) ... and then to current location on blossom.
https://www.garlic.com/~lynn/2002n.html#55 ibm time machine in new york times

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

HASP:

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP:
Newsgroups: alt.folklore.computers
Date: Sat, 28 Dec 2002 14:20:32 GMT

"Russ Holsclaw" writes:
Well, I dunno much about DEC software, but perhaps it made a PDP-10 act as a HASP Remote Job Entry workstation. Seems like a reasonable guess.

... aka 2780. lots of things simulated 2780.

when i put the 2741 & tty support into HASP along with cms editor syntax ... i deleted the 2780 support (at the university, which wasn't using it) since it picked up some addressability and kept hasp kernel size smaller (one of the advantages of complete source distribution & source build).

course it wasn't nearly as difficult as what we did at the university with the interdata/3 to get it to emulate control unit (we had to build our own channel attach card) ... claiming to have originate the 360 PCM controller business:
https://www.garlic.com/~lynn/submain.html#360pcm

misc. early RJE-related RFCs: 88 NETRJS: A third level protocol for Remote Job Entry. 105 Network Specifications for Remote Job Entry and Remote Job Output 217 Specifications changes for OLS, RJE/RJOR, and SMFS 283 NETRJT: Remote Job Service Protocol for TIPS 307 Using network Remote Job Entry 324 RJE Protocol meeting 325 Network Remote Job Entry program - NETRJS 338 EBCDIC/ASCII Mapping for Network RJE 360 Proposed Remote Job Entry Protocol 368 Comments on "Proposed Remote Job Entry Protocol" 407 Remote Job Entry Protocol 477 Remote Job Service at UCSB 499 Harvard's network RJE 725 RJE protocol for a resource sharing network

... for URL index of RFCs:
https://www.garlic.com/~lynn/rfcietff.htm

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

ibm time machine in new york times?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ibm time machine in new york times?
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main,comp.protocols.time.ntp,rec.arts.sf.science,alt.sci.time-travel
Date: Sat, 28 Dec 2002 15:56:46 GMT

the other scenario was a report that seemed to involve head-to-head comparison of 16mbit t/r against 3mbit ethernet ... claiming something like ten to fifteen times more aggregate thruput for t/r.

this was somewhat after paper in acm sigcomm proceedings (88) that for 30 station ethernet lan ... in low-level loop constantly sending minimum sized packets that effective aggregate thruput dropped off to 8.5mbits/sec (for 10mbit/sec ethernet media).

the only place that it seemed to be able to do such an actual head-to-head comparison was against very early ethernet that operated at 3mbits/sec and didn't do listen before transmit.

some number of reports showed that peak aggregate thruput of 16mbit t/r lan was about fifty percent of media because of token rotation delays.

the other report was from the austin pc/rt people. they had done a high perforance 4mbit t/r adapter card for the pc/rt ... but weren't allowed to do a similar project for 16mbit t/r adapter card. they showed that the sustained adatper thruput of their 4mbit t/r adapter was twice that of the 16mbit t/r adapter card that they were forced to accept.

This isn't so much an issue in a 100-300 station lan using t/r adapters for terminal emulation to mainframe ... however it became significant issue for typical workstation client/server environment with highly asymmetric traffic flows .... aka server lan station is either the sender or receiver for majority of all traffic on the lan. If the server was limited to 1mbit aggregate thruput (or less) .... then it hardly mattered what the raw media thruput of the lan was.

... so there was some comment that the only rational for doing a 16mbit t/r head-to-head comparison against 3mbit ethernet ... was if you had a time machine and could take the 16mbit t/r adapters back in time and sell them in competition against 3mbit ethernet.

Part of the technical issue was that 16mbit t/r with SNA .... doesn't have network layer and routers .... so you have 100 stations sharing 16mbits. A typical 100 station ethernet configuration with 16 10mbit subnets and routers was about the same as T/R configuration.


no. machines         100                  100
adapters/machine     1                    1
no. adapters         100                  100
cost/adapter         $900                 $300
total adapter        $90,000              $30,000
router               -                    $70,000
total cost           $90,000              $100,000

no. LANs             1                    16
router thruput       -                    200mbit
avail. bandwidth     16mbit               160mbit
machines/LAN         100                  6.25
avg bw/machine       .16mbit              1.6mbit

$/LAN                $90,000              $6,250
$/mbit               $5625                $625

For asymmetric (client/server &/or 3-tier) traffic flow it was possible to do one or more dedicated ethernet, FDDI, channel and/or escon interfaces to the router. Above doesn't take into account that actual effective 16mbit t/r thruput is closer to 8mbits ... and that worst case per ethernet aggregate effective is 8.5mbits.

Anyway above was from something where we introduced 3-tiered architecture (at a presentation to the CIO council of very large multi-national corporation ... which was in the habit of configuring 300 stations per 16mbit T/R).

We got hammered by the 16mbit t/r people as well as SNA and SAA people (i.e. SAA was basically trying to put the client/server genie back in the box .... and here we were coming up with 3-tiered architecture).

past 3tier & saa refs:
https://www.garlic.com/~lynn/subnetwork.html#3tier

and of course high speed data transport refs:
https://www.garlic.com/~lynn/subnetwork.html#hsdt

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

ibm time machine in new york times?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ibm time machine in new york times?
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main,comp.protocols.time.ntp,rec.arts.sf.science,alt.sci.time-travel
Date: Sat, 28 Dec 2002 16:50:29 GMT

from the previous ref ... while the elevator in bldg. 12 may have said that the floor with the credit union and the mail room was "1" .... if you went into or out of the front of the bldg ... you went thru the lobby on the main floor which was the floor above ... and so I always referred to the floor below the main floor as the basement.

Anne & Lynn Wheeler writes:
this was somewhat after paper in acm sigcomm proceedings (88) that for 30 station ethernet lan ... in low-level loop constantly sending minimum sized packets that effective aggregate thruput dropped off to 8.5mbits/sec (for 10mbit/sec ethernet media).

the above was worst case scenario for all 30 stations in tight low-level driver loop constantly transmitting minimum size enet packets (dropping aggregate effective thruput to 8.5mbit/sec).

however, another study from the period show that in bursty client/server scenario over 9.5mbit/sec effective thruput was easily possible (multiple bursty packets between client & server .... possibly not that unusual in many client/server operation) and that could degrade to 8.5mbit/sec in the worst case scenario.

the target for 16mbit t/r adapter (with its minimal per adapter thuput) was really designed for the terminal emulation environment because it neither supported typical asymmetric server bandwidth (sustained server thruput) operation nor classical client/server bursty activity (where both client & server have short transient periods of peak thruput/traffic).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

ibm time machine in new york times?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ibm time machine in new york times?
Newsgroups: alt.folklore.computers
Date: Sat, 28 Dec 2002 20:33:37 GMT

when 85 (large multi-lane divided highway) went thru ... the recreation area wound up on the opposite side from the main plant site .... a two-lane subgrade underpass was put in connecting the two parts of the plant site.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Star Trek: TNG reference

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Star Trek: TNG reference
Newsgroups: alt.folklore.computers
Date: Sat, 28 Dec 2002 21:22:31 GMT

"Kelli Halliburton" writes:
is that World War Eleven?

to quote some friend it was that unpleasantness in europe (even tho by almost every measure there was more activity in the pacific).

had a funny experience living in austin for short period ... next door to Guderian's nephew ... who was a retired us air force col. (with absolutely no connection to boyd as far as i knew). however a picture of him dressed in Guderian's uniform was indistinguishable from a picture of Guderian.
https://www.garlic.com/~lynn/subboyd.html#boyd

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

System vs. application programming?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System vs. application programming?
Newsgroups: alt.folklore.computers
Date: Sat, 28 Dec 2002 23:58:13 GMT

Peter Flass writes:
I would say it depends on your personality. If you are a "people person" you'd be better off in applications. If you enjoy working alone, go with systems. I've done both. A good systems guy will lock him/herself in a room with a terminal and emerge weeks or months later with some brilliant piece of code no one else thought of that makes the system run better/faster/etc. A good application guy will spend so much time with the user he/she'll begin to think like the user, and produce some code the user would have come up with, if only he could program.

i always thot if you weren't part of the production datacenter then (by definition) you were out of touch with reality. i always attempted to align myself with one or more production datacenters (whether it was system or application work) ... so that i do staged deliveries ... possibly weekly incremental but even for major development projects ... interval of no more than 2-3 months. it had the down side that you frequently had responsibility first or at least 2nd level problem determination at the datacenter (as things like attending the weekly datacenter meetings with users) .... and if you had more than five or six such full time jobs simultaneously ... you were kept busy.

If code was more than two months from the metal ... fantasy starts creeping in (at least for anything new .... if it is effectively nearly the same thing repeated dozens of times before then it is less of an issue).

there is the joke about one period working 32 hr days ... 8 hrs in bldg. 28 (research), 8 hrs in bldg 14 (disk engineering), 8 hrs in bldg 90 (stl database, etc), and 8 hrs in palo alto as HONE data center system build and support; each was actually two full time jobs (system development as well as system programming/support) ... for possibly eight full time jobs simultaneously.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

ibm time machine in new york times?

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ibm time machine in new york times?
Newsgroups: alt.folklore.computers
Date: Sun, 29 Dec 2002 00:40:18 GMT

Sam Yorko writes:
Really? Which part? I know where the OSH headquarters are, what about the area behind OSH that was just built up with five new buildings a couple of years ago?

there was bldg. block or two over from the end of light rail ... that at one time was quarters for employee credit union (after it moved out of bldg. 12 because of the seismic upgrade) and before it moved down to current location on blossom and chenawith. It then had a sign out front that said OSH hdqtrs for long time (don't know if it still does). i think it is on via del oro.

on san ignacio backing up to what is currently 85 (before great oaks exit) was bldgs. 96, 97, and 98 (all one story) ... there were leased bldgs that handled some of the overflow from the main plant site. They now have other occupants (both downsizing and consolidation of lots of stuff in bldg 50). It looks like who ever bought 97 & 98(?) .... they built in the area between the two bldgs .... so that it now looks like one large bldg (backing up to 85 .... on the right side driving south just before 101 ... you look right down at the back of the bldg and what looks like loading docks).

on the other side of the end of light rail is PG&E complex (facing santa teresa) and what use to be the rec. area. Some years ago, the rec. area was sold off ... and a large apartment complex built on the land (and the below grade, underpass connecting it to the main plant site was filled in).

anyway if you pull up something like mapblast ... the plant site is the area bounded by 85, cottle, and railroad/monterey hwy. try starting here and zooming out:
http://www.mapquest.com/maps/map.adp?country=US&addtohistory=&address=san+ignacio+%26+via+del+oro&city=san+jose&state=ca&zipcode=95123&homesubmit=Get+Map

also on that stretch of 85 (about where the bldgs on san ignacio back up to 85) i've been told by a number of people that radar detectors trip. This should be the collins digital radio (T3) signal from the repeater on hill going to santa teresa lab and the dish on top of bldg. 12 (there use to be another such repeater tower above the san jose dump .... connecting the los gatos vlsi lab and bldg 12).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

ibm time machine in new york times?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ibm time machine in new york times?
Newsgroups: alt.folklore.computers
Date: Sun, 29 Dec 2002 00:58:11 GMT

also when bldg. 14 was undergoing its seismic upgrade ... disk engineering moved into a leased two story red-brick-faced bldg (bldg 86) ... that had parking lot that backed up to san ignacio across from 96/97/98. When seismic upgrade finished ... they moved back into bldg. 14.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

myths about Multics

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: myths about Multics
Newsgroups: alt.os.multics
Date: Sun, 29 Dec 2002 17:41:36 GMT

"Shmuel (Seymour J.) Metz" writes:
The lack of address translation was part of what made OS/360 so expensive. Had the hardware designers had more ambityion, the software designers might have come out looking better.

aka .... os/360 monitor for apl\360 was somewhat more like CTSS .... swapping in/out whole workspace for application/process. this tended to have swap. configured as either 16kbyte or 32kbyte.

the port by csc (545 tech sq ... but 4th floor) to cms (running under cp/67 in virtual memory) opened up (nearly) 16mbyte workspaces (from 16kbyte). system calls (i.e. file i/o, other things) were also introduced in cms\apl (which causes quite a bit of trouble with the apl language purists). in any case with large address spaces and simple thing like file i/o, corporate business people in hdqtrs started logging into cambridge running complex business model & simulations using cms\apl (with the most sensitive of corporate data). this created quite some sensitivity to security issues with all the MIT & BU students running around csc using the system.

one of the other issues was the basic apl\360 storage allocation was always allocate new location on any sort of assignment ... and when end of the workspace address was reached ... garbage collect and collapse down. A plot of storage address references against time (printed output arraanged in 6ft high strips running around the halls of 4th floor, storage address on the verticle) ... showed a very saw-tooth type effect. this was quite detrimental to large paged virtual memory workspace environment.

anyway 360/67 was only 360 virtual memory machine .... melinda's paper has a lot of past stuff about ctss and csc w/67 hoping to win the multics bid (some of the ctss/7094 people went to multics in 545 tech sq ... and some went to csc on the 4th floor):
https://www.leeandmelindavarian.com/Melinda#VMHist

one not mentioned was the boeing huntsville (supporting of nasa) use of os/360 mvt running in virtual memory mode on 360/67 two processor system. mvt was slightly hacked to support the 360/67 virtual memory hardware tables but didn't support paging and only supported single address space. It turns out that the system drove some number of 2250 (19in vector displays) where typical 2250 application might run for several hours. The problem wasn't so much of application storage requirements exceeding real storage ... it was that mvt needed application storage to be contiguous and long running application tended to have quite a bit of storage allocation fragmentation. the virtual memory was used to remap addresses to provide the illusion of contiguous address space as partial mitigation of fragmentation. This was some number of modifications to os/360 releaxe 13.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

myths about Multics

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: myths about Multics
Newsgroups: alt.os.multics
Date: Mon, 30 Dec 2002 18:11:01 GMT

"Shmuel (Seymour J.) Metz" writes:
They say that the memory is the first thing to go. I ordered optional source code for every release of OS/360 from 14 up, along with various releases of OS/VS2. I could have rebuilt the entire system from source. What I could not get was machine readable source for service in between releases.

mentioned somewhere before .... i had heard a rumor that some agency requested the exact source for a release .... not the source materials ... but the exact, guaranteed binary comparable source .... and after a lengthy review were told that it wasn't practical.

For the resource manager .... at entry to final product test ... i built optional machine readible source & listing tapes ... as required for standard product release (didn't matter whether VM or OS or what kind of product). From this source listing tape ... PID also created microfiche.

However entry to final product test ... was six months before first customer ship. The supposedly claim was that for large complex delivery ... that the final build & integration as part of first customer ship couldn't be guaranteed to be exactly the same as the "source" tapes sent to PID possibly six months earlier (aka it would be extremely expensive & unpractical to synchronize the source tapes prepared).

The difference with CP/67 and VM/370 .... from most of the rest of the product distributions ... was that all distributions shipped with the exact source files as well as the procedures used for final product build & integration. This was for all distributions ... not only the major releases but also the monthly "PLC" maintenance distributions.

This source procedure wasn't part of the optional PID source materials. PID just got a tape and duplicated as "the" distribution tape (w/o the special designation processing that there might be source on the tape).

One of the reasons that on the other distributions ... there wasn't the source materials from PID for the maintenance stuff (it wasn't available as optional source materials for CP/67 or vm/370 via this method also) .... was that the typical six months delay between the PID process for entry to standard product release and the possible final product integration & test for first customer ship .... had much less meaning ... as well as nobody being able to guarantee that there were no changes between the (optional) source materials were created and shipped to PID ... and when the actual release tapes were created and shipped to PID.

... aka in effect, the only way to guarantee that the source & distribution actually matched were that they were built and created on the same media (which was the cp/67 & vm/370 process and was not related to the PID optional source material process).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

myths about Multics

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: myths about Multics
Newsgroups: alt.os.multics
Date: Mon, 30 Dec 2002 18:56:21 GMT

Anne & Lynn Wheeler writes:
... aka in effect, the only way to guarantee that the source & distribution actually matched were that they were built and created on the same media (which was the cp/67 & vm/370 process and was not related to the PID optional source material process).

HASP effectively had a similar kind of process as CP/67 & VM/370 where independent of the optional source material process ... they shipped exact source & build materials with the standard distribution.

that changed somewhere in the transition to JES .... where they had to adopt the standard POK processes. However, the JES group did have some difficulty. Somewhere along the way they had adopted the CP/CMS source management process for all internal development (as did some number of other groups). The problem for release was that the POK release process including a source management process that I believe was called something like ClearCaster. JES (and other groups) had some difficulty translating the intenal development cp/cms source management files into the ClearCaster system for product release.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

myths about Multics

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: myths about Multics
Newsgroups: alt.os.multics
Date: Mon, 30 Dec 2002 19:25:21 GMT

my impression (although i didn't see any quote details) that it was possible to enter binary executables into the POK integration & test process .... w/o it having originated as part of an end-to-end build from the POK source management system (Clear or clearcaster or whatever it was called). the result was that the source in clear(?) (and from which the optional source materials were created) only bore a fuzzy relationship to the executables at any point in time.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

windows office xp

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: windows office xp
Newsgroups: alt.folklore.computers
Date: Tue, 31 Dec 2002 04:49:47 GMT

Marco S Hyman writes:
"Acceptable" response is a moving target. In "on-line" systems of that era a common spec was something like 1/2 to 1 second response. When people got a consistent 1 second response time to their query they were happy.

aside: This was using block mode terminals where response is the time between hitting the "transmit" key and seeing the start of a response. It assumes that only a small amount of data is being sent from terminal to host. It took about a second and a half just to transport a full screen (24x80) at 9600 BPS.

If you gave users a 1/2 second response for a period of time, then went back to a one second response, you'd get nothing but complaints. All of a sudden 1 second was no longer "acceptable". So data com folks were taught to pad things a bit when the system was otherwise idle.

part of the 3278/3274 battle was about sub-second response time. some data:
https://www.garlic.com/~lynn/2001m.html#19 3270 protocol

note the above data is for locally attached .... it gets worse for SNA and worse still for any remote.

there was human factors study presented at internal technical exchange held at the (first?) marriott hotel in DC circa 70 or 71. The super program stuff was presented ... but there was also presention human threshold perception .... the minimum interval that response that could be perceived seemed to vary from about .10 second to nearly .25 second across a broadly sampled population. At the time there was no conjuncture as to the reason (why minimum preceptial threshold varied from person to person) ... just that was the observed results. Note that this also has some effect on settings for repeat delay and repeat rate. with a little bit of soldering, 3277s could have repeat delays and repeat rate adjusted (i.e. being able to set repeat delay and repeat rate to .1 and 10/sec).

I got a large timesharing service with large variety of mix-mode worked tuned to where the 90th percential response for trivial response was .11 second.

large time-sharing systems tended to have the 10am syndrome ... even if trivial interactive was controlled there was still the typical load build up in the morning .... peaking and then dropping off. Then a build up again after lunch, peak, and drop off.

misc. super programmer
https://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#24 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#26 S-P-F (was Mainframe operating systems)

marriott thread drift:
https://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#24 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#25 How many Megaflops and when?
https://www.garlic.com/~lynn/2000c.html#64 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001h.html#48 Whom Do Programmers Admire Now???
https://www.garlic.com/~lynn/2002i.html#49 CDC6600 - just how powerful a machine was it?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Big Brother -- Re: National IDs

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big Brother -- Re: National IDs
Newsgroups: alt.folklore.computers
Date: Tue, 31 Dec 2002 05:08:04 GMT

"Rupert Pigott" <darkboo-remove-this-ng.@hotmail.com> writes:
The war and post-war years radically changed food production in this country too (twice in fact, WWI & WWII)... IIRC the arable yield per hectare is three fold what it was in the late 40s now.

i remember during the 50s in NE montana summer wheat was good harvest if it got five bushels/acre ... but three bushel years weren't unusual. i also ran across some article about the palouse hills in SE washington .... something about a giant dust storm tens of thousands of years ago and the top soil is 100ft deep in places(?). Anyway ... they've recorded wheat harvests something like 100 bushels/acre

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

MVS History

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MVS History
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 31 Dec 2002 05:18:28 GMT

edgould@AMERITECH.NET (Edward Gould) writes:
Or the 8100 ??

i think Bob Evans had my wife audit 8100. it was another uc.5 microprocessor thing (as was 3705, 3081 service processor, some number of other things).

some tried to get peachtree processor for the 3705 product .... being a significantly superior processing engine; but failed (however peachtree did show up as series/1).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

cost of crossing kernel/user boundary

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: cost of crossing kernel/user boundary
Newsgroups: comp.arch
Date: Tue, 31 Dec 2002 15:27:55 GMT

Emil Naepflein writes:
My goal is to reduce the system call overhead to a minimum for any system call. One part of the overhead is the complete save/restore of the register set. On architectures where there are only a few registers it doesn't matter much. Some architecturs do the save implicitly during system call instruction processing (i386), others like mips give the choice what to save to the implementer. Here the question was whether it is possible to avoid the complete save/restore at entry/exit and rely on callee saves/restores.

one of the things i played with very early on in cp/67 was not fiddling the floating point registers (just the general purpose regs) ... unless there was task switch .... aka kernel made no use of them. For some fastpaths ... also tried to just perform the necessary reload of only general regs that fastpath interrupt handling had fiddled.

charlie tried doing something similar with control register 0. CR0 was the virtual address table register on the 360/67. Every time into any kernel interrupt handler it was reloaded ... even tho the value could never have changed. also since 67's TLB was only one address space ... and didn't have logic to see if the reload was changing any value ... it forced a flush of all TLB entires. So he removed the reload ... and the system started crashing. They spent a couple weeks diagnosing the problem until they found a bug in the '67 hardware ... which had gone undiscovered for something like six years. On page fault interrupt from program state into supervisor state ... the hardware would reset all the TLB entries to zero but not clear the TLB entry valid bit (effectively mapping virtual address page zero to real kernel page zero). This was the first time that a interrupt handler had been tried w/o reload of CR0 (which forced invalid for all TLB entries).

in the past
https://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary

the above description of changes to the svc interrupt handler for savearea management & misc. other .... reduced the time spent in the svc call interrupt processing from about 270microseconds to less than 70microseconds (including the interrupt and the return). Of course the BALR change (for those applicable calls) collapsed it to a couple microseconds (not counting the actual register save & restore instructions).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

next, previous, index - home