List of Archived Posts

2003 Newsgroup Postings (01/19 - 02/02)

Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Card Columns
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Card Columns
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Card Columns
InfiniBand Group Sharply, Evenly Divided
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
3745 & NCP Withdrawl?
Disk drives as commodities. Was Re: Yamhill
Card Columns
Card Columns
Card Columns
Card Columns
360/370 disk drives
oort compute bound since 12/6 nntp.el changes
oort compute bound since 12/6 nntp.el changes
oort compute bound since 12/6 nntp.el changes
360/370 disk drives
360/370 disk drives
1403 Printer
360/370 disk drives
Public key encryption
360/370 disk drives
360/370 disk drives
dasd full cylinder transfer (long post warning)
360/370 disk drives
oort compute bound since 12/6 nntp.el changes
oort compute bound since 12/6 nntp.el changes
360/370 disk drives
360/370 disk drives
360/370 disk drives
360/370 disk drives
Public key encryption
VMFPLC2 tape format
VMFPLC2 tape format
filesystem structure, was tape format (long post)
hyperblock drift, was filesystem structure (long warning)
internal network drift (was filesystem structure)
send/recv vs. raw RDMA
Disk drives as commodities. Was Re: Yamhill
Authentication w/o user ids and passwords
Authentication w/o user ids and passwords
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Microsoft worm affecting Automatic Teller Machines
Microsoft worm affecting Automatic Teller Machines
Microsoft worm affecting Automatic Teller Machines
earthlink ppp connection
Why did they make FORTRAN so hard to parse?
When/why did "programming" become "software development?"
Wanted: Weird Programming Language
founder, cambridge science center
diffence between itanium and alpha
Storing digital IDs on token for use with Outlook
When/why did "programming" become "software development?"
Storing digital IDs on token for use with Outlook
Storing digital IDs on token for use with Outlook
When/why did "programming" become "software development?"
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Disk drives as commodities. Was Re: Yamhill
Early attempts at console humor?
Early attempts at console humor?

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 19 Jan 2003 21:22:16 GMT
Ken Moore writes:
IBM seemed to find different names for a lot of concepts (c. 1970). I always assumed it was part of the strategy of pretending, when they adopted a useful idea, that they had just invented it. Could they really have been so blinkered as not to know about paging (Ferranti Atlas, c.1965) when they called it virtual memory (370 series, c.1971)?

see discussion of ctss/7094 ... and then 360/67 (part of the original 360). also some discussion of the 360/67 being one of the candidates for multics. then there was an (official) very large effort building something called tss/360 (single level store operating system) ... involving something over thousand people. lots of detail about early ctss/7094, cambridge science center, tss/360, cp/40, cp/67, vm/370, etc
http://www.leeandmelindavarian.com/Melinda/

... the original 360 was 360/30, 360/40, 360/50, 360/60, 360/62, & 360/70.

the 360/60, 360/62, & 360/70 were all going to have 1mic memory. 750 ns memory came along and the machines to use that were then 360/65, 360/67, & 360/75. as it turned it, i don't think that 360/60, 360/62, and 360/70 machines ever actually shipped.

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

http://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That


the 360/62 ... which morphed into 360/67 ... was nearly identical to 360/60 (morphed into 360/65) except it supported virtual pages with associative look aside buffer for translating virtual addresses. the 360/67 had both 24-bit virtual addressing and 32-bit virtual addressing modes.

much later when the 370s came out eventually with virtual storage ... they only supported 24-bit virtual addressing. some ten years later 3081/xa mode introduced 31-bit virtual address.

cambridge science center had actually custom modified a 360/40 with virtual addressing circa 1965 ... and built cp/40 for it. when the standard product 360/67 was available ... they ported cp/40 to 360/67 morphing it into cp/67 (an alternative operating system to tss/360 for 360/67 that later morphed into vm/370). cp/67 was running at cambridge science center and lincoln labs during 1967 ... and in january of 1968 some people from cambridge came out and installed it at the university i was at (I then picked up responsibility for cp/67 in addition to production responsibility for os/360).

posts specific to csc, 4th floor, 545tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech
slightly related future system threads:
http://www.garlic.com/~lynn/submain.html#futuresys

some past atlas references in this context:
http://www.garlic.com/~lynn/2000.html#52 Correct usage of "Image" ???
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2002.html#42 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)

boeing/huntsville did custom modified version of os/360 mvt (release 13?) that made use of the virtual memory of the 360/67 ... but didn't support paging (virtual memory was to address a fragmentation problem in mvt with contiguously allocated memory).

the initial development version of aos2 for svs/vs2 aka virtual memory version of the os/360 batch operating system (aka for 370) ... was done on 360/67 using a version of os/360 mvt cobbled together with a hacked version of CCWTRANS (virtual->real i/o translator) from cp/67.

the first code that ran on the very first engineering 370 model with virtual memory hardware support was a hacked version of cp/67 that was modified to conform to the 370 hardware relocation architecture (had different control registers and page tables than 360/67). in fact the hacked version of cp/67 for 370 had been running production for twelve months before the engineering hardware became available. there was a project that modified the virtual machine structure in cp/67 to support 370 relocation architecture instead of 360 architecture (but translated virtual 370 formated relocation tables into 360 formated "shadow" tables) ... aka provided 370 defined virtual machines instead of 360 defined virtual machines (somewhat akin to various virtual machine projects that provide 360/370/390 virtual machines on intel platforms). then a different cp/67 was hacked to operate using "real" 370 formated relocations tables. for various security reasons ... this environment operated with lots of mit & bu students ... there was

real 360/67 cp/67 providing 360 defined virtual machines on real 360/67 modified cp/67 running in 360/67 virtual machine providing virtual 370s modified cp/67 running in 370 virtual machine providing virtual 370s cms running in modified 370 virtual machine

all 12 months before the first engineering 370 machine with virtual memory support existed.

cp/67 wasn't the only alternative virtual memory system (to tss/360) built for the 360/67. univ. of michigan also built MTS (michigan terminal system) that supported virtual memory and paging on the 360/67. some mts stuff from umich:
http://www.itd.umich.edu/~doc/Digest/0596/index.html
http://www.itd.umich.edu/~doc/Digest/0596/feat01.html
http://www.itd.umich.edu/~doc/Digest/0596/feat02.html
http://www.itd.umich.edu/~doc/Digest/0596/feat03.html

posts mentioning michigan terminal system:
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000.html#91 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#44 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000f.html#52 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001e.html#13 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001h.html#24 "Hollerith" card code to EBCDIC conversion
http://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001k.html#27 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#9 mainframe question
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#45 Valid reference on lunar mission data being unreadable?
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002b.html#6 Microcode?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002d.html#49 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002m.html#28 simple architecture machine instruction set
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?

random postings mentioning cp/40:
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#37 SIE instruction (S/390)
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/98.html#33 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/99.html#126 Dispute about Internet's origins
http://www.garlic.com/~lynn/99.html#139 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/99.html#142 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/99.html#174 S/360 history
http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
http://www.garlic.com/~lynn/2000.html#52 Correct usage of "Image" ???
http://www.garlic.com/~lynn/2000.html#81 Ux's good points.
http://www.garlic.com/~lynn/2000.html#82 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#42 Domainatrix - the final word
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000e.html#16 First OS with 'User' concept?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#59 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
http://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#46 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2002b.html#6 Microcode?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#8 TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#36 Blade architectures
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002h.html#62 history of CMS
http://www.garlic.com/~lynn/2002h.html#70 history of CMS
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002l.html#22 Computer Architectures
http://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 19 Jan 2003 22:29:20 GMT
Anne & Lynn Wheeler writes:

http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)


short extract from above ... which was in turn from melinda's history:
What was most significant was that the commitment to virtual memory was backed with no successful experience. A system of that period that had implemented virtual memory was the Ferranti Atlas computer, and that was known not to be working well. What was frightening is that nobody who was setting this virtual memory direction at IBM knew why Atlas didn't work. 23

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 20 Jan 2003 00:17:11 GMT
aek@spies.com (Al Kossow) writes:
Do you know of any documents that still exist which describe the changes made to the 7094 to support CTSS ?

from melinda's document:
http://www.leeandmelindavarian.com/Melinda/
CTSS was developed on a series of IBM processors. In the 1950s, IBM's president, T.J. Watson, Jr., had very shrewdly given MIT an IBM 704 for use by MIT and other New England schools. 6 Then, each time IBM built a newer, bigger processor, it upgraded the system at MIT. 7 The 704 was followed by a 709, then by a 7090, and finally by a 7094. IBM also gave MIT the services of some highly skilled Systems Engineers and Customer Engineers, who formed its MIT Liaison Office, which was housed at the MIT Computation Center. As CTSS evolved, Professor Corbato. and his students and colleagues began to encounter problems that they knew were better addressed by hardware than by software, so they asked IBM for modifications to their processor. The IBMers in the Liaison Office had the job of finding engineers in Poughkeepsie to build the hardware extensions that MIT had determined were necessary to do time-sharing properly. By the time CTSS was in full production in 1963, the 7090 at MIT had been modified to have a second memory bank (32K words), an address relocation register, and memory protection. With these extensions to the hardware, Corbato's group was able to build CTSS into the system that became the exemplar for time-sharing systems.

-----------------------------------------------------------

7 It appears that (without a clear directive from Corporate management) IBM's Cambridge Branch Office decided to interpret Watson's original grant to MIT as authorization for them to upgrade the system at MIT whenever IBM produced a more powerful computer.


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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Mon, 20 Jan 2003 14:14:34 GMT
Keith R. Williams writes:
Aw shucks! I'm a newbie. I was in Poughkeepsie for nineteen years followed by a commutation to Burlington. So far I've served ten years here in the tundra.

I can't remember all the TLAs of the divisions I've done time in. I remember signing on to SPD and I'm in IMD now. Inbetween? I guess I could look in HRA.


i spent some time in both bldg. 14 (dasd engineering) & bldg. 15 (dasd product test) duringg 70s & 80s (although i officially worked in bldg. 28). got to help shoot some problems with 3880 (cutter). random ref to some later dasd products:
http://www.garlic.com/~lynn/2002o.html#3 PLX
some recent discussions of san jose plant site:
http://www.garlic.com/~lynn/2002n.html#55 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#38 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#41 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#45 ibm time machine in new york times?

other tales of bldg. 14&15:
http://www.garlic.com/~lynn/subtopic.html#disk

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

Disk drives as commodities. Was Re: Yamhill

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Mon, 20 Jan 2003 15:53:52 GMT
Anne & Lynn Wheeler writes:
i spent some time in both bldg. 14 (dasd engineering) & bldg. 15 (dasd product test) duringg 70s & 80s (although i officially worked in

there was strict separation between bldg. 14 (dasd engineering) & bldg. 15 (dasd product test). management structure didn't converge until you got to the top level executives in bldg. 12. the theory was that product test in bldg. 15 had complete freedom to veto release of product until it met all of their tests.

the separation theory extended to directive that nobody was allowed to have a badge enabled for access to both bldg. 14 and bldg. 15; aka a dasd engineer working in bldg. 14 had badge enabled for access to bldg 14 but not to bldg. 15; a dasd engineer working in bldg. 15 had badge enabled for access to bldg 15 but not to bldg. 14.

being totally outside the division and didn't officially work there ... the directive didn't apply to me ... so i had a badge that was access enabled for all corners of bldg. 14 as well as all corners of bldg. 15 (as well as bldg. 28 and various other places in the san jose area that i could wander into and out of).

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

Card Columns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Mon, 20 Jan 2003 18:40:39 GMT
"Shmuel (Seymour J.) Metz" writes:
Except, of course, that they didn't. S/7, S/1, 8100, S/3, PC, PC/RT, S/38; there were huge deviations from the idea of a single product line.

they weren't suppose to be compatible ... it was every model in the 360 line that was suppose to be compatible. i was told that the testimony was specifically with respect to the mainframe industry and the bunch/etc ... and each of them supposedly attempting to meet criteria of a compatible mainframe product line ... going from the mainframe business of the late '50s transitioning into the early to mid 60s. lots of these other machines happened after the testimony in question.

s/1 was peachtree in the 70s (some number of people tried to get it as basis for 3705 instead of uc.5). 8100 was kingston project with uc.5 microprocessor. uc.5 was also in 3705 ... some discussion that pu4/pu5 interface was reaction to the first 360 pcm controller:
http://www.garlic.com/~lynn/subtopic.html#360pcm

there were huge number of controllers, terminals, other stuff. opd also had stuff like displaywriter. field engineers had the "brick" which was a wireless portable computer. there was the precusor to the pc ... that ran apl & basic.

future system (official follow-on for 360 for some period)
http://www.garlic.com/~lynn/submain.html#futuresys

until it got killed. story is that some number of the future system people went up to rochester and did the s/38.

fort knox was sort of the next generation version of the 360 issue ... which was to use 801s for all microprocessors (s/3 stuff rom rochestor, low & mid range 370s, numerous controllers and other projects) ... which eventually got killed. ROMP was sort of follow-on by research and opd for displaywriter follow-on. When it got killed the group switched and got the company that did the unix port to pc for pc/ix to do a port to romp.
http://www.garlic.com/~lynn/subtopic.html#801

there was also the instruments division 68k machine

some of the past discussion of the palm processor for the pc precursor:
http://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
http://www.garlic.com/~lynn/2000.html#70 APL on PalmOS ???
http://www.garlic.com/~lynn/2000d.html#15 APL version in IBM 5100 (Was: Resurrecting the IBM 1130)
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2000g.html#31 stupid user stories
http://www.garlic.com/~lynn/2000g.html#46 A new "Remember when?" period happening right now
http://www.garlic.com/~lynn/2001b.html#45 First OS?
http://www.garlic.com/~lynn/2001b.html#51 Stealth vs Closed
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2002b.html#39 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#47 IBM 5100 [Was: First DESKTOP Unix Box?]

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Mon, 20 Jan 2003 18:44:33 GMT
"Stephen Fuld" writes:
Were the 2301s truely drums? I know that the 2305 were colloguilly called drums, but were really hixed head disks.

the 2301/2303s were drums ... see picture at one of the references ... either michigan or columbia. 2305 was follow-on to 2301s but were fixed head disk. as mentioned before 50s & 60s ... there were a number of form factors ... not just spinning platters ... in part reason for dasd ... later in the 70s ... there was much less exposure to form factors other than spinning platters.

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Mon, 20 Jan 2003 18:53:32 GMT
"Stephen Fuld" writes:
Depends upon what you mean by "used". Since IBM stopped making 3390's a few years ago, no true CKD disks are being made. All currently manufactured systems for IBM mainframes emulate CKD (Actuallly ECKD, of course.) in the storage control unit and use commodity SCSI type disks for the actual storage.

i just said that bbcchhr addressing has been used for 40 some years .... i didn't mean that everything always was actually either physically or logically ckd (by ibm or other vendors). note: 3375 was ckd emulated on 3370 fba device ... which has now gone on to simulating ckd on other types of fixed block devices.

from earlier posting in this thread:
http://www.garlic.com/~lynn/2003b.html#3
url pointer:
http://www.garlic.com/~lynn/2002o.html#3
which referenced earlier post:
http://www.garlic.com/~lynn/2001l.html#63


           2301       fixed-head/track (2303 but r/w four heads in parallel)
2303       fixed-head/track r/w single head (1/4th rate of 2301)
Corinth    2305-1     fixed-head/track
Zeus       2305-2     fixed-head/track
2311
2314
           2321       data-cell "washing machine"
?Piccolo   3310       FBA
Merlin     3330-1
Iceberg    3330-11
Winchester 3340-35
3340-70
           3344       (3350 physical drive simulating multiple 3340s)
Madrid     3350
NFP        3370       FBA
Florence   3375       3370 supporting CKD
Coronado   3380 A04, AA4, B04
EvergreenD 3380 AD4, BD4
EvergreenE 3380 AE4, BE4

           3830       horizontal microcode engine

Cybernet   3850       MSS (also Comanche & Oak)

Cutter     3880       jib-prime (vertical) microcode engine
Ironwood   3880-11    (4kbyte/page block 8mbyte cache)
Sheriff    3880-13    (full track 8mbyte cache)
Sahara     3880-21    (larger cache for "11")
??         3880-23    (larger cache for "13")

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

Card Columns

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Mon, 20 Jan 2003 19:09:28 GMT
Anne & Lynn Wheeler writes:
future system (official follow-on for 360 for some period)
http://www.garlic.com/~lynn/submain.html#futuresys

until it got killed. story is that some number of the future system people went up to rochester and did the s/38.


i believe one of the quoted references in the above stated that the 360 future system follow-on was to have such a large complex intergration between the main processor and the controllers and devices ... that it would make it difficult for PCM cotnroller competition .. which is what a couple of us at the univeristy get blamed for originating:
http://www.garlic.com/~lynn/subtopic.html#360pcm

large part of the FS processor architecture was one level store (lots of virtual memory) and probably also could be considered quite object oriented.

when FS got killed ... folklore is that some number of people went off to rochester and did the s/38 with a one-level-store architecture.

the other part is that some aspect of the FS large complex integration carried over into the pu4/pu5 design for ncp/vtam (in reaction to the first pcm controller project i worked on at the university).

and of course my comment about FS was that it had some analogy to a cult film that had been playing down the street in central sq for over a decade (inmates in charge of the institution).

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 20 Jan 2003 20:20:47 GMT
"Stephen Fuld" writes:
Were the 2301s truely drums? I know that the 2305 were colloguilly called drums, but were really hixed head disks.

lots of pictures and history
http://www.columbia.edu/cu/computinghistory/

2301 drum:
http://www.columbia.edu/cu/computinghistory/drum.html

note also in the above reference to 40s & 50s ... drums were in use for main memory.

newcastle photos:
http://web.archive.org/web/20031121232747/www.cs.ncl.ac.uk/events/anniversaries/40th/webbook/photos/index.html

misc. views of 360/67 at newcastle
http://web.archive.org/web/20031126035000/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/15.html
http://web.archive.org/web/20030820135059/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/16.html
http://web.archive.org/web/20030820135345/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/21.html
http://web.archive.org/web/20031004110105/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/28.html

mislabeled printer(?) actually 3330
http://web.archive.org/web/20030419023518/www.cs.ncl.ac.uk/events/anniversaries/40th/images/unclassified2/print03.html

2301 in upper right hand corner.
http://web.archive.org/web/20030820135303/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/29.html

2321 datacell:
http://www.columbia.edu/cu/computinghistory/datacell.html
more 2321 datacell
http://members.optushome.com.au/intaretro/2321DCD.htm
7094
http://www.columbia.edu/cu/computinghistory/1965.html

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 20 Jan 2003 20:41:41 GMT
"Stephen Fuld" writes:
Were the 2301s truely drums? I know that the 2305 were colloguilly called drums, but were really hixed head disks.

and close up of 2301 drum:
http://web.archive.org/web/20060620002221/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide12.jpg

list of more pictures at newcastle
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/
IBM System 360 Model 67 c.1969

Dave McGuire and Catherine Miller operating IBM System 360/67
Olive Patterson and Ron Pringle operating IBM 360/67
IBM 360/67 Core Storage - 64K
IBM 360/67 Paper Tape reader
IBM 360/67 Time sharing system
Satellite 1. Remote job entry station. Ground Floor Claremont Tower.



http://web.archive.org/web/20030429044929/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/
IBM System 360 Model 67 c.1969

Dave McGuire and Catherine Miller operating IBM System 360/67
Olive Patterson and Ron Pringle operating IBM 360/67
IBM 360/67 Core Storage - 64K
IBM 360/67 Paper Tape reader
IBM 360/67 Time sharing system
Satellite 1. Remote job entry station. Ground Floor Claremont Tower.
Roger Broughton with PCBs out of IBM 360/67
IBM 360/67 when originally installed
IBM drum
1403 printer 2540 card reader/punch (360/67)
IBM 360/67 in 500Mbyte disk configuration
Roger Broughton looking at panel in gate of IBM 360/67 Processor box
IBM 360/67 Dorothy Jackson and Anne Roberts (1967)
Roger Broughton, Catherine Miller and Ann King with the IBM 360/67
Dave McGuire at 1052 console, Catherine Miller at 2400 tape drive.
Loading in the IBM 370
Delivering the 1403 high speed line printer for IBM 360/67 or 370/168



http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/unclassified2/

Ian Doak beside "Zebedee"
picture 18
picture 21
Nigel Cox, Ewan Page, Wyn Jones (date?)
Pete Lee RA (c.1980)
Burroughs machine in Room 200C.
Terminals in Tower Room 923
Vaxstations in the Rack (1989)
Sheila Coulson operating the IBM 1130 (1967)
Roger Broughton loading IBM Disk Drives (3330)
Tony Mascall using the Reliability Project's PDP 11/45 (note the RK05 2.5 MB removable disk!)
Plant Room B
Terry Ratcliffe operating the MTS 3270 Terminal
Empty Machine Room
New machine being delivered, 3705? 2702?
Data Preparation Service c.1985
Isabel Gouveia Lima
Jill Foster (1989)
Martin Lamont, John Aspden, Dave Surtees, Clive Gerrard (1989)
Occassion 1? - Tony Mascall and Ewan Page
Occassion 2? - Brian Jones, Lorna Brown and ?
Occassion 1? - Tony Mascall, Benedict Heal and Ewan Page
Occassion 1? - Les Mitchell, Nigel Hall, Ann Youact?, John Lloyd and Tony Mascall
Occassion 3? - Phil Treleaven and Brian Randell
Sandy?, Angus McNay, Terry ?, John Mc?, Eddie Dodds, Ian ?, ?, John Chapman, Jim Eve, Margaret Robson, Ewan Page, Ian Scoins, Elizabeth Barraclough, MJE?
Burroughs B1700 Console
Claremont Tower site flooded by the underground Barras Burn c.1965
John Lloyd and David Appleton
Air Conditioning Plant B. Close-up
Terry Ratcliffe
Harry Whitfield
Terry Ratcliffe and Ian Scoins
Brian Randell
Jim Eve
Duty Advisor - Elizabeth Barraclough(1989)
Duty Advisor - Judy Hunter (date, occasion?)
Duty Advisor - Geoff Shearing


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

Card Columns

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Mon, 20 Jan 2003 22:45:50 GMT
Anne & Lynn Wheeler writes:
future system (official follow-on for 360 for some period)
http://www.garlic.com/~lynn/submain.html#futuresys

until it got killed. story is that some number of the future system people went up to rochester and did the s/38.


two of the somewhat more information references from above:
http://www.garlic.com/~lynn/2000f.html#16
http://www.garlic.com/~lynn/2001f.html#33

with respect to side reference to s/1 in one of the above:
http://www.garlic.com/~lynn/99.html#67 System/1?
http://www.garlic.com/~lynn/99.html#70 System/1?

as an undergraduate ... having been on project that built our own 360 controller ... and getting blamed for originating 360 pcm business, later tried to start a project that would port the above implementation from series/1 platform to a rios platform and make it widely available (mid-80s flavor of running vtam RUs thru high-performance packet network).

the original 360 pcm business thing caused a lot of heartburn in cpd (and other) cicles (somewhat being motivation for some of FS characteristics) ... the suggestion of this effort also resulted in some amount of heartburn in cpd circles.

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

InfiniBand Group Sharply, Evenly Divided

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Tue, 21 Jan 2003 01:39:30 GMT
"del cecchi" writes:
A few years ago, much of Minneapolis was cut off, or nearly so, due to some homeless folks having a campfire under one of the bridges across the Mississippi river. Toasted a bundle of fiber carrying most or all of the Internet connectivity. So, got to plan for outages. and hindsight is 20/20.

one of the all times was the backhoe (in conn?) cutting fiber and taking out most of new england internet. the issue was that some time earlier ... something like nine different links going out of new england via very carefully planned nine different physical routes. however, over the years ... when nobody was paying attention ... more and more of the links became consolidated on fewer & fewer physical routes ... until all nine physical routes had been consolidated on a single physical path.

not only do you have to plan ... but you need something like quarterly audits to make sure somebody hasn't come along and messed everything up. also issues with trying to get institutional memory extending several decades.

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

Disk drives as commodities. Was Re: Yamhill

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 21 Jan 2003 15:13:35 GMT
"Rupert Pigott" <darkboo-remove-this-ng.@hotmail.com> writes:
Tandon revived the idea. I used to have a 286 (circa '90/91) that had removeable packs... Datapaks or something ? Dunno, but they were hella-tough and offered a good whack of capacity. We loved em, you could move your C:\ drive to a different machine. :)

there was a GSA schedule for removeable drives in the late '80s & early '90s. a number of vendors produced them for gov. customers (take out the drives and lock them up when you left the office at night). a number of the workstation vendors had them ... the rs/6000 version had an external case that was little more than power connector and addressing. the removeable unit looked about like an "internal" drive but with a finished front panel and handle (slightly analogous to some existing hot pluggable drives).

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

Disk drives as commodities. Was Re: Yamhill

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 21 Jan 2003 15:16:11 GMT
Anne & Lynn Wheeler writes:
posts specific to csc, 4th floor, 545tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech



http://web.archive.org/web/20060620002416/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide20.jpg

in the above there are 9 drawers ... but only eight of them were addressable at a time. in the area above the drawers are controls and ready lights. not very distinct are the round "plugs" next to the green/red/yellow lights. these are the "addresses" for each drawer. you could open a drawer, remove a pack, put in a new pack into the drive and close the drawer. when the drive was up to speed ... you could pull a valid addressing plug from one of the other drawers and pop it into the drawer for the newly mounted pack (making that pack/drawer addressable)

... there was a short version of the above that only had five drawers and all were addressable. cambridge science center machine room was on the 2nd floor of 545 tech sq. it had 360/67 with 768k bytes of storage and 45 2314 drives (five banks of 9-drive units and one bank of 5-drive unit). when Lincoln Labs discontinued one of it processors (in a 360/67 multiprocessor configuration) ... somebody called the moving company and told them instead of returning it to the factory in kingston to deliver to 545 tech sq. it was several months before the factory was able to track down what happened to the machine.

to help distinquish the different banks of 2314s ... one of the hardware engines spray painted the traditional red/blue panels on each bank of 2314s a different color (people in the machine room then could refer to 2314 bank as to ts color).

later 3330 bank
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/unclassified2/print03.jpg

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Tue, 21 Jan 2003 15:48:03 GMT
"Stephen Fuld" writes:
Oh, I know. I worked at a site that had true drums (both fixed head and moving head) The fixed head drums had an access time of 4.3 milliseconds - in the late 1960s! Later I did some work on CDC's competitor to the 3850 MSS. Similar idea with cartridges containing a strip about 4 inches wide of magnetic material with the cartridges loaded to a read station by a robot. But CDC's was not a "backing store" for 3330 type disks. The cartridges were smaller capacity and were meant to be read directly.

then there was the 1655, a 2305 look-alike ... but with solid state memory (no spinning platters, no moving heads). I believe there were possibly a couple thousand 1655s produced.

random 1655 refs:
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer

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

3745 & NCP Withdrawl?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3745 & NCP Withdrawl ?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 21 Jan 2003 16:50:47 GMT
tjpo@AIRBORNE.COM (Patrick O'Keefe) writes:
Ok. Maybe I should have said "more available" rather than "cheaper". Cycles and storage on an FEP were a scarce resources, and there was a lot less tuning available to free them up.

there is some claim that pu4/pu5 architecture reflected much more of the (canceled) future system design/philosiphy ... which was suppose to have been the 360 follow-on. also some claim that scarce resource in the 3705 was in large part the choice of the uc.5 microprocessor over the much more capable peachtree used in the s/1.

recent future system threads:
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#5 Card Columns
http://www.garlic.com/~lynn/2003b.html#8 Card Columns
http://www.garlic.com/~lynn/2003b.html#11 Card Columns

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Tue, 21 Jan 2003 22:49:47 GMT
Anne & Lynn Wheeler writes:
then there was the 1655, a 2305 look-alike ... but with solid state memory (no spinning platters, no moving heads). I believe there were possibly a couple thousand 1655s produced.

what i was told about the 1655 was that all the (memory) chips had failed the vendor's memory dram Q&A tests ... and would otherwise be headed for the junkyard; that they managed to take advantage of some failure mode that that could be compensated for in solid state dasd type of operation.

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

Card Columns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Wed, 22 Jan 2003 20:14:39 GMT
"Russ Holsclaw" writes:
One of my favorite pet names for a kludgy IBM machine was the term "noodle-picker" for the 2321 Data Cell drive. Also: "noodle-snatcher".

Other pet terms I recall were "Maytag" for the 2311 disk drive, which somewhat resembled a top-loading washing machine, and "Pizza Oven" for the 2314 (a large box with 9 disk drives with removable disk packs). The drives were arranged in an array of drawer-like compartments, with a handle you pulled to open them. (Actually, the 2314 seemed more like a morgue to me than a pizza oven, but that didn't catch on with colleagues.)

I was no longer working in the field when the 3850 Mass Storage System, with it's honeycomb array of phallic-shaped tape cartridges, appeared. There must have been some really choice names for that one among CE's. Anybody heard about that?

Today, I work with a guy who wrote some of the microcode for that beast, but I'm sure he doesn't know how CE's might have referred to it.


note also ... that it was an EC to interlock the 3850 robot arm when the door was open ... after an unfortunate mishap

there is also thread that started in comp.arch ... and i cross-posted to alt.folklore.computers: "Disk drives as commodities" which has pointers to pictures and descriptions of 2311s, 2314s, 2321s, 2301s, 3330s, etc.

http://www.garlic.com/~lynn/2003.html#70 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003.html#72 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#6 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#9 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#14 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill

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

Card Columns

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Wed, 22 Jan 2003 20:21:36 GMT
"Russ Holsclaw" writes:
Yes, but IBM management types, who signed our Payroll Authorization cards, took a dim view of such expressions, especially in front of non-IBMers.

various references to ibm jargon file at:
http://www.212.net/business/jargon.htm

http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2001i.html#32 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#35 Military Interest in Supercomputer AI
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002e.html#45 REXX and its designer (was: IBM 7090 instruction set)
http://www.garlic.com/~lynn/2002h.html#7 disk write caching (was: ibm icecube -- return of
http://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#61 arrogance metrics (Benoits) was: general networking
http://www.garlic.com/~lynn/2002o.html#24 IBM Selectric as printer
http://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells

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

Card Columns

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers
Date: Thu, 23 Jan 2003 15:02:02 GMT
"Charlie Gibbs" writes:
acronym n. [Acronym for Alphabetic Collocation Reducing Or Numbing Your Memory.] A memorable word from which a non-memorable phrase is acrostically generated; a circumlocutory abbreviation often confused with its antonym, MNEMONIC.

cambridge science center did a couple where they started with people's initials .... turned them into acronym (or mnemonic) ... and then generated meaning for the acronym/mnemonic.

most people will recognized GML ... which begat SGML, HTML, XML, ECML, FSML, SAML, etc. G, M, L are the first initials of the last names of the three people involved ... morphed into generalized markup language, standard generalized markup language, hypertext markup language, extended markup language,

another from cambridge science center is compare and swap instruction; CAS are the initials of the person that invented the instruction/operation. Getting CAS into 370 hardware architecture ... the mnemonic CAS was morphed into CS and CDS ... to distinquish compare and swap (single 32bit word) from compare double and swap (64bit double word).

all of the above with offices, cambridge science center, 4th floor, 545 tech. sq.
http://www.garlic.com/~lynn/subtopic.html#545tech

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

Card Columns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 23 Jan 2003 15:25:41 GMT
Joe Morris writes:
My shop never had a 3350, but I heard users pronounce "MSS" as "mess".

3850 ... was robot arm with honeycomb shaped cartridges and wide tape. it supported "virtual" 3330 disk packs by staging data to/from 3330. there was a later version that used (faster) 3350 drives for staging by emulating virtual 3330s. 3850 had two staging modes ... full tape (50mbytes, half 3330-1) and six (3330) cylinders.

several pictures:
http://www.columbia.edu/cu/computinghistory/mss.html

including 3350 drives used for staging data

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

360/370 disk drives

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 23 Jan 2003 18:13:37 GMT
"Russ Holsclaw" writes:
Still, if you understood the dynamics of this disk architecture, you could do some pretty cool things that are not possible with today's fixed-sector disks. And you could do it without violating the system's security/integrity mechanisms. I kinda miss that.

part of the CKD design was offloading processing into the disk unit as opposed to keeping information in storage. it was a storage vis-a-vis i/o thruput trade-off. for 360s, essentially storage was much more constrained that i/o capacity. CKD supported record finding/positioning via search command. the argument for the search command was in the memory of the processor ... and was referenced for comparing against each record (as the bits rotated under the r/w head). as a result during the search command sequence there was a dedicated path between the device and processor memory (involving device, controller, and channel).

one use was rather than keeping directories (vtoc was directory for the whole drive, there was also a library filetype called PDS that had directory of file members) in real storage .... directories could be searched on disk for low, equal, high.

starting with 370 (and even some of the larger 360 configurations), the storage/io trade-off was shifting to being i/o constrained rather than storage constrained (shift from 360 from being storage constrained to 370 which started being i/o constrained). as a result, optimal trade-off had shifting for using bandwidth to search directories on the device ... to caching directories in storage and optimizing bandwidth.

i got called in at a very large customer that was periodically experiencing sever performance degradation during peak-load with large loosely-coupled, vs2/svs installation. i was brought into class room that had maybe dozen tables (about 6' long) ... all covered with foot high print out piles of system activity statistics. They gave me a run down of the system configuration and all the applications and then let me start pouring thru the activity data. After a while, for some reason i started to notice a correlation between poor system thruput and i/o activity rate on a specific 3330 pack. The activity on this 3330 would peak at about 6.5 i/o operations per second and stay that way for the duration of the poor performance. Now, normal heavy random access to 3330 could be expected to have somewhere between 20 to 40 I/Os per second. Eventually tracked it down to a shared program (PDS) library with a directory that spanned three cylinders. Under heavy load, applications programs were being constantly (re)loaded from this particular program library (in part 360s of heritage of looking or no caching because of design point of severe storage constraints).

Search of the PDS directory was using a "multi-track" search .... the 3330 had 19 tracks per cylinder and spun at 3600 rpm ... that translates into an unsuccesful multi-track search operation of 19 tracks taking just under 1/3rd second elapsed time. During this period the drive, the associated control unit, and the associated channel were busy (and with the control unit being busy, all other drives belonging to that control unit were unavailable ... and similar with the channel being busy, all other devices on that channel were unavailable via that channel path).

CMS, CP/67, VM/370, etc ... all grew up from CTSS heritage .... with fixed blocks, use of caching of directories, etc (even when using CKD devices, cms, et al would preformat them to simulated fixed block design). similarly unix could he considered to have inherited some of the same characteristics by way of Multics to CTSS (cms, cp/67, multics were located in 545 tech. sq ... and all projects had people that had formally worked on ctss).
http://www.garlic.com/~lynn/subtopic.html#545tech

I had started writing some reports in the late 70s about this dramatic shift from storage constrained to severe i/o constrained ... w/o some of the mainstream applications having a similar implementation shift if their design point. To highlight this ... I made the statement that dasd system thurput had declined by a factor of between five to ten times relative to system thruput over a ten to fifteen year period. The dasd division got upset about this and assigned their performance group to refute my claims. By the time they were thru, they had concluded that I had slightly understated the decline in dasd relative system thruput (it was actually somewhat worse).

In effect, during the period for a typical configuration, the amount of real storage and the processing power had increased by a factor of fifty times while the amount of dasd thruput had only increased by a factor of five times (dasd got five times faster .... but the amount of real memory increased by a factor of fifty times and the cpu mip rate increased by a factor of fifty times). The GPD study morphed into presentations/reports to guide/share on recommended guidelines regarding improving i/o thruput.

previous postings on this subject:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please

previous multi-track postings:
http://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/97.html#16 Why Mainframes?
http://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe background
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#19 OT?
http://www.garlic.com/~lynn/2000f.html#42 IBM 3340 help
http://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#60 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#6 index searching
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002d.html#22 DASD response times
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002n.html#50 EXCP
http://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth

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

oort compute bound since 12/6 nntp.el changes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Thu, 23 Jan 2003 18:25:21 GMT
i think since the 12/6 changes to nntp.el ... whenever nntp.el is transfering data ... it is compute bound. this on dial line with 21.2 on both nt4 & 2k (startup is especially

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

oort compute bound since 12/6 nntp.el changes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Thu, 23 Jan 2003 19:06:39 GMT
Lars Magne Ingebrigtsen writes:
Well, the nntp timeout has been shortened dramatically, but it sounds kinda odd that the CPU should be the limiting factor when downloading. (Although it's probably the case that the load is pretty high when downloading.)

Is downloading slower for you after the changes?


i switch back and forth between 0.08 and 0.13 and the elapsed time for doing things take the same amount of time .... but for 0.08 the cpu meter shows very little activity and 0.13 pegs the meter.

also ... if i load nntp.el from 0.08 before starting 0.13 ... it doesn't have the problem. i was hoping that it was something that was going to get fixed w/o having to delve into it further.

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

oort compute bound since 12/6 nntp.el changes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Thu, 23 Jan 2003 19:42:11 GMT
Lars Magne Ingebrigtsen writes:
Sure.

I've now added the variable 'nntp-read-timeout' to the current CVS to let you tweak this behavior. It defaults to 0.1; you might want to set it to 1 if you have a slow line.


just tried 0.09 & 0.10 ... and they are ok also ... but 0.13 seems to be spinning someplace.

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

360/370 disk drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 23 Jan 2003 22:52:04 GMT
"Russ Holsclaw" writes:
For example, around 1974, I discovered a trick for reading an entire trackful of fixed-length records with almost no rotational latency. This was done with a channel program consisting of a set of chained "ReadCKD" commands equal in number to the number of records/track, and no SearchID command and TIC at all. This would read the entire track, starting with the first block to pass under the head, regardless of which one it was. The program then sorted out which block was which by examining the record numbers in the input buffers. I could read a sequential file nearly twice as fast that way. This technique, combined with other tricks I won't go into here, greatly accelerated start-up of the RETAIN "database"(1) when the system had to be restarted.

there was work for one of the DBMS that did something similar but for writing log records. it would garner a full-track worth of logging information ... and the write would start at the first record the head encountered after settling/sync'ing.

i had an argument with the 3880-d13/d23 people why didn't they do something similar with they way they handled full-track caching.

one of the HONE people developed a compare&swap ccw sequence using ckd ... in a multi-cec, loosely-coupled environment ... handle cms minidisk locking rules across the whole complex. in the late '70s, hone complex in palo alto was largest single system image operation in the world; eight multiprocessors sharing common dasd farm ... and with branch office and field people having online service (and load balancing rules at front end to direct login).

random hone posts:
http://www.garlic.com/~lynn/subtopic.html#hone

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

360/370 disk drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 00:29:54 GMT
Nicholas Geovanis writes:
If I remember right, the instructor sort-of nodded when I said "Sounds like something the NSA might do". My impression was that this was for their Harvest system, but I can't remember if that was on IBM hardware.

harvest/stretch ... long ago and far away ...

http://www.ddj.com/documents/s=873/ddj0085b/
http://users.bestweb.net/~collier/sh/arch/index.html
http://www.brouhaha.com/~eric/retrocomputing/ibm/stretch/
http://cyclone.cs.clemson.edu/~mark/stretch.html
http://www.llnl.gov/vcm/interviews/norman_hardy_1.html

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

1403 Printer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1403 Printer
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 15:23:45 GMT
Joe Morris writes:
(And as a slight aside triggered by some of the recent comments in this thread, how many people recall the dubious pleasure of having to clean the ribbon dust out of a jammed 1416 print train cartridge?)

i only watched other people do it

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

360/370 disk drives

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 16:20:56 GMT
"Russ Holsclaw" writes:
True. The design is representative of the tendency in those days toward totally unbuffered I/O. The Search-ID CCW operation was probably the most extreme example of this imaginable. You'd have thought that they could have added a dinky little 5-byte register to hold the ID for comparison, but instead required all that extra channel overhead to keep transmitting the same little string of bytes over the cable over and over again. That one seemed silly to me right from the start.

i did the remote device adapter HYPERchannel support for STL ... as part of remoting 300 people from bldg.90/stl to bldg.96. Basically, the A510 emulated a mainframe channel and allowed attachments of normal control units. you captured the CCW string, downloaded it to the memory of the A510 and activated it running locally from the memory of the A510 (however data arguments would be forwarded over the HYPERchannel network back to an A220 and then to mainframe real memory). This worked for almost all controllers/devices except for CKD because of the severe latency constraints associated with the search argument. For STL, there were two "local" HYPERChannel networks in bldg.90 and bldg.96 .... interconnected by T1 (private microwave) link. The single T1 link carried all the 3270 "local" channel traffic plus misc. other local channel devices with response indistinquishable for the 300 terminals when they were really locally attached in bldg. 90 (and significantly better than any of the various networked 3274 options). It was actually slightly better since overall system thruput for dasd got better. The 3274 display controllers actually had fairly high channel busy times compared to dasd controllers that might move the same amount of data. Remoting the 3274s at the end of HYPERchannel network then caused all the 3274 data traffic to be driven thru a locally attached HYPERChannel A220. The channel busy characteristics of A220 was much closer to DASD controller (per byte moved) than 3274s. This freed up additional channel capacity for DASD activity .... and the overall system thruput increased (by 10-15 percent by moving all the 3274s to a HYPERChannel network) which translated into improved system response.

I then worked with one of the RETAIN people in Colorado on a similar implementation when a large number of people were moved to a building across the highway. In this case the T1 link was provided by a private infrared modem mounted on the roofs of the two buildings. There was some concern about transmission quality during rain, fog, or heavy snow .... however the story was that the only time the link saw any noticable bit error rate was during a white-out blizzard when nobody was able to get in to work. The other story was about keeping the infrared modems aligned during the day when the heating of the sun caused one side of the buildings to get taller and tilt the pole that the modem was attached to.

A similar design was implemented by NCAR (up the road) ... which was basically a software MSS implementation .... a 4341 provided control of staging data between tape<->disk and they got an upgraded A515 remote device adapter which allowed for packing off both CCWs and search arguments into the memory of the A515 (in order to support CKD disks). They could use dasd controllers that had a "real" channel interface to the 4341 and a separate channel interface to the A515s. The 4341 acting sort of like a logical 3850 MSS controller doing the staging to/from disk. Then lots of other processors (like non-ibm, crays, etc) could directly access the (CKD) DASD. There was some extra function put into the A515 so the 4341 could load DASD ccw strings along with seek/search arguments and permissions. The drivers on the processors that wanted to directly read/write the data just had to refer to the appropriate CCW "package" in the memory of the A515.

Similar, but different implementations were going on at LANL, LLNL, and nasa/ames ... all involving hyperchannel in one way or another. When we were doing HA/CMP were were interacting with just about all of the groups, the IEEE MSS standards activity ... and even provided some of the commercializing efforts funding (and lots of visits) ... aka LANL->Datatree, LLNL->Unitree, NCAR->Mesa Archival.

a little more thread drift:

The NCAR design also gave rise to the IEEE support for 3rd party transfers in HiPPI and IPI disk support.

the guy in retain that i worked with in colorado transferred to kingston in the mid-80s and worked in the high performance computing lab ... hooking up a bunch of FPS boxes with a 3090 ... random refs:
http://www.garlic.com/~lynn/2000c.html#5 TF-1
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002j.html#30 Weird

and our HSDT project paid for a T1 connection between that lab and the west coast ... driven by HYPERChannel boxes and rfc1044 support that I had written.

random hsdt stuff (including hyperchannel and rfc1044 support):
http://www.garlic.com/~lynn/subnetwork.html#hsdt

random ha/cmp stuff:
http://www.garlic.com/~lynn/subtopic.html#hacmp

misc. ncar, unitree, datatree, mesa mentions:
http://www.garlic.com/~lynn/99.html#146 Dispute about Internet's origins
http://www.garlic.com/~lynn/2000c.html#78 Free RT monitors/keyboards
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001l.html#34 Processor Modes
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable

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

Public key encryption

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public key encryption
Newsgroups: sci.crypt
Date: Fri, 24 Jan 2003 16:55:24 GMT
Michael Amling writes:
"Encryption" with the private key is usually referred to as digital signature. Raise the signature to the public key power to find out what was signed (Note: Digital signatures in practice are not quite that simple.) If you hope to keep data confidential by "encrypting" it with the private key, then you would have to keep the public key confidential (i.e. choose the public exponent at random rather than choosing 3 or 65537, and don't tell anyone what it is).

note that you can treat the public key as a secret key ... only shared between those people that are suppose to read the information ... and still retain the benefits of public/private key origin authentication.

the business process of public/private key has the part 1) of not allowing any one but the authorized entity access to the private key and the part of 2) publishing the public key.

the current business process concept of public key publishing is somewhat equated to x.509 and SSL certificate stuff with public certification authorities. however, the public/private key technology doesn't preclude other kinds of less wide-spread publication methods.

for various business reason ... the NACHA AADS (certificate-less) trials with hardware tokens .... had the private key on the hardware token and the public key kept by the financial institution and never published (after the financial institution got the public key ... the hardware token had only the private key signing function and not support for any kind of key export)
http://www.garlic.com/~lynn/x959.html#nacharfi

this appeared to have the business objective of restricting the hardware token to AADS (including x9.59 like debit) transactions
http://www.garlic.com/~lynn/x959.html#x959

with only the financial institution issuing the hardware token.

there was no method of determining either the private or the public key ... even by the person possesing the hardware token.

for the most part asymmetric key technology is related to technical issues. the public/private key characteristics are all business process issues .... and might have a number of different implementations based on requirements of different business situations.

general certificate-less related discussions:
http://www.garlic.com/~lynn/x959.html#aads

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

360/370 disk drives

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 19:23:29 GMT
Anne & Lynn Wheeler writes:
Similar, but different implementations were going on at LANL, LLNL, and nasa/ames ... all involving hyperchannel in one way or another. When we were doing HA/CMP were were interacting with just about all of the groups, the IEEE MSS standards activity ... and even provided some of the commercializing efforts funding (and lots of visits) ... aka LANL->Datatree, LLNL->Unitree, NCAR->Mesa Archival.

this was also related to the 3-tier architecture that we proposed ... which caused a lot of heartburn among the saa crowd.
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)

also
http://www.garlic.com/~lynn/subnetwork.html#3tier

some of the characteristics can be seen today in all the SAN stuff.

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

360/370 disk drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 19:25:41 GMT
"Russ Holsclaw" writes:
I can't remember who all worked on getting us set up with the HyperChannel thing. I was working on a RETAIN re-architecture project at the time. Our terminal connection work was being done by folks in the Operations function. I hadn't realized you'd been involved.

I wrote all the software support and did a lot of debugging at the STL location before it was cloned in boulder.

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

dasd full cylinder transfer (long post warning)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: dasd full cylinder transfer (long post warning)
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 22:28:55 GMT
nospam@nowhere.com (Steve Myers) writes:
It could make a big difference for sequential reads. Sometime around 1985 or 1986 I used this little trick to measure the time from interrupt to redrive on MVS/370 and 3330s. I found it usually took about 25% of a rotation! So, instead of taking 2 revolutions to sequentially read a full track, because you always lost a full rotation between the 25% lost rotation plus the remainder of the rotation waiting for R1 to come around again, it took about 1 1/4 rotations.

... start digression ...

so one of the things that i had done in the early '70s on cp/67 was a number of memory mapped functions. this (with the help of two BU work/study students) I ported to vm/370 and extended.

this was sort of follow-on to the CMS changes I had done as an undergraduate to optimize the cp kernel pathlength supporting CMS dasd operations. this was translated into "diagnose i/O" (in large part at the insistance of bob adair):
http://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
http://www.garlic.com/~lynn/2003.html#60 MIDAS

low-level cms filesystem functions were translated to the memory mapped api. this allowed that cms could continue to use buffer semantics paradigm (translated to page-mapped buffers) or do full laid-out memory mapping (say like in program loading)
http://www.garlic.com/~lynn/submain.html#mmap

even with applications that continued to use buffer paradigm semantics, there was still some thruput improvement because the "diagnose i/o" paradigm still had the flavor of real i/o operations .... requiring the virtual->real ccw translation (although significantly lower pathlength than the generalized SIO ccw translation) as well as virtual page prefixing overhead prior to scheduling the real i/o. because the filesystem was dealing directly with a page mapped api (even when using buffered i/o semantics), a lot of the page prefixing/unfixing, virtual->real, and other overhead was eliminated.

furthermore given that it was a page mapped semantics ... things like program loading could include options as to whether the mapping allowed sharing of segments across multiple different virtual address spaces.

for vm/370 release 3 ... a subset of the cp kernal changes were incorporated as discontiguous shared segments ... and the all non-filesystem CMS changes were pretty much all incorporated (rewrite of various applications to reside in r/o shared storage). random stuff:
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002o.html#25 Early computer games

the full memory map support included the capability that anybody could create and generate executable code and/or data that was definable as shareable ... both from dasd resident standpoint as well as memory resident standpoint .... w/o requiring any system privileges.

hone was one of the internal sites that made extensive use of the support ... in part because they were being really stressed to provide lots of advanced feature support to all the branch & field people in the world:
http://www.garlic.com/~lynn/subtopic.html#hone

having created the memory-mapped api abstraction ... then underneath the api, the kernel could do all sorts of local & dynamic adaptive implementation tricks .... if things were heavily real storage constrained ... the mapping didn't have to perform any operation other than updating the virtual memory tables (whereas the real i/o simulation code had to prefetch & lock affected virtual pages, translate virtual->real i/o, schedule and perform real i/o, unfix and possibly remove from storage the virtual pages involved). under zero real storage constraints the implementation could switch to start prefetch of all indicated page records and immediately return to the process starting execution. the asyncronicity semantics would be handled (transparently) by virtual memory infrastructure as to whether a page was available or not at the moment it was needed.

.... suspend digression ...

so one demonstration was to have an application executable file out on 3330 that occupried a full 3330 cylinder ... and be able (in no contention scenearios) to fetch the complete file in 19 revolutions (this also required a new low level cms filesystem function that would attempt to perform contiguous allocation ... and modifying the program executable file generation code to specify that contiguous allocation was desired). later was also able to demonstrate similar capability on 3380 cylinder (complete cylinder of data transfer w/o loss of revolution). the implementation could dynamically adapt to sub full track transfer, sequence of single full-track transfers, multiple full-track transfers (up to full cylinder).

.... resume digression ...

so another application of this was in the cp kernel spool file system support. this was motivated by a number of things ... but one issue was in hsdt
http://www.garlic.com/~lynn/subnetwork.html#hsdt

the use of the spool file system by the networking support. a basic problem was that the networking address space was serialized at every 4k worth of data transfer (read or written).

so one idea was to eliminate this serialization ... providing the effect of both read ahead and write behind. also for data resident in the spool file system that was being pushed out a network connection ... doing it in units of 4k bytes ... where the networking support code could use asynchronous interface to provide the mapping of virtual storage to disk locations ... and then let the virtual->real i/o translation handle the serialization without serilizing the network application code. Trick was to have the networking code do a memmory mapped API operation with non-serialization and then use a SIOF (start i/o fast) instruction to initiate the network i/o operation (aka the address space would get immediate return while allowing the virtual->real translation to proceed asynchronously).

that was just one of the identified short-comings .... if a major effort to cleanup the spool file system was going to be undertaken, might as well look at other issues:

1) assembler code in the kernel. redo it in vs/pascal resident in a virtual address space.

2) linear lists of spool files. for large installations this was a cpu killer. in the vs/pascal implementation replace the linear lists with red/black tree implementation ... this change more than compensated for the overhead of moving the code from assembler in the kernel to vs/pascal in virtual address space

3) leverage the memmory mapped api for dasd interface

4) the general enabling of system function didn't happen at boot/ipl until after the spool file system was initialized. moving the function to virtual address space required decoupling the tight system startup from spool file system initialization

5) if the system was shutdown/crashed cleanly (aka a system crash would atteempt to perfom at least a warm start save of the spool file information), the spool file system could come up quickly with warm start saved data (which also met that the system came back up quickly). if the system failed in non-clean mode (like power loss), checkpoint start needed to be performed ... which could easily take 30-60 minutes on a large configuration. decoupling (#4) removed spool file initialization from critical path of general system availability restart.

.... suspend digression ...

one demonstration was to show redesign of the checkpoint restart implementation using the extended memory mapped API ... reading 3380 cylinder of data with no loss in dasd revolution. this resulted in typical worst case checkpoint recovery of a couple minutes (down from sixty) which also was decoupled from general availability of the system.

the other demonstration was to support contiguous allocation for new (large) spoolfiles (with multi-block write behind) ... greatly improving creation elapsed time as well as subsequent retrieval (with multi-block read)

... resume digresionn ...

as a teaser ... i implemented a spoolfile<->tape application (in vs/pascal) that could be run on any unmodified vm/370 system. This used lots of spool file vs/pascal library code that i had written for the full project. basically given r/o access to the full-pack dasd areas contain the (kernel) spoolfile data .... it would perform a spoolfile->tape backup (which resulted in same format tape as the kernel spoolfile->tape command would generate). It also supported tape->spoolfile effectively using the (standard system) spoolfile diagnose interface.

past sfs posts:
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan

... end post ...

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

360/370 disk drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 22:54:44 GMT
"Russ Holsclaw" writes:
I can't remember who all worked on getting us set up with the HyperChannel thing. I was working on a RETAIN re-architecture project at the time. Our terminal connection work was being done by folks in the Operations function. I hadn't realized you'd been involved.

do you recognize: bldfe2(b580556), tie 646-2373/646-2361 later kgnvm5(vmqr), tie 373-1894

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

oort compute bound since 12/6 nntp.el changes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Fri, 24 Jan 2003 23:46:56 GMT
Anne & Lynn Wheeler writes:
also ... if i load nntp.el from 0.08 before starting 0.13 ... it doesn't have the problem. i was hoping that it was something that was going to get fixed w/o having to delve into it further.

ok using ognus-0.14 ... if i have the nntp-read-timeout value at default 0.1 or set to 0.9 ... it uses 100 percent of the cpu during startup of the newsgroups from the nttp server.

if i set the value to 1.0, it uses less than 2 percent of the cpu and startup takes the same elapsed time.

possibly 21.2 emacs or 21.2 emacs on nt/2k issue?

i'll try and report on linux (redhat 7.3) later (same server, same newsgroups, same dial-up link).

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

oort compute bound since 12/6 nntp.el changes

From: Lynn Wheeler <lynn@lhwlinux.ww.com>
Subject: Re: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Sat, 25 Jan 2003 01:13:21 GMT
Anne & Lynn Wheeler writes:
i'll try and report on linux (redhat 7.3) later (same server, same newsgroups, same dial-up link).

looks like nt/2k issue .... ognus-0.14 on 21.2 on linux (redhat7.3) doesn't have (cpu bound) problem with nntp-read-timeout set to 0.1 (same newsgroup file, same .gnus.el file, same server, same dial-up line & modem).

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

360/370 disk drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 25 Jan 2003 01:21:42 GMT
"Russ Holsclaw" writes:
That was certainly in the format of userid's at our site. I was bldfe2(b344736). Don't recall my phone number... I had so many in those days. Did you know Jeff Hill?

... yes .... except he had non-standard userid on bldfe2 ... aka jeffhill at bldfe2 ... bldfe2(jeffhill); at the time tie 347-2352.

also lee stewart, lou saylor.

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

360/370 disk drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 25 Jan 2003 01:26:41 GMT
and for even more topic drift ... i'm in boulder monday morning to attend talk at univ. of col.

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

360/370 disk drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 25 Jan 2003 02:21:16 GMT
Anne & Lynn Wheeler writes:
and for even more topic drift ...

and in two weeks i'm having dinner with somebody who was hyperchannel engineer that i worked with way back then.

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

360/370 disk drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 25 Jan 2003 15:01:08 GMT
Anne & Lynn Wheeler writes:

http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)


oops, typoe

http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)

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

Public key encryption

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public key encryption
Newsgroups: sci.crypt
Date: Sat, 25 Jan 2003 16:59:54 GMT
"johnysputnik" writes:
However don't use the same keypair for encrypt/decrypt as for sign/verify, if you intend to use the same algorithm for both - it becomes quite easy to attack if the key owner is not aware of the dangers

the other reason for using different keypair for encrypt/decrypt as for sign/verify is that the business rules tend to be different (aka asymmetric key tends to be technology issues .... "public" key attributes tend to be all business rule issues).

signature business rules tend to want the private key only available to the entity signing ... even to the extent it is encapsulated in hardware token with nobody ever knowning the private key (even the entity in possesion of the hardware token).

encrypt/decrypt business rules tend to be much more subject to business continuity and availability rules. typically businesses spend huge amounts of money to guarantee no single point of failure. having data (especially data at rest) encrypted ... and only available with the decryption by the private key ... can represent an enormous business risk unless that private key is replicated for availability.

as a result ... even tho the technology can be considered the same ... and both come with the syntactic "public key" label .... in fact, there are significant operational business process characteristic differences between encrypt/decrypt and sign/verify.

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

VMFPLC2 tape format

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VMFPLC2 tape format
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 25 Jan 2003 19:55:22 GMT
gah@UGCS.CALTECH.EDU (glen herrmannsfeldt) writes:
Is there any documentation on the VMFPLC2 tape format?

A google search doen't find any.


been a long time ... i had done a high performance version for my paged mapped changes .... but it was something like

each file was something like

1st record 64byte FST 2nd-nth record 4k (or 800bytes) data

there is header record with x'02', C'CMS' (somewhat borrowing from TXT files) ... see dsect below:

...

the optimization that i did for memory mapping was something like

1st record 1 to 3 4k records with 64 byte FST appended at the end

any additional records were 3 4k records (12kbytes)

basically i read 16kbytes with SILI and figured out what I was getting based on the residual length.

and of course .... i forced buffers to page-aligned boundaries.

from someplace:


•        3.  VMFPLC2 LOOKS FOR THE FUNCTION THE USER WANTS PERFORMED.   00154000
•                                                                       00155000
•        DUMP -                                                         00156000
•                                                              @V62B5H2 00157000
•        1.  THE FST RECORD IS WRITTEN TO TAPE FIRST, WITH     @V62B0H2 00158000
•            A COPY OF THE FST IN IT. THIS COPY IS USABLE FOR  @V62B0H2 00159000
•            EITHER EDF DISK FSTS, OR NON-EDF DISK FSTS.       @V62B0H2 00160000
•            THE FORMAT IS:                                    @V62B0H2 00161000
•                                                              @V62B0H2 00162000
•                     X'00'+-----------------------------+     @V62B0H2 00163000
•                          |       F I L E N A M E       |     @V62B0H2 00164000
•                     X'08'|-----------------------------|     @V62B0H2 00165000
•                          |       F I L E T Y P E       |     @V62B0H2 00166000
•                     X'10'|-----------------------------|     @V62B0H2 00167000
•                          |  X'MMDDHHMM' |WRT PTR|RD PTR|     @V62B0H2 00168000
•                     X'18'|-----------------------------|     @V62B0H2 00169000
•                          | MODE |# ITEMS|  FCL  |F/V|FL|     @V62B0H2 00170000
•                     X'20'|-----------------------------|     @V62B0H2 00171000
•                          |     LRECL    |DB CNT | YEAR |     @V62B0H2 00172000
•                     X'28'|-----------------------------|     @V62B0H2 00173000
•                          |#FULL TAPE BLK|LTH LSTBLK/800|     @V62B0H2 00174000
•                     X'30'|-----------------------------|     @V62B0H2 00175000
•                          | FILE ORIG PTR| ALT DATA BLK |     @V62B0H2 00176000
•                     X'38'|-----------------------------|     @V62B0H2 00177000
•                          | ALT ITEM CNT |#LV|PTRSZ|YYMM|     @V62B0H2 00178000
•                     X'40'|-----------------------------|     @V62B0H2 00179000
•                          |   DDHHMMSS   |  RESERVED    |     @V62B0H2 00180000
•                     X'48'|-----------------------------|     @V62B0H2 00181000
•                                                              @V62B0H2 00182000
•                                                              @V62B0H2 00183000
•        2.  FSTLKP IS CALLED TO FIND THE FILE TO BE DUMPED.  I@V62B0H2 00184000
•              FOUND, 'HX' IS PREVENTED AND IT'S FST IS ALTERED TO INDI 00185000
•            CATE A FIXED LENGTH FILE WITH A RECORD LENGTH OF 800       00186000
•            BYTES. THE FST RECORD (MARKED BY A C'D' FLAG BYTE @V62B0H2 00187000
•            IS WRITTEN TO TAPE AND FOR EACH FILE, ITS BLOCKS  @V62B0H2 00188000
•            ARE READ (VIA RDBUF OR BLK READ)    AND WRITTEN   @V62B0H2 00189000
•            ONTO TAPE(VIA TAPEIO) UNTIL EOF IS REACHED.                00190000
•            FOR EDF DISKS, THIS ALTERATION OF THE FST IS NOT  @V62B5H2 00191000
•            PERFORMED, AS THE FILE IS READ USING DMSEBLKR,    @V62B5H2 00192000
•            TO READ SEQUENTIAL BLOCKS OF THE FILE.            @V62B5H2 00193000

.... and

•                                                              @V62B0H2 02641000
•        TAPE BUFFER AREA.                                     @V62B0H2 02642000
•                                                              @V62B0H2 02643000
COUTSTRT DS    CL3                                             @V62B0H2 02644000
CARDOUT  DS    CL4         X'02', C'CMS'                       @V62B0H2 02645000
FLAGOUT  DS    CL1        'N'=END OF FILE, '0'=NULL BLOK       @V62B0H2 02646000
DATAOUT  DS    CL800                                           @V62B0H2 02647000
•        REMAP THE INPUT BUFFER WITH THE CINAREA DSECT         @V62B0H2 02648000
CINAREA  DSECT             NEW DSECT FOR "FLOATING" TAPE BUFFER@V62B0H2 02649000
CINSTRT  DS    3C                                              @V62B0H2 02650000
CARDIN   DS    CL4         X'02', C'CMS'                       @V62B0H2 02651000
FLAGIN   DS    CL1        'N'=END OF FILE, '0'=NULL BLOK       @V62B0H2 02652000
DATAIN   DS    CL800                                           @V62B0H2 02653000

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

VMFPLC2 tape format

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VMFPLC2 tape format
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 25 Jan 2003 20:17:18 GMT
somewhat topic drift ... my enhanced version i called vmxplc ... and could run on vanilla cms systems ... didn't mandate the page mapped file system enacements to operate:
http://www.garlic.com/~lynn/submain.html#mmap

however i added some additional enhancements to vmxplc and it was used as the basis for the san jose backup/archive system that i wrote (it was installed at sjr, hone and a number of other internal operations on the west coast). after some additional enhancements, it morphed into a product as workstation datasave facitlity ... which then morphed into adsm and now tsm.
http://www.garlic.com/~lynn/submain.html#backup

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

filesystem structure, was tape format (long post)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: filesystem structure, was tape format (long post)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 26 Jan 2003 16:47:18 GMT
long-winded and lots of drift

cms fst ref
http://www.garlic.com/~lynn/2003b.html#42 VMFPLC2 tape format

os/360 ckd, vtoc, & pds:
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#22 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#26 360/370 disk drives

in os/360 the vtoc ... originally always on cylinder zero ... but starting with release 15/16, os/360 dasd format/initialization allowed specification of the cylinder that the vtoc resided on. since vtoc was frequently high-use data area (and was never cached ... as per previous discussion regarding ckd trade-off between scarce memory resource and i/o bandwidth) ... it was possible to place it at the middle of the pack as part of strategy attempting to do arm movement optimization.

prior to release 15/16, i would cleanly format a os pack and then very carefully order the pre-allocation of the PDS library (sizes) (with objective of achieving minimial arm motion). Then i would run a carefully crafted sysgen ... where I had reordered the majority of theIEHMOVE/IEBCOPY statements so that members would be placed in the (new) library PDS to achieve minimum arm motion. On MFT release 11 and release 14 systems (for the typical university workload), i could achieve nearly three times the thruput compared to an out-of-the-box os/360 sysgen. However, this would degrade to possibly only twice over a six month period with normal system PTF activity (replacing various members in the PDS libraries). long ago posting:
http://www.garlic.com/~lynn/94.html#18 CP/67 and OS MFT14

slight memory slip in the above reference, the presentation wasn't houston share ... which was spring '68, where cp/67 was announced and only a couple months after cp/67 was installed at the university. the presetation was at the fall '68 share ... which i believe was Atlantic City (although i did do earlier share presentations on hand-built sysgens of mft11 and mft14). the hand-built sysgens improved over time as i was able to get better and better trace information about typical PDS system library member loading patterns.

cms from version started with cp/40 back in the mid-60s basically would format a dasd to simulate fixed-block architecture ... and have a table of allocated and unallocated records. as you started to write a file, it would start dynamically allocating records from the dasd available pool. as records were allocated to a file ... it would start building a table (hyperblocks) of records allocated to that file. a file's fst (in the above vmfplc2 reference) would contain a pointer to the file's hyperblocks. the initial cms filesystem used a (fixed) record size of 800 bytes for everything.

os/360 would do "file" allocation for the size of an initial contiguous area of dasd tracks (although the size specification could be done in number of records of specific size, number of tracks, or number of cylinders), along with a secondary extent size. The file information and space allocation would be in the vtoc. a file would get its initial allocation (even before any writes were performed) ... the space could be dynamically extended with a limited number of "extents".

in the mid-70s, the CMS (extended) EDF filesystem was added (concurrent support for the original and EDF filesystems). A disk area could be formated as either the original filesystem or the EDF filesystem ... with the EDF filesystem supporting (fixed) record sizes of 1k, 2k, or 4k.

memory-mapped filesystem stuff
http://www.garlic.com/~lynn/submain.html#mmap

For the memory-mapped implementation of the different CMS filesystem, I had to tweak the original filesystem to supporting 4k fixed record sizes (and tricks for 4k page alignment)... and then with the EDF filesystem to always forcing it to the 4k fixed record sizes option (along with the tricks for 4k page alignment). A trivial enhancement that I did for the original filesystem (and then later for the EDF filesystem) was that if the total filesize was less than 4k bytes, rather than having the FST point at an allocated hyperblock, forgo the hyperblock allocation and have the FST point directly at the (only) data block (if additional writes pushed the file size past 4k, then switch to using hyperblocks). Also, if the file was slightly less than 8k, the residual of the 2nd 4k could go in the only hyperblock (instead of a 2nd data record). While this conserved DASD space for small files, more importantly it cut the number of (serialized) arm accesses needed to retrieve the file data. While, in general, CMS didn't have a generalized filesystem cache ... it did read and keep the directory FST information in memory (as well as the dasd record allocation map) and periodically "checkpointed" it to dasd. OS/360 required that the vtoc be read, updated, and rewritten for all allocation and de-allocation events, however os/360 allocations events were for contiguous dasd areas and tended to be much fewer. CMS "filesystem checkpoint" was always careful replace, directory (FSTs) and allocation map were always written to new DASD location ... and then the master record was rewritten pointing to the new area rather than the old area.

I did add advisory contiguous allocation to CMS; normally CMS would dynamically allocate the necessary dasd record as the application would be doing the writes. This included any additional hyperblocks. In the memory-mapped case it was when filesize exceeded 4k, in all of the filesystem cases, it was as the number of block pointers in the current hyperblocks were filled (including adding levels of indirect hyperblocks ... aka hyperblocks pointing to hyperblocks). I then modified (at least) the program creation command (GENMOD) to specify contiguous allocation option. Basically it would first try to contiguous allocate the while filesize, and if it couldn't do that, it would try and contiguous allocate in units of 16 (4k) records, and then it would do as best it could. Normally, CMS applications weren't required to know how much data they were going to write, allocation just occured as the writing happened. However, program generation (GENMOD) knew ahead of time as did VMFPLC LOAD (from tape) as well as COPYFILE (aka typically system programs that started with some existing, known, file size).

I also modified the program creation (GENMOD) and program load (LOADMOD) code to support optional shared segment specification. This interacted with the memory-mapped interface and allowed that a set of contiguous 4k records on dasd to mapped to a shared segment boundary. All address spaces mapping the same set of contiguous 4k records on a segment boundary would share the same segment copy. A subset of this implementation was released in vm/370 release 3 as discontiguous shared segments w/o the CMS memory-maped filesystem support. As a result the CMS interface had to invoke a specialized CP kernel interface for saving and loading virtual memory images (much more restrictive than the generalized CMS genmod/loadmod facility).

All of this was done as updates to existing assembler source modules.

however, for the spool file system rewrite:
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)

I got to start from scratch, implementing in vs/pascal ... using a lot of the stuff that i had done earlier in modifying the cms filesystem for memory-mapped operation. This was motivated in part by trying to significantly improve thruput of vnet node ... which was heavily dependent on the operational characteristics of the spool file system:
http://www.garlic.com/~lynn/subnetwork.html#hsdt

somewhat totally unrelated was that most mainframe interfaces tended to be half-duplex (somewhat reflecting the mainframe heritage). one of the network support people in rochester had done a high-performance full-duplex line driver for the internal network. This was somewhat similar to the dual-simplex support that I had done for HYPERChannel ... using pairs of subchannel addresses for dedicated read/write operations. misc. related hyperchannel:
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#32 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#34 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#39 360/370 disk drives

for both this FDX line-driver ... and the RFC 1044 support that I did for the standard product .... I also implemented rate-based pacing (rather than window-based). recent rate-based pacing discussion:
http://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
http://www.garlic.com/~lynn/2003.html#59 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

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

hyperblock drift, was filesystem structure (long warning)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: hyperblock drift, was filesystem structure (long warning)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 26 Jan 2003 22:10:29 GMT
slightly related hyerblock story
http://www.garlic.com/~lynn/2003b.html

in the 70s we had these friday after work events (residual activity still going on today). before jim went to tandem he would frequently attend.
http://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002o.html#75 They Got Mail: Not-So-Fond Farewells

one night after 4-5 hrs of drinking we got off on the subject of how to improving computer literacy in the company. at the time, keyboards, online access and email was almost exclusively the activity of the (a few?) programmers and computer scientists (except for the data entry clerks for keyboards). so a question was, what kind of application would most likely get a non-programmer to get a keyboard on their desk. some of this was the reflection of the aftermath of the FS failure:
http://www.garlic.com/~lynn/2001f.html#33
http://www.garlic.com/~lynn/submain.html#futuresys

today, email is a killer app ... but that is only because there is some substantial percentage of other people that you communicate with also have email. we finally concocted the killer app being online telephone directory (because these people spent significant amount of time communicating via telephone; email could evolve afterwards when some significan percentage acquired terminals and online access).

... start phone directory killer app ....

one problem was that there was some corporate hdqtrs activity trying to get a $5m/annum budget, dedicated mainframes and dedicated staff to provide a online corporate telephone directory. our objective was to undercut them by several orders of magnitude.

The first criteria was that the online version had to be able to respond faster than it took somebody to pick up a paper copy of a directory off their desk and find a number. The next criteria was that the total implementation and deployment costs had to be serveral orders of magnitude less expesnive than the corporate hdqtrs proposal.

So a process was defined that involved 1) architecting a phone directory file format, 2) writing a lookup command, 3) contacting plant locations and requesting a machine readable copy of what ever phone information that they currently used to print the paper directory, 4) writing filters that converted from each plant location machine readable format to the architected file format. An additional limitation was that all of the above couldn't take more than four person weeks.

The performance requirement basically required that local copy of the files had to be available on most mainframes for local access. This then eventually resulted in the file format had to be relatively trivial, easily distributable and updateable (again all within the four person week effort limit). That led to relatively flat file organization with trivial complete replacement for each new distribution and a simple lookup command.

Now back to the elapsed time requirement. A typical plant file might have 10k to 20k records. Assuming a flat-file sorted by name field and a binary lookup that is about about 15 probes (the last name sort and last name search used a slightly cannonical form of the last name ... no blanks and no special characters) Assuming 4k physical records and avg. record size of 80 bytes ... that is about 50 name records per physical record. That means that probes will be within the correct physical record after about nine probes. Since in CMS it was possible to cache the command and the FST ... but not the hyperblocks or the data blocks, that was about 9 data block reads plus 3 hyperblock reads ... total of 12 dasd i/o operations. On loaded system with general contention for drive, any individual user is likely to get only 1-2 IO/sec, interleaved with other accesses to the same drive. Assuming no other (scheduling, paging, cpu) contention, this resulted in the command taking 6-12 seconds which was border line too long (i.e. people could thumb a paper directory in about the same time).

So instead of doing a binary search, it was decided to do a radix search including measuring the last name first letter frequency distribution. The average value for all directories was then built into the application. Taking the size of the file and the frequency distribution table, it would calculate the expected first record and last record for last names starting with a specific letter. Using the first two letters of a last name, the phone application would calculate the expected (radix) record location for that last name. On the first probe, it would then calculate the observed error (from the expected) for making the second probe. With a phone directory of 32k names, it was frequently possible to get within the correct physical (4k) block with two hyperblock reads and two data block reads. This was three times better than using straight binary search.

Lots of KISS to 1) achieve response time objective and 2) total resources to implement, deploy, and maintain (especially compared to corporate proposal for several orders larger budget).

all very simple ... but we got into some religous wars. back when full-screen editors first came out there was a religous war over the implementation of the up and down commands. edgar was one of the first (3270) fullscreen editors. its implementors took a program centric view of the commands and when up was executed, move the file "up" ... or the cursor position in the file towards the end of the file (and the displayable portion on the screen moved towards the end of the file). Most everybody else claimed that a end-user centric view would have an "up" command move the viewable portion of the file towards the start of the file ... not the end of the file. So there was this long religous issue regarding whether a full-screen editor implemented a programmer-centric set of commands or an end-user-centric set of commands.

so the phone book religous wars (somewhat between the east coast and the west coast) was did the program display name/number or number/name (aka was the name aligned on the left of the screen or was the phone number aligned on the left of the screen). Eventually name/number won out.

When only a single (matching) name was found, it was equally trivial to eyeball name/number as number/name. However, when a list of multiple matches occured it was easier to scan the names aligned on the left of the screen than scanning a name column displaced somewhere in the middle of the screen. Furthermore, it was poor human factors to have number inconsistently displayed at different locations of the screen (depending on whether there was single hit or multiple hits).

Later, i re-implemented the application in C on AIX, using the same source directory file formats (and the same source files copied from the mainframe to unix system). The mainframe version relied on fixed-length records and the count of total records with per first letter distribution frequency. In the unix version, I used standard unix "variable length" records but assumed an approximately uniform record length. The C-version then took the byte length of the file, and calculated a byte-position based on the letter frequency table (instead of a record position) ... and then did the jitter to find to start of a record.

... end phone directory killer app ...

so the phone directory app did help start to populate keyboards on desks of the less (non?) computer literate in the corporation (to some degree, everybody but the programmers).

however, the thing that tripped critical mass, with all the computer illiterate demanding keyboards on their desk involved a few of the top executives getting keyboards for exchanging email. at that point, all of the lower-level executives reporting to them needed keyboards on their desk, and then all of their direct reports needed keyboards; down thru much of corporate middle management. this resulted in a keyboard/terminal allocation crises. the company, like most during the period, did yearly budget cycles, including the number of internally allocated keybards (at the time, effectively all for programmers). The executive and middle-management demand explosion, occuring over a 2-3 month period near the start of a new budget year ... pretty much pre-empted the total corporate internal keyboard allocation for the whole year.

the keyboard allocation crisis then reached proportions where it required a company vp sign-off to get a (new) keyboard on somebody's desk. in response to this, a couple of us showed that the 3-year amortized cost of the keyboard was possibly half that of a business phone (and nobody thought twice of requiring a company vp signing off on whether somebody could have a phone on their desk). this didn't take into account that typical 327x keyboard lifetimes of the period was heading for ten years or more.

the keyboard/terminal on the desk then started to become a middle management status symbol. something like ten years later .... the first person in a department that would get a ps2m80 with 16mbytes of memory and high end display was the head of the department ... even though they typically only turned it on once or twice a week and would only use it for 327x (24x80, monochrome) terminal emulation to some mainframe application.

another issue that emerged is that the PROFS group was out scouring for applications to incorporate under their "padded-cell" environment. They picked up both their email application and the phone directory application in this manner (although they wrapped them hidden behind their profs screens ... and also wrote up claims to having developed them).

unrelated(?) killer app discussions:
http://www.garlic.com/~lynn/2000b.html#42 Why are Suns so slow?
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2002k.html#24 computers and stuff
http://www.garlic.com/~lynn/2002k.html#27 computers and stuff
http://www.garlic.com/~lynn/2002k.html#28 computers and stuff
http://www.garlic.com/~lynn/2002k.html#29 computers and stuff

past profs, vmsg, &/or phone directory discussions
http://www.garlic.com/~lynn/99.html#35 why is there an "@" key?
http://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001j.html#35 Military Interest in Supercomputer AI
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#56 E-mail 30 years old this autumn
http://www.garlic.com/~lynn/2002f.html#14 Mail system scalability (Was: Re: Itanium troubles)
http://www.garlic.com/~lynn/2002h.html#58 history of CMS
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002h.html#64 history of CMS
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, , misc
http://www.garlic.com/~lynn/2002p.html#34 VSE (Was: Re: Refusal to change was Re: LE and COBOL)

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

internal network drift (was filesystem structure)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: internal network drift (was filesystem structure)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 26 Jan 2003 22:58:11 GMT
Anne & Lynn Wheeler writes:
somewhat totally unrelated was that most mainframe interfaces tended to be half-duplex (somewhat reflecting the mainframe heritage). one of the network support people in rochester had done a high-performance full-duplex line driver for the internal network. This was somewhat similar to the dual-simplex support that I had done for HYPERChannel ... using pairs of subchannel addresses for dedicated read/write operations.

aka
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)

the internal (VNET) network process relied on the CP kernel spool file system for dasd (backing store). The FDX driver on a single 56kbit link could realistic move 10kbytes/sec (5kbytes in each direction).

The cp kernel spool file system API was serialized and synchronous on 4kbyte boundaries. On a heavily loaded system, any single process would be lucky to get more than 4-5 4k data blocks/sec thruput (either read or write) from the spool file system (20kbytes/sec). The issues were that a process was blocked (non-executable) during any spool file transfer operation, only one such request per process was active at a time, and any such request typically went into a common dasd service queue that might have 4-5 other active requests.

A strategic VNET node might have a dozen lines that typically ranged from 9600/sec to 56kbites/sec ... frequently making the local spool file system the thruput bottleneck with aggregate network traffic requirements easily exceeding 100kbytes/sec.

HSDT backbone nodes had two or more T1, 1.5mbites/sec (300kbytes/sec aggregate full-duplex per line) ... although eventually typical HSDT T1 carried both TCP/IP as well as internal network (VNET) traffic:
http://www.garlic.com/~lynn/subnetwork.html#hsdt
http://www.garlic.com/~lynn/internet.htm#0

Also, a vnet node in a campus environment might have multiple channel-to-channel connections .... and at some HSDT nodes, had local HYPERCHnannel support between mainframe nodes. Thruput capability easily in the multiple megabytes/sec ... easily saturating the 20kbyte/sec thruput serialized, yncronous spool file interface.

a major objective of the spool file rewrite was to allow (at least) the vnet node to have a asynchronous, non-blocking interface to the spool-file system, to schedule multiple requests concurrently, and to support multiple 4k record transfer requests (both reading & writing). and a slight KISS requirement was to do this in such a way that it had minimal on existing network node implementation software.

note that during this period .... the internal network was larger (more nodes) than the whole arpa/internet ... up thru sometime in the 1985/1986 time-frame (and doesn't include bitnet & earn networks using similar technology).

misc. past mentions of spool file & internal network:
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001l.html#25 mainframe question
http://www.garlic.com/~lynn/2002q.html#31 Collating on the S/360-2540 card reader?

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

send/recv vs. raw RDMA

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: send/recv  vs. raw RDMA
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 26 Jan 2003 23:13:08 GMT
"Stephen Fuld" writes:
But the differencwe between a SAN and what you were proposing is that in your scheme, in "normal operations" a host can overwrite the data needed by another system before that system ahs had the chance to use it. That implies that the host can initiate an I/O totally on its own. In a SAN, the devices are essentially on a complex switching network, but they share the attribute of being "slaves" to the host(s) to which they are attached, that is, they don't initiate transfers on their own, without a request from the host. So the situation of having a disk overwrite the data from a previous transfer because it decided on its own to initiate another transfer just doesn't happen.

a lot of the SAN stuff reflect the NCAR implementation with HYPERChannel ... which was then one of the primary drivers behind the 3rd party transfer support in the HiPPI and IPI standards ... and somewhat propagated out from there.

The NCAR implementation combined both the MSS staging stuff ... pools of disks used for staging data from other larger capacity media (tape robots, etc) and the distributed environment permissions controls (i.e. data didn't actually pass thru the NCAR MSS infrastructure ... it would set-up the 3rd party transfer controls ... and then allow the client to actually do the transfer thru the fabric).

past ncar/san discussions:
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives

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

Disk drives as commodities. Was Re: Yamhill

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Tue, 28 Jan 2003 02:55:39 GMT
"M. Ranjit Mathews" writes:
I've heard a disk drive that goes into an enclosure called a hard file, a disk, or a drive; I've never heard it called a DASD. What I've heard called a DASD is a 4U (or so) enclosure holding multiple "hardfile"s; an example of what I've heard called a DASD farm is a few 1,000 hardfiles in several floor standing refrigerator sized towers attached to a host.

i've had a couple URLs on disk/dasd history ... but the ibm san jose one is gone ... pointing to "Looking for IBM Hard disk drives?"
http://www.storage.ibm.com/hddredirect.html?/firsts/1970.htm
but lives on at the wayback machine:
http://web.archive.org/web/20010810145013/http://www.storage.ibm.com/hdd/firsts/1970.htm
http://web.archive.org/web/20010809021812/www.storage.ibm.com/hdd/firsts/index.htm
and
http://www.hgst.com

however these still work:
http://www.logicsmith.com/hdhistory.html
http://www.i-t-s.com/corporate/disk_drive_history.html from above:
An old idea flowers

The RAMAC disk drive was the first commercial implementation of an idea that had been kicking around for quite some time. The disk drive, in fact, was a successor to the magnetic-drum drive, and both go back to the early '50s at Engineering Research Associates. That company, with Eckert-Mauchly, was merged into Remington Rand to become Remington Rand Univac.


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

Authentication w/o user ids and passwords

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication w/o user ids and passwords.
Newsgroups: alt.computer.security,alt.security
Date: Tue, 28 Jan 2003 22:40:37 GMT
"Al" writes:
Hi there,

I would like to authenticate users, but without user ids or passwords.

What I would like to do is to ask the users to register just once and from then on, they can access a page to download some applets.

However, I do not want to use cookies or to remember the clients by IP address (as a lot of the users have dynamic IP addresses).

Also, I need an easy way to block a particular user, if I find that the user is causing problems, etc.


there are starting to kerberos implementations of pk-init draft .... which supports digital signature authentication. some random pk-init posts:
http://www.garlic.com/~lynn/2002j.html#60 How to map a user account to a digital cert?
http://www.garlic.com/~lynn/2002l.html#3 why is Kerberos better than this simpler replacement
http://www.garlic.com/~lynn/2002l.html#4 why is Kerberos better than this simpler replacement
http://www.garlic.com/~lynn/2002o.html#42 use of RADIUS
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#52 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos

there are also various implementations of radius with support for digital signatures in place of passwords.

kerberos is oriented more towards enterprise authentication .... incorporated into a number of platforms (including underlying structure for windows platforms).

radius is somewhat more internet oriented .... in use by the majority of ISPs and corporate networks. also can be referenced by various webservers authentication stubs.

various platforms like liberty have announce support for kerberos within federated authentication structures. random posts.
http://www.garlic.com/~lynn/aadsm12.htm#3 [3d-secure] NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#6 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aepay11.htm#1 Sun releases Liberty-enabled software
http://www.garlic.com/~lynn/aepay11.htm#2 Sun releases Liberty-enabled software

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

Authentication w/o user ids and passwords

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication w/o user ids and passwords.
Newsgroups: alt.computer.security,alt.security
Date: Wed, 29 Jan 2003 02:49:34 GMT
"Al" writes:
Thanks for all your replies!

Yes, certificates would be the way to go. I would greatly appreciate it if you could point me to resources of how to be my own CA and to issue the certs to the clients. Also, how can I easily block a particular client from accessing (after the client has been issued a certificate).

Thanks! - Al


note that the analogy are door badge systems. the low-value systems tend to be offline operations with badges that effectively have the same paradigm as certificates ... they are self-contained representation of both authentication and permissions. these low-value systems are dependent on taking back permission/possession of the physical badge.

the higher-value door badge systems are online .... the badge purely represents an authentication token ... but doesn't represent self-contained permissions. The online systems take the authenication and checks for what, if any permissions are enabled. these systems allow immediate changes in permissions ... including revoking all permissions.

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 29 Jan 2003 15:45:19 GMT
Keith R. Williams writes:
No air, no work. The disk drive's head actually flies over the platter. Like an airplane, without air it can't fly and will crash.

a lot of the air bearing simulation was done on the 195 in bldg. 28 and then on the 3033 in bldg. 15

random past:
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 29 Jan 2003 15:55:50 GMT
Anne & Lynn Wheeler writes:
a lot of the air bearing simulation was done on the 195 in bldg. 28 and then on the 3033 in bldg. 15

i asked to look at it the summer '80 to see about speed-ups as well as checkpointing. it was written in PLI and used VBS records (cms o/s simulation) ... under cms needed to checkpoint/close the file w/o having to re-open (CMS TCLOSE). also looked at adding REORDER & FORTRAN options ... and possibly recoding pieces in fortran for compilation with randy's fortq (which wasn't yet released as forthx official product).

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

Microsoft worm affecting Automatic Teller Machines

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft worm affecting Automatic Teller Machines
Newsgroups: comp.security.misc,alt.folklore.computers
Date: Wed, 29 Jan 2003 17:30:40 GMT
n1pop writes:
But using secure technologies like VPN will allow companies like us to direct much of the dedicated line traffic over the internet and help to reduce costs. Obviously, those technologies must also consider the possibility of a net-wide traffic jam and offer immediately-available workarounds.

when my wife & i were working on the original (e-commerce) payment gateway .... there were a whole bunch of issues regarding what you would expect from a normal telco financial transaction link.

1) sla (service level agreement) ... contractual service levels with significant penalty clauses if the SLA was not met

2) end-to-end diagnostic & problem resolution capability. little things like less than 5 minute elapsed time for first level problem determination (early on had traditional internet problem that involved 3hr manual diagnostic and the trouble ticket was closed NTF ... no trouble found). we did a draft manual & some bits & pieces of software to try and map normal business diagnostic & resolution procedures into a internet environment.

3) fault tolerant, no-single-point-of-failue, diverse routing, etc

4) did use SSL for encryption but had to force implementation for both client & server end authentication (which hadn't been done yet). Somewhat aside a friend of ours introduced VPN at router committee meeting at the fall '94 IETF meeting ... prior to that ipsec was heavy-weight end-to-end encryption/security. there was initially some comflicts between the light-weight (would come to be called VPN) and the heavy-weight solutions.

slightly related:
http://www.garlic.com/~lynn/aadsmore.htm#dctriv Digital Commerce Trivia Question
http://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc

also:
http://www.garlic.com/~lynn/subpubkey.html#fraud Risk, Fraud, Exploits
http://www.garlic.com/~lynn/subpubkey.html#assurance Assurance

trivia question .... who introduced light-weight stuff at fall '94 IETF meeting?

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

Microsoft worm affecting Automatic Teller Machines

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft worm affecting Automatic Teller Machines
Newsgroups: comp.security.misc,alt.folklore.computers
Date: Wed, 29 Jan 2003 17:52:07 GMT
Anne & Lynn Wheeler writes:
3) fault tolerant, no-single-point-of-failue, diverse routing, etc

aka telco provisioning

random provisioning postings
http://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
http://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2001n.html#51 The Weakest Link.
http://www.garlic.com/~lynn/2002.html#28 Buffer overflow
http://www.garlic.com/~lynn/2002f.html#24 Computers in Science Fiction
http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to

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

Microsoft worm affecting Automatic Teller Machines

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft worm affecting Automatic Teller Machines
Newsgroups: comp.security.misc,alt.folklore.computers
Date: Wed, 29 Jan 2003 18:05:11 GMT
Anne & Lynn Wheeler writes:

http://www.garlic.com/~lynn/subpubkey.html#fraud Risk, Fraud, Exploits
http://www.garlic.com/~lynn/subpubkey.html#assurance Assurance


oops, finger slip
http://www.garlic.com/~lynn/subintegrity.html#fraud Risk, Fraud, Exploits
http://www.garlic.com/~lynn/subintegrity.html#assurance Assurance

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

earthlink ppp connection

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: earthlink ppp connection
Newsgroups: earthlink.general-discussion,comp.os.linux.security
Date: Wed, 29 Jan 2003 22:07:09 GMT
i'm running a redhat 7.3 ppp connection into earthlink 56kbit dial-up connection. as soon as it connects ... the following starts and continues every 30 seconds as long as the connection is active (from iptables log):
Jan 29 13:30:57 lhw kernel: IN=ppp0 OUT= MAC= SRC=aa.bb.cc.dd DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=36775 PROTO=2
Jan 29 13:31:07 lhw kernel: IN=ppp0 OUT= MAC= SRC=aa.bb.cc.dd DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=23720 PROTO=2


the SRC ip address is always the other end of the PPP connection at the earthlink modem concentrator/router. it has been going on at least as long as i've been using iptables to log it.

any ideas why?

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

Why did they make FORTRAN so hard to parse?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did they make FORTRAN so hard to parse?
Newsgroups: alt.folklore.computers
Date: Thu, 30 Jan 2003 14:51:36 GMT
fouldragon@aol.com.ru (Marada C. Shradrakaii) writes:
Also try your local university... sometimes they have a surplus-goods shop. Mine has usually a huge (1.5m x 1.5m x 1m) box of keyboards of various types at 50 cents a throw, as-is. Often includes the 'real deal' IBM clicky keyboards.

when i transfered from 545 tech sq to san jose ... backus's was about 10 offices down the hall, but he was hardly ever there. he worked from home up in san fran. he did have 3275 with 9600 baud line to his house

picture 3275
http://obsoletecomputermuseum.org/ibm3275/

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

When/why did "programming" become "software development?"

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When/why did "programming" become "software development?"
Newsgroups: alt.folklore.computers
Date: Fri, 31 Jan 2003 04:26:22 GMT
ab528@freenet.carleton.ca (Heinz W. Wiggeshoff) writes:
Probably around the time programmers became "software engineers". Judging by the entries in ott.jobs, just about everyone up to an executive position is an engineer these days - iron ring be damned.

Real Programmers Don't Eat Quiche and Real Software Engineers Don't Read Dumps
http://www.garlic.com/~lynn/2001e.html#31 High Level Language Systems was Re: computer books/authors (Re: FA:

discussion of term inflation with "maintenance" turning into "development"
http://www.garlic.com/~lynn/2002b.html#27 IBM SHRINKS by 10 percent

slightly related
http://www.garlic.com/~lynn/2001b.html#1 Review of Steve McConnell's AFTER THE GOLD RUSH

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

Wanted: Weird Programming Language

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wanted: Weird Programming Language
Newsgroups: alt.folklore.computers
Date: Fri, 31 Jan 2003 14:52:04 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
Lemme guess: it is to the POO as an APL program is to the same program written in something other than a write-only language: shorter, but impenetrable?

I'll have you know that, POO was one of the first manuals moved over to script/gml. Actually the "read book" architecture manual .... using script conditionals ... it would either print as the whole "red book" or as the POO, with all the really interesting stuff not being printed.

as script and gml became pervasive for contracts and proposals (for instance for branch people on HONE), I started to joke that the largest body of programmers were the GML programmers.
http://www.garlic.com/~lynn/subtopic.html#hone hone & apl refs

of course, GML begate SGML .... and then you found huge numbers of GML programmers in all industries ... busily writing gov. proposals (all before the days of wysiwyg).

then later GML/SGML begate all HTML, XML, SAML, DAML, FSML, ECML, etc.
http://www.garlic.com/~lynn/subtopic.html#545tech 4th floor 545 tech sq.

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

founder, cambridge science center

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: founder, cambridge science center
Newsgroups: alt.folklore.computers
Date: Fri, 31 Jan 2003 15:30:06 GMT

http://www.bostonherald.com/news/obituaries/ras01302003.htm

Norman L. Rasmussen, 74, high-tech entrepreneur
by Monica Collins
Thursday, January 30, 2003

Norman Leo Rasmussen of Boston, a computer software innovator who pioneered IBM's first multiple user time-sharing system, died of multiple myeloma Sunday at Brigham and Women's Hospital. He was 74.

Working for IBM from the mid-1960s until the early 1970s, Mr. Rasmussen founded the IBM Cambridge Scientific Center of the Massachusetts Institute of Technology. He led and inspired the team that developed the Virtual Machine Operating Systems, which later became an IBM product known as CP/CMS, an early entry allowing multiple users to tap into a single computer mainframe. VM opened the way for cooperative computer programming development.

With his business acumen, scientific expertise, and fiery entrepreneurial spirit, Mr. Rasmussen soared into the brave new world of high-tech.

In 1975, after he left IBM, Mr. Rasmussen was co-founder of GSG Inc., a company that developed applications for various Department of Defense users of Arpanet, the original Internet. From 1980 to 1991, he was president and CEO of Teleprocessing Inc., a company he founded. TPI specialized in communications-based systems integration solutions for private sector organizations.

In 1991, he was recruited to become president and CEO of Softech, Inc., a troubled computer services company. Mr. Rasmussen succeeded in restoring Softech's viability before the company was sold in 1996.

Most recently, Mr. Rasmussen - whose family emigrated from Denmark in 1947 and who spoke three Scandinavian languages - was chairman of the Swedish-based Internet equipment company, Effnet Group AB until he retired in 2001.

Mr. Rasmussen was also a member of the Massachusetts Governor's Advisor Committee on Information Technology from 1984 to 1994.

For those who knew him, however, Mr. Rasmussen was not the starchy scientist. He was an early feminist who worked for social justice and a woman's right to choose. He was active in community affairs and was a familiar figure in his neighborhood, Boston's North End/Waterfront. He served on his condominium association's board of trustees.

Tall and handsome, with ramrod posture and a full head of white hair, Mr. Rasmussen was a well-traveled bon vivant. He frequently traveled to Europe and was multi-lingual. He and his wife, Ellen Parker, spent the 2001 holiday season traveling throughout Southeast Asia.

Yet, all journeys led back to his sailboat and the sea. Mr. Rasmussen was most at home on his sailboat, Galatea, and he spent summers sailing in Penobscot Bay.

Mr. Rasmussen is survived by his wife, Ellen Parker, the executive director of Project Bread; a daughter, Andrea; a son, Nicolas; and a brother, Eyvin.

A gathering to celebrate his life will be held Sunday at 1 p.m. at the Exchange Conference Center, 212 Northern Avenue on Boston's Waterfront.

The family asks that donations be made in Mr. Rasmussen's name to the Personal Physicians Fund for Community Medicine in Boston, c/o Walter Van Dorn Esq, Kirkpatrick and Lockhart LLP, 75 State Street, Boston MA 02110.


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

diffence between itanium and alpha

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: diffence between itanium and alpha
Newsgroups: comp.arch
Date: Fri, 31 Jan 2003 15:53:06 GMT
cecchi@signa.rchland.ibm.com (Del Cecchi) writes:
Yep, those companies like NCR, Burroughs, Univac, GE, et al were just garage shops. NOT

some recent discussions about the BUNCH and then later snow white and the seven dwarfs:
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2003.html#36 mainframe
http://www.garlic.com/~lynn/2003.html#71 Card Columns
http://www.garlic.com/~lynn/2003b.html#5 Card Columns

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

Storing digital IDs on token for use with Outlook

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Storing digital IDs on token for use with Outlook
Newsgroups: alt.technology.smartcards
Date: Fri, 31 Jan 2003 16:21:35 GMT
"Søren Maigaard" writes:
I am trying to store a digital ID from Thawte on a USB token for use with digital signatures and encryption in Outlook. Before I got the token, I just had the certificate installed on the PC, but have now moved it onto the token.

However, it seems that in order to have Outlook use the certificate, I need to install it on the PC again. Doesn't that mean that my private key-part of the digital ID is now again stored on the PC (as well as the token) and that anyone can sign (and decrypt) messages without having the token but just the PC (and password) ?

Is there any way to have Outlook use the certificate directly from the token, or at least only copy the public part onto the PC and then have Outlook use the token when signing and/or decrypting ?


certificates are designed for certifying information in an offline environment for parties that don't have previous relationships (a form of trusted key distribution in an offline, anarchy environment). The certificate just contains some information about the sender and the sender's public key (never the private key).

typically a message is either encrypted and/or signed.

If the message is encrypted ... it is either encrypted with the public key of the recipient or it is encrypted with a random symmetric key and the symmetric key encrypted with the public key of the recipient. None of this would involve your token.

If the message is signed ... a hash of the message is generated, and the hash is encrypted with the private key. The message is then sent with the signature appended.

In an anarchy, offline environment, it is assumed that the recipient has no prior information about you, nor do they already have your public key. In this scenario, the message is sent with the appended signature and also an appended certificate. The certificate contains some information related to the sender and the sender public key and is, in-turn signed by some commonly trusted (third) party (trusted by both the sender and hopefully the recipient).

The recipient keeps a table of public keys of the entities they trust. In the purely anarchy, offline environment, this table might only be populated with Certification Authorities that sign certificates. In a more structured environment .... this table might be populated with other entities that they also trust.

The recipient gets a message that has been digitally signed. They then look up in their table of trusted public keys ... to see if that public key is already loaded so that they can verify the digital signature. If the sender's public key is not already loaded into the trusted table ... and there is no online resource to obtain the sender's public key in a trusted manner ... then they may resort to certificates.

A certificate is effectively a special kind of signed message containing some information about the sender, the sender's public key and signed by some entity that is likely to have a public key already loaded into the recipient's table of trusted public keys.

When there is no other way of the recipient likely to have the public key of the sender and no online and/or direct way of obtaining that publc key then the certificate method of essentially two concatenated signed messages is used (the sender's message, the sender's signature, the CA's message ... containing the sender's public key, and the CA's signature).

Certificates were invented for offline environment that expected pretty much anarchy (no prior predictable) communication between two parties that otherwise had no prior knowledge of each other ... but the two parties were set up to trust a common intermediary (the certification authority). While they didn't have each other's public key loaded into their respective trusted public key table, they were expected to have loaded a common, trusted intermediary's public key into their respective trusted public key table.

The other use for the private key in the token is on receiving an encrypted message. This message is either encrypted with the recipient's public key or is encrypted with a random symmetric key which is in-turn encrypted with the recipient's public key. In both cases there is some information that can only be decrypted with the private key in the token. There is no involvement of anybody's certificate in this case.

misc. ref:
http://www.garlic.com/~lynn/aadsover.htm

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

When/why did "programming" become "software development?"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When/why did "programming" become "software development?"
Newsgroups: alt.folklore.computers
Date: Fri, 31 Jan 2003 17:05:51 GMT
Pete Fenelon writes:
Apparently the English Prostitutes Collective (yes, it exists) suggests that the correct term is "women who prostitute".

and then there is coyote union (to bring it back to slightly computer related) or why the santa teresa lab is called the santa teresa lab?:
http://www.garlic.com/~lynn/2000b.html#56 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2001g.html#34 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#37 Thread drift: Coyote Union (or Coyote Ugly?)
http://www.garlic.com/~lynn/2001i.html#11 YKYGOW...
http://www.garlic.com/~lynn/2002j.html#6 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002o.html#11 Home mainframes
http://www.garlic.com/~lynn/2002o.html#69 So I tried this //vm.marist.edu stuff on a slow Sat. night,

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

Storing digital IDs on token for use with Outlook

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Storing digital IDs on token for use with Outlook
Newsgroups: alt.technology.smartcards
Date: Fri, 31 Jan 2003 17:47:28 GMT
"Søren Maigaard" writes:
Thanks for the answer - very interesting read ! However, I still do not quite understand the USB token concept of it all. - I download my certificate from the CA (in this case Thawte). I install it in IE and it is now ready to be used by Outlook. This is both the private and public part of the cert. since I can also decrypt messages etc. - I then export the certificate, import it onto my USB token (could be iKey from Rainbow or others) and erase it from the IE cert list.: Outlook cannot use it in this configuration. - I can then install it in IE again, but that would transfer the entire Thawte cert including private keys back onto the PC. How can this be avoided and functionality maintained ?

what you should do to get a Thawte certificate is send them something about yourself (possibly just your email address) with your public key and signed with your private key. this should go to what is called a "registration authority" part of the certification process. They take your public key and verify the signature (that prooves that you actually possese the private key that corresponds to the public key). They then have to verify the stuff you claim .... like is the email address you supply .... actually belong to you. In the case if an SSL domain name certification ... they have to verify that you actually own the domain name that you claim.

once they have satisfied the validity of the asserted information (email address, domain name, etc), they then create a certificate containining the asserted information, the public key which is signed by them.

at this point they need to get the certificate back to you. if it is an email certificate they can email it back ... or send you an email with a URL that points to the certificate.

Tokens are used to protect the private key. In theory, the token could have generate the public/private key pair ... and export the public key but never export the private key. The token can support operations like:

1) generate key pair
2) export public key (but never export private key)
3) digitally sign (with private key)
4) decrypt (with private key)

tokens may also support loading & exporting other kinds of information (like certificates) into the token for convenience sake.

the objective of tokens is to protect the private key. one of the ways that they can protect the private key is never allowing the private key to exist any place outside of the token.

There is now a business process issue. asymmetric cryptography is a technology issue. public/private keys are a business process application of asymmetric cryptography.

there are two distinct business process that utilize the same public/private keys (and using the same asymmetric cryptography technology).

1) digital signatures
2) information secrecy

The digital signature business process typically has an objective that the private key exists in one and only one place.

The information secrecy business process (utilizing the same exact technology as the digital signature business process) typically wants the private key to be "escrowed" or backedup. The issue here is that businesses frequently spend huge amounts of money to make sure that there is no single point of failure. Information is valuable corporate assets.

If all the information residing on disk 1) happens to be encrypted with a private key (either directly or indirectly using random secret/symmetric keys which are in-turn encrypted with the private key) and 2) the token containing that only copy of that private key fails ... then the business can be at risk (they may have just lost some of their most valuable property).

There is frequently confusion as to the methods protecting the private key in these two distinct business process cases because the assymetric key technology is identical and the public/private key process description is frequently very similar.

In the digital signature case it can be advantages that the private key can never exist any place but a specific hardware token (even given that the token may fail and the private key lost). In the case of information secrecy, it is frequent that it is never the case that if the token fails the private key will be lost.

past discussions of asymmetric cryptography business processes:
http://www.garlic.com/~lynn/2001g.html#14 Public key newbie question
http://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure)
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#78 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003b.html#30 Public key encryption
http://www.garlic.com/~lynn/2003b.html#41 Public key encryption

misc ssl certificate refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

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

Storing digital IDs on token for use with Outlook

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Storing digital IDs on token for use with Outlook
Newsgroups: alt.technology.smartcards
Date: Fri, 31 Jan 2003 18:27:20 GMT
token that i designed for digital signature only operations (w/o a mandated requirement for certificates):
http://www.garlic.com/~lynn/x959.html#aads

examples of authentication only operations like related to kerberos pk-init (kerberos is foundation for windows authentication as well as a number of other platforms):
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm12.htm#4 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#66 Subpoena Sidelines PKI Project
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#32 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC)
http://www.garlic.com/~lynn/aepay10.htm#39 Microsoft Trustbridge ... Kerberos (tickets) support
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay10.htm#66 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay11.htm#1 Sun releases Liberty-enabled software
http://www.garlic.com/~lynn/2001d.html#46 anyone have digital certificates sample code
http://www.garlic.com/~lynn/2001e.html#56 Need explaination of PKI and Kerberos
http://www.garlic.com/~lynn/2001k.html#10 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2002i.html#54 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002j.html#60 How to map a user account to a digital cert?
http://www.garlic.com/~lynn/2002l.html#3 why is Kerberos better than this simpler replacement
http://www.garlic.com/~lynn/2002l.html#4 why is Kerberos better than this simpler replacement
http://www.garlic.com/~lynn/2002l.html#39 Moore law
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002o.html#40 I found the Olsen Quote
http://www.garlic.com/~lynn/2002o.html#42 use of RADIUS
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#52 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002q.html#17 Difference between AAA and Radius?
http://www.garlic.com/~lynn/2003.html#46 Horror stories: high system call overhead
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
http://www.garlic.com/~lynn/2003b.html#49 Authentication w/o user ids and passwords

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

When/why did "programming" become "software development?"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When/why did "programming" become "software development?"
Newsgroups: alt.folklore.computers
Date: Fri, 31 Jan 2003 19:23:55 GMT
Nick Spalding writes:
On what will when it is completed be an orbital motorway round Dublin there are two junctions very close together so that there is only a few hundred yards between the on ramp for one and the off ramp for the next. Often in these parts as you approach where an on ramp joins there is a notice saying 'Merging Traffic'; at this one it says 'Weaving Traffic'.

i believe the ramps onto 880/17 from 101 (san jose) also used to say "weave" (they've recently been rebuilt so i don't know if they still say that).

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 31 Jan 2003 22:23:10 GMT
ranjit_mathews@yahoo.com (M. Ranjit Mathews) writes:
# Performance: Both positioning and transfer performance factors are improving. The speed with which data can be pulled from the disk is increasing more rapidly than positioning performance is improving, suggesting that over the next few years addressing seek time and latency will be the areas of greatest value to hard disk engineers.

http://www.pcguide.com/ref/hdd/histTrends-c.html


this goes back to at least the '60s; dasd relative system performance declined by a factor of ten times (order of magnitude) over 15 year period ... aka disk arms were getting faster ... less fast than everything else .... including transfer speeds & capacity.

one of the other interesting numbers ... was if you assumed uniform access to data on drives .... and then divided the drive access per second by mbyte capacity (of the drive) ... to get access/second/mbyte .... there were alarming declines in that number.

in the early 80s with transition from 3350s to 3380s (newer faster technology), you could get equivalent performance on 3380s than on 3350s only if you didn't fill the 3380s completely full (aka data from disk farm of 3350s were copied to disk farm of 3380s that were only filled to eighty percent in order to maintain accesses/sec/mbyte).

random refs:
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2003b.html#22 360/370 disk drives

more random refs:
http://www.garlic.com/~lynn/93.html#4 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#6 OS with no distinction between RAM and HD ?
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2000c.html#19 Hard disks, one year ago today
http://www.garlic.com/~lynn/2001c.html#16 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001f.html#58 JFSes: are they really needed?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001l.html#41 mainframe question
http://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
http://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2002l.html#29 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#34 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP

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

Disk drives as commodities. Was Re: Yamhill

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 01 Feb 2003 01:13:12 GMT
"Stephen Fuld" writes:
But don't forget that the same things with allow faster transfer rate, primarily higher BPI, also mean more data per given area and thus reduced cost per megabyte. The downward price pressure is what is (indorectly) driving the increase in transfer rate.

so either the drives are kept mostly empty or they have data with access/sec/mbyte profiles ... matching what the drive is capable of (actually various data with a variety of different accesses/sec/mbyte)

the prevously posted reference had effective total system access per second increasing by a factor of 4-5 times (between late '60s and early '80s) ... while everything else increased by nearly 50 times (online dasd capacity, real storage, cpu rate, etc) ... except the total number of online users ... which basically changed proportional to the total aggregate system access/sec.

an issue that raid started out was improving the transfer rate/sec while possibly actually reducing the accesses/sec .... in technology where the transfer rate/sec was already improving much better than accesses/sec has been improving (independent of possibly other issues raid addresses like availability) ... aka not addressing the most pressing problem and possibly actually making the most pressing problem worst.

so there are a lot of strategies attempting to trade-off excess real storage to compensate for accesses/second bottleneck; large block transfers, caching, contiguous data organization, etc.

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

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 01 Feb 2003 22:34:41 GMT
"Stephen Fuld" writes:
A couple of points. First, remember that the overwhelming majority of drives are designed for the desktop market (perhaps 80%) where accesses/second/mb (access density) just isn't much of an issue, but $/mb is critical. Second, there is a natural reduction over time in the access density. If you think about an organization's use of computers, the first things they computerize are those that take the most manual effort, which are typically the things with the most activity. As costs decline, it becomes more and more economical to computerize applications that are less intense. This leads to a general lowering of access density with declining price of storage. Of course, there are lots of exceptions, etc. but I think the general trend is valid.

i've probably said something similar, someplace, long ago, and far away.

one point was that the market segment looking at raid tended to be the non-desktop market segment which were also more sensitive to the accesses/sec/mbyte ... which was being exacerbated by raid.

since over the last 35 years or so .... the least improvement has been in accesses per second ... with significant more improvement (possibly one or two orders of magnitude) in transfer rate, disk space, real storage, and processing power. as a result any dasd related paradigms left over from the last 35 years or so are possibly open for redoing ... where use of processing power, real storage, space, and transfer rates are traded off against number of required accesses. one of the trade-offs can be less pre-processing so that the knowledge is less densely packed.

one of these was the "big pages" paradigm from twenty years ago. 3380s were replacing 3330s; 3380s had about four times the transfer rate but less then twice the avg. 4k block access/second (39 vis-a-vis 25):
http://www.garlic.com/~lynn/95.html#8 3330 disk drives

page writes and page faults were done in clusters of ten (aka "big" pages). page size was 4k pages .... but they were moved to/from dasd in ten page blocks (40k, which happened to be a 3380 track size). space was reserved on 3380 at least ten times larger then expected total page allocation. any page fault would bring in all ten pages in a "big page" and release the allocated track space. page replacement would cluster pages from an address space in blocks of ten for writing ... which would take place at the nearest unallocated track using a moving cursor. write allocation is somewhat similar to a log structured filesystem ... because of the sparce allocation, the writing "wave" would tend to consume cylinders at a time.

past big pages posts:
http://www.garlic.com/~lynn/2001k.html#60 Defrag in linux? - Newbie question
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
http://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#4 Handling variable page sizes?

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

Disk drives as commodities. Was Re: Yamhill

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 02 Feb 2003 00:18:37 GMT
"Bill Todd" writes:
Since the point has now been repeated, it seems worth noting that several RAID flavors (0, 4, 5, and to some degree 1) improve accesses/sec (for

replicated (2-way, 3-way, etc ... aka raid0) ...., not much worse write (just writing in parallel) and 2, 3, etc times the access/sec/mbyte for reads ... predate raid. when "raid" came along, the raid-0 definition was included to adapt/explain something that had been around for some time.

if it is read intensive ... rather than getting three arms, and filling each disk 1/3rd full .... you might come out ahead if you filled disk full and had it replicated three times. the avg. access/sec/mbyte is the same in the two cases ... but doesn't take into account bursty and/or hot-spot behavior. it doesn't help much with write intensive tho.

the trade-off on bursty/hot-spot behavior is that it has got to be concentrating on local collection of data ... but not concentrating so much that caching becomes significant.

except for the availability issue ... if things are write intensive then things are better off filling each disk 1/3rd full ... rather than filling a disk and replicating it three times.

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

Early attempts at console humor?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Early attempts at console humor?
Newsgroups: alt.folklore.computers
Date: Sun, 02 Feb 2003 14:54:47 GMT
"Dennis Ritchie" writes:
Various systems (including the TSS subsystem on GE->Honeywell machines) would send a DEL (rubout) after every N seconds of consumed CPU time, just to let you know it still cared about you.

I think some of the IBM systems would likewise send shift-up/shift-down characters to wiggle the golf-ball on 1050 or 2741 terminals.


on cms it was the blip command, i don't know if it was inherited from ctss ...

originally
blip chars <count> (OFF) 1

and fixed at every two seconds of cpu ... characters defaulted to wiggling the typeball.

previous reference to "feature" in early cp/67 scheduler and "blip"
http://www.garlic.com/~lynn/2000g.html#12 360 Architecture, Multics, ..

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

Early attempts at console humor?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Early attempts at console humor?
Newsgroups: alt.folklore.computers
Date: Sun, 02 Feb 2003 14:57:19 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
VM will do this. You can turn it off by saying CP SET NOBLIP. I'm not sure what having it turned on does if you're on a 3270...

acts more like ftp hash command. oh, command reference in previous post was from cp/67 cms manual.

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

next, previous, index - home