List of Archived Posts

2002 Newsgroup Postings (1/1 - 1/12)

index searching

The demise of compaq

The demise of compaq

The demise of compaq

Buffer overflow

index searching

index searching

The demise of compaq

The demise of compaq

How to get 128-256 bit security only from a passphrase?

index searching

The demise of compaq

A terminology question

A terminology question

index searching

index searching

index searching

index searching

Infiniband's impact was Re: Intel's 64-bit strategy

Buffer overflow

Younger recruits versus experienced veterans ( was Re: The demise of compa

"blocking factors" (Was: Tapes)

index searching

Buffer overflow

Buffer overflow

ICMP Time Exceeded

Buffer overflow

Buffer overflow

Buffer overflow

Buffer overflow

Younger recruits versus experienced veterans ( was Re: The demise of compa

index searching

Buffer overflow

Buffer overflow

Buffer overflow

Buffer overflow

a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)

Buffer overflow

Buffer overflow

Buffer overflow

Multi-Processor Concurrency Problem

Movies with source code (was Re: Movies with DEC minis)

a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)

hollow files in unix filesystems?

Calculating a Gigalapse

VM and/or Linux under OS/390?????

hollow files in unix filesystems?

School Help

Microcode?

OT Friday reminiscences

Microcode?

Microcode?

Microcode?

School Help

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch
Date: Tue, 01 Jan 2002 21:47:28 GMT

Terje Mathisen writes:

This was the reason that I never understood that particular prof's
infatuation with special hw for the task:

Originally, when they started up, most data had to come from disk
arrays, and even 486 and earlier cpus could keep up with the fastest (or
most cost-efficient) disk systems.

Today the same holds true, but for main memory access vs cpu opcodes.

there used to be some number of implementations where matching engines
were co-located with every read head .... with the electronics to
simultaneously read from every head doing searches.

i think commodity disk & processor engine got large enuf, fast enuf,
and cheap enuf ... that it was simpler to just create large cluster of
PCs & disks ... and do the parallel searching with commodity priced
parts rather than custom hardware.

from disk array stand-point ... i believe CM5s had 32+8 disk arrays
and even floating point system boxes from the '85 era had 40mbyte/sec
disk arrays.

how 'bout teradata & britton-lee database machines ... misc. ref:
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?

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

The demise of compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The demise of compaq
Newsgroups: comp.os.vms,comp.arch,comp.sys.intel,alt.folklore.computers
Date: Tue, 01 Jan 2002 23:20:01 GMT

"Charlie Gibbs" writes:

This is the result of the shift in mindset from batch to interactive
systems.  "Interactive" is seen as more desirable, compared to stodgy
old batch systems.  But, as you've pointed out, there is a downside.

i'm not sure that it is a shift in mindset .... there is still huge
amount of batch that continues to exist .... i would even claim that
the backend "webserver" have most of the characteristics of
traditional batch systems with regard to drive for things like service
level agreements and "darkroom" operations.

it may not be so much that batch-like systems have dwindled ... it is
that there has been a huge explosion in the interactive systems market
... moving into home & consumer marketplaces (home pcs far out
numbering backend batch systems ... doesn't necessarily mean that the
backend batch systems have declined).

the downside issue in terms of the batch-like operations for the
backend webservers .... is trying to apply interactive-paradigm
platforms to a fundamentally batch-paradigm environment (including the
backend systems ...  aka webservers have relatively similar
operational characteristics to the CICS, IMS, etc ... "online"
subsystems that are traditional batch operations). Part of the issue
is that the batch-paradigm and interactive-paradigm platforms tended
to have very different design-points during development. However,
possibly the majority of the really large, scaled-up backend web &
internet systems have been platformed on non-interactive paradigm
platforms like Tandem (which is a compaq operation).

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

The demise of compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The demise of compaq
Newsgroups: comp.os.vms,comp.arch,comp.sys.intel,alt.folklore.computers
Date: Wed, 02 Jan 2002 06:02:37 GMT

JF Mezei writes:

That is because they were forced to streamline all the dataflow to be able to
reach that magical 10 transactions per second the banks needed. There was no
need for middleware when you stuck to the IBM mainframe and 3270 terminals. As
a matter of fact, when a mainframe interrogated another, it would often format
the transaction as if it came from a 3270 terminal and parse the response.

The interrogated mainframe didn't need any additional software to handle this
because everyone appeared to be a 3270 terminal.

But bring in the incompatible systems and all of a sudden you need to add a
layer that allows them to communicate between each other. Just look at the
overhead of HTML and XML where a simple transaction needs to be formatted,
transmitted as a chunk orders of magnitudes bigger and then parsed back into a
transaction the receiving computer can handle.

Just look at VMS mail. Instead of changing VMSmail to make it native RFC822 ,
they added a layer that converts from VMSmail to RFC822 and sends it out (and vice-versa).

but the "solution" to application migration to PCs and the whole
client/server was supposed to be SAA ... my wife and I took a lot of
heat on the middleware issue (we use to go by and kid the executive
that "owned" SAA ) ... this happened before HTML & XML.
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic: facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)

slightly related was the departmental server issue (from the late '70s
& early '80s ... which had similar requirements/solutions)
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

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

The demise of compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The demise of compaq
Newsgroups: comp.os.vms,comp.arch,comp.sys.intel,alt.folklore.computers
Date: Wed, 02 Jan 2002 16:11:35 GMT

Brannon_Batson@yahoo.com (Brannon Batson) writes:

I'd be willing to wager that any off the shelf Alpha could handle the
thousands of users with terminal shells and the batch processed text
jobs of yesteryear, and still have plenty of cycles left over.  The
difference is that software has become more demanding of the hardware
on a per-user basis, because (a) the users have become more demanding
of the software, and (b) as you said earlier, there are so many layers
of cruft between the user's problem and the hardware that solves it.
I don't see how either of these are the fault of the system architect.

for the web environment ... most of the gui stuff that is cpu
demanding is on the front-end personal computers/workstations. the
back-end webservers (in principle operate very much the way of
mainframe legacy systems doing online transactions) have suffered from
lack of scalable implementation.

first web servers ran http over tcp/ip and spawned a new address space
and task for every http request. for web servers that operated at a
few transactions per minute there wasn't much of a scalable issue.

http requests are effectively connectionless transactions ... while
tcp is a connection protocol ... tcp requires a minimum 7-packet
exchange for setup/teardown of the session, which is heavy-weight all
by itself. FINWAIT was a tcp teardown mechanism to verify there wasn't
any dangling packets and were all queued on a linear list and all
incoming packets did linear search of the FINWAIT list to see if it
was a dangling packet. circa 1996, dynix was possibly the only unix
that had experienced large numbers of FINWAIT and gone to FINWAIT
management that wasn't linear scan ... other webserver platforms that
started experiencing high-number of "quick" connections resulting in
huge FINWAIT lists were starting to see 90% of total CPU devoted to
FINWAIT list scan. NETSCAPE kept adding servers for connections as
well as FTP downloads of new browswers ... picking the NETSCAPE1,
NETSCAPE2, ... NETSCAPE19 node for connection was becoming a major
topic. NETSCAPE saw a dramatic change when they put in a large dynix
configuration for NETSCAPE20 node.

The use of (new) connection TCP for connectionless transaction HTTP
has been a real scaling issue as well as spawning & then just having
different address space for every transaction.

The other evolution for production webservers ... I believe was first
at YAHOO with the front-end routers with rotating routing to large
pool of backend servers (I have recollections of discussing it with
the vendor engineer responsible for the implementation). There had
been Q&D hack to DNS prior to that to return rotating IP-address from
pool but that was somewhat random and couldn't reach out to the
caching intermediate servers. The initial deployment of the rotating
routing code at YAHOO allowed significantly improved load balancing
across the back-end servers.

However, there still is significant extra computing resources expended
in the web environment to use connection & command oriented
paradigms in support of connectionless transaction activity.

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

Buffer overflow

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Buffer overflow
Newsgroups: sci.crypt
Date: Wed, 02 Jan 2002 16:29:05 GMT

Richard Heathfield writes:

It's better to write clear, maintainable code than to bum every cycle.
On that, I agree. I also think that it is better to play safe than to be
sorry. If you are not confident that a particular circumstance cannot
arise, then add production code to check against that possibility. If
you are confident that a particular circumstance cannot arise, because
of the way the program works, then assert it.

don't you just hate it when you do a custom kernel for somebody and
then they track you down in some other job 10 years later looking for
assistance ... they've continued to migrate the kernel to newer
generations of machines and then something really quirky hardware
change shows up (especially when the custom kernel has been propagated
all over some place like AT&T longlines).

random refs:
http://www.garlic.com/~lynn/95.html#14 characters
http://www.garlic.com/~lynn/96.html#35 Mainframes & Unix (and TPF)
http://www.garlic.com/~lynn/97.html#15 OSes commerical, history
http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
http://www.garlic.com/~lynn/2000b.html#74 Scheduling aircraft landings at London Heathrow
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001f.html#3 Oldest program you've written, and still in use?

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

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 02 Jan 2002 18:05:30 GMT

"Stephen Fuld" writes:

The idea of using disk controller hardware to search the disks at media
speed is an old one.  This was implemented by Univac for their Fastrand
drums where you could search the first word of each or all words of a set of
sectors.  Of course, it was also implemented by IBM in the CKD architecture,
where the K stands for the key.  There were (and still are) commands to
search the keys of the records on a track for equality or other relations.

But as someone else pointed out, these schemes were never very practical and
quickly lost out to various indexing schemes such as b-trees, etc.  However,
in a nod to backwards compatibility, the mechanism to search a partitioned
data set (sort of like like a directory) in an IBM mainframe still uses keys
and the relevant search commands (little enhanced) to search for a desired
entry.

CKD was in the controller not in the head .... it was a '60s
memory/bandwidth trade-off. The problem with CKD past about mid-70s
was that there was significant "excess" memory for in-core indexes and
I/O resources were becoming a bottleneck.

from posting here and elsewhere several times ... comparison from
early '80s but stuff that I had started on in the late '70s

system          3.1L            HPO     change
machine         360/67          3081K

mips            .3              14      47*
pageable pages  105             7000    66*
users           80              320     4*
channels        6               24      4*
drums           12meg           72meg   6*
page I/O        150             600     4*
user I/O        100             300     3*
disk arms       45              32      4*?perform.
bytes/arm       29meg           630meg  23*
avg. arm access 60mill          16mill  3.7*
transfer rate   .3meg           3meg    10*
total data      1.2gig          20.1gig 18*

Comparison of 3.1L 67 and HPO 3081k

I had tried to get a non-multi-track search in the product ... but
they gave me a price-tag for product support (no R&D, development,
just documentation and release) of $26m. specific problem
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe background
http://www.garlic.com/~lynn/99.html#74 Read if over 40 and have Mainframe background

by comparison CMS had an "in-core" filesystem ... from the beginning
... mid-60s ... but it was linear search; the in-core directory got
"sorted" enhancement in the early '70s for fast directory searching.

some recent CMS filesystem discussions:
http://www.garlic.com/~lynn/2001n.html#1 More newbie stop the war here!
http://www.garlic.com/~lynn/2001n.html#62 The demise of compaq
http://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2001n.html#88 A new forum is up! Q: what means nntp
http://www.garlic.com/~lynn/2001n.html#90 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#92 "blocking factors" (Was: Tapes)

misc. 3.1l/hpo comparison postings (w/more detailed explaination):
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?

various CKD, multi-track, vtoc, & pds discussions:
http://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/97.html#16 Why Mainframes?
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe  background
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
http://www.garlic.com/~lynn/2000e.html#22 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#19 OT?
http://www.garlic.com/~lynn/2000f.html#42 IBM 3340 help
http://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2001.html#12 Small IBM shops
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#54 FBA History Question (was: RE: What's the meaning of track overfl ow?)
http://www.garlic.com/~lynn/2001.html#55 FBA History Question (was: RE: What's the meaning of track overfl ow?)
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#48 VTOC position
http://www.garlic.com/~lynn/2001d.html#60 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001f.html#21 Theo Alkema
http://www.garlic.com/~lynn/2001g.html#24 XML: No More CICS?
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001k.html#51 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2001l.html#39 is this correct ? OS/360 became MVS and MVS >> OS/390
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
http://www.garlic.com/~lynn/2001n.html#4 Contiguous file system

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

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 02 Jan 2002 18:56:41 GMT

"Stephen Fuld" writes:

The idea of using disk controller hardware to search the disks at media
speed is an old one.  This was implemented by Univac for their Fastrand
drums where you could search the first word of each or all words of a set of
sectors.  Of course, it was also implemented by IBM in the CKD architecture,
where the K stands for the key.  There were (and still are) commands to
search the keys of the records on a track for equality or other relations.

in this particular on-site customer call (fortunately their national data
center was within driving distance):
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe background
http://www.garlic.com/~lynn/99.html#74 Read if over 40 and have Mainframe background

the disks had 19 platter/tracks & 19 heads per cylinder (actually 20
if you included the servo head/track/platter). since CKD didn't have
independent paths to each head ... the controller had to sequentially
read each track ... for a multi-track search of a whole cylinder it
was 19 revolutions & at 3600RPM (60RPS) ... the I/O operation took
nearly 1/3rd second elapsed time.

now since this was a '60s memory/bandwidth trade-off .... the
controller didn't have its own memory for the matching string/search
so it had to use the I/O channel/bus to continuelly retrieve the data
from the processor storage; the result was the I/O channel/bus,
controller, and drive/disk was "locked-out" for the duration of the
operation.

Now a processor might have six to 16 channel/buses ... so that wasn't
necessarily really terrible ... but there tended to be 16-30
drives/disks per controller and the controller could be attached up to
eight processors ... so all processors in a complex (as in the cited
example) would tend to be locked out of accessing all drives on the
specific controller. In the above example ... there were serveral
high-use drives/disks (especially the main application program library
for all processors).

Again because this was a mid-60s memory/i/o trade-off
paradigm/design-point, not only was there not memory for in-core
indexing there was also almost no (disk) data caching (nearly every
application invokation required numerous disk accesses).

This was donwside of using a legacy trade-off design-point from the
mid'60s well past when the trade-off issues had totally changed. It
was very recognizable by the late '70s ... and continued even up thru
current day ... that many of these legacy based platforms still have
significantly higher i/o rates because of poor leveraging of the
explosion in real storage availability (caching, in-storage indexes,
etc) .... this is independent of various legacy based platforms that
do heavily leverage caching/indexes and just are performing an
extrodinary amount of transaction ... typically requiring lots of data
that has low re-use patterns (and for which caching doesn't mitigate
the memory/IO issues).

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

The demise of compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The demise of compaq
Newsgroups: comp.os.vms,comp.arch,comp.sys.intel,alt.folklore.computers
Date: Wed, 02 Jan 2002 21:08:15 GMT

jmfbahciv writes:

I always thought that this was due to that "distributed processing"
craze gone awry.  Once the processing got doled out to pieces
of gear, collecting it back became impossible.  One reason was
that a piece would become a separate company.  Once it did,
it would go off on its own business path without the leash
it would have had if the group had stayed within an organization.

it wasn't even that ... just migration of function from mainframe out
to the PC ... combination of 3270 emulation with screenscraping and
spreadsheets.

one of the "real" & "serious" problems is that the mainframes tended
to have serious business continuity efforts (backups, recovery, etc)
which seldom existing on the PCs ... when serious corporate assets
weren't just being copied to the PC ... but actually (only) resided at
the PC ... there started to be an upswing in business problems.

there was a study done in mid-90s that of the businesses that had
serious business assets resident on a non-backedup disk that had
crashed ... 50 percent filed for bankruptcy within the first 30 days.

there was some serious efforts by the mainframe disk operations to
address the problem starting by at least the late '80s .... however
various kinds of corporate "in-fighting" seriously hampered the
deployment.

The SNA business group didn't want to give up its market turf and
revenue that it had from treating the PCs as emulated terminals
... the disk division wanted to deploy serious support providing "disk
speed" level bandwidth between the PCs and backend mainframe (along
with the appropriate applications ... making it practical for PCs,
workstations & departmental servers to treat backend mainframe disk
farms on par with local disks). Complicating all this was the SAA
effort which was a slightly disquised effort attempting to migrate as
much of the "lost" applications back to the mainframe ... treating the
PC was a really fancy, gui 3270 (does anybody remember the early '90s
efforts to have lotus 123 running on backend mainframe?).

this is somewhat related to the middleware and departmental computing
efforts.

related postings:
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

random sna & saa postings
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 ?)
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/2000.html#3 Computer of the century
http://www.garlic.com/~lynn/2000.html#51 APPC vs TCP/IP
http://www.garlic.com/~lynn/2000.html#53 APPC vs TCP/IP
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000b.html#78 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000b.html#89 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000c.html#45 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000e.html#56 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001b.html#49 PC Keyboard Relics
http://www.garlic.com/~lynn/2001d.html#38 Flash and Content address memory
http://www.garlic.com/~lynn/2001e.html#8 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001i.html#7 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#21 3745 and SNI
http://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#19 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2001k.html#21 OT: almost lost LBJ tapes; Dictabelt
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#23 mainframe question
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2001n.html#15 Replace SNA communication to host with something else
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...

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

The demise of compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The demise of compaq
Newsgroups: comp.os.vms,comp.arch,comp.sys.intel,alt.folklore.computers
Date: Wed, 02 Jan 2002 21:59:18 GMT

gherbert@gw.retro.com (George William Herbert) writes:

The basic truth is that the current website infrastructure
environments are highly scalable; they're also a lot more
complex than outsiders usually give them credit, and that
complexity and functionality are there for good reasons.

and some of largest aren't even the "interactive" evolved platforms
... unix, m'soft, etc ... but more of the legacy oriented platforms
like tandem.

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

How to get 128-256 bit security only from a passphrase?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to get 128-256 bit security only from a passphrase?
Newsgroups: sci.crypt
Date: Thu, 03 Jan 2002 04:01:58 GMT

"David Midkiff" writes:

I don't think its impossible to remember 45 characters: "In the beginning
God created the heavens and " That's 45 chracters. A key doesn't have to be
all unintelligible chracters. It could be obscure phrases. I once memorized
235 digits of pi for a contest in high school. Lame? Yes. But my point is
the human brain has a high capacity. If you can remember all the phone
numbers you've had in a lifetime you can remember number far greater than 45
chracters.

As for a practical solution ... it's called public-key cryptography ... like
RSA. One doesn't have to remember an entire 256-bit key. All one has to do
is establish a session key using public key schemes like RSA. Reusing keys
isnt a very smart idea.

the problem with shared-secret paradigm ... is that every security
domain requires a unique shared-secret ... which menas that there
isn't just one 45 character pass-phrase but tens. also english
sentences/phrases tend to not be completely random letters so the
amount of entropy is less than the number of characters (45 character
pass-phrase may only be the equivalent of ??? i don't remember the
value but possibly 100bits? ... even if it wasn't sensible combination
of words ... the number of valid word combinations totaling 45
characters is significanlty less than the number of 45 random letter
combinations).

one of the benefits of public key cryptography is that the public key
can be shared with a large number of different security domains. The
corresponding private key needs protection ... which could be with a
passphrase .... but note that in this case ... it is a single
non-shared passphrase protecting the private key (and so the issue of
requiring a unique shared-secret per security domain isn't an issue
...  or conversely, there is only a single security domain ... that of
protection of the individual's private key).

The issue of the need for session key depends on whether there is
authentication or encryption. Session keys for encryption is a method
used in both public key and secret key paradigms ... aka things like
debit/ATM network with secret key technologies have session or even
transaction keys (basically network & device shared-secret keys used
for exchanging session keys).  Within that debit/ATM infrastructure
there are also different shared-secret keys which are the individuals'
PINs for transaction authentication.

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

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 03 Jan 2002 21:46:27 GMT

"Stephen Fuld" writes:

Yes, but even if the controller had the memory (BTW, it would have required
only 256 bytes!) it would have saved the channel utilization but the
controller would still have been tied up reading the disk data, doing the
comparisons, etc.

problem was getting the architecture changed ... either a new kind of
operation or a non-CKD disk (aka like trying to get VTOC & PDS support
for FBA ... the main multi-track search culprits).

they aren't called channel programs for nothing.

effectively the i/o "channel" (nominally) an i/o bus is also
effectively the instruction fetch unit.

The i/o controller is somewhat the instruction decode unit.

combination of the i/o controller and the device (in this case disk) are
the execution units.

the CKD disk programming for simple searching is

          seek
          search
          tic   -8
          read/write

the seek instruction generates an exception if it doesn't work correctly.

the search instruction falls thru to the following instruction if the
record just examined doesn't meet search criteria (equal, less than,
greater than, greater or equal, etc). If the record just examined does
meet the search criteria, the search instruction generates a "branch"
to the next instruction plus 8 (skips the immediately following
instruction). Say a track has ten uniquely keyed records, the channel
program could loop ten times examining each record. The "search"
instruction is slightly misnamed, t isn't really a search multiple
record instruction ... it is a check current record for match
instruction (the search operation is implemented with multiple
"channel program" instructions in a loop).

Now the channel "architecture" precludes pre-fetch ... each
instruction is uniquely executed. A combination of precluding
pre-fetch and not having a real "search" operation created a lot of
the CKD problem. Effectively both mainframe processor architecture
allowed dynamic instruction modification (creating significant
performance impact on being able to pre-fetch & pipeline processor
instructions) and as well as channel program (creating similar
problems with trying to do instruction optimization).

The architecture precluding instruction pre-fetch also creates huge
problems for virtual memory operations. Effectively, for virtual
memory operations ... a "channel program" (one or more instructions)
is completely copied and "translated" (all virtual addresses replaced
with real addresses ... all branch instructions translated to point to
the copied program, etc). This worked for all channel programs that
weren't self-modifying. Self-modifying channel programs didn't work in
the virtual memory environment since the storage getting modified was
the "virtual" instructions not the "real" instructions (similar to
split I/D cache problem in harvard architecture and not being to
easily/directly modify instructions).

Searching implemented as a (channel) program loop (as opposed to an
instruction) and not being able to prefetch precluded officially
outboarding search operation into controller/device.

Now, this restriction also causes problems trying for channel
extensions because of latency issues with sequentially fetching &
executing each i/o instruction (ESCON, etc). I also encountered this
in the early '80s when I was doing the kernel HYPERChannel I/O
implementation (in part being able to remote several hundred people in
the IMS group 5-10 miles from STL). The objective was to take all the
locally processor attached devices used by standard programmers and
put them 5+ miles away from the data center. A major issue was that
the IMS group was all using local, cahnnel-attach 3270 terminals with
approx.  .25 secon system response. The standard SNA answer was with
"remote" VTAM terminals ... where the basic hardware response was greater
than one second (and the "system" response was much greater).
some recent related thread
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq

some remote 3270 response threads
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol

HYPERChannel had an A510, remote device adapter ... basically a box
that emulated a mainframe channel ... which standard mainframe control
units could be connected to. Because of the HYPERChannel communication
latencies ... it wasn't possible for the A510 to rely on correct
operation by accessing mainframe memory for all data. Instead, the
channel program was copied and downloaded into the A510 for local
exeecution (somewhat analogous to how the virtual memory systems
dynamically make a copy of virtual channel programs, creating
translated channel program). However, the standard A510 would take all
referenced data from mainframe memory (transferring it over network).
This worked for many things ... but would not work for the "looping"
argument to the "search" instruction. The point of this effort was to
preserve the IMS's group quarter second interactive response ... an
unanticipated side-effect was about a 10-15% total system thruput
because of reduced channel busy/contention (lots of channel processing
had been offloading into the A510 adapters) ... misc references:
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?

Towards the mid-80s, NSC created an enhanced remote device adapter
where the seek & search arguments could also be downloaded (supporting
CKD devices on HYPERChannel networks) called the A515. The A515 had
extended memory for complete copies of channel programs as well as
necessary processing for seek & search arguments.

One place that the A515 was used extensively was at NCAR For the Mesa
system ... which effectively implemented one of the early network
addressed storage (i.e. crays and other processors being able to do
direct transfers to/from ibm mainframe disk farm).

misc. ncar/a515 refs:
http://www.garlic.com/~lynn/99.html#146 Dispute about Internet's origins
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#78 Free RT monitors/keyboards
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001l.html#34 Processor Modes

misc. other hyperchannel & hsdt refs:
http://www.garlic.com/~lynn/subtopic.html#hsdt

Turns out in the late '70s, I was wondering around the SJ plant site
... seeing how I could get access to early processor models. Turns out
that initial processors went to the processor engineers ... and the
2nd processors went to the disk engineers.

The bldg. 14 & 15 machine rooms had disk "test cells" (secure steel
cages with combination locks, inside secure machine rooms, inside
secure buildings, inside secure plant site) containing "engineering
devices" undergoing R&D. There was complex switch setup since normal
operation of a single test-cell under MVS had a MTBF for MVS of 15
minutes .... so test-cells were connected one at a time to a processor
and special stand-alone code was used to drive the devices (some
FRIEND based). So, I decided if I could totally rewrite the kernel I/O
supervisor so it absolutely wouldn't crash ... SJ could migrate from a
scheduled stand-alone environment ... to any number of concurrent
test-cells operational under an operating system. The benefit to the
engineers was that they could now have a dozen test-cells working
concurrently ... instead of one at a time. The benefit to me was that
even with a dozen concurrent test cells ... the processor utilization
was less than one percent ... which met that there was all sorts of
interesting things I could think of doing with the other 99% of the
processors.  random refs:
http://www.garlic.com/~lynn/subtopic.html#disk

The downside ... was when problems occured ... I would get called
since they would first blame it on "my" operating system. Turns out
mostly what i encountered when i went over were engineering hardware
problems. This in turn led to two developments:

1) I got asked to all of these POK/SJC things between the
processor/channel engineers and the disk/controller engineers. when I
asked why I was being asked one of the engineers explained that most
of the senior engineers that previously oversaw this sort of stuff had
left in the mid-70s (the SJC senior engineers appeared to have been
the core of non-IBM disk efforts, various vendor IBM plug compatible
disk efforts, and various things like floppy and small disk startups).

2) I got to complain loadly about CKD being a 1960s paradigm and I
would write the software for a 1980s paradigm if the engineers would
build it for me. That was part of the problem where STL quoted $26m
for effectively "FBA" support for VTOC & PDS ... eliminating the CKD
(multi-track) search loop.

somebody tells this joke that i use to work 1st shift in
research/bldg.28, 2nd shift in engineering/bldg14&product-test/bldg15,
and 3rd shift in STL/bldg90.

Note this was still pre-DB2 ... I had helped do the technology
transfer from research on System/R to Endicott for SQL/DS. Baker had
yet to do the technology transfer from Endicott to STL for DB2 (so STL
was still mostly IMS, access methods, and misc. other stuff). It is
interesting that System/R went all the way to endicott (upstate NY)
and back to STL ... when research/28 and STL/90 were only ten miles
apart.

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

The demise of compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The demise of compaq
Newsgroups: comp.os.vms,comp.arch,comp.sys.intel,alt.folklore.computers
Date: Thu, 03 Jan 2002 22:06:54 GMT

jeffj@panix.com (Jeff Jonas) writes:

I have hurt feelings about the way IBM connectivity evolved
since I worked for related companies.
AT&T Teletype made IBM compatible terminals and controllers that we used
extensively internally, yet few folks outside of AT&T were brave enough
to use non-IBM terminals since IBM was apparently very harsh and
downgraded service to folks with mixed venders.

as an aside ... besides the issue with middleware and SAA ... the
communication division didn't particular like me.

as an undergraduate, there were four of us that built our own IBM
controller (reverse engineered channel protocol, built wire-wrap
channel attachment board, etc); it was a replacement for the 2702
terminal controller and is also credited with originating the
ibm plug-compatible controller (PCM) business, misc. refs:
http://www.garlic.com/~lynn/subtopic.html#360pcm

another in the late '80s was I was also trying to do a project that
would port a pu4/pu5 emulator to a rios/power processor; it would
have had 10times the performance, 10times the function, 1/10th the
cost, 10times the availability, etc of the communication division's
37x5 boxes (and would have also helped with distributed/network access
to the backend disk farms):
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#70

and about the same time, I also did the RFC1044 implementation and was
"tuning" the thruput at cray research between a Cray and a 4341-class
processor so that it was running at 4341 hardware channel speed
(1mbyte/sec) ... using a nominal amount of the 4341.  By comparison,
the communication division wanted to see that TCP thruput was less
than LU6.2 thruput ... i.e. the base non-RFC1044 support got about
44kbytes/sec and would consume nearly a full 3090 processor).
http://www.garlic.com/~lynn/subtopic.html#hsdt
http://www.garlic.com/~lynn/internet.htm

speaking of AT&T ... I had helped supply a customized operating system
to AT&T longlines in the 70s ... into which it effectively
disappeared.  Nearly ten years later the IBM branch office tracked me
down (in a completely different job) to try and help AT&T get off the
kernel. the operating system continued to run on new generation of
processors for nearly ten years ... but finally a processor came out
which the modified operating system wouldn't automatically migrate to
... which met that IBM wasn't going to sell longlines new processors
unless something could be done about the operating system.

random longlines refs:
http://www.garlic.com/~lynn/95.html#14 characters
http://www.garlic.com/~lynn/96.html#35 Mainframes & Unix (and TPF)
http://www.garlic.com/~lynn/97.html#15 OSes commerical, history
http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001f.html#3 Oldest program you've written, and still in use?
http://www.garlic.com/~lynn/2002.html#4 Buffer overflow

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

A terminology question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A terminology question
Newsgroups: sci.crypt
Date: Thu, 03 Jan 2002 22:21:40 GMT

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

Are the terms 'covert channel' and 'subliminal channel'
equivalent or not? Thanks.

M. K. Shen

I'm note sure about subliminal ... it is possible that subliminal
channel can be a type of covert channel. I think submliminal implies
that you aren't aware of it ... whether or not it violates security
policy ... and covert is that it violates security policy even if you
are aware of it.

from:
http://www.garlic.com/~lynn/secure.htm

covert channel

(1) A communication channel that allows a process to transfer
information in a manner that violates the system's security policy. A
covert channel typically communicates by exploiting a mechanism not
intended to be used for communication. (2) The use of a mechanism not
intended for communication to transfer information in a way that
violates security. (3) Unintended and/or unauthorized communications
path that can be used to transfer information in a manner that
violates an AIS security policy. [AJP] (I) A intra-system channel that
permits two cooperating entities, without exceeding their access
authorizations, to transfer information in a way that violates the
system's security policy. (O) 'A communications channel that allows
two cooperating processes to transfer information in a manner that
violates the system's security policy.' (C) The cooperating entities
can be either two insiders or an insider and an outsider. Of course,
an outsider has no access authorization at all. A covert channel is a
system feature that the system architects neither designed nor
intended for information transfer:

'Timing channel': A system feature that enable one system entity to
signal information to another by modulating its own use of a system
resource in such a way as to affect system response time observed by
the second entity.

'Storage channel': A system feature that enables one system entity to
signal information to another entity by directly or indirectly writing
a storage location that is later directly or indirectly read by the
second entity.

[RFC2828] A communication channel that allows a process to transfer
information in a manner that violates the system's security
policy. [TCSEC] A communications channel that allows a process to
transfer information in a manner that violates the system's security
policy. A covert channel typically communicates by exploiting a
mechanism not intended to be used for communication. [TNI] A
communications channel that allows two cooperating processes to
transfer information in a manner that violates the system's security
policy. [AFSEC][NCSC/ TG004] Any communication channel that can be
exploited by a process to transfer information in a manner that
violates the system's security policy. [IATF] The use of a mechanism
not intended for communication to transfer information in a way which
violates security. [ITSEC] Unintended and/or unauthorized
communications path that can be used to transfer information in a
manner that violates an AIS security policy. [FCv1] (see also overt
channel, security-compliant channel, storage channel, timing channel,
channel, exploitable channel, security, threat) (includes covert
storage channel, covert timing channel)

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

A terminology question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A terminology question
Newsgroups: sci.crypt
Date: Thu, 03 Jan 2002 23:01:06 GMT

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

From all literatures cited in this thread till now, it
seems to me to be the case that a subliminal channel is
a (special case of a) covert channel, if one wants to
stress a difference (nuance) between the terms, though
e.g. RSA ascribes to them the same meaning. Anyway, I
suppose that it is not a big sin, if one chooses, for
example, to follow Schneier or RSA in the use of the
words for crypto contexts.

M. K. Shen

simple, just make all channels not known (subliminal) to the security
officer, a violation of security policy (covert). security officers
are big on banning all things that they don't know about and only
permitting things that they explicitly permit (aka you can only do
what i tell you that you can do ... as opposed to you can do anything
that you are not forbidden to do).

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

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 03 Jan 2002 23:54:01 GMT

"Stephen Fuld" writes:

Yes - But think of "wasting" a few hundred bytes of main memory to keep the
names and addresses of the few most popular programs.  Perhaps that could
have eliminated many of the searches for program loading.

a similar ... but totally different scenario was linear searching of
some in-core structures.

When I first saw the CP/67 operating system ... it had very
significnat processor overhead. Over that fist year (i was still
undergraduate) I did some significant pathlength optimizations
... reducing overall kernel processing by up to 80% for many common
things ... and some selected pathlengths by possibly 100 times with
things like "fastpath" ... random ref:
http://www.garlic.com/~lynn/94.html#18

with such significant reduction ... other/new areas of the kernel was
starting to dominate kernel processor time. One of the major areas was
kernel storage management/allocation. Basically, storage was ordered
on a chain by real memory address. When storage was made released, it
was put into the chain based on its real memory address (as well as a
check made to see if adjacent storage locations could be combined into
large storage block). When requesting a block of storage, the chain
was scanned for block with exact match ... and if that failed, the
first larger block was taken (and appropriately adjusted).

This process was now starting to consume 20 percent or more of total
kernel processor utilization (chain lengths frequently of 300-400
elements ... this is analogous to the FINWAIT issue recently mentioned
in another thread in this NG (although the FINWAIT scanning could
hit 99 percent of total cpu utilization):
http://www.garlic.com/~lynn/2002.html#3 The demise of compaq

The 360/67 had a special RPQ (I believe first specified by
lincoln labs) instruction called the Search List (mnemonic SLT).

random refs:
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000d.html#47 Charging for time-share CPU time
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001d.html#23 why the machine word size is in radix 8??
http://www.garlic.com/~lynn/2001d.html#33 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#15 IBM 9020 FAA/ATC Systems from 1960's

The search list instruction could chain follow and perform various
kinds of matching ... and would do it 2-3 times faster than tightly
coded assembler loop (i.e. 5-10 percent intead of 20 percent of kernel
processing).

However, around 1970, the CSC group invented storage subpools. Storage
of certain characteristics were attempted to be allocated from LIFO
subpool chain ... which could be performed in around a total of 14
instructions. This reduced the storage management from around 20
percent (growing to 30 percent as loads increased) to typically less
than five percent and eliminated the need for the linear search (and
the need for the SLT instruction to do fast linear searching).

Later when a couple of us were working on migrating kernel code into
machine hardware ... for CP/67 succesor VM/370 ... we measured

fre+5a8                      73628   132     3.77
   'FRET'
fre+8                        73699   122     3.47
   FREE

... "FRET" is kernel storage deallocation ... "FREE" is kernel storage
allocation for total of 3.77+3.47 or 7.24 percent of kernel processor
time. ref:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist.

mainframe got an even more complex support with luther's radix partition
tree/sort hardware instructions:
http://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#20 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/2001.html#2 A new "Remember when?" period happening right now
http://www.garlic.com/~lynn/2001h.html#73 Most complex instructions

note see the URL pointer in the "most complex instructions" posting
...  earlier URL references for the mainframe instructions "principle
of operations" pointed to server in POK ... I think the official
server is now a server in boulder.

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

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 03 Jan 2002 23:59:57 GMT

"Stephen Fuld" writes:

I understand.  Not to mention that if IBM had made the interface more
straight forward, then it would have been easier to PCM and you would have
had more competitors (the Ellen Hancock scenario again).  But I do wish you
had succeeded :-).

but they also blame for for the PCM stuff in the first place
http://www.garlic.com/~lynn/subtopic.html#360pcm

some speculation that the whole pu4/pu5 interface is the way it is because
of having originated plug compatible controller business (reference
recent "The demise of compaq" thread postings going on concurrently in
same n.g.)

note that STK has since bought NSC.

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

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 04 Jan 2002 02:54:38 GMT

"Stephen Fuld" writes:

Is that the Com FE you have mentioned?  I have heard several stories about
the first storage PCM.  I don't know who was first there.

i'm not positive but the first disk/controller/storage PCM may have
been memorex ... one of the engineers ... among other things was
responsible for a lot of the 2321 datacell ... went to memorex to do
PCM disk & controller. He and the business guy then left and formed
BLI (& hired epstein) to do the first relational database engine (aka
attach to ibm channel & controller that did relational database disk
searches).

when epstein left (teradata and then founding sybase) BLI recruited
somebody i was working with who tried to talk me into going with him.

there has been this joke in the valley about there only be 200 people
total in the business ... they just keep moving around.

random refs:
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?
http://www.garlic.com/~lynn/2002.html#0 index searching

random data cell refs:
http://www.garlic.com/~lynn/2000.html#9 Computer of the century
http://www.garlic.com/~lynn/2000b.html#41 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)

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

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 04 Jan 2002 22:39:24 GMT

misc extracts from various web resources ....

http://www.disktrend.com/disk3.htm

But IBM wasn't standing still. In 1961, having joined IBM right out of
school 10 years earlier, Alan F. Shugart took over a project called
the Advanced Disc File which, like its parent, the RAMAC 350, packed
fifty 24-inch disks. But now, for the first time, self-acting slider
bearings made it possible to have a head for each disk surface; it was
no longer necessary to move heads up and down to reach different
disks. This development did away with the need for an air supply. It
also improved areal density and access time. A lot.

On Jan. 25, 1968, a month after the Dirty Dozen left IBM, Shugart was
promoted to the position of product manager for direct-access storage
devices at IBM. He reported to Vic Witt, as had the Dirty Dozen. But
in the summer of 1969, Memorex hired Shugart to take over its young
disk-drive operation as vice president of product development.

After Shugart joined Memorex, a large number of IBMers followed. A
very large number. Some estimates had the number at 200. Recruiting
was casual. Nursing a beer or two, Shugart would hang around the
eatery where many IBM engineers would lunch. Casual old-buddy
greetings would ensue and, pretty soon, the disk-drive staff at
Memorex would grow while that at IBM would shrink. Shugart was
assisted by a telephone.

By 1971, Shugart was responsible for all product development at
Memorex. In January 1973, he left to found Shugart Associates. In
December 1974, impatient with the absence of products ready for the
market place, the venture capitalists who funded Shugart Associates
fired Alan Shugart. Or maybe he quit.

The difference, Shugart said later, was about five microseconds.
Shugart was replaced by Don Massaro, a cofounder and director of
engineering. Under his leadership, the company brought out the first
5.25 inch floppy drive in 1976. A few years later, Xerox bought the
company and closed it down within three years.

In the late 1950s, IBM was developing a disk drive called RAMAC, in
order to support a software application for storing data about
manufacturing processes. The first disk drives were huge: They stood
vertically on end, were three feet in diameter, and required pumped
air pressure to spin. But they only stored about 5,000 characters
what we would refer to as 5K bytes today.

http://www.mhhe.com/cit/concepts/oleary/olc/chap5/compulore5.html

Shugart, who joined IBM right out of college, was assigned the
Advanced Disc File project, trying to squeeze more efficiency out of
RAMAC's progeny, now down to only two feet in diameter. He was
responsible for perfecting the technology that used multiple disk
platters and multiple read/write heads. He succeeded, and in 1968 was
promoted to product manager for direct-access storage devices at IBM.

By this time he had became a much-sought-after disk storage engineer,
and Memorex hired him as vice president of disk drive development. In
1971, he invented the first floppy disk, eight inches in diameter,
with a storage capacity of 128K (today's 3.5in floppy is over ten
times that amount). The first practical use for the disk was with the
IBM Displaywriter, a huge dedicated (single-task) word processing
machine.

Restless to see the floppy disk drive succeed, Shugart left Memorex in
1973 to found Shugart Associates. However, he was forced out a year
later, while his company went on to develop and introduce the first
5.25 inch floppy drive in 1976. Unable to stay away from the storage
industry, in 1979 he founded Shugart Technology, with Finis Conner, to
manufacture hard-disk drives. The company was soon renamed Seagate
Technology, which became a $9 billion company and remains in business
to this day. Finis Conner went on to launch Conner Peripherals.
Interestingly, Seagate and Conner (re)merged in 1996.

http://moore.sac.on.ca/NORTHERNLYNX/northern%20lynx/hdrive.htm

In 1970, IBM expanded the computer's ability to store data when it
introduced the memory disk, an 8-inch plastic disk designed for the
IBM Merlin 3330 with a capacity of 100Mbytes. Now called the floppy
disk, this memory disk could be removed from the computer making it
possible, for the first time, to move information from one computer to
another. Alan Shugart is credited with inventing the floppy. In the
summer of 1969, Shugart left IBM, with around 200 other IBM employees
following him, for the position of vice-president of product
development at Memorex. In 1973, Shugart left Memorex to create
Shugart Associates and develop the first 5.25-inch floppy drive for
Wang Laboratories. In 1979 Shugart and Finis Conner founded Shugart
Technology which changed its name in 1980 to Seagate
Technology. Seagate Technology introduced the first non IBM hard disk
in 1980 as the ST506 with a 5.25 inch drive, stopper motor and a
capacity of 5Mbytes. Soon other companies, including Sony, in 1981,
with the first 3.5 floppy drive and Rodime, in 1983, with the first
3.5 rigid disk drive, were producing hard disks.

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

Infiniband's impact was Re: Intel's 64-bit strategy

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 05 Jan 2002 18:16:10 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

You can eliminate the problem of latency for large transfers by
using the techniques I was mentioning earlier, as was done on MVT
and similar systems of the 19760s and 1970s.  The only practical
solution for small ones is to have compound interfaces; e.g. MPI

one aspect that affected everybody in the country ... was that the IBM
check-sorter required low-latency, nearly real-time response from the
processor. Because of some of the switch to virtual storage and the
extra layer between real i/o and the application ... there was some
non-standard operating system tweaking that had to be done in the "VS"
versions (i.e. MFT->VS1; MVT->VS2).

there is the story of Federal Express getting started by picking up
checks from all over the country in the evening and flying to
nashville for a country-wide check sort ... and then the return
flights back after the sort (things like bill-payment checks mailed to
out of area addresses, cleared thru the payor's bank ... and having to
find their way back to payee's bank). I believe flights had to arrive
by 10 or 11pm and then they were back in the air around 2am.

refs:
http://www.garlic.com/~lynn/99.html#155
http://www.garlic.com/~lynn/99.html#136a

there were also local bank sorting for intra-region exchanges (checks
not needing to be sent to a national sort).

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

Buffer overflow

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Buffer overflow
Newsgroups: sci.crypt
Date: Sat, 05 Jan 2002 21:07:00 GMT

two buffer-overflow items in today's posting to comp.risks

http://www.csl.sri.com/users/risko/risks.html
http://www.csl.sri.com/users/risko/risks.txt

 See last item for further information, disclaimers, caveats, etc.
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.84.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents:

 See last item for further information, disclaimers, caveats, etc.
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.84.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents:

 Peak time for Eurorisks (Paul van Keep)
 More Euro blues (Paul van Keep)
 ING bank debits wrong sum from accounts (Paul van Keep)
 Euro bank notes to embed RFID chips by 2005 (Ben Rosengart)
 TruTime's Happy New Year, 2022? (William Colburn)
 Airplane takes off without pilot (Steve Klein)
 Harvard admissions e-mail bounced by AOL's spam filters (Daniel P.B. Smith)
 Risk of rejecting change (Edward Reid)
Security problems in Microsoft and Oracle software (NewsScan)
Buffer Overflow security problems (Henry Baker, PGN)
 Sometimes high-tech isn't better... (Laura S. Tinnel)
 When a "secure site" isn't (Jeffrey Mogul)
 Abridged info on RISKS (comp.risks)

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

Younger recruits versus experienced veterans ( was Re: The demise of compa

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Younger recruits versus experienced veterans  ( was Re: The demise  of compa
Newsgroups: alt.folklore.computers
Date: Sat, 05 Jan 2002 21:21:32 GMT

Brian Inglis writes:

If at that time we had the source control systems and id strings
in the binaries that we have available now, I could have just
emailed them the file name and line number to fix, instead of
calling the programmers, asking them where they kept the latest
source code for their programs, which module used arrays, telling
them they weren't checking their array bounds, and they were set
too low for production work anyway.
Most of them thought ten was a big enough size for all arrays.

there has been a buffer overflow thread running in sci.crypt
newsgroup.  One of my past comments was that when we did vulnerability
analysis as part of our HA/CMP project ... prediction was that
C-language environments would have 10 times (to possibly 100 times)
higher occurance of buffer overflow problems & exploits than what we
had been used to in other environments (rough assumption given similar
applications & similar programming skill levels .... purely
characteristic of the C-language environment ... but awareness of the
problem might lead some to exercise caution and compensating
procedures).

there are a couple items on the buffer overlow & array bound checking
subject in posting today to comp.risks
http://www.csl.sri.com/users/risko/risks.html
http://www.csl.sri.com/users/risko/risks.txt

namely
 Security problems in Microsoft and Oracle software (NewsScan)
 Buffer Overflow security problems (Henry Baker, PGN)

misc. cluster & ha/cmp related postings
http://www.garlic.com/~lynn/subtopic.html#hacmp

general exploit, fraud, & risk postings
http://www.garlic.com/~lynn/subtopic.html#fraud

some random past postings
http://www.garlic.com/~lynn/aadsm9.htm#cfppki10 CFP: PKI research workshop
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
http://www.garlic.com/~lynn/99.html#219 Study says buffer overflow is most common security bug
http://www.garlic.com/~lynn/2000.html#30 Computer of the century
http://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001d.html#58 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
http://www.garlic.com/~lynn/2001n.html#72 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#76 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#84 Buffer overflow
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#4 Buffer overflow
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq

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

"blocking factors" (Was: Tapes)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "blocking factors" (Was: Tapes)
Newsgroups: alt.folklore.computers
Date: Sun, 06 Jan 2002 00:50:51 GMT

as was pointed at there was a little memory leakage (inter record gap
size) over 20 years.

so from:
http://www.digital-interact.co.uk/site/html/reference/media_9trk.html

....

Because these drives were originally start stop drives they needed
space between data blocks in order to be able to do this. This space
is known as the inter block gap (ibg) and is 0.6 inches for 800/1600
and 0.3 inches for 6250. This need for an ibg caused the tape usage to
be very inefficient when used with small block sizes.

...

The following chart gives an indication of the capacities of using a
standard 2400 ft tape with varying block sizes.

          512 Byte   1 Kbyte    2 Kbyte   4Kbyte    8Kbyte    Gapless
800 bpi    11.6 Mb   15.3 Mb    18.3 Mb    20.2 Mb   21.4 Mb   22.6 Mb
1600 bpi   15.5 Mb   22.5 Mb    30 Mb      36.1 Mb   40.2 Mb   45.3 Mb
6250 bpi   35.1 Mb   58.6 Mb    87.6 Mb   116.8 Mb  140.7 Mb  176.8 Mb

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

index searching

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 06 Jan 2002 01:25:59 GMT

"Stephen Fuld" writes:

Huh?  What about the 2311 and 2314?  I know they wren't floppies, but
could,t they be used "to move information from one computer to another" and
didn't they predate 1970?

wording of some of those web histories leaves something to be desired.

here is old table of 2305, 2314, 3310 (fba), 3330 (-11), 3350, 3370 (fba) & 3380
http://www.garlic.com/~lynn/95.html#8

some model numbers:
http://www.garlic.com/~lynn/2001l.html#63

I was doing some searching for 2311 reference and ran across
"Computing at Columbia Timeline"
http://www.columbia.edu/acis/history

which has a number of interesting things with pictures
1301 disk:
http://www.columbia.edu/acis/history/1301.html
totally unrelated 407:
http://www.columbia.edu/acis/history/407.html
& 360/91
http://www.columbia.edu/acis/history/36091.html
2301 "drum"
http://www.columbia.edu/acis/history/drum.html
2311 disk drive (foreground):
http://www.columbia.edu/acis/history/2311.html
2321 datacell (background):
http://www.columbia.edu/acis/history/datacell.html

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

Buffer overflow

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Buffer overflow
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 06 Jan 2002 17:14:09 GMT

"Douglas A. Gwyn" writes:

Actually who gets the blame in my book are the vendors who just
slapped their own name on the system without fixing the problems.

with the reference to vulnerability analysis in the late '80s in
support of HA/CMP .... and identifying buffer length issues as major
vulnerability in C programming environment ... one of the issues we
looked at was Reno & Tahoe (at that a large number of vendors were
using as their tcp/ip support)

a little more HA related ... minor other things

1) we would have like to have any application specify a "trap" to catch all
ICMPs that came back associated with any packet they sent out (possibly
as much a protocol issue as a implementation issue). Not having that made it
easier for various things including DOS attacks
http://www.garlic.com/~lynn/99.html#48 Language based exception handling

2) one of the things we wanted in as part of HA was ip-address
take-over.  Now, ARP cache nominally has a time-out so that clients
would eventually re-ARP periodically and get (the new)MAC
address. However, there was a bug in the Tahoe/Reno code in the IP
layer just before calling the ARP lookup where it kept a one-deep
cache of the last MAC address. If the previously used IP-address was
the same as the current IP-address, it would bypass calling ARP-lookup
and use the saved MAC address (this didn't have a time-out). There
turns out to be fairly large number of client configurations on small
nets where 99.9 percent of traffic is client to the same server ... or
clients on subnet where all their traffic goes thru a router. As a
result, all traffic was for the same IP-address so the IP-layer never
directly called the ARP code (where MAC addresses did time-out)
... and there was no management code &/or time-out for the single
saved MAC address. For some period, it seemed like 99.99 percent of
all deployed machines in customer shops had that "bug" (because it
seemed like nearly every vendor in the universe was using Tahoe/Reno
for their IP implementation).
http://www.garlic.com/~lynn/94.html#16 Dual-ported disks?
http://www.garlic.com/~lynn/96.html#34 Mainframes  Unix

3) marginally related was the problem of getting browser vendors
to include support for multiple A-records. we got changes to servers
that interfaced to payment gateway ... but it was harder problem
getting browswer vendors (even tho tahoe/reno clients did support
multiple A-records ... but unfortunately predated the advent of
browser clients
http://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#16 Old Computers
http://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)

random refs:
http://www.garlic.com/~lynn/subtopic.html#hacmp hacmp
http://www.garlic.com/~lynn/subtopic.html#fraud fraud, exploits, vulnerabilities

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

Buffer overflow

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Buffer overflow
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 06 Jan 2002 22:29:55 GMT

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

First, "traps", "interrupts", and other asynchronous events always
ask for trouble and must be avoided when at all possible.  Without
more care than practice (as opposed to theory) shows is reasonable to
expect from most programmers, asynchronous stuff produces too many
difficult to diagnose bugs.

Second, connected sockets do get informed of appropriate ICMP errors
in the BSD code.  Sockets that are not connected don't, because the
only clue that a system receiving an ICMP message has is a string of
bytes that supposedly came from the packet that caused the error.
The BSD code looks for a local socket with a destination address
including port number that matches the bytes in the ICMP message, and
arranges that the next system call on that socket will be told of the
error.  Sockets that are not connected don't hear about ICMP errors.
One practical reason is that the system has no record of which sockets
might have sent the packet the generated the ICMP error.  Note that
more than one socket might have been responsible for the packet the
caused the ICMP error message, because ICMP error messages do not
contain enough information to uniquely identify the sending socket.
Another reason is that by the time an ICMP message arrives, the
responsible socket might have sent several other UDP datagrams, and
an API for telling the application "the operation you did 37 milliseconds
ago had this problem" (or equivalent) is a can of worms experienced
application writers and operating system designers do not want to open.

Third, ICMP error messages are not authenticated, and even when not
forged, should almost always be ignored.  The classic example of the
need to ignore ICMP errors is that Unreachables for TCP packets should
be ignored at least when the state machine is not in ESTABLISHED and
perhaps in all states.  There are very few ICMP messages that are
not best ignored.

the issue is somewhat the difference between straightline application
development and industrial strength services. Many of the batch
derived platforms had extensive, optional trap & error handling
semantics that few "normal" applications used but many of the
industrial strength services would make extensive use of. Batch
oriented systems tended to evolve more sophisticated services in this
area because their applications already had the sense of running
"unattended" ... and any industrial strength service application
tended to have a design point of automating as much of the processing
(including exception handling) as possible.

As referenced earlier ... one of the largest financial settlement
networks attributed 100% availability for several year period to two
things 1) a form of geographic distributed clustering (three site
replication) and 2) automated operator. In a batch oriented,
automated service ... humans providing machine care & feeding were
called operators ... and to the extent that a service application
interacted with humans for operational issues ... it was these
operator/humans (even large scale "online" services that might have
tens of millions of human service interactions/day ... say like ATM
cash machines, the end-user/consumer interactions weren't classified
as operational interactions ... just simply service interactions).

In any case, as other forms of failures were eliminated and/or
automagically handled ... human mistakes started becoming the number
one cause of application service failure/outages. automated operator
methodology started provided expert-type systems that attempted to
programmatically handle as many of the "operator" services & decisions
as possible.

In any case, while IP had to follow various kinds of heuristics to try
and figure out how to push ICMP packets up the protocol stack
... other types of systems handled the function by allowing things
like an opaque handles/tags to be carried in both outgoing packets and
included in responses. The service/implementation/stack could then use
the opaque handle for origin identification purposes ... something
that IP sort-of attempts to approximate by looking for string matches.

In other network environments, various large scale service
applications would implement extremely sophisticated (possibly
domain-specific) error, diagnostic and recovery processes. Part of the
issue was whether or not the TCP/IP implementation and protocol had a
design point for

1) the straight-forward, simple application environment with a huge
point-to-point anarchy ...

and/or

2) the high-end industrial strength, automated service application
environment ... with highly asymmetric implementation requirements ...
the client-side end could look similar to #1, but the server end could
involve radically different implementation and highly sophisticated
technology.

frequently it is easy to subset #2 for the simpler application
environment (i.e. the asymmetric characteristic with the client-end
being radically simpler than the service server operation).

This is part of the claim that the effort to taking a normal,
straightline, high quality application and turning it into an
industrial strength service application may require 4 to 10 times more
code than in the base application (and possibly significantly more
complex code than in the base application since it is at least
targeted at addressing many of the really hard exception conditions).

... aka claim could be made that 1) interactive-derived platforms, 2)
most C language environments, and 3) much of TCP/IP were not really
targeted at the high-end, industrial strength, highly automated
service oriented application delivery market.

Many of the industrial strength high-end online services have been
platformed on various legacy platforms because of various of the
industrial automation facilities. Even some of the higher-end web
services have migrated to such platforms.

As an aside note ... there have been numerous proposals over the years
that ISP infrastructures (at all levels) discard incoming packets with
origins not consistent with their routing tables (i.e. most probably
spoofed packets). Possibly part of the justification for not doing
that is that most environments have other compensating procedures for
dealing with spoofed packets. However, from an industrial strength
service application, if it the frequency of spoofed packets were
reduced by even 95 percent, it would make their heuristics work much
better.

In general, many of the arguments seem to be that there are so many
things that are effectively anarchy that we should ignore them ... and
there is no point in fixing any of the anarchy because everybody
ignores them anyway.

misc. past IP spoofing postings:
http://www.garlic.com/~lynn/aadsm2.htm#integrity Scale (and the SRV record)
http://www.garlic.com/~lynn/aadsmore.htm#killer1 Killer PKI Applications
http://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#16 Root certificates
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

random industrial strength refs:
http://www.garlic.com/~lynn/aadsm2.htm#architecture A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsmail.htm#parsim parsimonious
http://www.garlic.com/~lynn/aepay6.htm#erictalk2 Announce: Eric Hughes giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/ansiepay.htm#x959bai X9.59/AADS announcement at BAI
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/94.html#44 bloat
http://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
http://www.garlic.com/~lynn/96.html#31 Mainframes & Unix
http://www.garlic.com/~lynn/96.html#32 Mainframes & Unix
http://www.garlic.com/~lynn/97.html#15 OSes commerical, history
http://www.garlic.com/~lynn/98.html#4 VSE or MVS
http://www.garlic.com/~lynn/98.html#18 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/98.html#51 Mainframes suck? (was Re: Possibly OT: Disney Computing)
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#107 Computer History
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
http://www.garlic.com/~lynn/2000.html#10 Taligent
http://www.garlic.com/~lynn/2000.html#22 Computer of the century
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2000e.html#48 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
http://www.garlic.com/~lynn/2001b.html#25 what is interrupt mask register?
http://www.garlic.com/~lynn/2001b.html#60 monterey's place in computing was: Kildall "flying" (was Re: First OS?)
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001c.html#16 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#56 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001h.html#1 Alpha:  an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
http://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
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/2001l.html#47 five-nines
http://www.garlic.com/~lynn/2001n.html#11 OCO
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
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

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

ICMP Time Exceeded

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ICMP Time Exceeded
Newsgroups: comp.security.firewalls
Date: Sun, 06 Jan 2002 22:55:32 GMT

Lars M. Hansen writes:

ICMP timeouts indicates that a packet destined for some IP address could
not reach its destination because the TTL was exceeded. This is often
caused by router outages and/or routing loops.

It is possible that the request didn't come from you at all, but from
someone else forging your IP as the source IP...

using traceroute for the address lets you quickly see if there are any
"normal" router loops. They have been much less frequent in the past
couple years ... various backbone sites use to have them frequently.

somebody forging your origin address and setting the TTL/hop-count to
4-5 ... with the size of the internet these days ... hops are
frequently at least 10 ... and standard software will typically set
the outgoing TTL hop count to somewhere between 30 and 60. If somebody
forged an outgoing packet with your origin address and a TTL hop-count
of just a few ... possibly enuf to get it several hops away from their
location before the hop-count decremented to zero and an ICMP error
packet was generated with your origin address.

TTL ... time-to-live is slight misnomer ... it isn't really a time
value, it is a hop-count ... i.e. the number of intermediate
nodes/routers that the packet will pass through before it gives up.
Each node decrements the supplied count before sending it on. When the
count expires, an ICMP error packet is generated using the origin
address.

ISPs could go a long way to eliminating many of these types of things
if they rejected origin packets that didn't match their route tables
(if they get a incoming IP-packet from a dial-up account where the
origin/from IP-address is different than the assigned IP-address for
that port ... treat it as an fraudulent packet and discard it).

Note that traceroute takes advantage of the limited count feature by
sending out a series of packets with increasing hop counts
... purposefully getting back ICMP error packets from each node in a
path to a final destination. You recognize routing loops with
traceroute because intermediate nodes will be listed multiple times
... and the destination node is never actually reached.

RFC references:

2827
     Network Ingress Filtering: Defeating Denial of Service Attacks
     which employ IP Source Address Spoofing, Ferguson P., Senie D.,
     2000/05/16 (10pp) (.txt=21258) (BCP-38) (Obsoletes 2267)
3013
     Recommended Internet Service Provider Security Services and
     Procedures, Killalea T., 2000/11/30 (13pp) (.txt=27905) (BCP-46)
3168
     The Addition of Explicit Congestion Notification (ECN) to IP,
     Black D., Floyd S., Ramakrishnan K., 2001/09/14 (63pp)
     (.txt=170966) (Obsoletes 2481) (Updates 793, 2401, 2474)

for more detailed RFC index ... see
http://www.garlic.com/~lynn/rfcietff.htm

random refs:
http://www.garlic.com/~lynn/aadsm2.htm#integrity Scale (and the SRV record)
http://www.garlic.com/~lynn/aadsmore.htm#killer1 Killer PKI Applications
http://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#16 Root certificates
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights  and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights   and traffic enforcement
http://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
http://www.garlic.com/~lynn/2002.html#20 Younger recruits versus experienced veterans  ( was Re: The demise  of compa

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

Buffer overflow

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Buffer overflow
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 06 Jan 2002 23:11:31 GMT

Anne & Lynn Wheeler writes:

As an aside note ... there have been numerous proposals over the years
that ISP infrastructures (at all levels) discard incoming packets with
origins not consistent with their routing tables (i.e. most probably
spoofed packets). Possibly part of the justification for not doing
that is that most environments have other compensating procedures for
dealing with spoofed packets. However, from an industrial strength
service application, if it the frequency of spoofed packets were
reduced by even 95 percent, it would make their heuristics work much
better.

slightly related thread today in comp.security.firewalls
http://www.garlic.com/~lynn/2002.html#24 ICMP Time Exceeded

some RFC references from RFC index
http://www.garlic.com/~lynn/rfcietff.htm

RFC references:
2827
     Network Ingress Filtering: Defeating Denial of Service Attacks
     which employ IP Source Address Spoofing, Ferguson P., Senie D.,
     2000/05/16 (10pp) (.txt=21258) (BCP-38) (Obsoletes 2267)
3013
     Recommended Internet Service Provider Security Services and
     Procedures, Killalea T., 2000/11/30 (13pp) (.txt=27905) (BCP-46)
3168
     The Addition of Explicit Congestion Notification (ECN) to IP,
     Black D., Floyd S., Ramakrishnan K., 2001/09/14 (63pp)
     (.txt=170966) (Obsoletes 2481) (Updates 793, 2401, 2474)

and the "internet like anarchy" thread in comp.security.misc.
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights  and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights   and traffic enforcement
http://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow

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

Buffer overflow

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Buffer overflow
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 06 Jan 2002 23:34:27 GMT

Anne & Lynn Wheeler writes:

http://www.garlic.com/~lynn/2002.html#24 ICMP Time Exceeded

fumble finger
http://www.garlic.com/~lynn/2002.html#25 ICMP Time Exceeded
                                      ^^

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

Buffer overflow

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Buffer overflow
Newsgroups: sci.crypt,alt.folklore.computers
Date: Mon, 07 Jan 2002 03:54:05 GMT

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

On the contrary, industrial strength services that are genuinely
industrial strength avoid traps and other asynchronous mechanisms for
error handling.  Asynchronous mechanisms are always harder to deal
with, and not to put to fine a point on it, practically incomprehensible
to the canonical "COBAOL programmers" that write most supposedly
industrial strength code.  The naive sloppiness of the 4.2 BSD "student
code" was not good, but anyone who has seen much COBOL, RPG, PL/1,
and so forth knows it was absolutely wonderful compared to typical
"industrial strength" code.

Note that I wrote "traps" instead of "traps & error handling" on purpose
because I'm talking about one and not the other.

most online services have developed extensive trap & error handling
for their "industrial strength" operation ... again potentially 10 times
as much in the "service" code as in the base-line application.

There are huge number of baseline application written in all sort of
languages; Cobol, RPG, PLI, C, etc .... which have never gone beyond
the baseline stage.

Online &/or other types of application have had lots of industrial
strength hardening added ... including lots of stuff potentially
dealing with all sorts of activities ... many unpredictable and also
effectively asynchronously.

SNA had a totally different design point that TCP/IP. TCP/IP had a
networking design point ... SNA effectively for a long, long time has
been VTAM which is a terminal control program .... targeted at
managing tens of thousands of online terminals. There was some joke
about SNA

System        ... not a system
Network       ... not a network
Architecture  ... not an architecture

The closest thing that showed any networking capability was APPN
... and the "official" SNA group non-concurred with announcing
APPN. APPN was finally announced, but the resolution with the SNA
group was the announcement was done in such a way that there was no
indication that APPN and SNA were in any way, what-so-ever, related.

The other downside characteristic of VTAM is the interesting PU4/PU5
relationship ... which some has considered to be a re-action to a
project I worked on as an undergraduate ... supposedly the first
non-IBM, IBM-compatible controller (supposedly originating the IBM PCM
market).
http://www.garlic.com/~lynn/subtopic.html#360pcm

However, from the standpoint of industrial strength, just about any
significant event in the system or network could be "trapped" by an
application wishing to specify a sufficient level of control. This was
not to just simply monitor/managed individual events and/or state
operation with the individual events ... but could acquire a
sophisticated overall view of all components in the environment within
the context of an industrial-strength application ... say some
critical online service.  An example, in TCP/IP world would be to
register for all SNMP events that might be in anyway what-so-ever
related to providing an online service ... some query/response and
some decidedly asynchronous.

In the VTAM, terminal controller world ... they had the advantage of
lots of point-to-point links and various related telco-like
provisioning along with service-level-agreements. A major online,
industrial strength application supporting tens of thousands of
terminals would typically have a trouble desk that was capable of
doing first level problem determination within five minutes or less
(and correcting huge numbers of the problems).  Having point-to-point
links and telco provisioning and facilities significantly simplified
this compared to standard TCP/IP environment where it became
significantly more difficult to do end-to-end problem determination
... especially within five minutes.

Another example, is my wife and I worked on the original electronic
commerce server ... and part of the infrastructure was could it meet
similar objectives of all problems resolved and/or at least first
level problem determination be accomplished within five minutes.  Some
of it turns out to be protocol issues but a large part of it also
turned out to be assurance and infrastructure issues.

Many of the ISPs and backbones are only just now started to address
some of these infrastructure issues. An indiciation is a simple thing
in the mainframe online infrastuctures with Service Level Agreements
where there are detailed measurements with two-nines to five-nines
type of objectives and financial penalties for not meeting objectives.
There are also detailed issues regarding being able to diagnose and
resolved problems within specific periods.

In the case of the first commerce server, my wife and I eventually
went back and built an internet failure mode grid for every
(significant) application state against every kind of
internet/networking failure mode ... and required that the application
have a predictable result for every point in the grid ...  where
desired objective was automatic correction and/or recovery but if not,
have sufficient information that the problem could be identified
within five minutes. At the time, fairly standard internet server and
ISP would be spending 3-4 hrs and technician closing trouble ticketing
w/NTF ... aka no trouble found.

Now, the TCP/IP protocol hasn't changed a lot in the 6-7 years that we
worked on the first commerce server ... but to some extent the
infrastructure has ... but I don't think that most operations are
capable of taking a trouble call and doing first level problem
determination within the first five minutes. There was some amount of
things done in the IP protocol to do automatic recovery of certain
types of failures ... but the protocol and overall infrastructure is
still a way from many of the automated fault, diagnostic, and recovery
capabilities of even some 20-year old online services. Part of the
issue is some of the telco provisioning evolved based on end-to-end
circuit. Traceroute is a poor substitute for doing end-to-end
diagnostic compared to getting end-to-end SLA telco provisioning on
circuits.

random refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn4
http://www.garlic.com/~lynn/aadsm5.htm#asrn1

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

Buffer overflow

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Buffer overflow
Newsgroups: sci.crypt,alt.folklore.computers
Date: Mon, 07 Jan 2002 14:23:18 GMT

"Rupert Pigott" writes:

True, but you can run TCP/IP on top of FrameRelay, ATM or good old Leased
Lines. So in the TCP/IP world you have a broad spectrum of price points of
and Service Levels possible.

but how many ISPs will provide service level agreements for end-to-end
operation with penalty clauses for not meeting service, performance
and thruput objectives?

one