From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Early tcp development? Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,alt.folklore.computers,alt.culture.internet,alt.culture.usenet Date: 03 Jan 1999 16:15:25 -0800it is even more interesting using TCP for HTTP transactions ... which (if i remember right) requires for reliable transmission a minimum of 7 packet exchange compared to five packet minimum for VMTP (rfc1045)
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Early tcp development? Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,alt.folklore.computers,alt.culture.internet,alt.culture.usenet Date: 07 Jan 1999 11:45:07 -0800also ... while huge images might dominate in terms of bandwidth there is still a significant large number of short HTTP/TCP session. An early issue was the enormous number of dangling FINWAITs ... and design assumptions that since FINWAITs are only associated with long-running activity ... there would never be more than a couple on the list at any time ... and therefor it was acceptable to do a serial searh of the list (some webservers circa '95 were spending 90% of processing running FINWAIT list).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 08 Jan 1999 08:55:26 -0800I think it was somebody at Princeton that did a port of Unix to 370. There were two people in IBM that tried to hire him when he graduated ... but were not able to get authorization. Amdahl hired him and produced gold (aka Au, Amdahl unix) which became UTS.
AT&T & IBM had an effort that had unix running on top a modified TSS/370 kernel.
I believe that the AT&T and Amdahl efforts were pretty much unrelated.
AIX/370 was a Locus port that included AIX/PS2 in the package.
About 85/86, at one of the science centers, IBM had a project to port BSD to 370 ... but part way thru the activity ... the effort got redirected to porting BSD to the IBM PC/RT.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 09 Jan 1999 15:08:10 -0800current description:
http://ppdbooks.pok.ibm.com:80/cgi-in/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/CCONTENTS
.. specifically
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/13.0
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/14.0
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/15.0
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/16.0
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/17.0
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 10 Jan 1999 09:32:13 -0800simplex 67 was single ported memory .... the two-processor 67 had a channel controller with dual-ported memory. Heavy load had a "half-duplex" 67 (i.e. single processor with channel controller and dual-ported memory) outperformed simplex 67.
anyway from the alt.folklore.computers and comp.arch archives ...
Subject: Re: Virtual Memory (A return to the past?)
From: lynn@garlic.com (Anne & Lynn Wheeler)
Date: 1995/09/27
Newsgroups: comp.arch
.. some of you are probably getting tired of seeing this ... but a typical '68 hardware configuration and a typical configuration 15 years later
machine 360/67 3081K mips .3 14 47* pageable pages 105 7000 66* users 80 320 4* channels 6 24 4* drums 12meg 72meg 6* page I/O 150 600 4* user I/O 100 300 3* disk arms 45 32 4*?perform bytes/arm 29meg 630meg 23* avg. arm access 60mill 16mill 3.7* transfer rate .3meg 3meg 10* total data 1.2gig 20.1gig 18* Comparison of 3.1L 67 and HPO 3081k========================================
360/65 is nominal rated at something over .5mips (reg<->reg slightly under 1mic, reg<->storage start around 1.5mic and go up). running relocate increases 67 memory bus cycle 20% from 750ns to 900ns (with similar decrease in mip rate). 67 was non-cached machine and high I/O rate resulted in heavy memory bus (single-ported) contention with processor.
drums are ibm'ese for fixed head disks.
disk access is avg. seek time plus avg. rotational delay.
the 3.1l software is actually circa late 70 or earlier 71 (late in the hardware life but allowing more mature software). the 3081k software is the vm/hpo direct descendant of the cp/67 system.
90th percentile trivial response for the 67 system was well under a second, the 90th percential trivial response for the 3081k was .11 seconds (well under instantaneous observable threshold for majority of the people).
the page i/o numbers is sustained average under heavy load. actual paging activity at the micro-level shows very bursty behavior with processes generating page-faults at device service intervals during startup and then slowing down to contention rates during normal running. the 3081k system had pre/block page-in support (i.e. more akin to swap-in/swap-out of list of pages rather than having to individually page fault).
big change between 68 and 83 ... which continues today is that processor has gotten much faster than disk tech. has gotten faster. real memory sizes and program sizes have gotten much bigger than disk has gotten faster (programs have gotten 10-20 larger, disk get twice as fast, sequentially page faulting a memmap'ed region 4k bytes at a time takes 5-10 times longer). Also while current PCs are significantly more powerful than mainframe of late '60s and the individual disks are 5-10 times faster, the aggregate I/O thruput of todays PCs tend to be less than the aggregate I/O thruput of the mainframe systems.
In any case, when I started showing this trend in the late '70s that disk relative system performance was declining (i.e. rate of getting better was less than the getting better rate for the rest of the system) nobody believed it. A simple measure was that if everything kept pace, the 3081K system would have been supporting 2000-3000 users instead of 320.
Somewhat bottom line is that even fixed head disks haven't kept up with the relative system performance. Strategy today is whenever possible do data transfers in much bigger chunks than 4k bytes, attempt to come up with asynchronous programming models (analogous to weak memory consistency & out-of-order execution for processor models), and minimize as much as possible individual 4k byte at a time, synchronous page fault activity.
From: lynn@garlic.com (Anne & Lynn Wheeler) Newsgroups: alt.folklore.computers Subject: Re: 3330 Disk Drives Date: 18 Jun 1995 17:10:56 GMTfollowing from report i originally did in '81 ... part of the numbers were excerpted in postings in this group early last year (archived at
Some of the numbers were done in late '70s where it was shown that upgrading from 3330-ii to 3350 only improved performance if allocated data was limited to approx. same as on 3330-ii. The 3380 are the original (single density) 3380.
2305 2314 3310 3330 3350 3370 3380 data cap, mb 11.2 29 64 200 317 285 630 avg. arm acc, ms 0 60 27 30 25 20 16 avg. rot del. ms 5 12.5 9.6 8.4 8.4 10.1 8.3 data rate mb 1.5 .3 1 .8 1.2 1.8 3 4k blk acc, ms 7.67 85.8 40.6 43.4 36.7 32.3 25.6 4k acc. per sec 130 11.6 24.6 23 27 31 39 40k acc per sec 31.6 4.9 13. 11.3 15. 19.1 26.6 4k acc per sec per meg 11.6 .4 .38 .11 .08 .11 .06======================================================================
slightly different table ... assuming a uniform access distribution, loading the indicated max. data on the drive (i.e. not filling the whole thing) gives the resulting 4kbyte-block-access/sec/mbyte (i.e. 3380 with only 40mbyte loaded gives approx. the same performance as 2314).
2305 2314 3310 3330 3350 3370 3380 data cap, mb 11.2 29 64 200 317 285 630 4k acc. per sec 130 11.6 24.6 23 27 31 39 20 meg - .041 .091 .082 .098. .122 .152 40 meg - - .023 .021 .025 .031 .039 60 meg - - - .009 .011 .014 .017 80 meg - - - .005 .006 .008 .010--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 10 Jan 1999 15:05:45 -0800370s were 115, 125, 135, 145, 155, 165 (and sort of 195)
initial 155 & 165 had no virtual memory (relocation) hardware
it was possible to open the front panel of the 155 and disable the cache ... and the thruput of the machine dropped to that of about a 145.
to announce virtual memory ... the 155s & 165s in customer shops needed a hardware retrofit. Turns out for the full virtual memory announcement ... an extra hardware line thru much of the 165 would have had to be designed and built ... and would have delayed virtual memory announcement by an additional six months. Since SVS (effectively MVT remapped to a virtual memory space) stated that they had no need for the full architecture ... they would be perfectly happy to go with abbreviated virtual memory hardware roll-out. The other machines shipped day one with the virtual memory support built in ... but had to wait for 155/165 & software before it was turned on.
155s and 165s were upgraded with 158s & 168s ... and 135s and 145s then with 138s and 148s.
The 168-1 had an interim upgrade to a 168-3 which doubled the size of its cache (although there were a couple shops who installed the 168-3 field upgrade and saw performance decline).
The 158s&168s were then upgraded by 3031, 3032, and 3033. The big feature of the 303x line was the channel director (somewhat analogous to the channel director on the 360/67 duplex configurations ... and actually a separate stripped down 158 processer with a different microcode load). The 3031s and 3032s were 158s and 168s repackaged with I/O support going thru the channel director. The 3033 started out as a 168 wiring diagram remapped to a faster chip technology.
The 138s & 148s were upgraded to 4331 and 4341 ... and then to 4361 and 4381.
The internal network was tagentially involved in the 145 support. The internal network was larger than the arpanet/csnet pretty much from the start up thru sometime in the mid-80s. One of the first links in the internal network (besides those running between machines in the same building) was between cambridge (mass) and endicott (ny).
Most of the virtual machine work was done in cambridge and the 370/145 work was being done in endicott. Endicott came to cambridge and proposed a joint project to build a 370 virtual machine capability ... which ran within a CP/67 (i.e. 360/67) virtual machine ... simulating the features that were different between the 360 and 370. A version of CP/67 was created that would provide 370 virtual machine architecture (this was reference to as 3.1h). Then a version of CP/67 was modified so that it ran on the 370 relate architecture (referred to as 3.1i).
For various security reasons ... partly because there were people like MIT students that had access to the Cambridge CP/67 service ... the environment looked like:
standard CP/67 running on real 360/67
providing 360/65 and 360/67 virtual machine service
a 3.1h operating system running in a 360/67 virtual machine
providing 370/145 (both relocate and non-relocate) virtual machines
a 3.1i operating system running in a 370/145 relocate virtual machine
providing 370/145 (both relocate and non-relocate) virtual machines
cms running in a 370/145 non-relocate virtual machine
This evironment had been running for a year before the very first
370/145 engineering machine (of any kind) was up to the point that it
could be tested. The first time that the "3.1i" system was booted on
the first engineering 370/145 machine ... it failed. After some quick
diagnostic, it turned out that the engineers had implemented some of
the architecture wrong. The operating system was quickly patched to
correspond to the incorrect hardware implementation ... and the
testing then proceeding successfully.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 11 Jan 1999 08:45:42 -0800drums are ibm'ese for fixed head disks.
well ... alright ... i added it to the '95 posting after getting questions from the posting in early '90s seemingly coming from no knowledge of either DASD nor drums ... "fixed head disks" seemed to be the simplest throw-away to get over that bit.
i tried to get a separate read/write data path (ala 2505 device "exposures") to the 3350 but it got shot down by the vulcan crowd.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 12 Jan 1999 10:30:45 -0800cp/67 started out being less than a single tray of "binary" cards.
vm/370 simulated card decks got much larger ... not only because there was much more code ... but also typically upwards of half the cards in any particular txt/binary deck was the source code tracking information (PTFs, macro libraries, updates, source libraries, etc).
the output of such a load was printed output of all the entry points in each module ... plus all the source code tracking information.
I remember being in madrid in the mid-80s ... and going to a theater showing some 30? minute drama "short" done at the university ... in several shots there was a wall of TV sets (20-30?) all "scrolling" the same information at around 1200 baud. I felt funny being able to recognize it was the VM/370 "loadmap" (i.e. output from the binary program load) ... i felt even funnier being able to recognize the year & month of the system based on the source code information scrolling past at 1200 baud.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 12 Jan 1999 23:36:17 -0800cp/67 originated with people from cambridge science center and some work being down by people from lincoln labs ... summer of 68 ... a couple of the people left and formed NCSS offering enhanced CP/67 online service ... another group left and formed IDC (interactive data) ... NCSS was down in Stanford Conn ... IDC was out in waltham mass. I was undergraduate ... there was an IBM sponsored class on CP/67 that summer down someplace in LA ... I got pressed into teaching part of the CP/67 class ... possibly because one or more of the IBM'ers had left and gone to NCSS.
back then you could get CP/67 from IBM ... sort of like you can get linux today ... all the source and do whatever you wanted with it. Lots of places ... including universities got copies with source ... and large numbers (well not large numbers by today's standards) ... but still significant numbers ... took the system & source and did various things with it.
all of this well before VM/370. Tymshare later used VM/370 to offer online service ... mid-70s
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Computers Newsgroups: alt.folklore.computers Date: 17 Jan 1999 22:31:07 -0800found green cards ... GX20-1703-7 yellow cards are GX20-1850-3 ... 1976 and the blue cards are 229-3174-0
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Computers Newsgroups: alt.folklore.computers Date: 18 Jan 1999 18:07:48 -0800I was involved in getting Interdata3 (and later array of interdata3s with an interdata4) to simulate an IBM mainframe communication control unit (bus&tag channel card, etc) ... I've been told that this activity was documented as having originated the IBM "OEM" (other equipment manaufacter) control unit business. Somewhere along the line interdata was bought by Perkin/Elmer. Recently somebody told me that they were selling Perkin/Elmer boxes in the early 80s with 360/370 bus&tag wire-wrap channel board ... potentially the same board design that we had done something like 15 years earlier.
If you look at other threads in this newsgroup ... the interdata 7? from the late 70s was one of the early efforts making Unix portable.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Computers Newsgroups: alt.folklore.computers Date: 18 Jan 1999 19:11:16 -0800360 had 8 bit bytes and standard i/o read a card column into single 8-bit byte. ... since a card column could contain up to 12 bits of information (12 rows) ... 360 defined a restricted subset of possible card punch combinations.
1401 supported binary .... to support processing 1401 binary decks (with more than 8 bits punched per column) ... 360 card punch controller had a "column binary" mode which read 80 columns into 160 byte positions ... in order to represent all information. From 360 green card 2540 operation:
read, feed, select stacker SS: SSD00010
where SS: 00 stacker R1
01 stacker R2
10 stacker RP3
D: 0 EBCDIC
1 column binary
character mode on 1401 was BCD 6bit code and almost proper subset
of EBCDIC in punch card definition.
it was possible to read/punch BCD cards using standard EBCDIC mode, but required column binary to read/punch 1401 binary cards.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Computers Newsgroups: alt.folklore.computers Date: 19 Jan 1999 10:50:03 -0800yep ... there was very little structural integrity left in a card that you had bunched all 80x12 holes ... didn't even necessarily require high speed reader.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Glass Rooms (was Re: drum memory (was: Re: IBM S/360)) Newsgroups: alt.folklore.computers Date: 20 Jan 1999 19:58:58 -0800my wife was UMich engineering graduate school ... and remembers blockades and riots ... having to cross picket lines to classes; once being in engineering lab with nose pressed to the window watching the rioters came thru the square trashing everything in their wake ... and somewhat surprised afterwards that they had broken out every window facing the square except the one she had her nose pressed to.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Computers Newsgroups: alt.folklore.computers Date: 23 Jan 1999 07:46:46 -0800there is another place that batch systems have worked ... almost any server deployment. the platforms that have grown out of interactive&desktop have paradigm that if something goes wrong ... they've tended to assume a human there to recognize and take action.
the batch paradigms have tended to provide extensive trap & recovery features to the application level (default to system define recovery and/or operator message ... but 7x24 applications could implement extensive support if that level of availability was required).
for the first webserver doing payments/e-commerce ... after they had done the straight-line and stress testing ... i went back with a failure-mode array (something like 40+ failure modes and 5-6 states), webserver code had to demonstrate automatic recovery ... and/or sufficient logging that on a trouble call ... the trouble desk could diagnose the problem within five minutes (none of this NTF on the trouble ticket after 2-3 hrs). Application couldn't inline trap on something like ICMP host not reachable ... and so had to do some contortions to produce something even approaching 7x24. I had to browbeat to even get multiple A-record support.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Computers Newsgroups: alt.folklore.computers Date: 23 Jan 1999 11:58:29 -0800my view point is that the old computers hosted both sequential batch as well as almost all of the major online applications currently in existance (airline res, payroll, banking, financial, insurance, securities, etc).
In some cases there have web gateways done to access those online capabilities.
as mention in prior note ... the old computers tended to follow the paradigm that things ran w/o people present (except for operators doing tape mounts) ... this has led to a rich set of semantics for trapping failures and being able to automate various recover strategies ... even up thru the application layer.
the desktop&interactive systems (and their derivatives) have tended to operate with a paradigm that person was issuing a "command" ... and therefor could determine a recovery strategy.
the legacy stuff ... has assumed that people weren't interactively determining the execution strategy (either in batch or in the big OLTP systems) ... and so sophisticated automated processes were developed.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Computers Newsgroups: alt.folklore.computers Date: 23 Jan 1999 19:54:25 -0800following from posting to alt.folklore.computers made here in 94mar. there was issue in early '80s regarding stanford PhD thesis on "clock" algorithms for page replacement ... meeting severe resistance because it talked about stuff that wasn't local LRU and/or as defined per true "working-set". I had done the global "clock" global LRU in the late 68 time-frame with a dynamic adaptive thrashing control that worked significantly better than working set (as found in the literature of the time). the following direct comparison ... same processor, same I/O, similar workload and configurations ... was instrumental in removing objections to thesis and PhD.
Genoble Science Center published a paper in CACM sometime in the early '70s describing their implementation of a "working-set" dispatcher on CP/67 (effectively faithful implementation described in Denning's article). They had a 1mbyte 360/67 (which left 154 4k "pageable-pages" after fixed kernel requirements). They provided about the same level of performance for 30 users as we did for 70 user on a 768k 360/67 (104 4k pageable pages).
The differences (circa '70-71):
grenoble cambridge machine 360/67 360/67 # users 30-35 70-75 real store 1mbyte 768k p'pages 154 4k 104 4k replacement local LRU "clock" global LRU thrashing working-set dynamic adaptive priority cpu aging dynamic adaptive--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Most embarrassing email? Newsgroups: alt.folklore.computers Date: 07 Feb 1999 14:28:22 -0800late 80s, i agreed to forward a "farewall" email written by my former boss saying that he was leaving the company and moving on to other opportunities. I selected the wrong distribution list and it went out to some 23,000 people inside the company. got quite a bit of flack back from around the world about who was I and why was I sending them the email.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: APL/360. Newsgroups: alt.folklore.computers Date: 09 Feb 1999 13:27:52 -0800big problem with apl/360 was its relatively small workspace ... typically 32k or less. when we ported to CMS (71?) we opened up the workspace to full virtual machine size (up to 16mbytes). One of the biggest problems with apl/360 was storage allocation ... every assignment (even to existing variables) went to new storage location. Instruction traces of apl/360 showed stair-step use of storage until it reached end of memory ... and then a sharp drop back by garpage collection moving everything down to lowest available address ... and then the stair-step use again. The storage allocation plus garbage collection created very saw-tooth pattern of storage usage. In a real storage environment it wasn't a problem ..... but in a virtual memory environment it was guaranteed to touch every virtual page ... and have very poor LRU characteristics (i.e. if you used it recently ... it might get re-assigned to totally new location and not be re-used). One of the things that had to be done for the apl/360 port to apl/cms was a storage management rewrite to make it useful for real-world problems.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K) Newsgroups: alt.folklore.computers,sci.skeptic,alt.folklore.urban,alt.folklore.military Date: 10 Feb 1999 11:44:27 -0800i've noticed what appear to be taxi way leading off into the trees at various places on roads in sweden.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K) Newsgroups: alt.folklore.computers,sci.skeptic,alt.folklore.urban,alt.folklore.military Date: 11 Feb 1999 08:31:25 -0800resilliance of runways needed to handle repeated impact of landing ... something that didn't need to be considered for roads.
even at that ... there was story about early landing approach signal at SeaTac ... and they noticed 747s landing within six feet of each other and the runway was starting to crack under the beating ... so they introduced randomization in the signal which spread touch-downs over 100 foot area.
on the other hand ... when I first drove on interstate on the east coast I noticed some with frost heave problems that was significantly worse than mountain county roads out west. the natives of the eastern state commented that it was a characteristic of the road industry in the state ... if they had actually done a 6'+ road bed initially ... then they wouldn't get paid to go out every year and repair the frost heaves.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K) Newsgroups: alt.folklore.computers,sci.skeptic,alt.folklore.urban,alt.folklore.military Date: 12 Feb 1999 12:34:50 -0800I've been told that highways may need up to 6' roadbed ... especially in frost heave situations.
A couple years ago I was at some road seminar that claimed 95+% of road and interstate wear & tear is by 18 wheelers ... that passenger cars don't exert enuf poinds per sq. inch to affect road materials ... but compression/decrompression of 18 wheelers on surface and roadbed was measurable ... and that was where almost all road wear came from (exceptions scenerios with frost heave and inadequate roadbed).
The net was that once roads were built ... almost all highway tax dollars is for repair ... and shouldn't the tax rate for repair be proportional to damage caused (<5% of total highway taxes spread across all non-18 wheeler use ... and 95+% of all highway taxes solely levied on 18-wheelers).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K) Newsgroups: sci.skeptic,alt.folklore.urban,alt.folklore.computers Date: 12 Feb 1999 14:20:17 -0800date problems posted by somebody to a newsgroup in 1984:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: You count as an old-timer if (was Re: Origin of the phrase Newsgroups: alt.folklore.computers Date: 13 Feb 1999 11:03:29 -0800• could whistle and get a 110 acoustic modem to talk back to you
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 15 Feb 1999 05:46:55 -08003270s operate analogous to restricted version of HTTP forms. There is control format for writing things to a page/screen .. output only areas, input areas, output&input areas, etc. Imagine early version of web/tv ... initially no color and no graphics, 25+ years ago, and interface between processor and controller ran at 640kbytes/sec.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Newsgroups: alt.folklore.computers Date: 15 Feb 1999 14:40:38 -0800I thot I remember being told that unpowered a 727 has absolutely no aerodynamic characterisitcs at all ... drops like a rock ... in fact there was something about early on having to change to "powered" landings for 727 because of stall danger.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Date: 16 Feb 1999 04:47:03 -0800the original 3270 was 3272 controller and the 3277 (24x80) terminal which had keyboard & other logic in the head. The 3274 controller moved much of the head logic back into the controller ... reducing the per terminal costs and introduced the 3278 (43x80 & other modes), 3279 (color and graphics), 3290(?) (flat panel).
The 3270 terminals had and annoying habit of dropping characters and locking the keyboard if you happened to be typing a character at the very moment that there was a write to the screen. Repeat and cursor positioning speeds were also maddening slow. On the 3277, because the logic was in the head ... some user modifications were possible ...
1) little soldering on the board inside the keyboard and you adjust the repeat delay, repeat rate, and cursor positioning speeds. It was actually possible to overdrive the repeat rate so that the screen update fell behind the keyboard repeat ... it took a little practice to position the cursor under a specific character ... since the cursor would continue to move for several positions after you lifted the cursor positioning key.
2) FIFO box inserted between where the keyboard plugs into the head which eliminates drop character and keyboard lockup.
It wasn't possible to fix the 3274-based terminals because the logic had moved back into the controller.
The 3270 card for the IBM/PC offered the opportunity to do some creative programming to enhance the user interface characteristics.
In the early 80s my brother was a regional apple sales rep. I attended dinners with the mac developers during the early mac period ... and getting into heated arguments about tainting the "kitchen table only" machine with something as unthinkable as a terminal emulator (3270) adapter
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: You count as an old-timer if (was Re: origin of the phrase Newsgroups: alt.folklore.computers Date: 17 Feb 1999 07:06:52 -0800highly skilled programmers working closely with the customer on day to day basis over extended period of time ... developing software that exactly met the needs and refining as necessary in live production work ... frequently resulted in solutions that better met customer requirements than something done at some central site by people hypothesising what the actual requirements might be.
the crux with the vast amounts of IBM people in the field doing customer software apps was June 23rd, 1969 .... what was that date?
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: You count as an old-timer if (was Re: origin of the phrase Newsgroups: alt.folklore.computers Date: 17 Feb 1999 14:16:55 -0800june 23rd, 1969
government got ibm to unbundle hardware, software, services, etc. ... now if somebody was at customer site or doing something for a customer it was billed time to the customer , phone calls became billed time, everything, pretty much got broken out into billed time. all the friendly people helping the customer disappeared and replaced with cash registers that kept going ding, ding, ding, ding, ding, ding.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Computers Newsgroups: alt.folklore.computers Date: 18 Feb 1999 16:44:56 -0800worked with the engineers over the disk development lab in the late 70s ... they were running standalone environment and using OLTEP and other stuff to exercise disks that they were developing.
problem was that typical mean-time between failures in that environment was something like 15 minutes for MVS. Environment was dozen or so disk engineering "test cells" (each engineering device was inside a steel wire cage that contained combination lock ... dozen of these cages on the machine room floor, each with own engineering device).
They tended to have the largest, newest mainframe processor (in order to test that the cpu worked with the disks)
I worked on building an absolute bullet proof i/o subsystem so that no single test cell or combination of test cells would crash the operating system. That allowed them to concurrently test all test cells ... instead of having to schedule dedicated machine time. Simultaneous testing of all test cells would utilize maybe 5% of a processor ... at the most. The rest of the processing power then was available for working on interesting problems.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Roads as Runways Was: Re: BA Solve Newsgroups: alt.folklore.computers Date: 20 Feb 1999 10:24:57 -0800i did a stint at boeing (during the dawn of BCS) ... back when the 747s were being introduced and the marketing claim that a 747 would alwas be serviced by at least four jetways ... serial #3 would be periodically seen flying thru skys of seattle.
the story I remember was that tex barrel-rolled both 707 and 727 coming off of renton field. a "problem" was that these were test configurations ... 50 gal drums in place of passenger seats; complex set of pipes and pumps would move water into different drums to test all sort of weight distribution configurations ... in any case, the barrel rolls tore a lot of this loose and there was lot of repair that had to be done.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: why is there an "@" key? Newsgroups: alt.folklore.computers Date: 26 Feb 1999 08:01:44 -0800CSC did cpremote ... something like hasp for cp/67 ... and then what became vnet. i believe one of the first vnet links was cambridge to endicott ... in support of the virtual 370 relocate project (modify a version of cp/67 to provide virtual 370 machines ... which had different relocate architecture than 360/67, and then do another modification of cp/67 that ran on 370 relocate hardware ... at cambridge there was "3.1l" running on the bare hardware ... pretty vanilla cp/67 ... in part because of security concerns because it had general users ... even MIT students using the system ... then in a virtual 67 run "3.1h" ... which ran in virtual 360/67 machine ... but provided virtual 370 machines ... then in a virtual 370 machine run "3.1i" ... which was a modification of cp/67 running on 370 relocate hardware architecture ... this was all done and in regular use a year before there was a real 370 engineering hardware that could be booted/ipled).
i believe the internal vnet was larger than the arpanet/internet from nearly its start up until sometime in the mid-80s.
i believe that vnet was one of the first things that had a truely layered architecture and implementation. This was used extensively to allows JES systems to participate in the internal network. JES networking started out mapping network nodes into the HASP 99-entry table (network nodes had to share entries with spool & real device entries ... so might only have 30 entries available). Later this was expanded to 255-entries and then to 999-entries ... however at all times the internal network had more nodes that could be mapped by JES table. As a result, JES nodes were regulated to end nodes ... because they had bad habit of discarding traffic involving nodes (either source or destination) that weren't in their local table.
The other JES problem is that they confused the network driver with the rest of the system function. As a result, one release of JES could cause other releases of JES (and the whole operating system) to crash by sending data with slightly different headers.
As a result, a VNET system might be deployed with a wide range of drivers ... standard VNET-to-VNET driver as well as a variety of JES drivers ... to handle different JES versions as well as doing JES protocol release-to-release translation to prevent JES subsystems ... and JES based operating sysetms from crash & burn (i.e. instances of modified JES systems on the west coast causing JES machines in europe to crash & burn ... because the west coast system had modified JES and moved a couple header byte definitions around and then tried to send europe some data).
in the mid-80s my wife and i ran skunk works ... one of the things was something we called high-speed data transport ... with a backbone that part of internal traffic was carried over. at the time of NSFNET1 RFP ... we attempted to get permission to bid and weren't allowed. We did get a technical audit by NSF that said what we were operating was at least five years ahead of all bid submissions (to build something new). I had done a number of things in the implementation ... included rate-based flow & congestion control ... something that they are now looking at for Internet2 (so maybe it was more than five years ahead).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: why is there an "@" key? Newsgroups: alt.folklore.computers Date: 26 Feb 1999 08:59:18 -0800one of the problems with vnet implementation was that it was store&forward and used the cp/67-vm/370 "spool" file system interface ... which included problems like synchronous filesystem semantics (a vnet node frequently bottlenecked somewhere between 20kbytes-40kbytes per second aggregate thruput ... primarily because of synchronous semantics at the disk interface).
for HSDT did a virtual passthru driver that would support local node store&forward bypass (i.e. end-to-end transmission). This eliminated problem with synchronous semantics at intermediate nodes.
for HSDT I also did a port of the "spool" filesystem to a virtual machine subsystem, completely rewritten in pascal and featured asynchronous semantics, block/contiguous allocation for large files, high-level multi-data block pointers (supporting multi-block read/writes), low-level forward/backward block threading for filesystem disaster recovery, and multi-device spool filesystem independence (large installation would have spool filesystem spread across large number disks ... failure of any single disk would corrupt/crash whole infrastructure).
hsdt had to deal with both intermediate and end nodes sustaining mbyte thruput rates ... 50-100 times (or more) what a typical vnet was capable of.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: why is there an "@" key? Newsgroups: alt.folklore.computers Date: 26 Feb 1999 09:13:39 -0800pr*fs had picked up source (about 60klocs of 370 assembler) of prerelease .8 or so of something called VMSG ... and wrappered their own command & gui interface around the feature/function ... and then claimed they had done the whole thing. One of the stoppers was that all VMSG based implementations had the author's initials in comment/unused control fields of all messages.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: why is there an "@" key? Newsgroups: alt.folklore.computers Date: 26 Feb 1999 10:56:27 -0800sligthly related
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: why is there an "@" key? Newsgroups: alt.folklore.computers Date: 26 Feb 1999 14:23:36 -0800ctss carried over to 2741 on cms had "@" as the character erase and "cent-sign" as line erase ... "@" and "cent-sign" were on the same key ... right-most key in the u-i-o-p row ... just above home position ... "@" as lower-case of the key ... "cent-sign" was upper-case ... so one or more "@" deleted one or more characters ... upper-case "@" ... i.e. "cent-sign" deleted the whole line.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subjet: Internet and/or ARPANET? Newsgroup: alt.folklore.computers Date: 01 Apr 1999reposted ... originally 31dec1998 alt.folklore.computers
not so much from technical standpoint but
... arpanet/telenet/tymnet -> csnet -> nsfnet -> internet
my wife and I were effectively (a?) red team on both nsfnet1 and nsfnet2
... weren't actually allowed to bid (although nsf technical audit of
backbone my wife and I operated claimed what we were running was at
least five years ahead of submitted bids ... to build something new).
Date: 10/22/82 14:25:57
To: CSNET mailing list
Subject: CSNET PhoneNet connection functional
The IBM San Jose Research Lab is the first IBM site to be registered on
CSNET (node-id is IBM-SJ), and our link to the PhoneNet relay at
University of Delaware has just become operational! For initial testing
of the link, I would like to have traffic from people who normally use
the ARPANET, and who would be understanding about delays, etc.
If you are such a person, please send me your userid (and nodeid if
not on SJRLVM1), and I'll send instructions on how to use the
connection. People outside the department or without prior usage of
of ARPANET may also register at this time if there is a pressing need,
such as being on a conference program committee, etc.
CSNET (Computer Science NETwork) is funded by NSF, and is an attempt
to connect all computer science research institutions in the U.S. It
does not have a physical network of its own, but rather is a set of
common protocols used on top of the ARPANET (Department of Defense),
TeleNet (GTE), and PhoneNet (the regular phone system). The
lowest-cost entry is through PhoneNet, which only requires the
addition of a modem to an existing computer system. PhoneNet offers
only message transfer (off-line, queued, files). TeleNet and ARPANET
in allow higher-speed connections and on-line network capabilities
such as remote file lookup and transfer on-line, and remote login.
... snip ... top of post, old email index
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp Date: 02 Apr 1999 08:47:54 -0800jmfbahciv writes:
looking at it from other facet ...
.. misc rfcs:
894 - Standard for the transmission of IP datagrams over Ethernet
networks 1984/04/01
826 - Ethernet Address Resolution Protocol: Or converting network
protocol addresses to 48 bit Ethernet address for transmission on
Ethernet hardware .. 1982/11/01
791 - Internet Protocol 1981/09/01
761 - DOD Standard Transmission Control Protocol 1980/01/01
739 - Assigned Numbers 1977/11/11
.... misc IEN:
IEN#1 - Issues in the Interconnection of Datagram Networks 1977/07/29
IEN#3 - Internet Meeting Notes 1977/08/15
IEN#5 - TCP Version 2 Specification 1977/03/
IEN#10 - Internet Broadcast Protocols 1977/03/07
IEN#11 - Internetting or Beyond NCP 1977/03/21
IEN#14 - Thoughts on Multi-net Control and Data Collection Factilities
1977/02/28
... and from IEN#16:
IEN # 16 Network Working Group Jon Postel Request for Comments: 730 USC-ISI NIC: 40400 20 May 1977 Section: 2.2.4.2 Extensible Field Addressing Introduction This memo discusses the need for and advantages of the expression of addresses in a network environment as a set of fields. The suggestion is that as the network grows the address can be extended by three techniques: adding fields on the left, adding fields on the right, and increasing the size of individual fields. Carl Sunshine has described this type of addressing in a paper on source routing [1]. Motivation Change in the Host-IMP Interface The revised Host-IMP interface provides for a larger address space for hosts and IMPs [2]. The old inteface allowed for a 2 bit host field and a 6 bit IMP field. The new interface allows a 8 bit host field and a 16 bit IMP field. In using the old interface it was common practice to treat the two fields as a single eight bit quantity. When it was necessary to refer to a host by number a decimal number was often used. For example host 1 on IMP 1 was called host 65. Doug Wells has pointed out some of problems associated with attempting to continue such usage as the new interface comes into use [3]. If a per field notation had been used no problems would arise. Some examples of old and new host numbers are: Host Name Host IMP old # new # -------------------------------------- SRI-ARC 0 2 2 2 UCLA-CCN 1 1 65 65537 ISIA 1 22 86 65558 ARPA-TIP 2 28 156 131100 BBNA 3 5 197 196613 Multinetwork Systems The prospect of interconnections of networks to form a complex multinetwork system poses additional addressing problems. The new Host-IMP interface specification has reserved fields in the leader to carry network addresses [2]. There is experimental work in progress on interconnecting networks [4, 5, 6]. We should be prepared for these extensions to the address space. The addressing scheme should be expandable to increase in scope when interconnections are made between complex systems.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 1968 release of APL\360 wanted Newsgroups: comp.lang.apl,comp.sys.ibm,alt.folklore.computers Date: 04 Apr 1999 10:44:12 -0700might find a flavor of it on one of the VM user group archives. Early '70s, CSC ported APL/360 to CP/67-CMS, eliminated the monitor & other multi-user stuff (since CP/CMS provided that part), opened up the workspace to 24bit, rewrote garbage collect (original apl/360 memory management never re-used storage ... alwas allocated new slot for assignment, when it got to end of workspace it collapsed everything back to low-memory (not too bad on 32kbyte workspace but running even a small program in 16mbyte workspace could be disasterous), and added stuff to interface to external things (like doing file i/o).
The last kick off big ruckus between cambridge science center and the phili science center (where falkoff was) ... which eventually lead to "shared variables" ... as paradigm for accessing external features.
The cms/apl version of apl/360 had significant more usage and wider distribution than the original apl/360. One of the major applications was on HONE which not only provided all the online support for field people (sales, marketing, SEs, CEs, branch, etc) ... but was also main stay of corporate hdqtrs for planning, forecast, business management, etc aspects.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp Date: 07 Apr 1999 23:34:58 -0700re: RFCs available ...
see the RFC index at https://www.garlic.com/~lynn/
many of the IENs are available as either IEN files or RFC files.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp Date: 08 Apr 1999 00:17:37 -0700re: files
for some related information see rfc2555 just released today
files can be found at ftp.isi.edu ... rfcs in directory in-notes (which is where my rfc index points to retrieve the actual rfc). iens can be found in directory in-notes/ien. just checking ien-index.txt might be of some interest to see the IP evoluation from 77 to 82.
from ien111:
August 1979 IEN: 111 Replaces: IENs 80, 54, 44, 41, 28, 26 Internet Protocol Specification 1. INTRODUCTION 1.1. Motivation The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks. Such a system has been called a "catenet" [1]. The internet protocol provides for transmitting blocks of data called datagrams from sources to destinations, where sources and destinations are hosts identified by fixed length addresses. The internet protocol also provides for fragmentation and reassembly of long datagrams, if necessary, for transmission through "small packet" networks. 1.2. Scope The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to promote data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. 1.3. Interfaces This protocol is called on by host-to-host protocols in an internet environment. This protocol calls on local network protocols to carry the internet datagram to the next gateway or destination host.For example, a TCP module would call on the internet module to take a TCP segment (including the TCP header and user data) as the data portion of an internet datagram. The TCP module would provide the addresses and other parameters in the internet header to the internet module as arguments of the call. The internet module would then create an internet datagram and call on the local network interface to transmit the internet datagram.
In the ARPANET case, for example, the internet module would call on a
local net module which would add the 1822 leader [2] to the internet
datagram creating an ARPANET message to transmit to the IMP. The
ARPANET address would be derived from the internet address by the
local network interface and would be the address of some host in the
ARPANET, that host might be a gateway to other networks.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet (TM) and USPTO Newsgroups: comp.protocols.tcp-ip.domains,misc.int-property,misc.legal,alt.folklore.computers Date: 08 Apr 1999 13:09:34 -0700bitnet (and its european cousin, earn) was a corporate sponsored network for universities ... somewhat similar to nsfnet's sponsored csnet. bitnet was based on technology from the corporate internal network ... the courporate internal network was larger than arpanet/csnet/nsfnet just about from day one thru about mid-80s (possibly one of the biggest factors in arpanet/csnet/nsfnet exceeding the corporate internal network in size were workstations that started to come into vogue in the early '80s ... while the internal corporate network remained mainframes, thousands of machines with hundreds of thousands of users).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp Date: 08 Apr 1999 14:58:15 -0700the IEN documents imply that what they were working on in the 77-80 time-frame was an "internet protocol" (IP) for infrastructures referred to as multinetwork systems (IEN-16) and catenet (ien-32).
both an "internet protocol" layer (ien-111) and "gateway" (ien-32) are integral components of being able to accomplish multinetwork systems.
from ien-32 ...
CATENET MONITORING AND CONTROL:
A MODEL FOR THE GATEWAY COMPONENT
John Davidson
Bolt Beranek and Newman, Inc.
IEN #32
Internet Notebook Section 2.3.3.12
April 28, 1978
Catenet Monitoring and Control:
A Model for the Gateway Component
1. INTRODUCTION
At the last Internet meeting, some concern was expressed
that we don't have a real "model" for what a gateway is, what it
does, and how it does it, and that without such a model it is
somewhat dificult to describe the kinds of activities which
should be monitored or controlled by a Gateway Monitoring and
Control Center (GMCC). To respond to that concern, we have
written this note to express our recent thoughts about a gateway
model. Although the note centers primarily around the topic of a
gateway model, we have also included a few thoughts about
possible models for the other components of a general
internetwork structure.
The note proceeds as follows. In Section 2 we try to
establish a reason for wanting a model of a given internetwork
component, and present a brief overview of the potential benefits
of Monitoring and Control. This presentation is largely
pedagogical since it is assumed that this document will, for a
while at least, be the only introduction to the topic available.
In Section 3 we discuss the fundamental kinds of activities
which must be performed by any internet component if it is to
participate in Monitoring and Control. This section establishes
motivation for some of the mechanisms discussed in the rest of
the paper.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers Date: 12 Apr 1999 15:31:39 -0700somewhat digression
many/most of the networking protocols seemed to assume a relatively homogeneous environment ... i.e. arpanet with the IMPs providing connectivity.
IEN (internet) work in the 77/78 timeframe resulted in gateways and a "internet" layer (i.e. prior references to various IEN documents).
with ISO defining level3/network and level4/transport ... the internet layer effectively fit someplace in-between ISO level3/level4.
this is similar to the internal corporate network (corporate time-sharing product and the corporate network technology ... which later was used in bitnet and earn) was done starting in the late 60s in 545 tech. sq (in some extent shared common heritage with multics back to ctss) ... which effectively had a gateway layer implemented at ever node. That in part was responsible for the corporate network being larger than the arpanet/internet from almost the beginning up thru mid-80s (the other was the corporate time-sharing system that also originated at 545 tech. sq. was running on a couple thousand internal corporate mainframes). One of the things that drove the arpanet/internet passed the internal corporate network was advent of workstations as nodes.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [netz] History and vision for the future of Internet - Public Question Newsgroups: alt.internet-media-coverage,alt.culture.internet,alt.folklore.computers,news.misc,sci.econ,comp.org.ieee,alt.culture.usenet Date: 13 Apr 1999 16:07:01 -0700somewhat conjecture ... is that NSFNET1 contract covered possibly 1/4th to 1/10th the resources put into NSFNET1 ... the rest put in by commercial corporations. Conjecture on my part is huge amount of dark fiber laying around ... and necessary to break checken/egg situation at the time with few apps to use the bandwidth, tariffs at the time were barrier to new apps that might be evolve to use the bandwidth. Strategy was to make significant bandwidth available as seed environment that applications could evolve that would eventually be able to utilize the excess capacity. While ARPANET activity has some technology/protocol relationship to current Internet ... the huge resources provided by commercial entities starting (at least) with NSFNET1 ... significantly define the current Internet infrastructure (in that sense ... commercialization happened over ten years ago).
Interop '88 had lots of vendors and loads of academic/arpanet people that had or were in the process of making transition to commercial companies.
folklore trivia question .... what was causing floor-net meltdown on sunday before Interop '88 started (and led to configuration option that is now required in all tcp/ip implemenations).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A word processor from 1960 Newsgroups: alt.folklore.computers Date: 15 Apr 1999 16:20:23 -0700I did something much simpler and later ... in 1968, I took the 2250 library that lincoln labs had ported to CMS ... and crafted it as device for the CMS context editor (somewhat evolved from CTSS editor) to support full screen operation
It was a 2250m1 graphics display ... mainframe channel attached that ran at a couple hundred kbytes/sec.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Enter fonts (was Re: Unix case-sensitivity: how did it originate? Newsgroups: alt.folklore.computers Date: 16 Apr 1999 16:53:27 -0700the precursor of SGML/HTML was GML (generalized markup language ... acronym were actually a hack on the three peoples last names) done at the cambridge science center and implemented in the cms script processor in the late 60s and early 70s. the script processor was ported to a number of other environments and (at least in the ibm mainframe world) could use output devices like the 3800 and the 6670 (san jose research hacked what was essentially an ibm copier3 with a computer interface to create the 6670 ... it was the first computer output device that I used that directly supported printing on both sides of the paper). There was general deployment of 6670s and the associated support by at least 1979.
Earlier implementations of font changes on 2741, ibm typerwritters and ibm word processors was achieved by manual switching of the typeball, in fact the early 3800/6670 font change processing relied on using the existing script font/typeball change processing.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Enter fonts (was Re: Unix case-sensitivity: how did it originate? Newsgroups: alt.folklore.computers Date: 16 Apr 1999 16:53:27 -0700the precursor of SGML/HTML was GML (generalized markup language ... acronym were actually a hack on the three peoples last names) done at the cambridge science center and implemented in the cms script processor in the late 60s and early 70s. the script processor was ported to a number of other environments and (at least in the ibm mainframe world) could use output devices like the 3800 and the 6670 (san jose research hacked what was essentially an ibm copier3 with a computer interface to create the 6670 ... it was the first computer output device that I used that directly supported printing on both sides of the paper). There was general deployment of 6670s and the associated support by at least 1979.
Earlier implementations of font changes on 2741, ibm typerwritters and ibm word processors was achieved by manual switching of the typeball, in fact the early 3800/6670 font change processing relied on using the existing script font/typeball change processing.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers Date: 17 Apr 1999 10:16:03 -0700re: homogeneous/heterogeneous
I was thinking in terms of the networking hardware and the protocol being homogeneos. the end-point host machines (might be heterogeneous) were attached to the IMPs and the IMPs managed the network protocol. The 360s (lincolns '67 and UCLA's '91) would have an IBM telecommunication controller (2702 or 2701) which would then talk to the IMP.
ibm360s had interesting problems interacting with a ascii-based infrastructure ... in part because of the ebcdic/ascii character translation.
I had written tty/ascii support for CP/67 while I was an undergraduate
(circa 68) that IBM shipped to customers in CP/67 (VanVleck
immortalizes a y2k-type calculation "bug" at
https://www.multicians.org/thvv/360-67.html,
since ttys were limited to 72 characters ... i did message transfer
information using one-byte/255 values; since cp/67 was shipped
w/source it was relatively straight-forward to modify it to support
devices that did transfers longer than 255 ... but they didn't change
my one byte code stuff ... as a result calculations resulted in bad
lengths and resulted in data operations off the end of the buffer,
which corrupted stuff leading to system failure).
About the same time (late '68) ... a couple of us at the university built a replacement (using our own minicomputer) to replace the 2702 communication controller (which is supposedly credited with originating the ibm OEM controller business). One of the reasons was that we had original thot it was possible to dynamically associate different line scanners with different lines (i.e. dynamically determine protocol at time of modem connection on dial-up lines). It turned out it almost work except IBM had taken short-cut and hardware strapped the oscillator to a line ... so dynamic switching of line scanner worked as long as all protocols operated at the same bit rate. In any case, one of the things we implemented was strobbing of bit raise/lower signal to support dynamic speed recognition.
Back to the ebcdic/ascii problem ... ebcdic is a 256bit code and ascii is a 127bit code ... and even tho ebcdic had more bit positions ... there were also ascii characters that were not defined in ebcdic (as well as vis-a-versa). Typically, character translation was done at the 360 from ebcdic->ascii (on outgoing) and ascii->ebcdic (on incoming) ... so the ascii network didn't have to worry about dealing with non-ascci machines (it was done in the 360 host). Defining the in-bound and out-bound character translation tables got to be tricky.
in any case, the arpanet started out protocol, hardware, and character set homogeneous ... with some of the end-point hosts (360s, with different character set) trying to simulate homogeneous operation.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers Date: 17 Apr 1999 15:21:59 -0700... from a slightly different perspective I know somebody that as a UCSB undergraduate was hired by ARPA to do host/network penetration studies prior to turning ARPANET on ... a couple years ago she observed that after nearly 30 years she could still penetrate a number of todays systems.
unless prepared it is hard to only fake strong-arm tactics.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers Date: 17 Apr 1999 18:41:17 -0700... slightly related ... at least with regard to not being able to trap ICMPs associated with specific sessions at the application ... being a tcp/ip "bug".
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?) Newsgroups: comp.arch Date: 16 Apr 1999 11:26:41 -0700for service based applications ... where the design point is that operation runs continuously with no human present ... the exception code for service operation can easily be 4* as much as the code supporting traditional straight-forward implementation ... frequently there are numerous domain specific exceptions and domain specific exception processing so that it is necessary to handle them in the application (and not take the default of the infrastructure).
... and of course my motherhood statement ... many of the infrastructures that grew up out of "batch" systems tend to be richer in their support of exception since the design point assumption was there wasn't a person directly connected to the application for operation (as compared to infrastructures that grew-up out of desk-top and/or interactive environments that had design point assumptions that a person might ultimately deal with the situation).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?) Newsgroups: comp.arch Date: 16 Apr 1999 13:19:41 -0700... oh yes, trivial example.
in the summer of '95 i got to diagnose an epidemic system failure at a large service provider. turned out to be the machine(s) were crashing with resource exhausion because of large number of half-open sessions (almost exactly to the day, a year prior to the denial of service attack problem hit the press in the summer of '96).
in any case, ... it reminded me of network services deployed 20+ years early that trap/caught similar error condition and appropriately released the resources. However, ... there was no way that I could set a trap on a tcp/ip half-open session so that all associated ICMP errors (like port not available and host not reachable) specific for that half-session. From a service offering stand-point, I consider that an error in both the tcp/ip implementation as well as in the protocol (regardless of the architecture purity appearance of the protocol).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?) Newsgroups: comp.arch Date: 16 Apr 1999 13:30:17 -0700oops, 2nd trivial example ... also from '95.
one of the web/browser companies had developed a lot of code that would support server's doing web financial transactions. they had done all the straight-line function and extensively stress-tested the code.
I went in with a failure-mode grid of 30-40 conditions and 4-5 states and required that the server being able to recognize and take some appropriate action (although as mentioned ... things like half-open session traps were outside the capability of the infrastructure and needed recommendations for other approaches for handling).
In any case, there was essentially 4* as much effort to try and turn the application into a service-quality implementation as went into the straight-forward base function.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Living legends Newsgroups: alt.folklore.computers Date: 18 Apr 1999 09:45:31 -0700well then what are 013, 813, A13 ...
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers Date: 18 Apr 1999 09:55:18 -0700Joel Winett at Lincoln did a number of early RFCs ... somewhat related to the '67 ... unfortunately most of them aren't online:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Enter fonts (was Re: Unix case-sensitivity: how did it originate? Newsgroups: alt.folklore.computers Date: 18 Apr 1999 13:40:37 -0700re: 6670 stories & off topic;
in 77/78 time-frame, 2 of the 3 people responsible for GML, the person responsible for the internal network, and I transferred from 545 tech sq (csc) to sjr.
into the 6670 line-driver went the obvious support using the alternate paper draw to print the file-seperator page (typically loaded with green or blue paper). To make the file-seperator page a little more interesting ... a feature called "6670 sayings" was added ... where the line driver randomly selected a quotation that was printed following the file ownership information.
SJR was having a security audit ... and the auditors were roaming around buildings after hours looking to see if there was classified information left out. One of the areas of interest was the 6670 output rooms to see if there was classifed information printed and left out (not immediately picked up). On the top of one 6670 was a pile of output ... the top file having a seperator page with the definition of an auditor being a person that goes around the battlefield after a war stabbing the wounded. The auditor took it as personal insult & that somebody had placed it on top the 6670 specifically to make a statement about the character of auditors. Some amount of time was spent trying to identify the individual responsible for the insult to auditors.
Lots of stuff used to be sent to me (back in the late '70s when global networking was new & fresh it was exciting to be processing hundreds of messages a day, ... as an example somebody had sent me the fortran source for adventure that compiled on cms ... within three months of adventure showing up at stanford ... one corporate type once claimed that they had statistics that for some months they could blame me for upwards of 30% of all traffic on all links on the whole internal network).
One year, the last week in march, somebody from an unnamed east coast location sent me a "corporate memo" dated April 1st (which was on sunday) that claimed to be a corporate password security memo outlining 10-15 rules for password selection. The memo concluded that there was only a single alphanumeric string that met all the criteria and each individual was to contact their local security officer to obtain that password. The first thing Monday morning (april 2) ... all the corporate bulletin boards in the building had a copy of the memo printed on corporate letterhead (and i wasn't responsible and/or had prior knowledge).
By noon, quite a storm was brewing ... not withstanding the content of the memo ... the date of the memo (april 1st) ... or that the date was sunday (and corporate memos are never issued on sunday) ... a very large percentage of people didn't realize it was an april 1st memo, and got quite angry when it was pointed out. After much investigation, the final outcome was that all corporate letterhead paper was to be moved from open shelves in the 6670 print rooms to locked cabinets.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internet and/or ARPANET? Newsgroups: alt.folklore.computers Date: 18 Apr 1999 14:39:01 -0700re: multics/cms ... off topic;
with respect to tom's comments at
https://www.multicians.org/thvv/360-67.html
about one of the reasons that multics started on the new file systems
being poor comparison with cp/67 ... taking hour to restart the system
(mostly in recovering the file system) ... while cp could crash 27
times in a single day ... restart and still have people getting
useful work done.
cms filesystem made all filesystem changes to blocks that were written to "versioned/new" locations ... and then at periodic syncs the single MFD block would be rewritten which reflected the new locations for changed filesystem blocks. Except for one problem ... the filesystem on disk was alwas consistent ... it was either the old version (before the MFD was rewritten) or the new version (after the MFD was rewritten).
There was a file system scramble problem if there was a power failure exactly at the instant the MFD was being written ... there could be scrambled bits in the MFD (there were no intermediate disk buffers ... all data being written was coming directly from processor memory, there would be sufficient power to complete the write ... but not enuf power to maintain processor memory ... could to result in disk writes with trailing zeros in a block ... and valid CRC ... i.e. no error indication on read).
In the 70s, a cms enhanced file system was done that had a pair of MFD record locations that writes would ping/pong to (that fixed the power failure write problem). On restart, both MFDs would be read, checked for consistency and then the consistent MFD for the most recent version would be used.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Fault Tolerance Newsgroups: comp.arch,alt.folklore.computers Date: 18 Apr 1999 17:31:06 -0700both my wife and I had done mainframe cluster stuff in the 70s and then in the 80s ran skunkworks where we did HA/CMP and fiber-channel scale-up (precursor to SP1/SP2, was going to start at 128-way). you would be surprised at the people now espousing clusters that we had to battle with at the time.
one of the bag of tricks for ha/cmp was ip-address take-over ... required that MAC addresses be aged out of the client ARP-caches. Turned up a bug in reno/tahoe (a lot of the products/systems then were built on reno/tahoe) ... the IP code had a one-address MAC as a special speed-up ... if new packet was the same ip-address as the previous ip-packet ... it would use the previously saved MAC address and not call the ARP code.
for some common client sysems that frequently interacted with a single server over & over ... the ip/mac address would never change regardless of the rules/processes flushing the ARP-cache. work-around was for ha/cmp to ping all clients it could find ... from a totally different ip-address ... in order to get the ip routine to change the hidden MAC address.
then there are counter examples. in the late 70s, i was also playing around in the disk engineering labs ... they had all these mainframe processors dedicated to disk testing (and were significantly under-utilized). If they tried to do concurrent testing of multiple test-cells (there was lots of security around disk development ... final level being individual units in small steel-mesh cages ... maybe 4' sq and 7' high with combination locks ... called test-cells) under an operating system ... it had MTBF of about 15 minutes (engineering disks tended to have some rather random & severe error modes). I redesigned and rewrote input/ouput supervisor so that it would never fail ... even if there were 6-12 test cells as well as normal operating system use happening concurrently. The resulting code was actually smaller than when I started (as well as much shorter path length). Of course the secret was that the code had evolved incrementally over a number of years ... and it was way overdue for redesign and cleanup.
The upside ... were the processors were maybe 5% used ... even with dozen test cells ... and the other 95% could be put to interesting uses. The downside ... I had to learn something about disk engineering ... when the disk testing didn't produce the correct results ... it wasn't uncommon for the operating system to be blamed ... I would have to go in and figure out what and heck they were doing.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Modem history [was ba.b: Re: Gender Gap's Wildest Show!!! Tonight!!!] Newsgroups: ba.broadcast,alt.folklore.computers Date: 18 Apr 1999 23:10:51 -0700from alt.folklore.computers, re: Internet and/or ARPANET
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Living legends Newsgroups: alt.folklore.urban,alt.folklore.computers Date: 19 Apr 1999 07:11:01 -0700re: 001;
there was one of those darn things sitting on file cabinet next to the 709 (serial #2?) ... never had to use it tho except to fiddle with it while i was waiting for something else.
what i don't have a strong recollection of ... but wasn't there something of similar shape that CEs used on 360 capacitor ROM
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Living legends Newsgroups: alt.folklore.urban,alt.folklore.computers Date: 19 Apr 1999 07:23:18 -0700how 'bout all those little tools in the CE toolkit for working on selectric typewriters ... I ordered a CE tooklit once because I wanted to keept a set of tools in my office for working on things ... but maybe half of the stuff in the briefcase i never used (it also took me several weeks to week the order accepted ... apparently you just don't have people ordering one of those things).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When did IBM go object only Newsgroups: alt.folklore.computers Date: 21 Apr 1999 22:00:54 -0700VM/CMS would ship the exact source that created the running system build.
there is the story about a request for the exact source that corresponded to (any) particular running system for MVT (applies to mvs & vse later). supposedly it was decided to be infeesable when the running cost estimate exceeded $10m (and climbing) ... even for a one time effort. there apparently was no straight-forward way of correlating the program listings cut for microfiche and the shipped executable code.
one of the significant dates was june 23rd, 1969 ... that was the unbundling of services. Prior to that date, IBM tended to have large numbers of people at customer sites, helping the customer get their work done. The result frequently was the creation of applications that were useful to the customer (since they evolved with close participation of the customer to meet the customer needs) ... at least HASP (JES2), ASP (JES3), IMS, and CICS originated from such customer environments. june 23rd, 1969, IBM started billing the customer for all time these ibm'ers spent with the customer ... and the sense of joint, close-cooperation evaporated.
There is somewhat offhand comments that the real IBM development groups were the customer shops ... where new (successful) application creation and development actually occurred. Such applications were then frequently transferred to IBM Development organizations (which actually didn't originate or develop things ... they were responsible for maintaining things and keeping them running over the years after they had been developed someplace else).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Living legends Newsgroups: alt.folklore.urban,alt.folklore.computers Date: 22 Apr 1999 09:25:40 -0700my first programming job when I was a sophomore was to effectively write my own stand alone operating system that replaced the 1401 MPIO (unit-record<->tape) front-end process for 709 ... with a 360/30.
The 360/30 replaced the 1401 and the 7track tapes, 2540reader/punch, and 1403 printer were moved from the 1401 to the 360/30. I designed & wrote my own task switcher, interrupt supervisor, device drivers, command functions, storage manager, buffering, etc. Was eventually about a box of cards (around 2000 360 assembler statements).
The easy stuff was the BCD stuff since EBCDIC was a superset ... the harder stuff was the binary ... since it was 36bit word rather than 32bit word ... and the cards could punch all 12 rows (which was invalid in 360, a column with all 12 holes punched couldn't be represented in a single 360 8bit byte). The 360 compatibility devices had a column binary feature that would map 80 columns of data into 160 (360) byte positions.
The standard for reading cards ... was to do a read/fead/select stacker ... all in a single operation. The problem was knowing ahead of time whether a card was bcd or binary. To get around the problem, you had to do a card read (no fead) in standard ebcdic ... and if there was an error, reread the card in column binary. What I tried to do was to be able to do the buffer/tasking necessary to do card->tape at full card reader speed while concurrently doing tape->printer at full printer speed.
I look back now ... what I wrote then is about the size of what is going into some of the smaller chipcards.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Living legends Newsgroups: alt.folklore.urban,alt.folklore.computers Date: 22 Apr 1999 12:07:36 -0700all of my 360 cards from the 60s and 70s are green
... i have a 360/67 specific card that is blue ... but i don't have any 360 cards that aren't green.
i have some 370 cards from the 70s that are yellow.
long ago I did an ios3270 version of the green/yellow card ... which should translate easily into html (i don't have a copy ... maybe somebody else does).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Living legends Newsgroups: alt.folklore.urban,alt.folklore.computers Date: 22 Apr 1999 12:30:02 -0700a side question ... does anybody know if the service processors are still vm machines running cms ... with all the service screens IOS3270.
the first such service processor implemenation of that was 3090 ... with two repackaged 4361s (for redundancy) ... both running a modified version of VM/370 release 6 and all the service screens done in cms IOS3270.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Living legends Newsgroups: alt.folklore.urban,alt.folklore.computers Date: 22 Apr 1999 19:36:40 -0700these are the display interface or the service processors?
the service processors contained the diagnostic logic and probe connections into the machine to diagnose failing characterisitcs (or do the machines even have a separate service processors). The modified 4361s had modifications so that they had special hardware probes into all parts of the machine to diagnose hardware failures and identify things like what part should be replaced.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: System/1 ? Newsgroups: alt.folklore.computers Date: 01 May 1999 17:51:54 -0700sure you don't mean series/1 ... someplace I had around the original "peachtree" specification document ... before it shipped to customers. it had a tremendous interrupt architecture and numerous people tried to get it designated the mainframe telecommunication controller (instead of the uc.5/37xx ... uc.5 was also used in the ibm 8100 and various other controllers).
the "official operating system" was called RPS ... the joke was that the former MFT group from kingston moved to boca and wrote MFT a 2nd time around ... it was difficult since peachtree was a 16bit minicomputer and cramming MFT into the machine didn't really go well.
the commonly used system for the Series/1 was EDX which was done by some physicists at ibm san jose research for the process control & lab instrumentation environment. S/1 picked up quite a bit of the ibm 1800 and ibm system/7 market segment.
IBM palo alto center ported both unix and locus to s/1 in 80s.
The S/1 started seeing use in the 80s for telecommunication operation. A T1 card was also done for the S/1 in the 80s for telecommunication environment. The 37xx couldn't touch the T1 speed ... and the only official controller supporting T1 was 2701 from the 60s ... and was getting a quite long in the tooth. In any case, S/1 started to see a lot more use in the telecommunication area thru the 80s.
in serveral cases it competing against a perkin/elmer box that was being sold as a telecommunication controller (which traces a lineage back to some undergraduate work some of us did in the 60s).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old naked woman ASCII art Newsgroups: alt.folklore.computers Date: 01 May 1999 18:09:52 -0700PASC had done unix & locus ports to S/1 and some other platforms.
PASC then started on a project to port BSD to ibm mainframe/370.
This was going on in parallel with the austin work to retarget the 801/ROMP from the word processor market to the unix market. system was going to be called AIX, basically system V vIII but built on top of a hypervisor layer that looked like it was left over from the word processor effort ... called VRM. This is somewhat analogous ... but totally different from the AT&T work that ported unix on top of TSS/370.
part way thru all this ... PACS/ACIS decided to retarget the BSD port from mainframe/370 to the PC/RT ... calling it AOS.
Eventually, the mainframe port was revisited by the PASC/ACIS people ... but using Locus as the base ... which resulted in AIX/370 (and its companion AIX/PS2 ... both from the Locus base).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old naked woman ASCII art Newsgroups: alt.folklore.computers Date: 02 May 1999 07:48:01 -0700oh yes, AOS trivia
now what was the C-compiler on AOS and why?
there was work going on to do 370 backend for various compilers by a guy in STL. part way thru the activity ... he left and joined a small compiler company in santa cruz.
a couple months later the BSD->370 port was launced. first couple weeks working out the details for the port ... I convinced the group to talk to guy that had left and was in santa cruz (since he was probably the most experienced and was most likely to provide 370 backend on the shortest possible schedule). In any case, that compiler was well integrated into the operation of the project by the time it was decided to redirect the effort from a 370 port to a PC/RT port.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: System/1 ? Newsgroups: alt.folklore.computers Date: 02 May 1999 08:44:03 -0700"Andrew McLaren" writes:
the port to RIOS would have been a screamer. we had actually did some work earlier on such configuration using blue iliad (first 32-bit 801, contemperary of 16-bit ROMP 801, but never made it much past first silicon) for such a purpose. we had tentatively targeted an '88 FCS for the RIOS version.
the port to RIOS would have also opened up a whole slew of additional new features that were then being constrained by the available S/1 addressing & memory
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: System/1 ? Newsgroups: alt.folklore.computers Date: 02 May 1999 08:44:03 -0700there was a port of NCP to the series/1 ... actually it was re-implementation of the NCP function on series/1 ... bascially both PU4 and PU5 emulation done on series/1 ... the "inside" of the network was then peer-to-peer packet ... there was a 3705/ncp emulation board done for mainframe channels ... and then the series/1 emulated pu5 cross-domain support to the vtam/pu5 running on the 370 host.
there was also a project to port the whole infrastructure to RIOS base.
however ... misc pages from old overheads giving the series/1 to 3725 comparison:
System verses 3725NCP System: • Higher availability • More reliable • More function • Improved Useability • Non-IBM Host Support • Much better connectivity • Much better performance • Fewer components • Easier to tune • Easier to tailor • Easier to manage • Less expensivea typical operation was taken and configured & costed for both 3725 and the series/1 based system. configuration was multiple distributed datacenters with large end-user population with realistic distribution (from actual measured data at customer shops) of messages going to "owning" host ... as well as to other hosts in the environment. The peer-to-peer internal packet networking was more reliable than the sessions maintained by VTAM. The Series/1 would replicate the session end-point and then could dynamically route the actual message flows. Except for the end-points to the user's desk ... the infrastructure was no single point of failure. The 3725 configuration was less available ... since 80% of the terminal sessions were cross-domain ... both the "owning" 3725 and the "owning" SSCP/PU5/VTAM had to be available for session setup (in addition to the end-points). It was possible to roll-in configuration updates into the Series/1 on the fly w/o taking anything down. Configuration updates in the 3725 infrastructure typically involved taking everything down and updating both the 3725 and VTAM configuration and then restarting (and hoping that everything worked ... or you would have to reverse the process).
3725 is more expensive • 3725 configuration is operating at saturation. - 80 3725s chosen for minimal acceptable connectivity and availability - Configurator rates the 3725 at 60 messages/sec. for this type of activity. • There are 2700 terminal messages a second • 95% of messages are forwarded (processed twice) • Configuration needs to handle 5265 messages/sec (1.95*2700) • 5265/80 = 66 messages/sec 3725 is more expensive • System requires 117 3725s to handle load - Maintain average operation at 75% capacity - 45 messages/sec is 75% capacity - 5265/45 = 117 3725s • Configuration needs a 47% increase - 3725s increase from 80 to 117 - 19.2kb links increase from 760 to 1112 - 19.2kb modems increase from 1520 to 2224 - Costs increase from $25.7m to $37.8m System is less expensive • $14.2m for System hardware + $120k for modems - $11.5m 20 8-plex S/1 nodes @ $573k . Duplex S1 (two processors) @ $90k (*4=$360k) . Lines/duplex @ $39k (*4=$157k) . Host interfaces/duplex @ $11k (*4=$44k) . A400 interface/duplex @ $3k (*4=$12k) - $1.8m for 40 A400 @ $45k - $900k for 20 A715 @ $45k - $120k for 20 T1 modems @ $6kThe port to RIOS would have increased processor power by orders of magnitude. Also, the emulation software was really starting to bump its head against the 16bit addressing (as well as available real memory) of the Series/1. Numerous new functions for the emulator were being severely restricted because of the addressing & memory constraints.
Of course, Raleigh wasn't very happy with this. They weren't very
happy with me as an undergraduate when I worked on the original
telecommunication clone (credited with originating the ibm OEM
controller business). This was potentially as/more significant.
misc. 360 pcm posts
https://www.garlic.com/~lynn/submain.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Melissa Virus or War on Microsoft? Newsgroups: alt.folklore.computers Date: 02 May 1999 14:58:55 -0700we used cluster analysis in the early '70s for a product called vs/repack that would do instruction/memory trace of a program and then re-organize the program for improved virtual memory operation. could be looking at hundreds of millions of data points for typical instance, would also look at number of different kinds of runs to see if program execution was sensitive to data being operated on.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: System/1 ? Newsgroups: alt.folklore.computers Date: 03 May 1999 09:13:25 -0700... as an aside ... at least for 3277s ... a FIFO box was built where you unplugged the keyboard from the head ... plugged the box into the head ... and then plugged the keyboard into the box ... and fixed the type-ahead problem. the other hardware modification that could be done to the 3277 was fast cursor.
pvm also had a ascii->3270 emulator ... which was software running on the host ... i was running 3101 (glass teletype) from home with pvm 3270 emulator by mid '80 (pvm was a mainframe telnet-like function)
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Series/1 as NCP (was: Re: System/1 ?) Newsgroups: alt.folklore.computers Date: 06 May 1999 06:41:15 -0700oops ... not '85, '86 ... COMMON Spring '86 Conference (session 43U, Series/1 As A Front End Processor by John Erickson).
SSCP EMULATION • Emulates PU5 host SSCP (System Services Control Point) • Supports SNA cross domain protocols • Support provided for following RU types: - ER-OP, NC-ER-OP, ER-INOP, NC-ER-INOP - NC-ER-ACT, NC-ER-ACT-REPLY - NC-ER-TEST, NC-ER-TEST-REPLY, ROUTE-TEST, ER-TESTED - NC-ACT-VR, NC-DACTVR - ACTCDRM, DACTCDRM, SDT, CLEAR, RQR, CDTAKED, CDTAKEDC - CDINIT, CDCINIT, CDTERM - CDSESSF, CDSESSST, CDSESSTF, CDSESSEND - INIT-OTHER-CD, TERM-OTHER-CD - DSRLST, BINDF, UNBINDF • Handles start-up, shut-down, and control for SSCP-SSCP sessions • Uses cross domain protocols to control terminal to host sessions • Supports multiple explicit and virtual routes • Uses virtual route pacing to prevent buffer overflow • Can emulate multiple SSCPs to bypass MAXSUBA problems • Supports both ENA and Pre-ENA addressing • Uses DSRLST to obtain host application status--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: High Availabilty on S/390 Newsgroups: bit.listserv.ibm-main Date: 09 May 1999 12:40:46 -0700denisb@interlog.com (Denis Belton) writes:
later when she & I were running the skunk works turning out High Availability Cluster Multi-Processing product ... I got a chance to author a section in the corporate continuous availability strategy document ... unfortunately both the rochester and the POK groups non-concurred with the section as not being able to be met (by them).
recently one of the large financial settlement infrastructures
credited the two primary things contributing to them having 100%
availability for the last six years are
• ims hot standby
• automated operator
i.e. as other kinds of failure modes have been dealt with ... operator
"failure modes" have started to become significant percentage of all
failures
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: IBM/computer chronology Newsgroups: alt.folklore.computers,alt.sys.pdp10 Followup-To: alt.folklore.computers Date: 17 May 1999 09:58:11 -0700following picked up from bit.listserv.ibm-main
http://www.isham-research.demon.co.uk/chrono.txt
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Chronology Newsgroups: bit.listserv.ibm-main Date: 18 May 1999 11:33:03 -0700370/195 also had some instruction retry .. some business case about MTBF and total number of components in box.
there was also a project that looked at implementing dual i-stream on an otherwise normal 195 (would have two PSWs, two sets of registers, .... but only one pipeline execution unit ... but would have everything in the pipeline tag'ed). the problem was that for majority of applications, the 195 pipeline could never be kept full because of pipeline stall/drain conditions. Having two i-streams had better chance of keeping the pipeline full.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Read if over 40 and have Mainframe background Newsgroups: bit.listserv.ibm-main Date: 18 May 1999 14:32:02 -0700we had big problem with a pair of 168s cross-connected in shared disk pool ... one 168 dedicated to large mvs and one dedicated to large vm/cms.
the rule was to never mount a mvs 3330 pack on a vm "owned" controller ... because vtoc & pds searches totally destroyed interactive response.
one day a mvs pack was mounted on a drive on the vm side of the configuration ... and within 15 minutes started getting irate calls from users complaining about severe performance degradation.
the mvs operator said it was a long running job and couldn't stop it &/or remove the pack
the vm crowd brought up a virtual VS1 on the heavily loaded VM system and mounted its packs on a MVS string ... and started some interesting virtual vs1 jobs (running under vm) ... doing various kinds of vtoc & pds searches ... that brought the real MVS system to a crawl ... so that the CMS users no longer noticed degradation from the MVS vtoc & pds search activity.
i actually had to shoot a similar problem at a large MVS customer shop that had six interconnected 168s and 3033ws all running MVS and sharing a common program library. performance was great most of the time ... but periodically it would have severe performance slow
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Read if over 40 and have Mainframe background Newsgroups: bit.listserv.ibm-main Date: 18 May 1999 17:20:13 -0700.... oops, finger slip
large corporation with operations in nearly every state ... half dozen 168s & 3033s all running MVS sharing the same disk pool. Large program library ... most of the time performance was really great ... but periodically things would slow to almost a stop. They had been looking at the problem for several months when I got called in.
they had a class room with dozen tables ... pretty much covered with performance reports stacked a foot high on all the tables. After a couple hrs ... the correlation with good and bad performance was somewhat tenuous ... there was little or nothing out of the ordinary in the CPU reports and the disk I/O rates to some 50-60 drives ... except I noticed a slightly funny drive that nominally had 3-4 disk i/os per second under almost all cases ... but had aggregate disk I/O rate of 6.5 disk I/Os per second when system was under heavy load.
Looking at the drive in more detailed ... it contained the shared program library for all of the complexes ... with a 3.5 cylinder PDS directory. Turns out that under heavy load ... all the systems were doing multi-track search on the 3330 PDS directory ... 19 tracks, 60 revs/sec ... 19/60 seconds elapsed time per search I/O operation. Typically what would happen is there would be 3 searches per second plus 3-4 record reads per second (aggregate of 6.5 disk I/Os peak I/O rate across all the machines).
The problem is the 19/60 second I/O busied out the drive, controller, and channel. When I came back from this one ... I started strongly campaigning for a improved structure that didn't use multi-track search. I did a prototype ... but I think STL quoted me $26million to integrate and ship it to customers ... so had to come up with something that wasn't obviously something completely different (or do it in a very contrived and complicated manner ... costing significantly more over a very long period of time ... rather than trivial striaght forward).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Mainframes at Universities Newsgroups: alt.folklore.computers Date: 23 May 1999 09:49:43 -0700CMS on 360/370 was much more interactive growing up out of the CTSS heritage.
TSO grew much more up out of the CRJE heritage (originally RJE ... remote job entry ... basically card images sent over a network ... and then effectively card images entered from a terminal for conversational remote job entry). I had done an early CRJE hack on HASP running on MVT18 at university ... supporting teletypes and 2741s ... basically I ripped out the 2780 support out of HASP (in part to get addressability and storage) ... and replaced it with 2741 and TTY support ... along with the syntax from the CMS conversational editor (not much code from CMS was directly usable ... since it was all single treaded and the HASP code had to be at least re-entrant and multi-treaded).
for some related RJE info ... see RJE at
https://www.garlic.com/~lynn/rfcterms.htm
there were a number of 360/370 CRJE type implementations ... basically all giving terminal user access to OS support services ... but they were rarely considered serious time-sharing.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Are mainframes relevant ?? Newsgroups: bit.listserv.ibm-main Date: Mon, 21 Jun 1999 23:48:59 GMTwhile undergrad ... i added 2741 & tty support to HASP-III running on MVT18 and implemented the CMS editor syntax for doing CRJE stuff (actually I ripped out the 2780 support in order to gain some addressability in order to stuff in the 2741, tty, and the editor stuff).
later on my wife got con'ed into leaving the JES2 group in gburg to go to POK to be responsible for loosely-coupled ... created peer-coupled shared data ... eventually became the basis for ims hot standby and then parallel sysplex.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Mainframes Relevant? Newsgroups: bit.listserv.ibm-main Date: Mon, 21 Jun 1999 23:54:57 GMTY2K is even worse on embedded systems ... seems like a lot of chips that needed intervals ... used clock circuits instead of doing interval circuit
story about somebody set the clock on their video camera to 2000 and the thing opened the tape door ... but wouldn't shut it. they set it off to be repaired and got it back 3 months later with a note saying "don't do that again".
wonder if there are car engines that will have y2k problems
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Authentication in eCommerce applications Newsgroups: comp.security.misc Date: Fri, 18 Jun 1999 19:00:36 GMTX9.59 is draft standard by the financial industry standards organization for all account based payments in all (electronic) environments ... i.e. web, point-of-sale, settop boxes, etc. It specifically defines a signed payment object ... but does include something that is defined as the hash of purchase order ... providing binding of the payment authorization to something like a purchase order (it doesn't sign the purchase order ... it signs something that authorizes payment for the purchase order ... with a binding to that purchase order ... which ... in effect ... signs the purchase order ... although indirectly).
at point-of-sale it implies a hardware token capability supporting the digital signing of the payment object.
for related info ... see
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Authentication in eCommerce applications Newsgroups: comp.security.misc Date: Fri, 18 Jun 1999 23:17:04 GMT... also ... slightly related ... there is IOTP work going on in IETF and other activities ... however
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Perfect Code Newsgroups: alt.folklore.computers Date: Tue, 22 Jun 1999 20:23:22 GMTthe call/entry to iefbr14 would be
l r15,address iefbr14 balr r14,r15which enters iefbr14 with r15 set to the iefbr14 entry point and r14 with the caller's address after the branch & link reg. instruction.
from ibm-main, courtesy of deja.com
> Forum: bit.listserv.ibm-main > Thread: JCL-Question > Message 2 of 4 Subject: Re: JCL-Question Date: 1997/10/02 Author: John Wolf <wolfjc@IBM.NET> In <3431BCC3.A4D4F3B6@cpuperform.com>, on 09/30/97 at 08:00 PM, Bob Halpern said: IEFBR14 has more apar activity than lines of code. 1. As stated below, to do the SR 15,15 before the BR 14. 2. To be marked re-entrant (I used it to stub off some modules for testing, and got 17 copies of a rather large module before the 80A. I did the second apar. John Wolf wrote: > > > ---------- > >> > >> >Can IEFBR14 really set a return code or do you have a modified IEFBR14 > >that > >> >verifies the DSN's? > >> > > > --snip-- > IEFBR14 is the ONLY one instruction program, that I know of, that had an > APAR made up for it. Way back like ten years ago IBM changed how R15 was > setup on return and BR14 started to give non zero return codes. This of > course changed how some JCL streams worked. So IBM had to change BR14 so > that it zeroed out R15 before it returned via R14. > ----------------------------------------------------------- > wolfjc@ibm.net > ----------------------------------------------------------- As has been pointed out to me I misspoke. The first cut of IEFBR14 had ONLY ONE instruction in it BR R14. When IBM fixed it they ADDED a SR R15,R15 before the BR R14 so the return code would be zero. IEFBR14 does NOTHING but send your JCL through allocation. The resulting data set,assuming you are allocating a new dataset, will not be opened and therefore will not have any DCB stuff set up ie: LRECL BLKSIZE RECFM. -- ----------------------------------------------------------- wolfjc@ibm.net -----------------------------------------------------------
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: "Pirates" -- what about Paul Allen? Newsgroups: rec.arts.tv,alt.folklore.computers Date: Sun, 27 Jun 1999 16:39:29 GMTi remember when the chuck-e-cheese open'ed just off blossom hill (circa 79/80?). It was the after hours place for the spring vmite conference in 80(?).
later they bought the toy store (with the giant toy soldier) at the corner of 101 and king for corporate hdqtrs (replaced the soldier with giant chuck-e-cheese).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: "Adventure" (early '80s) who wrote it? Newsgroups: alt.folklore.computers Date: Fri, 09 Jul 1999 20:22:39 GMTi got a mainframe fortran copy within 3 months of adventure appearing (by a somewhat circuitous route ... went from stanford to the UK back to the states and finally to san jose). I made the binary available on the internal network ... and would send the source to people that had completed the 300 pts. Within another six months somebody sent me back a PLI source version with something like 450 pts.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: "Adventure" (early '80s) who wrote it? Newsgroups: alt.folklore.computers Date: Fri, 09 Jul 1999 20:24:53 GMToh yes ... this had the 100 move limitation if being played between 8am-5pm.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Perfect Code Newsgroups: alt.folklore.computers Date: Fri, 09 Jul 1999 20:46:36 GMTone of the uses of iefbr14 could have condition code check ... set by sr r15,r15 (or xr)
nominally SR/XR would be faster than LA ... except in some machine specific cases. there have been all sorts of examples ... when I was doing CP/67 ascii support ... I found something like a IC/IC/STC/BXLE loop was nominally faster than the EX/TR instruction on the 360/67.
which brings up lots of the system exploits that I consider attributable to the C programming convention for strings being null terminated ... instead of having explicit lengths as in most of the mainframe cases. Uses of explicit lengths seems to have established convention that results in significantly lower buffer-overrun bugs ... which at times seems to be over half of the basis for internet intrusions/exploits.
with respect to the EX/TR & BXLE loop stuff ... the loop would either have to preprocess the string to obtain the length ... or embed a compare/branch ... in environments where string length isn't explicitly carried with the string.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: 1401 Wordmark? Newsgroups: alt.folklore.computers Date: Fri, 16 Jul 1999 15:51:47 GMTit was possible to put-up prepare on older terminal controllers ... 2702/2703 ... and achieve the same benefit of allowing the cpu meter to coast to a stop. one of the major turning points in cp/67 for 24x7 services was having prepare in the terminal CCW sequence on 2702/2703 ... which allowed the CPU meter to coast to a stop (if there was no activity). this single characteristic changed a lot of shops from 1st shift operation to four shift operation (that and some stuff having to do with automatic re-ipl and some of the original automated operator support).
i don't remember the coasting interval on 360s ... but the coasting interval on 158/168s was 400ms ... i.e. if the processor had a timer driven daemon that woke-up every 400ms ... if even for only a couple hundred instructions the cpu meter would never get the chance to go idle.
one of the break-thrus was having dynamic adaptive daemon intervals related to workload ... rather than static build-time values.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: 1401 Wordmark? Newsgroups: alt.folklore.computers Date: Fri, 16 Jul 1999 15:57:20 GMTthe 1st shift to four shift ... also was enabler for the cp/67-based (and later vm/370 foloow-on) time-sharing services ... allowing them to go 7x24 world-wide.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: FIne-grained locking Newsgroups: comp.arch Date: Mon, 19 Jul 1999 00:39:39 GMTfor some things in the early 70s i address things a different way with what I called a bounce lock ...
basically there was
"long" locks on a processes
"medium" locks on various services link specific kernel functions
compare&swap instructions for either locking &/or queue management
this was back in the days when I was working with the guy who invented compare&swap (i.e. a couple of use spent 2-3 months coming up with a mnemonic that was his initials CAS)
In any case ... coming into kernel code with kernel resource request ... it would use compare&swap to obtain/test the lock ... if the lock failed ... the code dropped the process into a queue waiting for that resource and the processor went off to look for other work.
It was an interesting trade-off ... since it sacrificed the cache locality associated with the process ... for the cache locality of the kernel resource function (i.e. when the specific kernel function completed current activity it would check to see if it had any queued process requests before actually exiting).
it allowed smp'ing a uniprocessor kernel by putting medium locks around various functions ... and not having to rewrite them for fine-grain smp operation. it reasonably worked up thru eight to ten-way w/o causing either lots of rewrite of the kernel and w/o having hardly any lock contention (request if it failed would bounce off the held lock, queue the request and go on to other work).
For the workload and the machine characteristics of the time the process-line/kernel-line cache sacrifice was beneficial ... with efficiency of the overall system actually going up ... the processor that fell into executing specific kernel code functions was actually running faster since because of cache locality improvements ... and the balance was such that the other processors didn't starve because of any possible bottleneck queueing up (and it was major, significant improvement over various processors spinning on lock contention). Part of the success was extremely light-weight queueing mechanism against the contended for lock/resource.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: FIne-grained locking Newsgroups: comp.arch Date: Mon, 19 Jul 1999 15:48:15 GMTcharlie a. salisbury ... this was late 60s, early 70s.
an interesting requirement put on getting compare&swap into processor architecture was writing a description of how compare&swap could be used in uniprocessor machines (a description that went into principle of operation book as programming notes). this gave raise to description of various methods of using compare&swap in multi-threaded application code on uniprocessor machines.
current version of that document:
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/CCONTENTS
along the way both a single-word and double-word versions of the
instruction was introduced so the CAS mnemonic got corrupted to CS &
CSD. Following specific &/or pointers
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/7%2e5%2e23
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: CPU's directly executing HLL's (was Which programming languages) Newsgroups: alt.folklore.computers,comp.arch Date: Mon, 26 Jul 1999 17:09:38 GMTPalo Alto Science Center did the 370/145 APL microcode for APL/CMS ... speeded up APL execution by factor of 10* or so .... would give 370/145 APL better performance than 370/168 APL (vague recollection that it was done by Randy Scarboro)
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Documentation query Newsgroups: alt.folklore.computers Date: Mon, 26 Jul 1999 17:16:04 GMTdonw thru CSC side ... madnick did SCRIPT on CMS ... that had period/two-digit-codes ... then the G/M/L guys added GML to SCRIPT ... which also begat SGML ... which begat HTML, XML, etc.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: MVS vs HASP vs JES (was 2821) Newsgroups: alt.folklore.computers Date: Thu, 29 Jul 1999 20:42:40 GMTHASP was done in Houston by Simpson, Crabtree et, al
I worked on HASP starting with OS release 11 ... up thru OS release 18 (HASP-III). One of the things was putting in CMS edit syntax as well as 2741 & TTY support for early form of CRJE support.
there was also ASP (asynchronous spooling program) done out on the west coast.
Migrating HASP into the IBM official product (instead of TYPE-III program) ... group finally landed in G'burg and HASP was renamed to JES2. The G'burg group also eventually picked up ASP ... renamed to JES3. My wife worked on JES2 & JES3 in the g'burg group until she was con'ed into going to POK to be responsible for loosely-coupled (she originated peer-coupled shared data ... original basis for IMS hot standby ... and then parallel sysplex).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: MVS vs HASP vs JES (was 2821) Newsgroups: alt.folklore.computers Date: Sun, 01 Aug 1999 03:59:01 GMTposted here previously .... work I did as undergraduate ... presented at fall share meeting in Atlantic City.
the university was running studant fortran jobs on 709... tape-to-tape ibsys ... with 1401 providing front end unit-record<->tape support. I believe thruput was in jobs per second.
initial conversion to OS Release MFT 9.5 on 360/67 (running in 65 mode) resulted in changing from jobs per second (on 709) to minutes per job (on 360).
adding hasp got the times to around 20-30 seconds per job i.e. w/o hasp system was running synchronous unit-record input (card-reader) ... processed by the compiler and almost as each card processed ... synchronous unit-record (printer) output. HASP provided asynchronous processing for the unit-record gear ... allowing "jobs" to be run effectively at asynchronous buffered disk-to-disk speed.
However that was still slower than the 709 with ibsys & fortran monitor running tape-to-tape.
waterloo introduced a fortran monitor (watfor) that would accept multiple student jobs for compile and execution ... and would do it very efficiently ... and finally we started to see fortran student workload thruput on the 360 surpase the 709.
--
OS Performance Studies With CP/67
OS MFT 14, OS nucleus with 100 entry trace table, 105 record
in-core job queue, default IBM in-core modules, nucleus total
size 82k, job scheduler 100k.
HASP 118k Hasp with 1/3 2314 track buffering
Job Stream 25 FORTG compiles
Bare machine Time to run: 322 sec. (12.9 sec/job)
times Time to run just JCL for above: 292 sec. (11.7 sec/job)
Orig. CP/67 Time to run: 856 sec. (34.2 sec/job)
times Time to run just JCL for above: 787 sec. (31.5 sec/job)
Ratio CP/67 to bare machine
2.65 Run FORTG compiles
2.7 to run just JCL
2.2 Total time less JCL time
1 user, OS on with all of core available less CP/67 program.
Note: No jobs run with the original CP/67 had ratio times higher than
the job scheduler. For example, the same 25 jobs were run under WATFOR,
where they were compiled and executed. Bare machine time was 20 secs.,
CP/67 time was 44 sec. or a ratio of 2.2. Subtracting 11.7 sec. for
bare machine time and 31.5 for CP/67 time, a ratio for WATFOR less
job scheduler time was 1.5.
I hand built the OS MFT system with careful ordering of
cards in the stage-two sysgen to optimize placement of data sets,
and members in SYS1.LINKLIB and SYS1.SVCLIB.
MODIFIED CP/67
OS run with one other user. The other user was not active, was just
available to control amount of core used by OS. The following table
gives core available to OS, execution time and execution time ratio
for the 25 FORTG compiles.
CORE (pages) OS with Hasp OS w/o HASP
104 1.35 (435 sec)
94 1.37 (445 sec)
74 1.38 (450 sec) 1.49 (480 sec)
64 1.89 (610 sec) 1.49 (480 sec)
54 2.32 (750 sec) 1.81 (585 sec)
44 4.53 (1450 sec) 1.96 (630 sec)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: MVS vs HASP vs JES (was 2821) Newsgroups: alt.folklore.computers Date: Sun, 01 Aug 1999 17:26:29 GMTre: hasp-II version 3;
okk .... hasp-i would work on pcp & mft ... and could take over the machine by modifying the svc new psw directly.
for mvt there was storage protection support and some misc. convention changes ... which required the installation of a TYPE-1 svc handler for HASP to assume the privileges it needed.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Early interupts on mainframes Newsgroups: alt.folklore.computers Date: Sat, 07 Aug 1999 18:12:43 GMTone of the reasons that diagnose was chosen ... was that it was a supervisor instruction and the architecture book defined it as machine dependent ... i.e. it was unlikely to be used by any ... but very special purpose software ... and we could claim that a "virtual" machine was a specific kind of machine ... and therefor we were within the architecture book's "rules & regulations" when we claimed that a "virtual" machine was a specific kind of machine and had the latitude to define the operation of the diagnose instruction in the "virtual" machine environment.
mostly the use of diagnose instruction in CP/67 was to return time information (this was before s/370 which had a store clock instruction).
one of the path length profiles that I had done as an undergraduate was in i/o simulation and ccw translation. Since all of CMS's disk I/O was very predictable ... seek/search/tic/read-write, etc. I had implementated an "immediate" x'FF' CCW that would expand into the whole operation; and since CMS's disk supervisor was simulated synchronous ... control wouldn't return to the SIO until the disk I/o was complete ... and would store CC=1, csw stored (i.e. as if it was an immediate CCW I/O operation).
The 360 SIO (start I/O) could return cc=0 (operation successfully started), cc=1 (csw stored, effectively some sort of immediate operation), cc=2 (subchannel busy), cc=3 (device not available). Simulating a cc=1 ... allowed the operation to look immediate, eliminating the necessity for CMS to do a bunch of programming to enter wait state ... and then take a subsequent I/O interrupt.
the pathlength stuff I had done for MFT was only partial benefit to the CMS environment ... since CMS had very low priviledge instruction ratio ... except for I/O. The x'FF' CCW cut the ccw translation overhead as well as bunch of tasking, idle PSW loading, and subsequent interrupt simulation, etc. which showed significant improvement in CMS intensive environment. The development group converted this to custom simulation with a diagnose instruction (but effectively the same semantics) ... in part since x'FF' CCW op-code wasn't protected in any way ... but essentially had a sanctioned "charter" based on what was in the rules & regulations set down in the 360/370 architecture red book.
rather than repeat ... now have urls
https://www.garlic.com/~lynn/94.html#18
https://www.garlic.com/~lynn/94.html#20
https://www.garlic.com/~lynn/94.html#21
https://www.garlic.com/~lynn/94.html#27
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: IEFBR14 cookie from www.ibm.com Newsgroups: alt.folklore.computers Date: Sat, 07 Aug 1999 20:43:53 GMTin the early 70s, I named one of the modules in my performance enhancements DMKSTP ... having come out of the 60s with muscle cars and "the racers edge" ... and I was able to include it in the resource manager product in '76.
another iefbr14 reference ...
https://www.garlic.com/~lynn/99.html#81
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Power4 = 2 cpu's on die? Newsgroups: comp.arch Date: Sat, 07 Aug 1999 20:54:15 GMTolder ibm design for two "processor" SMP ... where either processor could in fact utilize all hardware resources ... this is little over 25 years old (early '70s)
re:
https://www.garlic.com/~lynn/99.html#73 The Chronology
370/195 also had some instruction retry .. some business case about
MTBF and total number of components in box.
there was also a project that looked at implementing dual i-stream
on an otherwise normal 195 (would have two PSWs, two sets of registers,
.... but only one pipeline execution unit ... but would have everything
in the pipeline tag'ed). the problem was that for majority of applications,
the 195 pipeline could never be kept full because of pipeline stall/drain
conditions. Having two i-streams had better chance of keeping the pipeline
full.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Early interupts on mainframes Newsgroups: alt.folklore.computers Date: Tue, 10 Aug 1999 02:52:56 GMT"Don Chiasson" writes:
Edward Rice wrote in message ... >.......... > >Uh... polling is generally very inefficient and is avoided whenever >possible. An interrupt system (including faults) is designed into a system >to /avoid/ polling, not to perform more efficient polling. > There can be other problems. In real time systems driven by hardware interrupts if a device goes awry and generates a contunuous stream of interrupts, the whole system may hang because no program can get any processor time. Alternate scenario: interrupts are often handled by pushing machine status on a stack. If the interrupt rate is high or errors happen with errors the stack may overflow and crash the system. With a polling system, the program would test the device, note that it is not working and then go on to the next device. In a benign world these things do not happen. Donactually I did a variation on this for 370 cache machines in the mid-70s.
critical sections of the kernel ran disabled for all interrupts. prior to selecting some non-disabled work for execution I inserted a pair of instructions that enabled/disabled for interrups. This eliminated the uneccesary overhead of selecting and dequeueing some piece of work when there was interrupts pending that required other work.
recognizing that high rate of interrupts did terrible things to cache locality ... would monitor the I/O interrupt rate and if it exceeded some threshold for the machine ... the code dynamically switched normal workload from being enabled for all interrupts to being enabled for interrupts except I/O (and scheduled a timer event interrupt).
strategy that some I/O interrupts would be delayed for a small interval (than they would have been if normal workload ran enabled for all interrupts) ... and then the system would accept all pending I/O interrupts effectively in a batch. This would only kick-in when interrupts exceeded a threshold ... where the batch processing actually improved both the thruput of I/O interrupt handling as well as thruput of the workload processing (by improving the cache hit characteristics of both).
this was separate from the work done to "bullet-proof" I/O supervisor from things like hot interrupts as well as lost interrupt ... i.e.
https://www.garlic.com/~lynn/95.html#3
https://www.garlic.com/~lynn/99.html#31
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: The Translate (TR) instruction Newsgroups: alt.folklore.computers Date: Tue, 10 Aug 1999 20:27:48 GMTin addition to the translate instruction there was translate and test instruction.
translate would take and input string and a 256 byte table ... each byte in the input string was used to index into the 256 byte table and then the value from the table would replace the byte in the input string.
the translate and test would take and input string and a 256 byte table and each byte in the input string was used to index into the 256 byte table and keep processing until it found a non-zero entry in the 256 byte table.
translate tables were available for most terminal types ... both "input" translate table and an "output" table ... used to translate from/to terminal character code & ebcdic.
ascii characters were peculiar because ibm controllers would process an incoming byte by storing leading bit in low order position in a byte before transferring the full byte to mainframe memory. as a result the ascii translate tables ... weren't actually ascii<->ebcdic translation but between ebcdic and "bit-reversed" ascii.
on many 360/370 translate&test was not a very well optimized instruction and it was frequently faster to perform the logic using a bxle loop.
misc. ref.
https://www.garlic.com/~lynn/96.html#37
https://www.garlic.com/~lynn/98.html#35a
https://www.garlic.com/~lynn/99.html#44
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use Newsgroups: alt.folklore.computers Date: Fri, 13 Aug 1999 01:49:50 GMTthere was possibly 5 levels of hardware indirection between the software and actual data. one of the nails was an analysis (I believe by the houston science center) that calculated that PARS application (precursor to ACP & TPF ... aka airline res. system) ... running on a 195-speed hardware implementing FS architecture would have thruput lower than PARS running on 370/145.
there were 12 or 13 areas/sections. at the time, my wife worked for person heading up one of the sections (inter-system coupling, before she went to pok with responsibility for loosely-coupled and did the Peer-Coupled Shared Data architecture) ... she had come out of UofMich engineering and thot that it was fantastic that every blue-sky idea that might possibly ever have existed was being discussed & considered.
On the other hand ... I thot resource management ... (chapter 8?) wasn't even up to the level of what I had deployed at the time. At the time, there was a cult film playing (non-stop for 13 years?) down the block in central square ... queen of hearts(?) (actually "king of hearts") ... it crossed my mind that it might be a case of the inmates being in control of the institution.
the other interesting thing was super-tight security around all the documents ... which were available online. One weekend, I had a machine room that contained a copy of the documents with all the super-tight security. They made a point of saying that they could leave me in the machine room by myself all weekend and I wouldn't be able to access the documents. I was able to show that in less than five minutes elapsed time that I had access to everything in the room.
... part of this was discussed before ... see one of my earlier
postings here under "old manuals" at
https://www.garlic.com/~lynn/96.html
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Future Cryptology Newsgroups: sci.crypt Date: Fri, 13 Aug 1999 20:13:21 GMTtomstdenis writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!)) Newsgroups: alt.folklore.computers Date: Sat, 14 Aug 1999 15:57:23 GMTthe 3081/3/4 (370s & beyond) has 64bit tod clock with bit 12 being a microsecond (although architecture didn't require that all/any machine actually provide microsecond resolution). that made bit 32 slightly more than a second. its epoch was first day of this century (i actually got to spend 3 months with some other people resolving what that was).
most groups initially set zero to 1970 ... rather than the start of the century (and the rest set it to a year earlier than the start of the century). with bit 32 slightly larger than a second (1024/1000), 2**32+ seconds (clock period) is almost 140 years ... with epoch at start of this century it carries well past year 2000.
for more detailed description of current 390 architecture (effectively
a superset) see:
http://ppdbooks.pok.ibm.com:80/cgi-in/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/CCONTENTS
(although most of the time I find that this url is not operational on the weekend)
the guy that ran the FAA project went on to be president of IBM's FSD (now owned by loral) & then left and formed his own company. I believe he retired last summer.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!)) Newsgroups: alt.folklore.computers Date: Sat, 14 Aug 1999 16:17:00 GMTtotal aside ... 3083s were never intended to be built just 3081 and 3084. IBMs SMPs prior to the 3081 were two totally independent machines cobbled together ... so that the components could actually be unhooked and run as two independent processors. running as multiprocessor the machines were typically slowed down 15% of so to allow for memory contention resolution (and in cache machines to handle cache invalidation signals). when run as two independent processors the machines would run at full speed.
the 3081 was two processors in a single box ... it was not possible to partition it and run it as two independent machines. the 3084 was two 3081 tied together to make a 4-way SMP.
The initial 3081 ... 3081D was also only about 5mips per processor ... hardly showing any performance improvement over the 3033. It wasn't until the 3081K machines that it started to show over 7mips per processor.
ACP/TPF (airline res system) didn't have any SMP support (although they would take VM and could run two copies of ACP/TPF on 2-way system) ... the ACP/TPF market was looking for flat-out fast performance uniprocessor thruput ... which wasn't available on the 308x line. To satisfy the ACP/TPF market, a 3083 uniprocessor was built ... which immediately picked up a 15% processor hardware thruput (and somewhat reduced the cost of the 2nd processor which they couldn't effectively use ... but there was a lot of stuff done in the 3081 adding the 2nd processor w/o doubling the cost).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler) Newsgroups: alt.folklore.computers Date: Fri, 20 Aug 1999 15:29:28 GMTthe other problem was that the 3350 fixed head area didn't have a separate I/O transfer address ... if the single (logical) address assigned to the 3350 was busy doing arm motion ... it was not possible to do data transfers from the fixed head portion. I had a proposal similar to the multiple-exposure capability available on the 2305 (an all fixed head device) ... that supported eight logical request interfaces. The eight logical request interfaces could be used to help mask rotational delay ... i.e. with requests queued on all eight logical interfaces ... the first target that came under a rotating head would be serviced. In any case, any moderate use of the moveable arm on the 3350 would effectively make the fixed-head portion busy (& unavailable) over half the time.
The vulcan group was instrumental in getting the multiple-exposure 3350 proposal killed (perceived competitive threat) ... and then they were finally disbanded.
in another project (about the same timeframe) we collected significant amounts real live trace disk access data and simulated numerous caching strategies ... and a single global shared cache was alwas higher thruput than multiple sub-caches (i.e. a 20mbyte located at the processor and shared with all I/O devices was alwas more effective than 40 2mbyte caches spread out locally to each device). Of course this confirmed my work from the late 60s where global LRU for page replacement and working set management alwas outperformed the local LRU strategy documented in the working set literature of the time. The only caveat was a electronic track-line located at each rotating device that helped in rotational delay compensation (start reading data continuously from the current head position ... even if not at start of record, possibility that head is in the middle of the record desired so that when the head does come around to start of record it only has to transfer the data not yet read).
other reference ...
https://www.garlic.com/~lynn/95.html#8
https://www.garlic.com/~lynn/99.html#8
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler) Newsgroups: alt.folklore.computers Date: Fri, 20 Aug 1999 15:36:10 GMT... ok, there was 2nd caveat ... large data sequential operations that would wipe the global cache had to be managed (but that has alwas been true of global caches).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: IBM Mainframe Model Numbers--then and now? Newsgroups: alt.folklore.computers Date: Sat, 21 Aug 1999 00:34:16 GMTuc.5 was the processor in the 8100 and the 3705 (and others) ... peachtree in the S/1 was much better processor and numerous of us attempted to get it designated the base for communication controllor
my wife is one of the ring patent holders on (chat) ring used by S/1.
related discussion:
https://www.garlic.com/~lynn/99.html#63
https://www.garlic.com/~lynn/99.html#66
https://www.garlic.com/~lynn/99.html#67
https://www.garlic.com/~lynn/99.html#69
https://www.garlic.com/~lynn/99.html#70
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Computer History Newsgroups: alt.folklore.computers Date: Mon, 23 Aug 1999 15:57:10 GMTother aspects of unattended computer operation was automated re-ipl (masking some of the failure types), automated operator, and the way off-shift time would be charged for
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!)) Newsgroups: alt.folklore.computers Date: Mon, 23 Aug 1999 16:02:17 GMTand what is really wierd is the 3090 service processors were a pair of (somewhat modified) 4361s running a highly modified copy of VM/370 release 6 (service panels were written in CMS IOS3270). Old VM releases did have a problem switching DT/ST ... but never seem to have had a problem with the year (unless this was some of the new service processor specific modifications).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes) Newsgroups: alt.folklore.computers Date: Tue, 24 Aug 1999 23:44:25 GMTbut CMS in 1971 still looked pretty much the same way it looked when it was implemented in 1966.
in 1969 i crafted the CMS editor syntax (along with 2741 and tty) support into HASP/MVT18 to provide a CRJE type implementations ... i.e. it was pretty straight forward to make a MVT based implementation have the look and feel of CMS (in 1968, I had also borrowed the LL 2250M1 libraries originally written for Fortran display aps ... and crafted them into CMS edit for a form of full-screen editor).
In terms of usage of CMS ... all of those developers weren't using VM so much for testing ... they were using CMS for editing, software development, email (the internal network was larger than Arpanet/Internet from pretty much the start up until sometime into the mid-80s with the majority of the nodes all VM).
possibly the people that specified TSO (as opposed to implemented) didn't use online computing of any kind (and TSO was a much more specification driven project)
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes) Newsgroups: alt.folklore.computers Date: Tue, 24 Aug 1999 23:54:47 GMTi recently ran across a internal network weekly update file on an old floppy disk ... example of activity. Frequently all changes only VM machines ...
• Date Sent 1-21-83 • Node Connected Machine DIV WHERE OPERATOR • To/How Type NUMBER + LITVM * SWPVM/C 158/VM CHQ White Plains, N.Y. 8-236-2207 + MLVFSC3 * MLVFSC1/9 4331/VM EMEA Marne LaValle, France + OWGVM3 * OWGVMX/4 3033/VM FSD Owego, N.Y. 8-662-3787 + PISAVMSC * ROMESC/4 4331/VM EMEA Pisa, Italy 8-39-50-4783 + PKVMWFB1 * PKSMRVM/9 4341/VM DSD Poughkeepsie, N.Y. + RCH38AD1 * RCHVMV/9 SYS38/S38 SPD Rochester, Mn. 8-456-6297 + SMAVMDP0 * SMAVM1/9 4341/VM EMEA Sainte Marie, France + SMAVS33H * SMAVM1/9 3033/JES2 EMEA Sainte Marie, France 38-825000 + STLVM24 * STLVM10/9 4341/VM GPD Santa Teresa, Ca. + STLVM25 * STLVM10/9 4341/VM GPD Santa Teresa, Ca. + STUTVMX * STUTVM1/C 3033/VM EMEA Stuttgart, Ger. 49-711-7817-288 + TORVM2 * TOROVM1/C 3033/VM AFE Toronto, Canada 8-942-6050 + TUCVMTC3 * TUCVM3/9 4341/VM GPD Tucson, Arizona 8-461-4576 + VIMVM01 * WINH6/4 168/VM EMEA Vimercate, Italy + WELVMNZ1 * WTSCPOK/2 3033/VM AFE Wellington, New Zealand
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: The Translate (TR) instruction Newsgroups: alt.folklore.computers Date: Wed, 25 Aug 1999 17:41:20 GMTi actually have possible/probable problem with the ibm TR for ASCII->EBCDIC.
In X9.59 mapping to X9.15, we are adding a binary field to a record that was previously all alphanumeric and regularly translated from ASCII->EBCDIC as in
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/A%2e3%2e41?SHELF=
note that the typical IBM ASCII->EBCDIC translate tables have been bit reversed since the ibm line controllers have had a convention of storing the leading bit in the low-order bit position ... and ASCII transmits the leading bit from the high-order bit position (i.e. an ascii x'3F' would show up x'FC' im mainframe memory).
A possible problem is that some of the ASCII<->EBCDIC translate table sets are not reversible (not all ASCII characters occur in EBCDIC and not all EBCDIC characters occur in ASCII). Since IBM "TR" replaces the original data ... it can be impossible to recover the exact original binary data if incorrectly/inadvertently translated.
X9.15 is a subset of ISO8583 and is the typical protocol used to transmit point-of-sale (as well as mail-order/catalog-order and other) financial transactions.
X9.59 is the financial industry's draft standard for authenticating all account-based payments in all environments (point-of-sale, internet, settop, atm, credit, debit, etc) ... actually the charter is to preserve the integrity of the financial infrastructure for all electronic retail payments with just a digital signature.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes) Newsgroups: alt.folklore.computers Date: Thu, 26 Aug 1999 04:46:11 GMTfrom the 83 file .... 1000 mainframes on the internal worldwide network 6/10/83.
• Date Sent 6-14-83 • Node Connected Machine DIV WHERE OPERATOR • To/How Type NUMBER + CPHVMCE * CPHVM1/9 4341/VM EMEA Copenhagen, Denmark - CPHVMEC * CPHVM1/9 4341/VM EMEA Copenhagen, Denmark • I have just received word that CPHVMEC, the 1000th node that • appeared 6/10/83 was the incorrect node name due to some misunder- • standing in Copenhagen. CPHVMCE is the correct name.couple more samples from the 83 file
• Date Sent 7-29-83 • Node Connected Machine DIV WHERE OPERATOR • To/How Type NUMBER + BPLVM * PKMFGVM/9 4341/VM DSD Brooklyn, N.Y. 8-868-2166 + FRKVMPF1 * STFFE1/9 4341/VM CSD Franklin Lakes, NJ 8-731-3500 + FUJVM1 * FDLVM1/4 3033/VM AFE Fujisawa, Japan + GBGMVSFE * GBGVMFE3/C GUEST/MVS FED Gaithersburg, Md. 8-372-5808 + LAGVM5 * LAGM3/9 168/VM CPD La Gaude, France + LAGVM7 * LAGM1/9 3032/VM CPD La Gaude, France + MVDVM1 * BUEVM1/2 4341/VM AFE Montevideo,Uruguay 98-90-17 + RALVMK * RALVMA/C 4341/VM CPD Raleigh, N.C. 8-441-7281 + RALVMM * RALVS6/C 4341/VM CPD Raleigh, N.C. 8-227-4570 + RALVMP * RALVM2/C 3081/VM CPD Raleigh, N.C. 8-442-3763 + RCHVM1PD * RCHVM1/C 4341/VM SPD Rochester, Mn. + RCHVM2 * RCHVM1/C 4341/VM SPD Rochester, Mn. + RCHVM3 * RCHVM1/C 4341/VM SPD Rochester, Mn. + SJMMVS16 * SNJMAS2/9 4341/MVS GPD San Jose, Ca. 8-294-5103 + SJMMVS17 * SNJMAS1/9 4341/MVS GPD San Jose, Ca. 8-276-6657 + TUCVMJ * TUCVMI/5 148/VM GPD Tucson, Arizona 8-562-7100 + TUCVMN1 * TUCVM2/C 4341/VM GPD Tucson, Arizona 8-562-6074 + UITECVM1 * UITHON2/9 4341/VM EMEA Uithoorn, Netherlands • Date Sent 12-15-83 • Node Connected Machine DIV WHERE OPERATOR • To/How Type NUMBER + ADMVM2 * ADMVM1/9 4341/VM EMEA Amsterdam, Neth. 20-5133034 + BOEVMN * BOEVM1/9 4361/VM SPD Boeblingen, Ger. 49-7031-16-3578 + BRMVM1 * MTLVM1/9 4341/VM AFE Bromont, Canada 514-874-7871 + DUBVM2 * RESPOND/4 3158/VM EMEA Dublin, Ireland 785344 x4324 + ENDVMAS3 * ENDCMPVM/C 3081/VM GTD Endicott, N.Y. 8-252-2676 + KGNVME * KGNVMN/C 3081/VM DSD IBM Kingston, N.Y. + KISTAINS * KISTAVM/9 4341/VM EMEA Stockholm, Sweden + MDRVM2 * MDRVM1/9 3031/VM EMEA Madrid, Spain 34-1-4314000 + MSPVMIC3 * MSPVMIC1/9 4341/VM FED Minneapolis, Minn. 8-653-2247 + POKCAD1 * PKDPDVM/9 4341/VM NAD Poughkeepsie, N.Y. 8-253-6398 + POKCAD2 * POKCAD1/C 4341/VM NAD Poughkeepsie, N.Y. 8-253-6398 + SJEMAS5 * SNJMAS3/S 4341/MVS GPD San Jose, Ca. 8-276-6595 + TOKVMSI2 * FDLVM1/9 3031/VM AFE Tokyo, Japan
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes) Newsgroups: alt.folklore.computers Date: Thu, 26 Aug 1999 15:23:51 GMTanother inhibitor to people using MVS as their standard platform on the internal network was the JES limitation in number of nodes that could be addressed.
HASP mapped pseudo unit record devices into a one-byte/two-decimal-digit indexed table. JES carried over this design ... and also used the same table for network nodes ... but expanded the limit to three-decimal-digits (but still one byte). This allowed support for up to 256 definitions ... combination of pseudo unit record devices plus network nodes. A typical JES implementation might have 40-60 pseudo unit record devices allowing for 200 or so network node definitions. Sometime after the internal network passed 1000 nodes, JES did increase the number of definition slots to 999 (from 256).
As a result, somebody on a MVS system only was able to send/receive mail & files with other nodes that happened to be defined in their local 200 node table (JES also had a feature of disposing of incoming files/email from sites not defined, w/o warning anybody).
Aggravating all of this was JES feature that changes to the network definition required new JES generation and a scheduled MVS system re-boot/ipl ... something that most operations only did once or twice a month (even if you could establish a critical need for communicating with a specific node ... it could take 2-6 weeks before the changes were made and system re-ipled).
JES network support also had a downside that it scrambled network, file and other fields in the header (as well as scrambling processing in the network driver) ... and small version-to-version changes in various header information could preclude any network interoperability ... and incoming files from out-of-synch JES systems could even lead to MVS system crashes (there was well documented case of San Jose GPD JES enhancements causing repeated MVS system crashes in Hursley). Typical configurations were to only have MVS nodes at end-node locations "protected" by intermediate VM systems with special VM network modifications to sanitize/convert header information that would be acceptable to specific JES systems.
VM from the start had cleanly separated out all the various fields and processing and had large family of different line & protocol drivers which were easily modified ... and VM was frequently used as intermediate processor for JES/HASP machines talking to each other. (i.e. A VM system might be required just to enable two different JES systems to exchange information).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: What is the use of OSI Reference Model? Newsgroups: comp.programming Date: Sun, 29 Aug 1999 19:59:47 GMTthe OSI reference model (and federally mandated GOSIP in the late 80s and early 90s) in ISO was different from the IETF tcp/ip model.
one characteristic difference betwen ISO and IETF was that IETF requires at least two different interoperable implementations before becoming a standard ... ISO effectively requires a lot of people to vote on a paper description.
In late 80s ... trying to get high-speed protocol implementation thru ANSI X3S3.3 (ansi is US recognized standards body by ISO, X3S3.3 worries about matters corresponding to level 3&4 of the OSI model). To do high-speed ... some of the work effectively involved collapsing stuff in levels 3 & 4 ... which found hard slogging because of violation of levels 3 &4. Note this was despite the fact that IEEE803 LAN already accepted collapsing levels 0, 1 and part of 2
misc. references:
http://andrew2.andrew.cmu.edu/rfc/rfc1169.html
http://andrew2.andrew.cmu.edu/rfc/rfc994.html
http://www.ansi.org/
http://www.ieee.org/
http://www.ietf.org/
http://www.iso.ch/
http://www.scit.wlv.ac.uk/~cm1901/spos/comms/osirm.crit.html
https://web.archive.org/web/20020410124538/http://www.scit.wlv.ac.uk/~cm1901/spos/comms/osirm.crit.html
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: What is the use of OSI Reference Model? Newsgroups: comp.programming Date: Sun, 29 Aug 1999 22:15:57 GMTthere were significant number of people who were startled when TCP/IP prevailed over the federally mandated GOSIP (OSI).
with regard to high speed protocol ... it had several design points ... some
• a very thin layer in the kernel (osi level 4 or TCP) which would interface to HSP implemented in a chip ... which could talk directly to a LAN MAC layer (i.e. collapse almost all of OSI layers 0, 1, 2, 3, & 4).
• usable for transactions ... HTTP use of TCP/IP requires a minimum of seven packet exchanges ... HSP was designed to due the same in a minimum of 3 packet exchanges.
OSI (and to some extent early TCP/IP) had slow-speed, high-error rate, point-to-point copper design point ... predating fiber, satellites, FEC, encryption and LANs (vestiges even in TCP/IP with things like checksum in a header record).
HSDT (high speed data transport) project in the early and mid 80s was using satellites, fiber, fec (things like 15/16th reed-solomon), encryption (even something that looked similar to today's IPSEC/VPNs) and LANs.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: IBM S/360 microcode (was Re: CPU taxonomy (misunderstood RISC)) Newsgroups: comp.sys.amiga.advocacy,comp.sys.amiga.misc,comp.arch Date: Mon, 30 Aug 1999 18:01:31 GMTthe low end 370s tended to be verticle microcoded machines ... tended to look very RISC'y ... 145 avg. about 10 microcoded instructions per 370 instruction. higher end 370s were horizontal microcoded ... 165 was 80ns cycle machine ... slow main memory and avg. about 2.1 machine cycles per 370 instruction (assuming didn't take cache miss). The 168 had same cycle time, faster main memory and optimization & other stuff in the microcode reduced things to about 1.6 machine cycles per 370 instruction.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS390 bundling and version numbers -Reply Newsgroups: bit.listserv.ibm-main Date: Thu, 02 Sep 1999 22:48:42 GMTi first heard boney fingers at share meeting in '70s (denver '77/'78?) at the HASP songfest ... with the words rewritten to apply to JES2. It was a C&W song supposedly written by cousin of one the JES2 committee members who got it rewritten for JES2 and performed by his cousin (at least that was the story i was told). I also remember KFAT playing the original periodically.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Schneier/Publsied Algorithms Newsgroups: sci.crypt Date: Sun, 05 Sep 1999 22:22:30 GMTas i've possibly mentioned before ... the charter given the X9A10 working group for X9.59 (standard for all account-based payments, credit, debit, ACH, check, ATM, etc) was to preserve the integrity of the financial infrastructure for all electronic retail payments with only a digital signature (independent of privacy issues)
Eric Lee Green writes:
I'm primarily interested in encryption as a mechanism for protecting
financial data from criminals, not as a political statement. In my
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Computer, supercomputers & related Newsgroups: alt.folklore.computers Date: Tue, 07 Sep 1999 15:59:52 GMTfrom eugene in comp.benchmarks
misc. NSC references from my archives
https://www.garlic.com/~lynn/94.html#23
https://www.garlic.com/~lynn/94.html#24
https://www.garlic.com/~lynn/99.html#67
they had a product line was called HyperChannel ... which is gone (and there is now a new company called hyperchannel which is a ... what else? ... internet solutions provider).
NSC had initially done the (HyperChannel adapter) A720 in a project for my wife.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: atomic History Newsgroups: alt.folklore.computers Date: Thu, 09 Sep 1999 15:01:18 GMTi knew american officer (taught at war college, there was article on him during desert storm about the current crop of cols. and majors as his jedi knights ... titled the fight to change how america fights) that spent a lot of time debriefing US, Russian, and Germans in the 50s ... one of his comments was that german tank corp had 5-to-1 kill ratio over the americans and the americans prevailed by throwing 10-to-1 numerical superiority at them (and that it was a conscious decision on the american government part to win by being able to absorb 5-to-1 death ratio) ... his observation was the strategic planners in washington didn't factor in the moral effect that had on the troops being sent in as cannon fodder.
German officers were predominately professional soldiers with army having something like 3% officers with philosophy of making a decision as low in the organization as possible. By comparison, US army was something like 11-17% officers and decisions were made as high as possible with lots of paper trail (he quoted Guderian's order going into the blitzkrieg as verbal orders only ... government auditors being prone to looking to place blame after a battle ... regardless of how well it went ... and Guderian wanted the man on the scene to make the decision w/o having to go back up thru a chain of command for CYA ... and not have to fear any reprisals if things that didn't go perfectly)
his belief was that US won the war because of the logistics management of huge amounts of cannon fodder.
he also observed one of the problems of american business during the 80s was that too many of the (commercial) business CEOs had gotten their strategic training on how to run an operation as army officers during WW2 (top-heavy management, rigid command and control, lots of CYA and push decision to highest level possible).
going forward to vietnam war ... he tells story about the air force air-to-air missile. At some point in its development he was giving a briefing ... they fed him all the specs and showed a film that the missile hit the target every time it was fired ... claiming at .99KP. At the end of the film he said that they had just told him that it would only have a .09KP (1/10th); they said that wasn't true ... he said replay the film ... at the point where the missile was just about to hit the drone ... he said stop the film and asked what kind of guidance does the missile have?; A: heat-seeking; Q: what kind of heat-seeking?; A: pin-point heat-seeking; Q: what is the hottest part of a jet plane?; A: the engine.
"No it isn't ... the hottest point is the plume 15-30 yards behind the plane ... the only time you will score a hit in air-to-air combat is if you happen to be shooting out the other guy's tailpipe ... which is only about 10%."
So sometime in the middle of vietnam ... one star air force in vietnam had all the fighters switch from air force missile to sidewinder (which had .2kp to .24kp ... better than twice what they found the air force missile to have). he lasted almost three months before being called on the carpet at the pentagon; he had violated a cardinal rule of the services ... budget share ... he had reduced the air force's budget share (fewer US planes being shot down and air force missiles weren't being used up) and increased navy's budget share (sidewinder was an navy missile).
another story was the F16 design ... the "official" plane was the F15 ... but he was doing the F16 design anyway. MD kept trying to shut him down and couldn't. Finally, president of of MD went to ass. sec. of def. and demanded that john be charged with theft of government property (plane designed required lots of supercomputer time ... and therefor john was obviously stealing government computer time worth millions of dollars) and thrown in Leavenworth for 20 years. An intense audit of all government supercomputers followed but after three months they gave up without finding a trace. Finally the person heading up the investigation went to john and said ok, we give up ... we know you are doing it but we can't find any evidence ... but by the way can you privately tell me how you are doing it.
misc. other reference from the past ...
https://www.garlic.com/~lynn/94.html#8
a book recently sent us about the asian side was "A Different Kind of War" by Miles.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Painting machines (the colour the customer wants) Newsgroups: alt.folklore.computers Date: Fri, 10 Sep 1999 18:36:24 GMTsimilar thread ....
Newsgroups: alt.folklore.computers From: lynn@netcom11.netcom.com (Lynn Wheeler) Subject: Re: painting computers Date: Sun, 10 Apr 1994 16:21:48 GMT it wasn't authorized, but CSC painted the disk drives in its machine room (2nd floor 545 tech sq). There were five 8-drive 2314 strings and a short 5-drive string. Each string was painted a different color so that strings could be referred to by color for mounting/unmounting disk packs. -- Lynn Wheeler | lynn@netcom.com, lhw@well.sf.ca.us
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Computer supersitions [was Re: Speaking of USB ( was Re: ASR 33 Typing Element)] Newsgroups: alt.folklore.computers,alt.sys.pdp8,alt.sys.pdp11,alt.sys.pdp10 Date: Mon, 13 Sep 1999 14:33:32 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
smaller quata made the deadline sooner ... and not using any resource made the deadline sooner.
one pathelogical case noticed early on with APL on early cp/67 was large memory usage and compute bound processing ... with people playing with the keyboard to increase their proportional cpu consumption. the change said that playing with the keyboard provided better response for interactive type stuff ... but wouldn't allow consumption of more than "fair" share of resources.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Speaking of USB ( was Re: ASR 33 Typing Element) Newsgroups: alt.folklore.computers,alt.sys.pdp8,alt.sys.pdp11,alt.sys.pdp10 Date: Mon, 13 Sep 1999 15:43:21 GMTre: networking use ....
following were two '96 posts in comp.infosystems in response to where did 3-layer architecture originate. these were my candidates for earliest proposal that I had made for 3-layer architecture.
https://www.garlic.com/~lynn/96.html#16
there is slight typo in the ... "<50mbit" should have been "<50kbit" ... i.e. 1044 support was getting mbyte+/sec sustained thruput using modest cpu on 4341 and standard support could get <50kbit/sec thruput nearly saturating a 3090 cpu.
https://www.garlic.com/~lynn/96.html#17
We use to go visit the corner office in somers of the guy that had repsonsibility for SAA ... the idea that the middle layer provided most of the adaptability and flexability support for the desktop ... rather than client/server, mainframe & SAA drove those guys up the wall.
one of the big issues back in 1988 was the identified support costs of all those desktops.
I actually had a different one earlier from 1983 which talked about intermediate distributed computers between the desktop and the backend mainframes ... but that was much more of a hierarchical ordering compared to the referenced 1988 flavor which was much more of a mesh.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Speaking of USB ( was Re: ASR 33 Typing Element) Newsgroups: alt.folklore.computers,alt.sys.pdp8,alt.sys.pdp11,alt.sys.pdp10 Date: Mon, 13 Sep 1999 16:26:04 GMTwasn't just crash free desktops ... but being able to quickly and easily adapt the desktop to individuals' requirements w/o affecting the integrity of the operation .... dynamic tension between availability/reliability (usually implied by more structure) and adaptability/flexibility (usually implied by less structure).
part of the middle layer proposal (original 3-layer architecture) included support for doing stuff to the desktop.
and ... of course ... my reference on adaptability/flexibility
https://www.garlic.com/~lynn/99.html#120
https://www.garlic.com/~lynn/94.html#8
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Q: S/390 on PowerPC? Newsgroups: comp.arch Date: Tue, 14 Sep 1999 01:00:53 GMTDel Cecchi writes:
The other problem was that a lot of the applications were relatively disk intensive ... which moving from 16ms (& less) disk technology to 100ms+ disk access technology (along with still quite a bit of page thrashing in the 512k byte memory space ... to the same 100ms+ disk technology) ... made it relatively painful to use ... except for all but the most tailored applications.
On top of that ... the pair of 68000s delivered well under 100kips 370 processing rate.
In the same time frame ... I tried to get a 2.5mip 370 processing rate with 2mbyte memory and <15ms disk technology.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Dispute about Internet's origins Newsgroups: alt.folklore.computers Date: Thu, 16 Sep 1999 19:40:16 GMTsignificantly larger timesharing install during the late 60s and during the 70s; see
although some of the people doing early development in the mid-60s had previously also worked on ctss.
ignoring the actual customer install base, at various times during the
70s I was personally building & distributing to larger (internal
corporate) install base than some of the other systems total customer
install base.
https://www.garlic.com/~lynn/95.html#14
https://www.garlic.com/~lynn/96.html#35
https://www.garlic.com/~lynn/97.html#15
from the customer install base, the resource manager I released in spring of 76 (it was the first IBM "priced" SCP code ... I spent six months learning how to price operating system software), at a license fee of $990/month hit a 1000 licenses within six months of release (I don't know the total size of the customer install base ... just for some of the stuff I was involved in).
as mentioned before, the just internal network was larger than the
arpanet/internet from effectively the start up into the '80s.
https://www.garlic.com/~lynn/99.html#112
which was also the basis for BITNET and EARN.
also
https://www.garlic.com/~lynn/99.html#52
&
https://www.garlic.com/~lynn/99.html#53
and my part of the earlier thread on parts of this subject.
https://www.garlic.com/~lynn/internet.htm
small extract from Melinda's paper ...
II. A BRIEF HISTORY OF VM
CTSS
In the beginning was CTSS, the "Compatible Time-Sharing
System". CTSS was written by a small group of programmers at the
Massachusetts Institute of Technology (MIT) in Cambridge,
Massachusetts, under the leadership of Professor Fernando Corbato.
One of the CTSS programmers was Robert Creasy, who was later to become
the leader of the CP-40 project. Papers discussing the idea of a
time-sharing system began being published about 1959.
There followed a period of experimentation at MIT and other
institutions. An early version of CTSS was demonstrated on an IBM 709
at MIT in November, 1961. From that beginning, CTSS evolved rapidly
over the next several years and taught the world how to do
time-sharing.
CTSS was developed on a series of IBM processors. In the 1950s, IBM's
president, T.J. Watson, Jr., had very shrewdly given MIT an IBM 704
for use by MIT and other New England schools.
Then, each time IBM built a newer, bigger processor, it upgraded the
system at MIT.
The 704 was followed by a 709, then by a 7090, and finally by a
7094. IBM also gave MIT the services of some highly skilled Systems
Engineers and Customer Engineers, who formed its MIT Liaison Office,
which was housed at the MIT Computation Center.
As CTSS evolved, Professor Corbato and his students and colleagues
began to encounter problems that they knew were better addressed by
hardware than by software, so they asked IBM for modifications to
their processor. The IBMers in the Liaison Office had the job of
finding engineers in Poughkeepsie to build the hardware extensions
that MIT had determined were necessary to do time-sharing properly.
By the time CTSS was in full production in 1963, the 7090 at MIT had
been modified to have a second memory bank (32K words), an address
relocation register, and memory protection. With these extensions to
the hardware, Corbato's group was able to build CTSS into the system
that became the exemplar for time-sharing systems.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Dispute about Internet's origins Newsgroups: alt.folklore.computers Date: Thu, 16 Sep 1999 21:02:47 GMT... from footnote in melinda's paper
From the preface to the "candy-striped manual" (F.J. Corbato, M.M. Daggett, R.C. Daley, R.J. Creasy, J.D. Hellwig, R.H. Orenstein, and L.K. Korn, The Compatible Time-Sharing System: A Programmer's Guide, The MIT Press, Cambridge, Mass., 1963): The only other general purpose time-sharing system known to be operating presently, that of the Bolt, Beranek and Newman Corporation for the PDP-1 computer, was recently described by Professor John McCarthy at the 1963 Spring Joint Computer Conference. Other time-sharing developments are being made at the Carnegie Institute of Technology with a G20 computer, at the University of California at Berkeley with a 7090, at the Rand Corporation with Johnniac, and at MIT (by Professor Dennis) with a PDP-1. Several systems resemble our own in their logical organization; they include the independently developed BBN system for the PDP-1, the recently initiated work at IBM (by A. Kinslow) on the 7090 computer, and the plans of the System Development Corporation with the Q32 computer. To establish the context of the present work, it is informative to trace the development of time-sharing at MIT. Shortly after the first paper on time-shared computers, by C. Strachey at the June 1959 UNESCO Information Processing Conference, H.M. Teager and J. McCarthy at MIT delivered an unpublished paper Time-Shared Program Testing at the August 1959 ACM Meeting. Evolving from this start, much of the time-sharing philosophy embodied in the CTSS system has been developed in conjunction with an MIT preliminary study committee (initiated in 1960), and a subsequent working committee. The work of the former committee resulted, in April 1961, in an unpublished (but widely circulated) internal report. Time-sharing was advocated by J. McCarthy in his lecture, given at MIT, contained in Management and the Computer of the Future (MIT, 1962). Further study of the design and implementation of man-computer interaction systems is being continued by a recently organized institution-wide project under the direction of Professor Robert M. Fano.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Examples of non-relational databases Newsgroups: comp.databases Date: Fri, 17 Sep 1999 19:15:33 GMTIMS
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: High Availabilty on S/390 Newsgroups: bit.listserv.ibm-main Date: 09 May 1999 12:40:46 -0700 > > denisb@interlog.com (Denis Belton) writes: > I have been tasked with providing 7/24 availability or as near as possible on > the S/390 server platform. Environment is 9671 RB6 under OS/390 V2R6. There > are no plans to implement parallel SYSPLEX. > > I plan to inventory the reasons why we currently do IPLs and attempt to > eliminate or reduce them. Other areas to investigate are dynamic LLA and LPA, > dynamic I/O config using HCD. > > Any other suggestions would be most appreciated. Thanks in advance. when my wife was con'ed into going to POK to be responsible for loosely-coupled ... she origanted the Peer-Coupled Shared Data architecture that was eventually the basis for IMS hot standby and then parallel sysplex. later when she & I were running the skunk works turning out high availability cluster multiprocessing product ... I got a chance to author a section in the corporate continuous availability strategy document ... unfortunately both the rochester and the POK groups non-concurred with the section as not being able to be met (by them). recently one of the large financial settlement infrastructures credited the two primary things contributing to them having 100% availability for the last six years are • ims hot standby • automated operator i.e. as other kinds of failure modes have been dealt with ... operator "failure modes" have started to become significant percentage of all failures -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: High Performance PowerPC Newsgroups: comp.arch Date: Sat, 18 Sep 1999 05:12:44 GMTDel Cecchi writes:
It was being written in PL.8 and at one point at something like 120 PL.8 programmers working on it (between austin and ykt)
To save the hardware/software project they decided to try the "new" unix game ... and got the company that did the IBM/PC unix to do one for Austin ... turning the wordprocessor into PC/RT.
The caveat was that the wordprocessor team already understood the hardware (but not C or Unix) and so were going to provide an machine abstration layer to the 3rd party unix developer (the VRM ... written in PL.8 by the wordprocessor team). The claim was that the 3rd party unix would be able to port to the VRM abstration layer faster than the real hardware.
The problem was that the VRM abstration layer introduced a totally different device driver model ... and had other problems ... so the port in fact took significantly longer than if the port had been to the bare hardware.
By comparison the Palo Alto AOS team ported BSD4.3 to the (PC/RT) bare hardware using less than 1/10th the people and 10% of the time that went into just the VRM (not even comparing the combined VRM+UNIX effort).
somewhat related:
https://www.garlic.com/~lynn/99.html#36
https://www.garlic.com/~lynn/99.html#64
https://www.garlic.com/~lynn/98.html#25
https://www.garlic.com/~lynn/98.html#26
https://www.garlic.com/~lynn/98.html#27
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: early hardware Newsgroups: bit.listserv.vmesa-l Date: Thu, 16 Sep 1999 18:19:27 -0700my first (studeent summer) programming job was re-implementing 1401 MPIO on 360/30.
University had a 709/1401 pair where the 1401 did tape<->unit record front end for the 709. My job was to re-implement the MPIO program on the 360/30 ... where the same (1401) unit record gear had been switched (I designed my own device drivers, interrupt handler, multitasker, storage manager, console/command interface, etc). The 1403/2540 were moved from the 1401 to the 360/.30 (and the 1401 retired) ... until I got the 360 version running, the 360/30 ran the 1401 MPIO program in 1401 emulation mode.
Boeing formed BCS Jan. 1969 and that spring they con'ed me into giving a one week computer class for the BCS technical staff (i was still undergraduate and taking classes ... but they wanted me to teach the BCS technical staff a computer class). I was then hired for the summer as a full-time, supervisor level grade employee. I rented part of a house from one of the 747 test engineers (you could see 747 serial #3 periodically flying over seattle ... and the 747 "sales" group had a mock up and a write up that 747 carried so many passengers that they would be never serviced with anything less than four jetways).
That fall, I was a full-time BCS employee on educational leave of absence, a full-time student, and a IBM time-slip employee (all at the same time). IBM had a beta-version of the first CICS installed at the university and my job was to debug it and get it running.
'69 was the last summer I was in Seattle until last May when I came back to work with a company to do the X9.59 reference implementation.
there recently has been quite a bit of early hardware discussion on alt.folklore.computers ... especially with respect to time-sharing, ctss, and early 7090/7094.
Anne & Lynn Wheeler lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: early hardware Newsgroups: bit.listserv.vmesa-l Date: Fri, 17 Sep 1999 23:01:48 -0700re: teaching computing systems at boeing ....
IBM also had me teach part of a one week class the summer before down at some IBM ed center location near beverly hills hilton. Also, I periodically had evening time at the IBM datacenter (on university in seattle) and they would let me help with the MVT class.
some related stuff in that period (including part of presentation I gave
at Atlantic City share in '68):
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/94.html#2
https://www.garlic.com/~lynn/94.html#18
https://www.garlic.com/~lynn/96.html#9
https://www.garlic.com/~lynn/96.html#10
https://www.garlic.com/~lynn/96.html#39
https://www.garlic.com/~lynn/99.html#44
https://www.garlic.com/~lynn/99.html#76
https://www.garlic.com/~lynn/99.html#77
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Q: S/390 on PowerPC? Newsgroups: comp.arch Date: Tue, 21 Sep 1999 16:12:12 GMTthere is electronic check presentment project with the FRB & others here in the states ... deploying POS terminals that handle the paper integrated with other kinds of card processing (credit & debit) ... however that still leaves settlement.
somewhat related:
https://www.garlic.com/~lynn/99.html#71
slightly related
https://www.garlic.com/~lynn/95.html#11
https://www.garlic.com/~lynn/95.html#13
&
https://www.garlic.com/~lynn/aadsm3.htm#imicro
https://www.garlic.com/~lynn/aadsm2.htm#integrity
https://www.garlic.com/~lynn/aadsmail.htm#comfort
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: EBCDIC binary Conversion Question Newsgroups: bit.listserv.ibm-main Date: Tue, 21 Sep 1999 19:15:13 GMTthe mainframe telecom ebcdic<->ascii translate tables (btam, qtam, etc) were flaky because the ibm controllers assumed the leading bit went into the low-order bit position ... while tty/ascii stuff put the leading bit in the high-order bit position (i.e. incoming telecom ascii streams in mainframe memory appeared bit reversed). All of this was futher complicated because 7bit ascii could be no-parity, odd-parity, or even-parity (i.e. the 8th/parity ascii bit could be zero or one when it appears in mainframe memory depending on no-parity, even-parity, or odd-parity).
so ebcdic<->ascii translate tables depends not only on parity ... but whether or not they are on the mainframe side and are taking into account the difference in transmission convention.
slightly related:
https://www.garlic.com/~lynn/95.html#14
https://www.garlic.com/~lynn/96.html#30
https://www.garlic.com/~lynn/98.html#2
https://www.garlic.com/~lynn/98.html#34
https://www.garlic.com/~lynn/99.html#99
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Computer supersitions [was Re: Speaking of USB ( was Re: ASR 33 Newsgroups: alt.folklore.computers Date: Tue, 21 Sep 1999 19:50:15 GMTin early 70s for vm/370 we did a user level "INDICATE" command that gave smoothed system average of cpu utilization, real memory utilization, paging rate, and "expansion" ... ( (queuing delays) + use) / use
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: sysprog shortage - what questions would you ask? Newsgroups: bit.listserv.ibm-main Date: Wed, 22 Sep 1999 01:25:40 GMTcp/67(precursor to vm/370;vm/esa;etc) was generated as card deck and had a modified copy of the BPS loader in front ... so that it could be IPL'ed from cards ... or card image on tape & IPL'ed from tape. The CP/67 card deck image would load itself into memory and then write itself back out to disk ... from which it could be ipl'ed normally.
BPS (basic programming system) had lots misc. card stuff ... loader was required to load stuff from standard cards. There was also a trick with "3card loader" and BPS program that would generate ipl'able card image decks. This was the process that was used to generate the BPS loader ... but could be used on programs other than the loader.
All of the card stuff worked ipl'ing real cards ... or card images on any tape drive.
CP/67 (and virtual machine follow-ons) also had to simulate the hardware IPL process on devices that the real hardware supported IPL. By version 3 of CP/67 very few people were punching real cards ... they were punching virtual cards and running the production sysgen process in a virtual machine ... and/or writing the card image to tape.
This was also the process used thru-out VM/370 ... although the modifications to the original BPS loader got a little more extensive.
somewhat related
https://www.garlic.com/~lynn/94.html#11
https://www.garlic.com/~lynn/94.html#15
https://www.garlic.com/~lynn/98.html#9
https://www.garlic.com/~lynn/99.html#9
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch Date: Wed, 22 Sep 1999 03:13:31 GMT... from the archives ... I don't remember if the number was from an FRB report or a FSTC report.
------------------------------
From: Lynn.Wheeler@xxxxxxxx Date: Mon, 25 Jan 1999 13:47:12 -0800 Subject: Re: UCC attribution procedures note that financial industry draft standard payment standard x9.59 postulates securing any retail payment transactions (credit, debit, atm, etc) with just a digital signature ... w/o requiring encryption of any data ... and can do this for all electronic payment environments (including point-of-sale) and reducing the level of fraud in all environments that it is used (actually says something about preserving the integrity of the financial infrastructure for all electronic retail payments with just a digital signature) the issue then is the amount of fraud reduction & infrastructure improvement greater than the cost of the infrastructure change. one such benefit postulated (including the epay/check example) is the infrastructure costs of processing a paper check is significantly higher than the cost of an x9.59 debit transaction (there is a slightly correlated fraud assumption ... that w/o a paper check, random people can't arbritrarily make withdrawals from you checking account). there is a strong desire to eliminate all paper check processing, one claim is that current paper check processing in the US represents a (unjustifiable?) noticable percentage of the GNP. the issue isn't just that electronic things need to be done just because of the advent of the internet ... but also that the internet can help be a catalyst as well as reduce some of the deployment costs for transition to digital signed electronic transactions that have additional justifications. i also like to think that the x9.59/aads community was one of the first to highlight the distinction between prior & no-prior business relationships in relationship to electronic transactions. Please respond to Digital Signature discussion <DIGSIG@LISTSERV.TEMPLE.EDU>
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Thu, 23 Sep 1999 01:32:45 GMTwith respect to running legacy applications on PC hosted virtual machine, see
with respect to PARS from above reference, it was the precursor to ACP (airline control program) which evolved into todays' TPF (transaction processing facility) ... which forms the basis of a number of the airline res. systems.
with respect to using legacy code hosted on various PC platforms ... there may be various price/performance considerations favoring the PC platform ... but the legacy system attributes offer various advantages (pre-existing function, automated operator infrastructure, etc). For existing applications, the use of less expensive components to host the application may be an attractive alternative to rewriting (as in reference above regarding airline res "routes" rewrite).
With regard to check processing costs in the US ... large percentage of the checks are monthly bill mailings. The paper processing includes biller receiving the envelope, opening the envelope, transcribing the paper information, transporting the check to the commercial bank, commercial bank processing the check again. If the check isn't drawn on the same bank ... the check then has to be forwarded to the bank (there is a national clearing center where lots of planes from all over arrive late at night ... trucks take the paper to the sorters, they sort for a couple hrs and the trucks take the paper back to the planes ... and the planes return ... supposedly something like half of the high-end check sorters in the world are there), when the checks finally get to the consumer bank then they have to be sorted again (at least once more), microfilm, and in some cases stored so that they can be returned to the originator.
One of the problems with early high-end check sorters were they required real-time interrupt processing ... special modifications to operating system had to be done to support handle real-time interrupts.
some trivia ... there was previous activity to map 370 to 801 ... something like 15 years ago ... called fort knox ... i helped author report that killed it.
given price/performance & feature/function ... how somebody chooses to deploy their legacy applications should be straight forward business decision.
another trivia ... what is the connection between:
https://www.garlic.com/~lynn/internet.htm
& demise of RP3?
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Mainframe emulation Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 24 Sep 1999 02:35:02 GMTthere are lots of mainframe programs that don't require 4-5 nines availability ... and could be retargerted to platforms with other types of characteristics ... assuming the price/performance and feature/function made sound business sense.
i know of one place that had developed a 407 accounting package ... and it was ported to a 1401 emulating a 407 (plug boards, sense switches, etc) ... which was then ported to a 360 mainframe emulating a 1401 emulating a 407 ... and eventually upgraded to a 370. question of whether the program ran correctly or not was based on the emulated 407 sense switches that was printed on the last page of output. after many years if the sense switch printout was not what they were accustom to .. they just reran it.
there are very broad range of applications running on existing mainframes with a very broad range of availability & reliability requirements. claims about there being a single, homogeneous class of mainframe requirements for all mainframe applications are false.
Mainframe emulators can make very sound business sense with applications that have the appropriate requirements.
couple references to mainframe availability and operation:
https://www.garlic.com/~lynn/94.html#23
for IMS database development group allowed them to remote one 300 person organization 15 miles away (in one case) and in another case remote 300 person group in a new building on the other side of an interstate. I emulated a 370 channel (at the time expected BER of 10**-15) with a T1 communication link ... in the case of remoting the development group across the interstate ... used a optical (infrared) T1 modem and exhibited increase BER during rain and snow conditions (although during one heavy snow storm where there appeared to be total white out and nobody could get into work ... still managed to successfully get data from one side of the interstate to another).
This led to problems several years later
https://www.garlic.com/~lynn/94.html#24
where the expected channel error occurance for the total world-wide (latest model) mainframe install base over the period of 12 months (i.e. somewhat equivalent to a scsi buss error) was three ... and because I chose to simulate a channel error under certain conditions ... the total install base of all machines for all customers in the world for the whole year showed a total of 15 (instead of 3) such errors in the reports. This was of very serious concern to some people.
On the other hand ... fixing the following problem
https://www.garlic.com/~lynn/99.html#31
was "nice" ... even tho it only had significant effect on very small percentage of customers were seeing mean-time between MVS system crash of 15 minutes.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Dispute about Internet's origins Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens Date: Fri, 24 Sep 1999 16:24:54 GMTwith regard to nsfnet costs ... it that the calculation based on the amount of the nsfnet contract ... or based on the cost of the amount of resources actually involved in nsfnet (which possibly were supplied by commercial companies far in excess of the size of the nsfnet contract)???
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 (and descendants) VM system? Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 24 Sep 1999 21:47:48 GMTcambridge had a special, custom relocation box added to an ordinary 360 model 40 ... on which they developed cp/40 ... there was only one of a kind built supporting virtual memory
when the standard 360/67 product came along (a standard product offering, essentially a 360/65 with relocation hardware added ... the 67 could run in either 65 mode or 67 mode) ... the cambridge group ported cp from the model 40 to the 67 (resulting in the cp/67 product).
there was a "duplex" 360/67 (two processor model) that had a lot more engineering done to it ... and was quite a bit different from the two processor 360/65 SMP product.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Dispute about Internet's origins Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens Date: Fri, 24 Sep 1999 22:23:21 GMTsomewhat related article:
IBM'S MISSED OPPORTUNITY WITH THE INTERNET
Source: DAN GILLMOR column
IN 1980, some engineers at International Business Machines Corp. tried
to sell their bosses on a forward-looking project: connecting a large
internal IBM computer network to what later became the Internet. The
plan was shot down, and IBM's leaders missed an early chance to grasp
the revolutionary significance of this emerging medium. This is one of
those who-knows-what-might-have-been stories, an intriguing little
footnote in Internet history. It's a cautionary tale
Published on September 24, 1999, Page 1C, San Jose Mercury News (CA)
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 (and descendants) VM system? Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 24 Sep 1999 23:03:18 GMTalso ... some discussion about virtual memory on 370 at:
(i.e. 370 was initially shipped prior to virtual memory announcement).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 (and descendants) VM system? Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 25 Sep 1999 06:45:38 GMTCP/67 was done by the cambridge scientific center at 545 tech. sq in Cambridge ... by some of the same people that had worked on CTSS. The original system had been implemented on a custom modified 360 model 40 and referred to as cp/40 ... and then later ported to 360/67 when it became available.
see
VM and the VM Community: Past, Present, and Future, revised 08/16/97
https://www.leeandmelindavarian.com/Melinda#VMHist
three people from cambridge came out and installed CP/67 at the university that i was at in jan. 1968 ... this was the third installation after Cambridge and Lincoln Labs.
We also had TSS available for testing ... in jan. 1968, TSS with four users doing interactive work had poor performance and poor response times. CP/67 running on the same hardware doing similar type of edit and fortran compile and execute would support 10-15 users with reasonable response.
misc. reference
https://www.garlic.com/~lynn/94.html#37
https://www.garlic.com/~lynn/94.html#46
https://www.garlic.com/~lynn/94.html#53
https://www.garlic.com/~lynn/94.html#54
https://www.garlic.com/~lynn/94.html#55
https://www.garlic.com/~lynn/98.html#28
one set of 360 cronology
https://web.archive.org/web/20010218005108/http://www.isham-research.freeserve.co.uk/chrono.txt
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 (and descendants) VM system? Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 25 Sep 1999 15:01:50 GMTafter first starting on fair share in the late '60s (& trying to integrate fair share advisery ... with scheduling to the bottleneck ... i.e. biasing the fairshare calculations to the resource consumption representing the system bottleneck) ... i did a specific guideline non-fair-share advisery integrated with fair share in the '70s ... which operated at both the user as well as collections of user level.
I was dealing with a number of internal computing sites to which I offered to install the new feature.
The typical response was no way.
Head of IS departments frequently have to sit around in regular user review meetings and listen to complaints about all the bad things that have happened and demands for new types of services.
The comments were pretty uniform that if there was a facility to offer non-fair share with explicit controls ... the squabling between the different departments demanding explicit non-fair-share would never allow the review meetings to adjourn.
reference to internal computing sites:
https://www.garlic.com/~lynn/99.html#112
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Q: S/390 on PowerPC? Newsgroups: comp.arch Date: Sat, 25 Sep 1999 15:06:19 GMTto put some of this perspective ... 800-number lookup (i.e. 800 numbers are table lookup mapping to some real number) had requirement of maximum of five minutes of downtime per year (both scheduled and unscheduled, including operating and application system upgrades).
related post about 100% for six years:
https://www.garlic.com/~lynn/99.html#128
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Q: S/390 on PowerPC? Newsgroups: comp.arch Date: Sat, 25 Sep 1999 15:19:27 GMToh yes ... a couple of years ago one of the large national realtime financial processing centers had its roof collapse from snow and the hot backup had been in the world trade towers ... and they hadn't gotten around to recreating it at new location. it was gone for several hours until they got a site up and fully operational.
about ten years ago when I was doing high availability ... i coined the terms disaster survivability & geographic survivability (in part to distinguish from simple disaster recovery).
typically this means harden, bunkerred sites with UPS, generators, large onsite resovoirs of fuel ... near hospitals or other emergency facilities so they share in utility service with highest class of availability ... and then replicated at minimum of two sites with large geographic seperation that are chosen from 100 year studies to be suseptible to different kinds of problems.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Dispute about Internet's origins Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens Date: Sat, 25 Sep 1999 15:40:30 GMTthe question wasn't how much did NSF pay for NSFNET1 & NSFNET2 ... the question was what was the price of the resources that commercial companies actually installed for NSFNET1 & NSFNET2.
misc comments:
https://www.garlic.com/~lynn/99.html#40
https://www.garlic.com/~lynn/98.html#59
NSFNET1 contract called for T1 backone between a number of sites ... I was in the NCAR room and a couple others. Large room with rack of IBM PC/RTs with interface adapter cards supporting 440kbit transmission connected to IDNX telco multiplexors ... multiplexing multiple 440kbit channels into T1 trunks operating between sites.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Dispute about Internet's origins Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens Date: Sat, 25 Sep 1999 15:48:41 GMTi would even guess that they learned something by the time they tried the high performance storage system lab and the high performance network initiatives ... the vendors were asked to contribute equipemnt for free and the vendors could bask in the glow of the publicity.
I remember talking to some of the participants somewhat after some of the press releases ... one of the pacific rim countries had invited all the US participants in the US high performance network initiaive over and ordered/payed for a duplicate of the US installation.
it somewhat idlely crossed my mind who were they going to be most responsive to, an organization that asks for free donations or organization that pays in full for the installation.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 (and descendants) VM system? Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 25 Sep 1999 16:40:25 GMTthere were a couple other things did.
I did a lot with paged map file system in the 70s on VM that was never released outside of internal installations. It had all sorts of advisery parameters that affected the region of virtual memory occupied by the mapped object.
another was work done at Cornell by Bob Cowles ... they developed scheduling and other performance modifications to virtual machine product ... that was eventually being sold as a product add-on to the base IBM product.
VM ran both conversational time-sharing (CMS) and batch (typically some form of guest operating system) and frequently concurrent in mix-mode operation.
Part of Bob's work was to be able to create advisery guidelines regarding the page fault rate for specific virtual memories (i.e. rather than optimize to virtual memory size objectives ... directly drive off of page fault rate). The most trivial implementation was when selecting a page for replacement ... if the page fault rate was higher than the objective for the task that owned the associated virtual memory space ... possibly return the page to active state and keep searching.
The issue here is the shift in computing resource bottleneck between the 60s and the late 70s.
reference:
https://www.garlic.com/~lynn/95.html#5
i.e. in situations where real memory is the bottleneck ... place greatest weight based on various real memory related consumption optimizations (pages currently active in real memory). however, when bottleneck shifts to moving pages between real memory back&forth backing store ... then rather than trying to indirectly optimize that resource by management associated with number and kind of pages resident in real memory ... tie the optimization directly to the resource bottleneck ... i.e. frequency of pages having to be moved.
the only URL reference I've got at the moment to cornell work is
http://www.marist.edu/~mvmuajs/vmoutlook/vmprog.html
Bob is currently at SLAC (or last time I talked to him)
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 (and descendants) VM system? Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 25 Sep 1999 18:25:33 GMTother virtual machine activity ... ADMS ... now
in 1977, I transferred to San Jose Research to work with VM system that they were going to install. While waiting for the machine to install, I would commute up to Palo Alto to help with the HONE consolidation at 1501 California.
I had been supplying HONE system with CP & CMS infrastructure from nearly the beginning. When EMEA moved to La Defense in Paris (from the states) I hand installed a HONE clone for them. When HONE needed first install in Asia, I did it for them.
One of the most prevelent uses of the early virtual memory management work was HONE. The original VM support for additional virtual memory features was limited to the "IPL" command simulation i.e. an image of specific virtual pages were captured and stored in a CP area that was only accessible via the "IPL" command simulated ... which included a complete reset of the virtual machine operation in addition to mapping specific virtual page contents into the virtual machine address space.
The IPL by name feature was used to do 1) fast starts for guest operating systems (the image saved was well after lots of guest operating system functions had been performed ... which might normally take several minutes) and 2) "share pages" (i.e. IPL-by-name control tables could specify shared memory areas where all virtual machines would point to a single set of pages in memory).
The major HONE deployed application to all of the world-wide field had been implemented in APL. There was a mechanism where a combined image of CMS plus the APL application were saved and automatically "IPLed-by-name" when branch office personel logged into the system.
An opportunity for HONE was that while the main online environment for the branch office people was platformed & encapsulated within APL but several of the applications that they needed access to might be other kinds of CMS applications (high on their prioriety were various "configurators" written in Fortan ... starting with 370/125 all mainframe configuration orders had gotten so complex that they could not be done w/o using HONE ... most of these were APL applications but several involving performance & thruput modeling were done in Fortran for performance). IPL-by-name provided no facility for dynamically switching back & forth between multiple different applications.
As part of my CMS paged-mapped file system that I had original started on CP/67 ... I included numerous flavors of page sharing specification at the application level within the CMS file system w/o having to resort to IPL-by-name command.
A major use of this feature was by the various deployed HONE systems to effect transparent transition back & forth between APL operation and FORTRAN applications.
For VM/370 verison 3, the development group picked up most of the internal CP kernel changes ... but none of the CMS changes ... so they had to platform the API off the existing IPL-by-name facility ... resulting in the LOADSYS/diag98 api implemenation.
HONE had also done a simple EXEC for backing up all the branch office file system areas ... it would cycle thru all the file areas for the various branch offices people ... dumping their files to tape using the VMFPLC command.
The main work during the fall of 1977 in Palo Alto was implementing SMP support in VM/370 release 3 so that by YE77, they were running production SMP operation.
One of the other tasks I undertook was to completely rewrite their simple backup exec. The first thing I did was to rewrite the tape I/O interface. The CMS "VMFPLC" command that they had been using for tape operation when writing to tape were generating tapes that were 50%-90% inter-record gap on the newer 6250 BPI tape drives. Other functions done to the exec was:
1) tape library ... keeping track of which tapes were used and not used 2) CMS simulated tape label function (similar to OS/360 tape label function ... in part as safety catch when operators might mount the wrong tape 3) history of files backed up (and which tape they were on). 4) incremental file-backup capability 5) interface to find & restore files on user's behalf
I called the rewritten function CMSBACK and by 1979 it was the production backup facility for HONE, San Jose Research, and many of the disk engineering locations in the San Jose area.
During 1980 the number of instatllations continued to grow, adding Los Gatos, Santa Teresa,
In 1981, I worked with Mark Brown to do a version two of CMSBACK, which included migrating of some number of the functions out of EXEC into compiled code and creating a demon that can directly accessed by users for restoring files (rather than having to go thru support person for restore requests). Mid-1981 was the first attempt to make CMSBACK available to a larger audience as a prodduct (instead of simply internally developed tool).
Mark Brown left IBM in the spring of 1982 (and went to work on similar activities for vm backup and archive products for another vendor after "version 2" was finished). Bob Rees replaced him on the CMSBACK effort and started work on CMSBACK version 3.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Q: S/390 on PowerPC? Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 25 Sep 1999 18:34:11 GMTfor another comparison ... dialog (online library information & abstracts, was subsidary of Lockheed at the time) computing center had around 300 drives in the early 80s attached to IBM mainframe.
tymshare, dialog, and HONE (ibm branch office and field online support) datacenters were probably all within 8-9 miles of each other at the time.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Q: S/390 on PowerPC? Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 25 Sep 1999 18:47:52 GMTback then a large mainframe computing center installation easily running to tens of millions of dollars and 60% or more would be for the disks.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Mon, 27 Sep 1999 16:37:49 GMTI think TPF has similar type of availability numbers for unscheduled downtime ... based on large collection of clustered mainframes. However, I've seen them have scheduled outages. I believe part of it is that the disk/data management facilities (TPF data management has been relatively primitive ... highly streamlined for specific kind of transactions) periodically require some sort of offline re-org. My youngest had a job with air freight forwarder during college and he said it wasn't unusually for some to overrun their offline window and still be down when he started his shift.
In the past, I've been in the far east and trying to change schedules bright and early Monday morning and told that the system was still down.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Mon, 27 Sep 1999 18:10:52 GMTand when i was asked to redo routes several years ago ... that particular operation had a top ten problem list which included offline re-org ... misc ref:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Are there any really large commercial databases? Newsgroups: comp.databases Date: Tue, 28 Sep 1999 00:28:20 GMTsome of the nasa databases have been talking about growing to petabytes (1000 terabytes) ... but they are typically mulit-megabyte records, relatively small number of records, and few update/inserts per day. others playing in this area are possibly oil exploration ... with maybe hundreds of terabytes.
there are commercial databases that are much smaller (few number of terabytes) but have much smaller records and only process from half million to 20 million insert/updates per day and only have tens of billions of items.
while total physical size is one measure of database limits ... total number of records managed and number of insert/updates can be a much more telling characteristic of the database capability.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 28 Sep 1999 04:14:27 GMT1419s on MVT could be done with PCI (flag in I/O commands to generate a program controlled hardware interrupt) and interrupt appendage (application specified routine that received control during kernel interrupt processing)
VS1 on 370 required "SCP PRPQ" (kernel modification) to support check sorter (early 70s ... starting circa 1973).
description of A national processing center .. but it has grown
somewhat since then
http://www.unisys.com/news/releases/1995/jan/01045747.html
there are also urban legends about local exchange operation in the san fran area.
description of the federal reserve hub/spoke system
http://www.federalreserve.gov/boarddocs/testimony/1997/970916a2.htm
real early 1419 reference ...
http://www.geocities.com/SiliconValley/Lakes/5705/1401.html
some processing notes about check sorting:
http://www.comdisco.com/bc/disaster_nashville.html
http://www.comdisco.com/bc/item_processing.html
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 28 Sep 1999 06:52:46 GMTand for some interesting discussion about federal reserve settlement (as distinct from paper check forwarding) ... especially with regard to the difference between intra-district versis inter-district settlement
the GOA report referenced in the above with regard to systemic risk
is:
Payments, Clearance, and Settlement: A Guide to the Systems, Risks, and
Issues (Chapter Report, 06/17/97, GAO/GGD-97-73)
and is available from the www.gao.gov site.
Some time ago, I merged the glossary from that report with others
and it is available at:
https://www.garlic.com/~lynn/payment.htm
and also
https://www.garlic.com/~lynn/financial.htm
although I suggest checking the glossary notes at
https://www.garlic.com/~lynn/
before referencing the financial glossary
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 28 Sep 1999 18:27:02 GMTwe had a good update & demos on iris scan (not nearly as intrusive as retina scan) at FSTC last week
a problem is that it still requires secure sensor/scanner (normally not owned by the person being sensed).
one of the things that I hadn't realized was not only is iris different in identical twins ... but that left & right iris are different (i.e. DNA doesn't handle cases of identical twins) and it even works with blind people (unless they lack both eyeballs totally).
we are within goal of being able to put finger-reader right on an AADS
card owned by the person... and use it only for card activation (so
that biometric information never leaves the person's control) ... part
of the discussion is at:
https://www.garlic.com/~lynn/aadsm2.htm#straw
although finger-reader on some of the non-card form factors is still an issue (not as bad on cell phone or PDAs).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Wed, 29 Sep 1999 17:48:14 GMTactually have had some amount of problem with TCP/IP and some of the browser vendors. Most large servers have POP (point-of-presence) attachment to the internet at least one place ... and with hierarchical routing in the Internet ... can't have multiple POPs into different places into internet backbone with different IP address. Only some of the IP boxes are now just starting to show signs of "telco provisioning" technology.
So standard process is to have multiple attachments into the backbones all with different IP addresses and rely on DNS name server to map multiple IP addresses to the same host name. The problem I had was getting the browser companies to actually support multiple DNS "A-records" ... the brain dead example in most TCP books just has the code pulling the (one & only) ip address out of the ip-lookup reply and doing connect. If the connect fails they give up.
The HA logic was if the connect failed ... check to see if the address-lookup returned more than one ip address ... and try connects on the other ip addresses. Mid-90s, some of the browser developers would tell me that multiple A-record support was too new/advanced ... even tho I could pull examples from source code on the 4.3 tahoe distribution .. nearly ten years previous ... real problem was that it didn't show up in any of the examples used by college student texts.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 02 Oct 1999 16:53:25 GMTmy comment about multiple A-record support was the example didn't show up in the typical college text on tcp/ip. it was trivial to pull code example from TELNET/FTP clients on BSD 4.3 TAHOE (base code for large percentage of commercial implementations during the late 80s and early 90s).
related reference:
https://www.garlic.com/~lynn/94.html#34
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 02 Oct 1999 16:46:02 GMTeasier for crooks? .... quick hit & run robbery typically is much simpler than maiming/killing and carrying around degradable biological material.
one of the big issues on biometrics (fingers, iris, face recognition, retina scans, etc) has nearly alwas been building in methods to check for liveness (i.e. it isn't being spoofed by some method that would result in the scanner reproducing the same electronic signature for the biometric sensor). The other for secure scanners has been evesdropping ... just recording the biometric signature produced by the scanner ... and injecting the signature directly into the infrastructure (with scanner cut-out).
the traditional 3-factor authentication security scenerio has alwas been
• something you have,
• something you know, and
• something you are.
ATM so far has only been two-factor ... something you have (card) and
something you know (pin ... but really rather weak). Going to
3-factor authentication doesn't seem to be easier for 3rd world
crooks (they've alwas had the option of killing ... there are the
stories about people being killed mailing a letter for the value of
the stamp).
Issue for security has alwas been does the cost outweight the benefit ... i.e. are the significant drops in technology costs for biometric sensing enuf to deploy resulting in net benefit to the infrastructure.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: OS/360 (and descendants) VM system? Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 02 Oct 1999 17:31:43 GMToh yes ... example of supercharged VS1 (... rather long-winded example from the archives)
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: What is "Firmware" Newsgroups: alt.folklore.computers Date: Sat, 02 Oct 1999 20:42:03 GMTi think the WOM may have been done in conjunction with the paper (from Berkeley?) on recursive compression algorithm ... showing that arbritrary number of bytes could be compressed into a single byte ... it went well with what i knew of black holes ... until they published the paper on black holes evaporating.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: IBM Assembler 101 Newsgroups: bit.listserv.ibm-main Date: Sat, 02 Oct 1999 20:51:20 GMTwpb@JPS.NET (Bill Becker) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computer Date: Sat, 02 Oct 1999 21:20:19 GMTother problems with telnet/ftp/http TCP connection:
1) getting it connected reliably in the first place ... HTTP has exhaserbated (&/or helped) the problem with high frequency of very short TCP (transaction-like) connections
2) few if any of the components are telco provisioned and as soon as internet infrastructure started going to hierarchical routing ... it became very difficult to mask failures by advertising different routes for end-points
3) multiple DNS A-records would work if the client application was smart enuf to use value returned in ip-lookup as a list instead of single address and retry with each address on the list in case of failure (this has lot more benefit in HTTP case since there are all of these very short, transaction-like connections with little or no state history ... compared to telnet long running connections with potentially significant state). DNS round-robin for load-balancing slightly mitigates the problem with braindead client applications. Geographic/hop/load sensitive DNS try to make the first entry in the list ... the closest resource. However, almost all ISPs do local DNS caching (with timeouts typicaly set to hours) which negates majority of the fancy DNS list re-ordering.
4) in smaller configurations IP address take-over was also possible
for helping mask failures ... except in cases of IP implementation
bugs (ref:
https://www.garlic.com/~lynn/96.html#34)
5) the HTTP short transaction severely stressed implementations in the mid-90s because of nearly all TCP FINWAIT implemenations (after close ... keep around dangling status in case of stray packets ... FINWAIT lists were assumed to be at most a couple so there were sequential list search strategy on ever incoming packet ... until they found HTTP was resulting in 20,000+ dangling FINWAIT on the lists and 95-99% of the processor was taken up running down the list)
extraneous information
VMTP (RFC1045) with proposal to reduce minimum transaction to five packet exchange (compared to TCP seven packet exchange).
XTP
http://www.ca.sandia.gov/xtp/
https://web.archive.org/web/20020209014400/http://www.ca.sandia.gov/xtp/
would even do better, reducing it to three packet exchange.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Sun, 03 Oct 1999 15:59:59 GMTnote that simple deployment for iris scan is ATM cards where people write their PIN on the card. I believe they said that there are pilots currently in Houston.
Comparison isn't that it is impossible to spoof the iris scan ... just that it is (much) harder than finding/stealing somebody's card with PIN written on it (larger percentage than some people might think) and using it. all the technology for iris spoofing would also appear to be more complicated than forcing somebody at gunpoint to withdraw $20 from their ATM.
the finger-reader ... in addition to higher error rates ... has problems in public places ... plan, standard use with people that show up with dirty & greasy fingers ... not only causing problems for them ... but also leaving the sensor possibly inoperable for others.
from privacy standpoint ... finger-reader has slight advantage ... it
is possible to package finger-reader on a card and use it for card
activation ... so that the person's biometric information never leaves
device under the person's control. iris scan is still shared sensor
device ... so the biometric signature is exposed to devices owned &
shared by others (i.e. finger-reader on the card is only used to turn
the card on & off ... ATM machine iris sensor is used to authenticate
the transaction) ... ref AADS strawman:
https://www.garlic.com/~lynn/aadsm2.htm#straw
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Sun, 03 Oct 1999 16:33:20 GMTstill easier to force somebody to perform the operation at gunpoint ... the way some ATM robberies happen today.
iris scan looks at the face and figures out where the eye is on the face ... and then focuses in on the center of the eye & images the surface of the eye to get the iris signature. there are much easier ways to steal $20-$100 than removing an eyeball and spoofing an iris scan ... that it would seem to be well down on the list of probable actions.
for higher value security infrastructures they might be looking at multi-factor biometrics ... say face-scan, iris-scan, retina-scan, finger-length, finger-print & voice-recognition ... in conjunction with computer command/response (computer asks for randomly selected action/response) ... and all done under surveillance monitoring. the easier attacks are still forcing someone or attacks on the electronics behind the sensors ... spoofing the sensors would still way down on the list.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Sun, 03 Oct 1999 19:35:51 GMTis stealing somebody's atm card, performing non-intrusive capture of their iris, and creating an iris print on the backside of the iris ... more or less expensive than stealing/finding somebody's atm card with the PIN written on the back???
most security techniques aren't totally fail-safe ... they just have to make the level of difficulty higher than other methods yielding similar rewards &/or reduce the frequency of fraud by measurable percentage points yielding positive cost/benefit.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Sun, 03 Oct 1999 19:42:39 GMTi.e. the cost of deploying the iris scan (or any biometric authentication) methodology needs to be offset by the reduction in the rate of fraud (not necessarily make the possibility of fraud zero ... just reduce the amount of fraud by more than the cost of deploying the infrastructure).
with current reduction in technology costs ... it appears to have tipped the scales in the favor of even simple iris scan being able to reduce amount of fraud by more than the cost of the technology deployment (even if there are known possible methods of defeating the iris scan ... the cost/difficulties of those methods of defeating simple iris scan have to be higher threshold than possible investments in other form of fraud payback).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Crowther (pre-Woods) "Colossal Cave" Newsgroups: alt.folklore.computers Date: Sun, 03 Oct 1999 20:36:42 GMTfollowing is reply that I received when I was trying to track down copy of ZORK (in the late 70s). At the time I already had numerous copies of adventure in fortran and several enhanced versions written in pli ... ref:
> ZORK is a PDP-10 program written in MUDDLE, a LISP-derivative language > for which no compiler exist outside the PDP-10. It is friendly with > the I.T.S. operating system and no other. One Tim Anderson of the > Lab for Computer Science is its proprietor. > > Someone at DEC apparently took the MUDDLE source and > transliterated it to FORTRAN. I don't know how faithful > the transliteration is. It is supposed to b e available through > the DEC Users group association, DECUS. A letter to them > may turn up some information. > > Beware. ZORK is addictive. Untold man-hours will disappear into > its use, and some people will decide they want to analyze the game > itself, which is said to require a man-month or so before solutions > and algorithms become clear.--
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 05 Oct 1999 02:44:42 GMTin fact the AADS CHIP strawman ...
proposes the person own the biometric sensor and the biometric data never leaves the person's control
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 05 Oct 1999 03:44:33 GMTlook at draft X9.59 protocol that we've been working on for a couple years (charter given the X9A10 working group was to preserve the integrity of the financial infrastructure for all electronic retail payments with just a digital signature) ... and preparing the way to fasttrack to ISO. the underlying AADS is also being looked at as an implementation for FSTC FAST ... so it would be possible to not only eliminate fraudalent transactions by knowing the account number ... but be able to not have to provide web servers your name/address ... even for hardgood shipments.
various ref:
https://www.garlic.com/~lynn/aepay2.htm#aadspriv
https://www.garlic.com/~lynn/aepay2.htm#privrules
https://www.garlic.com/~lynn/8583flow.htm
https://www.garlic.com/~lynn/aadswp.htm
https://www.garlic.com/~lynn/aadsover.htm
https://www.garlic.com/~lynn/aadsm2.htm#privacy
https://www.garlic.com/~lynn/aadsm3.htm#cstech13
http://www.fstc.org/
http://www.americanbanker.com/PSUser/ABO_Story.htm?NS_adv_search=0&NS_search_set=tuc07kRZxf973468095f7f1&NS_doc_offset=0
http://www.elistx.com/archives/ansi-epay/199907/msg00026.html
https://web.archive.org/web/20010727182920/lists.commerce.net/archives/ansi-epay/199907/msg00026.html
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 05 Oct 1999 04:09:11 GMTit is much simpler to coerce/blackmail than it is to go to the trouble of killing/maiming somebody, hijacking their biometric material and then using the biometric material for impersonation. killing/maiming for biometric impersonation seems to be much more along the lines of terriost activity than fraud (i.e. financial return on investment is much lower than other methods) ... or out of the movies.
the deployment of iris scan for ATMs would appeal to people that currently write their PINs on their cards ... i.e. PIN security is frequently much weaker than hypothesized because of dealing with real live humans ... i.e. the iris scan brings ATMs up to the security hypothesized for PINs ... because real live humans frequently don't conform to what the manual specifies in the regulations.
in fact ... PIN/password lack of security is starting to be widely recognized ... not that the technologists & security experts designed poor PIN/password technology ... but because there is large percentage of the population that doesn't follow the rules laid down in the security manuals (the technology may not have been weak ... but it is weak because of PIN/password infrastructure required human actions that doesn't happen in real life).
an issue for biometrics for ATM is does the cost come down enuf so that it can be used economically to fix recognized human factor failings associated with existing PIN/password infrastructures.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 05 Oct 1999 04:13:18 GMTrelated on PIN/passwords:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: S/360 history Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 07 Oct 1999 04:28:54 GMTone other relocate for 360/67 (cp/67, mts, tss) was done by Boeing Huntsville ... for handling storage fragmentation under MVT when supporting a large number of 2250M1 involved in long running applications. This was done against a OS/360 release 13 MVT (there may have been some MVT in release 12 ... but our shop went directly from OS/360 release 11 MFT to OS/360 release 14 MFT ... MVT for most shops didn't start to look practical until the combined OS/360 release 15/16).
I didn't actually see the Boeing Huntsville system ... just talked to some of the people that transferred with the machines (two 360/67s) to Seattle around summer of '69 ... and brought up CP/67.
note that CP/67 was done originally as cp/40 on a custom, one of a kind 360/40 which had relocate box tacked on to it.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: amusing source code comments (was Re: Testing job applicants) Newsgroups: alt.folklore.computers Date: Thu, 07 Oct 1999 04:15:26 GMTwould be wall clock ... on 360/65, a three step fortran (compile step, link-edit step, and execution step) could be over a minute ... even for null program ... with almost all job scheduler.
before WATFOR ... our shop did a custom monitor that would do all three steps under monitor control (involving only single job scheduler step instead of three) ... but when WATFOR came along ... it was significantly better.
the other was to almost triple the thruput of job scheduler by careful
tuning ... compared to standard system ... as per:
https://www.garlic.com/~lynn/94.html#18
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: S/360 history Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 07 Oct 1999 15:15:34 GMTmy understanding was that the only triplex 360/67 that was built was for lockheed ... for MOHO(?) project. the normal channel director for duplex 67 was manually set (mesh interconnect between I/O channels, memory banks and CPUs ... with switches that controlled what went where).
the triplex channel director was also under program control ... hardware could be reconfigured by changing the switch settings ... addressed by combination of control registers.
one of the IBM SEs that worked on the project later joined CSC in cambridge ... and was responsible for the compare&swap instruction ... his initials are CAS ... so the mnemonic came first ... and then it was necessary to come up with words that went with the mnemonic.
ron smith in architecture insisted that multiprocessor support wasn't sufficient and it was necessary to invent some use for the instruction in uniprocessor mode ... which lead to the programming notes about how "interrupt enabled" applications could safely update fields and chains (even in uniprocessor configurations).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: S/360 history Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 08 Oct 1999 02:06:33 GMTfootnote, pg 11, melinda varian's
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: checks (was S/390 on PowerPC?) Newsgroups: comp.arch,alt.folklore.computers Date: Thu, 14 Oct 1999 12:30:34 GMTsomebody associated with program on information resources policy (http://pirp.harvard.edu/) in australia did surveys of several countries around the world on things like ATM & checks (electronic transaction, non-electronic). One of the results of the survey from several countries with regard to ATMs is that there is positive confirmation on withdrawals but not on deposits. For ATM deposits it may be at least a day or more before there is confirmation that what you thot got deposited is also what the bank believed was deposited. For deposits, having a bank employee confirm on the spot that they agree or disagree with you (and if disagree, both of you can immediately resolve the differences) is viewed as very positive beneift.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: S/360 history Newsgroups: bit.listserv.ibm-main Date: Mon, 11 Oct 1999 22:41:18 GMTwhen burlington (mass, it was in the old service bureau bldg in burlington mall) was closed and the group told they could move to pok ... many of them left the company and got jobs developing vms.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: The Watsons vs Bill Gates? (PC hardware design) Newsgroups: alt.folklore.computers Date: Sun, 17 Oct 1999 14:40:19 GMTwe setup up process for regular releases and then monthly releases for PLC or program level changes. PLC for the most part were bug fixes (although there were periodic exceptions for special function). PLC would be something like 2.15 (or release 2, PLC 15).
source control numbered changes sequentially so both bug fixes and enhancements tended to be identified by their sequential number from source code change system (even if the change spanned several modules). after 7-8 years, the numbers went past the ten thousand mark (this was when both binaries and source was shipped to customers, where the source was the internal source code infrastructure).
for the resource manager ...
https://www.garlic.com/~lynn/94.html#2
we created a set of regression tests that initially took 3 months elapsed time to run. I had been asked to do an maint. release of the resource manager tracking the PLC base product schedule. The problem was that a minimum regression tests set took 10-14 days to run. I could see no way that I could do the normal resource manager stuff, do the integration and test with the monthly PLC and also do minimum regre ssion tests at monthly intervals .. so I insisted that the resource manager PLC schedule had to be a release every three months (instead of every month).
misc. other references ...
https://www.garlic.com/~lynn/94.html#5
https://www.garlic.com/~lynn/94.html#7
https://www.garlic.com/~lynn/94.html#52
https://www.garlic.com/~lynn/95.html#1
somewhat related threads ....
https://www.garlic.com/~lynn/97.html#11
https://www.garlic.com/~lynn/97.html#14
https://www.garlic.com/~lynn/97.html#15
https://www.garlic.com/~lynn/97.html#16
https://www.garlic.com/~lynn/99.html#16
https://www.garlic.com/~lynn/99.html#17
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Merced Processor Support at it again . . . Newsgroups: comp.arch Date: Tue, 19 Oct 1999 19:19:07 GMTalso trout 3090.
308x were done by the 158 group
3090s were done by the 168 group
rather than coming out simultaneous ... they started leapfrogging each other.
misc ref:
https://www.garlic.com/~lynn/95.html#3
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Clustering systems Newsgroups: comp.arch Date: Thu, 21 Oct 1999 03:01:14 GMTmany of the customers are just looking for up time. both fault tolerant and clustered systems can address the requirements in different ways ... including combinations of the two.
several years ago looked at an environment that had a requirement for <5mins downtime per year. There was a fault tolerant message handling box that had two T1 links out the back-end to database processor. The message was sent out one T1 and if the reply didn't come in ... it was sent out the other T1. The initial assumption that they needed a fault-tolerant database processor on the backend ... however the fault-tolerant candidates at the time needed several hrs of scheduled downtime per year for various things. It was relatively straight forward to show that a clustered database implementation could meet the outage requirement ... and that the message processing to compensate/mask for T1 serial failures would also work equally well for compensating/masking a cluster member failure.
However, as general purpose hardware has been getting more & more reliable ... the frequency of outages/failures have started to drift to other areas.
great quote of off sci.crypt today
> Yes, "in theory there is no difference between theory and practice, but
> in practice there is."
misc. references
https://www.garlic.com/~lynn/96.html#13
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/96.html#27
https://www.garlic.com/~lynn/96.html#28
https://www.garlic.com/~lynn/99.html#71
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Clustering systems Newsgroups: comp.arch Date: Fri, 22 Oct 1999 17:32:31 GMTbig characteristic between fault tolerant and clusters tend to be how well transient state information is kept ... with clusters tending to maintain consistency on more of a macro stage and fault tolerant tending to maintain information consistency at much lower micro stage.
fault tolerant tend to be better at maintaining state information for things with long running state like telnet connections. clusters tend to work well where there is relatively short transactions in environment where transactions are likely to be redriven (for one reason or another).
one example of transaction redrive is from previous post:
https://www.garlic.com/~lynn/99.html#182
The mentioned backend fault tolerant hardware provided 5-6 nines (<5 minutes downtime per year) but the associated software needed scheduled downtimes on the order of hrs per year. A proposed solution to the backend downtime was to have clusters of fault tolerant boxes ... but given the frontend transaction redrive ... it was not possible to show any significant difference between clusters of fault-tolerant backend boxes and clusters of non-fault-tolerant backend boxes (except in cost & price/performance) ... they both met requirements.
other types of situations involving transaction redrive are some of
the tcp/ip related protocols (http, nfs). but there can be
misc. gotchas like:
https://www.garlic.com/~lynn/96.html#34
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Clustering systems Newsgroups: comp.arch Date: Fri, 22 Oct 1999 17:51:51 GMTalso in the late 80s when we were running around doing this sort of stuff, i coined the terms disaster survivability and geographic survivability (in part to distinguish from disaster recovery). geographic clusters address things like data center getting flooded.
situation involving large cornerstone of the financial system ... i.e.
https://www.garlic.com/~lynn/99.html#71
where neither of the two "most important" availability pieces is fault tolerant hardware.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Clustering systems Newsgroups: comp.arch Date: Fri, 22 Oct 1999 18:18:40 GMT<5min per year, <hr per decade, or approx. one shift per century; 100 year flood taking out the data center for 2-3 days can totally destroy your availability statistics for a millenium.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Clustering systems Newsgroups: comp.arch Date: Fri, 22 Oct 1999 21:42:23 GMTvarious things that take out data center
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Merced Processor Support at it again . . . Newsgroups: comp.arch Date: Sat, 23 Oct 1999 16:28:09 GMTmisc. 303x ref:
3031&3032 were actually 158 & 168 with new covers and setup to use "channel directors" for I/O. the channel directors were actually 158 with different microcode (instead of 370 instruction set ... did i/o).
3033 started out being 168 wiring logic mapped to newer/faster chip technology (got about 20% increase in performance) and then some logic tweaking (that got the rest of the performance).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Merced Processor Support at it again . . . Newsgroups: comp.arch Date: Sat, 23 Oct 1999 16:36:09 GMTi believe the Amdahl machine (Amdahl 7? or 8?) was something like 36 ciruit/chip technology and the 168 logic was mapped to something like 40 circuit/chip technology. the 168 was 4 circuit/chip technology and the initial mapping of 168 to newer technology continued to use the same 4 circuits per chip (and got its 20% performance boost just from the chips being faster). tweaking of the logic to do more onchip operation in critical areas got the remaining performance (168-3 was about 3.1mip machine ... 20% got it to about 3.7mip ... tweaking the logic then got 3033 up to something like 4.5mip).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Internet Credit Card Security Newsgroups: sci.crypt Date: Sat, 23 Oct 1999 17:36:59 GMT"Gary" writes:
we are trying to do something with X9.59 ... misc refs: at
https://www.garlic.com/~lynn/
for all electronic payment infrastructures (i.e. preserve the integrity of the financial infrastructure for all electronic retail payments with just a digital signature)
the digital signature and a couple other values by themselves are small enuf to push thru in interchange (banknet) addenda field. two issues, 1) current debit/credit typically are on the order of 60-80 bytes ... so the additional data shouldn't significantly bloat the current number of bytes flowing and 2) additional data fitting in existing interchange addenda field infrastructure (although new work item has gone to ISO to identify specific addenda field).
the other issue is the computational effort ... some work with AADS
chip strawman
https://www.garlic.com/~lynn/aadsm2.htm#straw
the device could be pin/biometric activated ... so there is no shared-secret &/or biometric/privacy information anywhere in the infrastructure.
misc. other
https://www.garlic.com/~lynn/aadsm2.htm#privacy
https://www.garlic.com/~lynn/aadsm3.htm#cstech
https://www.garlic.com/~lynn/aadsm3.htm#cstech5
https://www.garlic.com/~lynn/aepay2.htm#aadspriv
https://www.garlic.com/~lynn/aepay2.htm#privrules
https://www.garlic.com/~lynn/aepay3.htm#x959risk1
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Merced Processor Support at it again . . . Newsgroups: comp.arch Date: Tue, 26 Oct 1999 00:08:33 GMT"Shmuel (Seymour J.) Metz" writes:
Product or Event Ann. FCS Description CDC 6600 63-08 64-09 LARGE SCIENTIFIC PROCESSOR IBM S/360-67 65-08 66-06 10 MOD 65+DAT; 1ST IBM VIRTUAL MEMORY AMH=AMDAHL 70-10 AMDAHL CORP. STARTS BUSINESS AMH V/6 75-04?75-06 02 FIRST AMDAHL MACHINE, FIRST PCM CPU AMH V6-2 76-10 77-09 11 (1.05-1.15)*V6 WITH 32K BUFFER IBM 3033 77-03 78-03 12 VERY LARGE S/370+EF INSTRUCTIONS AMH V7 77-03 78-09 18 AMDAHL RESP. TO 3033 (1.5-1.7)* V6 IBM 3031 77-10 78-03 05 LARGE S/370+EF INSTRUCTIONS IBM 3032 77-10 78-03 05 LARGE S/370+EF INSTRUCTIONS IBM 3033MP 78-03 79-09 18 MULTIPROCESSOR OF 3033 AMH PLANT 78-05 AMDAHL OPENS DUBLIN, IRELAND PLANT AMH V8 78-10 79-09 11 (1.80-2.00)*V6, FLD UPGR. FROM V7 IBM 3033AP 80-06 80-08 02 3033 ATTACHED PROCESSOR IBM 3033 80-06 81-10 16 Ext. Addr.=32MB REAL ADDR.;MP ONLY AMH UTS 80-09 81-05 UTS=Amdahl Unix Op. System (under VM) IBM 3081D 80-11 81-4Q 12 FIRST H MODEL, 10MIPS IN DP, WATER COOLED AMH 580/5860 80-11 82-09 22 (2*V8, 12+ MIPS) UP, NEW,AIR COOLED TECH. AMH 580/5880 80-11 85-05 54 MP OF 5860 AT 21+ MIPS IBM 3081K 81-10 82-2Q 08 NEW DP FUM: 1.35*3081D, 64K BUFFER/OVLAP IBM 370-XA 81-10 83-03 17 NEW ARCH 3081: 31 BIT REAL/VIRT, NEW I/O IBM 3084 82-09 83-4Q 15 1.9*3081K Perf., 4 way MP, 3081K upgrade--
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Merced Processor Support at it again . . . Newsgroups: comp.arch,alt.folklore.computers Date: Thu, 28 Oct 1999 15:23:23 GMTAnne & Lynn Wheeler <garlic.com> writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: offline RFCs (RFC439) Newsgroups: alt.folklore.computers Date: Sun, 31 Oct 1999 04:23:42 GMTrecent history of old RFCs project
901 Oct 7 10:32 rfc591.txt
2579 Sep 29 11:51 rfc436.txt
2242 Sep 29 11:48 rfc434.txt
7998 Sep 29 11:40 rfc589.txt
7093 Sep 28 12:50 rfc377.txt
9059 Sep 28 12:50 rfc387.txt
10925 Jun 10 1998 rfc31.txt
8360 May 21 1998 rfc57.txt
2330 May 21 1998 rfc53.txt
5343 May 21 1998 rfc47.txt
2534 May 20 1998 rfc34.txt
2216 May 20 1998 rfc32.txt
5088 Mar 4 1998 rfc52.txt
1813 Feb 5 1998 rfc314.txt
7941 Jan 23 1998 rfc339.txt
6103 Jan 23 1998 rfc390.txt
58074 Jan 23 1998 rfc354.txt
10643 Jan 22 1998 rfc559.txt
17774 Jan 22 1998 rfc469.txt
1130 Jan 16 1998 rfc45.txt
and from
Other RFCs have been physically lost. If you have a physical version of RFC 79, 94, 178, 282, 351, 387, 455, 456, 457, 468, 478, 487, 488, 489, 491, 496, 500, 501, 504, 506, 508, 513 and 590, please send us a copy. Thanks
.....................
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Back to the original mainframe model? Newsgroups: bit.listserv.ibm-main Date: Sun, 31 Oct 1999 18:04:29 GMTnot just memory but most other features ... between 3272 and 3274 controllers they even moved a lot of the logic back into the controllers to cut down the per head costs
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: 1403 printer on a 1401? Newsgroups: alt.folklore.computers Date: Fri, 05 Nov 1999 18:15:09 GMTthe N1 cover was hydraulic cover because it was so heavy with soundproofing material .... the problem that almost everybody has experienced is that the cover would automatically raise if something happened unexpectantly inside the printer (like if it ran out of paper) ... and the top of printer was very handy surface for card trays and cups of coffee.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Anti trust suits--IBMs' compared to Microsoft Newsgroups: alt.folklore.computers Date: Mon, 08 Nov 1999 15:43:15 GMTlittle note on PCM (plug compatible) / OEM (other equipment)
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Anti trust suits--IBMs' compared to Mi Newsgroups: alt.folklore.computers Date: Mon, 08 Nov 1999 19:14:17 GMTalso ... possibly interesting reference to the ibm case
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee Newsgroups: alt.folklore.computers Date: Thu, 11 Nov 1999 15:29:55 GMTsilverpelican writes:
lots of people see the web as the browser thing that sits on their desktop ... but in fact, large parts of the web, is the stuff that sits in some closed room somewhere, running unattended w/o hiccups for days and months at a time. the mainframe/batch derivatives tend to be much better at that than the interactive derivatives.
also ... gml->sgml->html->xml markup history is as long as the
networking history
https://web.archive.org/web/20231001185033/http://www.sgmlsource.com/history/roots.htm
https://web.archive.org/web/19981206171107/http://www.sgmlsource.com/history/roots.htm
my stuff from the internet history thread earlier this year:
https://www.garlic.com/~lynn/internet.htm
other misc.
https://www.garlic.com/~lynn/96.html#7
https://www.garlic.com/~lynn/96.html#8
https://www.garlic.com/~lynn/99.html#12
https://www.garlic.com/~lynn/99.html#33
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/99.html#136
https://www.garlic.com/~lynn/99.html#136a
https://www.garlic.com/~lynn/99.html#163
https://www.garlic.com/~lynn/99.html#184
& for something completely different:
https://web.archive.org/web/20240130182226/https://www.funsoft.com/
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Life-Advancing Work of Timothy Berners-Lee Newsgroups: sci.econ,comp.ai.philosophy,comp.society.futures,soc.history.science,alt.folklore.computers Date: Thu, 11 Nov 1999 15:34:15 GMTgenew@shuswap.net (Gene Wirchenko) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: amusing source code comments (was Re: Testing job applicants) Newsgroups: alt.folklore.computers Date: Fri, 12 Nov 1999 02:53:42 GMTwasn't there something about weather bureau datacenter burning and loosing the cray1 and they are currently lost capability of 7day ... they are making do with some fill-in computers ... but are only doing 3day & 4day???
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Life-Advancing Work of Timothy Berners-Lee Newsgroups: alt.folklore.computers Date: Mon, 15 Nov 1999 18:45:30 GMTcompared to long ago, pathlengths today can be orders of magnitude longer to do the same thing ... put some aspects of the hardware has increased faster than pathlengths have increased ... in other areas the increase hasn't been so noticable.
my old standby ... just going from 68 to 83 ...
https://www.garlic.com/~lynn/99.html#4
in part ... starting to advocate for things like raid architectures.
the difference is even more pronounce another 15 years later.
what might be supported by a 286 class machine 30 years ago
https://www.garlic.com/~lynn/98.html#2
... random posting regarding more recent scale-up
https://www.garlic.com/~lynn/96.html#15
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Middleware - where did that come from? Newsgroups: alt.folklore.computers Date: Tue, 16 Nov 1999 04:12:55 GMTthe first/origin of 3-layer architecture was asked in comp.inforsystems a couple years ago ... the HSDT stuff was the earliest reference that was submitted.
https://www.garlic.com/~lynn/96.html#16
https://www.garlic.com/~lynn/96.html#17
https://www.garlic.com/~lynn/98.html#50
https://www.garlic.com/~lynn/99.html#123
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Middleware - where did that come from? Newsgroups: alt.folklore.computers Date: Tue, 16 Nov 1999 04:34:42 GMTsome of the stuff that I discussed going into the middle layer of the 3-layer architecture
• management • administration • problem determination • fault isolation • configuration • non-stop operation • capacity planning • accounting • authentication • access control • audit trails • application interfaces • software maintenancemuch of the "middleware" discussed today are just those things clients &/or client software directly interact with i.e. the application interfaces stuff ... however, in the original architecture I put several things for effective infrastructure operation.
related to various things like
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/96.html#18
https://www.garlic.com/~lynn/99.html#48
https://www.garlic.com/~lynn/99.html#49
the problem in administration is who knows about what ... the mainframe doesn't know about the PCs and the PCs hardly know about the mainframes ... leaving only the middle layer with connectivity, visibility, and awareness into all camps.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Non-blocking synch Newsgroups: comp.arch Date: Tue, 16 Nov 1999 05:03:32 GMTwhen charlie originally did CAS in the early 70s, it was single argument ... but within very short time, the very first enhancement was to be able to handle two arguments ... giving rise to the arguments being CS & CSD ... while it require the two arguments to be consecutive ... it did allow for paired pointers and other types of operation ... and justified for even non-blocking operations on multi-threaded user level code on uniprocessors (which might have race conditions because of interrupt preemption of different threads)
& not quite the original write-ups that got the instruction accepted
but ...
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/A%2e6
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Core (word usage) was anti-equipment etc. Newsgroups: alt.folklore.computers Date: Tue, 16 Nov 1999 21:09:21 GMT135/145 shipped with virtual memory hardware ... but required microload to turn it on ... after ibm announced virtual memory for the 370s (i think the standard 145 panel "light rollers" even had a light with label: "xlate" ... which raised a number of questions prior to announcement).
155/165 had to have field upgrades to add relocate hardware to them.
the original base 370 architecture included selective relocate table entry invalidate instructions (in addition to PTLB). In escalation with architecture, the 370/165 engineers said that it would delay hardware relocated retrofit package by six months if they had to support the selective invalidation instructions. The SVS (aka soon to be MVS) group claimed that an SVS/MVS system would never do more than five page invalidations per second ... so that the difference between selective invalidation and purging the whole lookaside buffer wasn't a critical performance issue ... so selective invalidation was dropped out of base 370 relocate architect on initial announce (and 135/145 microcode had to be retrofitted to not enable the corresponding instructions).
slightly related discussion of sto-stack/look-aside
https://www.garlic.com/~lynn/93.html#8
https://www.garlic.com/~lynn/93.html#25
https://www.garlic.com/~lynn/94.html#46
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Life-Advancing Work of Timothy Berners-Lee Newsgroups: alt.folklore.computers Date: Wed, 17 Nov 1999 02:02:26 GMTGene Ome writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee Newsgroups: sci.econ,comp.ai.philosophy,comp.society.futures,soc.history.science,alt.folklore.computers Date: Thu, 18 Nov 1999 17:19:00 GMTnote that IP provided the internet characteristic ... there was lots of networking & packet switching before internet ... but it was almost all homogeneous implementation ... all the players in the network communicated by having the same hardware box in the same network.
a big IP contribution in the late '70s were things like the idea of gateways and being able to do internetworking (of non-homogeneous participants).
some of this from similar internet discussion that ran earlier this
year in alt.folklore.computers:
https://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Life-Advancing Work of Timothy Berners-Lee Newsgroups: sci.econ,comp.ai.philosophy,comp.society.futures,soc.history.science,alt.folklore.computers Date: Thu, 18 Nov 1999 17:55:43 GMTwe tended to call it graceful degradation ... design for situation were some non-trivial, common failures could occur and it wouldn't be noticed ... and if faced with a catastrophic failure do a fast recovery (tradional disaster/recovery scenerio)
misc. references:
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/99.html#31
https://www.garlic.com/~lynn/99.html#54
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/99.html#145
https://www.garlic.com/~lynn/99.html#164
https://www.garlic.com/~lynn/99.html#184
& story/ref about fast restart:
https://www.garlic.com/~lynn/99.html#44
https://www.multicians.org/thvv/360-67.html
& somewhat directly related
https://www.garlic.com/~lynn/99.html#0
for some of the people participating in the XTP/TRB meetings during the late 80s and early 90s ... there was a great deal about protocol not only supporting traditional packet rerouting ... but also reliable multicast ... multiple redundant sources at multiple different physical locations doing reliable multicast to multiple redundant destinations at multiple different physical locations (not only were the networking paths redundant but the senders and receivers were also redundant).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee Newsgroups: alt.folklore.computers Date: Thu, 18 Nov 1999 18:04:01 GMTbased the RFCs and the IEN references ... TCP appeared on arpanet and was supported by the host-to-host protocol well before the IP & internetworking with gateway work was done.
from various discussions on the subject at
https://www.garlic.com/~lynn/internet.htm
IEN111 discussing applying IP/internet to the ARPANET:
In the ARPANET case, for example, the internet module would call on a
local net module which would add the 1822 leader [2] to the internet
datagram creating an ARPANET message to transmit to the IMP. The
ARPANET address would be derived from the internet address by the
local network interface and would be the address of some host in the
ARPANET, that host might be a gateway to other networks.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Core (word usage) was anti-equipment etc. Newsgroups: alt.folklore.computers Date: Fri, 19 Nov 1999 05:51:06 GMTthe following excerpts from:
IBM S/360-67 65-08 66-06 10 MOD 65+DAT; 1ST IBM VIRTUAL MEMORY IBM PL/I LANG. 66-?? 6???? MAJOR NEW LANGUAGE (IBM) IBM S/360-91 66-01 67-11 22 VERY LARGE CPU; PIPELINED IBM PRICE 67-?? 67??? PRICE INCREASE??? IBM OS/360 67-?? 67-12 MVT - ADVANCED MULTIPROGRAMMED OS IBM TSS 67??? ??-?? 32-BIT VS SCP-MOD 67; COMMERCIAL FAILURE 1Kbit/chip RAM 68 First commercial semicon memory chip IBM CP/67 68+?? 68+?? MULTIPLE VIRTUAL MACHINES SCP-MOD 67 .... IBM SW UNBUNDLE 69-06 70-01 07 IBM SOFTWARE, SE SERVICES SEP. PRICED IBM S/360-195 69-08 71-03 20 VERY LARGE CPU; FEW SOLD; SCIENTIFIC IBM 3330-1 70-06 71-08 14 DISK: 200MB/BOX, $392/MB IBM S/370 ARCH. 70-06 71-02 08 EXTENDED (REL. MINOR) VERSION OF S/360 IBM S/370-155 70-06 71-01 08 LARGE S/370 IBM S/370-165 70-06 71-04 10 VERY LARGE S/370 IBM S/370-145 70-09 71-08 11 MEDIUM S/370 - BIPOLAR MEMORY - VS READY AMH=AMDAHL 70-10 AMDAHL CORP. STARTS BUSINESS IBM S/370-135 71-03 72-05 14 INTERMED. S/370 CPU IBM S/360-22 71-04 71-07 03 SMALL S/360 CPU IBM LEASE 71-05 71 06 01 FixTERM PLAN;AVE. -16% FOR 1,2 YR LEASE IBM PRICE 71-07 71+?? +8% ON SOME CPUS;1.5% WTD AVE. ALL CPU IBM S/370-195 71-07 73-05 22 V. LARGE S/370 VERS. OF 360-195, FEW SOLD Intel, Hoff 71 Invention of microprocessor IBM MVS-JES3 72+?? 75-10 LOOSE-COUPLED MP (ASP-LIKE) IBM VSAM 72+?? 7?-?? NEW RANDOM ACCESS METHOD IBM VM ASSIST 72+?? 7?-?? MICROCODE ASSIST FOR VM/370 IBM 3705 72-03 72-06 COMMS CNTLR: 352 LINES; 56KB/SEC IBM S/370 VS 72-08 73-08 12 VIRTUAL STORAGE ARCHITECTURE FOR S/370 IBM 135-3 72-08 73-08 12 INTERMED. S/370 CPU IBM 145-3 72-08 73-08 12 INTERMED. S/370 CPU IBM 158 72-08 73-04 08 LARGE S/370, VIRTUAL MEMORY IBM 168 72-08 73-08 12 VERY LARGE S/370 CPU, VIRTUAL MEMORY IBM OS/VS1 72-08 73-?? VIRTUAL STORAGE VERSION OF OS/MFT IBM OS/VS2(SVS) 72-08 72+?? VIRTUAL STORAGE VERSION OF OS/MVT IBM OS/VS2(MVS) 72-08 74-08 MULTIPLE VIRTUAL ADDRESS SPACES IBM VM/370 72-08 72+?? MULTIPLE VIRTUAL MACHINES (LIKE CP/67) IBM 125 72-10 73-04 06 SMALL S/370 CPU IBM MVS-JES2 72-?? 72-08 JOB-ENTRY SUBSYSTEM 2 (HASP-LIKE)
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: AES cyphers leak information like sieves Newsgroups: sci.crypt Date: Fri, 19 Nov 1999 17:51:10 GMTa lot of hardware transmission gear currently incorporates various kinds of FEC ... typically something like reed-solomon or viterbi. long ago & far away we worked on doing standard hardware 15/16ths reed-solomon & then on selective resend, transmit the 1/2rate viterbi ... instead of the original block.
on links with bit-error-rate (BER) of 10-**9, 15/16ths reed-solomon can give six orders of magnitude correction ... i.e. resultiing in BER 10-**15.
by sending the 1/2rate viterbi on selective resend ... instead of the original message ... there is still high probability of message recovery even if both individual messages have uncorrectable transmission errors (also the total number of bits transmitted is the same as in the simple selective resend protocol).
this was applying FEC to the encrypted message. wouldn't work in the simple hardware link encryptor desings ... since the selective resend logic wouldn't have access to the original encrypted message for calculating the 1/2rate viterbi FEC.
monitoring the frequency of transmission errors ... the process could decide to switch from selective resend of the 1/2rate viterbi ... to alwas transmitted the 1/2rate virturbi with the original message (pretty lossy conditions ... say BER 10-**2). Trade-off of loosing half the effective thruput vis-a-vis overhead of doing selective resend.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: How did you learn to program? Newsgroups: comp.lang.misc,comp.ai.edu,rec.arts.sf.science,sci.edu,alt.folklore.computers Date: Sat, 20 Nov 1999 16:46:35 GMTuj797@victoria.tc.ca (Arthur T. Murray) wrote:
misc.
https://www.garlic.com/~lynn/98.html#9
https://www.garlic.com/~lynn/98.html#49
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: GEOPLEX Newsgroups: bit.listserv.ibm-main,alt.folklore,computers Date: Sun, 21 Nov 1999 21:07:03 GMTlong ago & far away we had that problem with JES2 link between STL and Hursley being switched from a land-line to a double-hop satellite link. They brought up JES2 pair on the link and couldn't establish a connection ...so they stopped and brought up VNET on the link and everything would transfer fine w/o any errors. They dropped the link and brought up pair of JES2 again and were unable to establish a connection. Somebody's conclusion was that the line was full of errors and VNET was just too stupid to realize it (of course the problem was that JES2 had a keep-alive ping that had time-out shorter than the satellite double-hop round trip).
misc. references (including hardware FEC for reliable transmission,
also frequently used in many satellite systems):
https://www.garlic.com/~lynn/99.html#210
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/99.html#33
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/99.html#77
https://www.garlic.com/~lynn/99.html#91
https://www.garlic.com/~lynn/99.html#110
https://www.garlic.com/~lynn/99.html#145
https://www.garlic.com/~lynn/99.html#184
https://www.garlic.com/~lynn/99.html#209
gad writes:
>Can I have a GEOPLEX player several thousand miles away and have
>a minimum of 1 structure list i.e. logger?
No. No can do.
There is a finite limit to the distance allowed for the communication
protocols used for the Sysplex Timer and Coupling Facility, which is the
limiting factor to a Geographically dispersed Sysplex.
Greg
Greg Dyck
IBM Poughkeepsie, OS/390 BCP Platform team
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Why is Pascal no longer a leading development Language? Newsgroups: comp.programming Date: Thu, 25 Nov 1999 19:02:59 GMTmost of the pascal's are weak in several areas ... a couple years ago i did a port of a 60,000+ statement pascal application to a different platform ... my impression was it was probably the largest application ever processed by the target platform's pascal ... i was in contact with the platform vendor a couple times a week during the port with bugs
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Ask about Certification-less Public Key Newsgroups: sci.crypt Date: Fri, 26 Nov 1999 17:33:01 GMT"Lyal Collins" writes:
Search for AADS or ANSI X9.59 to see a standard that uses this model.
The deployment costs are similar - you need a secure database, and a
reliable, trusted registration process to store the public key.
the deployment costs are similar if you are starting from scratch
... however if you already have a secure infrastructure (like for
financial transactions) ... the incremental costs to upgrade the
existing facility may only be a couple percent and the public key
specific operationl costs of the overall infrastructure may can even
be a smaller percentage.
https://www.garlic.com/~lynn/aadsmail.htm#variations
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1
other opportunities possible for incremental costs is to leverage the
existing pin debit ... where the card is personalized, pin is securely
recorded, handled, and transmitted. Incremental costs for adding a
chip to magstrip card, generating key pair, and securely recording
public key is also rather small. In many respects, the
shared-secret/pin actually requires higher integrity processes than
corresponding processes for public key (i.e. the infrastructure isn't
compromised just by learning a person's public key).
https://www.garlic.com/~lynn/aadsm2.htm#straw
the scenerio is that it is possible to deploy PKI small pilots for relatively small up front investment ... much less than the 2%-3% costs to modify an existing infrastructure (public key enabling an existing infrastructure is well under the Y2K remediation costs).
Claim has alwas been that the trade-off cross-over is approx. when the public key enabled market penetration exceeds 4%-5% it becomes much less expensive to modify the existing infrastructure than building a new infrastructure from scratch.
the biggest actually costs is the customer call center ... general consumer market expectation is that they have a 1-800 to contact if anything hiccups (one of the things that small pilots frequently pass over).
misc. other references:
https://www.garlic.com/~lynn/aadsover.htm
https://www.garlic.com/~lynn/aadswp.htm
& of course
https://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Ask about Certification-less Public Key Newsgroups: sci.crypt Date: Fri, 26 Nov 1999 17:46:45 GMT... also ....
Subject: AADS/X9.59 cost sharing intuition
Several times at X9A10 meetings there have been statements about the advantages of infrastructure cost sharing associated with AADS operation.
assertion #1: majority of a certificate authority is account-based management
assertion #2: cryptography for digital signature infrastructure can be added to existing financial account infrastructure at 1%-5% of the cost of the current infrastructure
corollary: cost sharing with integration of digital signatures into an existing financial account based infrastructure will have existing non-digital signature applications carrying 95%-99% of the total account costs.
assertion #3: high value digital signature financial applications can carry 90%-95% of the digital signature infrastructure cost
corollary: non-financial application use of a integrated financial digital signature infrastructure can be done at 1/200th to 1/2000th the per account cost of an independent non-financial digital signature infrastructure.
In a financial AADS infrastructure:
fraction of account costs covered by non-digital signature applications
.95 to .99
fraction of account costs covered by digital signature applications
.05 to .01
fraction of digital signature account costs covered by financial digital signature applications
.90 to .95
fraction of digital signature account costs covered by non-financial digital signature applications
.10 to .05
fraction of account costs covered by non-financial digital signature applications
.1*.05 to .05*.01 or .005 to .0005 (1/200th to 1/2000th)
This is applicable to the integration and use of AADS/X9.59 in an existing financial account infrastructure.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Ask about Certification-less Public Key Newsgroups: sci.crypt Date: Fri, 26 Nov 1999 23:23:39 GMTalso, at recent FSTC/FAST meeting where we were discussing a number of AADS implementations (www.fstc.org) there was also reference to NPKI project in michigan (i.e. no public key infrastructure, i.e. public keys ... but not public key infrastructure as currently commonly constituted).
there was also an AADS Radius demo'ed at PC/EXPO in NYC last spring (i.e. radius is the dominant authentication mechanism thruout the world).
AADS for all electronic retail financial transactions, aka X9.59
... to preserve the integrity of the financial infrastructure for
all eelectronic retail payments with digital stignature, at least
both debit & credit (while preserving privacy).
https://www.garlic.com/~lynn/
AADS for non-financial electronic commerce transactions (age, address,
location, eligibility). FSTC/FAST:
http://www.fstc.org/
AADS Radius for majority of all internet authentication transactions.
https://www.garlic.com/~lynn/
there is also various activities involving AADS for all wholesale financial transactions and various kinds of business-to-business operations.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: lynn@adcomsys.net (Anne & Lynn Wheeler) Subject: AADS/X9.59 demo & standards at BAI (world-wide retail banking) show Newsgroups: gov.us.topic.ecommerce.standards Date: 1 Dec 1999 13:41:33 -0500AADS X9.59 (reference implementation) integrated with one of the major web merchant systems looks like it will be demo'ing in several booths at next week's BAI show in miami. It will use aads digital signature chipcard for signing the x9.59 transaction.
In addition, the AADS FSTC/FAST-like demos are also working, i.e. age, location, etc. and will be at the show (for instance allowing verification of non-minor status before allowing to proceed at a website). This will be able to use the same aads digital signature chipcard.
The only demo that might not make to the show is the AADS RADIUS demo (i.e. RADIUS is utilized by the majority of internet service providers around the world to authenticate connections by their customers ... as well as the major method for dial-in authentication to corporate intranets). This will also will work with the same AADS digital signature chipcard.
The AADS operations can be done securely w/o divulging privacy information. X9.59 financial transactions can be w/o requiring name & address. Signed AADS shipping transactions can be done allowing web sites to ship hard goods w/o requiring name&address. Minor/non-minor status can be affirmed w/o divulging name&address. Location for shipping costs & sales takes can be provided w/o divulging name&address
The AADS Policy & Practices consistency writeup is available at
https://www.garlic.com/~lynn/
several of the privacy issues have been discussed previously on
various mailing lists and are selected postings are also archived at
https://www.garlic.com/~lynn/
X9.59 is an emerging standard of the ANSI Financial Standards body:
http://www.x9.org/
FSTC/FAST is effort to expand the financial authentication
infrastructure to areas other than payment transactions.
http://www.fstc.org/
There has been similar AADS activity out of NACHA
https://web.archive.org/web/20020122082440/http://internetcouncil.nacha.org/
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Mainframe acronyms: how do you pronounce them? Newsgroups: bit.listserv.ibm-main Date: Thu, 02 Dec 1999 16:49:42 GMTi was doing support at customer site in fall of '69 when we were selected to be one of the original CICS beta-test sites ... it was for an online library catalogue project. i seem to remember that hard C was "Customer" had hard C (but that was a long time ago).
one of the first bugs I had to shoot was CICS BDAM open was failing on some of our files.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Study says buffer overflow is most common security bug Newsgroups: bit.listserv.vmesa-l Date: Tue, 30 Nov 1999 23:12:16 -080ever since we started ha/cmp in the late 80s ... we've been making that claim ... & in many cases it is severely aggravated by C-language convention null terminated implicit string lengths.
misc. other reference:
https://www.garlic.com/~lynn/99.html#163
--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: VM History Newsgroups: bit.listserv.vmesa-l Date: Sat, 4 Dec 1999 10:18:50 -0800there also have been lots of s/360 threads in alt.folklore.computers ... & in one of those threads
there is URL pointer that has hardware & software announcement & ship dates
--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: VM History Newsgroups: bit.listserv.vmesa-l Date: Sat, 4 Dec 1999 10:19:05 -0800and slightly more network related ... but with some VM content:
& some of the internet/network specific thread
https://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Looking for a (working) PERQ Newsgroups: alt.folklore.computers,alt.sys.perq Date: Tue, 07 Dec 1999 15:11:12 GMTslightly PERQ related .... in the following reference
there is mention of different groups reviewing the proposal for a new workstation ... and all of the groups concluded what they were doing was better than the proposal and so the proposed new workstation (SUN) didn't need to be done.
the workstation group that participated in the evaluation was using mostly/all PERQs. One of the PERQ demos that i remember was a phone application.
the perq would pull off the calling phone number on the incoming call and show it in a pop-up window on the PERQ. numbers could also be looked up in a directory and if found also display the person's name. I also seem to remember you could classify numbers and associate activity with them ... send the call directly to phone mail, only display the window, play a specific ring/tune, play a specific message at phone mail, etc. For outgoing ... you could give a name ... and it would look up the number and do the dialing. In phone mail ... you could look at the phone mail log, it would give the incoming number, person's name if available, date/time of the call, length of recorded message, whether the message had been heard, etc.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Paradigm Shifted (was: Re: BBSs vs. The Internet) Newsgroups: alt.folklore.computers Date: Fri, 10 Dec 1999 14:59:43 GMTagree ... one of the motivations for doing the IOS rewrite and getting an operating system that could tolerate the disk/dasd engineering & product test labs was to be able to co-op the remaining CPU (say 95%) on whole slew of really big mainframes.
misc ref (some even posted from lynn@netcom.com ... which is still
active, I think I first got "lynn" in '92 ... even tho it was a
intra-lata per minute call ... they didn't have local access for the
next town just south of san jose):
https://www.garlic.com/~lynn/94.html#15
https://www.garlic.com/~lynn/95.html#3
https://www.garlic.com/~lynn/97.html#15
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: X9.59/AADS announcement at BAI this week Newsgroups: alt.technology.smartcards Date: Fri, 10 Dec 1999 23:54:33 GMTmanaged to get announcement at BAI this week (www.bai.org). Have demos for X9.59 transactions (retail payments, credit, debit, check, etc). First draft talked about both point-of-sale and internet ... but things got simplified when the final press release went out. Also wed's American Banker had a front page article.
demos at BAI include both financial transactions as well as privacy broker transacrtions (provide adult/minor status and address for shipping companies ... w/o having to divulge name, address and/or other personal details at web sites).
A similar AADS announcement was made by nacha about a month ago:
https://web.archive.org/web/20020122082440/http://internetcouncil.nacha.org/
Work also been done on integrating AADS support into RADIUS (what the majority of the internet service providers and corporate intratnets use for authenticating access).
This provides for the same AADS infrastructure to support financial transactions, privacy broker transactions as well as internet/intranet access and web server access.
other details on AADS and X9.59 can be found at
https://www.garlic.com/~lynn/
====================================
Media Contacts:
First Data Corp.: Caroline Hoke, (770) 857-7178,
caroline.hoke@firstdatacorp.com
CyberSafe: Steve Birge, (425) 837-1057, steve.birge@cybersafe.com
TSA: Joel Molyneaux, (402) 778-1590, molyneauxj@tsainc.com
Interworld: Chris Faust, chrisf@interworld.com
Six Companies Announce Plans to Support
Proposed Digital Payments Industry Standard
First Data Corp., Compaq, TSA, Certicom, InterWorld and CyberSafe
cooperating to develop AADS digital payments infrastructure
MIAMI - Dec. 7, 1999 - A group of leading technology companies today
announced its support and plans to develop the Account Authority
Digital Signature (AADS) and proposed ASC X9 digital payments
standard. First Data Corp., Compaq Computer Corp., Transaction
Systems Architects (TSA) Corp., Certicom, InterWorld and CyberSafe
together made the announcement at the Bank Administration Institute
(BAI) Retail Delivery 1999 Conference here.
These companies are developing solutions for a secure digital payments
infrastructure based on AADS, to be used on either the Internet or at
point-of-sale terminals. A demonstration - including a reference
implementation and Internet-based merchant web site - is available at
the conference. (To make an appointment to see the demo, visit booth
#1242.)
An implementation of this secure digital payments solution uses a
smart card and personal identification number (PIN), that, when
combined, provide a secure "digital signature" for purchases
transacted either on the Internet or at a point-of-sale terminal. The
PIN activates the signing key in the smart card to give each
transaction a unique digital signature. Once initiated, the secure
transaction is authenticated as being uniquely associated with the
buyer, and is securely transferred through the authentication process.
This digital signature system provides the purchaser with a greater
degree of security and privacy than traditional systems while
simultaneously providing the merchant with greatly reduced charge-back
and transaction repudiation. With AADS, the card issuer, which has the
existing consumer relationship, handles both the authentication and
the transaction authorization. By eliminating the need for
third-party authorization, the theft of credit card content and
information - including numbers on the Internet - is reduced. The
AADS solution applies equally to credit card or debit card processing.
"First Data is supporting this and other security and authentication
solutions and protocols desired by consumers, merchants and bank card
issuers. We are committed to ensuring that electronic transactions -
whether over the Internet or at the point of sale - are as safe and
secure as possible," said Lee Adrean, executive vice president of
First Data Corp. and responsible for the company's Internet Commerce
initiatives.
"CyberSafe and First Data have been working together to meet an
important market requirement for digital payments - security
infrastructures that provide a worry-free environment for consumers
and merchants in conjunction when using real or virtual smart cards"
said Jim Cannavino, chairman and CEO of CyberSafe Corp. "CyberSafe
believes that AADS is the basis for financial settlement, security,
and on-line shopping experiences that directly address consumer
security and privacy concerns as well as eliminate merchant concerns
related to charge-backs and repudiation of charges".
Each of the companies supporting the statement of direction will
contribute a unique and important part of the infrastructure:
§ First Data Corp. intends to support its customers by providing
AADS-enabled transaction processing services and smart cards.
§ TSA intends to support AADS in software and services based on its
BASE24®, i24™ and e24™ product lines, with particular focus on
implementation of a "PIN Debit on the Internet" capability.
§ Certicom intends to provide the elliptical curve encryption
technology for smart card and authentication engines.
§ Compaq currently ships certain components of the Compaq desktop,
server, and laptop product lines enabled for reading/signing AADS
smart cards. Compaq also provides the Compaq NonStop? Himalaya
S-series product line that supports TSA BASE24® software product
offerings.
§ InterWorld intends to offer digital signature support as part of its
web site development offerings.
§ CyberSafe will enable security for AADS, by providing e-commerce
application developers a software development kit (SDK) and other
security infrastructure products and services to enable rapid
deployment of an AADS infrastructure.
About First Data
Atlanta-based First Data Corp. (NYSE: FDC) helps move the world's
money. As the leader in electronic commerce and payment services,
First Data serves more than two million merchant locations, 1,400 card
issuers and millions of consumers, making it easier, faster and more
secure for people and businesses to buy goods and services. For more
information, please visit the company's web site at
http://www.firstdatacorp.com/
... since bought by fiserv
About InterWorld
InterWorld Corporation is leading the Enterprise Commerce movement
that enables businesses to compete and evolve in today's new digital
economy. With InterWorld's Commerce Exchange solution, manufacturers,
distributors and retailers can get to market quickly, scale to meet
growing demands, as well as, evolve to keep pace with changing market
conditions and customer demands. For more information, visit
http://www.interworld.com/
https://web.archive.org/web/20000229152004/http://www.interworld.com/
About TSA
Transaction Systems Architects' (NASDAQ:TSAI) software facilitates
electronic payments by providing consumers and companies access to
their money. Its products are used to process transactions involving
credit cards, debit cards, smart cards, home banking services, checks,
wire transfers as well as automated clearing and settlement. TSA
solutions are used on more than 3,200 product systems in 75 countries
on six continents. For more information, visit
http://www.tsainc.com/
About Certicom
Certicom is a leading provider of next-generation encryption
technology used to build strong, fast, and efficient security
solutions. Major computing and communications companies, such as
3Com/Palm Computing, BellSouth Wireless Data, Hewlett-Packard,
Motorola, Pitney Bowes and VeriFone, incorporate Certicom technology
into electronic commerce software, wireless messaging applications,
and smart cards. For more information, visit
http://www.certicom.com/
About Compaq
Compaq Computer Corporation is the second-largest computer company in
the world and the largest global supplier of computer systems. Compaq
develops and markets hardware, software, solutions, and services,
including industry-leading enterprise computing solutions,
fault-tolerant business-critical solutions, enterprise and network
storage solutions, commercial desktop and portable products, and
consumer PCs. Customer support and information are available at
http://www.compaq.com/
About CyberSafe
CyberSafe is a privately held corporation founded in 1991. Its
award-winning TrustBroker? Security Suite, Defensor®, and Centrax?
product lines are designed to enable secure electronic business, while
reducing administration costs. CyberSafe is headquartered in
Issaquah, Wash., and on the World Wide Web at
http://www.cybersafe.com/
For additional information, please send requests to
info@cybersafe.com.
# # #
CyberSafe, Defensor and the CyberSafe logo are registered trademarks
of CyberSafe Corporation and its wholly owned
subsidiaries. TrustBroker and Centrax are trademarks of CyberSafe
Corporation and its wholly owned subsidiaries. All other products and
trademarks are the property of their respective owners.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: BBSs vs. The Internet Newsgroups: alt.folklore.computers Date: Sat, 11 Dec 1999 02:23:28 GMTDave writes:
minor references:
https://www.garlic.com/~lynn/95.html#7
https://www.garlic.com/~lynn/97.html#2
https://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Attacks on a PKI Newsgroups: sci.crypt Date: Sun, 12 Dec 1999 16:46:08 GMTlcs Mixmaster Remailer writes:
much of many PKIs are pretty much orthogonal to existing online authentication infrastructures, many of which are currently shared-secret based and could be incrementally upgraded from shared-secret authentication to public key authentication w/o introducing PKI and/or changing existing business policies and practices.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Why couldn't others compete against IBM? Newsgroups: alt.folklore.computers Date: Mon, 13 Dec 1999 04:04:39 GMTmisc. reference:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Attacks on a PKI Newsgroups: sci.crypt Date: Mon, 13 Dec 1999 23:13:46 GMTHelger Lipmaa writes:
certificates provide great introductory credentials for offline comfort involving parties that have no previous knowledge of each other and/or no prior business relations.
however, certificates have poor transactional characteristics in both consumer<->business e-business and business<->business e-business (simple offline analogy is oldtime purchase department checks with printed "signing" limit authority ... of something like $5,000 until they discovered $1m projects were being funded by signing 200 such checks, i.e. aggregation involves online accounts).
also in the consumer to business e-business, consumer certificates tend to violate all sorts of privacy guidelines. solutions have been things like relying-party-only certificates ... with only identifier is the account number. In this scenerio, the account record has to be "hit" ... in which case it can be trivially shown that certificate is at least redundant and superfluous and likely also introducess unnecessary risk.
In general, AADS has gone to great deal of trouble to support KISS (several observations have then that is frequently much harder to do something simply than to do something in complex fashion).
To some extent we did violate the KISS principle in the convoluted mapping of Certification Authority policies and practices; we started by defining a CA-based infrastructure with certificates ... and then using existing CA policies and practices show that a certificate doesn't actually exist in that portion of the business operation. From that build a whole e-business series of certificate-based operations where the certificate(s) never actually appears.
for those interested in such convoluted exercises (as opposed to
straight-forward KISS) see the business policies & practicies
discussion at
https://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Digital Signature on SmartCards Newsgroups: alt.technology.smartcards Date: Tue, 14 Dec 1999 01:17:55 GMTis the question about digital signatures with smartcards or x.509 certificates on smartcards? they aren't the same.
at BAI last week (world-wide retail banking show) we had smartcards demo'ing digital signatures for financial transactions (financial industry retail payment standard) and privacy broker transactions (as mentioned in this NG a couple days ago). The only demo missing was for AADS RADIUS digital signature authentication ... for doing all ISP and webserver access.
the smartcards had no x.509 certificates and/or any need for such things for doing high integrity transactions.
for recap and some related material see:
https://www.garlic.com/~lynn/
and more recently discussion on sci.crypt about PKI "problems"
https://www.garlic.com/~lynn/99.html#226
& ietf-pkix with respect to high integrity AADS chipcards and bio-sensors
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo3
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Radius Help help!!! Newsgroups: comp.security.misc Date: Tue, 14 Dec 1999 17:11:49 GMTlook at
RADIUS is only used by the majority of ISPs and corporate intranets around the world for authenticating connections.
random other URL
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/cs_unx/csu212ug/nasconra.htm
or try any of the search engines for RADIUS
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Why couldn't others compete against IBM? Newsgroups: alt.folklore.computers Date: Wed, 15 Dec 1999 18:32:49 GMTfrom reference ...
I ran across this description at the time of the government anti-trust
suit (in the early '70s) ... I never ran across any validation/repeat,
so I don't know if it is real:
An "expert witness" representing one of the companies (that left the
business) testified regarding the state-of-the-art in the late
50s. Supposedly in the late 50s ALL of the computer companies realized
the SINGLE MOST IMPORTANT criteria to be successful in the computer
business was to have compatibility across the whole computer line,
from entry level to the largest machine. The witness went on to
observe that only one company was successful in meeting this goal, all
the other companies failed. The remaining companies failed to
adequately deal with multiple plant operations (each responsible for a
particular model in the product line) that locally optimized the
hardware architecture/implementation for the specific model.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Need Unix system call to get the CPU time taken by a thread Newsgroups: comp.programming.threads Date: Thu, 16 Dec 1999 04:11:11 GMTthere are times when what I get back from unix system call wasn't sufficient &/or didn't take into account all the effects.
For those environments ... & to do a sanity check on whether the cpu gotten really represents all CPU consumed by the operation I created a background application that was in a tight cpu loop that took a measurable amount of real time) when there was no other activity on the system).
I then ran the base case operation while the background task was operational and noticed the increase in elapsed real time for the background task. This represents the aggregate of all cpu resources needed by the base case operation (regardless of how/where/when the CPU time was being accounted for).
I then would run the incremental cases, taking note of the increase in the background task elasped real time for each incremental case.
the base case & the incremental cases might involve some number of interative operations ... given the noted increase in background elapsed time being representative of the CPU used for the task/cases, and the counted number of iterations in each case, ... it is possible to calculate the per interation CPU required.
IN the thread/no-thread case ... the a no-thread run could be taken as the base case, and the threaded run would represent the incremental case.
This process may be more useful on a server system where some amount of the workload operation (for instance low level LAN & network drivers) may be going on in the kernel and not directly charged off against a specific user task ... and result in a much more comprehensive measurement for capacity planning purposes.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Computer of the century Newsgroups: alt.folklore.computers,comp.arch,comp.sys.unisys Date: Wed, 29 Dec 1999 19:25:42 GMTfrom posting earlier this year:
1.In 1969, Continental Airlines was the first (insisted on being the
first) customer to install PARS. Rushed things a bit, or so I hear. On
February 29, 1972, ALL of the PARS systems canceled certain
reservations automatically, but unintentionally. There were (and still
are) creatures called "coverage programmers" who deal with such
situations.
2.A bit of "cute" code I saw once operated on a year by loading a
byte of packed data into a register (using INSERT CHAR), then used LA
R,1(R) to bump the year. Got into a bit of trouble when the year 196A
followed 1969. I guess the problem is not everyone is aware of the odd
math in calendars. People even set up new religions when they discover
new calendars (sometimes).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Computer of the century Newsgroups: alt.folklore.computers Date: Wed, 29 Dec 1999 19:35:42 GMTfirst mini that i worked with was interdata/3 ... circa late '60s.
we built a 360 channel attachment card for it and programmed it to be 360 telecommunications controller
minor ref:
https://www.garlic.com/~lynn/96.html#4
https://www.garlic.com/~lynn/99.html#12
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Attacks on a PKI Newsgroups: sci.crypt Date: Wed, 29 Dec 1999 19:54:40 GMT"Lyal Collins" writes:
Account Authority Digital Signature (AADS) public key ... eliminates those exploit modes, preserves existing authentication business processes and establishes the basis for parameterised risk management.
In the paramemterized risk management portion ... the AADS public protocol and processes can be the same across a wide-range of business processes & requirements ... but the risk parameters are adjusted based on the integrity level of the environment housing the private key and doing the digital signing (simple example is credit limit and transaction authorization are different whether the private key is a PC housing with password access ... or a separate 140-3 smartcard with both PIN and biometrics).
This is easily generalized to authentication infrastructure ... using the same infrastructure for things like financial transactions, web access, & ISP login (straight-forward RADIUS enhancement) ... all sharing the same technology infrastructure and level of integrity adjusted to meet the requirements of the business.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Attacks on a PKI Newsgroups: sci.crypt Date: Wed, 29 Dec 1999 19:57:40 GMT... and of course ... lots of AADS description and discussion at
& recent X9.59/AADS announcement
https://www.garlic.com/~lynn/99.html#224
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: I can't believe this newsgroup still exists. Newsgroups: alt.os.multics Date: Wed, 29 Dec 1999 21:58:06 GMTwestin*nospam@graphics.cornell.edu (Stephen H. Westin) writes:
CMS/360 had invocation of programs as command names from the cp/40 days ... say 65 (going on in the same building as Multics ... but more due to a common heritage than one getting it from the other).
IBM Future System project that went on in the early '70s drew on the above plus everything else it could find (including Multics, even tho no product ever shipped).
Numerous FS and CMS people eventually turned up in IBM Rochester and did the S/38 with the characteristics that also propagated into the S/38 follow-on, the AS/400.
some of this from VM history paper at:
https://www.leeandmelindavarian.com/Melinda#VMHist
misc. other
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/99.html#44
https://www.garlic.com/~lynn/99.html#100
https://www.garlic.com/~lynn/99.html#126
https://www.garlic.com/~lynn/99.html#127
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Attacks on a PKI Newsgroups: sci.crypt Date: Thu, 30 Dec 1999 01:30:56 GMT"Lyal Collins" writes:
the old style checks with signing limits has been one model proposal for certificate pki ... build into the certificate language similar to signing limits. the attack point turned out to be aggregation ... certificates can be used for atomic operations but have very poor operational characteristics where aggregation can be involved (fraud where somebody with a $5000 signing limit discovered that they could do million dollar transactions by writing 200 checks)
for the points that are in common to the different transaction types (a million $30 transactions or 30 million dollar transactions) need to have similar integrity levels ... and it does need to be account based to handle aggregation-like issues.
an AADS signing chip is an attack point for a specific account ... not for the infrastructure as a whole (for one thing it doesn't have any system-wide shared-secret &/or systemic risk characteristics). the integrity of any single chip has to be comparable to the benefit gained from attacking it. A specific AADS signing chip might possible have parameterised risk management specifying things like the maximum individual transaction size, the transaction velocity, the maximum aggregated number of transanctions in some interval and the maximum aggregated value of transactions in some interval.
the transaction authorization and execution infrastructure has to have integrity comparable to the aggregation of all possible transactions it might process ... however any single AADS signing chip only needs integrity comparable to the transactions that the specific chip might be used for.
The AADS case has been that the account-based transaction authorization and execution infrastructure for financial operations has to exist regardless of any other operational characteristics. Given that such an account-based infrastructure has to exist, then it is trivially shown that having CA & certificates as part of that infrastructure's transactions represents redundant and superfluous operations and needlessly increases the infrastructure's systemic risk.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: IBM UC info Newsgroups: alt.folklore.computers Date: Thu, 30 Dec 1999 18:04:28 GMT"Henk Stegeman" writes:
we had an effort to try and get peachtree used in the 3705 rather than the uc.5 ... since it was much more suited for a telecommunications controller (peachtree was used in the s/1).
minor peachtree (& telecommunication) references:
https://www.garlic.com/~lynn/93.html#2
https://www.garlic.com/~lynn/94.html#33a
https://www.garlic.com/~lynn/99.html#63
https://www.garlic.com/~lynn/99.html#64
https://www.garlic.com/~lynn/99.html#66
https://www.garlic.com/~lynn/99.html#67
https://www.garlic.com/~lynn/99.html#70
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <garlic.com> Subject: Re: Attacks on a PKI Newsgroups: sci.crypt Date: Fri, 31 Dec 1999 00:24:03 GMTGreg writes:
I think it is pretty well accepted that PKI design point is offline, electronic. The models they have/fit correspond to the world before it started moving to online.
checks/debit/credit have had failure modes like forgeries ... but also there are other failure modes like insufficient funds &/or credit limit.
PKI can be used for addressing offline forgery issues.
however, starting sometime in the '60s, telecommunication and computers costs started coming down to the point where it started being economically attractive to do online transactions ... & being able to address the insufficient funds and credit limit failure modes (i.e. card swipe online terminals at point of sale) ... i.e. cost of the telecommunications and computers was much less than the benefit of doing online transactions (cost/benefit ratio).
since the '60s, the cost of telecommunication and computers have continued to decline, making online transactions even more attractive, improving the cost/beneift ratio with online starting to become more and more ubiquitous (further reducing the attractiveness of offline solutions like PKIs). The internet itself is just one example of the move to pervasive, ubiquitous online operation.
AADS chip card & X9.59 for all electronic retail transactions addresses both the forgery as well as insufficient funds using integrated online solution.
A CA/PKI only offline solution would be going back to a pre-60s solution only addressing the forgery failure mode.
And as stated previously, given an online digital signed solution (ala X9.59) which addresses forgery issues, end-to-end authentication (financial institution doing the authentication/forgery checking and not relying on intermediaries), as well as insufficient funds & credit limit failure modes ... then it is trivially shown that also having a CA/PKI as part of the transactions is at best redundant and superfluous and typically introduces unnecessary systemic risk and unecessary additional failure modes.
and as usual ... more AADS & X9.59 at
https://www.garlic.com/~lynn/x959.html#x959
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/