From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 5100 Newsgroups: alt.folklore.computers Date: Sun, 08 Jun 2003 00:56:31 GMTCharles Richmond writes:
different (nat semi) scamp:
http://www3.sk.sympatico.ca/jbayko/cpu2.html
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FAST - Shame On You Caltech!!! Newsgroups: comp.protocols.tcp-ip,alt.folklore.computers Date: Sun, 08 Jun 2003 02:51:14 GMTunoriginal_username@yahoo.com (Le Chaud Lapin) writes:
mid-80s, we did it in HSDT to keep a high-speed satellite channel full ... i.e. measure the propagation delay end-to-end (aka latency) ... and then figured out what was necessary to keep the channel full. while the propagation delay measurement was absolutely necessary for the satellite link ... it was useful for terrestrial links also).
as previously stated we weren't allowed to bid on NSFNET1 ... but a
NSF technical audit of what we had running (both terrestrial and
satellite backbone links) stated that it was at least five years ahead
of the NSFNET bid responses to build something new (maybe some even 15
years ahead?).
https://www.garlic.com/~lynn/subnetwork.html#hsdt
slightly related thread in this n.g. in april:
https://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#45 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
and somewhat total aside ... the 20th anv. of 1/1/83 tcpip network has
past, however, coming up on 6/10/83 is the anniversary of the 1000th
node on the internal network (larger than the arpanet/internet until
sometime mid-85):
https://www.garlic.com/~lynn/2003i.html#76 Columbia U Computing History - New stuff
https://www.garlic.com/~lynn/internet.htm#22 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Fix the shuttle or fly it unmanned ... Newsgroups: alt.folklore.computers Date: Sun, 08 Jun 2003 14:24:29 GMTBrian Inglis writes:
mainframe terminal communications is "synchronous at many levels", in part because it is a half-duplex paradigm at many levels. there is some lore about somebody attempting to implement LU6.2 on top of tcp/ip full-duplex platfrom and having extreme difficulty achieving the half-duplex semantics.
this was around the time that i did rfc 1044 support for mainframe tcp/ip product ... which was getting about 44kbytes/sec thruput on a 3090 thru an 8232 (and just about using all of one processor). there was some tuning at cray research with the 1044 support running on a 4341 talking with a cray that was saturating the 4341 channel and only using a modest amount of 4341 processor (in part this used pairs of ibm half-duplex subchannel addresses to achieve full-duplex emulation .... this is akin to fiber operation, pairs of dedicated dual-simplex with dedicated transmission channel in each direction). minor historical note ... took off from SFO for trip to cray research for benchmarking trip ... about five minutes before the quake hit.
a problem that IBM Kingston had trying to attach HiPPI to a 3090 was that
ibm channels wouldn't support the transfer speed. So they hooked
it into the expanded store bus (expanded store was large page memory
that had synchronous instructions to move 4k pages between regular
memory and expanded store). HiPPI i/o controls was done with reserved
addresses in expanded store (effectively analogous to memory mapped
peek&poke .. but doing full 4k transfers even for small command sets).
misc. hippi/expanded store refs:
https://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
https://www.garlic.com/~lynn/2001m.html#53 TSS/360
https://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
https://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
https://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
somes past posts related to experience with redoing a
major TPF application:
https://www.garlic.com/~lynn/96.html#31 Mainframes & Unix
https://www.garlic.com/~lynn/99.html#153 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000.html#61 64 bit X86 ugliness (Re: Williamette trace cache (Re: First view of Willamette))
https://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
https://www.garlic.com/~lynn/2001k.html#26 microsoft going poof [was: HP Compaq merger, here we go again.]
https://www.garlic.com/~lynn/2002i.html#40 CDC6600 - just how powerful a machine was it?
slightly tcp/ip related recent ref:
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
high speed data transport:
https://www.garlic.com/~lynn/subnetwork.html#hsdt
some comparison 3725/ncp and emulated sscp & ncp on S/1 running
on top of peer-to-peer packet network:
https://www.garlic.com/~lynn/99.html#67 System/1 ?
https://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was System/1 ?)
misc. past refs to having done rfc 1044 support:
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/96.html#14 mainframe tcp/ip
https://www.garlic.com/~lynn/96.html#15 tcp/ip
https://www.garlic.com/~lynn/96.html#17 middle layer
https://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/2000.html#90 Ux's good points.
https://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000f.html#30 OT?
https://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#52 Pre ARPAnet email?
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002.html#11 The demise of compaq
https://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
https://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
https://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
https://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
https://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
https://www.garlic.com/~lynn/2003c.html#28 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
https://www.garlic.com/~lynn/2003d.html#35 Why only 24 bits on S/360?
https://www.garlic.com/~lynn/2003d.html#37 Why only 24 bits on S/360?
https://www.garlic.com/~lynn/2003d.html#59 unix
https://www.garlic.com/~lynn/2003i.html#43 A Dark Day
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A few Z990 Gee-Wiz stats Newsgroups: comp.arch Date: Sun, 08 Jun 2003 14:51:18 GMTRobert Myers writes:
it isn't so much the ephemeral nature of the distributed caches .... it is recreating the global commit event sequence from the distributed logs ... in some architectures this has used a fine-granularity global clock. there has been work on virtual-times .... not necessarily needing an accurate clock but something that can recreate the original global sequence of commits occurring across all of the distributed nodes (and all the possible interdependency of commits involving multiple different sets of records).
the swamp isn't the i/o for moving the data around the distributed caches (and supporting it in a number of different architectures). the swamp is recreating the original global sequence of events in the case of recovery after a failure .... and being able to do it in architectures that don't have fine granularity global timer.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Sun, 08 Jun 2003 16:34:59 GMTpeter@taronga.com (Peter da Silva) writes:
references to study:
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
lots of references to vulnerabilities & exploits (including
various buffer overflows):
https://www.garlic.com/~lynn/subintegrity.html#fraud
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Sun, 08 Jun 2003 20:12:27 GMTCharles Richmond writes:
the above CVB & CVD instruction refs are taken from the z/architecture ... so the 64-bit version of the instructions are included.
and for something really different ... they now have convert unicode
to UTF-8 and UTF-8 to UNICODE hardware instructions:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.40?SHELF=DZ9ZBK01&DT=20020416112421
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.41?SHELF=DZ9ZBK01&DT=20020416112421
and they now have hardware covert to/from binary floating point and
hexadecimal floating point formats
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9.3.1?SHELF=DZ9ZBK01&DT=20020416112421
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9.3.2?SHELF=DZ9ZBK01&DT=20020416112421
current floating point overview:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9.0?SHELF=DZ9ZBK01&DT=20020416112421
and finally, they now have convert from fixed and convert to fixed hardware
instructions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9.4?SHELF=DZ9ZBK01&DT=20020416112421
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9.4?SHELF=DZ9ZBK01&DT=20020416112421#FIGFPDRT
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Sun, 08 Jun 2003 20:15:53 GMToops, and the convert from/to fixed instruction detailed hardware descriptions
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A few Z990 Gee-Wiz stats Newsgroups: comp.arch Date: Sun, 08 Jun 2003 22:31:58 GMTRobert Myers writes:
The issue becomes what if you then let the (dirty, if you prefer) record float around the distributed caches .... what are the vulnerabilities to the record home location getting updated correctly in the face of various kinds of failure modes.
the original fast commit operated in a single node, but a write of the dirty record was required prior to any movement of the record to another cache (in fact, originally other caches were forced to read the record from the home location).
the first improvement was to still force the write to home location before any operations in other caches could occur, but allow direct inter-cache transfers to occur (w/o requiring the record to be read from disk).
the much more daring improvment was to extend the fast commit logic to the distributed cache environment, not only allowing multiple commits to go unwritten to home location ... but the commits could occur not only sequentually in the same log ... but could be distributed across multiple logs. In the worst case failure scenario, recovery then becomes an issue of merging all of the distributed logs so that the commit entries occur in their original sequential order.
the previous gee-wiz postings:
https://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2003i.html#72 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2003j.html#3 A few Z990 Gee-Wiz stats
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Mon, 09 Jun 2003 04:14:11 GMTPeter Flass writes:
reference to meeting with claim 1/3rd exploits being buffer overflows, 1/3rd virus over the network exploiting automatic scripting, and 1/3rd being various kinds of social engineering typically involving some from of identity/information theft.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Whatever happened to 'University Computer Centers'? Newsgroups: alt.folklore.computers Date: Mon, 09 Jun 2003 20:58:43 GMTJoe Morris writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: 20th anv. of 1000th node on internal network Newsgroups: alt.folklore.computers,bit.listserv.ibm-main Date: Tue, 10 Jun 2003 15:26:26 GMTas per some of of my recent posting in various newsgroups, today is the 20th anv. of the 1000th node on the internal network.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Idiot drivers Newsgroups: alt.folklore.computers Date: Tue, 10 Jun 2003 18:18:20 GMTjmfbahciv writes:
I was told that there were frost heave problems in that section every year. I again repeated that I had driven on Idaho county road in the rockies that was better quality than the mass pike .... and that there are road construction specifications for how to build in areas that are be subject to frost heaves.
somebody (born and raised in mass) then made reference to that fact that road repair is big time business in mass and that if it had been done correctly originally, then there wouldn't be the annual contracts to fix it. there were then jokes about the road repair industry in mass. utilizing large quantities of water soluable asphalt.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.folklore.computers Date: Tue, 10 Jun 2003 23:27:54 GMTararghNOSPAM writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Wed, 11 Jun 2003 01:34:21 GMTEric Smith <eric-no-spam-for-me@brouhaha.com> writes:
you discover that there has been a review of this missile built by some
really bright engineers. the bright engineers say that during testing,
every time the missile is fired it hits the flares on the drone target.
they were asked what kind of guidance system does the missile have,
they answer heat seeking. they were asked what kind of heat seeking,
they answer pin point. they were asked what is the hottest part of a
jet. somebody then decides to terminate the review.
https://www.garlic.com/~lynn/99.html#120 atomic History
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.folklore.computers Date: Wed, 11 Jun 2003 03:57:48 GMT"Glen Herrmannsfeldt" writes:
the major cms change was that the "cambridge" cms would test if it was running on the bare machine or not and decide to use the cp diagnose APIs if it was running under cp. this test was removed for the "conversational" cms, precluding its ability to run on the bare hardware.
i used to have multiple copies of complete cp67/cms on tapes
... including all of the infrastructure to bootstrap everything from
scratch. This was the source where I was able to pull off the original
multi-level source maint. procedures for melinda varian for her
reference:
https://www.leeandmelindavarian.com/Melinda#VMHist
however, all of the tapes were in the same tape library in almaden
... which later went thru something of a troubled period and for one
reason or another ... operators managed to mount all of the tapes as
scratch. misc. past ref:
https://www.garlic.com/~lynn/2001b.html#76 Disks size growing while disk count shrinking = bad performance
https://www.garlic.com/~lynn/2001h.html#57 Whom Do Programmers Admire Now???
https://www.garlic.com/~lynn/2003i.html#13 A Dark Day
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Wed, 11 Jun 2003 13:32:46 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
for the originally payment gateway (for what is now typically referred to as electronic commerce) we required quite a bit of extra work. traditional processing tends to be circuit based where there is some amount of bootstrapping diagnostic procedures ... starting with end-to-end loop back ... as well as stuff like SLAs (service level agreements). trouble/call center is nominally expected to perform first level problem determination within five minutes. an early straight line version of the gateway ... had a call into the trouble center where the trouble ticket after three hours of manual diagnoses was closed NTF (no trouble found).
a matrix of five states and something like 40 conditions was defined regarding various kinds of network, softwrae, and hardare failures which the applictication either had to automatically recover from and/or provide enuf diagnostic information to support five minute first level problem determination.
effectively most of the work didn't have to do with taking "A" and turning it into "B" ... but what are all possible things that are likely to go wrong along the way; or is isn't how it can be made to work once, it is how it can be made to (nearly) work every time.
misc. past threads with business/industrial strength data processing:
https://www.garlic.com/~lynn/94.html#44 bloat
https://www.garlic.com/~lynn/98.html#4 VSE or MVS
https://www.garlic.com/~lynn/aadsm2.htm#architecture A different architecture? (was Re: certificate path
https://www.garlic.com/~lynn/aepay6.htm#erictalk2 Announce: Eric Hughes giving Stanford EE380 talk this
https://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm11.htm#33 ALARMED ... Only Mostly Dead ... RIP PKI
https://www.garlic.com/~lynn/aadsmail.htm#parsim parsimonious
https://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001h.html#1 Alpha: an invitation to communicate
https://www.garlic.com/~lynn/2001l.html#4 mainframe question
https://www.garlic.com/~lynn/2001l.html#14 mainframe question
https://www.garlic.com/~lynn/2001n.html#90 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow
https://www.garlic.com/~lynn/2002.html#26 Buffer overflow
https://www.garlic.com/~lynn/2002.html#28 Buffer overflow
https://www.garlic.com/~lynn/2002.html#32 Buffer overflow
https://www.garlic.com/~lynn/2002.html#38 Buffer overflow
https://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
https://www.garlic.com/~lynn/2003e.html#11 PDP10 and RISC
https://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Thu, 12 Jun 2003 14:14:47 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: pbx security from 20 years ago Newsgroups: comp.security.misc Date: Fri, 13 Jun 2003 15:10:20 GMTpbx's were discovered to be major vulnerability at least 20 years ago ... this particular scenario was with regard to hotel pbx which might not even be in locked room ... and encryption requirement for business people reading email while traveling:
and (re)discovered more recently:
Homeland Security Information Bulletin
Compromised Private Branch Exchange (PBX) and Telephone Voice Mail
Systems June 3, 2003
This Bulletin is being disseminated for information purposes only. The
Department of Homeland Security is working with the Federal Bureau of
Investigation to address multiple reports from private industry
describing incidents involving compromises of Private Branch Exchange
(PBX) and telephone voice-mail systems. These compromises allow
unauthorized users to make long distance domestic and international
telephone calls through the compromised systems. FBI Field Offices in
several cities have been working closely with fraud investigators from
various telecommunication carriers who have reported encountering
intruders making numerous international calls.
A common scenario for these compromises follows this general pattern:
An intruder circumvents a PBX system's security and gains access to a
voice-mail system. The intruder may then configure the compromised
system to dial out to a domestic or foreign phone number.
PBX compromises are not a new vulnerability, but they highlight the
need for PBX users to maintain vigilance. These schemes appear to be
becoming more prevalent. This illegal activity enables unauthorized
individuals anywhere in the world to communicate via compromised US
phone systems in a way that is difficult to trace. Reports have also
surfaced suggesting that some of these unauthorized calls are being
used to connect to local access numbers for internet service
providers, thereby giving the caller free Internet service via a
modem. An intruder gaining unauthorized access to several mailboxes
can redirect repeated calls to a specific number, such as 911, and
cause denial-of-service (DoS) activity.
While law enforcement and industry investigators work to mitigate
these ongoing schemes and prosecute the responsible parties, DHS in
coordination with the FBI has chosen to highlight this activity in
order to raise awareness among users of PBXs to the possible risk
associated with exploitation of the PBX vulnerability. DHS and the FBI
recommend that phone system administrators review their internal
security policies, enable all password protection functions, change
default passwords and continually audit phone billing records to
detect unauthorized activity. Users of PBX systems should consider
protecting themselves by performing the following basic actions:
1. Periodically change the phone system administrator and
maintenance passwords.
2. Lock users out after a limited number of failed attempts at
accessing password protected accounts.
3. Mandate that all users create their own passwords and change them
periodically.
4. Ensure that passwords are as long as permitted by your system.
5. Properly secure or disable unnecessary features such as call
forwarding or call transfer.
6. Assign someone as phone system/voice mail administrator and keep
him/her informed of personnel changes.
The National Institute of Standards and Technology (NIST) makes
available on its Web page NIST Special Publication 800-24 entitled
"PBX Vulnerability Assessment - Finding Holes in Your PBX Before
Someone Else Does." This provides generic PBX security methodology and
vulnerability analysis. The report can be found at:
http://www.csrc.nist.gov/publications/nistpubs/800-24/sp800-24pbx.pdf
For specific security and vulnerability information, PBX
administrators should consult with their respective PBX system vendor.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: why doesn't processor reordering instructions affect most software? Newsgroups: comp.arch Date: Fri, 13 Jun 2003 18:14:13 GMTBrannon_Batson@yahoo.com (Brannon Batson) writes:
thornton 6600 & tomasulo 360/91
http://www.cs.swan.ac.uk/~csneal/HPM/tomasulo.html
somewhat related
https://people.computing.clemson.edu/~mark/acs_technical.html
from above
A generalized scheme for parallel decoding of multiple instructions
and out-of-order issue, was proposed by Lynn Conway in late
1965. Conway, who joined the project in 1964 after finishing graduate
work at Columbia, was assigned with Don Rozenberg to develop the
machine simulator. Approaching the problem of instruction decoding and
issuing from a software and systems point of view, she hit upon a
general scheme for multiple issue that, due to its regularized
structure, could be implemented within the maximum number of gate
levels of the ACS machine cycle. Conway speculates that preoccupation
with assumed gate-level limitations may have constrained design
options considered by earlier designers to less ambitious out-of-order
schemes. Her multiple-decode and multiple-issue scheme was developed
in late 1965, independently of the out-of-order issue proposal for the
floating-point unit of the S/360 Model 91. (rewrite this to include
effect of backup registers - simplified form of register renaming for
FP loads.) Both the Model 91 and the CDC 6600 are based on decoding at
most one instruction per cycle. Her proposal, formally accepted by the
ACS architecture group in 1966, appears to be the first invention of
the generalized (i.e., multiple-decode, multiple-issue) dynamic
instruction scheduling we see in current-day processors.
The ACS-1 design called for one 8-entry contender stack for index
instruction and one 8-entry contender stack for arithmetic
instructions. Loads were sent to both the index and arithmetic stacks
to maintain instruction ordering. The X stack could issue up to three
instructions per cycle in-order; the A stack could issue up to three
instructions per cycle out-of-order. Thus, up to 7 instructions could
be issued per cycle: 3 index operations (two of which could be
load/stores), three arithmetic operations, and one branch. As in the
Stretch, it was expected that the index part of the ACS-1 machine
would run ahead of the arithmetic part, and therefore loads would be
started early enough to hide the memory latency. (This general
technique would acquire the name "decoupled access-execute
architecture" from Jim Smith in 1982; in his research and subsequent
work on the Astronautics ZS-1, FIFO buffers in between the two units
would take the place of the ACS-1 backup register scheme.)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: tcp time out for idle sessions Newsgroups: comp.protocols.tcp-ip Date: Fri, 13 Jun 2003 20:17:45 GMTRick Jones writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.folklore.computers Date: Fri, 13 Jun 2003 22:08:07 GMTAlex Colvin writes:
misc. PLI varying refs:
http://mailgate.supereva.it/comp/comp.lang.pl1/msg02564.html
http://www.users.bigpond.com/robin_v/pli-n5.htm
http://www-3.ibm.com/software/awdtools/pli/pli1297.htm
http://www.agorics.com/Library/KeyKos/Gnosis/171.html
http://www-3.ibm.com/software/awdtools/pli/pli0695.htm
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Qwerty vs Dvorak Newsgroups: alt.folklore.computers Date: Fri, 13 Jun 2003 23:07:10 GMTMichael Wojcik writes:
when I first did tty/ascii support, I remember mapping left/right brackets to the character/line delete functions. i can't find a reference to teletype keyboard layout and can't remember for sure the details of why I did that.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: why doesn't processor reordering instructions affect most software? Newsgroups: comp.arch Date: Sat, 14 Jun 2003 00:07:01 GMTMichael Koenig writes:
our manager in engineering when my wife and I were doing ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
had previously been at motorola, had done a lot of rios work, then
went on to head up somerset, and then became president of mips during
the 10k work.
John Cocke was heavily involved with power, having original
worked on stretch (ca. 1960)
http://www.cs.clemson.edu/~mark/stretch.html
and acs (as per previous post, ca 1967)
https://people.computing.clemson.edu/~mark/acs.html
and then starting with 801/risc in 1975
timeline from above: rios (aka power1) 1989
power/pc 601 1993
power/pc 603 1994
power/pc 604 1994
power2 1994
from:
http://www.sit.wisc.edu/~mptaylor/microprocessor.html
The IBM/Motorola PowerPC 601 brought RISC technology to mass-market
computers in 1993. "It was one of the first microprocessors to
implement out-of-order execution of instructions. This processor and
its successors have been adopted by Apple for its Power Macintosh
line" ("The Microprocessor at 25" 147+). The processor runs at clocks
speeds ranging from 50 to 120 MHz ("Power PC" 4). The chip contains
2.8 million transistors ("The Microprocessor at 25" 147+). The
processor was the first 32-bit chip in the Power PC architecture
("Power PC" 2).
the CPU Infro center at:
http://bwrc.eecs.berkeley.edu/CIC/
1994 CPU announcements:
http://bwrc.eecs.berkeley.edu/CIC/announce/index-1994.html
1996 CPU announcements:
http://bwrc.eecs.berkeley.edu/CIC/announce/index-1996.html
Section Five Born Beyond Scalar:
http://bwrc.eecs.berkeley.edu/CIC/archive/cpu_history.html
Part III: overview of RIOS on the above page
from above (POWER1 in rs/6000, aka RIOS)
POWER1 was also one of the first superscalar CPUs of its generation,
the branch unit could dispatch multiple instructions to the two
functional unit input queues while itself executing a program control
operation (up to four operations at once, even out of order).
Speculative branches were supported using a prediction bit in the
branch instructions (results discarded before being saved if not
taken, the alternate instruction was buffered and discarded if the
branch was taken), and the branch unit manages subroutine calls
without branch penalties, as well as hardware interrupts. Results are
forwarded to instructions in the pipeline which use them before they
are written to the registers.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.folklore.computers Date: Sat, 14 Jun 2003 03:25:01 GMTMichael Wojcik writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Red Phosphor Terminal? Newsgroups: alt.folklore.computers Date: Sat, 14 Jun 2003 15:46:42 GMTBrian Inglis writes:
you could write automated terminal scripts (and do screen scraping) ... well before IBM/PCs and HLLAPI.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Idea for secure login Newsgroups: sci.crypt Date: Sat, 14 Jun 2003 18:47:28 GMTpaul@westpoint.ltd.uk (Paul Johnston) writes:
so one scenario is something like a SSL session ... as countermeasure against things like MITM attacks during account creation aka it isn't just that the password has to be securely exchanged in the first place, it is that the authentication material (shared-secret, non-shared-secret, whatever) also has to be securely bound to the account creation process (since you brought up the issue of vulnerabilities during the account creation process).
other scenarios are to use non-shared-secrets ... and send a public key to be registered in lieu of a password.
basically (public key registered in lieu of shared-secret) is
outlined for both radius (the predominant infrastructure for AAA on
the internet) ... misc. radius posts
https://www.garlic.com/~lynn/subpubkey.html#radius
as well as kerberos pk-init ... the environmental infrastructure found
in windows and many other platform. misc. pk-init refs:
https://www.garlic.com/~lynn/subpubkey.html#kerberos
so imagine that what is being registered is not a shared-secret and is not vulnerable to any kind of evesdropping. however, both shared-secret and non-shared-secret (like public keys) authentication material are still vulnerable to things like MITM attacks during the account setup process. You still need security even if you have totally addressed the evesdropping issue (either via cloaking a shared-secret or using a non-shared-secret).
once the authentication material is registered ... then the solution is for both the server and the client provide information as part of the authentication message (login) ... as part of various kinds of replay attacks. The server can do that with a totally random number, a global incrementing integer, and/or a time-of-day value. The client then combines that with something they supply. In the public key case, the client digitally signs the combined message contents and sends off either the full combined message ... or just their addition and the digital signature. If it is the full combined message, then the server just validates the digital signature from the public key registered in the account record. If it is the abbreviated message, the server first reconstructs the message that was digital signed with their contribution.
If the client provides both unique (or the only unique) pieces, then the server has to remember all past client provided unique pieces as replay countermeasure (modulo some structure to the client unique piece that only requires the most recently used piece to be recorded, but then both the server and the client have to keep that piece of information in sync). If the server provides one of the unique pieces, it only has to verify that particular unique piece was used in the authentication/login message (like fine granularity timer that only has to be remembered for the duration of the login process).
there are a number of other shared-secret vulnerabilities ... which lead to the guidelines about frequently changing shared-secrets and to never use a shared-secret from one security domain in another security domain (like place-of-work, online banking, local personal ISP login, etc). The proliferation of authentication environments leads to the human factors shortcomings of using easily guessed shared-secrets, re-using the same shared-secret in multiple environments, and/or having to record shared-secrets in obvious places.
some recent shared-secret threads
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#26 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#31 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#34 virus attack on banks (was attack on paypal)
https://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aepay11.htm#22 FBI Probing Theft of 8 Million Credit Card Numbers
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aepay11.htm#49 A More Anonymous Internet
https://www.garlic.com/~lynn/aepay11.htm#50 Concern Grows About ID Theft
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
https://www.garlic.com/~lynn/2003e.html#57 Security in RADIUS (RFC2865)
https://www.garlic.com/~lynn/2003h.html#55 PKINIT
https://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#2 Two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.folklore.computers Date: Sat, 14 Jun 2003 19:10:03 GMT"Charlie Gibbs" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.folklore.computers Date: Sat, 14 Jun 2003 19:32:48 GMTCharles Shannon Hendrix writes:
Later on 370 you could use the MVCL instruction with a zero length
from and a zero for pad (aka MVCL had both from & to lengths as well
being able to specify the pad when the to length was larger than the
from length).
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.3.26?DT=19970613131822
from above:
The technique for setting a field to zeros that is illustrated in the
second example of MVC cannot be used with MVCL. If the registers were
set up to attempt such an operation with MVCL, no data movement would
take place and condition code 3 would indicate destructive overlap.
Instead, MVCL may be used to clear a storage area to zeros as
follows. Assume register 8 and 9 are set up as before. Register 3
contains only zeros, specifying zero length for the second operand and
a zero padding byte. Register 2 is not used to access storage, and its
contents are not significant. Executing the instruction MVCL 8,2
causes locations 60000-607FF to be filled with zeros. Bits 8-31 of
register 8 are incremented by 80016, and bits 0-7 of registers 2 and 8
are set to zeros. Bits 8-31 of register 9 are decremented to zero, and
condition code 2 is set to indicate that the first operand is longer
than the second.
...
I got to help shoot a 370/125 MVCL microcode bug. On 360, all of the instructions prechecked theirq start and end bounds ... for access & fetch protection as well as page fault (in virtual memory) before starting the instruction. The CLCL & MVCL instructions introduced on 370 were defined not to precheck the ending bounds, they just incrementally executed the instruction, updating the register contents as appropriate (which also made the instruction interrruptable and restartable). The 125 microcode bug prechecked the ending bounds of the CLCL & MVCL instructions and programs failed that expected to see partially executed CLCL/MVCL operation.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Offshore IT Newsgroups: alt.folklore.computers Date: Sat, 14 Jun 2003 20:54:30 GMTjmfbahciv writes:
it says that only half the students are currently passing the 10th grade level exam (in english and math). presumably they could dumb it down and only require an 8th grade education to graduate from 12th grade?
it is also says that the cancellation is good because it will save the state $1.3m ... ignoring the issue of uneducated citizens.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3725 Comms. controller - Worth saving? Newsgroups: alt.folklore.computers Date: Sun, 15 Jun 2003 14:22:46 GMTRob Storey writes:
with the series/1 running ncp & sscp (aka vtam) emulation. the sscp emulator supported distributed ownership (no-single-point-of-failure) and fake-out cross-domain ownership to the mainframe vtam. maybe 15 years, you started seeing similar capabilities in real ncp & sscp.
3725s were really slow ... would saturate at about 80 500-byte messages/sec.
one of the people in raleigh kept telling us that they might someday be able to support T1 thru a 3725.
we were also doing hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt
and we were at the cape for the lift-off of 41d carrying sbs4 (we were
going to be using transponder on sbs4 for a project) and it was
delayed a day and some people from raleigh wanted to talk about the
37xx stuff. we made a quick trip up to raleigh and back for the
discussion. it was not an easy trip to get from the cape to raleigh
and back.
http://www.nasa.gov/mission_pages/shuttle/shuttlemissions/archives/sts-41D.html
old raleigh story:
https://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
https://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How is a smartcard created? Newsgroups: alt.technology.smartcards Date: Sun, 15 Jun 2003 18:40:26 GMT"Duble" writes:
i got to walk all the lines. basically 8in or 12in diameter wafers from the chip fabrication. chips are little tiny things .... possibly several thousand per wafer. they get tested and the bad chips marked. the wafers are then typically sent to module embedding plant ... where the wafer is sliced and diced into the individual chips. Each chip placed inside the 7816 module (which come on long tape spool with possible a couple thousand modules per spool) and also retested.
The spools are then sent to card embedding. The white plastic stock has the depression for the 7816 module milled out and the 7816 module embedded into the plastic. basically can have a machine with a spool of 7816 modules, a whole pile of white plastic, the machine takes a card, mills out depression in plastic and then places the module into the card ... and then the whole thing is retested.
the small (phone, etc) simms use the same 7816 payment card size .... but the plastic card has punches around the simm so that it can be easily removed from the card. for simms, this leverages the significant investment in automated 7816 card machinary.
the specification for the 7816 milling and module placement is very precise.
from the module embedding, the boxes are cards then can be sent off to personalization plant (like at credit card processor) for plastic embossing along key injection and personalization of the chip. typically along the way, all of the stuff is kept under high security lock and key ... and transported in armored vehicles.
asuretee is a little different since before it leaves the chip fabrication plant all personalization has been completed and the chip requires no further personalization. It can be sent off for 7816 module embedding or directly off to some manufacturing plant for direct embedding in some device.
One of the reasons for the high security lock and key for traditional chips .... is so that the processor has a high level of confidence that the chips that left the manufacturing plant are still the actual chips that are in the cards that will be mailed off & delivered to the end customer. the financial industry has gone to a great deal of trouble to develop extremely high security/integrity chips for financial applications .... and they would prefer counterfeit chips not to have be substituted somewhere during processing.
asuretee uses a high security process in the chip manufacturing plant for unique FIPS186-2, ecdsa public/private key generation in the chip, where the private key is never divulged. Digital signatures by the chip then becames a form of trusted chip serial number (that isn't duplicatable).
It is then possible for any institution to verify the integrity of any chip, at any time, with a extremely high degree of confidence by cross-checking a digital signature (from any chip) with the manufacturing integrity service. In that way, substitution of counterfeit chips .... either before or after personalization ... or even after delivery of the token to the end customer can be readily spotted.
In theory, institutions that currently reuquire the armored car process ... for guaranteeing the integrity level of chips actually arrive .... could start accepting consumer presented hardware tokens, since the integrity level of asuretee chips can be verified with the integrity service.
I'm giving a more detailed talk at IEEE chip conference next week.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Sun, 15 Jun 2003 18:05:26 GMTDowe Keller writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Language semantics wrt exploits Newsgroups: comp.arch Date: Mon, 16 Jun 2003 02:03:05 GMTbhurt@spnz.org (Brian Hurt) writes:
apl had very distinctive pattern that looked like sawtooth ... (all assignments resulted in allocation of new space) ... pattern slowly growing to the top of memory and then a very strong straight line as garbage collection occurred and compacted all used data. the original design point of apl\360 was 16kbyte to 32kbyte workspaces swapped in and out of real memory.
ported to cms\apl ... it was more likely to be 1mbyte to 16mbyte virtual memory available used as workspace. Even relatively small, compact cms\apl programs might only be 32kbytes ... but if they ran for any period of time would evenaully touch all of available virtual memory.
Potentially, you might have 80 total cms users, half dozen or more running cms\apl, each with mbyte or more of virtual memory ... all on a real 360/67 with 768kbytes real memory (about 100 4k virtual pages after fixed memory requirements). total allocated virtual memory could easily be tens of megabytes.
One of the first things that cambridge had to do as part of cms\apl was rewrite the garbage collector to make it much more virtual memory friendly (early '70s, some 30 odd years ago).
misc. past apl &/or hone references:
https://www.garlic.com/~lynn/subtopic.html#hone
misc. past cambridge (4th floor, 545 tech sq) references:
https://www.garlic.com/~lynn/subtopic.html#545tech
misc. past refs to vs/repack
https://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
https://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
https://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
https://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
https://www.garlic.com/~lynn/2002f.html#50 Blade architectures
https://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
https://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
https://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A Dark Day... Newsgroups: alt.folklore.computers Date: Mon, 16 Jun 2003 02:18:34 GMTshannon@daydream.shannon.net (Charles Shannon Hendrix) writes:
the kernel product group were releasing monthly updates to the base kernel ... and I needed to somewhat track the various kernel activities. every three months I would do a re-integration at the most current level and then perform a sample 100 regression benchmarks or so to verify that ongoing changes hadn't affected the operation of the resource manager.
misc. benchmarking
https://www.garlic.com/~lynn/submain.html#bench
hardware tended to be much more rigorous. disk engineering was in bldg. 14. right next door in bldg. 15 was product test ... which did bunch of testing before product was allowed to ship. Among other things they had a fairly large environmental chamber that you could roll these six foot high, refer sized boxes into and operate while controlling air pressure, humidity, temperature. one of the things was that engineering and product test did not share common management until quite high in the organization. there was also an edict that people working in one organization couldn't even have door badge authorization for the other organization's bldg (although there were a couple of us that slipped thru the cracks for one reason or another).
misc. disk engineering
https://www.garlic.com/~lynn/subtopic.html#disk
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Interrupt in an IBM mainframe Newsgroups: bit.listserv.ibm-main Date: Mon, 16 Jun 2003 19:15:32 GMTtjpo@AIRBORNE.COM (Patrick O'Keefe) writes:
the alternative to interrupts has been polling. it used to be that it was extremely clear-cut that interrupt overhead was much lower than polling overhead (only doing something when there was something to do, vis-a-vis constantly checking to see if there was something to do, whether there is or not). however with increase in cache machines (dependent on cache locality) and highly pipelined machines, interrupts have become relatively more expensive.
long ago and far away (going on 30 years and shipped in the resource manager product), i went to a interrupt rate threshhold and turned off i/o interrupts during program execution (but left on external/timer interrupts). kernel would periodically poll for any i/o interrupts (by masking on i/o interrupts and then masking them off). This is intermediate between having to poll each device for new events ... and having total interrupt anarchy.
under high i/o interrupt rate, any i/o interrupt latency/delay because of being masked off tended to be more than compensated for by the tendency to batch i/o interrupts and the more efficient processing because of improved cache hit of the i/o interrupt processing routines.
fair share &/or resource manager:
https://www.garlic.com/~lynn/subtopic.html#fairshare
replacement algorithms &/or resource manager
https://www.garlic.com/~lynn/subtopic.html#wsclock
slightly related, automated benchmarking for calibrating resource
manager
https://www.garlic.com/~lynn/submain.html#bench
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: why doesn't processor reordering instructions affect most software? Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 17 Jun 2003 03:37:15 GMTPaul DeMone writes:
the reference in the above to:
http://www.cs.clemson.edu/~mark/architects.html Recent Processor Architects
There is mention of both Birnbaum & Worley in the 801 and the PA-RISC
sections
http://www.cs.clemson.edu/~mark/architects.html#workstation
and the Intel IA-64 section:
http://www.cs.clemson.edu/~mark/architects.html#indep
previous references to joke about there really only being 200 people
https://www.garlic.com/~lynn/2001n.html#46 Blinking lights
https://www.garlic.com/~lynn/2002.html#16 index searching
https://www.garlic.com/~lynn/2002l.html#37 Computer Architectures
https://www.garlic.com/~lynn/2002o.html#9 PLX
https://www.garlic.com/~lynn/2003d.html#69 unix
https://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: CC vs. NIST/TCSEC - Which do you prefer? Newsgroups: sci.crypt Date: Tue, 17 Jun 2003 13:07:17 GMTpgut001@cs.auckland.ac.nz (Peter Gutmann) writes:
CC provides protection profiles that allows certification to be specific to an environment or type of product ... where there may be compensating procedures and/or not applicable in the orange book scenario. so you now have things like firewall and smartcard protection profiles. however, at a meeting a couple months ago, there was report that of the 60 some odd CC certifications, all but 3-4 got deviations/exemptions. The issue then became how to evaluate two similar products with similar certifications ... if they all deviate one way or another.
for crypto-specific products .... FIPS140 certification is frequently (also) needed ... especially when any/the protection profile doesn't cover FIPS140 crypto areas.
misc. past postings on CC & protection profiles.
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
https://www.garlic.com/~lynn/aepay4.htm#x9flb12 LB#12 Protection Profiles
https://www.garlic.com/~lynn/2001.html#50 What exactly is the status of the Common Criteria
https://www.garlic.com/~lynn/2001i.html#55 Computer security: The Future
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
https://www.garlic.com/~lynn/2002k.html#35 ... certification
https://www.garlic.com/~lynn/2002m.html#72 Whatever happened to C2 "Orange Book" Windows security?
https://www.garlic.com/~lynn/2003c.html#39 DOD 5200.28-STD capable OS?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Overflows Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Thu, 19 Jun 2003 01:09:26 GMTararghNOSPAM writes:
LCR
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.47?DT=19970613131822
LNR
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.51?DT=19970613131822
LPR
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.52?DT=19970613131822
FP
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/9.0?DT=19970613131822
FP load compliment
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/9.4.8?DT=19970613131822
FP load negative
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/9.4.9?DT=19970613131822
FP load positive
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/9.4.10?DT=19970613131822
search on "overflow" in POP yields:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/SEARCH?Book=dz9ar004&searchRequest=overflow&SEARCH=Search&Type=EXACTW&SHELF=&DT=19970613131822&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK
Ranked Search Results for Book: dz9ar004 66 topics have matches for: overflow 1. Fixed-Point-Overflow Exception, 6.5.2.19 2. Decimal-Overflow Exception, 6.5.2.12 3. Signed Binary Integers, A.1.1.1 4. Channel-Report Word, 17.9.2 5. Exponent-Overflow Exception, 6.5.2.14 6. Fixed-Point Overflow, 7.3.1.2 7. Binary Arithmetic, 7.3 8. ADD DECIMAL, 8.3.1 9. ZERO AND ADD, 8.3.9 10. Program-Status-Word Format, 4.2.1 11. SHIFT AND ROUND DECIMAL, 8.3.7 12. LOAD COMPLEMENT, 7.5.47 13. SHIFT LEFT DOUBLE, 7.5.73 14. SUBTRACT, 7.5.88 15. Unsigned Binary Arithmetic, 7.3.2 16. ADD, 7.5.1 17. ADD HALFWORD IMMEDIATE, 7.5.3 18. LOAD POSITIVE, 7.5.52 19. SUBTRACT HALFWORD, 7.5.89 20. SHIFT LEFT SINGLE, 7.5.75 21. Floating-Point Number Representation, 9.1 22. Decimal-Arithmetic Instructions, 8.2.1 23. Measurement Block, 17.1.2.1 24. MULTIPLY, 9.4.12 25. SUBTRACT DECIMAL, 8.3.8 26. DIVIDE, 9.4.4 27. SHIFT LEFT DOUBLE (SLDA), A.3.36 28. SHIFT LEFT SINGLE (SLA), A.3.37 29. ADD NORMALIZED, 9.4.1 30. LOAD ROUNDED, 9.4.11 31. Interruption Action, 6.1 32. STORE CHANNEL REPORT WORD, 14.3.10 33. Binary-Integer Representation, 7.2 34. MULTIPLY HALFWORD IMMEDIATE, 7.5.65 35. ADD UNNORMALIZED, 9.4.2 36. Channel Report, 17.9.1 37. Floating Point to Fixed Point, A.5.7.2 38. Appendix B. Lists of Instructions, B.0 39. Decision Making, 5.3.1 40. Format, 4.6.1.1 41. Formation of the Intermediate Value, 5.2.3.1 42. Formation of the Intermediate Value, 5.2.4.1 43. Signed and Logical Comparison, 7.4 44. BRANCH RELATIVE ON COUNT, 7.5.16 45. CONVERT TO DECIMAL, 7.5.33 46. MULTIPLY, 7.5.63 47. MULTIPLY SINGLE, 7.5.66 48. SUBTRACT LOGICAL, 7.5.90 49. MULTIPLY DECIMAL, 8.3.6 50. Normalization, 9.2 51. COMPARE, 9.4.3 52. SUBTRACT NORMALIZED, 9.4.15 53. SUBTRACT UNNORMALIZED, 9.4.16 54. Channel-Subsystem Timer, 17.1.1.1 55. Unsigned Binary Integers, A.1.1.2 56. MULTIPLY HALFWORD (MH), A.3.32 57. ADD DECIMAL (AP), A.4.1 58. ZERO AND ADD (ZAP), A.4.8 59. BRANCH ON COUNT, 7.5.11 60. BRANCH ON INDEX LOW OR EQUAL, 7.5.13 61. BRANCH RELATIVE ON INDEX LOW OR EQUAL, 7.5.18 62. Instructions, 8.3 63. SQUARE ROOT, 9.4.13 64. Floating-Point-Data Format, 9.3 65. Instructions, 9.4 66. Instructions, 7.5--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Virtual Cleaning Cartridge Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 19 Jun 2003 02:48:14 GMTMatthew.Stitt@ABCDISTRIBUTING.COM (Matthew Stitt) writes:
I do have OSDEATH ... and now "computing on demand" has given reality to "Multiprogramming with a Variable Number of CPUs".
Random aside, one of the executives that sponsored HPSS at LLNL coined
the term information utility:
https://www.garlic.com/~lynn/2001.html#20 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001.html#19 Disk caching and file systems. Disk history...people forget
and the more things change (sun exec says utility computing just starting
to evolve):
http://www.computerworld.com/databasetopics/data/datacenter/story/0,10801,82263,00.html
the more the stay the same (shared-utility computing):
https://www.garlic.com/~lynn/2002e.html#47 Multics_Security
from long ago and far away:
In the first few months of the year that System 360 Operating System
came to a full stop, all signs appeared normal and there was no
indication of an impending disaster. The SDD Manager of Programming
Systems stated at the spring SHARE meeting that the F Level of FORTRAN
V would definitely be implemented and would at least equal the speed
of the E Level FORTRAN V subset, provided it was run on a Model 75 or
greater. There was no truth, he asserted, to the rumor that IBM was
dropping FORTRAN in favor of PL/3. Option 89, or MVC
(multiprogramming with a variable number of CPU's), which had been
released in System Release 101.8 was hailed by a large number of users
as the ultimate in operating systems. Representatives of a major
government agency which had been running a Model 91 with 8 million
bytes using a modified BPS supervisor, lodged a mild protest, but were
shouted down by the majority.
On April 1, an announcement by the Management Information Department
of DPD caused quite a stir. Their Management Action Optimization
(MAO) program would be written using the new Linear Interpretation
Nucleus (LIN), part of DOS extended. This occurred, it was rumored,
in spite of persistent efforts by the Marketing Verification
Department (MVD) to persuade them to use OS. This department is
charged with the "purification" of TYPE II programming standards.
There were indications, however, that something was in the air. The
OS Internals Workshop was extended from 13 weeks to 26 weeks. A
resident psychiatrist was installed to try to cut down on nervous
breakdowns, defections, and AWOL's. A blue letter advised salesmen
that "throughput" and "turnaround time" were not to be used. The
byword was to be "full utilization of system resources." At all
costs, customers were to be discouraged from asking, "But when will my
job be completed?"
Release 91.0 contained a module of the nucleus that stopped the
software clock during system overhead time. Murmurs about the
difference between meter time and time accounted for led to the
removal of all meters and a shift from a 176 hour base to 264 hours
per month. Dissatisfaction was increasing, however; one large
scientific/engineering/commercial customer announced his intention to
switch to a competitor, but after two years was unable to do so
because he was unable to discover exactly what his system was doing.
The end finally came in mid-October. System Release 110.7 was
distributed, which converted everyone to MPSS (Multiple Priority
Scheduling System), which combined the following control program
options:
Multiprogramming with a Valuable Number of Tasks
Multijob Initiation
Multiple Priority Secection
Multiprocessing with a Variable Number of CPUs
SYSGEN was accomplished with little difficulty in 504 system hours.
Expectantly, customers IPLed and initiated their job streams.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: tunneling TCP/IP over UDP for high-latency links? Newsgroups: comp.protocols.tcp-ip Date: Thu, 19 Jun 2003 02:17:33 GMTbennett@peacefire.org (Bennett Haselton) writes:
bibliography
http://www.ca.sandia.gov/xtp/biblio.html
most of the more recent RFCs discussing long delay issues have been regarding various wireless implementations.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: tunneling TCP/IP over UDP for high-latency links? Newsgroups: comp.protocols.tcp-ip Date: Thu, 19 Jun 2003 18:57:29 GMTbennett@peacefire.org (Bennett Haselton) writes:
the approach can be done from two standpoints ....
1) what are the minimum number of things that you need to add to a protocol running on UDP;
2) another way of looking at it would be what features don't you want from an XTP protocol running on top of UDP (aka there might be some things thot of in the XTP effort that are actually useful that might be thot of immediately on the first go around of designing something from scratch).
the reply in XTP comes in one round trip ... the 3rd packet is for reliable delivery and reliably closing the connection; aka XTP piggybacks the session open and transaction in single packet with the response in the return.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Of what use 64-bit "General Purpose" registers? Newsgroups: comp.arch Date: Fri, 20 Jun 2003 14:10:09 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
back in early to mid '70s, it was worked on for 370/195 to address a thruput problem. Any branch not to a target in the pipeline would stall the pipeline. having two independent threads had better chance of keeping pipeline full and thruput near peak. they doubled the psw/i-fetch and the registers ... and used one bit flag to tag thread.
precursor to the 370/195 thread is mentioned in the 1968 ACS-360
description as the red/blue bit to designate instruction stream and
register set
https://people.computing.clemson.edu/~mark/acs_technical.html
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Flash 10208 Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 20 Jun 2003 19:21:24 GMTChris_Craddock@BMC.COM (Craddock, Chris) writes:
note:
http://www.cs.clemson.edu/~mark/architects.html
split cache mention from above (now seen in power & power/pc chips):
IBM 801
Joel Birnbaum started a project in early 1975 within the Research
Division of IBM to do a machine based on John Cocke's ideas for a
simple machine: load-store architecture, execute (delayed) branches,
and split cache; the project took on the 801 name because the
T.J. Watson Research Center building number is 801
...
slightly releated:
https://www.garlic.com/~lynn/2003j.html#18 why doesn't processor reordering instructions affect most
https://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
https://www.garlic.com/~lynn/2003j.html#35 why doesn't processor reordering instructions affect most
mainframe timeline:
https://web.archive.org/web/20050207232931/http://www.isham-research.com/chrono.html from above: 3090-200 announce 2/85, fcs 11/85. 3090-400 announce 2/85, fcs 2q/87
mainframe cache (trout 1.5 aka 3090) description from long ago (20
years) and far away:
Date: 11/18/83 10:48:00
To: wheeler
From: someplace in POK ...
Lynn,
The 1.5 D Cache has two directories which operate in parallel. The
DLAT is a conventional affair which works no differently than it did
in the 3033.
The little logical directory contains addresses most recently used to
access the cache. The addresses are concatenated with a STO ID. One
of the codepoints of the STO ID identifies the address as real,
another makes it Guest real (SIE Guest), a third is for System Area,
and the rest are for usual STOs. When an operand request is made we
access the logical directory with the incoming LOGICAL address and
look for a match between the address in the directory and the target
address, and a match between the STO ID in the directory and the STO
ID of the target. Remember, this directory contains a mixture of
virtual and real addresses (hence the name 'logical directory').
At the same time we cycle the little directory and the cache, we
access a bigger REAL directory. This operates much the same as the
308x and Trout does. The virtual address of the target address is
used to look up the corresponding REAL address in the TLB and that
real address is used as the comparand for the real directory search.
If all goes well, the two directories see a match and the request is
processed in a hurry. A peculiar case may occur in which the logical
directory does not get a match but the real directory does. What
happens there is that the real directory sends the proper information
over to the cache to access the cache arrays for data, and the
requester sees the data two cycles later than he would have if the
logical directory had also obtained a match. Note, no translation is
done here and the only delay is due to the time to get the address
over to the cache. At the same time we access the data, we update the
logical directory to reflect the address so that the next time it is
used we will get a hit in the little directory. Thus, the system
tends to keep the logical directory updated with the addresses most
recently used to access the cache. If STOs change or real-virtual
switches occur, the logical directory follows that history.
So, trying to tie it all together: the instruction cache is managed
with real addresses and doesn't know anything about STOs or synonyms.
(Just like the good old days) The data cache is managed with real and
logical addresses, but the only penalty that occurs is a two cycle
delay on OPERAND FETCHES ONLY (stores always go fast) on the first
reference to a line in the cache in which the addressing mode or
address space has changed. This does NOT look like a cache miss or
TLB miss - the penalties incurred in those cases are considerably
longer.
How does that sound?
... snip ... top of post, old email index
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: An a.f.c bibliography? Newsgroups: alt.folklore.computers Date: Sat, 21 Jun 2003 23:26:04 GMTcbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
in above:
Real Programmers Don't Eat Quiche Real Software Engineers Don't Read Dumps
https://www.garlic.com/~lynn/2002e.html#39 Why Use - ?
in above:
Real Programmers Don't Write Specs
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hand cranking telephones Newsgroups: alt.folklore.computers Date: Sat, 21 Jun 2003 23:36:17 GMTBrian Inglis writes:
one example was long distance company that thot it was doing nightly backups of billing data disk. after a disk crash, they found out that there was a problem in backup and there was nothing on the tapes. a month of billing data was lost. people in charge possibly lost their jobs and more stringent backup process was put in place.
past discussions:
https://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
https://www.garlic.com/~lynn/2002.html#7 The demise of compaq
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hand cranking telephones Newsgroups: alt.folklore.computers Date: Sun, 22 Jun 2003 14:31:35 GMTjmfbahciv writes:
the standard process at cambridge for building a new production cp/67
kernel was to both right the bootable image to disk and a bootable
"card" image for kernel rebuild to tape. the tapes were kept around in
case it was needed to regress. I started a procedure that would add to
the tape all the source and procedures to rebuild the same kernel from
scratch. I had kept a number such tapes around over the years ... and
when melinda
https://www.leeandmelindavarian.com/Melinda#VMHist
was collecting the original cp67/vm370 multi-level source
maint. procedures, I was able to pull it off one such tape. Even tho I
had saved several such tapes ... they were in the same tape library
that later went thru some problems.
minor ref to keeping multiple copies in the same tape library:
https://www.garlic.com/~lynn/2001h.html#57 Whom Do Programmers Admire Now???
https://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003i.html#13 A Dark Day
somebody told me a story of helping setup one of the non-ATT telephone office (late '70s/early '80s) and not getting all the battery backup installation correct ... and the first couple times they lost power, taking off all the telephones in westchester county.
misc. power backup related threads:
https://www.garlic.com/~lynn/99.html#145 Q: S/390 on PowerPC?
https://www.garlic.com/~lynn/aadsm2.htm#availability A different architecture? (was Re: certificate path
https://www.garlic.com/~lynn/2001.html#61 Where do the filesystem and RAID system belong?
https://www.garlic.com/~lynn/2001f.html#27 Design (Was Re: Server found behind drywall)
https://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
https://www.garlic.com/~lynn/2002g.html#62 ibm icecube -- return of watercooling?
https://www.garlic.com/~lynn/2003f.html#36 Super Anti War Computers
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Fast TCP Newsgroups: alt.computer.security Date: Sun, 22 Jun 2003 15:44:49 GMTtoro writes:
1) protocol setup chatter 2) pacing
lots of tcp apps have used a windowing algorithm as an indirect mechanism to control pacing. windowing basically is a facility for managing end-point buffer resources, it only indirectly controls pacing issues like packet transmit rate, packet arrival rate, inter-packet transmit interval, etc.
one of the most common implemented algorithms is slow-start ... which I believe was presented at '88 august ietf meeting, the same month that a acm sigcomm proceedings had paper showing that slow-start is non-stable in any sort of real-world environment.
one of the past discussions was that transmitting a slew of back-to-back packets can cause overrun at intermediate router boxes. In theory, (slow-start) windowing is to try and mitigate things like bursts of packet transmissions from a source. The problem found in the '88 sigcomm paper was that in real world situations, the return ACK packets can bunch up, with a batch arriving at the source all at once. In a windowing paradigm, receiving a batch of ACKs means that all the associated buffers are freed up for transmission in one burst, leading to potentially several back-to-back packets being transmitted very quickly. This can lead to congestion, lost packets, back-off and restarting the slow-start mechanism, gradually increasing number of outstanding packets until the next burst of batched ACKs appears and the cycle starts again. All of these protocol stuttering issues contribute to the effective delivered packet rate being less than the wire-speed.
rate-based pacing would explicitly measure approximate elapsed round-trip delay and then do something like methodically adjust the inter-packet transmission delay. This directly controls factors that can account for congestion and intermediate node overruns and is also insensitive to network operation peculiarities like ACK batching.
One of the comments regarding the use of windowing algorithm in the '80s instead of direct timer control was that possibly a large number of the 80s-era platforms lacked the timer facilities to implement things like inter-packet transmit delay.
there was a much longer discussion on the subject in comp.protocols.tcp-ip
misc. recent related threads:
https://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#45 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003h.html#7 Why did TCP become popular ?
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
https://www.garlic.com/~lynn/2003j.html#39 tunneling TCP/IP over UDP for high-latency links?
https://www.garlic.com/~lynn/2003j.html#40 tunneling TCP/IP over UDP for high-latency links?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Tao Of Backup: End of postings. Newsgroups: comp.security.misc,comp.unix.admin,comp.unix.misc Date: Sun, 22 Jun 2003 17:40:04 GMTross.ps@ross.net (Ross Williams) writes:
P privacy (and confidentiality)
A authentication
I sometimes Identification, sometimes Integrity
N non-repudiation
integrity aspect of security taxonomy includes availability and assurance.
people sporadically confuse authentication and identification as well as ignore various other aspects of security.
backups, recovery, business continuity, etc are very much a part of security taxonomy from integrity and availability standpoint.
merged security glossary
https://www.garlic.com/~lynn/index.html#glossary
sources:
https://www.garlic.com/~lynn/index.html#glosnote
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: June 23, 1969: IBM "unbundles" software Newsgroups: alt.folklore.computers Date: Thu, 26 Jun 2003 00:50:54 GMT"Russ Holsclaw" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Origin of "Function keys" question... Newsgroups: alt.folklore.computers Date: Fri, 27 Jun 2003 02:27:42 GMTproto@panix.com (Walter Bushell) writes:
my brother was an apple regional rep in the early '80s so I periodically got to have dinner with some of the people working on the mac (before it was announced) and argued that the restriction of only allowing it to be used on the kitchen table and never allowing it a mac to ever be bought for any business reason what so ever ... might not be the best way to ever earn a profit.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multics Concepts For the Contemporary Computing World - a CPU Newsgroups: alt.os.multics Date: Fri, 27 Jun 2003 02:53:33 GMTPeter Flass writes:
The original design point for 801 and ROMP was that a proprietary operating system had all security and priviledge checking at compile and load time .... so there was absolutely no priviledge checking needed at runtime. Inline application code could as easily swap segment register values as it could swap general register values (without having to resort to any kind of kernel call where priviledges were enforced).
801 used inverted tables and the total number of different possible addressable segments was 12bits or 4096 (w/o having to implement some invalidation process). This was exbanded to 24bits or 16million possible addressable segments .... although they had to be mapped into one of the 16 possible segment registers.
Porting UNIX to that environment created a problem since
1) addressing changes required priviledge validation by kernel calls and
2) there were starting to be some unix application environments that had multiple tens if not hundreds of memory objects simulateneously mapped in a single address space. The porting of those application environments to the ROMP/RIOS platforms required attempting to map some cluster/collection of simultaneously used memory mapped objects into a single shared library (which could in turn be mapped into the address space using a single segment register).
The issue in ROMP/RIOS with the limitation of sixteen segment registers was the paradigm translation of applications involving large numbers of individual memory mapped objects into paradigm with collections or libraries of memory mapped objects.
The proprietary operating system approach to application inline code to frequently and quickly change addressed objects wasn't possible (in the unix environment) and the approach of doing an extremly large number of kernel calls for something that had been anticipated to take a couple of instructions wasn't pratical.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Transactions for Industrial Strength Programming Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Fri, 27 Jun 2003 13:41:39 GMT"Bill Todd" writes:
another item that is sometimes considered is cluster recovery elapsed time (in face of failure); almost a kind of real-time constraint. larger transaction granularity tends to increase recovery time, while extremely fine-grain transaction increase the normal, straight-line processing time. processing power may be thrown at the straight-line case (finer granularity transaction) as part of a strategy to help bound the recovery time. of course, finer grained transaction (and locking) may increase parallelism and aggregate thruput. however, transaction consistency boundaries at least have to cover the scope of the operation being performed. A branch debit would be the individual account plus the aggregate branch balance. A intra-branch transfer would be the two individual accounts (but not affecting the branch net).
An overnight ACH batch settlement would have all the accounts that are hit plus the overall net for the batch. Locking all the acocunts is more efficient, doing the individual operations as transactions requires checkpointing position in the batch (and allows other operations to proceed in parallel). It is possible to do it as nested transaction. There is the exception processing involving the case of individual accounts having insufficient funds ... which means that all the operations can't be completed as listed for the ACH batch ... requiring exception processing sent back to the clearing house.
Various (typically overnight) financial settlement processes are sort of meta-transactions that have a slightly fuzzy nature since failures and exceptions can happen that aren't covered by the traditional data processing transaction capabilities.
since multiple locks tend to be required (somewhat implied by reference to preventing information inconsistency), there needs to be convention for lock ordering in attempt to avoid deadly embrace caused by concurrent transactions (say always lock the aggregate branch balance first and then accounts in numerical sequence). If nearly all transactions require the lock on the aggregate branch balance, then there is much lower opportunity for parallelism. So now you get the opportunity to try and define logical aggregate branch balance as some other construct.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Origin of "Function keys" question... Newsgroups: alt.folklore.computers Date: Fri, 27 Jun 2003 13:46:55 GMTRoland Hutchinson writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: public key confusion Newsgroups: sci.crypt Date: Fri, 27 Jun 2003 14:31:50 GMTtruman@rediffmail.com (aditya) writes:
public/private is a business process application of asymmetric key technology that sort of addresses the secret key distribution problem. the private key is consistently never divulged and the public key is consistently the only one ever distributed.
for secrecy, data is encrypted with the public key ... since only the non-divulged private key can ever decrypt the message.
encrypting something with the private key can establish authentication (but not normally secrecy). something that can be decrypted with a public key must have only come from the owner of the private key (which has never been divulged). since public/private key authentication isn't (normally) providing secrecy, it can be sufficient to encrypt (with the private key) a secure hash of the message (rather than the whole message).
note that not only are public/private keys a business process application of asymmetric key technology, but secrecy and authentication are addtional types of business processes.
then there is the confusion of key escrow. attempts are made to elevate authentication to the status of digital signature. a key that has never been divulged implies that "signed" messages can only have originated from the private key owner. key escrow makes duplicates of the private key, possibly compromising the strict constraint regarding the private key never being divulged.
business process secrecy constraints with regard to divulging the private key can be different than business process signature constraints; especially where data at rest has been encrypted and there are significant business continuity requirements (every thing is replicated for a minimum of no single point of failure).
since there can be different business process constraints with regard to divulging the private key, the result may be two sets of public/private keys; one set dedicated to secrecy use and one set dedicated to authentication use.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: June 23, 1969: IBM "unbundles" software Newsgroups: alt.folklore.computers Date: Fri, 27 Jun 2003 19:06:33 GMTJohn Ahlstrom writes:
aetna was the first "true blue" business customer to install an Amdahl in '76. same year that I got to be the guinea pig as the first charged for SCP software with the Resource Manager.
misc.
https://www.garlic.com/~lynn/subtopic.html#fairshare
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Origin of "Function keys" question... Newsgroups: alt.folklore.computers Date: Fri, 27 Jun 2003 18:53:10 GMTjchausler writes:
supposedly somebody bought it and installed it in a barn like building. i was told story that on days when it was cool enuf, they would open up the double barn doors on each end and turn on this gigantic fans ... and run it. something like 20,000 tubes.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Goodbye PROFS Newsgroups: alt.folklore.computers Date: Sat, 28 Jun 2003 14:08:16 GMTCharles Shannon Hendrix writes:
minor past profs &/or vmsg posts:
https://www.garlic.com/~lynn/99.html#35 why is there an "@" key?
https://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#56 E-mail 30 years old this autumn
https://www.garlic.com/~lynn/2002f.html#14 Mail system scalability (Was: Re: Itanium troubles)
https://www.garlic.com/~lynn/2002h.html#58 history of CMS
https://www.garlic.com/~lynn/2002h.html#59 history of CMS
https://www.garlic.com/~lynn/2002h.html#64 history of CMS
https://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#4 HONE, , misc
https://www.garlic.com/~lynn/2002p.html#34 VSE (Was: Re: Refusal to change was Re: LE and COBOL)
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
https://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
https://www.garlic.com/~lynn/2003e.html#69 Gartner Office Information Systems 6/2/89
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: OT: The dynamics of the Indian IT industry. Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 28 Jun 2003 14:43:22 GMTcomputerguy@ANTELECOM.NET (Dino Jr) writes:
one article i ran across (from HK?) several years ago was comparing the infrastructure pros & cons of india vis-a-vis Guangdong province with regard to factors for successful IT outsourcing. A major factor was comparing infrastructure bureaucracies and the difficulty and lead time in obtaining basic, dependable services (electricity, water, phones, telecommunications, etc) in support of IT outsourcing.
Frequently, analysis of the sucessess and failures of two similar endevors is more enlightening than a more straight-forward presentation.
quicky search engine attempt just now didn't turn up a whole lot.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: atomic memory-operation question Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 28 Jun 2003 22:08:13 GMT"Oliver S." writes:
1) description of how CAS could be used for uniprocessor environments as well as multiprocessor environments. That originated the whole stuff about how fully interrupt enabled, multi-threaded applications (regardless of whether they were running on uniprocessors or multiprocessors) would implement atomic operations.
2) CAS extended to CS (compare and swap) and CDS (compare double and swap).
... which was what went into the 370 machines.
somewhat as part of the recent expansion for 64bit support, the instructions have been expanded.
compare and swap instruction format
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.26?SHELF=DZ9ZBK01&DT=20020416112421
compare and swap double with detailed programming notes (for both compare
and swap and compare and swap double, including both 32bit versions and
the new 64bit versions):
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.27?SHELF=DZ9ZBK01&DT=20020416112421
additional information in instructure-use example appendix:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.26?SHELF=DZ9ZBK01&DT=20020416112421
multiprogramming and multiprocessing examples that is still somewhat
close to the original description that was asked to come up with
30 some odd years ago:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/A.6?SHELF=DZ9ZBK01&DT=20020416112421
the sub sections:
A.6.1 Example of a Program Failure Using OR Immediate
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/A.6?SHELF=DZ9ZBK01&DT=20020416112421
A.6.2 Conditional Swapping Instructions (CS, CDS)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/A.6.2?SHELF=DZ9ZBK01&DT=20020416112421
A.6.3 Bypassing Post and Wait
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/A.6.3?SHELF=DZ9ZBK01&DT=20020416112421
A.6.4 Lock/Unlock
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/A.6.4?SHELF=DZ9ZBK01&DT=20020416112421
A.6.5 Free-Pool Manipuation:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/A.6.5?SHELF=DZ9ZBK01&DT=20020416112421
and then there is the new Perform Locked Operation Instruction
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.95?SHELF=DZ9ZBK01&DT=20020416112421
A.6.6 perform locked operation instruction:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/A.6.6?SHELF=DZ9ZBK01&DT=20020416112421
random past compare&swap posts:
https://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
https://www.garlic.com/~lynn/93.html#14 S/360 addressing
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?
https://www.garlic.com/~lynn/2001f.html#41 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001f.html#61 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001f.html#70 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001f.html#73 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001f.html#74 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001f.html#76 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001g.html#4 Extended memory error recovery
https://www.garlic.com/~lynn/2001g.html#8 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001g.html#9 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
https://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
https://www.garlic.com/~lynn/2001k.html#65 SMP idea for the future
https://www.garlic.com/~lynn/2001k.html#67 SMP idea for the future
https://www.garlic.com/~lynn/2001n.html#42 Cache coherence [was Re: IBM POWER4 ...]
https://www.garlic.com/~lynn/2001n.html#43 IBM 1800
https://www.garlic.com/~lynn/2002.html#52 Microcode?
https://www.garlic.com/~lynn/2002b.html#28 First DESKTOP Unix Box?
https://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
https://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
https://www.garlic.com/~lynn/2002h.html#45 Future architecture [was Re: Future micro-architecture: ]
https://www.garlic.com/~lynn/2002l.html#58 Spin Loop?
https://www.garlic.com/~lynn/2002l.html#59 Spin Loop?
https://www.garlic.com/~lynn/2002l.html#69 The problem with installable operating systems
https://www.garlic.com/~lynn/2003.html#12 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2003.html#18 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2003b.html#20 Card Columns
https://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?
https://www.garlic.com/~lynn/2003c.html#78 The relational model and relational algebra - why did SQL become the industry standard?
https://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
https://www.garlic.com/~lynn/2003e.html#67 The Pentium 4 - RIP?
https://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
https://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
https://www.garlic.com/~lynn/2003g.html#30 One Processor is bad?
https://www.garlic.com/~lynn/2003h.html#5 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
https://www.garlic.com/~lynn/2003h.html#20 UT200 (CDC RJE) Software for TOPS-10?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Ted Nelson, of Project Xanadu Newsgroups: alt.folklore.computers Date: Sun, 29 Jun 2003 04:13:37 GMTLarry__Weiss writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Big Ideas, where are they now? Newsgroups: alt.folklore.computers Date: Sun, 29 Jun 2003 15:17:07 GMTLarry__Weiss writes:
when number of people using the internal network for communication started to greatly expand circa 1980 ... it was taken as a major phenomena. there were several studies initiated, including bringing in hiltz & turoff to do investigation.
a grad student doing thesis on computer mediated conferencing was paid to sit in the back of my office for nine months and take notes on all my communication. logs of all instant messages and all sent/received email was made available for analysis. report turned into stanford phd thesis joint between language department and computer ai; and later some books (knowledge machines, language and information in a technological society).
random refs:
https://www.garlic.com/~lynn/aepay10.htm#26 Definese Dept Criticised on Internal Credit Card Fraud
https://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
https://www.garlic.com/~lynn/2001j.html#29 Title Inflation
https://www.garlic.com/~lynn/2001k.html#64 Programming in School (was: Re: Common uses...)
https://www.garlic.com/~lynn/2002b.html#51 "Have to make your bones" mentality
https://www.garlic.com/~lynn/2002c.html#27 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002e.html#37 Would the value of knowledge and information be transferred or shared accurately across the different culture??????
https://www.garlic.com/~lynn/2002g.html#64 Pardon my ignorance,
https://www.garlic.com/~lynn/2002k.html#63 OT (sort-of) - Does it take math skills to do data processing ?
https://www.garlic.com/~lynn/2002l.html#54 10 choices that were critical to the Net's success
https://www.garlic.com/~lynn/2002p.html#3 IBM OS source code
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Micro$loth Update Mail-Bomb Newsgroups: alt.folklore.computers Date: Tue, 01 Jul 2003 05:26:08 GMT"Rupert Pigott" writes:
some specific references to system_r reunion site
https://www.garlic.com/~lynn/2003c.html#78 The relational model and relational algegra - why did SQL become the industry standard?
the system/r reunion site with lots of history:
http://www.mcjones.org/System_R/
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Dealing with complexity Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: Tue, 01 Jul 2003 14:32:57 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Dealing with complexity Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: Tue, 01 Jul 2003 14:34:54 GMTJan C. Vorbrüggen writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Transactions for Industrial Strength Programming Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Tue, 01 Jul 2003 14:27:34 GMTJan C. Vorbrüggen writes:
that is independent of industrial strength transaction processing systems and PDUs for rapid switching between grid/battery/diesel.
one place I visited told story that a couple yeara ago they had taken the top-of-the-line PDU, in use by most commercial datacenters and hired three engineering firms to redesign it ... and give the design back to the vendor. an ancillary claim was that within a year, there were a thousand of the new boxes deployed within the beltway.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Cost of Message Passing ? Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 01 Jul 2003 14:47:10 GMT"Rupert Pigott" writes:
i just ran across hardware announcement about targeting IPv6 on OC192
environments and doing 266million searches/second.
http://www.commsdesign.com/story/OEG20030630S0053
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Modular Exponentiations on Battery-run devices Newsgroups: sci.crypt Date: Tue, 01 Jul 2003 17:48:03 GMT"Andrew Swallow" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Dealing with complexity Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: Wed, 02 Jul 2003 00:46:17 GMTeugene@cse.ucsc.edu (Eugene Miya) writes:
there are also all the boyd stories about the f15, f16, etc ... trying
to get it right .... and then there is the air force air-to-air
missile when some really bright people miss a very simple point
... what is the hottest part of a jet? misc.
https://www.garlic.com/~lynn/subboyd.html#boyd
specific:
https://www.garlic.com/~lynn/99.html#120 atomic History
https://www.garlic.com/~lynn/2003j.html#13 A Dark Day
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Transactions for Industrial Strength Programming Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.arch,comp.lang.asm370 Date: Wed, 02 Jul 2003 11:10:28 GMTrobertwessel2@yahoo.com (Robert Wessel) writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multics Concepts For the Contemporary Computing World Newsgroups: alt.os.multics,comp.arch,alt.folklore.computers Date: Sat, 05 Jul 2003 14:02:47 GMTjmfbahciv writes:
sjr's 195 also ran some amount of air bearing simulation for disk
floating head technology (again weeks long queue). when we bullet proofed
input/output supervisor for the disk engineering (bldg 14) and disk
product product test lab (bldg 15)
https://www.garlic.com/~lynn/subtopic.html#disk
a lot of the disk test cell testing got converted from stand alone testing to running in operating system environment and so could do half dozen or dozen test cell twork going on simultaneously (instead of one at a time dedicated time). the other benefit was that even with multiple test cell load ... the cpu load was rarely more than a couple percent ... so in addition to improving test cell work by several hundred percent ... it opened up significant cpu processing to disk engineering.
The product test lab's 3033 had about the same cpu thruput as sjr's 195 for most workloads .... 195 really took off when you could get instruction loops within 63 instructions. opening up several of the processors required for dedicated disk I/O testing to selected CPU intensive use, significantly aided things like the air bearing work for floating disk heads.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multics Concepts For the Contemporary Computing World Newsgroups: alt.os.multics,comp.arch,alt.folklore.computers Date: Sun, 06 Jul 2003 13:52:26 GMTPeter Flass writes:
misc. page, kernel, pathlength, resource manager, fair share
scheduling, etc:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
misc. past discussions of kernel paging:
https://www.garlic.com/~lynn/94.html#4 Schedulers
https://www.garlic.com/~lynn/97.html#23 Kernel swapping itself out ?
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
https://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
https://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002k.html#13 Difference between Unix and Linux?
https://www.garlic.com/~lynn/2002q.html#54 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2003e.html#12 Resolved: There Are No Programs With >32 Bits of Text
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multics Concepts For the Contemporary Computing World Newsgroups: alt.folklore.computers Date: Sun, 06 Jul 2003 14:34:09 GMTjmfbahciv writes:
As long as the CPU with I/O doesn't saturate handling I/O request ... it is possible to show significant CPU thruput because of various cache residency effects. actually was able to demonstrate the difference with a two processor 370/158 ... for a heavily loaded interactive time-sharing environment. running one processor with all the I/O had 20-30 percent higher thruput because of improved cache hit effects with no noticable loss in i/o thruput (and majority of all I/O requests had to be queued in any case).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Microkernels are not "all or nothing". Re: Multics Concepts For the Contemporary Computing World Newsgroups: alt.os.multics,comp.arch,alt.folklore.computers Date: Mon, 07 Jul 2003 20:31:02 GMT"Russell Williams" writes:
misc. past threads regarding nextstep and mach:
https://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
https://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
https://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001k.html#19 HP Compaq merger, here we go again.
https://www.garlic.com/~lynn/2001n.html#35 cc SMP
https://www.garlic.com/~lynn/2002i.html#73 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2003.html#46 Horror stories: high system call overhead
https://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
https://www.garlic.com/~lynn/2003c.html#32 Early attempts at console humor?
https://www.garlic.com/~lynn/2003c.html#45 Early attempts at console humor?
https://www.garlic.com/~lynn/2003e.html#25 A Speculative question
https://www.garlic.com/~lynn/2003e.html#33 A Speculative question
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 1950s AT&T/IBM lack of collaboration? Newsgroups: comp.dcom.telecom.tech,alt.folklore.computers Date: Wed, 09 Jul 2003 03:02:30 GMTFloyd Davidson writes:
a similar thread is about the OSI design point (and not to single it
out, SNA reflected very similar basic design point) ... which was low
bandwidth, high error rate, low technology, point-to-point copper.
some past comments including references to osi
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
trying to convince somebody that you wanted to do T3 tdma satellite system with dynamic asymmetric bandwidth re-allocation on superframe, reed-solomon giving 10 to the minus 15 effective bit error rate, and end-to-end encryption was a challenge since the data communication protocols of the period. It turns out to look almost like some brand new OC1 corporate ATM fiber networks .... and the infrastructure is still doing static, symmetic link bandwidth allocation (static point to point virtual links with the same bandwidth in both directions).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 1950s AT&T/IBM lack of collaboration? Newsgroups: comp.dcom.telecom.tech,alt.folklore.computers Date: Wed, 09 Jul 2003 02:44:13 GMThancock4@bbs.cpcn.com (Jeff nor Lisa) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 1950s AT&T/IBM lack of collaboration? Newsgroups: comp.dcom.telecom.tech,alt.folklore.computers Date: Thu, 10 Jul 2003 19:38:04 GMTFloyd Davidson writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 1950s AT&T/IBM lack of collaboration? Newsgroups: comp.dcom.telecom.tech,alt.folklore.computers Date: Thu, 10 Jul 2003 20:08:39 GMTDave Nevers writes:
the big ten meter dishes were c-band with earlier generation of
birds. we did data only tdma on sbs-4 that was Ku-band as part of
high-speed data transport:
https://www.garlic.com/~lynn/subnetwork.html#hsdt
the hsdt earth stations were highly optimized for dynamic asymmetric
bandwidth allocation on superframe boundaries for typical bursty
traffic found in large backbone infrastructures. this caused a lot of
consternation in the SNA crowd, because it didn't even remotely relate
to how any of the SNA products operated. The dishes in northern US
were 4.5meter (lot smaller than the 10meter, but still good size).
it also caused some of the internal political difficulties that stood
in the way for us doing the original NSFNET 1&2 backbones:
https://www.garlic.com/~lynn/internet.htm
hsdt which also included various terrestrial links (both fiber and traditional T1 telco).
SBS telco/voice went to MCI (the sbs voice customer base) but the birds went to hughes (early directtv stuff). joke in the last days of SBS was that some of the people that came over from IBM, had re-created the 14-level management structure (for the approx. 480k IBM employees) in SBS organization with approx. 2-3k employees (aka something like half the employees were supposedly executives of one sort or another).
we were later told by the subcontractor that built to spec. the highly optimized data earthstation implementation ... that they were approached by AT&T to build identical set of earthstations.
we also got called in the early days after the ROLM acquisition to look at applying some of the HSDT work to ROLM products.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm