List of Archived Posts

2003 Newsgroup Postings (6/7 - 7/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

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!!!

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

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 extended store bus (extended store was large page memory
that had synchronous instructions to move 4k pages between regular
memory and extended store). HiPPI i/o controls was done with reserved
addresses in extended store (effectively analogous to memory mapped
peek&poke .. but doing full 4k transfers even for small command sets).
misc. hippi/extended 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

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 guarenteed 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

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

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

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

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

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

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 varien for her
reference:
http://www.princeton.edu/~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

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/subtopic.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

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
Hennessey'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://www.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

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

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

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://www.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

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?

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

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

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

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?

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?

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

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

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 parameterized
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/subtopic.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

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/subtopic.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

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?

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

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.ldworen.net/fun/osvu.html

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_BORDERED 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?

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://www.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