List of Archived Posts

2003 Newsgroup Postings (06/07 - 07/10)

IBM 5100
FAST - Shame On You Caltech!!!
Fix the shuttle or fly it unmanned
A few Z990 Gee-Wiz stats
A Dark Day
A Dark Day
A Dark Day
A few Z990 Gee-Wiz stats
A Dark Day
Whatever happened to 'University Computer Centers'?
20th anv. of 1000th node on internal network
Idiot drivers
A Dark Day
A Dark Day
A Dark Day
A Dark Day
A Dark Day
pbx security from 20 years ago
why doesn't processor reordering instructions affect most
tcp time out for idle sessions
A Dark Day
Qwerty vs Dvorak
why doesn't processor reordering instructions affect most
A Dark Day
Red Phosphor Terminal?
Idea for secure login
A Dark Day
A Dark Day
Offshore IT
IBM 3725 Comms. controller - Worth saving?
How is a smartcard created?
A Dark Day
Language semantics wrt exploits
A Dark Day
Interrupt in an IBM mainframe
why doesn't processor reordering instructions affect most
CC vs. NIST/TCSEC - Which do you prefer?
Overflows
Virtual Cleaning Cartridge
tunneling TCP/IP over UDP for high-latency links?
tunneling TCP/IP over UDP for high-latency links?
Of what use 64-bit "General Purpose" registers?
Flash 10208
An a.f.c bibliography?
Hand cranking telephones
Hand cranking telephones
Fast TCP
The Tao Of Backup: End of postings
June 23, 1969: IBM "unbundles" software
Origin of "Function keys" question
Multics Concepts For the Contemporary Computing World - a CPU
Transactions for Industrial Strength Programming
Origin of "Function keys" question
public key confusion
June 23, 1969: IBM "unbundles" software
Origin of "Function keys" question
Goodbye PROFS
OT: The dynamics of the Indian IT industry
atomic memory-operation question
Ted Nelson, of Project Xanadu
Big Ideas, where are they now?
Micro$loth Update Mail-Bomb
Dealing with complexity
Dealing with complexity
Transactions for Industrial Strength Programming
Cost of Message Passing ?
Modular Exponentiations on Battery-run devices
Dealing with complexity
Transactions for Industrial Strength Programming
Multics Concepts For the Contemporary Computing World
Multics Concepts For the Contemporary Computing World
Multics Concepts For the Contemporary Computing World
Microkernels are not "all or nothing". Re: Multics Concepts For
1950s AT&T/IBM lack of collaboration?
1950s AT&T/IBM lack of collaboration?
1950s AT&T/IBM lack of collaboration?
1950s AT&T/IBM lack of collaboration?

IBM 5100

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 5100
Newsgroups: alt.folklore.computers
Date: Sun, 08 Jun 2003 00:56:31 GMT
Charles Richmond writes:
I am not familiar with the "scamp" processor for IBM. Where was that used???

there were gobs of processors and chips ... i don't place scamp ... but quick use of search engine produces a bunch of time-lines listing scamp as possibly first personal computer (URLs in previous post provided more detail):
http://www.islandnet.com/~kpolsson/comphist/comp1969.htm
http://other.cerrocoso.edu/studenthelp/computime/1947.htm
http://www.c2ctravel.net/desktop.htm
http://www.sagegis1.com/history4.htm
http://www.chass.utoronto.ca/~bhall/hps282f/LECTURE%2024%20Computers.htm

different (nat semi) scamp:
http://www3.sk.sympatico.ca/jbayko/cpu2.html

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

FAST - Shame On You Caltech!!!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
unoriginal_username@yahoo.com (Le Chaud Lapin) writes:
Frankly, I am appalled that an institution with so much prestige as Caltech would engage in this type of marketing sensationalism. I just hope that certain grant-administering people over at DARPA and NSF in Washington stop falling for this type of non-sense.

-Chaud Lapin-

References:

http://pr.caltech.edu/media/Press_Releases/PR12356.html
http://news.nationalgeographic.com/news/2003/03/0318_030318_internet.html
http://www.jservice.com/News/DettaglioWeb.asp?ID=75
http://www.pasadenastarnews.com/Stories/0,1413,206%257E22097%257E1369821,00.html
http://www.darpa.mil
http://www.nsf.gov


HSP (high-speed-protocol) did rate-based pacing (both congestion control and latency compensation). I think there were some tests with streaming video in the early '90s.

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?).
http://www.garlic.com/~lynn/subnetwork.html#hsdt

slightly related thread in this n.g. in april:
http://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#45 Rewrite TCP/IP
http://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):
http://www.garlic.com/~lynn/2003i.html#76 Columbia U Computing History - New stuff
http://www.garlic.com/~lynn/internet.htm#22 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)

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

Fix the shuttle or fly it unmanned

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Brian Inglis writes:
4381 could probably keep 1-2 on dedicated channels going flat out per CPU, limited by the I/O interface, OS and applications software.

>>Yes, it would be interesting to see how much bandwitdh a
>>43xx would be able to push into a network doing CICS transactions
>>with 3270 forms.

Would be severly limited by the terminal lines and controllers as well as CICS. I've not seen much in IBM communications that would saturate decent bandwidths. TPF output? HIPPI maybe?

>I doubt it would be better in overall bandwidth, but
>I would not be at all surprised if the response times
>were better.

CICS was barely tolerable on local channel attached terminals, it was abominable on anything remote, godawful disgusting on multidrop lines. Non-local IBM terminal communications are synchronous at many levels.


at about the time there was work going on to try and reduce the number of buffer copies below five and 5k instructions pathlength in a tcp transaction on typical unix platform ... somebody noted that it was over 100k instructions and 14 buffer copies in an equivalent vtam operation ... SNA is not a system, is not a network, is not an architecture .... it was a communication infrastructure for supporting huge numbers of terminals hung off a mainframe (infrastructures that might have in excess of 100k terminals). minor ref:
http://www.garlic.com/~lynn/2002.html#28 Buffer overflow

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 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:
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001m.html#53 TSS/360
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?

somes past posts related to experience with redoing a major TPF application:
http://www.garlic.com/~lynn/96.html#31 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#153 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#61 64 bit X86 ugliness (Re: Williamette trace cache (Re: First view of Willamette))
http://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
http://www.garlic.com/~lynn/2001k.html#26 microsoft going poof [was: HP Compaq merger, here we go again.]
http://www.garlic.com/~lynn/2002i.html#40 CDC6600 - just how powerful a machine was it?

slightly tcp/ip related recent ref:
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!

high speed data transport:
http://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:
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was System/1 ?)

misc. past refs to having done rfc 1044 support:
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/96.html#14 mainframe tcp/ip
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#52 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
http://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003c.html#28 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#35 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#37 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#59 unix
http://www.garlic.com/~lynn/2003i.html#43 A Dark Day

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

A few Z990 Gee-Wiz stats

Refed: **, - **, - **
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 GMT
Robert Myers writes:
The whole thing sounds little different from maitaining processor cache-coherency, except that you have to go through an I/O channel and live with a much larger latency to do it. Not only that, you have to do it all over again for all the oddities of each vendor's hardware. Has the look of a swamp full of alligators to me.

Oracle seems to have decided to front the hardware vendors now in more ways than one. First providing RedHat support, now providing the distributed-cache functionality (not, one imagines, that the pressue on them to do so in the latter case hasn't been enormous). How long before they start selling boxes?


the problem is that guaranteed commits have occured in journaled logs along the way ... with the logs being node specific ... and interdependencies with other data consistency that may have occured at some node. the issue isn't one of keeping consistency for normal operation ... the problem is if one or more or all of the nodes hiccup (all loose power) .... and you have to invoke recovery from the logs ... and get the distributed logs globally re-integrated according to the original global event sequence.

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 occuring 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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

A Dark Day

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
peter@taronga.com (Peter da Silva) writes:
I don't think that the instruction set and the file formats are related nearly so closely as that. After all, RSX on the PDP-11 used counted records in files, while UNIX used terminated records. They were both running on the same hardware.

and multics (implemented in PLI) and 360 generation had little or no buffer overflow exploits (aka the claim is that implicit length conventions and implementation reflected in C libraries and things implemented in C is the major contributor to buffer overflow vulnerabilities in the world today). in fact the 1974 air force study has claimed no buffer ovreflow exploits for multics. multics on ge (later honeywell) and single level store had very different operating system and hardware architecture from 360 genre.

references to study:
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://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):
http://www.garlic.com/~lynn/subintegrity.html#fraud

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

A Dark Day

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 GMT
Charles Richmond writes:
One thing that our college's IBM/370-155 lacked in 1978, was an instruction to convert an integer to a floating point number. To do this required a small subroutine...

but 360/370 did have CVB (convert to binary) and CVD (convert to decimal) instructions ... somewhat more oriented towards commercial market(? ... as well as all the straight packed decimal operations).
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.38?SHELF=DZ9ZBK01&DT=20020416112421
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.39?SHELF=DZ9ZBK01&DT=20020416112421

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

A Dark Day

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 GMT
oops, and the convert from/to fixed instruction detailed hardware descriptions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/18.2.4?SHELF=DZ9ZBK01&DT=20020416112421
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/18.2.5?SHELF=DZ9ZBK01&DT=20020416112421

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

A few Z990 Gee-Wiz stats

Refed: **, - **, - **, - **, - **, - **, - **
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 GMT
Robert Myers writes:
Thanks to both of you for the time you have put into tutoring me. With any luck, I am not the only one is benefitting from having just the right people available when you have a naive question to ask. :-).

Everything, of course, hinges on making sure that, if nothing else, the log files get written correctly. It seems like such a high-priority task that I'd be tempted to cache the disk doing the logging with some kind of non-ephemeral memory.

Without such a step, it seems like confirming transactions without an actual write to the physical log disk would be dangerous. I suppose the chances of a log write not completing before a remote system has a chance to act on information that is still in an ephemeral state are small, but it doesn't sound impossible.


the original discussion was specifically with respect to fast commit where the log has been written ... but the actual data record hasn't been written back to its original home location ... in fact, multiple commits involving different (generations of) record values to go unwritten to home location.

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:
http://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003i.html#72 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003j.html#3 A few Z990 Gee-Wiz stats

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

A Dark Day

Refed: **, - **, - **, - **, - **
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 GMT
Peter Flass writes:
Yes, but there are languages that encourage bad programming and languages that discourage it. It is possible to write PL/I code to cause buffer overflows, but you really have to work at it. In C, you have to work at least as hard to avoid them. That's not just my thinking, the Multics retrospective paper published last year says this flat out.

somewhat cross related to buffer exploits and cybersecurity:
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Whatever happened to 'University Computer Centers'?

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 GMT
Joe Morris writes:
As I noted in the earlier posting, telco equipment is a traditional user of 48VDC, and many telco installations have a completely separate rectifier/battery frame that could be replaced by a feed from a common battery vault. I've still got a problem with feeding 48V across a server farm room, both because you'll probably need to be providing $LINEVOLTAGE in any case, and because of the need for larger wires.

at least in the mid-90s, there were issues of ISP co-hosting in telco facilities needing 48v ... routers, servers, etc. when we were deploying the original payment gateway (aka for what has become electronic commerce) ... we spec'ed diverse routing & telco provisioning and one of the ISPs was co-hosted at a MCI facility that was 48v. misc. electronic commerce trivia:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

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

20th anv. of 1000th node on internal network

Refed: **, - **, - **
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 GMT
as per some of of my recent posting in various newsgroups, today is the 20th anv. of the 1000th node on the internal network.
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/internet.htm#22 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2003i.html#27 instant messaging
http://www.garlic.com/~lynn/2003i.html#32 A Dark Day
http://www.garlic.com/~lynn/2003i.html#76 Columbia U Computing History - New stuff
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!

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

Idiot drivers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Idiot drivers
Newsgroups: alt.folklore.computers
Date: Tue, 10 Jun 2003 18:18:20 GMT
jmfbahciv writes:
It took a Republican governor to honor (partly) that promise about the Mass Pike. Although I do prefer to drive on a toll road (usually maintained better). It is stupid to insist on collecting tolls while driving on the road (that's the pieces that the governor got rid of).

the first time i drove on the mass pike it was cross country trip from the west coast to the east coast in the winter. there was a section that was quite rough, potholes and speed limit reduced to something like 45mph. I commented that on the trip I had driven on some Idaho county road in the rockies that was better quality than the mass pike ... and didn't the speed limit of 45mph disqualify it as an interstate (and eligible for federal fundings). In fact, it was the worst stretch of road (interstate or otherwise) that i had encountered on the whole trip.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

A Dark Day

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Dark Day...
Newsgroups: alt.folklore.computers
Date: Tue, 10 Jun 2003 23:27:54 GMT
ararghNOSPAM writes:
I had enough debugging with dumps (12 inch high stack of paper) way back in the 70's. And this was on a dinky little 360/65 with only a meg of memory. Can you even Imagine how many cases of paper, how many ribbons, how long it would take to print a core dump on even a small PC (my smallest has 64 meg) ? Assumming you could even find a printer that wouldn't flake out before finishing.

couple minutes ago got an email from sysprog at an installation with new production z/vm system, 9gbytes of real memory and observing some paging issues that somehow involves a 800mb virtual machine with 64k resident (4kbyte) virtual pages ... @1kpages/4meg ... that is 256mbytes. some other details possibly makes it sound like a bug i might of found and fixed 30 years agao.

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

A Dark Day

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 GMT
Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
Suppose you're flying a fighter jet. You hit a button to fire a missile. Because of some unanticipated problem, an integer overflow happens. Would you rather allow the system to proceed with the undefined results, and do god only knows what? Or would you prefer to have an exception handler that decides "I don't know why that happened, but I'd better do something sensible that will keep the error from propagating and potentially screwing up the entire avionics system"? Note that this is different from your proposed "restart the processing from scratch", which would be literally disastrous.

suppose there is this little unpleasantness that has been going on for some time. it includes some amount of air battles with jets. everytime your people fire a missile it misses (well not quite every time, but almost ... and it misses much more than the opponents missile miss). some number of your jets are shot down and people are lost.

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 seaking. they were asked what kind of heat seaking, they answer pin point. they were asked what is the hottest part of a jet. somebody then decides to terminate the review.
http://www.garlic.com/~lynn/99.html#120 atomic History

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

A Dark Day

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
Copies of VM/370, source and object, are around. Maybe that isn't so different from CP/67, and easier to find machines it will run on.

the port of cp/67 to vm/370 involved moderate amount of rewrite. the changes for the port of cms (cambridge monitor system) to cms (conversational monitor system) (for 370) were significantly less (in many cases none).

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:
http://www.leeandmelindavarian.com/Melinda/

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:
http://www.garlic.com/~lynn/2001b.html#76 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001h.html#57 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2003i.html#13 A Dark Day

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

A Dark Day

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Depending on testing and validation to fix all problems is no good. It is provably impossible - you HAVE to allow for failures in the field. At least if you care about reliability.

i've been claiming that the amount of code for a service, industrial strength application is 4-10 times larger than the straightline application code ... using most of current programming technologies. some environments do somewhat better job ... but some number of failure/faults are domain specific.

for the originaly 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 everytime.

misc. past threads with business/industrial strength data processing:
http://www.garlic.com/~lynn/94.html#44 bloat
http://www.garlic.com/~lynn/98.html#4 VSE or MVS
http://www.garlic.com/~lynn/aadsm2.htm#architecture A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aepay6.htm#erictalk2 Announce: Eric Hughes giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm11.htm#33 ALARMED ... Only Mostly Dead ... RIP PKI
http://www.garlic.com/~lynn/aadsmail.htm#parsim parsimonious
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001h.html#1 Alpha: an invitation to communicate
http://www.garlic.com/~lynn/2001l.html#4 mainframe question
http://www.garlic.com/~lynn/2001l.html#14 mainframe question
http://www.garlic.com/~lynn/2001n.html#90 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002.html#26 Buffer overflow
http://www.garlic.com/~lynn/2002.html#28 Buffer overflow
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002.html#38 Buffer overflow
http://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
http://www.garlic.com/~lynn/2003e.html#11 PDP10 and RISC
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

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

A Dark Day

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 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
It is almost a forgotten skill nowadays, but you also have to design it so that bugs and other problems that occur in the field can be located and dealt with.

i did a dump reader in rex(x) as a replacement for the official one ... and for a time it was used extensively by internal sites (people at internal datacenters, and a large proportion of the vm PSRs ... guys who handle failure reports submitted from customers).
http://www.garlic.com/~lynn/submain.html#dumprx
one of the things was an evolving library of routines that (automagically) picked around in the dump, attempting to identify failure characteristics. it gave me a somewhat different perspective when i was writing/developing my own code. since i was also distributing a highly modified kernel to a large number of internal datacenters for production operation, i had some experience getting called in and having to shoot failures. minior ref .... hone production system supporting all sales, marketing, and field people world-wide:
http://www.garlic.com/~lynn/subtopic.html#hone
and a place that tended to particularly stress the i/o subsystem, the disk engineering lab:
http://www.garlic.com/~lynn/subtopic.html#disk

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

pbx security from 20 years ago

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 GMT
pbx'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:
http://www.garlic.com/~lynn/aadsm12.htm#4 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
http://www.garlic.com/~lynn/2003i.html#62 Wireless security

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

why doesn't processor reordering instructions affect most

Refed: **, - **, - **, - **, - **
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 GMT
Brannon_Batson@yahoo.com (Brannon Batson) writes:
OoO execution existed well before MIPS did it. The CDC 6600 and the IBM S/360 architectures were doing dynamic scheduling with out of order execution in the 1960s long before MIPS was a glimmer in Hennessy's eye.

tomasulo dynamic scheduling for 360/91
http://www.cs.bu.edu/faculty/best/crs/cs550/yueh/tomasulo.html
http://www-csd.ijs.si/courses/processor/Chapter3/tsld030.htm
http://www.icsa.informatics.ed.ac.uk/research/groups/hase/projects/tomasulo/
http://www.csee.umbc.edu/~plusquel/611/slides/chap4_4.html
http://www.wired.com/news/technology/0,1282,6179,00.html
http://www.kroening.com/diplom/diplom/main002.html

thornton 6600 & tomasulo 360/91
http://www.cs.swan.ac.uk/~csneal/HPM/tomasulo.html

somewhat related
http://people.cs.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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

tcp time out for idle sessions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Rick Jones writes:
No, I would say that you are right. Keepalives are best done by the application. The application best knows its requirements.

there was this joke about trying to get a JES2 connection from STL (west coast) to Hursley (UK) over double hop (geo-sync) satellite connection; 422k miles over plus 422k back for 176k miles total ... it never could establish the connection because of the jes2 keep-alive time-outs. They then tried vnet and it worked perfectly. the conclusion (by the executive in STL responsible for jes2) was that the link actually wasn't working, and it was the inadequate error recovery in vnet that wasn't recognizing the problems (not withstanding the traffic vnet was transferring all checked out as valid .... possibly it was some quantum effect that was making the vnet bits come out correct even tho the link supposedly wasn't operational?). it also helped to have rate-based pacing to maximize thruput on the link.

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

A Dark Day

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Dark Day...
Newsgroups: alt.folklore.computers
Date: Fri, 13 Jun 2003 22:08:07 GMT
Alex Colvin writes:
And there are languages that encourage programming and languages that discourage it. You're not likely to see buffer overflows (subscriptrange) in PL/I because buffers are a pain in PL/I. You don't see string overruns because you tend to deal in fixed-length strings. You might as well say that Fortran prevents memory leaks.

PLI varying strings had header that gave maximum & current length the library code appropriately used the length fields.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Qwerty vs Dvorak

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Qwerty vs Dvorak
Newsgroups: alt.folklore.computers
Date: Fri, 13 Jun 2003 23:07:10 GMT
Michael Wojcik writes:
OTOH, 1964 EBCDIC did include the cent mark - see the message I just posted responding to John Savard regarding my beloved square brackets.

Come to think of it, it's a little odd old typewriters had the cent mark. It ought to be easy enough to produce a reasonable cent-symbol on a typical mechanical typewriter by overtyping a c with a colon or some such. If you wanted a pretty cent symbol for something, do a half-reverse-feed first, so it'd be vertically centered on the line. ISTR having to overtype for various symbols back in the day, though now I can't recall what I typically needed to type that way. Hmm... accented letters for foreign words would be one example. Had to type a couple of papers for Spanish class, and the choices were overtype diacriticals or write them in by hand.


ibm typewriters and the ibm 2741 had the cent sign. 2741 had lower case "at" sign and upper case "cent" sign above the right pinky (next to letter "P") CP/67 & CMS editing mapped the "at" sign to character delete (aka lower case) and the "cent" sign (upper case) to line delete.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

why doesn't processor reordering instructions affect most

Refed: **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Michael Koenig writes:
Right - I stand corrected. Can we agree on MIPS R10000 being the first microprocessor with dynamic scheduling since S/360 is a mainframe and CDC 660 is a super-computer?

the following pegs mips 10k at 1996
http://www.cs.clemson.edu/~mark/architects.html
note the above has summary description of range of mainframes, supers, super-minis, workstations, etc. also for a number of other refs, start with
http://www.cs.clemson.edu/~mark/

our manager in engineering when my wife and I were doing ha/cmp
http://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)
http://people.cs.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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

A Dark Day

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Dark Day...
Newsgroups: alt.folklore.computers
Date: Sat, 14 Jun 2003 03:25:01 GMT
Michael Wojcik writes:
It'd be true for COBOL, too, if any of the various free COBOL compiler projects were up to snuff (I understand from the folks on comp.lang.cobol that they aren't, quite) and were more widely ported. (A few features, like ALTER, have been deprecated by newer COBOL standards, but most 20-year-old code still seems to compile and run on today's compilers.)

although instead of 20 years ... it may be getting closer to 40 years. when i was an undergraduate ... there was a 360 cobol program that had been brought over from 709 cobol .... which was a cobol program that emulated the 407 plug-board operation ... and at the run, it printed out the 407 switch settings. one day there was a value printed that hadn't been seen before .... after some consultation ... it was decided to run the program again to see if the values came out the same.

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

Red Phosphor Terminal?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Red Phosphor Terminal?
Newsgroups: alt.folklore.computers
Date: Sat, 14 Jun 2003 15:46:42 GMT
Brian Inglis writes:
IBM 3290 plasma display terminal. IIRC it required a special DFT/HFT 3274 coax adapter and microcode load. ISTR it occupied 4 terminal positions but required 5 addresses in the controller for some reason. It could show 4 different terminal sessions on the screen at once, and you could hardware zoom each to use the full screen, and perhaps also reduce the character size so you could look at a full 132x66 printer page. May also have supported some kind of mono graphics: maybe that's what the fifth terminal address was for?

Had one on our VM system, used for multiple VSE system consoles, perhaps via PVM, as well as a VM operator terminal, which could also be used via PVM for occasional CICS console stuff on any of the VSE machines.


and if you had howard's parasite & story:
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#36 Newbie TOPS-10 7.03 question

you could write automated terminal scripts (and do screen scraping) ... well before IBM/PCs and HLLAPI.

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

Idea for secure login

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Idea for secure login
Newsgroups: sci.crypt
Date: Sat, 14 Jun 2003 18:47:28 GMT
paul@westpoint.ltd.uk (Paul Johnston) writes:
I just wondered if this login scheme had been considered before and what the verdict was.

I have already used a challange hash authentication protocol for web logins. The client and server have the password as a shared-secret. This works ok, but the password has to be securely exchanged in the first place.

But, you can use the non-reversible property of secure hashes to avoid the need to exchange a password. When creating the account, the client sends the server:

md5(hmac_md5(password, random))

Now, to login the client sends:

hmac_md5(password, random), md5(hmac_md5(password, random2))

The first part proves the client knows the password - an eavesdropper can't reverse the md5 and calculate this. However, they could now perform a replay attack, so the second part sets a new login secret.

I realise this scheme fails completely if the attacker is not just a malicious eavesdropper, but can modify packets in transit, etc. That is not a problem to be because I am implementing this with JavaScript that is downloaded insecurely, so I can never get around an active attacker.

Does it work?


basically, when creating the account ... you have to have a secure path anyway .... the issue is NOT just that the person can proove they have the correct secret ... but ALSO that the correct secret is bound to the account being created from the appropriate person .... aka vulnerability is something like a man-in-the-middle attack.

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
http://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:
http://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
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#26 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#31 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#34 virus attack on banks (was attack on paypal)
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aepay11.htm#22 FBI Probing Theft of 8 Million Credit Card Numbers
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aepay11.htm#49 A More Anonymous Internet
http://www.garlic.com/~lynn/aepay11.htm#50 Concern Grows About ID Theft
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
http://www.garlic.com/~lynn/2003e.html#57 Security in RADIUS (RFC2865)
http://www.garlic.com/~lynn/2003h.html#55 PKINIT
http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#2 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation

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

A Dark Day

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:
The same thing can be said for a COBOL MOVE into a field with editing characters - or an IBM 360 assembly language program using the ED instruction, for that matter. What makes an interpreter is not the complexity of individual operations, but the fact that it interprets either the original source code or some minimally processed version. If it turns the source code into executable machine code that must be run later on its own, it's a compiler, not an interpreter.

watfor was barely a compiler ... it got its superfast compiler speed by not doing a whole lot more than turning each program statement into a call to a specific routine responsible for executing the statement.

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

A Dark Day

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Dark Day...
Newsgroups: alt.folklore.computers
Date: Sat, 14 Jun 2003 19:32:48 GMT
Charles Shannon Hendrix writes:
How many systems bother doing this these days?

I never assume the memory I ask for is clean.

If I want that, I code a routine to handle it myself.


the first version of CP/67 that i got had a concept of a zeros page. the first time a virtual machine touched a virtual page it was paged in from a specially formated page on the ipl volume. I changed the code to do a STM loop to clear the real storage location before letting it be given over as a virtual page (using most of the registers temporarily cleared to zeros).
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.3.39?DT=19970613131822
There was possibility of using overlapping MVC instruction, but it also required a loop for 4096 bytes ... and it was a byte at a time and significantly slower.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Offshore IT

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Offshore IT
Newsgroups: alt.folklore.computers
Date: Sat, 14 Jun 2003 20:54:30 GMT
jmfbahciv writes:
An "educator" was quoted yesterday saying that those who drop out of school to avoid the MCAS won't get a feeling of accomplishment; they need a high school diploma before they can get a good feeling. This is the f**king attitude that has to change, IMO, of course. If a kid hasn't had one feeling of complishment by the time s/he's 18, there is a serious problem with rearing kids. I bet most of them got a feeling of accomplishment on their playstations.

2003/6/14, california cancels exit exam
http://www.bayarea.com/mld/mercurynews/living/education/6088015.htm

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

IBM 3725 Comms. controller - Worth saving?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Rob Storey writes:
I was recently made aware of an IBM 3725 communications controller sitting in a bargain/junk warehouse. I wnt to look at it, and offered AU$50 (about US$33) for it, but they wanted more like $200. I may still buy it, but it's largish (size of two fridges), and I don't really have anywhere to keep it at the moment. So I'm wondering:-

Are these things getting rare? Is it worth preserving something like this? Any speculations on what it might be worth.


some comparison of 3725 and series/1 based emulator:
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/94.html#33a High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)

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
http://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:
http://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)

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

How is a smartcard created?

Refed: **, - **, - **, - **, - **, - **
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 work for a rather large Credit Card processor. Recently in the embossing area, we received some cards that had been requested as 'test' plastics. For some unknown reason, the supplier decided that we just wanted to look at the things, and so provided us with standard mag stripe cards, with a white circle and the text 'Attach IC here' where the chip should have been!! Hmmm ... clever! ;o)

as part of assurance for the aads strawman chip
http://www.garlic.com/~lynn/x959.html#aads

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

A Dark Day

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 GMT
Dowe Keller writes:
Exactly, it as if everyone started using hatchets for pounding nails. You wouldn't blame the hatchet manufacturer because you inadvertently cut your thumb off.

truely random drift, there is a roofing tool that is hachet on one side for shingles and hammer on the other side for nails.

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

Language semantics wrt exploits

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Language semantics wrt exploits
Newsgroups: comp.arch
Date: Mon, 16 Jun 2003 02:03:05 GMT
bhurt@spnz.org (Brian Hurt) writes:
If virtual memory space is sufficient larger (~3x) then real memory space, welcome to swapping hell, but the GC will eventually recover (once it's finished moving that huge object). If you're talking about allocating a single object that is over 50% of your virtual memory size, you're likely to have other problems. Note that this is assuming that the copying collector wants to allocate a whole second copy of your 0.6memory object- requiring 1.2memory to do so. A reasonably safe assumption.

when apl\360 was first ported to cms (at the cambridge science center) there was a big problem with apl's memory allocation and garbage collection. we had a trace facility ... that eventually was released as vs/repack ... that we could plot memory references; print this out on the backside of green-bar paper ... and paper the halls of 4th floor walls with; 6foot strips ... on the wall ... taped together ... memory address was veritical ... and instructions executed (time) was horizontal ... as it program marched down the hall.

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 occured 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 virtaul 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:
http://www.garlic.com/~lynn/subtopic.html#hone
misc. past cambridge (4th floor, 545 tech sq) references:
http://www.garlic.com/~lynn/subtopic.html#545tech
misc. past refs to vs/repack
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002f.html#50 Blade architectures
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

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

A Dark Day

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Dark Day...
Newsgroups: alt.folklore.computers
Date: Mon, 16 Jun 2003 02:18:34 GMT
shannon@daydream.shannon.net (Charles Shannon Hendrix) writes:
Regression testing is a rare thing. I have only worked in a single shop with a testing group, and they didn't do it properly.

I don't mind testing my code, but I feel better if someone other group looks at it too.


for the resource manager .... built an automated benchmarking process ... with a synthetic workload that could be extensively parameterised to match real world workload characteristics. initially did several hundred benchmarks simulating broad range of workloads and configurations and calibrating the resource manager. then had a apl program that would look at past benchmarks, do some analytical modeling and then select the next benchmark parameters (workload and configuration) to be run. eventually ran couple thousand benchmarks as part of preparing the resource manager for release.

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
http://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
http://www.garlic.com/~lynn/subtopic.html#disk

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

Interrupt in an IBM mainframe

Refed: **, - **, - **, - **, - **
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 GMT
tjpo@AIRBORNE.COM (Patrick O'Keefe) writes:
As good as the doc it, it may not really address that 2nd question. It answers the first question well, but sort of presupposes you already know the importance.

Anything I can think of to answer that 2nd question ends up sounding like a tautology. They are important because the architecture was designed to have them be important.


first it sounds like a homework question ... frequently the kind you get at the start of each new semester.

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:
http://www.garlic.com/~lynn/subtopic.html#fairshare
replacement algorithms &/or resource manager
http://www.garlic.com/~lynn/subtopic.html#wsclock
slightly related, automated benchmarking for calibrating resource manager
http://www.garlic.com/~lynn/submain.html#bench

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

why doesn't processor reordering instructions affect most

Refed: **, - **, - **, - **
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 GMT
Paul DeMone writes:
The PowerPC 604 and Pentium Pro both implemented OOO execution. The 604 shipped roughly 6 months before PPro and the PPro shipped about 6 months before the R10k. The R10k also shipped at about the same time as the PA-8000, a much more aggressive OOO execution design.

besides:
http://www.garlic.com/~lynn/2003j.html#18 why doesn't processor reordering instructions affect most
http://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most

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
http://www.garlic.com/~lynn/2001n.html#46 Blinking lights
http://www.garlic.com/~lynn/2002.html#16 index searching
http://www.garlic.com/~lynn/2002l.html#37 Computer Architectures
http://www.garlic.com/~lynn/2002o.html#9 PLX
http://www.garlic.com/~lynn/2003d.html#69 unix
http://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)

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

CC vs. NIST/TCSEC - Which do you prefer?

Refed: **, - **, - **, - **
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 GMT
pgut001@cs.auckland.ac.nz (Peter Gutmann) writes:
Give the above requirements, the CC certification, with its mutual recognition arrangements for certification (up to a given level) will definitely be more valuable.

to some degree orange book was targeted at multi-user, multi level security, general purpose data processing system. many things needing certification didn't meet that paradigm ... and/or couldn't also many nominally network connected infrastructures would get even a C2-level certification w/o the network connection (aka wouldn't have been able to get even a C2 w/network connection).

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.
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
http://www.garlic.com/~lynn/aepay4.htm#x9flb12 LB#12 Protection Profiles
http://www.garlic.com/~lynn/2001.html#50 What exactly is the status of the Common Criteria
http://www.garlic.com/~lynn/2001i.html#55 Computer security: The Future
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
http://www.garlic.com/~lynn/2002k.html#35 ... certification
http://www.garlic.com/~lynn/2002m.html#72 Whatever happened to C2 "Orange Book" Windows security?
http://www.garlic.com/~lynn/2003c.html#39 DOD 5200.28-STD capable OS?

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

Overflows

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 GMT
ararghNOSPAM writes:
Well the yellow card shows: (and they are in the 360 green card also)
LCR - Load Complement
LNR - Load Negative
LPR - Load Positive

There exist the FP versions of the above.

However, I don't have a PO handy, so I don't know exactly what they do.


esa/390 POP
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/CONTENTS?SHELF=#I%2e0

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

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

Virtual Cleaning Cartridge

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Matthew.Stitt@ABCDISTRIBUTING.COM (Matthew Stitt) writes:
This thread reminded me of the old OS/VU operating system announcement letter. Everything would be virtual when this thing would be delivered. I guess with virtual DASD and virtual Tape, we're getting closer.

i thot i had a copy ... but nope ... so a little time with handy search engine:
http://www.cbttape.org/fun.htm
http://www.randomjoke.com/funny/ibmvu.php
http://www.mcraeclan.com/Links/Computers/IBMMainframeHistory/mvsosvu.htm
http://www.mcraeclan.com/links/Computers/IBMMainframeHistory/vmxmas.htm
http://www.mercurynews.com/mld/mercurynews/business/11814661.htm

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:
http://www.garlic.com/~lynn/2001.html#20 Disk caching and file systems. Disk history...people forget
http://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):
http://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.

Nothing Happened
Nothing.

When it slowly dawned on everyone that nothing was going to happen, now or later, a flood of anguished telephone calls swamped the branch offices. At Poughkeepsie, in turn, all extensions, all twenty-five thousand of them, were busy. Unauthorized vehicles were turned away at the entrance roads. The Director of Programming Systems could not be found.

At last a brave customer engineer fought his way through the crowd around his system and obtained a dump. As he scanned the hex, the horrible truth came home to him. All of core, as far as the eye could see, was filled with control blocks, each containing pointers to other control blocks. DADSM was allocating and suballocating, searching DSCB's and building new ones. Job Management was initiating new jobs, task management was creating tasks and ATTACHING and LINKING, data management was opening data sets, and building WTG tables, DCB's, DEB's, ECB's, and IOB's. It was finding TIOT's from tasks dispatched by task management, which pointed to JFCB's. But no programs were being executed. No data was being read or written or processed. Operating System had taken over all the system resources and was entirely occupied with issuing supervisor calls, saving registers, restoring registers, chaining forwards and backwards, and following pointers all over core. Every pointer led to some other pointer. Operating System, after several years of effort by thousands of programmers, had finally become a completely closed system.

The great dilemma was solved only through the intervention of the Chairman of the Board, who personally issued a black_boardered Blue Letter announcing the withdrawal of Operating System. A large bonfire was built in the Poughkeepsie parking lot in which a huge mountain of OS documentation was burned, while the local high-school band played a funeral dirge. Users all over the world wearily set to the task of rewriting using the BPS assemble. A new programming system was announced for delivery in two years, to be called Assembler Stacked Support (ASS). And everyone breathed a great sigh of relief and became happy for a time.


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

tunneling TCP/IP over UDP for high-latency links?

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 GMT
bennett@peacefire.org (Bennett Haselton) writes:
Since UDP does not guarantee delivery, you'd have to have some application-level error checking. But otherwise, wouldn't this be a faster way to load Web pages over a high-latency link?

I googled "tunneling tcp/ip over udp" and "tunneling http over udp" but couldn't find anything to indicate it had been discussed much.


xtp looked at transaction protocol for minimal round trips (& packet exchange) for reliable transport. tcp has minimum seven packet exchange. vmtp (rfc 1045) has minimum five packet exchange. xtp has minium three packet exchange. overview/intro:
http://www.ca.sandia.gov/xtp/xtpintro.html

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

tunneling TCP/IP over UDP for high-latency links?

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 GMT
bennett@peacefire.org (Bennett Haselton) writes:
I'm actually looking at the minimum number of round trips required before the user actually starts downloading data. TCP requires seven packet exchanges, but it's the fourth one that sends the requested data to the requester. Do any of the other protocol designs get the data on the second roundtrip, like the UDP tunneling thing?

The other advantage of tunneling over UDP is that UDP is already built into most operating systems -- so you could have a mini-proxy server running on your local computer that you configure your browser to use, and the proxy server takes your HTTP requests and puts them into UDP packets to send to a proxy server on the other side of the high-latency link. Then that proxy finds the content you're looking for, sends it back over UDP, and the mini-proxy on your machine reassembles the data and presents it to the client.


so as per the XTP documentation .... it is a transport protocol that can run over just about anything ... from barebones MAC/ATM to possibly UDP? Then the issue is what are the minimum things that you want in your tunneling thing .... which works out to just about the minimum number of things defined for XTP. as in the XTP documentation ... particular connection can configure which set of XTP features are needed.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Of what use 64-bit "General Purpose" registers?

Refed: **, - **, - **, - **
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 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
I had temporarily forgotten, but it doesn't make much difference.

While SMT is theoretically a form of parallelism, it is unclear whether it is a worthwhile one. The problem is that it is optimising for 1980s restrictions (i.e. limited die space etc. available for ALUs) and not 1990s ones (e.g. access to memory and avoidance of pipeline and other glitches). An even worse problem is, because of its properties, it requires different optimisation techniques to that of 'conventional' SMP.

You end up then having to optimise at the serial level, at the SMT level, at the SMP level, and at the multi-chip level. Not funny. Of, course, I am excluding the simplest sorts of programs that can be optimised for all forms of parallelism at once.


and while SMT has the appearance of parallelism ... it is designed to address serialization & thruput problem.

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
http://people.cs.clemson.edu/~mark/acs_technical.html

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

Flash 10208

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Chris_Craddock@BMC.COM (Craddock, Chris) writes:
You will always see such a "hit" with just about any cache architecture. On the older boxes with integrated I/D cache the hit is not as large, but its there. If you "store" in any cache line, that line has to be invalidated in the caches of all of the other CPUs, which takes time. The z series design allows for (vastly) higher cache and memory bandwidth, but at the cost of murdering performance for many typical non-reentrant programs. Its a trade-off that was long overdue. Most other machines have used "Harvard" (i.e. separate I & D) caches for literally a decade or more.

Chris


Having instructions and data in the same cache line ... that constantly gets modified is similar to the cache line sensitivity work done for the 3081/3084 .... where a lot of storage allocation routines were modified to allocate on cache line boundaries and in units of cache lines. the issue wasn't a split I&D cache ... but "split" cache between the different processors ... and having different storage allocation units that shared cache line could result in horrible cache thrashing between the different (processor) caches.

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:
http://www.garlic.com/~lynn/2003j.html#18 why doesn't processor reordering instructions affect most
http://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
http://www.garlic.com/~lynn/2003j.html#35 why doesn't processor reordering instructions affect most

mainframe timeline:

http://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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

An a.f.c bibliography?

Refed: **, - **, - **
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 GMT
cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Probably also Douglas Adams' assorted works and the (in)famous paper, "Real Programmers Don't Use Pascal" for a background on humour & lifestyle choices...

... http://www.garlic.com/~lynn/2001e.html#31 High Level Language Systems was Re: computer books/authors (Re: FA:

in above:

Real Programmers Don't Eat Quiche Real Software Engineers Don't Read Dumps

http://www.garlic.com/~lynn/2002e.html#39 Why Use - ?

in above:

Real Programmers Don't Write Specs

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

Hand cranking telephones

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hand cranking telephones
Newsgroups: alt.folklore.computers
Date: Sat, 21 Jun 2003 23:36:17 GMT
Brian Inglis writes:
Most corporations don't want business data out where users can play with it, change it without an audit trail, store it where it won't be backed up, delete it by mistake. They want these functions performed by a professional IT person.

there was some study from ten years ago that claimed that half of businesses that had disk failure involving non-backed-up business critical data filed for bankruptcy within 30 days.

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:
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq

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

Hand cranking telephones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hand cranking telephones
Newsgroups: alt.folklore.computers
Date: Sun, 22 Jun 2003 14:31:35 GMT
jmfbahciv writes:
Every once in a while, I would INSIST on doing a fake restore just to test the process. Managers and developers would sigh, think bitch thoughts but go ahead and do it (that was for the stuff I couldn't do myself). Eventually, others acquired the habit. Training can be the pits.

the whole business continuity thing tends to have yearly exercise about being able to rebuild from scratch at a backup datacenter.

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
http://www.leeandmelindavarian.com/Melinda/
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:
http://www.garlic.com/~lynn/2001h.html#57 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://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:
http://www.garlic.com/~lynn/99.html#145 Q: S/390 on PowerPC?
http://www.garlic.com/~lynn/aadsm2.htm#availability A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/2001.html#61 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001f.html#27 Design (Was Re: Server found behind drywall)
http://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
http://www.garlic.com/~lynn/2002g.html#62 ibm icecube -- return of watercooling?
http://www.garlic.com/~lynn/2003f.html#36 Super Anti War Computers

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

Fast TCP

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Fast TCP
Newsgroups: alt.computer.security
Date: Sun, 22 Jun 2003 15:44:49 GMT
toro writes:
I read about the new TCP and the fact that it allows enormous data transfer rates by changing the error handling procedure. Since I am still learning the TCP/IP protocol, I was wondering whether this speed would help the stability of the infastructure and in which way

basically the bits can't go faster than the wire. the issues in tcp is chaotic network with seemingly random hops between any two end points are:

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:
http://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#45 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003h.html#7 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003j.html#39 tunneling TCP/IP over UDP for high-latency links?
http://www.garlic.com/~lynn/2003j.html#40 tunneling TCP/IP over UDP for high-latency links?

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

The Tao Of Backup: End of postings

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
ross.ps@ross.net (Ross Williams) writes:
I've just received an email complaining about my quarterly postings about the Tao Of Backup website and accusing me of spamming. The emailer did not provide a valid reply address, so I am replying here.

one taxonomy of security is PAIN

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
http://www.garlic.com/~lynn/index.html#glossary

sources:
http://www.garlic.com/~lynn/index.html#glosnote

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

June 23, 1969: IBM "unbundles" software

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:
Today is the 34th anniversary of IBM's announcement that, henceforth, it would no longer give away application software, but sell it instead, thus "leveling the field" for companies that were creating application software.

I was still in school at the time of the announcement. however i got elected to be the guinea pig for the first priced SCP software ... the resource manager. as part of that I got rewarded with spending something like six months on and off with the business and pricing people working on the rules for SCP pricing ... 5/11/76
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

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

Origin of "Function keys" question

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 GMT
proto@panix.com (Walter Bushell) writes:
I was introduced to computers in 1965 (IBM 1620)and didn't own one until 1984 (Macintosh), it was much longer for me.

Of course,the Mac was the first computer worth buying.


I was introduced to computers in 1966 (ibm 709) but didn't get a personal 2741 connected to the mainframe until 1969 and didn't get a personal 2741 terminal at home until march 1970.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Multics Concepts For the Contemporary Computing World - a CPU

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 GMT
Peter Flass writes:
This is true, but my understanding of Multics is that it worked this way. The segment and base registers would be paired: CS:EIP current code segment, DS:EDX curent part of linkage segment, SS:EBP stack segment, leaving ES, FS, and GS free to access other segments. How much code (basic blocks) reference six segments?

the issue in ROMP (pc/rt) and RIOS (original rs/6000) was that the original 801 architecture provided for 16 segment registers .... allowing up to a maximum of 16 different virtual objects to be simultaneously mapped into the address space.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Transactions for Industrial Strength Programming

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:
From later comments it seems that you may be talking about data that can be easily reconstructed. That's not what transactions are primarily about.

A major goal of transactions is to prevent the loss of any data (within the confines of whatever redundancy may be used to ensure that single failures don't compromise it) where reconstruction may not be easy. If the transaction completed, its changes are permanent, even in the event of subsequent failure; if not, it never happened.

A second goal is to allow fairly fine-grained data-sharing. Multiple transactions can proceed fully in parallel as long as none modifies a datum that another uses.


... and/or prevent inconsistency of information with some data being changed but not all.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Origin of "Function keys" question

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 GMT
Roland Hutchinson writes:
Of course the compelling business reason to buy a Mac turned out to be desktop publishing. I don't think anyone saw that coming while the Mac was still an unannounced product.

i sort of ribbed them that if you squint real hard you sort of could believe that all the desk top publishing was occuring on kitchen tables ... and besides it was ok because most of the people doing it weren't wearing 3 piece suits (so therefor it wasn't really business).

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

public key confusion

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key confusion
Newsgroups: sci.crypt
Date: Fri, 27 Jun 2003 14:31:50 GMT
truman@rediffmail.com (aditya) writes:
I have worked on single key algortihms and have an idea of how a public key cryptosystem works. I have a doubt. Is it that, in a public key cryptosystem- there can be many pairs of public-private key? In other words, is it that there are many private keys (and their corresponding public keys) in a public key cryptosystem? secondly, the generation of the public key is a mathematical function of the private key- is that correct?

slight editorial, asymmetric key algorithms have pairs of keys, information encrypted by one is decrypted by the other.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

June 23, 1969: IBM "unbundles" software

Refed: **, - **, - **, - **, - **, - **, - **, - **
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 GMT
John Ahlstrom writes:
So where did the Amdahl etc customers get the SCP?

the initial amdahl installations were mts and vm at various universities. both you could get for free ... you just order it (the mainframe emulators on intel platforms are running these earlier "free" VM versions today). early mvs you could also order for free. an issue about mvs was the joke that MVS required at least 20 IBM SEs on the account for its care and feeding.

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.
http://www.garlic.com/~lynn/subtopic.html#fairshare

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

Origin of "Function keys" question

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 GMT
jchausler writes:
Where was there a 709 running in 1966? At CMU (then CIT :-) we got a retired 7090 from Gulf Oil about 66 or 67 (they didn't give us the memory and so the machine was never reassembled and run). I am surprised that a tube based mainframe would still be in service at that late a date (although there was that story about the Univac II still running on the left coast in the mid 70's.)

washington state university, johnson hall annex, pullman washington. it was like serial nummber 003?. they tried to get ibm to pick it up for musuem. i heard they finally sold it for almost scrap.

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Goodbye PROFS

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Goodbye PROFS
Newsgroups: alt.folklore.computers
Date: Sat, 28 Jun 2003 14:08:16 GMT
Charles Shannon Hendrix writes:
The only thing that sucks more than getting useless email from a useless suit is getting it with sound, graphics, and viruses.

note that the problem with scripting incoming files over the network was identified as a problem some 30 odd years ago ... and appropriate procedures defined.

minor past profs &/or vmsg posts:
http://www.garlic.com/~lynn/99.html#35 why is there an "@" key?
http://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#56 E-mail 30 years old this autumn
http://www.garlic.com/~lynn/2002f.html#14 Mail system scalability (Was: Re: Itanium troubles)
http://www.garlic.com/~lynn/2002h.html#58 history of CMS
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002h.html#64 history of CMS
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, , misc
http://www.garlic.com/~lynn/2002p.html#34 VSE (Was: Re: Refusal to change was Re: LE and COBOL)
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
http://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
http://www.garlic.com/~lynn/2003e.html#69 Gartner Office Information Systems 6/2/89

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

OT: The dynamics of the Indian IT industry

Refed: **, - **, - **, - **, - **
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 GMT
computerguy@ANTELECOM.NET (Dino Jr) writes:
We all do a bit of griping about the outsourcing of IT jobs to India and other offshore locations, so I think some of you might find this informative and interesting. I particularly found the information in Chapters 9 & 10 quite educational.


http://www.london.edu/cnem/Events/Software_Conference/Desai_paper.pdf

"The paper develops a more nuanced explanation of the emergence of India's IT industry. It gives due weight to historical accidents, namely that the exit of IBM in 1978 left India with a few thousand programmers familiar with mainframes, and that the presence of a few thousand Indian engineers in the US led US firms to turn to India at a time of programmer shortage."


and, in fact, some number of the Indians in the US were the ones that had the connections and started brokering the outsourcing.

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 succesful 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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

atomic memory-operation question

Refed: **, - **, - **, - **, - **, - **, - **, - **
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:
Does anyone know which current architecutres are able to do an atomic compare-&-conditional-exchange where the operand-size is at least twice the size of a pointer ? x86's have the cmpxchg8b which is very nice for lock-free data-structures (like pools).

the original compare&swap back for the 370 ... 30 some odd years ago (compare and swap was chosen because CAS are the initials of the person originating the concept) was originally purposed as single instruction (what was replaced was exactly the pointer size). However the people that owned the 370 architecture wanted some enhancements

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:
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?
http://www.garlic.com/~lynn/2001f.html#41 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#61 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#70 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#73 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#74 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#76 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001g.html#4 Extended memory error recovery
http://www.garlic.com/~lynn/2001g.html#8 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001g.html#9 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2001k.html#65 SMP idea for the future
http://www.garlic.com/~lynn/2001k.html#67 SMP idea for the future
http://www.garlic.com/~lynn/2001n.html#42 Cache coherence [was Re: IBM POWER4 ...]
http://www.garlic.com/~lynn/2001n.html#43 IBM 1800
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002b.html#28 First DESKTOP Unix Box?
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002h.html#45 Future architecture [was Re: Future micro-architecture: ]
http://www.garlic.com/~lynn/2002l.html#58 Spin Loop?
http://www.garlic.com/~lynn/2002l.html#59 Spin Loop?
http://www.garlic.com/~lynn/2002l.html#69 The problem with installable operating systems
http://www.garlic.com/~lynn/2003.html#12 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003.html#18 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003b.html#20 Card Columns
http://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?
http://www.garlic.com/~lynn/2003c.html#78 The relational model and relational algebra - why did SQL become the industry standard?
http://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
http://www.garlic.com/~lynn/2003e.html#67 The Pentium 4 - RIP?
http://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003g.html#30 One Processor is bad?
http://www.garlic.com/~lynn/2003h.html#5 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003h.html#20 UT200 (CDC RJE) Software for TOPS-10?

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

Ted Nelson, of Project Xanadu

Refed: **, - **, - **
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 GMT
Larry__Weiss writes:
Has anyone here actually met Ted Nelson? I've always thought that he was a true "big thinker" of fairly early computing (1970's) and wish that he had published more books. I never introduced myself, but remember him at Siggraph conferences in the early 1980's.

misc. past threads with nelson &/or xanadu
http://www.garlic.com/~lynn/2000g.html#26 Who Owns the HyperLink?
http://www.garlic.com/~lynn/2002o.html#45 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2002o.html#47 XML, AI, Cyc, psych, and literature

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

Big Ideas, where are they now?

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 GMT
Larry__Weiss writes:
What other big ideas from computings history are still waiting to be fullfilled?

hiltz & turoff The Network Nation, Human Communication via Computer, 1978

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:
http://www.garlic.com/~lynn/aepay10.htm#26 Definese Dept Criticised on Internal Credit Card Fraud
http://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2001j.html#29 Title Inflation
http://www.garlic.com/~lynn/2001k.html#64 Programming in School (was: Re: Common uses...)
http://www.garlic.com/~lynn/2002b.html#51 "Have to make your bones" mentality
http://www.garlic.com/~lynn/2002c.html#27 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002e.html#37 Would the value of knowledge and information be transferred or shared accurately across the different culture??????
http://www.garlic.com/~lynn/2002g.html#64 Pardon my ignorance,
http://www.garlic.com/~lynn/2002k.html#63 OT (sort-of) - Does it take math skills to do data processing ?
http://www.garlic.com/~lynn/2002l.html#54 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002p.html#3 IBM OS source code

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

Micro$loth Update Mail-Bomb

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:
I don't think they were necessarily slow. Just the way those particular folks implemented their DB engines. I heard a story that the IBM folks who came up with SQL tried to strangle it at birth and use something more like QUEL. :)

My suspicion is that SQL won out primarily because it looked like English so you could sell it PHBs easier.


some past system/r & sql refs:
http://www.garlic.com/~lynn/submain.html#systemr

some specific references to system_r reunion site
http://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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Dealing with complexity

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 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
No, but they would push the limits further. Instead of modern systems being bug-ridden and almost unusable heaps, debuggable only by calling in the dwindling number of people with really low-level hacking experience, they could be fairly robust and largely self-diagnosing.

We could be talking about a factor of 10 reduction in development effort and administrator effort, a factor of 100 reduction in visible problems, a factor of 100 increase in software MTBF in problem situations, coupled with a factor of 10 increase in size. There is plenty of margin :-(

There is no way to ELIMINATE the problems of complexity, however.

And, no, I do NOT mean Project Eliza, which completely misses the point.


some activity from dependable computing, some reference:
http://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html
and
http://www.hdcc.cs.cmu.edu/index.html
http://www.scs.cmu.edu/hot/2000/11/nasa.html

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

Dealing with complexity

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 GMT
Jan C. Vorbrüggen writes:
Known? It was ignored when a terminal at Düsseldorf airport was built, which lead to the death of 17 (IIRC) people. When I first read the account in the paper, I couldn't believe it.

is it my imagination or were terminals at dusseldorf and dresden done by the some architect?

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

Transactions for Industrial Strength Programming

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 GMT
Jan C. Vorbrüggen writes:
Yup. In the system I saw, the disk subsystem bascially was a large set of nodes with battery backup, so that the whole database was "in core". On shutdown or any other failure, the nodes dumped their memory to disk sequentially as fast as they could.

no-single-point-of-failure is frequently specified in conjunction with transaction. i remember auditing some early raid-5 designs for no-single-point-of-failure and catching some w/o replicated battery-backed cache (for the parity update on transaction write).

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Cost of Message Passing ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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:
By 'cost' do you mean that it takes longer to communicate via message passing than shared memory ?

I don't see why this should be so. In a NUMA system or a message passing system for a message to get from CPU A to CPU B it will still have to travel along a very similar signal path. So it can't be the plumbing that slows it down

If you are talking about a locally delivered message then perhaps it could be slower, simply because you are eating bandwidth to make a copy (and pranging the cache to boot).

The trick seems to be to make messages cheap in the hardware, this has been done many many times. From my point of view keeping it simple is the way to go here, so you start by throwing your Ethernet gear into a skip. :)

I've seen a few people smugly compare TCP over Ethernet with custom built shared-memory pipes down the years and make the bogus leap of intuition that message passing is slow... I suppose to counter that they would really need to see how shared memory performs across TCP + Ethernet. My guess would be : considerably more shite than message passing.


SCI was attempt to be all things to all people (mappings for cache memory, disk protocol, etc):
http://www.scizzl.com/
http://hsi.web.cern.ch/HSI/sci/sci.html
http://www.computer.org/proceedings/lcn/1591/15910691abs.htm
http://lists.insecure.org/linux-kernel/2001/Jul/1421.html

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 | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Modular Exponentiations on Battery-run devices

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:
Take the number of clock cycles required to calculate the exponential multiply by the energy used by the device in one second and device by the number of clock cycles per second.

The energy and speed of the device should be in its documentation.


the other place is some of the financial smartcards that are looking at transiting to proximity (from iso 7816 contract to iso 14443 proximity) where the energy driving the chip is RF (out of the air).

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

Dealing with complexity

Refed: **, - **, - **
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 GMT
eugene@cse.ucsc.edu (Eugene Miya) writes:
I think a better analysis of the types of complexity would be better. I've never been a fan of line of code as a metric. There are instances, Szilard and the bomb, and the SR-71, where knowing basic materials like stuff while seemingly trivial made critical differences in the final product (boron used in making graphite and distilled not tap water used in finishing and cleaning Ti). And I'd guess there were similar Cray stories.

K.I.S.S.

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.
http://www.garlic.com/~lynn/subboyd.html#boyd

specific:
http://www.garlic.com/~lynn/99.html#120 atomic History
http://www.garlic.com/~lynn/2003j.html#13 A Dark Day

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

Transactions for Industrial Strength Programming

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 GMT
robertwessel2@yahoo.com (Robert Wessel) writes:
While I can't comment on all things sold as transaction monitors, CICS provides full transaction support for a variety of record oriented file types (mainframe heritage, after all). Record locking, forward and backwards recovery (aka logging and transaction backout), over as many files as you want to touch, and it'll synchronize the parts of the transaction it's handling with the "real" database server, if you're hitting one too.

long ago and far away ... the university got to be one of the original CICS beta test sites (on its way to its first product release). i got to shoot some number of bugs. I particularly remember a trivial bdam open bug. it was pretty obvious that it had been originally developed and tested in a single environment. lot of the products from the '60s originated in some specific customer shop ... and because it appeared useful and no other product of that nature was in the market, ... it would get promoted from customer application to commercial product.

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

Multics Concepts For the Contemporary Computing World

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
jmfbahciv writes:
One of the reasons I decided to continue to work on TOPS-10 was so more people had more CPU cycles available to them at all times. I envisioned that a lot more things would be accomplished in the sciences if calculations could be off-loaded onto a computer, especially if the computing could be completed in CPU-seconds rather than CPU-months...or years.

I heard about a program session that run by chemists, stand-alone, and was in its 20th day of the 30-day run when a very bad, power-stopping storm visited the area. The calculations done these days wouldn't have been considered back in the 70s or 80s.

You needed Cray power and waiting line was long and fraught with many strainers that a user had to overcome before getting the computes.


pasc had a program that would be in the queue for sjr's 195 for 3 months before being run. they found that they could schedule it in the background on pasc's 370/145 ... where it wouldn't get a lot of 1st shift cpu, but could catch up on 2nd, 3rd and 4th (weekends) ... and complete in little less than 3 months. of course they did regular checkpoints.

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)
http://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 - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Multics Concepts For the Contemporary Computing World

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 GMT
Peter Flass writes:
Yes, but there's OS code and then there's OS code. Are device drivers part of the OS? There has certainly been debate about where they belong. There are parts of the OS that are beaten to death - scheduler, memory manager, etc. These need to be as efficient and close to the hardware as possible. Then there are parts of the OS kernel that aren't heavily used - in general why not just let them page out and don't worry, within reason, about squeezing the last byte and cycle out of them. It's the old 80-20 rule.

i did that as undergradudaet woring on he cp/67 kernel ... after redoing the memory manager, the schedule, the interrupt handlers, the page i/o subsystem, the linkage infrastructure, resourcce management .... i created an infrastructure that allowed portions of the kernel to be enabled for page replacement ... and the kernel call/linkage infrastructure added code to handle the semantics of page-in/lock and unlock.

misc. page, kernel, pathlength, resource manager, fair share scheduling, etc:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

misc. past discussions of kernel paging:
http://www.garlic.com/~lynn/94.html#4 Schedulers
http://www.garlic.com/~lynn/97.html#23 Kernel swapping itself out ?
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#13 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002q.html#54 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003e.html#12 Resolved: There Are No Programs With >32 Bits of Text

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Multics Concepts For the Contemporary Computing World

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 GMT
jmfbahciv writes:
That is a configuration problem. If all your I/O has to go through CPU A, I/O bound shops will not use the CPU resource efficiently. If your configuration is set up so that any CPU can get to any I/O channel, nothing has to got through a context switch to dump bits through a channel.

an issue is that the CPU with the processor can have much of the I/O supervisor in the cache and spend a lot of time executing that code. Another processor doesn't necessarily have to force a context switch ... it just queues a request and returns to its application execution while the CPU with the channels peal off the queued request and perform the I/O. For heavily loaded disk I/O with a queue almost always waiting for a disk arm .... the request will almost always be queued in any case ... so there is potentially almost no pathlength difference for the CPU originating the request (it gets queued because of the disk arm busy regardless).

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 - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Microkernels are not "all or nothing". Re: Multics Concepts For

Refed: **, - **, - **, - **
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:
Microkernel researchers spent a long time figuring out performance cheats/tweaks to avoid paying the general purpose message passing overhead for common user<->OS communications. One trick used in Mach is to optimize away the thread dispatch in some cases, treating the receiving thread as a continuation of the sending one, with some restrictions on semantics (kinda like vfork sped up fork).

Given that there's still a need for message passing (all the daemons and servers that nobody argues should be inside the OS), I'm a little surprised that no better user mode domain-crossing mechanisms have been developed. You could certainly beat general purpose thread->thread cross-process messaging by taking advantage of the fact that you don't need a separate thread on the other side (just like a syscall), and you don't need fully symmetric protection (the server is more trusted than the clients, again like a syscall). But maybe the higher levels of protocols like OLE impose so much overhead that it's not worth the effort.


one could claim that CP/67 was one of the early microkernels ... providing a simplified machine instruction API ... with other operating systems ... general purpose as well as the cambridge monitor system (CMS) providing the interactive facility. some misc. past posts on optimizing cp/67:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

misc. past threads regarding nextstep and mach:
http://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
http://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001k.html#19 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2001n.html#35 cc SMP
http://www.garlic.com/~lynn/2002i.html#73 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2003.html#46 Horror stories: high system call overhead
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
http://www.garlic.com/~lynn/2003c.html#32 Early attempts at console humor?
http://www.garlic.com/~lynn/2003c.html#45 Early attempts at console humor?
http://www.garlic.com/~lynn/2003e.html#25 A Speculative question
http://www.garlic.com/~lynn/2003e.html#33 A Speculative question

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

1950s AT&T/IBM lack of collaboration?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Floyd Davidson writes:
What is odd in that instance is that, at least at ATT, the research people were clearly very heavily involved in the theoretical and initial implementation of computers and computer networking, but virtually nothing they did filtered down to operations in terms of _understanding_. A large number of "black box" items showed up to make the system work better, but anybody who understood them was shunned. (And Scott Adam's has given us ten years of Dilbert cartoons to describe the environment in which that could happen.)

we did a number of digital communication projects, fiber, satellite, etc and had to deal with various and sundry telco people in the late '70s and early '80s. A person that has lived all their life with operational, analog, voice, point-to-point copper really have a different perspective ... and may have a really hard time understanding something different. In some situations they earned the label "telephone toads".

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
http://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 - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

1950s AT&T/IBM lack of collaboration?

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 GMT
hancock4@bbs.cpcn.com (Jeff nor Lisa) writes:
A prior post mentioned AT&T central office capability to house computers. AFAIK, this was required for ESS too, I believe the electronics generated a fair amount of heat that had to be removed and also required tighter temperature/humidity control than a relay system did.

when we were working with mosaic (now netscape) on the original payment gateway (for what is now being called electronic commerce) we had no single point of failure with redundant connections to different ISPs. One of the ISPs was co-located at large CO ... and most everything was 48volt. it was also interesting attempting to track/discover the various failure modes for the operation (and build recovery scenarios).

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

1950s AT&T/IBM lack of collaboration?

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 GMT
Floyd Davidson writes:
The URL didn't work, but I'm assuming that was the relatively recent thread in alt.folklore.computers, which I did read and found interesting.

oops missing "l" in html:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

1950s AT&T/IBM lack of collaboration?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Dave Nevers writes:
In the meantime, IBM was trying to get into PBXs and networking. They brought out a PBX in Europe (called Evergreen), but for the U.S. market they bought ROLM and began marketing the CBX. They also entered into a joint venture with Aetna Insurance to create a satellite based network called SBS (Satellite Business Systems). Few customers had enough data to justify the 10-meter dishes, and the round-trip satellite delay infuriated voice users. Aetna bailed on the venture, and SBS was quietly sold to MCI, who promptly dismantled it. SBS wasn't really a radical new idea from IBM. It really represented the backbone portion of a complete telco-bypass proposal from Xerox (yes, XEROX) called XTEN. XTEN called for large satellite uplink data 'hubs' fed in a metropolitan area by privately owned microwave, bypassing both the local telco and Long Lines.

my wife was one of the IBM'ers (after being in POK responsible for loosely-coupled ... aka mainframe cluster architecture) that went to SBS.

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:
http://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:
http://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 - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

next, previous, index - home