List of Archived Posts
2003 Newsgroup Postings (1/19 - 2/2)
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Card Columns
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Card Columns
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Card Columns
- InfiniBand Group Sharply, Evenly Divided
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- 3745 & NCP Withdrawl?
- Disk drives as commodities. Was Re: Yamhill
- Card Columns
- Card Columns
- Card Columns
- Card Columns
- 360/370 disk drives
- oort compute bound since 12/6 nntp.el changes
- oort compute bound since 12/6 nntp.el changes
- oort compute bound since 12/6 nntp.el changes
- 360/370 disk drives
- 360/370 disk drives
- 1403 Printer
- 360/370 disk drives
- Public key encryption
- 360/370 disk drives
- 360/370 disk drives
- dasd full cylinder transfer (long post warning)
- 360/370 disk drives
- oort compute bound since 12/6 nntp.el changes
- oort compute bound since 12/6 nntp.el changes
- 360/370 disk drives
- 360/370 disk drives
- 360/370 disk drives
- 360/370 disk drives
- Public key encryption
- VMFPLC2 tape format
- VMFPLC2 tape format
- filesystem structure, was tape format (long post)
- hyperblock drift, was filesystem structure (long warning)
- internal network drift (was filesystem structure)
- send/recv vs. raw RDMA
- Disk drives as commodities. Was Re: Yamhill
- Authentication w/o user ids and passwords
- Authentication w/o user ids and passwords
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Microsoft worm affecting Automatic Teller Machines
- Microsoft worm affecting Automatic Teller Machines
- Microsoft worm affecting Automatic Teller Machines
- earthlink ppp connection
- Why did they make FORTRAN so hard to parse?
- When/why did "programming" become "software development?"
- Wanted: Weird Programming Language
- founder, cambridge science center
- diffence between itanium and alpha
- Storing digital IDs on token for use with Outlook
- When/why did "programming" become "software development?"
- Storing digital IDs on token for use with Outlook
- Storing digital IDs on token for use with Outlook
- When/why did "programming" become "software development?"
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Disk drives as commodities. Was Re: Yamhill
- Early attempts at console humor?
- Early attempts at console humor?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 19 Jan 2003 21:22:16 GMT
Ken Moore writes:
IBM seemed to find different names for a lot of concepts (c. 1970). I
always assumed it was part of the strategy of pretending, when they
adopted a useful idea, that they had just invented it. Could they
really have been so blinkered as not to know about paging (Ferranti
Atlas, c.1965) when they called it virtual memory (370 series, c.1971)?
see discussion of ctss/7094 ... and then 360/67 (part of the original
360). also some discussion of the 360/67 being one of the candidates
for multics. then there was an (official) very large effort building
something called tss/360 (single level store operating system)
... involving something over thousand people. lots of detail about
early ctss/7094, cambridge science center, tss/360, cp/40, cp/67,
vm/370, etc
http://www.princeton.edu/~melinda/
... the original 360 was 360/30, 360/40, 360/50, 360/60, 360/62, &
360/70.
the 360/60, 360/62, & 360/70 were all going to have 1mic memory. 750
ns memory came along and the machines to use that were then 360/65,
360/67, & 360/75. as it turned it, i don't think that 360/60, 360/62,
and 360/70 machines ever actually shipped.
note/update:
I remember reading an early document about 360/6x machine with virtual
memory having one, two, and four processors. I sort of had vaque
recollection that it was model number other than 360/67.
however, i've subsequently been told that 360/60 was with 2mic memory
and 360/62 was with 1mic memory. both models never shipped, and were
replaced with 360/65 with 750ns memory. the 360/67 then shipped as
360/65 with virtual memory ... only available in one (uniprocessor)
and two processor (multiprocessor) configurations
http://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That
the 360/62 ... which morphed into 360/67 ... was nearly identical to
360/60 (morphed into 360/65) except it supported virtual pages with
associative look aside buffer for translating virtual addresses. the
360/67 had both 24-bit virtual addressing and 32-bit virtual
addressing modes.
much later when the 370s came out eventually with virtual storage
... they only supported 24-bit virtual addressing. some ten years
later 3081/xa mode introduced 31-bit virtual address.
cambridge science center had actually custom modified a 360/40 with
virtual addressing circa 1965 ... and built cp/40 for it. when the
standard product 360/67 was available ... they ported cp/40 to 360/67
morphing it into cp/67 (an alternative operating system to tss/360 for
360/67 that later morphed into vm/370). cp/67 was running at cambridge
science center and lincoln labs during 1967 ... and in january of 1968
some people from cambridge came out and installed it at the university
i was at (I then picked up responsibility for cp/67 in addition to
production responsibility for os/360).
posts specific to csc, 4th floor, 545tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech
slightly related future system threads:
http://www.garlic.com/~lynn/subtopic.html#futuresys
some past atlas references in this context:
http://www.garlic.com/~lynn/2000.html#52 Correct usage of "Image" ???
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2002.html#42 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
boeing/huntsville did custom modified version of os/360 mvt (release
13?) that made use of the virtual memory of the 360/67 ... but didn't
support paging (virtual memory was to address a fragmentation problem
in mvt with contiguously allocated memory).
the initial development version of aos2 for svs/vs2 aka virtual memory
version of the os/360 batch operating system (aka for 370) ... was
done on 360/67 using a version of os/360 mvt cobbled together with a
hacked version of CCWTRANS (virtual->real i/o translator) from cp/67.
the first code that ran on the very first engineering 370 model with
virtual memory hardware support was a hacked version of cp/67 that was
modified to conform to the 370 hardware relocation architecture (had
different control registers and page tables than 360/67). in fact the
hacked version of cp/67 for 370 had been running production for twelve
months before the engineering hardware became available. there was a
project that modified the virtual machine structure in cp/67 to
support 370 relocation architecture instead of 360 architecture (but
translated virtual 370 formated relocation tables into 360 formated
"shadow" tables) ... aka provided 370 defined virtual machines instead
of 360 defined virtual machines (somewhat akin to various virtual
machine projects that provide 360/370/390 virtual machines on intel
platforms). then a different cp/67 was hacked to operate using "real"
370 formated relocations tables. for various security reasons ... this
environment operated with lots of mit & bu students ... there was
real 360/67
cp/67 providing 360 defined virtual machines on real 360/67
modified cp/67 running in 360/67 virtual machine providing virtual 370s
modified cp/67 running in 370 virtual machine providing virtual 370s
cms running in modified 370 virtual machine
all 12 months before the first engineering 370 machine with virtual
memory support existed.
cp/67 wasn't the only alternative virtual memory system (to tss/360)
built for the 360/67. univ. of michigan also built MTS (michigan
terminal system) that supported virtual memory and paging on the
360/67. some mts stuff from umich:
http://www.itd.umich.edu/~doc/Digest/0596/index.html
http://www.itd.umich.edu/~doc/Digest/0596/feat01.html
http://www.itd.umich.edu/~doc/Digest/0596/feat02.html
http://www.itd.umich.edu/~doc/Digest/0596/feat03.html
posts mentioning michigan terminal system:
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000.html#91 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#44 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000f.html#52 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001e.html#13 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001h.html#24 "Hollerith" card code to EBCDIC conversion
http://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001k.html#27 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#9 mainframe question
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#45 Valid reference on lunar mission data being unreadable?
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002b.html#6 Microcode?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002d.html#49 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002m.html#28 simple architecture machine instruction set
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?
random postings mentioning cp/40:
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#37 SIE instruction (S/390)
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/98.html#33 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/99.html#126 Dispute about Internet's origins
http://www.garlic.com/~lynn/99.html#139 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/99.html#142 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/99.html#174 S/360 history
http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
http://www.garlic.com/~lynn/2000.html#52 Correct usage of "Image" ???
http://www.garlic.com/~lynn/2000.html#81 Ux's good points.
http://www.garlic.com/~lynn/2000.html#82 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#42 Domainatrix - the final word
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000e.html#16 First OS with 'User' concept?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#59 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
http://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#46 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2002b.html#6 Microcode?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#8 TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#36 Blade architectures
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002h.html#62 history of CMS
http://www.garlic.com/~lynn/2002h.html#70 history of CMS
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002l.html#22 Computer Architectures
http://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 19 Jan 2003 22:29:20 GMT
Anne & Lynn Wheeler writes:
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
short extract from above ... which was in turn from melinda's history:
What was most significant was that the commitment to virtual memory
was backed with no successful experience. A system of that period that
had implemented virtual memory was the Ferranti Atlas computer, and
that was known not to be working well. What was frightening is that
nobody who was setting this virtual memory direction at IBM knew why
Atlas didn't work. 23
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 20 Jan 2003 00:17:11 GMT
aek@spies.com (Al Kossow) writes:
Do you know of any documents that still exist which describe the changes
made to the 7094 to support CTSS ?
from melinda's document:
http://www.princeton.edu/~melinda/
CTSS was developed on a series of IBM processors. In the 1950s, IBM's
president, T.J. Watson, Jr., had very shrewdly given MIT an IBM 704
for use by MIT and other New England schools. 6 Then, each time IBM
built a newer, bigger processor, it upgraded the system at MIT. 7 The
704 was followed by a 709, then by a 7090, and finally by a 7094. IBM
also gave MIT the services of some highly skilled Systems Engineers
and Customer Engineers, who formed its MIT Liaison Office, which was
housed at the MIT Computation Center. As CTSS evolved, Professor
Corbato. and his students and colleagues began to encounter problems
that they knew were better addressed by hardware than by software, so
they asked IBM for modifications to their processor. The IBMers in the
Liaison Office had the job of finding engineers in Poughkeepsie to
build the hardware extensions that MIT had determined were necessary
to do time-sharing properly. By the time CTSS was in full production
in 1963, the 7090 at MIT had been modified to have a second memory
bank (32K words), an address relocation register, and memory
protection. With these extensions to the hardware, Corbato's group
was able to build CTSS into the system that became the exemplar for
time-sharing systems.
-----------------------------------------------------------
7 It appears that (without a clear directive from Corporate
management) IBM's Cambridge Branch Office decided to interpret
Watson's original grant to MIT as authorization for them to upgrade
the system at MIT whenever IBM produced a more powerful computer.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Mon, 20 Jan 2003 14:14:34 GMT
Keith R. Williams writes:
Aw shucks! I'm a newbie. I was in Poughkeepsie for nineteen years
followed by a commutation to Burlington. So far I've served ten years
here in the tundra.
I can't remember all the TLAs of the divisions I've done time in. I
remember signing on to SPD and I'm in IMD now. Inbetween? I guess I
could look in HRA.
i spent some time in both bldg. 14 (dasd engineering) & bldg. 15 (dasd
product test) duringg 70s & 80s (although i officially worked in
bldg. 28). got to help shoot some problems with 3880 (cutter). random
ref to some later dasd products:
http://www.garlic.com/~lynn/2002o.html#3 PLX
some recent discussions of san jose plant site:
http://www.garlic.com/~lynn/2002n.html#55 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#38 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#41 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#45 ibm time machine in new york times?
other tales of bldg. 14&15:
http://www.garlic.com/~lynn/subtopic.html#disk
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Mon, 20 Jan 2003 15:53:52 GMT
Anne & Lynn Wheeler writes:
i spent some time in both bldg. 14 (dasd engineering) & bldg. 15 (dasd
product test) duringg 70s & 80s (although i officially worked in
there was strict separation between bldg. 14 (dasd engineering) &
bldg. 15 (dasd product test). management structure didn't converge
until you got to the top level executives in bldg. 12. the theory was
that product test in bldg. 15 had complete freedom to veto release of
product until it met all of their tests.
the separation theory extended to directive that nobody was allowed to
have a badge enabled for access to both bldg. 14 and bldg. 15; aka a
dasd engineer working in bldg. 14 had badge enabled for access to bldg
14 but not to bldg. 15; a dasd engineer working in bldg. 15 had badge
enabled for access to bldg 15 but not to bldg. 14.
being totally outside the division and didn't officially work there
... the directive didn't apply to me ... so i had a badge that was
access enabled for all corners of bldg. 14 as well as all corners of
bldg. 15 (as well as bldg. 28 and various other places in the san jose
area that i could wander into and out of).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Mon, 20 Jan 2003 18:40:39 GMT
"Shmuel (Seymour J.) Metz" writes:
Except, of course, that they didn't. S/7, S/1, 8100, S/3, PC, PC/RT,
S/38; there were huge deviations from the idea of a single product
line.
they weren't suppose to be compatible ... it was every model in the
360 line that was suppose to be compatible. i was told that the
testimony was specifically with respect to the mainframe industry and
the bunch/etc ... and each of them supposedly attempting to meet
criteria of a compatible mainframe product line ... going from the
mainframe business of the late '50s transitioning into the early to
mid 60s. lots of these other machines happened after the testimony in
question.
s/1 was peachtree in the 70s (some number of people tried to get it as
basis for 3705 instead of uc.5). 8100 was kingston project with uc.5
microprocessor. uc.5 was also in 3705 ... some discussion that pu4/pu5
interface was reaction to the first 360 pcm controller:
http://www.garlic.com/~lynn/subtopic.html#360pcm
there were huge number of controllers, terminals, other stuff. opd
also had stuff like displaywriter. field engineers had the "brick"
which was a wireless portable computer. there was the precusor to the
pc ... that ran apl & basic.
future system (official follow-on for 360 for some period)
http://www.garlic.com/~lynn/subtopic.html#futuresys
until it got killed. story is that some number of the future system
people went up to rochester and did the s/38.
fort knox was sort of the next generation version of the 360 issue
... which was to use 801s for all microprocessors (s/3 stuff rom
rochestor, low & mid range 370s, numerous controllers and other
projects) ... which eventually got killed. ROMP was sort of follow-on
by research and opd for displaywriter follow-on. When it got killed
the group switched and got the company that did the unix port to pc
for pc/ix to do a port to romp.
http://www.garlic.com/~lynn/subtopic.html#801
there was also the instruments division 68k machine
some of the past discussion of the palm processor for the pc precursor:
http://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
http://www.garlic.com/~lynn/2000.html#70 APL on PalmOS ???
http://www.garlic.com/~lynn/2000d.html#15 APL version in IBM 5100 (Was: Resurrecting the IBM 1130)
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2000g.html#31 stupid user stories
http://www.garlic.com/~lynn/2000g.html#46 A new "Remember when?" period happening right now
http://www.garlic.com/~lynn/2001b.html#45 First OS?
http://www.garlic.com/~lynn/2001b.html#51 Stealth vs Closed
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2002b.html#39 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#47 IBM 5100 [Was: First DESKTOP Unix Box?]
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Mon, 20 Jan 2003 18:44:33 GMT
"Stephen Fuld" writes:
Were the 2301s truely drums? I know that the 2305 were colloguilly called
drums, but were really hixed head disks.
the 2301/2303s were drums ... see picture at one of the references
... either michigan or columbia. 2305 was follow-on to 2301s but were
fixed head disk. as mentioned before 50s & 60s ... there were a number
of form factors ... not just spinning platters ... in part reason for
dasd ... later in the 70s ... there was much less exposure to form
factors other than spinning platters.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Mon, 20 Jan 2003 18:53:32 GMT
"Stephen Fuld" writes:
Depends upon what you mean by "used". Since IBM stopped making 3390's a few
years ago, no true CKD disks are being made. All currently manufactured
systems for IBM mainframes emulate CKD (Actuallly ECKD, of course.) in the
storage control unit and use commodity SCSI type disks for the actual
storage.
i just said that bbcchhr addressing has been used for 40 some years
.... i didn't mean that everything always was actually either
physically or logically ckd (by ibm or other vendors). note: 3375 was
ckd emulated on 3370 fba device ... which has now gone on to
simulating ckd on other types of fixed block devices.
from earlier posting in this thread:
http://www.garlic.com/~lynn/2003b.html#3
url pointer:
http://www.garlic.com/~lynn/2002o.html#3
which referenced earlier post:
http://www.garlic.com/~lynn/2001l.html#63
2301 fixed-head/track (2303 but r/w four heads in parallel)
2303 fixed-head/track r/w single head (1/4th rate of 2301)
Corinth 2305-1 fixed-head/track
Zeus 2305-2 fixed-head/track
2311
2314
2321 data-cell "washing machine"
?Piccolo 3310 FBA
Merlin 3330-1
Iceberg 3330-11
Winchester 3340-35
3340-70
3344 (3350 physical drive simulating multiple 3340s)
Madrid 3350
NFP 3370 FBA
Florence 3375 3370 supporting CKD
Coronado 3380 A04, AA4, B04
EvergreenD 3380 AD4, BD4
EvergreenE 3380 AE4, BE4
3830 horizontal microcode engine
Cybernet 3850 MSS (also Comanche & Oak)
Cutter 3880 jib-prime (vertical) microcode engine
Ironwood 3880-11 (4kbyte/page block 8mbyte cache)
Sheriff 3880-13 (full track 8mbyte cache)
Sahara 3880-21 (larger cache for "11")
?? 3880-23 (larger cache for "13")
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Mon, 20 Jan 2003 19:09:28 GMT
Anne & Lynn Wheeler writes:
future system (official follow-on for 360 for some period)
http://www.garlic.com/~lynn/subtopic.html#futuresys
until it got killed. story is that some number of the future system
people went up to rochester and did the s/38.
i believe one of the quoted references in the above stated that the
360 future system follow-on was to have such a large complex
intergration between the main processor and the controllers and
devices ... that it would make it difficult for PCM cotnroller
competition .. which is what a couple of us at the univeristy get
blamed for originating:
http://www.garlic.com/~lynn/subtopic.html#360pcm
large part of the FS processor architecture was one level store (lots
of virtual memory) and probably also could be considered quite object
oriented.
when FS got killed ... folklore is that some number of people went off
to rochester and did the s/38 with a one-level-store architecture.
the other part is that some aspect of the FS large complex integration
carried over into the pu4/pu5 design for ncp/vtam (in reaction to the
first pcm controller project i worked on at the university).
and of course my comment about FS was that it had some analogy to a
cult film that had been playing down the street in central sq for over
a decade (inmates in charge of the institution).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 20 Jan 2003 20:20:47 GMT
"Stephen Fuld" writes:
Were the 2301s truely drums? I know that the 2305 were colloguilly called
drums, but were really hixed head disks.
lots of pictures and history
http://www.columbia.edu/acis/history/
2301 drum:
http://www.columbia.edu/acis/history/drum.html
note also in the above reference to 40s & 50s ... drums were in use
for main memory.
newcastle photos:
http://www.cs.ncl.ac.uk/events/anniversaries/40th/webbook/photos/index.html
misc. views of 360/67 at newcastle
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/15.html
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/16.html
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/21.html
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/28.html
mislabeled printer(?) actually 3330
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/unclassified2/print03.html
2301 in upper right hand corner.
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/29.html
2321 datacell:
http://www.columbia.edu/acis/history/datacell.html
more 2321 datacell
http://members.optushome.com.au/intaretro/2321DCD.htm
7094
http://www.columbia.edu/acis/history/1965.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 20 Jan 2003 20:41:41 GMT
"Stephen Fuld" writes:
Were the 2301s truely drums? I know that the 2305 were colloguilly called
drums, but were really hixed head disks.
and close up of 2301 drum:
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide12.jpg
list of more pictures at newcastle
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/
IBM System 360 Model 67 c.1969
Dave McGuire and Catherine Miller operating IBM System 360/67
Olive Patterson and Ron Pringle operating IBM 360/67
IBM 360/67 Core Storage - 64K
IBM 360/67 Paper Tape reader
IBM 360/67 Time sharing system
Satellite 1. Remote job entry station. Ground Floor Claremont Tower.
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/
IBM System 360 Model 67 c.1969
Dave McGuire and Catherine Miller operating IBM System 360/67
Olive Patterson and Ron Pringle operating IBM 360/67
IBM 360/67 Core Storage - 64K
IBM 360/67 Paper Tape reader
IBM 360/67 Time sharing system
Satellite 1. Remote job entry station. Ground Floor Claremont Tower.
Roger Broughton with PCBs out of IBM 360/67
IBM 360/67 when originally installed
IBM drum
1403 printer 2540 card reader/punch (360/67)
IBM 360/67 in 500Mbyte disk configuration
Roger Broughton looking at panel in gate of IBM 360/67 Processor box
IBM 360/67 Dorothy Jackson and Anne Roberts (1967)
Roger Broughton, Catherine Miller and Ann King with the IBM 360/67
Dave McGuire at 1052 console, Catherine Miller at 2400 tape drive.
Loading in the IBM 370
Delivering the 1403 high speed line printer for IBM 360/67 or 370/168
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/unclassified2/
Ian Doak beside "Zebedee"
picture 18
picture 21
Nigel Cox, Ewan Page, Wyn Jones (date?)
Pete Lee RA (c.1980)
Burroughs machine in Room 200C.
Terminals in Tower Room 923
Vaxstations in the Rack (1989)
Sheila Coulson operating the IBM 1130 (1967)
Roger Broughton loading IBM Disk Drives (3330)
Tony Mascall using the Reliability Project's PDP 11/45 (note the RK05 2.5 MB removable disk!)
Plant Room B
Terry Ratcliffe operating the MTS 3270 Terminal
Empty Machine Room
New machine being delivered, 3705? 2702?
Data Preparation Service c.1985
Isabel Gouveia Lima
Jill Foster (1989)
Martin Lamont, John Aspden, Dave Surtees, Clive Gerrard (1989)
Occassion 1? - Tony Mascall and Ewan Page
Occassion 2? - Brian Jones, Lorna Brown and ?
Occassion 1? - Tony Mascall, Benedict Heal and Ewan Page
Occassion 1? - Les Mitchell, Nigel Hall, Ann Youact?, John Lloyd and Tony Mascall
Occassion 3? - Phil Treleaven and Brian Randell
Sandy?, Angus McNay, Terry ?, John Mc?, Eddie Dodds, Ian ?, ?, John Chapman, Jim Eve, Margaret Robson, Ewan Page, Ian Scoins, Elizabeth Barraclough, MJE?
Burroughs B1700 Console
Claremont Tower site flooded by the underground Barras Burn c.1965
John Lloyd and David Appleton
Air Conditioning Plant B. Close-up
Terry Ratcliffe
Harry Whitfield
Terry Ratcliffe and Ian Scoins
Brian Randell
Jim Eve
Duty Advisor - Elizabeth Barraclough(1989)
Duty Advisor - Judy Hunter (date, occasion?)
Duty Advisor - Geoff Shearing
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Mon, 20 Jan 2003 22:45:50 GMT
Anne & Lynn Wheeler writes:
future system (official follow-on for 360 for some period)
http://www.garlic.com/~lynn/subtopic.html#futuresys
until it got killed. story is that some number of the future system
people went up to rochester and did the s/38.
two of the somewhat more information references from above:
http://www.garlic.com/~lynn/2000f.html#16
http://www.garlic.com/~lynn/2001f.html#33
with respect to side reference to s/1 in one of the above:
http://www.garlic.com/~lynn/99.html#67 System/1?
http://www.garlic.com/~lynn/99.html#70 System/1?
as an undergraduate ... having been on project that built our own 360
controller ... and getting blamed for originating 360 pcm business,
later tried to start a project that would port the above
implementation from series/1 platform to a rios platform and make it
widely available (mid-80s flavor of running vtam RUs thru
high-performance packet network).
the original 360 pcm business thing caused a lot of heartburn in cpd
(and other) cicles (somewhat being motivation for some of FS
characteristics) ... the suggestion of this effort also resulted in
some amount of heartburn in cpd circles.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Tue, 21 Jan 2003 01:39:30 GMT
"del cecchi" writes:
A few years ago, much of Minneapolis was cut off, or nearly so, due to
some homeless folks having a campfire under one of the bridges across
the Mississippi river. Toasted a bundle of fiber carrying most or all
of the Internet connectivity. So, got to plan for outages. and
hindsight is 20/20.
one of the all times was the backhoe (in conn?) cutting fiber and
taking out most of new england internet. the issue was that some time
earlier ... something like nine different links going out of new
england via very carefully planned nine different physical
routes. however, over the years ... when nobody was paying attention
... more and more of the links became consolidated on fewer & fewer
physical routes ... until all nine physical routes had been
consolidated on a single physical path.
not only do you have to plan ... but you need something like quarterly
audits to make sure somebody hasn't come along and messed everything
up. also issues with trying to get institutional memory extending
several decades.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 21 Jan 2003 15:13:35 GMT
"Rupert Pigott" <darkboo-remove-this-ng.@hotmail.com> writes:
Tandon revived the idea. I used to have a 286 (circa '90/91) that had
removeable packs... Datapaks or something ? Dunno, but they were
hella-tough and offered a good whack of capacity. We loved em, you
could move your C:\ drive to a different machine. :)
there was a GSA schedule for removeable drives in the late '80s &
early '90s. a number of vendors produced them for gov. customers (take
out the drives and lock them up when you left the office at night). a
number of the workstation vendors had them ... the rs/6000 version had
an external case that was little more than power connector and
addressing. the removeable unit looked about like an "internal" drive
but with a finished front panel and handle (slightly analogous to some
existing hot pluggable drives).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 21 Jan 2003 15:16:11 GMT
Anne & Lynn Wheeler writes:
posts specific to csc, 4th floor, 545tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide20.jpg
in the above there are 9 drawers ... but only eight of them were
addressable at a time. in the area above the drawers are controls and
ready lights. not very distinct are the round "plugs" next to the
green/red/yellow lights. these are the "addresses" for each drawer.
you could open a drawer, remove a pack, put in a new pack into the
drive and close the drawer. when the drive was up to speed ... you
could pull a valid addressing plug from one of the other drawers and
pop it into the drawer for the newly mounted pack (making that
pack/drawer addressable)
... there was a short version of the above that only had five drawers
and all were addressable. cambridge science center machine room was on
the 2nd floor of 545 tech sq. it had 360/67 with 768k bytes of storage
and 45 2314 drives (five banks of 9-drive units and one bank of
5-drive unit). when Lincoln Labs discontinued one of it processors (in
a 360/67 multiprocessor configuration) ... somebody called the moving
company and told them instead of returning it to the factory in
kingston to deliver to 545 tech sq. it was several months before the
factory was able to track down what happened to the machine.
to help distinquish the different banks of 2314s ... one of the
hardware engines spray painted the traditional red/blue panels on each
bank of 2314s a different color (people in the machine room then could
refer to 2314 bank as to ts color).
later 3330 bank
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/unclassified2/print03.jpg
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Tue, 21 Jan 2003 15:48:03 GMT
"Stephen Fuld" writes:
Oh, I know. I worked at a site that had true drums (both fixed head and
moving head) The fixed head drums had an access time of 4.3 milliseconds -
in the late 1960s! Later I did some work on CDC's competitor to the 3850
MSS. Similar idea with cartridges containing a strip about 4 inches wide of
magnetic material with the cartridges loaded to a read station by a robot.
But CDC's was not a "backing store" for 3330 type disks. The cartridges
were smaller capacity and were meant to be read directly.
then there was the 1655, a 2305 look-alike ... but with solid state
memory (no spinning platters, no moving heads). I believe there were
possibly a couple thousand 1655s produced.
random 1655 refs:
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3745 & NCP Withdrawl ?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 21 Jan 2003 16:50:47 GMT
tjpo@AIRBORNE.COM (Patrick O'Keefe) writes:
Ok. Maybe I should have said "more available" rather than
"cheaper". Cycles and storage on an FEP were a scarce resources,
and there was a lot less tuning available to free them up.
there is some claim that pu4/pu5 architecture reflected much more of
the (canceled) future system design/philosiphy ... which was suppose
to have been the 360 follow-on. also some claim that scarce resource
in the 3705 was in large part the choice of the uc.5 microprocessor
over the much more capable peachtree used in the s/1.
recent future system threads:
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#5 Card Columns
http://www.garlic.com/~lynn/2003b.html#8 Card Columns
http://www.garlic.com/~lynn/2003b.html#11 Card Columns
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Tue, 21 Jan 2003 22:49:47 GMT
Anne & Lynn Wheeler writes:
then there was the 1655, a 2305 look-alike ... but with solid state
memory (no spinning platters, no moving heads). I believe there were
possibly a couple thousand 1655s produced.
what i was told about the 1655 was that all the (memory) chips had
failed the vendor's memory dram Q&A tests ... and would otherwise be
headed for the junkyard; that they managed to take advantage of some
failure mode that that could be compensated for in solid state dasd
type of operation.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Wed, 22 Jan 2003 20:14:39 GMT
"Russ Holsclaw" writes:
One of my favorite pet names for a kludgy IBM machine was the
term "noodle-picker" for the 2321 Data Cell drive.
Also: "noodle-snatcher".
Other pet terms I recall were "Maytag" for the 2311 disk drive,
which somewhat resembled a top-loading washing machine,
and "Pizza Oven" for the 2314 (a large box with 9 disk drives
with removable disk packs). The drives were arranged in an
array of drawer-like compartments, with a handle you pulled to
open them. (Actually, the 2314 seemed more like a morgue to me
than a pizza oven, but that didn't catch on with colleagues.)
I was no longer working in the field when the 3850 Mass Storage
System, with it's honeycomb array of phallic-shaped tape
cartridges, appeared. There must have been some really choice
names for that one among CE's. Anybody heard about that?
Today, I work with a guy who wrote some of the microcode for
that beast, but I'm sure he doesn't know how CE's might have
referred to it.
note also ... that it was an EC to interlock the 3850 robot arm when
the door was open ... after an unfortunate mishap
there is also thread that started in comp.arch ... and i cross-posted
to alt.folklore.computers: "Disk drives as commodities" which has pointers
to pictures and descriptions of 2311s, 2314s, 2321s, 2301s, 3330s, etc.
http://www.garlic.com/~lynn/2003.html#70 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003.html#72 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#6 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#9 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#14 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Wed, 22 Jan 2003 20:21:36 GMT
"Russ Holsclaw" writes:
Yes, but IBM management types, who signed our Payroll
Authorization cards, took a dim view of such expressions,
especially in front of non-IBMers.
various references to ibm jargon file at:
http://www.212.net/business/jargon.htm
http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2001i.html#32 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#35 Military Interest in Supercomputer AI
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002e.html#45 REXX and its designer (was: IBM 7090 instruction set)
http://www.garlic.com/~lynn/2002h.html#7 disk write caching (was: ibm icecube -- return of
http://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#61 arrogance metrics (Benoits) was: general networking
http://www.garlic.com/~lynn/2002o.html#24 IBM Selectric as printer
http://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers
Date: Thu, 23 Jan 2003 15:02:02 GMT
"Charlie Gibbs" writes:
acronym n. [Acronym for Alphabetic Collocation Reducing Or Numbing
Your Memory.] A memorable word from which a non-memorable phrase
is acrostically generated; a circumlocutory abbreviation often
confused with its antonym, MNEMONIC.
cambridge science center did a couple where they started with people's
initials .... turned them into acronym (or mnemonic) ... and then
generated meaning for the acronym/mnemonic.
most people will recognized GML ... which begat SGML, HTML, XML, ECML,
FSML, SAML, etc. G, M, L are the first initials of the last names of
the three people involved ... morphed into generalized markup
language, standard generalized markup language, hypertext markup
language, extended markup language,
another from cambridge science center is compare and swap instruction;
CAS are the initials of the person that invented the
instruction/operation. Getting CAS into 370 hardware architecture
... the mnemonic CAS was morphed into CS and CDS ... to distinquish
compare and swap (single 32bit word) from compare double and swap
(64bit double word).
all of the above with offices, cambridge science center, 4th floor,
545 tech. sq.
http://www.garlic.com/~lynn/subtopic.html#545tech
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 23 Jan 2003 15:25:41 GMT
Joe Morris writes:
My shop never had a 3350, but I heard users pronounce "MSS" as "mess".
3850 ... was robot arm with honeycomb shaped cartridges and wide
tape. it supported "virtual" 3330 disk packs by staging data to/from
3330. there was a later version that used (faster) 3350 drives for
staging by emulating virtual 3330s. 3850 had two staging modes
... full tape (50mbytes, half 3330-1) and six (3330) cylinders.
several pictures:
http://www.columbia.edu/acis/history/mss.html
including 3350 drives used for staging data
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 23 Jan 2003 18:13:37 GMT
"Russ Holsclaw" writes:
Still, if you understood the dynamics of this disk architecture,
you could do some pretty cool things that are not possible with
today's fixed-sector disks. And you could do it without violating
the system's security/integrity mechanisms. I kinda miss that.
part of the CKD design was offloading processing into the disk unit as
opposed to keeping information in storage. it was a storage vis-a-vis
i/o thruput trade-off. for 360s, essentially storage was much more
constrained that i/o capacity. CKD supported record
finding/positioning via search command. the argument for the search
command was in the memory of the processor ... and was referenced for
comparing against each record (as the bits rotated under the r/w
head). as a result during the search command sequence there was a
dedicated path between the device and processor memory (involving
device, controller, and channel).
one use was rather than keeping directories (vtoc was directory for
the whole drive, there was also a library filetype called PDS that had
directory of file members) in real storage .... directories could be
searched on disk for low, equal, high.
starting with 370 (and even some of the larger 360 configurations),
the storage/io trade-off was shifting to being i/o constrained rather
than storage constrained (shift from 360 from being storage
constrained to 370 which started being i/o constrained). as a result,
optimal trade-off had shifting for using bandwidth to search
directories on the device ... to caching directories in storage and
optimizing bandwidth.
i got called in at a very large customer that was periodically
experiencing sever performance degradation during peak-load with large
loosely-coupled, vs2/svs installation. i was brought into class room
that had maybe dozen tables (about 6' long) ... all covered with foot
high print out piles of system activity statistics. They gave me a run
down of the system configuration and all the applications and then let
me start pouring thru the activity data. After a while, for some
reason i started to notice a correlation between poor system thruput
and i/o activity rate on a specific 3330 pack. The activity on this
3330 would peak at about 6.5 i/o operations per second and stay that
way for the duration of the poor performance. Now, normal heavy random
access to 3330 could be expected to have somewhere between 20 to 40
I/Os per second. Eventually tracked it down to a shared program (PDS)
library with a directory that spanned three cylinders. Under heavy
load, applications programs were being constantly (re)loaded from this
particular program library (in part 360s of heritage of looking or no
caching because of design point of severe storage constraints).
Search of the PDS directory was using a "multi-track" search .... the
3330 had 19 tracks per cylinder and spun at 3600 rpm ... that
translates into an unsuccesful multi-track search operation of 19
tracks taking just under 1/3rd second elapsed time. During this period
the drive, the associated control unit, and the associated channel
were busy (and with the control unit being busy, all other drives
belonging to that control unit were unavailable ... and similar with
the channel being busy, all other devices on that channel were
unavailable via that channel path).
CMS, CP/67, VM/370, etc ... all grew up from CTSS heritage .... with
fixed blocks, use of caching of directories, etc (even when using CKD
devices, cms, et al would preformat them to simulated fixed block
design). similarly unix could he considered to have inherited some of
the same characteristics by way of Multics to CTSS (cms, cp/67,
multics were located in 545 tech. sq ... and all projects had people
that had formally worked on ctss).
http://www.garlic.com/~lynn/subtopic.html#545tech
I had started writing some reports in the late 70s about this dramatic
shift from storage constrained to severe i/o constrained ... w/o some
of the mainstream applications having a similar implementation shift
if their design point. To highlight this ... I made the statement that
dasd system thurput had declined by a factor of between five to ten
times relative to system thruput over a ten to fifteen year
period. The dasd division got upset about this and assigned their
performance group to refute my claims. By the time they were thru,
they had concluded that I had slightly understated the decline in dasd
relative system thruput (it was actually somewhat worse).
In effect, during the period for a typical configuration, the amount
of real storage and the processing power had increased by a factor of
fifty times while the amount of dasd thruput had only increased by a
factor of five times (dasd got five times faster .... but the amount
of real memory increased by a factor of fifty times and the cpu mip
rate increased by a factor of fifty times). The GPD study morphed into
presentations/reports to guide/share on recommended guidelines
regarding improving i/o thruput.
previous postings on this subject:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
previous multi-track postings:
http://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/97.html#16 Why Mainframes?
http://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe background
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#19 OT?
http://www.garlic.com/~lynn/2000f.html#42 IBM 3340 help
http://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#60 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#6 index searching
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002d.html#22 DASD response times
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002n.html#50 EXCP
http://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Thu, 23 Jan 2003 18:25:21 GMT
i think since the 12/6 changes to nntp.el ... whenever nntp.el is
transfering data ... it is compute bound. this on dial line with 21.2
on both nt4 & 2k (startup is especially
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Thu, 23 Jan 2003 19:06:39 GMT
Lars Magne Ingebrigtsen writes:
Well, the nntp timeout has been shortened dramatically, but it sounds
kinda odd that the CPU should be the limiting factor when
downloading. (Although it's probably the case that the load is
pretty high when downloading.)
Is downloading slower for you after the changes?
i switch back and forth between 0.08 and 0.13 and the elapsed time for
doing things take the same amount of time .... but for 0.08 the cpu
meter shows very little activity and 0.13 pegs the meter.
also ... if i load nntp.el from 0.08 before starting 0.13 ... it
doesn't have the problem. i was hoping that it was something that was
going to get fixed w/o having to delve into it further.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Thu, 23 Jan 2003 19:42:11 GMT
Lars Magne Ingebrigtsen writes:
Sure.
I've now added the variable `nntp-read-timeout' to the current CVS to
let you tweak this behavior. It defaults to 0.1; you might want to
set it to 1 if you have a slow line.
just tried 0.09 & 0.10 ... and they are ok also ... but 0.13 seems to
be spinning someplace.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 23 Jan 2003 22:52:04 GMT
"Russ Holsclaw" writes:
For example, around 1974, I discovered a trick for reading an
entire trackful of fixed-length records with almost no rotational
latency. This was done with a channel program consisting of a set
of chained "ReadCKD" commands equal in number to the number of
records/track, and no SearchID command and TIC at all. This
would read the entire track, starting with the first block to
pass under the head, regardless of which one it was. The program
then sorted out which block was which by examining the record
numbers in the input buffers. I could read a sequential file
nearly twice as fast that way. This technique, combined with
other tricks I won't go into here, greatly accelerated start-up
of the RETAIN "database"(1) when the system had to be restarted.
there was work for one of the DBMS that did something similar but for
writing log records. it would garner a full-track worth of logging
information ... and the write would start at the first record the head
encountered after settling/sync'ing.
i had an argument with the 3880-d13/d23 people why didn't they do
something similar with they way they handled full-track caching.
one of the HONE people developed a compare&swap ccw sequence using ckd
... in a multi-cec, loosely-coupled environment ... handle cms
minidisk locking rules across the whole complex. in the late '70s,
hone complex in palo alto was largest single system image operation in
the world; eight multiprocessors sharing common dasd farm ... and with
branch office and field people having online service (and load
balancing rules at front end to direct login).
random hone posts:
http://www.garlic.com/~lynn/subtopic.html#hone
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 00:29:54 GMT
Nicholas Geovanis writes:
If I remember right, the instructor sort-of nodded when I said "Sounds
like something the NSA might do". My impression was that this was for
their Harvest system, but I can't remember if that was on IBM hardware.
harvest/stretch ... long ago and far away ...
http://www.ddj.com/documents/s=873/ddj0085b/
http://users.bestweb.net/~collier/sh/arch/index.html
http://www.brouhaha.com/~eric/retrocomputing/ibm/stretch/
http://cyclone.cs.clemson.edu/~mark/stretch.html
http://www.llnl.gov/vcm/interviews/norman_hardy_1.html
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1403 Printer
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 15:23:45 GMT
Joe Morris writes:
(And as a slight aside triggered by some of the recent comments in
this thread, how many people recall the dubious pleasure of having
to clean the ribbon dust out of a jammed 1416 print train cartridge?)
i only watched other people do it
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 16:20:56 GMT
"Russ Holsclaw" writes:
True. The design is representative of the tendency in those days
toward totally unbuffered I/O. The Search-ID CCW operation was
probably the most extreme example of this imaginable. You'd have
thought that they could have added a dinky little 5-byte register to
hold the ID for comparison, but instead required all that extra
channel overhead to keep transmitting the same little string of
bytes over the cable over and over again. That one seemed silly to
me right from the start.
i did the remote device adapter HYPERchannel support for STL ... as
part of remoting 300 people from bldg.90/stl to bldg.96. Basically,
the A510 emulated a mainframe channel and allowed attachments of
normal control units. you captured the CCW string, downloaded it to
the memory of the A510 and activated it running locally from the
memory of the A510 (however data arguments would be forwarded over the
HYPERchannel network back to an A220 and then to mainframe real
memory). This worked for almost all controllers/devices except for
CKD because of the severe latency constraints associated with the
search argument. For STL, there were two "local" HYPERChannel networks
in bldg.90 and bldg.96 .... interconnected by T1 (private microwave)
link. The single T1 link carried all the 3270 "local" channel traffic
plus misc. other local channel devices with response indistinquishable
for the 300 terminals when they were really locally attached in bldg.
90 (and significantly better than any of the various networked 3274
options). It was actually slightly better since overall system thruput
for dasd got better. The 3274 display controllers actually had fairly
high channel busy times compared to dasd controllers that might move
the same amount of data. Remoting the 3274s at the end of HYPERchannel
network then caused all the 3274 data traffic to be driven thru a
locally attached HYPERChannel A220. The channel busy characteristics
of A220 was much closer to DASD controller (per byte moved) than
3274s. This freed up additional channel capacity for DASD activity
.... and the overall system thruput increased (by 10-15 percent by
moving all the 3274s to a HYPERChannel network) which translated into
improved system response.
I then worked with one of the RETAIN people in Colorado on a similar
implementation when a large number of people were moved to a building
across the highway. In this case the T1 link was provided by a private
infrared modem mounted on the roofs of the two buildings. There was
some concern about transmission quality during rain, fog, or heavy
snow .... however the story was that the only time the link saw any
noticable bit error rate was during a white-out blizzard when nobody
was able to get in to work. The other story was about keeping the
infrared modems aligned during the day when the heating of the sun
caused one side of the buildings to get taller and tilt the pole that
the modem was attached to.
A similar design was implemented by NCAR (up the road) ... which was
basically a software MSS implementation .... a 4341 provided control
of staging data between tape<->disk and they got an upgraded A515
remote device adapter which allowed for packing off both CCWs and
search arguments into the memory of the A515 (in order to support CKD
disks). They could use dasd controllers that had a "real" channel
interface to the 4341 and a separate channel interface to the
A515s. The 4341 acting sort of like a logical 3850 MSS controller
doing the staging to/from disk. Then lots of other processors (like
non-ibm, crays, etc) could directly access the (CKD) DASD. There was
some extra function put into the A515 so the 4341 could load DASD ccw
strings along with seek/search arguments and permissions. The drivers
on the processors that wanted to directly read/write the data just had
to refer to the appropriate CCW "package" in the memory of the A515.
Similar, but different implementations were going on at LANL, LLNL,
and nasa/ames ... all involving hyperchannel in one way or another.
When we were doing HA/CMP were were interacting with just about all of
the groups, the IEEE MSS standards activity ... and even provided some
of the commercializing efforts funding (and lots of visits) ... aka
LANL->Datatree, LLNL->Unitree, NCAR->Mesa Archival.
a little more thread drift:
The NCAR design also gave rise to the IEEE support for 3rd party
transfers in HiPPI and IPI disk support.
the guy in retain that i worked with in colorado transferred to
kingston in the mid-80s and worked in the high performance computing
lab ... hooking up a bunch of FPS boxes with a 3090 ... random refs:
http://www.garlic.com/~lynn/2000c.html#5 TF-1
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002j.html#30 Weird
and our HSDT project paid for a T1 connection between that lab and the
west coast ... driven by HYPERChannel boxes and rfc1044 support that I
had written.
random hsdt stuff (including hyperchannel and rfc1044 support):
http://www.garlic.com/~lynn/subnetwork.html#hsdt
random ha/cmp stuff:
http://www.garlic.com/~lynn/subtopic.html#hacmp
misc. ncar, unitree, datatree, mesa mentions:
http://www.garlic.com/~lynn/99.html#146 Dispute about Internet's origins
http://www.garlic.com/~lynn/2000c.html#78 Free RT monitors/keyboards
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001l.html#34 Processor Modes
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public key encryption
Newsgroups: sci.crypt
Date: Fri, 24 Jan 2003 16:55:24 GMT
Michael Amling writes:
"Encryption" with the private key is usually referred to as digital
signature. Raise the signature to the public key power to find out
what was signed (Note: Digital signatures in practice are not quite
that simple.)
If you hope to keep data confidential by "encrypting" it with the
private key, then you would have to keep the public key confidential
(i.e. choose the public exponent at random rather than choosing 3 or
65537, and don't tell anyone what it is).
note that you can treat the public key as a secret key ... only shared
between those people that are suppose to read the information ... and
still retain the benefits of public/private key origin authentication.
the business process of public/private key has the part 1) of not
allowing any one but the authorized entity access to the private key
and the part of 2) publishing the public key.
the current business process concept of public key publishing is
somewhat equated to x.509 and SSL certificate stuff with public
certification authorities. however, the public/private key technology
doesn't preclude other kinds of less wide-spread publication methods.
for various business reason ... the NACHA AADS (certificate-less)
trials with hardware tokens .... had the private key on the hardware
token and the public key kept by the financial institution and never
published (after the financial institution got the public key ... the
hardware token had only the private key signing function and not
support for any kind of key export)
http://www.garlic.com/~lynn/x959.html#nacharfi
this appeared to have the business objective of restricting the
hardware token to AADS (including x9.59 like debit) transactions
http://www.garlic.com/~lynn/x959.html#x959
with only the financial institution issuing the hardware token.
there was no method of determining either the private or the public
key ... even by the person possesing the hardware token.
for the most part asymmetric key technology is related to technical
issues. the public/private key characteristics are all business
process issues .... and might have a number of different
implementations based on requirements of different business
situations.
general certificate-less related discussions:
http://www.garlic.com/~lynn/x959.html#aads
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 19:23:29 GMT
Anne & Lynn Wheeler writes:
Similar, but different implementations were going on at LANL, LLNL,
and nasa/ames ... all involving hyperchannel in one way or another.
When we were doing HA/CMP were were interacting with just about all of
the groups, the IEEE MSS standards activity ... and even provided some
of the commercializing efforts funding (and lots of visits) ... aka
LANL->Datatree, LLNL->Unitree, NCAR->Mesa Archival.
this was also related to the 3-tier architecture that we proposed ...
which caused a lot of heartburn among the saa crowd.
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
also
http://www.garlic.com/~lynn/subnetwork.html#3tier
some of the characteristics can be seen today in all the SAN stuff.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 19:25:41 GMT
"Russ Holsclaw" writes:
I can't remember who all worked on getting us set up with the
HyperChannel thing. I was working on a RETAIN re-architecture
project at the time. Our terminal connection work was being done
by folks in the Operations function. I hadn't realized you'd been
involved.
I wrote all the software support and did a lot of debugging at the STL
location before it was cloned in boulder.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: dasd full cylinder transfer (long post warning)
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 22:28:55 GMT
nospam@nowhere.com (Steve Myers) writes:
It could make a big difference for sequential reads. Sometime around
1985 or 1986 I used this little trick to measure the time from
interrupt to redrive on MVS/370 and 3330s. I found it usually took about
25% of a rotation! So, instead of taking 2 revolutions to sequentially
read a full track, because you always lost a full rotation between
the 25% lost rotation plus the remainder of the rotation waiting for
R1 to come around again, it took about 1 1/4 rotations.
... start digression ...
so one of the things that i had done in the early '70s on cp/67 was a
number of memory mapped functions. this (with the help of two BU
work/study students) I ported to vm/370 and extended.
this was sort of follow-on to the CMS changes I had done as an
undergraduate to optimize the cp kernel pathlength supporting CMS dasd
operations. this was translated into "diagnose i/O" (in large part at
the insistance of bob adair):
http://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
http://www.garlic.com/~lynn/2003.html#60 MIDAS
low-level cms filesystem functions were translated to the memory
mapped api. this allowed that cms could continue to use buffer
semantics paradigm (translated to page-mapped buffers) or do full
laid-out memory mapping (say like in program loading)
http://www.garlic.com/~lynn/subtopic.html#mmap
even with applications that continued to use buffer paradigm
semantics, there was still some thruput improvement because the
"diagnose i/o" paradigm still had the flavor of real i/o operations
.... requiring the virtual->real ccw translation (although
significantly lower pathlength than the generalized SIO ccw
translation) as well as virtual page prefixing overhead prior to
scheduling the real i/o. because the filesystem was dealing directly
with a page mapped api (even when using buffered i/o semantics), a lot
of the page prefixing/unfixing, virtual->real, and other overhead was
eliminated.
furthermore given that it was a page mapped semantics ... things like
program loading could include options as to whether the mapping
allowed sharing of segments across multiple different virtual address
spaces.
for vm/370 release 3 ... a subset of the cp kernal changes were
incorporated as discontiguous shared segments ... and the all
non-filesystem CMS changes were pretty much all incorporated (rewrite
of various applications to reside in r/o shared storage). random
stuff:
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
the full memory map support included the capability that anybody could
create and generate executable code and/or data that was definable as
shareable ... both from dasd resident standpoint as well as memory
resident standpoint .... w/o requiring any system privileges.
hone was one of the internal sites that made extensive use of the
support ... in part because they were being really stressed to provide
lots of advanced feature support to all the branch & field people in
the world:
http://www.garlic.com/~lynn/subtopic.html#hone
having created the memory-mapped api abstraction ... then underneath
the api, the kernel could do all sorts of local & dynamic adaptive
implementation tricks .... if things were heavily real storage
constrained ... the mapping didn't have to perform any operation
other than updating the virtual memory tables (whereas the real i/o
simulation code had to prefetch & lock affected virtual pages,
translate virtual->real i/o, schedule and perform real i/o, unfix and
possibly remove from storage the virtual pages involved). under zero
real storage constraints the implementation could switch to start
prefetch of all indicated page records and immediately return to the
process starting execution. the asyncronicity semantics would be
handled (transparently) by virtual memory infrastructure as to whether
a page was available or not at the moment it was needed.
.... suspend digression ...
so one demonstration was to have an application executable file out on
3330 that occupried a full 3330 cylinder ... and be able (in no
contention scenearios) to fetch the complete file in 19 revolutions
(this also required a new low level cms filesystem function that would
attempt to perform contiguous allocation ... and modifying the program
executable file generation code to specify that contiguous allocation
was desired). later was also able to demonstrate similar capability on
3380 cylinder (complete cylinder of data transfer w/o loss of
revolution). the implementation could dynamically adapt to sub full
track transfer, sequence of single full-track transfers, multiple
full-track transfers (up to full cylinder).
.... resume digression ...
so another application of this was in the cp kernel spool file system
support. this was motivated by a number of things ... but one issue
was in hsdt
http://www.garlic.com/~lynn/subnetwork.html#hsdt
the use of the spool file system by the networking support. a basic
problem was that the networking address space was serialized at every
4k worth of data transfer (read or written).
so one idea was to eliminate this serialization ... providing the
effect of both read ahead and write behind. also for data resident in
the spool file system that was being pushed out a network connection
... doing it in units of 4k bytes ... where the networking support
code could use asynchronous interface to provide the mapping of virtual
storage to disk locations ... and then let the virtual->real i/o
translation handle the serialization without serilizing the network
application code. Trick was to have the networking code do a memmory
mapped API operation with non-serialization and then use a SIOF (start
i/o fast) instruction to initiate the network i/o operation (aka the
address space would get immediate return while allowing the
virtual->real translation to proceed asynchronously).
that was just one of the identified short-comings .... if a major
effort to cleanup the spool file system was going to be undertaken,
might as well look at other issues:
1) assembler code in the kernel. redo it in vs/pascal resident in a
virtual address space.
2) linear lists of spool files. for large installations this was a cpu
killer. in the vs/pascal implementation replace the linear lists with
red/black tree implementation ... this change more than compensated
for the overhead of moving the code from assembler in the kernel to
vs/pascal in virtual address space
3) leverage the memmory mapped api for dasd interface
4) the general enabling of system function didn't happen at boot/ipl
until after the spool file system was initialized. moving the function
to virtual address space required decoupling the tight system startup
from spool file system initialization
5) if the system was shutdown/crashed cleanly (aka a system crash
would atteempt to perfom at least a warm start save of the spool file
information), the spool file system could come up quickly with warm
start saved data (which also met that the system came back up
quickly). if the system failed in non-clean mode (like power loss),
checkpoint start needed to be performed ... which could easily take
30-60 minutes on a large configuration. decoupling (#4) removed spool
file initialization from critical path of general system availability
restart.
.... suspend digression ...
one demonstration was to show redesign of the checkpoint restart
implementation using the extended memory mapped API ... reading 3380
cylinder of data with no loss in dasd revolution. this resulted in
typical worst case checkpoint recovery of a couple minutes (down from
sixty) which also was decoupled from general availability of the
system.
the other demonstration was to support contiguous allocation for new
(large) spoolfiles (with multi-block write behind) ... greatly
improving creation elapsed time as well as subsequent retrieval (with
multi-block read)
... resume digresionn ...
as a teaser ... i implemented a spoolfile<->tape application (in
vs/pascal) that could be run on any unmodified vm/370 system. This
used lots of spool file vs/pascal library code that i had written for
the full project. basically given r/o access to the full-pack dasd
areas contain the (kernel) spoolfile data .... it would perform a
spoolfile->tape backup (which resulted in same format tape as the
kernel spoolfile->tape command would generate). It also supported
tape->spoolfile effectively using the (standard system) spoolfile
diagnose interface.
past sfs posts:
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
... end post ...
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 24 Jan 2003 22:54:44 GMT
"Russ Holsclaw" writes:
I can't remember who all worked on getting us set up with the
HyperChannel thing. I was working on a RETAIN re-architecture
project at the time. Our terminal connection work was being done
by folks in the Operations function. I hadn't realized you'd been
involved.
do you recognize:
bldfe2(b580556), tie 646-2373/646-2361
later
kgnvm5(vmqr), tie 373-1894
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Fri, 24 Jan 2003 23:46:56 GMT
Anne & Lynn Wheeler writes:
also ... if i load nntp.el from 0.08 before starting 0.13 ... it
doesn't have the problem. i was hoping that it was something that was
going to get fixed w/o having to delve into it further.
ok using ognus-0.14 ... if i have the nntp-read-timeout value at
default 0.1 or set to 0.9 ... it uses 100 percent of the cpu during
startup of the newsgroups from the nttp server.
if i set the value to 1.0, it uses less than 2 percent of the cpu and
startup takes the same elapsed time.
possibly 21.2 emacs or 21.2 emacs on nt/2k issue?
i'll try and report on linux (redhat 7.3) later (same server, same
newsgroups, same dial-up link).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Lynn Wheeler <lynn@lhwlinux.ww.com>
Subject: Re: oort compute bound since 12/6 nntp.el changes
Newsgroups: gnu.emacs.gnus
Date: Sat, 25 Jan 2003 01:13:21 GMT
Anne & Lynn Wheeler writes:
i'll try and report on linux (redhat 7.3) later (same server, same
newsgroups, same dial-up link).
looks like nt/2k issue .... ognus-0.14 on 21.2 on linux (redhat7.3)
doesn't have (cpu bound) problem with nntp-read-timeout set to 0.1
(same newsgroup file, same .gnus.el file, same server, same dial-up
line & modem).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 25 Jan 2003 01:21:42 GMT
"Russ Holsclaw" writes:
That was certainly in the format of userid's at our site.
I was bldfe2(b344736). Don't recall my phone number... I had
so many in those days. Did you know Jeff Hill?
... yes .... except he had non-standard userid on bldfe2 ... aka
jeffhill at bldfe2 ... bldfe2(jeffhill); at the time tie 347-2352.
also lee stewart, lou saylor.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 25 Jan 2003 01:26:41 GMT
and for even more topic drift ... i'm in boulder monday morning to
attend talk at univ. of col.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 25 Jan 2003 02:21:16 GMT
Anne & Lynn Wheeler writes:
and for even more topic drift ...
and in two weeks i'm having dinner with somebody who was hyperchannel
engineer that i worked with way back then.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/370 disk drives
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 25 Jan 2003 15:01:08 GMT
Anne & Lynn Wheeler writes:
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
oops, typoe
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public key encryption
Newsgroups: sci.crypt
Date: Sat, 25 Jan 2003 16:59:54 GMT
"johnysputnik" writes:
However don't use the same keypair for encrypt/decrypt as for sign/verify,
if you intend to use the same algorithm for both - it becomes quite easy to
attack if the key owner is not aware of the dangers
the other reason for using different keypair for encrypt/decrypt as
for sign/verify is that the business rules tend to be different (aka
asymmetric key tends to be technology issues .... "public" key
attributes tend to be all business rule issues).
signature business rules tend to want the private key only available
to the entity signing ... even to the extent it is encapsulated in
hardware token with nobody ever knowning the private key (even the
entity in possesion of the hardware token).
encrypt/decrypt business rules tend to be much more subject to
business continuity and availability rules. typically businesses spend
huge amounts of money to guarentee no single point of failure. having
data (especially data at rest) encrypted ... and only available with
the decryption by the private key ... can represent an enormous
business risk unless that private key is replicated for availability.
as a result ... even tho the technology can be considered the same ...
and both come with the syntactic "public key" label .... in fact,
there are significant operational business process characteristic
differences between encrypt/decrypt and sign/verify.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VMFPLC2 tape format
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 25 Jan 2003 19:55:22 GMT
gah@UGCS.CALTECH.EDU (glen herrmannsfeldt) writes:
Is there any documentation on the VMFPLC2 tape format?
A google search doen't find any.
been a long time ... i had done a high performance version for
my paged mapped changes .... but it was something like
each file was something like
1st record 64byte FST
2nd-nth record 4k (or 800bytes) data
there is header record with x'02', C'CMS' (somewhat borrowing from TXT files)
... see dsect below:
...
the optimization that i did for memory mapping was something like
1st record
1 to 3 4k records with 64 byte FST appended at the end
any additional records were
3 4k records (12kbytes)
basically i read 16kbytes with SILI and figured out what I was getting
based on the residual length.
and of course .... i forced buffers to page-aligned boundaries.
from someplace:
• 3. VMFPLC2 LOOKS FOR THE FUNCTION THE USER WANTS PERFORMED. 00154000
• 00155000
• DUMP - 00156000
• @V62B5H2 00157000
• 1. THE FST RECORD IS WRITTEN TO TAPE FIRST, WITH @V62B0H2 00158000
• A COPY OF THE FST IN IT. THIS COPY IS USABLE FOR @V62B0H2 00159000
• EITHER EDF DISK FSTS, OR NON-EDF DISK FSTS. @V62B0H2 00160000
• THE FORMAT IS: @V62B0H2 00161000
• @V62B0H2 00162000
• X'00'+-----------------------------+ @V62B0H2 00163000
• | F I L E N A M E | @V62B0H2 00164000
• X'08'|-----------------------------| @V62B0H2 00165000
• | F I L E T Y P E | @V62B0H2 00166000
• X'10'|-----------------------------| @V62B0H2 00167000
• | X'MMDDHHMM' |WRT PTR|RD PTR| @V62B0H2 00168000
• X'18'|-----------------------------| @V62B0H2 00169000
• | MODE |# ITEMS| FCL |F/V|FL| @V62B0H2 00170000
• X'20'|-----------------------------| @V62B0H2 00171000
• | LRECL |DB CNT | YEAR | @V62B0H2 00172000
• X'28'|-----------------------------| @V62B0H2 00173000
• |#FULL TAPE BLK|LTH LSTBLK/800| @V62B0H2 00174000
• X'30'|-----------------------------| @V62B0H2 00175000
• | FILE ORIG PTR| ALT DATA BLK | @V62B0H2 00176000
• X'38'|-----------------------------| @V62B0H2 00177000
• | ALT ITEM CNT |#LV|PTRSZ|YYMM| @V62B0H2 00178000
• X'40'|-----------------------------| @V62B0H2 00179000
• | DDHHMMSS | RESERVED | @V62B0H2 00180000
• X'48'|-----------------------------| @V62B0H2 00181000
• @V62B0H2 00182000
• @V62B0H2 00183000
• 2. FSTLKP IS CALLED TO FIND THE FILE TO BE DUMPED. I@V62B0H2 00184000
• FOUND, 'HX' IS PREVENTED AND IT'S FST IS ALTERED TO INDI 00185000
• CATE A FIXED LENGTH FILE WITH A RECORD LENGTH OF 800 00186000
• BYTES. THE FST RECORD (MARKED BY A C'D' FLAG BYTE @V62B0H2 00187000
• IS WRITTEN TO TAPE AND FOR EACH FILE, ITS BLOCKS @V62B0H2 00188000
• ARE READ (VIA RDBUF OR BLK READ) AND WRITTEN @V62B0H2 00189000
• ONTO TAPE(VIA TAPEIO) UNTIL EOF IS REACHED. 00190000
• FOR EDF DISKS, THIS ALTERATION OF THE FST IS NOT @V62B5H2 00191000
• PERFORMED, AS THE FILE IS READ USING DMSEBLKR, @V62B5H2 00192000
• TO READ SEQUENTIAL BLOCKS OF THE FILE. @V62B5H2 00193000
.... and
• @V62B0H2 02641000
• TAPE BUFFER AREA. @V62B0H2 02642000
• @V62B0H2 02643000
COUTSTRT DS CL3 @V62B0H2 02644000
CARDOUT DS CL4 X'02', C'CMS' @V62B0H2 02645000
FLAGOUT DS CL1 'N'=END OF FILE, '0'=NULL BLOK @V62B0H2 02646000
DATAOUT DS CL800 @V62B0H2 02647000
• REMAP THE INPUT BUFFER WITH THE CINAREA DSECT @V62B0H2 02648000
CINAREA DSECT NEW DSECT FOR "FLOATING" TAPE BUFFER@V62B0H2 02649000
CINSTRT DS 3C @V62B0H2 02650000
CARDIN DS CL4 X'02', C'CMS' @V62B0H2 02651000
FLAGIN DS CL1 'N'=END OF FILE, '0'=NULL BLOK @V62B0H2 02652000
DATAIN DS CL800 @V62B0H2 02653000
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VMFPLC2 tape format
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 25 Jan 2003 20:17:18 GMT
somewhat topic drift ... my enhanced version i called vmxplc ... and
could run on vanilla cms systems ... didn't mandate the page mapped
file system enacements to operate:
http://www.garlic.com/~lynn/subtopic.html#mmap
however i added some additional enhancements to vmxplc and it was used
as the basis for the san jose backup/archive system that i wrote (it
was installed at sjr, hone and a number of other internal operations
on the west coast). after some additional enhancements, it morphed
into a product as workstation datasave facitlity ... which then
morphed into adsm and now tsm.
http://www.garlic.com/~lynn/subtopic.html#backup
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: filesystem structure, was tape format (long post)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 26 Jan 2003 16:47:18 GMT
long-winded and lots of drift
cms fst ref
http://www.garlic.com/~lynn/2003b.html#42 VMFPLC2 tape format
os/360 ckd, vtoc, & pds:
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#22 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#26 360/370 disk drives
in os/360 the vtoc ... originally always on cylinder zero ... but
starting with release 15/16, os/360 dasd format/initialization allowed
specification of the cylinder that the vtoc resided on. since vtoc was
frequently high-use data area (and was never cached ... as per
previous discussion regarding ckd trade-off between scarce memory
resource and i/o bandwidth) ... it was possible to place it at the
middle of the pack as part of strategy attempting to do arm movement
optimization.
prior to release 15/16, i would cleanly format a os pack and then very
carefully order the pre-allocation of the PDS library (sizes) (with
objective of achieving minimial arm motion). Then i would run a
carefully crafted sysgen ... where I had reordered the majority of
theIEHMOVE/IEBCOPY statements so that members would be placed in the
(new) library PDS to achieve minimum arm motion. On MFT release 11 and
release 14 systems (for the typical university workload), i could
achieve nearly three times the thruput compared to an out-of-the-box
os/360 sysgen. However, this would degrade to possibly only twice over
a six month period with normal system PTF activity (replacing various
members in the PDS libraries). long ago posting:
http://www.garlic.com/~lynn/94.html#18 CP/67 and OS MFT14
slight memory slip in the above reference, the presentation wasn't
houston share ... which was spring '68, where cp/67 was announced and
only a couple months after cp/67 was installed at the university. the
presetation was at the fall '68 share ... which i believe was boston
(although i did do earlier share presentations on hand-built sysgens
of mft11 and mft14). the hand-built sysgens improved over time as i
was able to get better and better trace information about typical PDS
system library member loading patterns.
cms from version started with cp/40 back in the mid-60s basically
would format a dasd to simulate fixed-block architecture ... and have
a table of allocated and unallocated records. as you started to write
a file, it would start dynamically allocating records from the dasd
available pool. as records were allocated to a file ... it would start
building a table (hyperblocks) of records allocated to that file. a
file's fst (in the above vmfplc2 reference) would contain a pointer to
the file's hyperblocks. the initial cms filesystem used a (fixed)
record size of 800 bytes for everything.
os/360 would do "file" allocation for the size of an initial
contiguous area of dasd tracks (although the size specification could
be done in number of records of specific size, number of tracks, or
number of cylinders), along with a secondary extent size. The file
information and space allocation would be in the vtoc. a file would
get its initial allocation (even before any writes were performed)
... the space could be dynamically extended with a limited number of
"extents".
in the mid-70s, the CMS (extended) EDF filesystem was added
(concurrent support for the original and EDF filesystems). A disk area
could be formated as either the original filesystem or the EDF
filesystem ... with the EDF filesystem supporting (fixed) record sizes
of 1k, 2k, or 4k.
memory-mapped filesystem stuff
http://www.garlic.com/~lynn/subtopic.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 F