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

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: Mon, 20 Jan 2003 00:17:11 GMT

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 14:14:34 GMT

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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

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 - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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: Mon, 20 Jan 2003 18:40:39 GMT

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:
https://www.garlic.com/~lynn/submain.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 precursor to the pc ... that ran apl & basic.

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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 18:44:33 GMT

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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 18:53:32 GMT

from earlier posting in this thread:
https://www.garlic.com/~lynn/2003b.html#3
url pointer:
https://www.garlic.com/~lynn/2002o.html#3
which referenced earlier post:
https://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")

Card Columns

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

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 - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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: Mon, 20 Jan 2003 20:20:47 GMT

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:
https://web.archive.org/web/20031121232747/www.cs.ncl.ac.uk/events/anniversaries/40th/webbook/photos/index.html

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

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

2301 in upper right hand corner.
https://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 - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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: Mon, 20 Jan 2003 20:41:41 GMT

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.


https://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 - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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: Mon, 20 Jan 2003 22:45:50 GMT

with respect to side reference to s/1 in one of the above:
https://www.garlic.com/~lynn/99.html#67 System/1?
https://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 - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

InfiniBand Group Sharply, Evenly Divided

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

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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

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 distinguish 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 - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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, 21 Jan 2003 15:48:03 GMT

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

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

3745 & NCP Withdrawl?

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

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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, 21 Jan 2003 22:49:47 GMT

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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: Wed, 22 Jan 2003 20:14:39 GMT

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.

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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: Wed, 22 Jan 2003 20:21:36 GMT

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

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

Card Columns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers
Date: Thu, 23 Jan 2003 15:02:02 GMT

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 distinguish 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.
https://www.garlic.com/~lynn/subtopic.html#545tech

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

including 3350 drives used for staging data

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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 18:13:37 GMT

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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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 16:20:56 GMT

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 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:
https://www.garlic.com/~lynn/2000c.html#5 TF-1
https://www.garlic.com/~lynn/2000c.html#61 TF-1
https://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
https://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):
https://www.garlic.com/~lynn/subnetwork.html#hsdt

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

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

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

Public key encryption

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public key encryption
Newsgroups: sci.crypt
Date: Fri, 24 Jan 2003 16:55:24 GMT

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)
https://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
https://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:
https://www.garlic.com/~lynn/x959.html#aads

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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:23:29 GMT

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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

dasd full cylinder transfer (long post warning)

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

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):
https://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
https://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)
https://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 kernel 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:
https://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
https://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
https://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:
https://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
https://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:
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan

... end post ...

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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 | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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

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

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

Public key encryption

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public key encryption
Newsgroups: sci.crypt
Date: Sat, 25 Jan 2003 16:59:54 GMT

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

VMFPLC2 tape format

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

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

•                                                              @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

VMFPLC2 tape format

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

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.
https://www.garlic.com/~lynn/submain.html#backup

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

filesystem structure, was tape format (long post)

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

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

os/360 ckd, vtoc, & pds:
https://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#22 360/370 disk drives
https://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:
https://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
https://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 advisery 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 occurred 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:
https://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:
https://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:
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
https://www.garlic.com/~lynn/2003b.html#32 360/370 disk drives
https://www.garlic.com/~lynn/2003b.html#34 360/370 disk drives
https://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:
https://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
https://www.garlic.com/~lynn/2003.html#59 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

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

hyperblock drift, was filesystem structure (long warning)

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

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.
https://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
https://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:
https://www.garlic.com/~lynn/2001f.html#33
https://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 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 occurred 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 crisis. 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, occurring 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:
https://www.garlic.com/~lynn/2000b.html#42 Why are Suns so slow?
https://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
https://www.garlic.com/~lynn/2002k.html#24 computers and stuff
https://www.garlic.com/~lynn/2002k.html#27 computers and stuff
https://www.garlic.com/~lynn/2002k.html#28 computers and stuff
https://www.garlic.com/~lynn/2002k.html#29 computers and stuff

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

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

internal network drift (was filesystem structure)

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

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:
https://www.garlic.com/~lynn/subnetwork.html#hsdt
https://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:
https://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
https://www.garlic.com/~lynn/2001l.html#25 mainframe question
https://www.garlic.com/~lynn/2002q.html#31 Collating on the S/360-2540 card reader?

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

send/recv vs. raw RDMA

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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

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.
https://www.garlic.com/~lynn/aadsm12.htm#3 [3d-secure] NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#6 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aepay11.htm#1 Sun releases Liberty-enabled software
https://www.garlic.com/~lynn/aepay11.htm#2 Sun releases Liberty-enabled software

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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 - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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: Wed, 29 Jan 2003 15:45:19 GMT

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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: Wed, 29 Jan 2003 15:55:50 GMT

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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 17:30:40 GMT

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:
https://www.garlic.com/~lynn/aadsmore.htm#dctriv Digital Commerce Trivia Question
https://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc

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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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 17:52:07 GMT

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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 | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

any ideas why?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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 04:26:22 GMT

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

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

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

Wanted: Weird Programming Language

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

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.
https://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.
https://www.garlic.com/~lynn/subtopic.html#545tech 4th floor 545 tech sq.

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

founder, cambridge science center

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

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

difference between itanium and alpha

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: difference between itanium and alpha
Newsgroups: comp.arch
Date: Fri, 31 Jan 2003 15:53:06 GMT

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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:
https://www.garlic.com/~lynn/aadsover.htm

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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 17:47:28 GMT

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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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: Fri, 31 Jan 2003 22:23:10 GMT

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:
https://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
https://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
https://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
https://www.garlic.com/~lynn/2002.html#22 index searching
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2003b.html#22 360/370 disk drives

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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 - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://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 22:34:41 GMT

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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

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

Early attempts at console humor?

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

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"
https://www.garlic.com/~lynn/2000g.html#12 360 Architecture, Multics, ..

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

Early attempts at console humor?

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

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

next, previous, index - home