2002 Newsgroup postings (04/27 - 05/20) Lynn Wheeler

2002 Newsgroup Postings (04/27 - 05/20)

Blade architectures
WATFOR's Silver Anniversary
Computers in Science Fiction
Why are Mainframe Computers really still in use at all?
markup vs wysiwyg (was: Re: learning how to use a computer)
Black magic in POWER5
The HTML one-pixel dilation trick
income tax [was: Computers in Science Fiction]
The HTML one-pixel dilation trick
IBM MIcrochannel??
"Soul of a New Machine" Computer?
"Soul of a New Machine" Computer?
"Soul of a New Machine" Computer?
Secure Device Drivers
"Soul of a New Machine" Computer?
Security Issues of using Internet Banking
Why are Mainframe Computers really still in use at all?
Black magic in POWER5
Black magic in POWER5
Why did OSI fail compared with TCP-IP?
Security Issues of using Internet Banking
Why did OSI fail compared with TCP-IP?
Why did OSI fail compared with TCP-IP?
Why are Mainframe Computers really still in use at all?
Why did OSI fail compared with TCP-IP?
Why are Mainframe Computers really still in use at all?
Why did OSI fail compared with TCP-IP?
Security Issues of using Internet Banking
Why did OSI fail compared with TCP-IP?
Why did OSI fail compared with TCP-IP?
Why did OSI fail compared with TCP-IP?
Why did OSI fail compared with TCP-IP?
Secure Device Drivers
ESCON Distance Limitations - Why ?
Why did OSI fail compared with TCP-IP?
Why did OSI fail compared with TCP-IP?
The need for Meaningful Error Messages :)
Security Issues of using Internet Banking
Why is DSA so complicated?
"Soul of a New Machine" Computer?
Why did OSI fail compared with TCP-IP?
Why is DSA so complicated?
Why is DSA so complicated?
Why is DSA so complicated?
ibm icecube -- return of watercooling?
Why did OSI fail compared with TCP-IP?
Why did OSI fail compared with TCP-IP?
Why are Mainframe Computers really still in use at all?
Why did OSI fail compared with TCP-IP?
Why did OSI fail compared with TCP-IP?
Why did OSI fail compared with TCP-IP?
Timecard stupidity
Spotting BAH Claims to Fame
Are you sure about MONDEX?
Are you sure about MONDEX?
Multics hardware (was Re: "Soul of a New Machine" Computer?)
Siemens ID Device SDK (fingerprint biometrics) ???
Amiga Rexx
Amiga Rexx
Amiga Rexx
Amiga Rexx
GE 625/635 Reference + Smart Hardware
ibm icecube -- return of watercooling?
Pardon my ignorance,
Pardon my ignorance,
Real man-in-the-middle attacks?
Formal Classification for Security Topics
Coulda, Woulda, Shoudda moments?
Why are Mainframe Computers really still in use at all?
Digital signature
Pipelining in the past
Coulda, Woulda, Shoudda moments?
Biometrics not yet good enough?
Coulda, Woulda, Shoudda moments?
Coulda, Woulda, Shoudda moments?
Coulda, Woulda, Shoudda moments?
Pipelining in the past
Pipelining in the past
Is it safe to use social securty number as intranet username?
Coulda, Woulda, Shoudda moments?
Pipelining in the past
Multics reference in Letter to Editor
Future architecture
Questions about computer security
Questions on IBM Model 1630

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: alt.folklore.computers
Date: Sat, 27 Apr 2002 18:14:24 GMT

Kragen Sitaker writes:
And, of course, KeyKOS was a single-level-store OS for the 370 and SPARC, which I seem to recall was somewhat of a commercial success in the 1980s. It wasn't the case that everything had an address in KeyKOS, though; although you could map any data into your address space if you had the proper access to it (just as you can in Linux with mmap()), that wasn't the normal way of operating.

others for the 370 was RASP (simpson worked on before joining Amdahl) and Aspen (after he joined Amdahl). misc. refs
https://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.

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

WATFOR's Silver Anniversary

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: WATFOR's Silver Anniversary
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 28 Apr 2002 15:09:02 GMT

nospam@nowhere.com (Steve Myers) writes:
The big advantage of both WATFOR systems was their run time diagnostics. References to undefined variables, and array bounds checking, were godsends to both students and professionals.

Many people that ran WATFOR/360 remember those crazy error codes, though, and it was just as bad with WATFOR/7040. That was the biggest single problem with both systems.

typical student job was under second compile & run under watfor (on 360/65) ... one of the big wins for students with watfor runtime was things like uninitialized variables & bounds checking.

benchmark i presented at fall '68 SHARE in Atlantic City:
https://www.garlic.com/~lynn/94.html#17

standard gen'ed system in above took approx. 30seconds elapsed time to do 3step job ... essentially all job scheduler ... or about 10 seconds per job step. even with the r17 loader as standard ... with a single compile,linkedit, & go per student job that would still be around 11-12 seconds plus per student job.

fortran g compile was something like 10 times slower than watfor (but execution was faster). majoritqy of student jobs were compile ... first a very large percentage didn't even make it to run-time because of compile-time errors, second ... the watfor bounds check & uninitialized variables terminated the program very early. even with a smart loader handling multiple student jobs per job scheduler pass ... there was still extensive disk i/o reloading fortran g compile (at least half dozen different pds members) and link-edit accessing the fortran run-time library (which would have to be done per every student job).

watfor job step would load the compiler/runtime into memory in the initial 10 second job step ... and then blow threw 100 student jobs in a couple seconds (15 seconds or less total elapsed time, including job scheduler & watfor compiler/runtime).

with the optimized sysgen that I showed in the above ... job scheduler and other elapsed time processing was speeded up by over a factor of over two times ... 12 seconds for three step job (instead of 30seconds) ... which resulted in around 4 seconds for watfor compiler & runtime load and then blow thru 100 student jobs in less than additional five seconds ... say 8 to 9 seconds elapsed time for 100 typical student jobs. It wasn't until you got to some of the higher level courses that runtime elapsed time came close to exceeding compile elapsed time ... at that point you saw some cross-over to fortran g.

the problem with optimized sysgen was that normal PTF activity would update/replace PDS member ... aka at the end of allocated PDS space allocation ... rather at carefully positioned. 4-5 months of normal PTF activity would increase the carefully optimized 12 seconds to 20 seconds elapsed time or more for 3step job scheduler processing.

later fortran H came along that was a really heavy weight compile time ... but saw some significant runtime reductions for big programs. then there was fortran Q ... internally, which was an enhanced fortran H ... done by the guy at PASC also responsible for the APL\CMS microcode on the 370/145 (and some number of other projects). fortran Q enhancements were eventually released as fortran HX product.

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

Computers in Science Fiction

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Sun, 28 Apr 2002 17:27:51 GMT

jmfbahciv writes:
Oh, no. That's not how I see it. I gave a talk about my USAGE project to a customer one time. He wanted to know if the data capture was real time. My answer, of course, was no. He got real upset (much to the consternation of the salesman sitting in the meeting). However, the saleman finally figured out that the customer and I had completely different definitions of realtime. My definition had to do with the realtime clock that could be an option on the CPU. The customer's definition was based in IBMese. I never did find out what that was because the salesman said that he'ld explain once I was out of the room...

Hint...Lynn? :-)

note that starting with 370 in the early 70s there was real-time TOD clock that was 64 bits, the 33nd bit was just slightly over a second (epoch slightly over 130 years ... originally epoch was suppose to start first day of the last century ... which carried well into this century, but the epoch is 1/1/70 ... so it carries it to the next century). Most machines tic'ed the clock in real time at about a microsecond (although the resolution provided for nanosecond) and the store clock instruction was non-supervisor/non-priviledge instruction. There was a supervisor instruction that could set a (clock comparator) value that would interrupt when the clock reached that value. There was also a separate 64bit interval timer that decrement at the same rate as the TOD clock which would also interrupt when reached zero. An add-on box could set this from the naval observatory. 370 (real-time) tod clock threads
https://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/2000.html#2 Computer of the century
https://www.garlic.com/~lynn/2000.html#4 Computer of the century
https://www.garlic.com/~lynn/2000f.html#57 X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)
https://www.garlic.com/~lynn/2001f.html#52 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001f.html#53 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2002.html#52 Microcode?

by comparison the 360/67 only had a 32bit decrementing timer that had low-order bit position that was about 13+ microseconds (and would interrupt at zero). cp/67 had to make due with process accounting and time-slice control for interactive environment by doing a lot of swapping and storing of that timer. it got easier for vm/370 on the 370 models with the real tod clock and the other time facilities.

real-time (hard processing time deadlines) wasn't really mainstream mainframe ... there was the Federal Systems Division (FSD) special computers done for nasa and other places that were real-time. then of course there are the original modified 360/50s & 360/65s for the air traffic control system. misc faa atc:
https://www.garlic.com/~lynn/2002b.html#6 Microcode?
https://www.garlic.com/~lynn/2002f.html#29 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction

then there was all the process controller stuff that was frequently (real) real-time ... like 1800, system/7, & s/1 based stuff (of course S/1 also saw a lot of use as communication controller in addition to process controller). these were real-time in the sense that when something happened in the real world, the computer had a (very) tight realtime deadline to re-act/respond.

most of the mainframe stuff was real-time in the sense of handling interactions with people (interactive as opposed to batch) ... but also like ATM machines.

the one mainframe application (that I know of) that had real, real-time constraints was the 1419 check sorter ... both MVT on 360 ... and later VS1 on 370 had special I/O processing paths in order to meet the elapsed time constraints of the 1419 check sorter. misc 1419, check sorter:
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2002.html#18 Infiniband's impact was Re: Intel's 64-bit strategy

ACP (airline control program, currently called TPF) to maintain its transaction rate ... did have stuff that killed transactions if they exceeded a very small amount of processing. In the early '90s some of the ACP/TPF airline systems had grown into pretty large clusters handling several thousand transactions per second.

Some of the ATM & point-of-sale stuff have some interesting characteristics (some also using TPF currently). In the '70s there was a guy that wrote a virtual machine based ATM transaction processor for VM/370 for one lf the LA area financial institutions ... he claimed that he got higher ATM transaction throughput with vm/370 on a 370/158 (about 1mip processor) than TPF on 370/168 (about 3mip processor). The difference was that he had a much more sophisticated arm queueing and account record clustering strategies. recent acp/tpf thread:
https://www.garlic.com/~lynn/2002f.html#60 mainframes and mini-computers

A problem with ACP (& TPF) was that it was much closer to a monitor than an operating system (with lots of sophisticated system services). At least some of the large-scale airline res systems ... do much of the prep & maint processing on auxiliary large scale MVS-based database systems ... and then shutdown TPF periodically and rebuild TPF infrastructure from the MVS hosted data.

As a independent consultant in the mid-90s we looked at porting routes (res application accounting for something like 25 percent of total activity) to a ha/cluster configuration. misc. routes
https://www.garlic.com/~lynn/96.html#31 Mainframes & Unix
https://www.garlic.com/~lynn/99.html#17 Old Computers
https://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
https://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#153 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000.html#61 64 bit X86 ugliness (Re: Williamette trace cache (Re: First view of Willamette))
https://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001g.html#45 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
https://www.garlic.com/~lynn/2001k.html#26 microsoft going poof [was: HP Compaq merger, here we go again.]
https://www.garlic.com/~lynn/2001n.html#0 TSS/360
https://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown

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

Why are Mainframe Computers really still in use at all?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Mainframe Computers really still in use at all?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 29 Apr 2002 13:43:40 GMT

ss57@YAHOO.COM (Steve Smith) writes:
LexisNexis search engines and core data are on OS/390 mainframes.

i believe also dialog and some number of the large airline res systems (although many for a long time had extended clusters using HYPERchannel, including lexis/nexis and large tpf res systems)).

then there is possibly the largest & oldest, granddaddy of them all, national library of medicine. NLM hit a huge bimodal problem early on (70s) ... a search would return hundreds of thousands or more hits ... until somewhere out in the 5-7 term refinement, where the number of hits dropped to zero. Somewhere around 1980, a pc-based user interface was developed to help manage search strategy ("grateful med") and the default for NLM was to return the number of hits (as opposed to the hits themselves). Then it became something of a random walk using grateful med ... to find a search combination that returned less than hundreds or thousands but more than zero. as of 5-6 years ago (last time I checked) ... the implementation was still late '60s BDAM.

http://www.nlm.nih.gov/

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

markup vs wysiwyg (was: Re: learning how to use a computer)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: markup vs wysiwyg (was: Re: learning how to use a computer)
Newsgroups: comp.sys.intel,comp.os.vms,comp.arch,alt.folklore.computers
Date: Mon, 29 Apr 2002 15:38:40 GMT

"Bob Knowles" writes:
And a bit more history: DEC (specifically CUP Engineering, now sadly defunct) was part of the drive to get SGML adopted as a standard by ISO. At what was thought to be the last hurdle, there was a delay (some of the reviewers decided on a change that turned out to be more far-reaching than they thought), and the schedule slipped by over a year.

i believe one of the players that pushed hard to turn GML into SGML standard was the federal government & some guy that coined the term COTS.

various gov. documents are really complex and they wanted some way of transitioning to online. later when i was doing some due diligence on tymshare for the m/d purchase ... one of the systems (besides gnosis/keykos) was engelbart's augment ... which had some really complex online gov. documents (i believe RFP responses) that had really complex hyperlink structures (running on a tymshare tops-10 system). there was also a cord keyboard that was in use with augment.

misc. augment posts:
https://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
https://www.garlic.com/~lynn/2000g.html#26 Who Owns the HyperLink?
https://www.garlic.com/~lynn/2000g.html#31 stupid user stories

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

Black magic in POWER5

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Black magic in POWER5
Newsgroups: comp.arch
Date: Mon, 29 Apr 2002 16:10:03 GMT

Peter Boyle writes:
The link posted made reference to tcp/ip and MPI acceleration, so if I were to make a crazy guess:

The memory controller goes on chip, and chips system bus interface has a slave with bus qualifiers specifying PID and a virtual adressing mode. The cpu could then translate the address (major faults and all), and you have "acceleration" for dma from user space without the Myrinet style pre-registration and locking of pages.

no idea, but one of the things from mainframe is all the access register stuff (some 20 years old) and controlled ability to access areas in multiple virtual address space areas ... allowing (pointer) data access w/o having to do the buffer copies (or using locked/pinned real address).

w/o the access rules, base 801/rios already has the makings if there were operations that directly supported specification for segment-id/segment-offset combo (i.e. PID might be needed for access rules, but the pre-unix 801 already had segment-id/segment-offset for unique virtual address).

there is all the old protocol engine stuff for tcp/ip (and xtp) for scatter/gather of the pieces ... with trailer protocol for crc calculated on the fly.

previous power5/power6 ref:
https://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips

some old 801 segment-id discussions:
https://www.garlic.com/~lynn/98.html#26 Merced & compilers (was Re: Effect of speed ... )
https://www.garlic.com/~lynn/2000.html#59 Multithreading underlies new development paradigm
https://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme

misc. access register:
https://www.garlic.com/~lynn/98.html#36 What is MVS/ESA?
https://www.garlic.com/~lynn/2000d.html#28 RS/6000 vs. System/390 architecture?
https://www.garlic.com/~lynn/2001d.html#28 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001d.html#30 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001h.html#73 Most complex instructions
https://www.garlic.com/~lynn/2001k.html#16 Minimalist design (was Re: Parity - why even or odd)
https://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix

some old tcp/ip accelerator refs:
https://www.garlic.com/~lynn/99.html#0 Early tcp development?
https://www.garlic.com/~lynn/2000b.html#9 "Mainframe" Usage
https://www.garlic.com/~lynn/2001b.html#57 I am fed up!
https://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?
https://www.garlic.com/~lynn/2001h.html#22 Intel's new GBE card?
https://www.garlic.com/~lynn/2001k.html#62 SMP idea for the future

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

The HTML one-pixel dilation trick

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The HTML one-pixel dilation trick
Newsgroups: alt.folklore.computers,comp.infosystems.www.authoring.html
Date: Mon, 29 Apr 2002 16:32:25 GMT

Brian Inglis writes:
Extracted from "The Mosaic Handbook", ORA, 1994. Marc Andreessen left NCSA in Dec 93. NCSA agreed to have Spyglass license and develop Mosaic in Aug 94. Sometime around there MA and Jim Clark founded Mosaic Communications Corp.

other misc:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2

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

income tax [was: Computers in Science Fiction]

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: income tax [was: Computers in Science Fiction]
Newsgroups: alt.folklore.computers
Date: Mon, 29 Apr 2002 22:39:08 GMT

William Hamblen writes:
Withholding first arrived with the Social Security tax in the '30s. Income tax withholding arrived during WWII when the rates were raised drastically. Income tax day was changed from March 15 to April 15 at the same time.

slightly more computer related is EFTPS (electronic funds tax payment system) ... all corporations with greater than $200k/annum in corporate tax + employee withholding have to use EFTPS (but anybody can, there has also been pending regs to lower the threshold to $50k/annum). Something like 1 million out of the 7 million corporations in the US now use EFTPS. Also the treasury has been quoted that something over 90 percent of the federal budget now flows in via EFTPS. Some number of the states have also implemented similar programs.

https://web.archive.org/web/20030422170840/http://fms.treas.gov/eftps/index.html
https://web.archive.org/web/20011114211859/http://www.fms.treas.gov/eftps/news.html

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

The HTML one-pixel dilation trick

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The HTML one-pixel dilation trick
Newsgroups: alt.folklore.computers,comp.infosystems.www.authoring.html
Date: Tue, 30 Apr 2002 04:11:21 GMT

Arjun Ray writes:
Mosaic Communications Corp -> Netscape Communications Corp and Mosaic Netscape -> Netscape Navigator.

there was a company in the valley that had the rights to the word netscape for some time ... they suggested/provided it to the new company as alternative to mosaic.

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

IBM MIcrochannel??

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM MIcrochannel??
Newsgroups: alt.folklore.computers
Date: Tue, 30 Apr 2002 15:46:34 GMT

maynard@thebrain.conmicro.cx (Jay Maynard) writes:
I have a couple of IBM MCA RS/6000s. They make great platforms for the P/390 personal mainframe system, much more so than the PCI versions that followed; you can stuff an MCA P/390 board in any MCA box, and it'll work, while the PCI version is much, much pickier.

the problem with MCA for RS/6000s wasn't the protocol itself or even doubling the rate ... it was having a common bus hardware with the ps/2 and suggestion that the rs/6000s should use ps/2 adapter cards instead of designing their own. there was a joke if the rs/6000s had to use the ps/2 scsi disk adapter card ... it would run as slow as ps/2.

there were benchmarks of the ps/2 16mbit MCA t/r adapter card against the PC/RT designed 4mbit ISA t/r adapter card. While 16mbit t/r might have had higher aggregate thruput ... the cards were designed for office desk top thruput. Any single 16mbit MCA t/r card had lower sustained thruput than the PC/RT designed 4mbit ISA t/r card. Not so bad for random office desk top use ... but serious problem for engineering client/server ... especially where the "server" needed to sustain the aggregate of all the individual clients.

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

"Soul of a New Machine" Computer?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Soul of a New Machine" Computer?
Newsgroups: alt.folklore.computers
Date: Tue, 30 Apr 2002 15:31:55 GMT

Pete Fenelon writes:
It contributed significantly to DG revenue through the early 80s, though largely in terms of keeping customer loyalty rather than being a "Vax killer". DG later abandoned proprietary minis and got into Motorola 88k-based workstation/server systems running a variety of Unix (DG/UX). The 88k was something of a turkey. DG almost died, but resurrected itself as a company that builds Intel-based servers. It was bought out by storage company EMC towards the back end of '99.

part of the emc purchase was that dg had gotten into disk arrays. dg had built new campus with three new bldgs out on 495 ... which got sold off (one of the bldgs bought by company that does the data processing outsourcing for investment houses). DG, sequent, and convex all built numa scale-up configurations with SCI interconnect (DG and sequent with intel processors and i believe dolphin chips, convex with hp processors and their own SCI design). dg got bought by emc (for its clariion disk arrays?), sequent by ibm, and convex by hp.

rolm was using dg computers. we got to go in to look at the development process. There was one stage where it was taking 24hrs elapsed time just to load the new software into a switch for testing. at one time the rolm campus across from great america was considered the epitome of silicon valley. rolm was bought by ibm and then sold off to siemens. siemens now has a couple other bldgs in the area ... including the complex at the first street & 101 for its infineon spin-off.

somebody recently told a story about dg founder (de castro) and getting his startup funding from the money people.

random dg refs:
https://web.archive.org/web/20010223235626/http://computernewsdaily.com/247_090497_094212_26108.html
http://www.forbes.com/1997/10/14/feat.html
https://web.archive.org/web/20040427165907/http://multics.acms.org.au/z0105.htm

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

"Soul of a New Machine" Computer?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Soul of a New Machine" Computer?
Newsgroups: alt.folklore.computers
Date: Tue, 30 Apr 2002 15:38:57 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
I didn't consider the 88k to be too bad... if anything, I thought it was quite a decent processor. Its main problem seemed to be that Motorola lost interest when it started pursuing the Power architecture.

or a lot of the 88k showed up in the power/pc. the rios/801/power was a non-smp chip (no provisions for cache coherence). ok, i'm having a senior moment ... what was the name of the joint group responsible for 601 ... our former boss headed it up (and he had come from motorola before working on rios, later he was president of mips).

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

"Soul of a New Machine" Computer?

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Soul of a New Machine" Computer?
Newsgroups: alt.folklore.computers
Date: Tue, 30 Apr 2002 16:41:46 GMT

Anne & Lynn Wheeler writes:
a non-smp chip (no provisions for cache coherence). ok, i'm having a senior moment ... what was the name of the joint group responsible for 601 ... our former boss headed it up (and he had come from motorola before working on rios, later he was president of mips).

oops, finally clicked, somerset; misc. past threads.
https://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2001g.html#23 IA64 Rocks My World
https://www.garlic.com/~lynn/2001i.html#28 Proper ISA lifespan?
https://www.garlic.com/~lynn/2001j.html#37 Proper ISA lifespan?

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

Secure Device Drivers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure Device Drivers
Newsgroups: comp.arch
Date: Tue, 30 Apr 2002 17:18:58 GMT

hack@watson.ibm.com (hack) writes:
Btw, we were in such a situation when we added FBA support: this differed enough from (then) 3330/40/50 support that we had to rethink a number of things. But we had manuals, and they were not secret! The work was also completely below the file system (which just assumed a space of blocks of a size reported at logical device connection time), so although it was not all in ONE place, it was in a small number (3 or 4) of expected places.

When most people think of S/370 or its successors, they think of MVS and its descendants, where (due to OS/360 heritage) many device properties (in particular CKD-ness and track sizes) were visible all the way up into application code, with assumptions spread all over the place. That is indeed a predicament that is difficult to outgrow -- but it is a property of historical software conventions, not of the I/O interface. Other S/390 operating systems such as VM, VSE, Linux or mine need not be burdened by it.

the problem with MVS supporting FBA was that it was really tied to CKD & multi-track searching for both VTOC and PDS members. Even offering them fully operational & tested support ... the STL group turned it down, claimed the bill for just documentation and education in the release cycle was on the order of $26m. I've claimed that the life-time costs associated w/ECKD far surpases what it would have been for FBA cut-over and its subsequent life-time costs.

It was easy for CP & CMS ... since both CP & CMS effectively treated CKD devices as logical fixed block since the days of CP/40 in the mid-60s.

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

"Soul of a New Machine" Computer?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Soul of a New Machine" Computer?
Newsgroups: alt.folklore.computers
Date: Wed, 01 May 2002 16:06:33 GMT

Charles Richmond writes:
Of course it looks "IBM-y"...it is based on the IBM Power architecture of the RS-6000. It was jointly developed by Apple, Monorola, and IBM, so no surprise there.

Someone must have thought that the PowerPC chips made good embedded processors...they were used on the Mars Pathfinder project...

somerset was the design team. it was headed up by guy that went on to be president of mips (he had previously been at motorola before joining the RIOS group for the power chips ... 32bit 810). the powerpc workstation chips were 601, 603, 610, 615, 620, etc. Then there was the rochester group doing what had been called the 630 for the as/400. The 4xx chips were targeted at embedded market ... and somewhere there was even talk of 2xx line of chips.

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

Security Issues of using Internet Banking

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Wed, 01 May 2002 16:15:07 GMT

mrr@acer.reistad.priv.no (Morten Reistad) writes:
It is user-friendly and VERY lightweight.(it works OK over a 9600 bps mobile phone connection; with image loading turned off).

one of the requirements given the X9A10 working group for the x9.59 payment standard was that it work for all electronic payments in all environments.

one of the environmental issues are point-of-sale terminals. a large percentage of POS terminals are kind-of repackaged PC/XTs with 2400 baud modems. One of the recent issues that came up looking at upgrading POS terminals to higher speeds ... was that just the protocol initialization hand-shaking chatter for higher speed modems takes longer than total elapsed time for existing calls.

misc. x9.59 refs:
https://www.garlic.com/~lynn/x959.html#x959

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

Why are Mainframe Computers really still in use at all?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Mainframe Computers really still in use at all?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 01 May 2002 16:19:46 GMT

eugene@cse.ucsc.edu (Eugene Miya) writes:
Good question. Ask the IRS.

i think that IRS has had more re-engineering/modernization projects over the last 15 years than even FAA ATC. The one at the census was somewhat more successful for the year 2000 census ... but they have 10 years between events to get ready.

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

Black magic in POWER5

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Black magic in POWER5
Newsgroups: comp.arch
Date: Wed, 01 May 2002 16:48:34 GMT

Peter Boyle writes:
i. I/O can assert virtual addresses (whether or not locked) and have translation carried out, so no pregistration of pages and/or g-s tables. I'm ashamed to admit I was entirely unaware of the mainframe segment translations the Wheelers posted, they don't really work in a typical contemporary VM system.

hardware access registers was ability to have multiple virtual address spaces defined for a process ... with rules about accessing data in other than the primary virtual address space. part of this was targeted at semi-priviledged processes providing system services ... but running in their own address space ... and being able to directly access parameters and other passed data. Furthermore, it is possible to do a "call" & context switch to semi-priviledge processes in other address spaces w/o having to take an interrupt into the kernel and execute kernel instructions. The makings are there for demon like processes & other services in their own, unique address spaces that are directly calleable from an application program. The mechanisms are then there for having hardware support for a collection of data ... where different pieces of the collection resided in different virtual address spaces. architecture for access registers and multiple address space technology date back to the late '70s. The earliest implementation was "dual-address" space support on the 3033 in the late '70s.

somewhat in parallel with the multiple address space architecture support in the mainframe was the 801 work dating from the same era. This showed up in the ROMP chip ... used in PC/RTs. ROMP, instead of having a virtual address space register ... had 16 segment registers in a 32bit virtual address space. The top four bits of the 32bit virtual address selected/indexed a segment register. A ROMP segment register contained a 12bit segment-ID. The hardware table look aside, operated with a combo of 12bit segment-id/16bit page number. The ROMP documentation talked about 40bit virtual addressing ... this is because the hardware had 28-bit virtual address displacements within a segment plus the 12bit segment-id. A ROMP processor, in theory could have up to 4096 simultaneously actively defined virtual memory segments. If this was mapped into 32-bit unique virtual address spaces with 16 privately defined 256mbyte segments per 32-bit virtual address space ... it allowed for 256 simultaneously actively defined virtual address spaces supported in hardware. Note however, that the 801/ROMP architecture/implementation wasn't originally targeted at a UNIX virtual address space paradigm.

RIOS/POWER for the RS/6000 extended the 12bit segment-id found in ROMP to 24bits ... and therefor the RIOS/POWER documentation mentioning 52-bit virtual addressing supported by the hardware.

Part of the original issue involving things like buffer copies and different domains of control ... would involve the hardware being able to simultaneously access different pieces of data appearing in different address space ... and have an address specification mechanism that included multiple address spaces. The mainframe hardware access registers provide such a mechanism (original implementation in the late '70s with the 3033 dual-address space mode). The ROMP/RIOS also support hardware unique addressing across multiple virtual address spaces with "segment-ids".

A case could even be made that both the ROMP/RIOS and the access register solutions originally evolved in nearly the same time & place ... even with some of the same people overlap.

original post:
https://www.garlic.com/~lynn/2002g.html#5

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

Black magic in POWER5

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Black magic in POWER5
Newsgroups: comp.arch
Date: Wed, 01 May 2002 17:01:41 GMT

Anne & Lynn Wheeler writes:
A case could even be made that both the ROMP/RIOS and the access register solutions originally evolved in nearly the same time & place ... even with some of the same people overlap.

simple example:
https://web.archive.org/web/20021226021851/www.hpl.hp.com/news/2001/apr-jun/2worley.html

see dual-address space reference in the above.

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++,alt.folklore.computers
Date: Wed, 01 May 2002 20:19:17 GMT

"Rudvar Alswill" writes:
OSI was started in the seventies to find a model and develop protocols for computer communications. At a cost of almost 1 Billion dollars and twenty years, it failed completely. It was strongly supported by Telecom groups in Europe. Yet they were totally discredited by producing virtually nothing in that time and for that amount of money. How did so many highly technical people waste so much time and money and fail in such a undignified way.

1) OSI was strongly oriented towards the telco copper wire point-to-point problems of the 70s & earlier, like high error rates and little or no FEC technology. it was also pre-LAN

2) TCP/IP was a working implementation ... where OSI tended to be a lot of specification independent of practical implementation ... IETF at least required two operational, interoperable implementations prior to advancement to RFC.

3) TCP/IP underwent major evolution with the 1/1/83 cut-over from the strongly host-to-host orientation into "internet" (aka IP part of tcp/ip).

in the late '80s at one point in X3S3.3 (ansi standards for equivalent to OSI level 3 & 4) ... work on high speed protocol (HSP) effort was fealt to be very dubious because progression to ISO level supposedly required conformance with seperation of level 3 & level 4 operations. HSP would have collapsed portions of level 3 & 4 into single level. The ISO & ANSI OSI-related groups were already quite skizo over this requirement since IEEE 803 had already collapsed OSI level 1, level 2, and parts of level 3 into single layer (and there was no obvious easy way of declaring LANs invalid and having them all destroyed). HSP would have filled between the level 4 interface to IEEE 803 (aka all of OSI level 4 and all of OSI level 3 not already occupied by IEEE 803).

in that sense the organizational activities around the "pure, original, OSI architecture" wasn't very agile at adapting to changing technology. There were lots of organizational mandates about meeting pure architecture specification ... but not a whole lot of attention to practicallities of the real market and changing technology.

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

Security Issues of using Internet Banking

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Wed, 01 May 2002 21:21:01 GMT

"Charlie Gibbs" writes:
Right now I'd settle for having an ATM not lie to me. That's what I call it when it says my account balance is $1200, and then says "your request exceeds your balance" when I try to withdraw $40. (There was a hold on my account - which is another topic in itself - but the machine couldn't be bothered telling me about that.)

getting a failure indication thru the debit network from the bank-end bank processor out to the ATM machine is major undertaking ... frequently they map several decline/error indications into a standard message.

for the NACHA aads trials (specifically "NACHA AADS RFI" & "NACHA AADS results references"):
https://www.garlic.com/~lynn/x959.html#aads

it was a major under-taking to get the backend processor to return "incorrect digital signature" in place of "incorrect PIN". I've seen better worded message that says "your request exceeds your available balance" ... i.e. "available" taken to be a whole set of conditions. Of course somebody might have been trying to cut the number of characters displayed. Also this can be distinct indicator from "your request exceeds your limit" ... although both might map to same condition ... retrying the operation with a lower value.

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++,alt.folklore.computers
Date: Thu, 02 May 2002 03:40:41 GMT

"David H. Lipman" <DLipman~nospam~@Verizon.Net> writes:
Do you remember GOSIP ?

Nobody wanted to "reinvent the wheel" after TCP/IP became so widely proliferated. { GOSIP - Gov't. Open Systems Internet Protocol }

post containing some gosip extracts and document refs:
https://www.garlic.com/~lynn/2000d.html#70 When the Internet went private

a couple misc. files tripped across:


gosip-v2.txt ... also gosip-v2.ps ... 10/90
gosip-order-info.txt                   9/91
vendors-guide.doc                      8/90

RFCs mentioning GOSIP ... go to
https://www.garlic.com/~lynn/rfcietff.htm

& click on Term (term->RFC#) then click on "GOSIP" in the Acronym fastpath which gives:

Government OSI Profile (GOSIP)
see also Open Systems Interconnection
2441 1632 1629 1237 1169 1039

clicking on the actual RFC number, will bring up the RFC summary in the bottom frame. clicking on the ".txt=nnnnn" field in the summary will retrieve that specific RFC. misc. summaries from above:

1039
DoD statement on Open Systems Interconnection protocols, Latham D., 1988/01/01 (3pp) (.txt=6024) (Obsoletes 945)

1169
Explaining the Role of GOSIP, Cerf V., Mills K., 1990/08/09 (15pp) (.txt=29413)

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

Why did OSI fail compared with TCP-IP?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++,alt.folklore.computers
Date: Thu, 02 May 2002 15:13:15 GMT

Jason Ozolins writes:
And don't forget, what was implemented tended to perform like slugs on drugs. In 1993 I watched a file transfer over Ethernet between a Windows 3.1 box running ICL's beautiful office automation suite and an ICL SPARC SVR4 box running OSI protocols go about the same speed as my 9600 baud modem at home could manage. At the time, my thought was "if this is the future, then the future will be very very slow".

I believe that some organization in europe implemented the full 7-level OSI stack and when the thruput numbers were presented somebody from one of the ISO group said that OSI was supposed to be a abstract model ... not a real specification.

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

Why are Mainframe Computers really still in use at all?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Mainframe Computers really still in use at all?
Newsgroups: alt.folklore.computers
Date: Thu, 02 May 2002 15:04:38 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
What consulting outfit got their claws into the IRS? I'm sure that they got desperate enough at some point to farm out the smart work.

the most recent modernization round I believe has been CSC. however, i believe there is lots of talk of another round involving joint bid from ??? (there was some bid press release ... i think it was joint bid with 3-4 companies with one being IBM). I believe I've heard some comment that there is some amount of 360 assembler still in use that has to be analyzed as part of any modernization effort.

I don't think it is an issue of desperation leading to farming out the work. I think it may be long term staffing levels ... for a (supposedly) short term project of any magnitude do you hire a bunch of civil serpents who you then have to fire when the project is done? Furthermore, the skill mix & staffing levels for such a modernization project is pretty different than the day-to-day operational & support staff.

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

Why did OSI fail compared with TCP-IP?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: alt.folklore.computers
Date: Thu, 02 May 2002 15:18:07 GMT

"George R. Gonzalez" writes:
One personal experience-- we were trying to decide around 1989 whether to go with X.500 for directory services (on a 640K DOS pc client no less).

All we really needed was a souped up "finger" daemon. Easily understood and implemented.

I downloaded the X.500 client and server-- memory fails me but it was something like 33 megabytes of tar file, 1,300 files.

I remember being at a ACM conference around 1990 (sigmod?) ... and somebody there characterizing x.500 as a bunch of networking types re-inventing 1960s database technology.

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

Why are Mainframe Computers really still in use at all?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Mainframe Computers really still in use at all?
Newsgroups: alt.folklore.computers
Date: Thu, 02 May 2002 15:20:35 GMT

Anne & Lynn Wheeler writes:
I don't think it is an issue of desperation leading to farming out the work. I think it may be long term staffing levels ... for a (supposedly) short term project of any magnitude do you hire a bunch of civil serpents who you then have to fire when the project is done? Furthermore, the skill mix & staffing levels for such a modernization project is pretty different than the day-to-day operational & support staff.

also can you imagine trying to get a shole bunch of short-term supergrades thru congressional approval process?

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch
Date: Thu, 02 May 2002 15:30:38 GMT

Chris Quayle writes:
It's easy now to have 20-20 vision now in hindsight, but networking at the time was very much in it's infancy. Early computer networks were based on a telecoms model because that was the working global comms network of the time. The state machine design model came directly from hardware design techniques. Some of the early protocols (X25 frame etc) were implemented at hardware level because the computing power to do this in software did not exist at a reasonable cost. Even now, state machine design techniques are an excellent way to visualise and implement complex protocols. The difference being that now many more of the layers are implemented in software, rather than hardware.

It's surprising how the layered model and state machine design techniques have persisted right up to the present time, so perhaps some of those original ideas were more on target than is given credit for.

however, IETF adopted to the real-world ... ISO effectively kept saying that IEEE 803 LANs violated the OSI model and shouldn't be allowed to exist. we ran into that in x3s3.3 on HSP that was trying to doing something that went directly from the top of level4 directly to mid-level3 ... aka top of IEEE803 LANs and were told it would never receive ISO standardization because it violated the OSI model.

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

Security Issues of using Internet Banking

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Thu, 02 May 2002 17:11:58 GMT

Brian Inglis writes:
If you can think up the test for the condition that leads to this abrupt exit, the least you can do is tell the user or support what the condition was that caused the exit, and provide a unique error reference that leads back to the test in the code, even if you don't know what caused it and what it means. That's what C's __FILE__, __LINE__, and now __func__, are for, together with a nice enum err { ERR_ }, to guide support right to the defensive code, in case the error text is not sufficiently descriptive.

ibm operating systems and products started that in the 60s, things of the form: module, error code, severity level and verbal description. for interactive like CMS ... it was possible to set option where severity level could be filtered or message could be just the code, just the verbage or both. then there were big manuals that listed each along with paragraph or two more detailed description. something similar was done for kernel panics.

I wrote a post-mortem kernel dump analyzer (in REXX, then called just REX) that had softcopy of the messages&codes manual and would automatically reference the appropriate detailed description. I also started development of a library of scripts that could do certain sets of specific analysis based on failure code.

misc. dumprx refs:
https://www.garlic.com/~lynn/94.html#11 REXX
https://www.garlic.com/~lynn/2000b.html#32 20th March 2000
https://www.garlic.com/~lynn/2000b.html#33 20th March 2000
https://www.garlic.com/~lynn/2001c.html#0 Z/90, S/390, 370/ESA (slightly off topic)

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++,alt.folklore.computers
Date: Thu, 02 May 2002 17:31:14 GMT

Chris Morgan writes:
The obvious concrete example being LDAP, which is a subset of X.something (500?)

as mentioned in another posting somebody at an ACM conference circa 1990 (SIGMOD?) ... x.500 was a bunch of networking types re-inventing 1960s database technology.

LDAP is much more of a networking protocol that accesses database backends (you don't see many LDAPs using other than pre-existing DBMS technology). It is also heavily influenced by IETF process ... aka

https://www.garlic.com/~lynn/rfcietff.htm

select Term (term->RFC#) and then select "LDAP" from the Acronym fastpath, i.e.:

ightweight directory access protocol (LDAP ) (LDAPv2) (LDAPv3 )
see also ITU directory service protocol , directory
3112 3088 3062 3060 3045 2927 2926 2891 2849 2830 2829 2820 2798 2739 2714 2713 2696 2657 2649 2596 2589 2587 2559 2307 2256 2255 2254 2253 2252 2251 2247 2164 1960 1959 1823 1798 1778 1777 1558 1487 1249

it is then possible to select on any of the RFC numbers to get a summary of the specific RFC. In the RFC summary entry it is possible to select on the ".txt=nnnn" field to retrieve the actual RFC ... aka

3088 E
OpenLDAP Root Service An experimental LDAP referral service, Zeilenga K., 2001/04/16 (11pp) (.txt=19471)

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

Why did OSI fail compared with TCP-IP?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++,alt.folklore.computer
Date: Thu, 02 May 2002 17:45:43 GMT

Tony Finch writes:
And SNMP uses ASN.1 and SSL certificates are X.509.

SSL certificates are sort-of X.509 ... and X.509 certificates are specified as ASN.1 encoded, aka ASN.1 encoding is used for transmission purposes. Once transmitted, to use the information, there has to be ASN.1 decoding of the information. There is some move for XML encoding of various things in place of ASN.1 encoding.

There are huge number of things that are ISO standards ... other than OSI networking standards. Many such ISO standards are widely deployed and successful. Just because something is an ISO standard doesn't automagically make it a failure and just because something is an IETF standard doesn't automagically make it a success. However, IETF has had something of a track record of requiring actual operational implementations before moving things along the standards track, aka it doesn't mean that the people in IETF are either smarter or dumber ... but there is something of a sanity check having real live implementations.

A world-wide deployed network message protocol that is an ISO standard is 8583 (neither TCP/IP nor OSI) ... all those ATM and point-of-sale (debit & credit) boxes that you find all over the world (as well as the backend bank-to-bank). Note, however it doesn't use ASN.1 encoding.

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++
Date: Thu, 02 May 2002 21:51:46 GMT

Marco S Hyman writes:
>{ GOSIP - Gov't. Open Systems Internet Protocol }

Not "protocol", "profile". It was a functional profile of which of the (some times incompatible) parts of OSI should be used for systems sold to the US government. Exanple: OSI had two different (and incompatible) network protocols, CONS and CLNS. GOSIP specified which one a conforming implemention must use.

// marc

and not internet ... but interconnection ... aka
U. S. Government Open Systems Interconnection Profile (GOSIP) VERSION 2.0 October 1990

the whole thing about internet (aka IP) was the great 1/1/83 switch-over for arpanet ... prior to that it looked more like traditional (homogeneous protocol) network. the 1/1/83 switch-over introduced the concept of internet and gateways (between networks).

one of my claims regarding the internal corporate network being larger than all of arpanet/internet from the beginning until some time around '85 was that effectively the internal corporate network essentially supported gateway function in every node from the beginning.

misc. internet posts:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/subnetwork.html#internet
https://www.garlic.com/~lynn/subindex.html#network
https://www.garlic.com/~lynn/subindx2.html#network

misc. osi, hsp, iso posts:
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

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

Why did OSI fail compared with TCP-IP?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip
Date: Fri, 03 May 2002 13:20:46 GMT

"Ketil Malde" <ketil+@ii.uib.no> writes:
You don't have to look to Adams; In "The fifth discipline", Peter Senge considers a committee to effectively work at the lowest IQ of the members, IIRC. Good book, by the way.

different committees operate at different levels
sum(IQ0, IQ1, ..., IQn)
sum(IQ0, IQ1, ..., IQn)/n
min(IQ0, IQ1, ..., IQn)
min(IQ0, IQ1, ..., IQn)/n

i.e. a comittee can be less effective than any single member of the comittee alone ... with large comittees tending to zero effectiveness.

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

Secure Device Drivers

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure Device Drivers
Newsgroups: comp.arch
Date: Fri, 03 May 2002 13:47:40 GMT

Jan C. Vorbr�ggen writes:
I have the distinct impression OS implementors disagree with you. For instance, VMS only fairly late offered this mechanism (called FAST_IO, IIRC - there is also FAST_PATH, which AFAIK is more to do with making sure an I/Os path through the OS is as short as possible) and it requires slightly modified code on the side of the application. There are some restrictions (I think buffers have to be page-aligned, for instance), and it is clearly only worthwhile if you are going to do a lot of I/O. It does offer substantially improved performance at some initial cost, both in programming and at run time.

when i worked on redoing the i/o supervisor and error recovery to make I/O bullet proof for the disk engineering lab (i.e. at the time, MVS had something like 15 minute MTBF operating with a single test cell):
https://www.garlic.com/~lynn/subtopic.html#disk

the general path also got a lot faster ... in part because a lot of the code was somewhat spaghetti ... having been the result of something like 10+ year growth, modification, enhancements, and fixes (as well as having numerous anomolous conditions).

but I also did some amount of fastpath for the optimized case (somewhat out of habit having started doing fastpath something like 15 years earlier).

I also redid the path finding for i/o and path load balancing to improve its optimization and pathlenth. and then I had to redo it again. the emerging 3880 disk controller turned out to have significant alternate path penalty overhead. If the 3880 had to change channel/path between I/O operations there was significant internal latency and overhead (not only latency to initiate operations but also busy for servicing any other operations during the period). At low to moderate loading levels ... multiple path overhead in the 3880 tended to offset any increase in thruput because of additional parallel transfer paths. It wasn't until really high transfer utilization (optimally few very large transfers, minimizing 3880 control op involvement) that benefit of parallel transfers started to offset the internal 3880 controller overheads. As a result, parallel path scheduling wasn't just a simple matter of straight-forward load balancing across the available paths. The scenario at the time was that there could be 16-32 3mbyte/sec disks connected to a 3880 controller with up to four possible 3mbyte/sec parallel transfer paths (an alternative configuration was the same set of disks could be connected to a pair of 3880 controllers, each with up to four transfers paths, allowing up to eight parallel transfer paths to the same set of disks, clustering of up to eight different processors, each with a single path ... or some combination of processor clustering and parallel paths).

The other issue at the time was trying to get MVS support for FBA which significantly improved thruput in nearly all common environments.

recent FBA & CKD thruput postings:
https://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers

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

ESCON Distance Limitations - Why ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ESCON Distance Limitations - Why ?
Newsgroups: comp.arch.storage
Date: Fri, 03 May 2002 14:50:21 GMT

"Yves Amblard" writes:
Can anyone explain the origin of the ESCON's distance limitations ? If found a lot of documents related to ESCON but none is giving a mathematical explanation. I know it's due to the protocol and signal propagation but was unable to find numbers or a mathematical explanation for it. I found a lot of documents on the web describing the distance limitation issue but no real explanation.

ESCON is a half-duplex, synchronized at the multi-byte level (not at the per transfer or per operation level). especially with disks & tapes there are various operations that presume continuous (or at least within specific latency) operation once started.

It inherited the design from data-streaming half-duplex channel cables (originally increasing the per byte synchronized transfer distance from 200' to 8-byte synchronized transfer distance limitation of 400'). Don't think of ESCON like dual-simplex FCS ... and operation latencies ... think of it as data-streaming half-duplex bus&tag copper that just happens to be using fiber.

try search engines with escon, data-streaming, distance; example
http://www-1.ibm.com/servers/eserver/zseries/library/specsheets/pdf/optica.pdf

or "escon extended distance"

for exact formulae, might try library for something like ibm r&d journal looking for an article when data-streaming &/or escon were originally announced.
http://www.research.ibm.com/journal/
http://www.research.ibm.com/journal/rd37-6.html

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

Why did OSI fail compared with TCP-IP?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip
Date: Fri, 03 May 2002 17:54:55 GMT

Anne & Lynn Wheeler writes:
sum(IQ0, IQ1, ..., IQn)
sum(IQ0, IQ1, ..., IQn)/n
min(IQ0, IQ1, ..., IQn)
min(IQ0, IQ1, ..., IQn)/n

i.e. a comittee can be less effective than any single member of the comittee alone ... with large comittees tending to zero effectiveness.

or taking a leaf out of management theory & span of control (combinatorial interaction issue) ...

sum(IQ0, IQ1, ..., IQn)/n!

which also tends to zero for large n ...

it possibly is unrelated to the lowest IQ or even the inverse ... somebody once observed that effectiveness declined sharply as the number of really bright (opinionated) people went up (something akin to deadly-embrace scenario).

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++
Date: Sat, 04 May 2002 00:22:54 GMT

Andi Kleen writes:
TCP/IP does not really conform to the OSI 7 layer model, although it is not too far off.

except for the whole IP (internet) layer ... which is non-existent in the OSI model ... and would create a brand new 8th layer ... sort of sitting somewhere between transport (layer 4) and network (layer 3).

the IP (internet) layer ... was the major thing in the 1/1/83 great switch-over. the pre-IP, pre-1/1/83, NCP/IMP based infrastructure was not too far off (from OSI model), being much more of a traditional, homogeneous networking implementation. The 1/1/83 switch-over to an internetworking implementation added something that was different with the (IP) layer to inter-networking of networks (networks being a layer 3 concept, and inter-networking not having an OSI defintion).

The "inter-network" IP layer ... also including the concept of (inter)-networking gateways. My claim previous claim was that the internal corporate network effectively had gateway function support in every node and was one of the reasons that the internal corporate network was larger than the whole arpa/internet until sometime circa 1985. I claim that the introduction of the IP layer and internetworking with gateways was one of the things that help promote the take-off of the internet (in 1/1/83 switch-over) and for it to surpose the internal network in size (there was a number of other factors also).

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

The need for Meaningful Error Messages :)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The need for Meaningful Error Messages :)
Newsgroups: alt.folklore.computers
Date: Sun, 05 May 2002 23:14:54 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
And that's the REAL problem. The quicker the computing world rewinds to, say, 1975 fer instance, the better. Give me a box of punched cards, an 029 and I'll be back in my 'happy place'. Oh - throw in a 2741 APL terminal too.

or at least APL typeball and a system that has APL 2741 support. I don't have my 2741 anymore (almost 30 years gone ... although I only got around to throwing out the table-top cover that fit on my 2741 just a couple years ago), but I do have one thing left which is a 2741 APL typeball. random apl refs:
https://www.garlic.com/~lynn/subtopic.html#hone

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

Security Issues of using Internet Banking

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Sun, 05 May 2002 23:21:58 GMT

somewhat related to internet banking security ... i updated my merged security glossary with NSA's intrustion glossary. payment, financial, x9f, and security glossaries at:
https://www.garlic.com/~lynn/index.html#glossary

the addition of this glossary along with some associated references seems to beg for new taxonomy structure for "security software" (I added some ... but not extensive).
https://www.garlic.com/~lynn/secure.htm

also somewhat related to secure financial transactions is the non-repudiation thread on PKIX mailing list:
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation

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

Why is DSA so complicated?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is DSA so complicated?
Newsgroups: sci.crypt
Date: Mon, 06 May 2002 02:53:05 GMT

ashwood@msn.com (Joseph Ashwood) writes:
Additionally since DSA can be performed using ECC (ECDSA), this gives the possibility of some very small keys, making it ideally suited for small devices.

I think that covers most of the reasons why DSA, for all it's seeming complexity, is often preferrable to RSA-style signatures. Of course I'm sure that given provocation I could come up with a sizable list why RSA signatures are superior as well.

one of the issues with DSA (both fips186-1 & fips182-2) has been secure random number generation. while ec/dsa looks good from the standpoint of small devices ... chipcards, etc ... many of these devices in the past have had inadequate random number capability. In the past I heard of some reference to test of various older model chipcards ... involving power-on, generate random number, power-off ... repeated 64k times ... and there were repeats involving possibly up to 30 percent of the generated numbers.

As a result, they have tended to use RSA keys ... where the keys have been generated externally and injected into the device ... and then used to sign messages ... which have had random numbers included in the body of the message before passing to the device (NONCEs).

Given a "small device" with adequate random number capability ... then it is possible to do both DSA (ECC or otherwise) key generation in the device as well as DSA signatures (requiring random number generated for each signature). Had an opportunity to have booth demonstrating one such hardware token at cardtech/securetech two weeks ago in New Orleans. misc refs to aads chip strawman:
https://www.garlic.com/~lynn/x959.html#aads

NIST FIPS page:

http://csrc.nist.gov/publications/fips/index.html

... with respect to fips186-2:
DRAFT October 2001 -- A change notice for FIPS 186-2, Digital Signature Standard (DSS) (.pdf file), has been made available that addresses key sizes and random number generation. This change notice replaces the item that was posted on August 3, 2001, Recommendations Regarding Federal Information Processing Standard (FIPS) 186-2, Digital Signature Standard (DSS). Comments and questions for this recommendation are requested and may be addressed to FIPS186@nist.gov.

... from fips186-1:
APPENDIX 3. RANDOM NUMBER GENERATION FOR THE DSA

Any implementation of the DSA requires the ability to generate random or pseudorandom integers. Such numbers are used to derive a user's private key, x, and a user's per message secret number, k. These randomly or pseudorandomly generated integers are selected to be between 0 and the 160-bit prime q (as specified in the standard). They shall be generated by the techniques given in this appendix, or using other FIPS approved security methods.

One FIPS approved pseudorandom integer generator is supplied in Appendix C of ANSI X9.17, "Financial Institution Key Management (Wholesale)."

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

"Soul of a New Machine" Computer?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Soul of a New Machine" Computer?
Newsgroups: alt.folklore.computers
Date: Mon, 06 May 2002 12:41:58 GMT

Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
The first 88K processor, the 88100, was even externally a Harvard architecture. It used separate 88200 CMMU (Cache & MMU) chips on the instruction bus and the data bus. Normally the system bus side of the CMMUs would be tied together, but there was no reason the hardware required that.

IIRC, the AMD 29000 and 29005 used separate instruction and data busses as well, but a single common address bus.

i don't know about 88k, but engineers that had worked on 801 designs were later involved in working on both amd 29k and hp's risc. I don't remember the exact timing ... but it may have been after Fort Knox was killed that you started seeing 801 engineers at other companies. misc. fort knox references:
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
https://www.garlic.com/~lynn/2001h.html#69 Very CISC Instuctions (Was: why the machine word size ...)

with regard to:
https://www.garlic.com/~lynn/2002g.html#18 Black magic in POWER5

there is folklore that the individual worked last two weeks up until final hour on blue iliad (which never got much past early sample chips; romp was 16bit chip, blue iliad was first 32bit, big & hot; & RIOS was 32bit):
https://www.garlic.com/~lynn/98.html#25 Merced & compilers (was Re: Effect of speed ... )
https://www.garlic.com/~lynn/99.html#66 System/1 ?
https://www.garlic.com/~lynn/2000.html#16 Computer of the century
https://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip
Date: Mon, 06 May 2002 13:10:11 GMT

"A. G. McDowell" writes:
To be somewhat more constructive, I think there are so many ways to get nowhere that the more useful question is "How did DARPA do so well?". Many of those scarred by OSI were also in touch with TCP/IP and did learn from it. Here's to "Rough Consensus and Running Code"!

Internop '88 had a large number of vendors that were also showing OSI related products. Interop '88 was possibly the first time that a large number of different boxes were connected to multiple LANs ... the floor NET was four parallel LANs (remember OSI believed that LANs were invalid and shouldn't be allowed to exist). Sunday the floor nets were crashing welling into monday AM ... before the problem was diagnosed ... which resulted in a new (IETF) standard specification.

the concept of interneting & gateways (again something not provided for by OSI and was ruled invalid/violations) had come about 1/1/83 and in part allowed the internet to exceed the size of the internal corporate network by sometime '85 (pre 1/1/83, non-internetworking & non-gateway was much more straight OSI).

NSF had let RFP for NSFNET1 backbone ... however it came about at time that the internet was growing, interneting/gateways was prooving valid and there was huge excessive dark fiber capacity sitting around. The result was that the amount of commercial resources dumped into the backbone was far in excess of the funding provided by the NSF NSFNET (& NSFNET2) backbone RFP (direct & indirect commercial backing was far in excess of federal funding; there has been side threads in the past about the acceptable use policies not allowing commercial use of the NSFNET backbone because it was total federal backing). A conjecture was that the dark fiber owners were attempting to promote both actual use and the academic development of applications oriented towards large bandwidth utilization (planting seeds for utilization demand of the dark fiber bandwidth). One could say that they succeeded ... most notably with the advent of Mosaic.

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

Why is DSA so complicated?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is DSA so complicated?
Newsgroups: sci.crypt
Date: Mon, 06 May 2002 18:21:40 GMT

"Roger Schlafly" writes:
There is not much difference regarding random numbers. The consensus now is that you also need random numbers to do RSA securely. Either way, a pseudorandom number generator could be injected into the device.

RSA is not really any simpler, either. Just look at all the papers on the security of various padding schemes and the other RSA technicalities. The advantage of RSA is that it has faster signature verifications, and that's about all.

there is appearnce of difference of regarding requiring random numbers. It is obvious that a hardware token needs a secure random number for generating the actual signatures.

there is a lot of stuff about padding and including random numbers in the body of messages that are RSA signed ... however since it isn't actually part of the specification ... they allow external forces to supply all of that externally before sending the message to the token for signing (aka random numbers all being done externally to the token). that leaves the token dependent on external forces for the random numbers & padding (possible choice when tokens were chosen w/o real random number capability, keys generated externally, and just SHA-1 sent to token for RSA signing).

This possibly exposes a token to risks of signing mal-formed messages/SHA-1? ... which is mitigated when token accepts full responsibility for fips186 operation (security issues of signing dependencies are all encapsulated explicitly in the standard).

There is possibility that any belief that RSA was much simpler and didn't have any of these other security issues allowed for bifurcated implementations ... with tokens just doing simple RSA encrypting of sha-1.

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

Why is DSA so complicated?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is DSA so complicated?
Newsgroups: sci.crypt
Date: Mon, 06 May 2002 18:21:40 GMT

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

Why is DSA so complicated?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is DSA so complicated?
Newsgroups: sci.crypt
Date: Mon, 06 May 2002 19:36:42 GMT

"Anton Stiglic" writes:
What do you mean it's not part of the specification?

of what gets implemented in a hardware token that is passed a sha-1 to encrypted with RSA private key ... there is nothing about the hardware token being able to verify that it isn't dealing with a mal-formed message and refusing to sign it.

lets say where is the trust/security boundary ... is the trust/security boundary only around the physical perimeter of the chip inside the hardware token ... or does the trust/security boundary extend to all the components that the chip might be dependent on for correct operation.

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

ibm icecube -- return of watercooling?

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ibm icecube -- return of watercooling?
Newsgroups: comp.arch,comp.arch.storage
Date: Tue, 07 May 2002 04:14:24 GMT

"del cecchi" writes:
The IBM 4381 was impingement cooled. :-)

it was more like an upright freezer (aka rack) than the precursor 4341 which was more like a chest freezer. there all the jokes about the 4381 having this little "cooling towers" inside.

quick check with alta-vista just turned up these pictures:
https://web.archive.org/web/20030105092947/http://www.telnet.hu/hamster/oldiron/e_ibms.html

didn't show insides of the 4381 ... but did show inside 3090

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip
Date: Tue, 07 May 2002 15:42:16 GMT

craigp@world.std.com (Craig Partridge) writes:
There was not a huge excess of capacity for NSFNET Phase I, indeed, it was a struggle to get T1 lines for some locations. Nor was there much corporate contribution. NSFNET Phase I was run on a shoestring.

I believe we have agreed offline that I was referring to NSFNET1 (phase I) & NSFNET2 (phase 2) backbone RFP for T1 & T3 backbones.

What I was calling NSFNET1 backbone ... was the RFP for "T1" backbone which was "won" by Merit, IBM, & MCI (for $11.2m, if I remember right), and NSFNET2 backbone was for RFP for "T3" backbone. Both the NSFNET1 backbone and NSFNET2 backbone were heavily subsidized by commercial sources far in excess of the RFP bid awards/funding by the federal gov:
https://www.garlic.com/~lynn/2000e.html#10

Earlier NSFNET/CSNET efforts funded by NSFNET were shoestring (aka not the heavy commerical subsidy of later activities) ... somewhat related:
https://www.garlic.com/~lynn/99.html#37a

only slightly related:
https://www.garlic.com/~lynn/2001h.html#65

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,alt.folklore.computers
Date: Tue, 07 May 2002 16:02:21 GMT

hfbonney writes:
Well, MAP and TOP were ISO stacks over 802.4 token bus and over ethernet, respectively. MAP (Manufacturing Automation Protocol) added things like mini-MAP where devices were connected at Layer 2 within a manufacturing "cell". There must have been more implementation work done on this standard for quite a while. I think Boeing went for it, for one, though it was GM that started it (?). Does it still exist at all?

but was it an ISO OSI stack?

ANSI X3S3.3 had standards responsibility for approx. network/transport level responsibility and fed into the corresponding standards body at the ISO level. the message was that x3s3.3 could work on HSP (high speed protocol) but that the ISO group wouldn't pass it as a standard ... because the charter for that standards group was that standards had to conform to the OSI model (and the ISO group responsible for lower level standards activity also had charter that stated they could only pass standards that conformed to the OSI model).

That doesn't say that there weren't other ANSI and ISO groups that could pass standards ... which didn't require conforming to OSI model ... especially if they were in specialized industries.

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

Why are Mainframe Computers really still in use at all?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Mainframe Computers really still in use at all?
Newsgroups: alt.folklore.computers
Date: Tue, 07 May 2002 16:13:57 GMT

"Russell P. Holsclaw" writes:
So, to run PCP on a model 65 was absurd in the extreme. I'm pretty sure the IRS box had at least 512K (that seemed like a lot in those days :-) ), although I believe it was possible to buy a mod65 with only 256K, but no less. The core arrays came in 256K increments, IIRC. In fact, much of the speed advantage of the 65 came from interleaved core cycles, which probably required more than the 256K configuration.

unless they might have had a dedicated application that took all of the machine all of the time ... I know one customer with such an application ... they were eventually resorting to tweaking DOS so that it would run on 370/165 (pre-relocate).

360/50 had 2mic memory ... 360/60 & 360/70 were to have 1mic memory ... before first customer ship, memory technology was upgraded to 750ns memory and the model numbers changed to 360/65 & 360/75. There were some 360/65s early-on running with 256k ... but operating system requirements eventually forced customers to larger memory configurations.

note/update:

I remember reading an early document about 360/6x machine with virtual memory having one, two, and four processors. I sort of had vaque recollection that it was model number other than 360/67.

however, i've subsequently been told that 360/60 was with 2mic memory and 360/62 was with 1mic memory. both models never shipped, and were replaced with 360/65 with 750ns memory. the 360/67 then shipped as 360/65 with virtual memory ... only available in one (uniprocessor) and two processor (multiprocessor) configurations

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++
Date: Tue, 07 May 2002 17:58:18 GMT

"Rudvar Alswill" writes:
The layered approach, really nothing to shout about, was not a OSI achievement. They borrowed this from IBMs SNA and Honeywells network. OSI contribution seems almost negative, giving people the wrong ideas and mindset about networks.

note that IBMs SNA implementation was hardly layered. might say that it was the opposite of layered. there has been some folklore that a lot of SNA was driven by a project that I was involved in as an undergraduate that produced the first PCM (plug compatible) controller.
https://www.garlic.com/~lynn/submain.html#360pcm

the internal corporate network (larger than arpanet/internet) for much of the early life (until approx. '85) was not SNA based. In fact, SNA didn't even have a "network" layer ... it was oriented towards providing large scale, centrialized terminal control operation. The first appearance of anything resembling networking was with APPN. The SNA group non-concurred with the announcement of APPN ... and there was a 3 month delay while the issues were resolved. The final announcement letter was carefully crafted to not directly link APPN (& networking) and SNA in any way what so ever.

my wife spent a very short stint early on with SNA architecture group. this was before she went to pok with responsibility for loosely-coupled architecture and wrote Peer-Coupled Shared Data architecture (basis for IMS hotstandby and later sysplex). The loosely-coupled/cluster stuff was also not SNA.

random past posts:
https://www.garlic.com/~lynn/subindex.html#network
https://www.garlic.com/~lynn/subindx2.html#network
https://www.garlic.com/~lynn/subpubkey.html#networking
https://www.garlic.com/~lynn/subtopic.html#hacmp

misc. other folklore:
https://www.garlic.com/~lynn/2000b.html#69 oddly portable machines.

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,alt.folklore.computers
Date: Wed, 08 May 2002 14:01:58 GMT

Dirk Fieldhouse writes:
A merged implementation should also be correct in the sense of conforming to the requirements of the relevant OSI standards and profiles. There is/was absolutely no requirement for any internal interfaces according to the specifications. Layering was a module structure intended as a functional breakdown to facilitate development of specifications by separate committees.

that is not what was said in the ansi x3s3.3 (responsible for level3/4 standards) meeting as to what the corresponding ISO (level3/4) group would do if x3s3.3 passed a standard that didn't follow/include level3 interfaces ... i.e. HSP (high-speed protocol) ... going from level4/transport directly to IEEE 803 (LANs) ... which is about the middle of level3, aka IEEE 803 subsumes level1, level2, and part of level3/network.

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

Why did OSI fail compared with TCP-IP?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,alt.folklore.computers
Date: Wed, 08 May 2002 14:23:51 GMT

Anne & Lynn Wheeler writes:
that is not what was said in the ansi x3s3.3 (responsible for level3/4 standards) meeting as to what the corresponding ISO (level3/4) group

from some long ago trip report ... as an aside, I believe that there was a talk given at Aug89 IETF meeting at stanford that the "fastpath" had been further reduced to 120 instruction (ref. at the end).

Date: Mon Apr 24 13:44:57 1989
From lynn
Subject: ANSI standards

Quicky note on ansi x3s3.3 and xtp meetings last week. More information coming as time allows.

A "high speed networking & transport protocol" proposal was submitted by the xtp people at the x3s3.3 meeting. After various discussions it was decided to submit a "study proposal for high speed protocols" to the x3 committee ... the work product of which will be some number of protocol proposals.

Problems with the original protocol proposal were numerous. Many people objected to it violating the OSI reference model (and in fact it is not possible to submit a protocol proposal to X3 that violates the reference model ... although it is possible to approve an ANSI standard that does violate the reference model ... but that takes some fine work ... case in point are the LAN protocols ... especially with FDDI coming up thru level 1 and 2 well into level 3).

The other camps were that existing protocols could be modified ... and then of course the XTP camp. Existing protocol modification camp doesn't adequately take into account that hardware/technology (x3s3.3 is responsible for levels 3 & 4) is eating them from below (and high-speed protocol standard will have to face that reality).

The current plan is to attempt having the work group responsible for the high-speed protocol study to co-schedule the meetings with the XTP TAB meetings.

Also during the meeting, I had a talk with ??????. He mentioned that he just got a hard copy of a paper from Berkeley that mentioned they have done some sort of enhanced perfomance TCP/IP that gets the pathlength down to 200 instructions (modifications to mbuffs, timer handling, interrupt handling, etc). Jacob mentioned that he would send me a copy.

... snip ... top of post, old email index

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

Timecard stupidity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Timecard stupidity
Newsgroups: alt.folklore.computers
Date: Thu, 09 May 2002 14:55:16 GMT

CBFalconer writes:
Very vaguely. Somebody was trying to get shipping credit to borrow money against shipments. They shortly went broke. Somewhere around the mid '80s.

i don't know if they were actually shipped ... i seemed to remember story they were in boxes and counted by some audit group. I don't have it handy but i thot i had run across URL on some newspaper article of the time.

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

Spotting BAH Claims to Fame

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Spotting BAH Claims to Fame
Newsgroups: alt.folklore.computers
Date: Thu, 09 May 2002 15:04:05 GMT

jmfbahciv writes:
My group produced all manuals that were done on-line across all product lines. My claim to fame within that group was convincing all writers to do manuals on-line. Before I started my campaign, most documentation was produced using typewriters. This cause docs to get shipped sometimes a year after the software shipped. I figured I could cut that lag down to a month or two if we did the prep production on line. Then, finally, a year or two after I left that job, they gave the supervisorship of that group to people who really knew something about printing (newspaper production background) and typesetting.

we thot we had big deal when they went to managing and printing the 370 principles of operation manual online with CMS and script. The early printed versions of these weren't quite the same quality as the normal manuals since they were being done eith 1403 TN chain with ribbon. Quality got better when they started using 3800 page printer.

A big incentive for using script was conditional logic. The principle of operations manual was really selected pieces from a larger document called the "red book" or the 370 architecture manual (and internal only document). When printed as the 370 architecture manual ... there was the full specifications. When printed as the 370 principle of ops ... all the detailed specifications disappeared and just got the public document.

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

Are you sure about MONDEX?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are you sure about MONDEX?
Newsgroups: alt.technology.smartcards
Date: Fri, 10 May 2002 19:32:53 GMT

kgold@watson.ibm.com (kgold) writes:
So, when someone breaks the system to the point where they are able to add money to a card without subtracting it from another card , what happens? How is this detected?

it has been awhile ... but i believe mondex cards were suppose to have secret keys in waiting ... and that if anybody broke the current secret key ... some sort of signal would be initiated that would eventually propagate out to all cards to upgrade to the next available key in waiting.

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

Are you sure about MONDEX?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are you sure about MONDEX?
Newsgroups: alt.technology.smartcards
Date: Fri, 10 May 2002 19:34:53 GMT

oh yes, random past mondex refs:
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/2002e.html#14 EMV cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested

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

Multics hardware (was Re: "Soul of a New Machine" Computer?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics hardware (was Re: "Soul of a New Machine" Computer?)
Newsgroups: alt.folklore.computers,alt.os.multics
Date: Sat, 11 May 2002 10:24:53 GMT

Brian Inglis writes:
Any background available on what Explorer Posts did/were?

there was also a post at los gatos lab (flags stood to the side of the lobby). the post originally had several VM/CMS accounts on LSGVMA.

the los gatos lab. was originally advanced system divison built in the '60s. early on they did stuff like AM0 ... i believe effectively precursor to vsam. it was peculiar bldg. on 200 acres over the hill from san jose dump. it was rambling 1 story bldg. built with special run of 5'(?) wide redwood plywood (inside & out). later years was particular problem as there was continual problem with scavenging parts ... since there was no place to buy it. lsg did work on the ibm atm machine, jib-prime (processor in the 3880 disk controller), blue iliad (1st 32-bit 801 risc chip). it also was first to use scanning electronic microscope to analyze running microchip. they had several GE-Calma chip design stations ... and of cours the LSM ... los gatos state machine ... original hardware logic simulator (or sanitized version ... logic simulator machine ... precursor to YSM & EVE). it also had microwave tower on top of the hill above the dump with line of site between the bldg. 29 (aka los gatos lab) and the roof of bldg. 12 on the main plant site that ran 45mbit (T3) collins digital radio (there was similar setup between bldg. 12 and STL/bldg.90 with the tower on the ridge to the west of santa teresa)/

A couple of years ago, bldg. 29 was demolished and land sold off for housing development. It was off guadalupe mines road ... just off of camden (about halfway between camden/blossom hill intersection & camden/almaden xway). The post was then moved to almaden research (where i think it may still live).

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

Siemens ID Device SDK (fingerprint biometrics) ???

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Siemens ID Device SDK (fingerprint biometrics) ???
Newsgroups: alt.computer.security
Date: Sat, 11 May 2002 15:23:25 GMT

"Spelcher" <sam@@biomassmedia.com> writes:
I have looked all over the net and can't find a thing about where to get siemens SDK for their line of fingerprint biometric technology. This is a fingerprinting device that has been embedded into mice and keyboards for login authentication into windows. If anyone can point me in the right direction or knows of a good forum etc that would be greatly appreciated.

they were demo'ing it at cardtech/securetech a couple weeks ago in new orleans.

they (joint infineon/siemens) also had a display that had 8in wafer that was being repeatedly flexed by two arms that bent two edges of the wafer until they met and then back to straight. they use silicon wafer manufacturing technology to create the fingerprint sensor ... and were demonstrating that they can put the sensor on a 7816 card and it will meet the ISO "flexing" standards.

so in addition to the mice & keyboards ... they also showed the sensor in a 7816 card.

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

Amiga Rexx

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amiga Rexx
Newsgroups: alt.folklore.computers
Date: Sun, 12 May 2002 16:05:47 GMT

"Jim Mehl" writes:
Yes, of course. PC's have had several versions of REXX from early on that ran under DOS, Windows, OS/2 and later Linux.

... & of course Mike originally created REX on CMS in the late '70s. I beileve there was some copyright problem with "rex" and the name was changed to "rexx" before it was released as product. 20mar2000 was 21st b'day.

the rexx language association
http://www.rexxla.org

ANSI standard x3.274-1996
http://www.rexxla.org/Standards/standards.html

Rexx links (including operating system & amiga pointers):
http://www.rexxla.org/Links/links.html

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

Amiga Rexx

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amiga Rexx
Newsgroups: alt.folklore.computers
Date: Sun, 12 May 2002 21:06:32 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
comp.lang.rexx

check the n.g. for the posting about rexx's 21st birthday:
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000

warning drift ... the above references is an agenda for annual vmite meeting ... is was held very year at sjr (couple hundred people from around the world) usually the week before SHARE. one year, the hottest after meeting activity was the recently opened (original, very first) chuck e. cheez on kooser (just after the blossom hill/kooser fork; a couple blocks from the old almaden winery).

besides Mike's talk on REX ... there was Jim's talk on (first relational database) System/R.

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

Amiga Rexx

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amiga Rexx
Newsgroups: alt.folklore.computers
Date: Sun, 12 May 2002 23:26:20 GMT

"Jim Mehl" writes:
OK, but then VMITE got changed to CCITE or something like that. Woody used to do a wonderful dinner at Germania. Does he still do that? Jim Mehl

germania hall was dinner convention before chuck e. cheez ... and they didn't do chuck e. cheez every night. three weeks ago was walking by germania hall ... but decided have dinner down the street. notice that in the old vmite agenda ... woody gave a talk on dwss ... which was a feature put in primarily in support of system/r. I haven't been to ite meeting since taking the early out ... but i have managed to periodically make it to a "fridays" since then (something that Jim Gray and I sort-of started before he went to tandem).

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

Amiga Rexx

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amiga Rexx
Newsgroups: alt.folklore.computers
Date: Mon, 13 May 2002 03:22:17 GMT

"Jim Mehl" writes:
I don't remember ChuckECheese meetings. Perhaps that was after my time. I always thought you and Vera Watson did the VM/CMS changes for System R. Where are the Friday meetings these days. I can still move around <grin>. And perhaps a VMITE reunion should be considered. Jim Gray and Mike Blasgen organized a System R reunion in 95 or so and it was very successful. The last I heard Woody was at cmslives@somethingorother. Jim

Vera ... RIP on Annapurna
http://www.sdcnow.org/septNews4.htm ( 404 )
http://dynaweb.oac.cdlib.org/dynaweb/ead/stanford/mss/m1220/@Generic__BookTextView/196 American Women's Himalayan Expedition, Inc. : files
http://lomaprieta.sierraclub.org/lp0012_TheSeventies.html
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Vera.html Vera Watson

al griefer (still doing fridays) was the catcher in Endicott for system/r code for what became sql/ds (later transferred to SJR). original fridays were frequently at a deli called the courtyard in the shopping center at bernal & santa teresa (they are now periodically held at the same place ... but it is now a mexican restaurant). there was also (later) an erik's deli that opened up across from the main plant site (it is still there) ... i'm sure it was purely coincidental but for a long time my name was on the door to the back/side room and they would let us have pitchers of anchor steam at discount.

jim & I were keynote speakers at nasa meeting in santa cruz a year ago.

system/r reunion
http://www.mcjones.org/System_R/SQL_Reunion_95/

random old rexx announcement from google groups:
http://groups.google.com/groups?q=cmslives&hl=en&selm=91324.162448CATHIE%40SLACVM.SLAC.STANFORD.EDU&rnum=1

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

GE 625/635 Reference + Smart Hardware

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: GE 625/635 Reference + Smart Hardware
Newsgroups: alt.os.multics
Date: Mon, 13 May 2002 19:44:58 GMT

"Douglas H. Quebbeman" writes:
Although I have yet to install it and play with it, Hercules is said to provide full emulation of System/360 and some later hardware, to the point of being able to run, say, MVS/JES2, and support multiple virtual 3270 terminals.

The DEC VAX emulator is starting to become usable now... it can actually run OpenVMS and permit installation of software packages.

A couple of 7094 emulators are out there, too...

What I haven't figured out yet, is if these emulators are written by people who avoid corresponding with naysayers, or if they simply take such correspondence as a gauntlet tossed to the floor...

360/370 channel programming at the channel interface is very straight-forward. However, lower-level device stuff can get complicated and unique per device (i.e. like combinations of parameters).

some of the 360/370 platforms have real live hardware that look, taste, and feel like real channel interfaces and allow attachment of real devices. the emulation then only has to worry about the simulation of the direct channel programming fetch and hand-off.

there typically is a much smaller set of devices that are simulated on other kinds of devices ... like 3270x into windows, ckd disks on scsi, 3420/3480 tapes on dat tapes, etc.

It isn't so much the channel emulation that is the issue ... in fact, CCWTRANS from CP/67 copies and redoes CCWs from virtual space to real space is a pretty clear example ... if the emulator (i.e. CP/67 is an 360 emulator providing virtual machines ... but happens to run on the same 360 hardware that it is emulating). Another example from 25 years ago are the HYPERchannel remote device adapter. There was some code that collected up the CCW program, slightly massaged them and then downloaded them into a remote NSC A51X box which emulated IBM channels and allowed attachment of real 360 controllers and devices. NCAR used the function to implement a SAN on IBM ckd disks .... i.e. a ibm 370 played the games with A51x boxes but the actual transfer to/from disks involved Crays (and some number of other types of computers).

The TRP era of early '90s had LANL commercializing their internal filesystem as DataTree (thru General Atomics), LLNL commercializing their internal filesystem as Unitree (also thru General Atomics), NCAR commercializing their stuff (as Mesa Archival) and NASA/AMES commercializing their stuff (I don't remember their product name). All four used NSC HYPERchannel in one form or another.

misc. hyperchannel refs:
https://www.garlic.com/~lynn/subnetwork.html#hsdt

the other aspect was vendors who built plug-compatible (PCM) hardware that looked & tasted like ibm devices and attached to real ibm channels:
https://www.garlic.com/~lynn/submain.html#360pcm

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

ibm icecube -- return of watercooling?

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ibm icecube -- return of watercooling?
Newsgroups: comp.arch,comp.arch.storage
Date: Mon, 13 May 2002 19:56:13 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Real UPSs are fine, from what I have heard (though I have never used one), but 95% of what are sold as UPSs nowadays aren't. In particular, a real UPS will carry on providing smooth current even when there is a lightning strike to the supply line nearby. Many of the cheaper, so-called UPSs will merely provide power if the supply disappears fairly cleanly.

the high grade ones are two separate pieces the PDU (power distribution units) and the UPS (uninterruptable power supply).

I once visited a commerical data center that was so sensitive to things like lightning strikes, etc ... that they brought in the company that builds that top of the line PDU and said we are hiring three engineering companies to work with you to redesign the PDU to meet our requirements (this was about 5-6 years ago) ... and you can have the results as long as you build what we needed. I was told that within a year afterwards ... there was already 1200 of these new PDUs installed in just the DC metropolitan area.

The commercial PDUs might have two or more separate feeds from different power sub-stations, a bank of batteries and diesel generators. The batteries are primarily there until the diesel comes online. Real operations tend to also run off the diesel at least one hour a month to verify that everything is in working order.

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

Pardon my ignorance,

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pardon my ignorance,
Newsgroups: alt.folklore.computers
Date: Mon, 13 May 2002 23:27:06 GMT

slavins@hearsay.demon.co.uk@localhost (Simon Slavin) writes:
Their new coined-word is 'blade' for a bus-card. Those comms boxes full of modems-on-cards now have 'blades'. I can see what they mean but it does seems to make computing into something vicious.

I vaguely remember some executive making some statement about needing a really vicious marketing plan.

blades may be related to that.

also remember data-blades ... from the stonebreaker object/relational company that Informix bought (which was then in turn bought by ibm).

with respect to rack-mount horizontal blades(?) and forced cooling from special ducks in the side of the racks (long ago and far away):
https://www.garlic.com/~lynn/2000c.html#21
https://www.garlic.com/~lynn/2000c.html#22

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

Pardon my ignorance,

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pardon my ignorance,
Newsgroups: alt.folklore.computers
Date: Tue, 14 May 2002 17:36:03 GMT

Eric Sosman writes:
Here again we see IBM's innate conservatism at work: they kept on using ducks long after the rest of the industry had switched to the much cheaper and lower-maintenance pigeon. Some claimed it was just TJW Jr. feathering his nest, but an IBMer I once knew said their engineering folks had studied alternative birds -- geese, in fact -- and decided they were all turkeys and would never fly. A sad story, eider way.

those sort of slips of mine are well documented. in the early '80s there was somebody that sat in the back of my office for 9 months taking notes on how i communicated, went to my meetings with me, had logs/copies of all my email and instant messaging. The analysis turned into stanford phd (joint language and computer ai), papers and a book or two (more recent one on some of the work was "knowledge machines" published in '95). one slight consolation is that I don't have to take it as a sign of age.

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

Real man-in-the-middle attacks?

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Real man-in-the-middle attacks?
Newsgroups: sci.crypt
Date: Wed, 15 May 2002 20:03:23 GMT

NOSPAMperlmodules@lunkwill.org (Jason) writes:
Okay, this answers a different question from the one you asked, partly because somebody already answered the question you did ask, but mostly because I think the answer to the other question is so interesting. :)

The important function served by certs is to correlate what you asked for (www.google.com) with what you got (a CA-signed cert for www.google.com). That's why your browser freaks out if the remote site tries to redirect you to another site, say g00gl3.com, because an attacker might hold a valid certificate for the domain you didn't ask for.

and server fingerprints in the site's main logo, which the client then > manually verifies - this is just a shared-secret you established > beforehand, and the attacker will likely discover it and replace the > image with an altered one).

note that since all the CAs rely on the domain name infrastructure as the authoritative agency for certifying domain names when issuing domain name certificates ... one of the domain name infrastructures risks is also to subvert the domain name infrastructure just prior to requesting a domain name cert .... aka both end users as well as CAs are at risks with attacks on the domain name infrastructure.

One of the CA-oriented proposals to improve the domain name infrastructure for the purposes of CAs being able to rely on (trust) the integrity of the domain name infrastructure when they are going to go thru the certification process for issuing a domain name server certificate .... is to have people register public key in association with domain names.

That and other work in DNSSEC also improves the integrity of the domain name infrastructure for everybody (not just the CAs which require it in order to be able to rely on the validity of the associations in the certificate) ... but effectively also obsoletes much of the need for the SSL domain name certificates at all; aka you can trust the information that you get from the domain name infrastructure, the domain name infrastructure already supports serving up arbritrary information that maps to a domain name (not just an ip-address) .... so the domain name infrastructure could serve up both the ip-address and any registered public key in the same operation.

since the domain name infrastructure would have been strengthend (in large part because CAs have to be able to trust domain name infrastructure) ... then both the served up ip-address and public key can be trusted (certificates are trusted associations because of the ca signature; trusted domain name infrastructure can also provide trusted associations ... not only ip-addresses but also public keys ... w/o actually requiring certificates).

random refs:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

misc glossaries (including merged security glossary):
https://www.garlic.com/~lynn/index.html#glossary

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

Formal Classification for Security Topics

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Formal Classification for Security Topics
Newsgroups: sci.crypt
Date: Wed, 15 May 2002 20:14:17 GMT

shahram@sharif.edu (Shahram) writes:


Hi,

I'm looking for a formal classification of computer/network security
project topics so that I can categorize the related projects in
separate groups.
A very high level classification would be:
1. Protection
2. Detection
3. Response
However, this is a very general classification and most of the
projects fall into more than one category.
I have made another list of categories which is given below:

1. Hacking/cracking, and DOS attacks
2. IDS and auditing techniques
3. Firewalls
4. OS security
5. VPN
6. Security in distributed computers and networks (except Internet)
7. Internet protocols security (including IP, IPSec, TLS, S/MIME, ...)
8. Electronic payment systems (and electronic commerce) security
9. Wireless and mobile security
10. Authentication, identification, and access control techniques
11. Cryptographic algorithms and protocols (including key
distribution)
12. CA and PKI (digital signature techniques)
13. Database security
14. Smart card security
15. Multi-media security
16. Computer viruses
17. Security standards and policies

I would like to know if there is any other category that could be
added to the above list or maybe some of the categories should be
merged.
Is there any formal classification for what I am looking for? Any
comment/reply is highly appreciated.

Thanks in advance,

I was updating the taxonomy for the merged security glossary after I picked the NSA Intrusion Glossary as well as some recent SC27 glossary stuff.

I eventually added a high-level for "security software" ... various kinds of IDS, firewalls, virus checkers, etc (primarily as a result of a lot of the NSA intursion glossary structure). I also found that SC27 is big on evidence, proof, audits, and time-stamping ... so added a high level category for evidence. ... refs:
https://www.garlic.com/~lynn/secure.htm .... merged security glossary & taxonomy

some notes on sources:
https://www.garlic.com/~lynn/index.html#glossary

I already had a high level category for risks & risk management. risk management sort of subsumes protection, detection and response as well as overlapping evidence and audit (as well as security software).

risks then subsumes threats, attacks, vulnerabilities and some other categories.

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

Coulda, Woulda, Shoudda moments?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Thu, 16 May 2002 00:24:06 GMT

ted@loft.tnolan.com (Ted Nolan <tednolan>) writes:
I had the realization a few years back that I could have invented the world wide web in 1986. I think I had the skills (I was learning sockets, and had played a little with suntools), I had the equipment (Sun2s with SunOS 1.4 connected via ethernet and packet radio), and I had the need (enabling different army units to keep their commander updated on their latest status). The only problem is that, of course, I didn't think of it. (And it may be just as well, I probably would have based the markup on nroff :-)

script had been done by madnick in the middle 60s on cms at the science center ... it & runoff had a lot of simularities. Later, "G", "M", & "L" also at the science center added GML (from their initials) to cms script circa 1970. CERN was a longtime vm/cms installation from sometime in the early '70s (there was the great CERN TSO/CMS "bake-off" report to SHARE in 1974 ... which inside IBM got classified IBM Confidential Restricted ... available on need-to-know-only basis, aka most IBMers weren't to be allowed to know what was in the CERN SHARE report).

for something else that could have been different ... that people that wanted to do sun came and wanted to know if the corporation would do it. there was an evaluation done at PASC (palo alto science center, cms of course was at cambridge science center ... cms having been cambridge monitor system before being made more acceptable by changing it to conversational monitor system). In any case, three other groups around the company came into PASC for the evaluation ... and all claimed to be doing something similar but much better. As a result, the company declined to do sun. The sun guys then looked for some other way to get it started.

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

Why are Mainframe Computers really still in use at all?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Mainframe Computers really still in use at all?
Newsgroups: alt.folklore.computers
Date: Thu, 16 May 2002 00:33:50 GMT

ehrice@his.com (Edward Rice) writes:
Coast & Geodetic was at Commerce, btw. US Geologic Survey was at Interior. I'm not sure which you're thinking of. USGS, at that time, had two castes of personnel -- the older rockhounds and hydrologists with dirty boots and muddy Jeeps, and sharp young dudes who knew computers and hadn't come up through the science ranks for the most part. Cafeteria tables didn't tend to mix the two, and they had different plans. One group was plotting toward a good retirement and doing the balance of their scientific work before that happened, with as little of this computer tomfoolery as possible; the other gang wanted to elbow the first ones aside and take over and Get Things Done Right, with computers. It was actually a fair balance of interests, and by the time the younger group actually did move up into control, they'd acquired more respect for their elders. USGS went through a shift, though, from a lot of people who felt that handwritten notes /were/ a final product, to people who weren't sure if a report could be turned out without a computer.

the young computer turks have played out in a number of places and times.

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

Digital signature

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Digital signature
Newsgroups: comp.security.misc
Date: Thu, 16 May 2002 12:52:17 GMT

treebirds@hotmail.com (Andrijani) writes:
As we know digital signature is one kind of authentication method. From what I read, it seems that digital signature is quite strong enough from technological point of view. I also agree that banking industries that provide on-line services have to adopt this method. However, I would like to know whether using digital signature will really protect net banking? Can it decrease customer fearness to conduct on-line transaction?

Any comments are welcomed,

digital signatures can demonstrated message tampering in-transit and probably where message originated.

there is the "SET" protocol from a couple years ago for online transactions. however, it didn't significantly improve the situation compared to SSL (doing much more than protection of data in-flight).

several states and the federal gov. have passed electronic signature laws ... that include/cover things in addition to public key cryptography.

one of the exploits in the current SSL as well as SET was data at rest, aka the merchant needs to keep a transaction file/audit which becomes a vulnerability point. the financial industry payment standard x9.59 addressed some number of those shortcomings.
https://www.garlic.com/~lynn/x959.html#x959

aka ... the x9a10 standards working group was given the requirement for work on the x9.59 payment standard to protect the integrity of the financial infrastructure (provide end-to-end integrity for all electronic payments ... not just internet, not just credit, not just debit, not just stored-value; all).

there are a lot of ancillary issues for digital signatures ... like burden of proof and non-repudiation. there was recently series of discussions on non-repudiation on another mailing list:
https://www.garlic.com/~lynn/aadsm11.htm

one of the issues in non-repudiation is "intention" ... simple digital signature authentication can show that a message probably was transmitted from your PC and probably was not modified in transit; but doesn't show that you were actually involved in the transaction in any way. one of the EU issues in this area is the FINREAD standard in conjunction with hardware token.

The token acceptor device is a certified, closed, tamper-evident device (on par with some of the point-of-sale security modules) that has a secure display and a secure PIN-pad/entry. The FINREAD token acceptor device is responsible for accurately displaying information on what is about to be signed and that the signing doesn't occur until after the information has been displayed and a person has entered the valid PIN acceptable to the hardware token.

PC software and some hardware tokens will sign anything/everything once a valid PIN has been entered after power-on/startup. FINREAD device in conjunction with a hardware token that requires human interaction for every signature increases the probability that not only did the transaction originated from your PC ... but you actually intended to sign that specific transaction and approve the details of the contents of the transaction.

The straight-forward, simple digital signatures for making sure the message wasn't modified in transit is a long way from the attributes typically associated with a physical signature.

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

Pipelining in the past

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pipelining in the past
Newsgroups: comp.arch
Date: Thu, 16 May 2002 19:37:27 GMT

gah@ugcs.caltech.edu (glen herrmannsfeldt) writes:
In terms of instruction decode, S/360 is pretty simple, so it isn't much worse than RISC for pipelining.

The 360/91 pipelines floating point. I believe that the fixed point and address unit ran in parallel with that.

s/360 was really hard for pipelining because it allowed self-modifying instruction .... (it wasn't a harvard architecture) ... instruction decode had to constantly check if anything already executing (including the immediate previous instruction) has modified the current instruction. its easier now with lots of spare circuits to devote to things like speculative execution and instruction abrogation.

the 91/195 had 63(?) instruction pipeline/cache(?) ... a branch would drain the whole thing ... unless the branch was (back) to an instruction already in the pipeline/cache; there were all sorts of codes that attempted to get loops inside 63 instructions.

there was prototype work done on a dual i-stream 195 because so little general purpose code could take advantage of the 63 instruction cache (i.e. prevalence of branches); aka duplicate instruction counter, duplicate set of registers, add a bit to the 63 instruction cache/decode to indicate which i-stream; etc.

the 370s at the low and mid-range ... were all verticle microcode machines with something like a ten-to-one performance difference between the native microcode engine and the 370 instruction rate. At least for these machines, it was estimated that support for self-modifying instruction stream cost at least a factor of two in 370 instruction rate.

For a time, the real "strategic" follow-on to 360 was going to be FS (future systems) ... with the non-virtual-memory 370s just a temporary stop-gap. FS included an extremely complicated CISC environment (ex: a generalized ADD instruction had the microcode figure out things like adding string numbers, floating point numbers, fixed point numbers and do all the magic necessary things in real time at instruction execution). FS was finally killed .... but one could claim that the 801/RISC ideas were at least partially a reaction to FS ... with 801 being at the far opposite end of the spectrum.

Later on, there was a big push called Fort Knox that was going to make all the microcode engines in all products ... 801 processors (with some misc. bells & whistles for doing other architecture instruction simulation). Fort Knox was eventually killed but not after a fairly large number of resources was put into it. I believe that it was after Fort Knox was killed that you started seeing some number of 801 chip engineers (re-)appearing at other companies.

There is a lot of lore that a splitter group from FS went off to rochester and implemented a lot of the ideas (even tho FS was supposed to be dead) as the s/38. One might say things have finally somewhat converged with the S/38 follow-on, the AS/400 now using power/pc chips.

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

Coulda, Woulda, Shoudda moments?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Thu, 16 May 2002 22:17:09 GMT

Larry__Weiss writes:
Alohanet worked out some ideas that were later used in the Ethernet network protocol. I'm not clear how the software layers that would be comparable to TCP or IP worked in the Alohanet scheme.

this is a little like the osi thread

lots of people claim that alohanet used packets and arpanet used packets (and ethernet uses packets); and if you squint hard enuf all packets look the same.

note however, that arpanet was traditional homogeneous host-to-host operation. the great thing in tcp/ip was the 1/1/83 internet/gateway stuff ... i.e. there could large numbers of different networks that could be gatewayed together. The side claim is that one of the reasons that the internal network was larger than arpanet/internet until possibly mid-85 ... was that each node effectively had a form of gateway.

The traditional arpanet packet claim is that if some path failed, the IMPs could figure out alternative paths and packets would be rerouted (there weren't predefined end-to-end path/circuit definitions). The other thing I've heard (although not explicitly verified) was that by the time IMP population as approaching 200 in the late '70s that it was a good thing that ARPANET had mandated 56kbit circuits ... because the internal IMP route/path related administrative chatter was consuming a significant amount of bandwidth.

TCP was a connection end-to-end protocol devised and implemented on the IMP host-to-host arpanet ... and then later ported to IP (with the host-to-host IMP arpanet coverting to IP internet in the 1/1/83 switch-over).

misc. osi refs:
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

random internet
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/subindex.html#network
https://www.garlic.com/~lynn/subindx2.html#network

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

Biometrics not yet good enough?

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometrics not yet good enough?
Newsgroups: talk.politics.crypto
Date: Fri, 17 May 2002 11:13:06 GMT

Max Polk writes:
Also, many fingerprint biometric devices can be compromised with very little effort, see http://www.counterpane.com/crypto-gram-0205.html#5

there is still a cost/benefit possible.

lets say that the issue is plastic cards that people have in their wallets and there is a large set of the population that write their PIN number on their card. They also leave their fingerprints on their cards.

So what is the risk difference between the ease of lifting a PIN that is written on a card and fraudulently typing it in vis-a-vis lifting a fingerprint off a card and fraudulently entering a false fingerpint?

I would contend that it is harder to fraudulently enter the fingerprint than it is to enter the PIN. Now the question is it sufficiently harder to fraudulently enter a fingerprint (compared to fraudulently entering a PIN) that it justifies the cost of a fingerprint infrastructure vis-a-vis PIN-pads?

"little" is relative ... it comes down to cost/benefit.

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

Coulda, Woulda, Shoudda moments?

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Fri, 17 May 2002 16:57:27 GMT

misc. others:
http://nethistory.dumbentia.com/
http://www.rfc-editor.org/history.html
http://www.isoc.org/internet/history/
http://www.zakon.org/robert/internet/timeline/
http://www.matrix.net/publications/mn/mn1101_routing_and_addressing.html
http://www.anderbergfamily.net/ant/history/

misc. history:
https://web.archive.org/web/20050324023349/http://daemonnews.org/199903/history.html
http://ed-thelen.org/comp-hist/BRL64.html
http://ed-thelen.org/comp-hist/on-line-docs.html
http://www.computerhistory.org/
http://www.clock.org/~jss/work/mts/30years.html
http://www.computer.org/annals/
http://www.computerhistory.org/timeline/topics/components.page
http://www.mitre.org/pubs/showcase/sage/sage_impact.html
https://web.archive.org/web/20021213035609/http://www.mitre.org/pubs/showcase/sage/sage_impact.html
http://www.punch-card.co.uk/
https://people.computing.clemson.edu/~mark/acs.html
http://www.columbia.edu/cu/computinghistory/
https://www.leeandmelindavarian.com/Melinda#VMHist
http://vm.marist.edu/~vmshare/
https://web.archive.org/web/20030813135723/http://www.cbi.umn.edu/collections/inv/corpman.htm
http://accl.grc.nasa.gov/archives/index.html
http://www.brouhaha.com/~eric/retrocomputing/ibm/stretch/
http://www.beagle-ears.com/lars/engineer/comphist/

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

Coulda, Woulda, Shoudda moments?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Fri, 17 May 2002 17:11:23 GMT

Alistair Gale writes:
Can you point me to a timeline which covers the evolution of Arpanet via whatever intermediate forms there were to the Internet? Especially sites with character studies of the pioneering engineers.

I'm also interested in anecdotes about the snubbing of Jerry Pournelle and the role Al Gore played in opening up the 'net to the rest of us. (Byte Mag, the Information Superhighway......)

or some direct pointers to past posts:
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/98.html#59 Ok Computer
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#40 [netz] History and vision for the future of Internet - Public Question
https://www.garlic.com/~lynn/99.html#146 Dispute about Internet's origins
https://www.garlic.com/~lynn/2000.html#49 IBM RT PC (was Re: What does AT stand for ?)
https://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#78 Free RT monitors/keyboards
https://www.garlic.com/~lynn/2000d.html#56 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#58 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#59 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
https://www.garlic.com/~lynn/2000d.html#76 When the Internet went private
https://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000d.html#78 When the Internet went private
https://www.garlic.com/~lynn/2000d.html#80 When the Internet went private
https://www.garlic.com/~lynn/2000e.html#5 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#10 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#13 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#31 Cerf et.al. didn't agree with Gore's claim of initiative.
https://www.garlic.com/~lynn/2000e.html#38 I'll Be! Al Gore DID Invent the Internet After All ! NOT
https://www.garlic.com/~lynn/2000e.html#39 I'll Be! Al Gore DID Invent the Internet After All ! NOT
https://www.garlic.com/~lynn/2000f.html#44 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#45 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#46 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#47 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#49 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#50 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#51 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2002b.html#40 Poor Man's clustering idea
https://www.garlic.com/~lynn/2002g.html#40 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002g.html#45 Why did OSI fail compared with TCP-IP?

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

Coulda, Woulda, Shoudda moments?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Fri, 17 May 2002 17:24:19 GMT

& while I've been known to repeat boyd stories:
https://www.garlic.com/~lynn/subboyd.html#boyd

i don't remember repeating jerry stories ... try
http://www.jerrypournelle.com/tourguide.html

i've seen him give his bronco slide-show.

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

Pipelining in the past

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pipelining in the past
Newsgroups: comp.arch
Date: Fri, 17 May 2002 20:15:12 GMT

gah@ugcs.caltech.edu (glen herrmannsfeldt) writes:
Sounds like PL/I, which allows all those operations and conversions.

well the thing that went along with the 801 project in the '70s was CPr (control program risc, lots of CP things running around at that time) and pl.8 (an almost pli). the thread was that pl.8 generated code at compile time would compensate for lack of hardware features in 801 (rather than FS moving all the complexity into microcode/hardware, the hardware was drastically simplified and all the complexity moved into the compiler).

801 was not only swung to the opposite end of the specturm from the stand-point of harvard architecture and no consistency between i-cache & d-cache (eliminating possibility of modifications of instructions) ... but also no cache consistency at all (i.e. any smps had very, very weak memory consistency). some of the 801 crew had worked on "G" in the very early '70s trying to get at least 4-way very high speed SMP cache machine with extremely strong memory consistency ... 801 swung to the other end away from not only strong memory consistecny, but to no memory consistency.

At least one of the people that worked on "G" also worked on the 195 dual i-stream. ... it was probably also called something else in addition to "G"; at least the part of the effort providing software virtual 4-way SMP was referred to as "G". other people on "G" went on to work on system/r.

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

Pipelining in the past

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pipelining in the past
Newsgroups: comp.arch
Date: Fri, 17 May 2002 23:13:46 GMT

alexc@world.std.com (Alex Colvin) writes:
>well the thing that went along with the 801 project in the '70s was >CPr (control program risc, lots of CP things running around at that

was the term "risc" in use then?

can't remember ... it could have been one of those name morphs ... CPr might have been control program research .... like Los Gatos State/Simulation Machine (LSM) turned into Logic Simulation Machine ... Cambridge Monitor System turned into Conversational Monitor System, etc.

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

Is it safe to use social securty number as intranet username?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is it safe to use social securty number as intranet username?
(long)
Newsgroups: alt.computer.security,alt.privacy,comp.privacy,comp.security,comp.security.firewalls,comp.security.misc
Date: Sun, 19 May 2002 00:53:59 GMT

Machine Messiah writes:
What do the experts here think of a policy of requiring an employee to log on to an intranet using a social security number as a username?

My employer wants me to complete an online training course and they have set up a system where we can log onto their intranet individually, but they expect us to use our social security number as a username. I asked my supervisor if it were possible to change my username to something less personally vital as my SS# and said she didn't think so and she was NOT very civilized about it.

is the login a real "user" as in unix .... or is it an identifier used by some database application ... possibly some CICS application sitting behind the scenes ... aka ... there is no user in the unix or windows sense; it is just an identifier used by a database application for validation purposes (i.e. restricting the requester to only information in the database related to the SSN)?

lets say it is a database application ... an approach might be to use a totally random identifier and some PIN/password to get past the first screen. The random identifier probably would mean a new field in the database ... the SSN# is possibly already an indexed field; so using it as a psuedo userid would be a trivial effort.

The database application could possibly already exists ... some number of companies are "web'izing" various call center operations ... a person calls the call center, the call center asks for various information like SSN and mother's maiden name, date-of-birth, pin, etc. They enter the supplied information into various screen fields ... if things check out ... the call center screen proceeds with the requested transaction.

Some number of "call center" web'ising ... are trying to front-end various call center screens and applications with some form of web forms ... substituting person direct entry of the information that the call center person would be doing as an intermediate proxy typist (i.e. they are typing in what you speak to them, and then doing some simple procedural steps and then the requested transaction). In such scenarios ... the SSN# is not a userid in the traditional sense ... just the identifier used by the existing application.

A security issue then becomes the security of the web'ized call center forms vis-a-vis the standard call center operation with telephone interaction. The company might even have a can'ed package ... which would also support touch tone operation ... whether or not activiated ... which asks for you SSN# followed by a PIN. A possible web'izing process is just translating the touch-tone operation into a web form.

Some security questions (trying to compare to human call center or touch tone call center) would be:

1) what machines is the web version available from 2) is the web version just restricted to intranet or is it also availabe from general intranet 3) is the web version implemented with SSL 4) assuming a web-server passthru to database back-end application, what security is implemented on the web-server and does any of the entered data ever hit a web-server disks ... or does the web-server purely act as a protocol converter from SSL/browser to established database back-end application. 5) how isolated is the database back-end from the web-server are their filtering security procedures to drastically limit what can pass between the database back-end and the web-server

another approach is that there is some gateway router between an existing office net ... and internal intranet that has various platformed services. The gateway router runs radius for authenticating incoming connection requests (in much the same way the majority of ISPs perform internet connection authentication)

The radius authentication server needs to provide some "id" and "password" for the radius authenticated connection. Some radius servers are done by defining a system "userid" and "password" of the same information ... so the radius authorization and system login authorization use the same id & password. Various operations that have no interest in offering system login capability .... maintain a subscriber database of "ids" and "passwords" that don't correspond to any real userid on any system. This database information is just for the purposes of offering up very temporary & transient information that is quickly checked and then deleted (in the gateway). An existing database of SSN with existing PINs for an existing corporate application could be one way of providing the information for radius server function.

In this scenario the ID/password information can flow into the gateway (for the radius authentication) either in the clear or encrypted. There then is some security implication that if the information flows in the clear ... what kind of evesdropping opportunities are there.

A somewhat ancillary side issue involves web-servers that perform client authentication using a flat file of userid/password information (again these are not real system userids ... just authentication information). However, it also relatively straight-foward for web-servers to implement client authentication using radius ... and the source information is on some secure corporate database and only existis at the web-server for very, very short duration of time when the id/password is actually being checked.

For more information on radius see rfc 2865.

It is possible to go to:
https://www.garlic.com/~lynn/rfcietff.htm

and select Term (term->RFC#) from the RFCs listed by section

from the Term screen select "RADIUS" from the Acronym fastpath at the beginning of the file.

remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058

selecting any RFC number will bring up the summary in the bottom frame.

selecting the ".txt=nnnn" field fromt he RFC summary will retrieve the actual RFC.

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

Coulda, Woulda, Shoudda moments?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Sun, 19 May 2002 04:45:34 GMT

ted@loft.tnolan.com (Ted Nolan <tednolan>) writes:
Any moments when in retrospect you _could_ have revolutionized computing?

well ... a project I worked on when I was an undergraduate with a couple others built our own plug-compatible IBM controller. This is supposedly considered the origin of the IBM PCM controller business, a several billion dollar/annum industry for 30 some odd years.
https://www.garlic.com/~lynn/submain.html#360pcm

at one time I participated in this group (acorn publishing task force, not related to acorn systems that came along several years later) that started out with about 20 people ... and grew to something like 40 or so ... in silicon valley. It was looking at doing software publishing for this new thing that was coming along called Acorn. Every month or so there was a check made with Boca and they would say they had no interest in doing software ... and the task force could have the charter ... and we kept working on for this thing called Acorn that Boca was doing (eventually announced as ibm/pc). random acorn bits:
http://inventors.about.com/library/weekly/aa031599.htm
http://inventors.about.com/library/inventors/blibm.htm
https://web.archive.org/web/20021212123258/http://www.digitalcentury.com/encyclo/update/pc_hd.html
http://www.pattosoft.com.au/jason/Articles/HistoryOfComputers/1980s.html
other code names (mostly apple, but some ibm):
https://web.archive.org/web/20021122123451/http://www.dash.nl/Applesites/applemuseum/sections/codenames.html

Eventually, somebody in Boca called up and said that they changed their mind and they were interested in software and we could all continue working on it if we would move to Boca.

I somewhat participated in a project called DataHub (PC networking and fileserver) ... that was being designed and developed by a small group in San Jose GPD. Some of the code was subcontracted out to small group in Provo (one of the GPD people commuted back & forth between San Jose and Provo just about every week). At one point GPD decided to walk away from the DataHub project ... and let the group in provo assume rights to everything that they had been working on (I believe this spawned a PC networking & server company hdqtred in Provo).

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

Pipelining in the past

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pipelining in the past
Newsgroups: comp.arch
Date: Sun, 19 May 2002 15:59:42 GMT

Paul Repacholi writes:
The uV-II was what? 85 or so for shipping in numbers?

from posting on (all) vax shipments:
https://www.garlic.com/~lynn/2002f.html#0


VAX SHIPMENTS - US
------------------
1978-
SYSTEM       1984      1985      1986      1987     TOTAL
--------   --------  --------  --------  --------  --------
MVI          1,340       500         0         0     1,840
MVII             0     9,000    15,000    17,000    41,000



VAX SHIPMENTS - NON US
                 ----------------------
1978-
SYSTEM       1984      1985      1986      1987     TOTAL
--------   --------  --------  --------  --------  --------
MVI            860       100         0         0       960
MVII             0     1,900    10,000    12,000    23,900

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

Multics reference in Letter to Editor

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics reference in Letter to Editor
Newsgroups: alt.os.multics
Date: Sun, 19 May 2002 19:24:27 GMT

Toby Thain writes:
They did have A/UX a long time ago (late 80s?), so the idea wasn't totally alien to them. IIRC, memory protection was promised as part of System 7... we only had to wait 12-odd years for actual delivery...

somewhere along the line i got to play with a/ux pre-announce (i think fall '87 running on mac IIs and mac SEs, work was possibly done by unisoft). also note that next machines ran mach.
http://www.unisoft.com/about.html

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

Future architecture

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Future architecture
Newsgroups: comp.arch,comp.sys.super
Date: Sun, 19 May 2002 19:57:42 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
If it is fundamentally flawed, it is because most people cannot learn to think 'parallel' and not because it cannot be made to work (because we know it can). Now, as with most aspects of social engineering, it is extremely unclear what is a fundamental impossibility and what has merely not been tackled in an appropriate way or in a determined enough fashion.

Don't get me wrong - I regard a change to parallel working as a MAJOR task, involving probably even a change in the way that mathematics and the sciences are taught at school. But I do feel that the effort would repay itself (and not only in terms of programming efficiency). And, unless we TRY moving in that direction, we shall not discover whether the problems are fundamental or not!

one might claim that parallel is a special case of asynchronous. imagine a large number of totally independent, asynchronous operations.

one of the things that the los gatos simulation machine (LSM) had was support for asynchronous chip designs as well as combo digital/analog circuits (one of the things that los gatos worked on was the disk read/write heads). Follow-on generations of verification engines and design tools simplified things for purely synchronous clock chip designs.

the cluster supercomputers could be considered one application of loosening syncronicity (allowing greater degree of asyncronicity).

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

Questions about computer security

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Questions about computer security
Newsgroups: alt.computer.security
Date: Mon, 20 May 2002 02:33:07 GMT

"Simon" writes:
I have some wuestions about computer security :

- Do you know the CreateRemoteThread API? What are the security risks involved with it? - If you were to write a program on NT that filters incoming POP3 attachments to decide whether or not they're allowed to pass through, how would you proceed? - What are the different ways someone can steal or destroy someone else's data via the Internet? - What is a virus? What's the difference between viruses, worms and Trojan horses?

thank you for your answers

are these homework questions/assignment?

pointer to some quidelines about homework:
https://www.garlic.com/~lynn/2001l.html#0 Disappointed

one of the recommendations in the reference pointed to by the above is to read the news.announce.newusers n.g.

obtw, merged security glossary:
https://www.garlic.com/~lynn/secure.htm

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

Questions on IBM Model 1630

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Questions on IBM Model 1630
Newsgroups: alt.folklore.computers
Date: Mon, 20 May 2002 19:25:38 GMT

genew@mail.ocis.net (Gene Wirchenko) writes:
Does anyone else think that this is very similar to the datacell (?2314)? I'm not saying I think it's the same hardware, but the description of the Rube Goldberg contraption has the same air.

I have heard of no connection between the datacell (2321) and the optical library. I heard that LLNL had one but never saw one or heard any details about it. From the description it sounds more like some of the tape libraries ... maybe 3850 mass storage library (modulo the "boxes" were tapes that had to be moved to tape drive ... rather than boxes of optical strips).

univ. had a 2321 when I was an undergraduate. it was shaped vaugely like upright drum or washing machine. There were 10(?) vertical containers of vertical stips inside the machine. The machine rotated to get the right container under the read/write head (instead of a robot arm). The read/write head would withdraw the selected strip when the correct container had rotated. To insert it back there was compressed air blown to separate strips forming a gap to drop the strip back in (if things weren't correctly aligned, the strip would catch and accordion/fan-fold as the mechanism lowered).

Standard IBM CKD disk seek command is seven bytes: BBCCHHR ... where standard CC is cylinder #, HH is head #, and R is record #.

The BB comes from the datacell and selects the "bin" (i.e. container of stips).

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

next, previous, index - home