List of Archived Posts
2004 Newsgroup Postings (01/01 - 01/28)
- comp.arch classic: the 10-bit byte
- Saturation Design Point
- The BASIC Variations
- The BASIC Variations
- TSS/370 source archive now available
- The BASIC Variations
- The BASIC Variations
- Dyadic
- virtual-machine theory
- Dyadic
- Dyadic
- Dyadic
- virtual-machine theory
- Holee shit! 30 years ago!
- Holee shit! 30 years ago!
- Holee shit! 30 years ago!
- Holee shit! 30 years ago!
- Holee shit! 30 years ago!
- virtual-machine theory
- virtual-machine theory
- BASIC Language History?
- 40th anniversary of IBM System/360 on 7 Apr 2004
- 40th anniversary of IBM System/360 on 7 Apr 2004
- Holee shit! 30 years ago!
- 40th anniversary of IBM System/360 on 7 Apr 2004
- 40th anniversary of IBM System/360 on 7 Apr 2004
- 40th anniversary of IBM System/360 on 7 Apr 2004
- dual processors: not just for breakfast anymore?
- Two subjects: 64-bit OS2/eCs, Innotek Products
- passwords
- Threat of running a web server?
- Two subjects: 64-bit OS2/eCs, Innotek Products
- BASIC Language History?
- passwords
- Two subjects: 64-bit OS2/eCs, Innotek Products
- 40th anniversary of IBM System/360 on 7 Apr 2004
- merged security taxonomy & glossary
- When rsa vs dsa
- When rsa vs dsa
- AMD/Linux vs Intel/Microsoft
- AMD/Linux vs Intel/Microsoft
- AMD/Linux vs Intel/Microsoft
- 40th anniversary of IBM System/360 on 7 Apr 2004
- [Fwd: Re: Mainframe not a good architecture for interactive w
- OT The First Mouse
- 40th anniversary of IBM System/360 on 7 Apr 2004
- DE-skilling was Re: ServerPak Install via QuickLoad Product
- Mainframe not a good architecture for interactive workloads
- AMD/Linux vs Intel/Microsoft
- Mainframe not a good architecture for interactive workloads
- Mainframe not a good architecture for interactive workloads
- Mainframe not a good architecture for interactive workloads
- AMD/Linux vs Intel/Microsoft
- Mainframe not a good architecture for interactive workloads
comp.arch classic: the 10-bit byte
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: comp.arch classic: the 10-bit byte
Newsgroups: comp.arch
Date: Thu, 01 Jan 2004 14:29:57 GMT
"Stephen Fuld" writes:
Yeah, I guess so. Still tens of usec seems a long time to have
interrupts disabled. But the tradeoff versus doing all the work of
a full I/O was probably worth it. On the other hand, the only
reason this was needed at all was due to that cardinal mistake of
computer architecture, not allowing enough address bits. :-(
I was told that it was because of physical packaging ... not number of
addressing bits .... it was going to have to be NUMA of some kind; aka
the additional memory was going to have to be physically packaged
where there was going to have to be increased latency to physically
reach the additional memory. going to explicit different kind of
access allowed more latitude in amount of data transferred in an
access and streaming of the access ... as partial delay propagation
compensation.
slight drift, there was earlier instance of 3033 which had a hack
where the size of physical memory addressing (26bits) was larger than
logical memory addressing (24bits) by going to more bits in page table
entry.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Saturation Design Point
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Saturation Design Point
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 02 Jan 2004 14:09:01 GMT
jmfbahciv writes:
It was a way to mark and name when the event of sweeping the
cache (thus updating memory) was done. Caution: I'm going
to use TOPS-10 terminology here so our meanings may get jumbled.
Let's say Job 2 ran on CPU1 and wrote some stuff to a memory
buffer assigned to a disk output file buffer ring. The
job goes into I/O wait so CPU1 puts the job on a queue and picks
another job to run. Meanwhile, CPU0 runs out of things to do,
finds that Job 2 needs attention (CPU0 has a hard wire to the
channel/disk that Job 2 needs. So it picks Job 2 to run.
Job 2's output buffer in memory may not have the newly written
data because CPU0 picked Job 2 to run before CPU1 flushed its
cache. CPU0 believes that memory is good and had no way to
know if CPU1 had done its business or not. It was also a design
of SMP (the S in symmetric) that one CPU cannot be put in wait
for another CPU. <shudder> Deadlocks and deadly embraces would
be just the icing on that cake of worms.
Byte pointers were a common word of memory that could be incorrect.
One of the words in the buffer headers was the byte pointer to the
current buffer to be filled/emptied.
370s & later had store-thru caches.
rios had store-in cache and no provision for cache coherency .... and
was perceived to not be multiprocessor system; it was one of the
reasons we did ha/cmp for scale-up although we had worked on smp in
the past (and were particpating in some sci standards stuff).
there was a sort of 4-way smp rios using rios.9 chips ... which had
the convention that a segment table could be flagged where it wouldn't
cache the data.
it wasn't until power/pc that there was provisions made for cache
cohenency and real multprocessor operation.
random hacmp stuff:
http://www.garlic.com/~lynn/subtopic.html#hacmp
random smp stuff:
http://www.garlic.com/~lynn/subtopic.html#smp
note that compare&swap instruction had been developed for process
serialization/syncronization. lots of past compare&swap refs:
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/93.html#22 Assembly language program for RS600 for mutual exclusion
http://www.garlic.com/~lynn/94.html#02 Register to Memory Swap
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#45 SMP, Spin Locks and Serialized Access
http://www.garlic.com/~lynn/95.html#8a atomic load/store, esp. multi-CPU
http://www.garlic.com/~lynn/97.html#10 HELP! Chronology of word-processing
http://www.garlic.com/~lynn/97.html#19 Why Mainframes?
http://www.garlic.com/~lynn/98.html#8 ** Old Vintage Operating Systems **
http://www.garlic.com/~lynn/98.html#16 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/99.html#88 FIne-grained locking
http://www.garlic.com/~lynn/99.html#89 FIne-grained locking
http://www.garlic.com/~lynn/99.html#176 S/360 history
http://www.garlic.com/~lynn/2000.html#80 Atomic operations ?
http://www.garlic.com/~lynn/2000e.html#4 Ridiculous
http://www.garlic.com/~lynn/2000e.html#22 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#25 Test and Set: Which architectures have indivisible instructions?
http://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#32 Multitasking and resource sharing
http://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001b.html#33 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#40 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001d.html#26 why the machine word size is in radix 8??
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?
http://www.garlic.com/~lynn/2001f.html#21 Theo Alkema
http://www.garlic.com/~lynn/2001f.html#41 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#61 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#70 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#73 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#74 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001f.html#76 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001g.html#4 Extended memory error recovery
http://www.garlic.com/~lynn/2001g.html#8 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001g.html#9 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
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/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2001k.html#12 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2001k.html#54 DEC midnight requisition system
http://www.garlic.com/~lynn/2001k.html#65 SMP idea for the future
http://www.garlic.com/~lynn/2001k.html#66 SMP idea for the future
http://www.garlic.com/~lynn/2001k.html#67 SMP idea for the future
http://www.garlic.com/~lynn/2001k.html#69 Programming in School (was: Re: Common uses...)
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#42 Cache coherence [was Re: IBM POWER4 ...]
http://www.garlic.com/~lynn/2001n.html#43 IBM 1800
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002b.html#48 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002h.html#21 PowerPC Mainframe
http://www.garlic.com/~lynn/2002h.html#24 PowerPC Mainframe
http://www.garlic.com/~lynn/2002h.html#45 Future architecture [was Re: Future micro-architecture: ]
http://www.garlic.com/~lynn/2002h.html#46 Future architecture
http://www.garlic.com/~lynn/2002h.html#55 Future architecture [was Re: Future micro-architecture: ]
http://www.garlic.com/~lynn/2002i.html#82 HONE
http://www.garlic.com/~lynn/2002l.html#18 ISAs, SMP and hardware optimisations
http://www.garlic.com/~lynn/2002l.html#58 Spin Loop?
http://www.garlic.com/~lynn/2002l.html#59 Spin Loop?
http://www.garlic.com/~lynn/2002l.html#69 The problem with installable operating systems
http://www.garlic.com/~lynn/2002m.html#1 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#12 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003.html#18 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
http://www.garlic.com/~lynn/2003.html#72 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#20 Card Columns
http://www.garlic.com/~lynn/2003b.html#26 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?
http://www.garlic.com/~lynn/2003c.html#78 The relational model and relational algebra - why did SQL become the industry standard?
http://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
http://www.garlic.com/~lynn/2003e.html#67 The Pentium 4 - RIP?
http://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003g.html#30 One Processor is bad?
http://www.garlic.com/~lynn/2003h.html#5 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003h.html#20 UT200 (CDC RJE) Software for TOPS-10?
http://www.garlic.com/~lynn/2003j.html#58 atomic memory-operation question
http://www.garlic.com/~lynn/2003k.html#45 text character based diagrams in technical documentation
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003m.html#29 SR 15,15
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2003o.html#32 who invented the "popup" ?
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
The BASIC Variations
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: alt.folklore.computers
Date: Sat, 03 Jan 2004 18:32:20 GMT
"J.Clarke" writes:
I dunno--you got me puzzled now--I'm sure you're remembering
_something_ right but I don't recall what. Perhaps you're thinking
of when they brought in McNamara (the uber-PHB) and his "whiz kids"
(mini-PHBs) and started running the DoD on the basis of "cost
effectiveness", with the results being painfully obvious to the
soldiers on the ground in Vietnam. The appalling part of it was
that he was kept in office for 8 years instead of having his butt
fired when it became clear that his approach was costing lives and
gaining nothing. FWIW, McNamara apologized for this a few years
ago--the countless men who lost friends, health, or just years of
their lives in Vietnam however do not seem to be in any hurry to
forgive him. I would be interested in knowing what General Giap
thought of his book and his apology. Unfortunately I lost touch
with my Viet Cong friend (4'2, so smart she's almost scary,
stunningly beautiful even in her late '40s, sweetest person you'd
ever care to meet, bakes a mean cookie, happily married alas, but
_do__not__mess__with__her_) before McNamara's book came out, so
can't get her opinion, and have no idea how to contact Giap.
slightly related:
http://www.garlic.com/~lynn/99.html#120 atomic History
and
http://www.garlic.com/~lynn/subboyd.html#boyd
one of the biographies has a chapter on the year he spent running one
of the largest datacenters around ... and definitly the largest in the
far east.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
The BASIC Variations
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: comp.lang.basic.misc,alt.lang.basic,alt.folklore.computers
Date: Sun, 04 Jan 2004 18:41:07 GMT
erewhon@nowhere.com (J French) writes:
That sort of fault tolerance sounds pretty impressive
- I did not realize it was present in the early(ish) DECs
- Tandem comes to mind .. as does the early RAID stuff
TL brought up an interesting point
- hardware failure can bring down the whole house of cards
- OTOH the 'house of cards' would probably not exist without
computerization
I sometimes wonder how long people would last if the water supply was
shut off - technology increases vulnerability (?)
technology frequently tends to reduce redundancy ... fewer spare
resources needed for the general case because of things like delivery
optimization (more and more just in time stuff). the other aspect is
the ability to support higher level of service w/o increasing the
resources needed to provide the service. this in turn, reduces the
cost of providing the service ... since higher level of activity is
provided w/o increasing the amount of resources.
however, highly leveraged systems can be prone to severe degradation
with only minior disruption; one example might be the chicago
airport example discussed recently.
http://www.garlic.com/~lynn/2003o.html#27 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#33 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#41 When nerds were nerds
complex infrastructure of any kind (not necessarily technology)
frequently increases vulnerability ... in part because the complexity
itself can lend to failures occuring in unanticipated ways.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
TSS/370 source archive now available
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS/370 source archive now available
Newsgroups: bit.listserv.ibm-main
Date: Mon, 05 Jan 2004 03:21:32 GMT
mainframedave@ibm-main.sbcglobal.net (David Alcock) writes:
I've always wondered what VSPC looked like. I see that a college has this
definition for VSPC:
Virtual Storage Personal Computing - A general purpose,
interactive time-sharing system formerly used on UNM's
mainframe computers and superceded by MUSIC.
I used MUSIC in college.
vspc ... was originally named pco ... personal computing option
(possibly chosen as a variation on tso?) but it turned out that "pco"
was already in use in europe ... so it was decided that a name change
was needed. misc past pco/vspc refs:
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
http://www.garlic.com/~lynn/2003k.html#0 VSPC
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
The BASIC Variations
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: comp.lang.basic.misc,alt.folklore.computers
Date: Mon, 05 Jan 2004 03:45:48 GMT
"Bill Leary" writes:
It was actually sort of n odd thing to go to the VAX, open it up and
install a new microcode disk (or diskette) in the PDP. I'd gotten
so fixed on the idea the 8" and 5.25" floppies were PC-only things.
references to shugart inventing the diskette for distributing/loading
microcode .... 1971 microcode load for system/370s and for 3830 disk
controllers (i.e. 3830 controller for 3330/merlin disk drives).
random shugart/diskette refs from search engine:
http://www.cnn.com/TECH/computing/9907/08/1971.idg/index.html
http://www.accurite.com/FloppyPrimer.html
http://inventors.about.com/library/weekly/aa110198.htm
http://www.oldcomputers.net/trs80ii.html
http://www.newton.mec.edu/brown/TE/HOT/STUDENTS/BARGAR/timeline.html
http://www.miami.com/mld/miamiherald/5387554.htm
http://history.acusd.edu/gen/recording/mag/p44.html
http://www.canoe.ca/TechNews0009/27_gazin.html
http://www.feb-patrimoine.com/Histoire/english/information_technology/information_technology_4.htm
http://www.sal.ksu.edu/faculty/gregs/hist231/portfolios/comphistory/components.htm
this mentions shugart having done the 2321 ... and several other
projects including the diskette
http://www.columbia.edu/acis/history/datacell.html
random 360/370 microcode refs::
http://www.garlic.com/~lynn/subtopic.html#360mcode
random past merlin refs:
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#17 index searching
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#54 "average" DASD Blocksize
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
The BASIC Variations
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: comp.lang.basic.misc,alt.folklore.computers
Date: Mon, 05 Jan 2004 19:04:38 GMT
Keith R. Williams writes:
In IBM these (and there may have been four heads per track) were known
as "fixed head disks" or perhaps "drums", even though they were disks.
These were normally used for paging store.
there was 2303 and 2301 fixed-head "drums" for the 360 (small spinning
barrel with tracks on the outside). The 2301 read/wrote four heads in
parallel for four times the data transfer rate of the 2303.
later in the 370 time-frame there was 2305-1 & 2305-2 fixed head
disk. one of them had half the capacity because half the heads were
off-set 180 degrees on paired tracks. there were half as many tracks
but the same number of heads. avg. latency was based on rotation only
needing to make half revolution maximum to get a record under a head.
one of the reasons/justifications for the term DASD (direct access
storage device) was because there were a number of technologies in the
60s, some things like the 2321 datacell. drums predated disks by quite
a bit (and a number of vendors eventually had them).
early post in part of this thread has pointer to 2321 reference,
somewhat in conjunction with diskette history:
http://www.garlic.com/~lynn/2004.html#5 The BASIC variations
another 2321 reference:
http://members.optushome.com.au/intaretro/2321DCD.htm
misc. dasd/drum search engine ref
http://www.computerworld.com/hardwaretopics/storage/story/0,10801,75215,00.html
the following
http://www.beagle-ears.com/lars/engineer/comphist/ibm_nos.htm
mentions that main memory for 650 computer was rotating drum (1953) and
the 733 was 8192 word magnetic drum
other 650 references:
http://www-1.ibm.com/ibm/history/exhibits/650/650_ph09.html
http://www.mta.ca/~amiller/ibm650/ibm650.htm
http://www.columbia.edu/acis/history/650.html
http://www.cedmagic.com/history/ibm-650-drum.html
http://portal.acm.org/citation.cfm?doid=320764.320768
a couple 733 references
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP704.html
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP709.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Dyadic
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dyadic
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 05 Jan 2004 19:39:49 GMT
Kees.Vernooy@ibm-main.klm.com (Vernooy, C.P. - SPLXM) writes:
The 3081 was explained to us as a two-headed monster, hence dyadic,
with two equal, full functional heads (processors) on one body. The
former machines (303x series) had 1 full function head and could
have added an extra one (a so called Attached Processor), but with
limited funtionality, no I/O etc.
Its power was explained by comparing it to a hammer: if you want to
hammer nails more quickly, you could beat faster, use a heavier
hammer etc, until the 308x period. Then you head a hammer with 2
(3081) of 4 (3084) heads, so you could nail 2 or 4 times as much
nails than before, with the same action.
360/65 had full duplex smp. it was two completely independent
processor complexes that could be either both operate totally
independently or combined to share memory and operate as a two
processer symmetric multiprocessor. however, the channel
configurations weren't integrated so both processors continued to have
(only) their locally attached I/O configuration. to allow both
processers access to a common set of devices, the device I/O
controllers were typically configured with twin tails; each one
connected to a channel attached to each processor.
the 360/67 was more sophisticated design and had a channel controller
that allowed integration of all channels available to all processors.
360/67 had provisions for reading the setting of the channel
controller switches in control registers (which also provided for
configuring memory banks). the 360/67 was originally designed to
support up to four processor configurations but except for one
triplex, i believe only two-processor configurations were actually
built. The triplex was somewhat unique in that not only could the
settings of the channel controller switches be read with the control
registers ... but it was also possible to modify the channel
controller switches by changing bits in the control registers. note
also that the 360/67 support both 24-bit and 32-bit virtual addressing
(32-bit not 31-bit).
a lot of work on 360/67 smp at cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech
resulted in the smp compare and swap instruction that shows up on 370
(CAS are the initials of the person at cambridge responsible for the
compare and swap instruction invention). lots of past smp references
http://www.garlic.com/~lynn/subtopic.html#smp
as special, custom hardware there were also the 9020 machines for the
FAA air traffic control system (modified 360/50s).
the 370/158 & 370/168 implementation regressed to the 360/65 smp
implementation ... two independent hardware configurations that could
have their memory combined ... but retained their private,
independent, non-integrated channel connections (and could be divided
and run as two completely independent uniprocessor). none of the
advance features found in the 360/67 multiprocessor made it into 370
(as well as only 24bit virtual addressing).
370/158 and 370/168 were also available in multiprocessor
configurations where only a single processor had attached I/O
channels. This was what was referred to as attached processor
configuration.
The 3081 was designed as a fully functional two processor
configuration but w/o the additional hardware necessary to operate as
two completely independent uniprocessors (power supplies, connectors,
etc). It also started to show some of the more advanced features that
had been implemented in the 360/67 like having more than 24-bit
virtual addressing and allowing all processors to access all channels.
However, it didn't have the extended ras and configurability
capability that was implemented in the 360/67 triplex channel
controller. There was never orignally intended to be a 3083 ... but I
believe it was finally produced for the TPF/ACP market place (at the
time, TPF/ACP didn't yet have support for multiprocessor operation).
following has some of the control register bit definitions from
the 360/67 blue card:
http://www.garlic.com/~lynn/2001.html#69 what is interrupt mask register?
http://www.garlic.com/~lynn/2001.html#71 what is interrupt mask register?
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
random past 3084 refs:
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000d.html#9 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#62 z/Architecture I-cache
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2002h.html#46 Future architecture
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
http://www.garlic.com/~lynn/2002p.html#59 AMP vs SMP
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#8 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003g.html#30 One Processor is bad?
http://www.garlic.com/~lynn/2003j.html#42 Flash 10208
http://www.garlic.com/~lynn/2003p.html#45 Saturation Design Point
lost of random 9020 references
http://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/2001e.html#13 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001g.html#45 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2001i.html#14 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#15 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#13 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2001k.html#65 SMP idea for the future
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#53 A request for historical information for a computer education project
http://www.garlic.com/~lynn/2001n.html#62 The demise of compaq
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002b.html#32 First DESKTOP Unix Box?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002e.html#5 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002f.html#29 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#42 Blade architectures
http://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#19 PowerPC Mainframe?
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2002i.html#79 Fw: HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#10 What is microcode?
http://www.garlic.com/~lynn/2002l.html#39 Moore law
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2002o.html#28 TPF
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#59 AMP vs SMP
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#48 InfiniBand Group Sharply, Evenly Divided
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#30 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#7 Low-end processors (again)
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#50 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#52 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
http://www.garlic.com/~lynn/2003j.html#58 atomic memory-operation question
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003m.html#4 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#37 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2003o.html#52 Virtual Machine Concept
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2003p.html#40 virtual-machine theory
http://www.garlic.com/~lynn/2004.html#1 Saturation Design Point
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
virtual-machine theory
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual-machine theory
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 07 Jan 2004 14:49:26 GMT
glen herrmannsfeldt writes:
Well, I think it is usual to exclude timing related tests, though
the Principles of Operations doesn't guarantee timing, anyway.
from POP standpoint, timing issues would have been model dependent as
well as execution of diagnose instruction. pop specified conformance
across wide range of hardware implementations and performance
(microcoded and hardwired).
even within same model ... things like integrated channels and/or
controllers would have some amount of variance because of various
cycle stealing issues i.e. the same hardware engine was shared
between microcode that implemented "mainframe" insturctions and
microcode that implemented channels and/or controller functions.
simple example is that 3031 is effectively identical hardware as
158. however for the 303x processors, a 158 hardware engine was split
off and dedicated to channel director ... implementing just the
channel function.
a 370/158 was a single hardware engine that was shared between
executing 370 microcode program and channel microcode program. A 3031
had a dedicated (158) engine for just the 370 microcode and a second
(158) engine for executing the channel microcode.
random past posts on channel director:
http://www.garlic.com/~lynn/97.html#20 Why Mainframes?
http://www.garlic.com/~lynn/98.html#23 Fear of Multiprocessing?
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#176 S/360 history
http://www.garlic.com/~lynn/99.html#187 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
http://www.garlic.com/~lynn/2000c.html#69 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#21 S/360 development burnout?
http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#3 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#6 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#14 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#21 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002p.html#59 AMP vs SMP
http://www.garlic.com/~lynn/2003.html#39 Flex Question
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003g.html#32 One Processor is bad?
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Dyadic
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dyadic
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 07 Jan 2004 15:00:48 GMT
IBM-MAIN@ibm-main.isham-research.com (Phil Payne) writes:
The 3033 was not in any way a stopgap system. An awful lot of
design went into it. The 3032 was never a major success, and by the
end of the 303x era IBM had announced the 3033N and 3033S in their
respective spaces. The 3033S was a silly machine - it was the
physical size of a 3033 but only had a 512B (there's no K missing)
cache. If you wrote a synthetic instruction loop that would fit in
512 bytes, it was as fast as a 3033U. I lost a benchmark at the
Finanzamt Charlottenburg that way and now have a life-long hatred of
synthetic kernels. IBM upped the buffer to 1KB at one point.
303x had 158 engine dedicated as channel director.
3031 was effectively a 158 repackaged with 158 engine dedicated to 370
microcode and a second 158 engine dedicated to channel microcode
(370/158 shared the same 158 engine for both 370 microcode and channel
microcode).
3032 was effecitvely a 168 repackaged to use 303x channel director
3033 started out as 168 wiring design remapped to faster chip
technology that was something like 20 percent faster than the 168 chip
technology (which would have made 3033 about 20 percent faster than
168). late in the 3033 design, there was some competitive pressure to
make it close to 50 percent faster than 168. the 168 chip technology
had four circuits per chip ... the 3033 chip technology in addition to
being about 20 percent faster also had something like 40 circuits per
chip ... but initially was only going to utilize the 168 wiring design
using four circuits per chip. The late, aggresive performance upgrade
looked at redesigning critical portions of the processor, including
leveraging more circuits per chip and additional performance of
intra-chip operation.
there was comments that after 370 there were two parallel efforts
... offset in time ... the 3033 being effort of the 168 group, the
3081 being effort of the 158 group, and the 3090 being effort of the
168 group
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Dyadic
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dyadic
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 07 Jan 2004 16:48:52 GMT
dba@ibm-main.lists.duda.com (David Andrews) writes:
Perhaps we're at odds with the characterization: "repackaged" is
different from "recycled". My interpretation is that the directors were
new equipment, but not new designs.
Someone told me once that the service processor on the 3081 was a
reworked 8100 -- but I never dreamed it was an actual returned 8100. As
I mentioned earlier, American tax law at the time would have made this
problematic.
I had heard that the 8100 used a uc.5 microprocessor and the service
processor in the 3081 was a uc.5 microprocessor (i.e. the 3081 wasn't
an 8100 ... but the service processing in the 3081 used the same
hardware engine as was used in the 8100).
303x channel directors were 158 engines with just the integrated
channel microcode and the 370 microcode stripped out. a 3031 was a
pair of 158 engines ... one engine dedicated to 370 microcode and one
engine (channel director) dedicated to integrated channel microcode
(while a 370/158 engine had the same engine sharing the two sets of
microcode, 370 microcode and integrated channel microcode).
i was once told that the incremental manufacturing cost of each
additional 158 engine was similar to highly automated car
manufacturing (i.e. not including NRE, up-front design, plant
construction, line construction & setup, etc).
the 3090 started out having a service processor that was a 4331
running a customized version of vm/370 release 6 ... with all the
service panels implemented in cms ... and evolved into a pair of 4361s
running customized version of vm/370 release 6)
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Dyadic
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dyadic
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 08 Jan 2004 14:35:47 GMT
Keith R. Williams writes:
The ES9000 used a PS/2 running OS/2 as its service processor. I
believe the 'z' systems use a ThinkPad.
note that the service processor has lots of probes/connectors into
all parts of the machine to run the diagnostics necessary to do
service. the service processor also interfaced to a lot of other
parts of the machine; aka it wasn't just the keyboard/display
interface.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
virtual-machine theory
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual-machine theory
Newsgroups: alt.folklore.computers
Date: Tue, 13 Jan 2004 21:29:42 GMT
dpeschel@eskimo.com (Derek Peschel) writes:
So the 68000 allows any program to tell whether it's in supervisor mode
or not. And presumably the supervisor/user mode is related to the
virtual/real mode, so you have a program that can tell if it's running
virtually, which is bad.
But is that the whole answer? I can imagine a VM executive running in
supervisor mode running a guest also in supervisor mode. So the relation
between the two modes could be weak, _if_ you make sure that the host
always controls all aspects of the guest CPU. Do the 68010 and later
promise that? For example, do they trap attempts to read the SR and let
the executive determine the guest's SR?
we had a guest (370) operating system
running under a vm executive providing 370 virtual machines
running under a vm executive providing 370 virtual machines
running under a vm executive providing 360/67 virtual machines
running on a microcded 360/67
the issue was that the generalized vm executive provided public access
time-sharing at same time doing a joint project with endicott on 370
operating systems before 370 virtual memory was announced.
the "2nd level" vm executive believe it was running on 360/67
architecture but provided 370 virtual machines (which had some number
of architecture differences from 360/67 virtual machines).
the "3rd level" vm executive believed it was running on 370
architecture and provied 370 virtual machines.
the top level was a guest operating system that believe it was running
(on unannounced) 370 real machine.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Holee shit! 30 years ago!
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit! 30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Tue, 13 Jan 2004 23:24:16 GMT
cstacy@news.dtpq.com (Christopher C. Stacy) writes:
When the page goes from memory to disk, the page is "swapped out".
Are you trying to ask what's it called when you "remove" a page
from core (because it's no longer part of the working set, and you
want that core for the free list or something), but it's not dirty?
I don't think there's a special name for that -- one would just
say we are "invalidating the page map entry" or "freeing a page".
i actually had big argument with the original VS2/SVS on the dirty
page issue. basically the idea was to implement an approximation to
LRU; however the performance modeling group in POK came up with a hack
on LRU approximation that would select non-changed pages before
changed pages .... because there was much less work stealing
non-changed pages (which didn't have to be written out before they
were scavenaged). they continued this page replacement strategy well
into MVS before they came to the conclusion that "stealing" high-use,
shared-program (linkpack) pages before they were stealing low-use,
private, modified data pages ... wasn't all that good an idea.
that later changed with the big page strategy introduced with 3380s
... since when a big page was brought into memory ... all the disk
records were de-allocated. With no saved copy of a page on disk, *all*
stolen (replaced) pages had to be (re)written ... whether or not they
had been changed during the most recent stay in memory (when there was
no previously saved image of a page on disk, removing it from memory,
forced a write).
misc. discussion on page replacement, working set, etc:
http://www.garlic.com/~lynn/subtopic.html#wsclock
rather recent discussion of big pages (comp.arch) ... along with lots
of references to past big page discussions:
http://www.garlic.com/~lynn/2003o.html#61 1teraflops cell processor possible?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Holee shit! 30 years ago!
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit! 30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 15 Jan 2004 01:04:07 GMT
Brian Inglis writes:
Instead, like Java, the program goes away and garbage collects at
random intervals, when its filled the whole address space with junk.
The users really love unpredictable response time: it was bad enough
when systems were slower but programs had small address spaces (like
64KB).
IMHO one reason why languages with garbage collection were never
widely used for user programs. This generation has just jumped on
the bandwagon and is going to learn the hard way why it never became
popular. Whatever happened to all the research and implementations
of nice incremental garbage collector algorithms developed in the
1970s to replace the nasty bulk mark and sweep (pronounced Markt und
Sveep!) algorithms that trash virtual memory?
that was done as part of porting apl\360 to cms\apl in the early 70s
(30 plus years ago) i.e. instead of swapping 16k workspaces that you
might get with apl\360 ... cms\apl had available the virtual address
space.
misc. past past posts about some of the analysis and vs/repack.
http://www.garlic.com/~lynn/93.html#5 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/99.html#20 APL/360
http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002f.html#50 Blade architectures
http://www.garlic.com/~lynn/2002q.html#47 myths about Multics
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits
http://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Holee shit! 30 years ago!
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit! 30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 15 Jan 2004 01:21:29 GMT
"Shmuel (Seymour J.) Metz" writes:
Motorola had a separate MMU chip for the 68000 line; I don't recall
whether it was for the 68010 or the 68020. At some point the
functionality became part of the processor chip. I don't recall wher
National Semiconductor or Zylog had an MMU. IBM's RS/6000 and POWER
chip had paging. I believe that the Intel and Motorola RISC chips also
supported paging.
rs/6000 was rios ... precursor to rios was romp that showed up in
pc/rt (although it was originally going to be used for displaywriter
follow-on); misc. 801, romp, rios, etc refs:
http://www.garlic.com/~lynn/subtopic.html#801
great microprocessors of the past and present:
http://www3.sk.sympatico.ca/jbayko/cpu.html
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Holee shit! 30 years ago!
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit! 30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 15 Jan 2004 01:26:14 GMT
glen herrmannsfeldt writes:
MVT had ROLLIN/ROLLOUT. As there was no DAT, once a program was
loaded it was fixed in memory. If a program needed to expand,
it was possible for MVT to ROLLOUT whatever was in the needed
addresses, and later ROLLIN again.
nasa huntsville and brown(?) did modified MVT (os/360 release 13) with
DAT support on 360/67 (over 35 years ago). it didn't do paging
thougth; it used the DAT to address severe memory fragmentation
problem with long running 2250 interactive jobs.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Holee shit! 30 years ago!
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit! 30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 15 Jan 2004 01:38:31 GMT
Peter Flass writes:
There are three possibilities here.
1) Large virtual address space mapped to possibly smaller physical
memory. This is the current standard, e.g. IA32 in 32-bit mode,
IBM z/Architecture, etc.
2. Address space = physical memory. Example - IBM OS/360 where
multiple "jobs" shared a common "address space", although it
wasn't called that. This is the usual case on a system without
relocation hardware, but with memory protection.
3. Address space smaller than physical memory. This is the usual
case on systems with relocation hardware but no paging.
the 360/67 had both 24bit and 32bit virtual addressing options.
move to 370 ... resulted in only 24bits virtual and logical being
supported (31bit virtual addressing didn't re-appear to ten years
later with 3081/XA).
the 3033 had something of a blip tho. virtual and logical was still
24bits ... but large systems were becoming real storage constrained.
3033 had a hack where they were able to take two unused bits in the
page table entry and "address" 14bits worth of 4k real pages. The
standard 370 architecture had 16bit page table entry, 12bits for page
numbers (12bit page numbers times 4k/12bit pages ... 24bits real
addressing), 2 additional defined bits, and 2 undefined bits.
the hack with the 2 undefined page table bits allowed for addressing
14bits worth of 4k real pages (64mbytes). fortunately, I/O
architecture CCWs already had IDALs which allowed for more than 24bit
real address for I/O.
instructions couldn't generate more than 24bit addresses, but IDALs
allowed for specifying greater than 24bit real storage addresses for
doing I/O .... and the PTE entry stuff allowed for translating 24bit
virtual address into a 26bit real storage address.
misc. past discussions of IDAL
http://www.garlic.com/~lynn/2000g.html#28 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002d.html#52 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002d.html#56 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002d.html#57 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002e.html#21 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?
http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
virtual-machine theory
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual-machine theory
Newsgroups: alt.folklore.computers
Date: Thu, 15 Jan 2004 01:51:03 GMT
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
This is extremely perverted. Some people actually have fun
when they go to work. PHBs do not approve.
So, was the "guest" MVS? IIRC, MVS could gaze at its navel
and determine if it was running under VM or was in charge of
the machine.
wasn't mvs .... this was joint project between cambridge and endicott
... and was running "production" a year before the first engineering
370 hardware was running with virtual memory support.
when they finally got the first 370 engineering machine in endicott
(this was a full year after all the software stuff mentioned
previously had been done and completed) with virtual memory (this
machine had a knife switch for an ipl/boot button) ... they used the
modified cp/67 (to run on real 370) for a test.
It almost immediately failed. It turned out the engineers had
incorrectly reversed the implementation of two of the B2 opcodes. the
cp/67 kernel was quickly patched to correspond to the incorrect
hardware implementation and from then on it ran fine.
mvs for a while was vs2/mvs .... which was a follow-on to vs2/svs (aka
SVS -> single virtual storage; MVS -> multiple virtual storage).
basically vs2/svs was somewhat modified MVT that thot it was running
in 16mbyte real address space ... and there was underlying kernel
stuff to do the paging and virtual memory management. the initial
prototype work involved hacking a MVT kernel with the paging stuff
running on a 360/67 (before 370 machines with virtual memory was
available) ... along with a borrowed copy of CP/67 CCWTRANS module
hacked into the MVT kernel. CCWTRANS handled the copying of virtual
CCW chains, translating virtual to real address for real I/O, and
making sure that the related virtual pages were fixed in real storage
for the duration of the i/o operation.
misc. past aos, svs, etc history
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
virtual-machine theory
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual-machine theory
Newsgroups: alt.folklore.computers
Date: Thu, 15 Jan 2004 01:53:03 GMT
Brian Inglis writes:
Nah, MVS always assumed it was the master of any machine it ran on.
DOS/VSE and OS/VS1 later versions disabled paging if they were running
under a virtual machine (machine serial number model byte x'FF' IIRC).
and VS1 also had handshaking support ... which allowed a psuedo page
fault interrupt to be reflected to VS1 when the virtual machine
hypervisor took a page fault in the VS1 address space. This allowed
VS1 to do task switching and overlap execution while VM was handling
the lower level page fault & page-in operation.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
BASIC Language History?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: BASIC Language History?
Newsgroups: alt.folklore.computers
Date: Sat, 17 Jan 2004 16:04:35 GMT
Andrew McLaren <amclar@optusnet.n0$pam.com.au> writes:
The reference Sammet cites ("[KM66]")is the BASIC manual by Kemeny
and Kurtz[2]. So it's probably correct :)
I suspect the Sippls just made a small error in expanding the
acronym; corrected in a later edition.
BTW the most recent IEEE Annals in the History of Computing had as
its theme Women and Computing; and included a reminiscence by Jean
Sammet about the early days when she was working with Dr Grace
Hopper. Fascinating stuff!
sammet was in the boston programming center on 3rd floor 545 tech sq
... when it was absorbed by the science center & the vm/370 group.
boston programming center had done cps (conversational programming
system) which included an interactive/conversational pli.
most of the BPC staff were absorbed into the vm/370 group and moved
out to burlington mall (old sbc bldg ... before sbc was transferred to
cdc) when the vm/370 group outgrew space in tech sq. a few stayed with
the science center in tech. sq.
random past 545 tech sq posts
http://www.garlic.com/~lynn/subtopic.html#545tech
some past posts mentioning sammet
http://www.garlic.com/~lynn/2000d.html#37 S/360 development burnout?
http://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002j.html#17 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002o.html#76 (old) list of (old) books
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2003c.html#0 Wanted: Weird Programming Language
http://www.garlic.com/~lynn/2003c.html#1 Wanted: Weird Programming Language
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
40th anniversary of IBM System/360 on 7 Apr 2004
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 17 Jan 2004 16:41:35 GMT
WmHBlair@ibm-main.houston.rr.com (William H. Blair) writes:
Actually, they were slower. A 370/195 was about 3.7 MIPS, whereas
a 360/91 or 360/95 were neck and neck at 5.0 MIPS. The 95's faster
thin-film memory turned out to have no significant effect on the
actual processor thruput, a fact noticed by IBM, which contributed
to the decision to go back to even slower core memory in the next
big machine, the 370/165. The 370/195 was just a 360/91 with the
System/370 instruction set (well, most of it, but not all of it);
it was the only "/370" that was not completely a 370. It used the
slower core memory, as well, mainly because, at $2,000,000 per MB,
the fast stuff was just so damn expensive that nobody, even NASA,
could afford it. 360/65 and 360/75 core storage was still eye-
openingly expensive ($1,000,000 per MB), but few machines existed
that had even 512KB. At one point, I worked on a 360/75 that had
1MB (4 2365 boxes) of the fast core storage (four way interleaved
to achieve an effective cycle time of less than 200 ns) and 2MB
of slow core storage (LCS or Large Capacity Storage), for a total
of 3MB. At that time, IBM told us that there were only seven such
boxes in the world (with that much memory), and none of them were
even in the hands of IBM. NASA Houston had five for the Apollo
moon program, TUCC had one, and I think UCLA had the other (at
that time).
SJR (bldg. 28) had 370/195 ... and for highly optimized codes that fit
in the pipeline it could peak around 10mips. some amount of the air
bearing 3380 (floating head) head simulation was being done on that
machine .... but with large batch queue there were sometime really
extended turn-arounds.
palo alto science center had job that was experiencing 3 month turn
arounds (on the sjr 370/195) .... and tried setting it up to run in
the background on their 370/145 ... they could get complete run in
something like two months instead of the three months it took waiting
on the 195. the 370/145 was used for cms interactive work ... but that
machine was also where the apl microcode work was done (as well as
some amount of other microcode stuff). misc mcode refs:
http://www.garlic.com/~lynn/subtopic.html#360mcode
and some number of hone &/or apl refs:
http://www.garlic.com/~lynn/subtopic.html#hone
in the late '70s the consolidated US hone center had moved to bldg
across the back parking lot from the palo alto science center.
with regard to the air bearing simulation work, we were doing also
doing this work to get operating system running on the machines in the
disk enginneering (bldg 14) and disk product test (bldg 15, across the
street from bldg. 28). at the time, MVS had something like MTBF of 15
minutes when run on a machine with a single testcell in operation (so
their standard mode was to schedule stand alone test time for each of
the dozen or so testcells). we finally got the rewrite of IOS done so
the operating system was rock solid even with multiple testcells
operating concurrently.
now the engineering & product test labs tended to get early
enginneering processors to validate disk operation (i.e. early 370s,
303x, etc). bldg. 15 got one of the earliest internal 3033s. now one
of the characteristics of the testcell operation was that in
stand-alone operation it was using much less than one percent of the
processor. when we got operating system up and running ... even with
half dozen testcells running concurrently, there was only a couple
percent cpu utilization. as a result, all of a sudden we had large
amounts of cpu sort of unaccounted for and available. so one of the
things we thot would be a good idea was to move all the air bearing
simulation work off the terribly overloaded 195 (in bldg. 28) to the
(effectively) totally idle 3033 (in bldg. 15). misc. disk engineering
refs:
http://www.garlic.com/~lynn/subtopic.html#disk
in the early to mid 70s ... there was a project looking at doing a two
processor 370/195 ... actually it was much more akin to the dual
i-stream hyperthreading stuff currently going on in microprocessors;
keep the same pipeline and execution elements ... but have two sets of
registers, PSWs, etc. ... and one bit instruction tag for everything
in the pipeline ... to identify which instruction stream it belonged
to. the issue was there was no speculative execution past a branch
instruction (on the 195) ... so branches tended to drain the pipeline
(unless they were loop within the pipeline).
random past 195 posts:
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/94.html#39 IBM 370/195
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#24 old manuals
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
http://www.garlic.com/~lynn/99.html#209 Core (word usage) was anti-equipment etc
http://www.garlic.com/~lynn/2000c.html#38 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#21 Competitors to SABRE? Big Iron
http://www.garlic.com/~lynn/2000f.html#13 Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?
http://www.garlic.com/~lynn/2000f.html#21 OT?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#18 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001c.html#1 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#27 Massive windows waisting time (was Re: StarOffice for free)
http://www.garlic.com/~lynn/2001h.html#49 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001n.html#38 Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#41 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2001n.html#86 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002.html#50 Microcode?
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2002h.html#19 PowerPC Mainframe?
http://www.garlic.com/~lynn/2002h.html#23 System/360 shortcuts
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002j.html#43 Killer Hard Drives - Shrapnel?
http://www.garlic.com/~lynn/2002k.html#16 s/w was: How will current AI/robot stories play when AIs are
http://www.garlic.com/~lynn/2002m.html#35 simple architecture machine instruction set
http://www.garlic.com/~lynn/2002m.html#57 The next big things that weren't
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2002o.html#44 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#37 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
http://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003h.html#47 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003j.html#41 Of what use 64-bit "General Purpose" registers?
http://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
http://www.garlic.com/~lynn/2003l.html#31 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
40th anniversary of IBM System/360 on 7 Apr 2004
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 18 Jan 2004 05:14:53 GMT
a quicky use of search engine on 370/195 ... some minor references
references sample program that ran 120 seconds on 360/91 and 20
seconds on 370/195 (and seconds on 1108)
http://www.nea.fr/abs/html/ccc-0179.html
lots of IBM, 360, 370 as well as non-ibm dates, 1964-1974
http://perso.club-internet.fr/febcm/english/information_technology/information_technology_3.htm
list of manuals at charles babbage insitute ... it would be
interesting if any ever get scanned and put online
http://www.cbi.umn.edu/collections/inv/cbi00060.html
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Holee shit! 30 years ago!
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit! 30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Tue, 20 Jan 2004 00:19:05 GMT
"John W. Kennedy" writes:
There's at least one SQL server that does the same with its databases.
An advantage to this is that code can avail itself of knowledge about
the disk geometry.
some number of RDBMS had both raw device as well as filesystem
options. the issue on unixes wasn't just the disk geometry ... but
the whole general issue of things like concurrent & asynchronous i/o
(before any such features were generally available on unix platforms).
in some scenarios ... unix was used to load the (rdbms) application
... and then it took over the machine and did most of its own
management. later posix asynchronous i/o and lightweight threads were
supposedly available for being able to accomplish similar results, but
using standard system facilities.
this (raw device support) carried over into being able to do
concurrent shared disk access for rdbms with ha/cmp .... i.e. unix
platforms not having filesystems that supported "loosely-coupled" (aka
mainframe for different machines having concurrent/common access to
the same set of shared disks).
minor reference
http://www.garlic.com/~lynn/95.html#13
more ha/cmp stuff:
http://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
40th anniversary of IBM System/360 on 7 Apr 2004
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 20 Jan 2004 00:36:52 GMT
b19141@ibm-main.achilles.ctd.anl.gov (Barry Finkel) writes:
IIRC, Delta (Atlanta) and United (Denver) also had 195's (I am not
sure if they were upgraded to 370 from 360). I do not know how many
each had. I was told that there were only 24 195's built. Argonne
had serial number 17.
the lore is that one of the nails in FS coffin was analysis by the
houston science center ... that if ACP was ported from 370/195 to
high-end FS machine (built from same 370/195 level
technology/performance) it would have the thru-put of 370/145 (aka the
FS machine architecture would introduce 10-30 to one performance
degradation).
a couple recent posts mentioning FS:
http://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
http://www.garlic.com/~lynn/2003p.html#30 Not A Survey Question
and a whole FS collection:
http://www.garlic.com/~lynn/subtopic.html#futuresys
and then some number of the FS crowd went off to rochester and
implemented FS as the S/38 ... which later morphed into the as/400.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
40th anniversary of IBM System/360 on 7 Apr 2004
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 20 Jan 2004 19:03:23 GMT
broidoj@ibm-main.gti.net (Jeffrey R. Broido) writes:
Yes. The external (to the CPU) memory bus, among other
things, was enclosed in a black, partially ribbed structure across
the back of the system out of the front of which sprouted the CPU
(or DAT box and CPU for the model 67) and out of the rear of which
sprouted one to four quarter-meg core boxes, each of which contained
four small 64Kb three-dimensional core arrays, potted and heated to
90 degrees F. My only quibbles are that the memory boxes supplied
with the models 65 and 67 were 2365s, not 2361s, and the nominal
memory access speed as quoted by IBM (and measured crudely by us)
was .7 microseconds, not 1.0 microseconds.
At Rutgers, we referred to the structure containing the
memory bus (and main power supply) as "The Subway Car". We
discovered that one or two people could actually hide in there as
long as the left side (as viewed from the front), which contained
enough enormous electrolytic capacitors to add-up to over one farad
(which is an large capacity, indeed), was avoided.
note that the 65, multiprocessor 65, and the 67 were pretty
common ... with single ported memory and bus contention
between processor and I/O.
running in virtual memory mode ... the dat box added 150 microseconds
to the cycle ... making it .9 microseconds (instead of .750
microseconds) to allow the dat box to do its thing.
the multiprocessor 67 was something of a different beast entirely. it
had a channel director and tri-ported memory. this introduced
soemthing like .1 (mumble ) additional cycle overhead. a half-duplex
67 on processor intensive workload with little or no I/O was slower
than a simple 67 (half-duplex 67 running in 65-mode possibly with
os/mvt was slower on cpu intensive workload than simplex 67 or 65).
however, on heavy cpu intensive workload with heavy i/o (say cp/67
with one hundred percent cpu utilization, heavy interactive, and heavy
paging) ... a half-duplex 67 (single processor) outperformed a simplex
67 because of the reduction in bus contention between the cpu and I/O
the 67 channel controller also provide the capability for all
processors to access all channels. the 360/65 (and later 370) duplex
strategy was that processors continued to have dedicated channels and
integrated i/o configurations came by configuring all controllers with
twin-tail channel connectors (one to each processor). The channel
controller had panel configuration switches that controlled whether
operating as duplex or partitioned as two half-duplexes, how the
memory banks were routed and the channels connected. These
configuration switches were "sensed" thru defined bits in the control
registers ... and in at least one model ... it was possible to change
the switch settings by changing the bits in the control registes.
the work on cp/67 multiprocessor support at the cambridge science
center resulted in the compare and swap instruction (original mnemonic
the initials of the person in cambridge that invented it) ... misc.
cambridge posts:
http://www.garlic.com/~lynn/subtopic.html#545tech
misc. multiprocessor posts:
http://www.garlic.com/~lynn/subtopic.html#smp
I had heavily optimized the cp/67 page i/o pathlength and completely
redesigned and rewrote the scheduling controls, page replacement
algorithm, etc .... so it was possibly to have concurrent one hundred
percent cpu intensive workload while at the same time running
interactive instensive and heavy paging. my page thrashing control
inventions were different from the working set stuff that had been
published in the literature about the same time. some 15 years later,
there was significant resistance to a stanford Phd thesis (wsclock)
that proposed something similar to what I had done on cp/67. Helping
to overcome the resistance was that the grenoble science center had
published an ACM paper on modifying cp/67 for a traditional
working-set dispatcher with some published numbers. With essentially
the same hardware, grenoble had approximately the same thuput and
interactive response with 35-40 users on 1mbyte 360/67 (154 pageable
pages after fixed storage requirements) that I had with 70-80 users on
768k 360/67 (104 pageable pages). lots of past stuff on scheduling
and paging:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
misc. past channel controller posts:
http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#26 System/360 Model 30
http://www.garlic.com/~lynn/97.html#19 Why Mainframes?
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2000.html#88 ASP (was: mainframe operating systems)
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000e.html#2 Ridiculous
http://www.garlic.com/~lynn/2000e.html#4 Ridiculous
http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#66 what is interrupt mask register?
http://www.garlic.com/~lynn/2001.html#69 what is interrupt mask register?
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002j.html#22 Computer Terminal Design Over the Years
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
http://www.garlic.com/~lynn/2003c.html#72 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2004.html#7 Dyadic
misc. past threads on the global versis local replacement stuff:
http://www.garlic.com/~lynn/94.html#01 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#1 Multitasking question
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/94.html#4 Schedulers
http://www.garlic.com/~lynn/96.html#0a Cache
http://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
http://www.garlic.com/~lynn/2003j.html#3 A few Z990 Gee-Wiz stats
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
40th anniversary of IBM System/360 on 7 Apr 2004
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 20 Jan 2004 19:10:08 GMT
tjpo@ibm-main.AIRBORNE.COM (Patrick O'Keefe) writes:
In the late 60's I was an operator at the IBM Datacenter in downtown
Seattle. 2 stories of glass curtain windows showing off a range of
IBM machines - up through S/360 Mod 50. The eventual "security"
feature added was a mostly transparent cloth curtain that was closed
at night.
now somebody has offices in that space and big sign (... all i can
remember is that name starts with J?). i remember getting some 3rd
shift testing in that datacenter in the late '60s (i was undergraduate
at the time) ... and during the day killing some time wandering around
some of the ibm offices upstairs. i remember sitting in on an mvt
debugging class ... and after about 30 minutes starting to correct the
instructor ... who then asked me to leave.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
dual processors: not just for breakfast anymore?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dual processors: not just for breakfast anymore?
Newsgroups: comp.arch
Date: Tue, 20 Jan 2004 18:30:03 GMT
Christian Bau writes:
Hyperthreading doesn't give you any more resources, it only tries to
help you using a bigger percentage of available resources. So it won't
help if you are bandwidth limited, it also won't help if your code is
written so well that it reaches limits of instructions per cycle,
floating point instructions per cycle etc.
Hyperthreading should work quite well if you have long chains of
dependent floating point operations: Huge latency, so your code eats
only a small percentage of the available resources, and hyperthreading
might double that. Of course, that is the kind of code you would want to
avoid in the first place.
the hack for the 370/195 (30 some years ago) was because it didn't
have speculative execution and branches would drain the (64
instruction) pipeline (unless it was loop within the pipeline). the
majority of codes ran the 195 at less that half its peak thruput
... because of the branch stalls.
the dual processor had duplicate set of registers and dual i-streams
... and work in the pipeline got a red/black flag to indicate which
i-stream the work was in, the idea was that stalls in one i-stream
might be overlapped with work from the other i-stream. one might
claim that the tera ... oops cray ... carries the stall/latency
compensation to extream ... previous thread reference
http://www.garlic.com/~lynn/2003p.html#5 Hyperthreading vs. SMP
... aka up to 128 hardware threads
random past 195 dual i-stream posts
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Two subjects: 64-bit OS2/eCs, Innotek Products
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Two subjects: 64-bit OS2/eCs, Innotek Products
Newsgroups: alt.os.development,comp.arch,comp.os.os2.apps,comp.os.os2.misc,comp.os.os2.programmer.misc
Date: Tue, 20 Jan 2004 18:20:23 GMT
Tim Olson writes:
The PowerPC processors were jointly designed and manufactured by
both Motorola and IBM (well, 601 was IBM-only), and Apple used both
suppliers for various PowerMac designs. Another group at IBM was
continuing the design of the POWER series.
RIOS was power series (I have a clear grean plastic paper weight here
with six chips and says 150 million ops, 60 million flops and 7
million transistors). power/pc was done at somerset, joint project
between ibm and motorola ... the executive we reported to when we were
doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
went over to head up somerset (he had previously been at motorola
before coming to work on rios). he then went on to become president of
mips and then later returned to austin.
one big point about RIOS was that it didn't have any provisions for
cache consistency. the only SMP that had been done with RIOS chips was
4-way using RIOS.9 .... which had a hack that you could flag segment
as being cacheable or non-cacheable (aka if you needed consistent
memory ... it was consolidated in a segment flagged as
non-cacheable). one big point about power/pc was to be able to support
cache-consistency (there are references to power/pc being power with
88k bus ... but you need more than the 88k bus to have cache
consistency).
RISC formalised: IBM 801
http://www3.sk.sympatico.ca/jbayko/cpuAppendA.html#801
IBMS RS/6000 POWER
http://www3.sk.sympatico.ca/jbayko/cpu5.html
27 yars of ibm risc
http://www.rootvg.net/column_risc.htm
note in the above ... refers to RSC as RISC Single Chip ... but,
in fact, it was called RIOS Single Chip.
misc. past 801, romp, rios, power/pc postings
http://www.garlic.com/~lynn/subtopic.html#801
misc. somerset specific postings:
http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2001g.html#23 IA64 Rocks My World
http://www.garlic.com/~lynn/2001i.html#28 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001j.html#37 Proper ISA lifespan?
http://www.garlic.com/~lynn/2002g.html#12 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#14 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002l.html#37 Computer Architectures
http://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
http://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
passwords
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: passwords
Newsgroups: alt.computer.security
Date: Tue, 20 Jan 2004 20:19:22 GMT
Colonel Flagg writes:
3-6 months ago, either in here or on slashdot, someone posted the URL to
an article written about password strengths and statistics attempting to
show that passwords above a certain number of characters was no more
"secure" than a password of lesser characters.... anyone remember the
URL or have it bookmarked?
the number of characters in theory are analogous to the number of bits
in crypto key ... and therefor can be viewed from the stand-point of
how long will a brute-force attack take. however, if the
infrastructure supports limit on consecutive bad passwords or other
defensive methods ... then brute-force attacks can be thwarted (and it
is no longer necessary to have ever increasing key sizes to make
repetitive trying of all possible values impractical).
there is a second order problem .... the whole issue of
- frequently changing shared-secrets
- shared-secret paradigm propagated into scores of environments
- requirement that unque shared-secret be used for every
different security domain
overloads typical human memory capability leading to people having to
write the scores of passwords down. long, complex passwords can
aggravate the human memory limitations. many/most of the password
articles seem to address the issue from purely myopic position that an
individual never will be in position of dealing with more than a
single security domain (and never having to remember more than a
single password that may never change).
what in fact happens, the threat model can be against the aid used for
remembering scores of passwords ... not the actual password themselves
(trojan horses looking to harvest password files).
an alternative is to go to a two-factor authentication based on
non-shared-secret (something you have and something you know)
.... aka
1) a hardware token that does a digital signature and can be validated
by a public key (that has been registered in lieu of a shared-secret
password). having access to list of registered public keys in one
security domain wouldn't compromise the use of the same public keys in
a different security domain ... aka a shared-secret can be used to
both originate as well as validate an authentication ... while a
public key can't be used to originate an authentication ... but can
only be used to validate an authentication
2) a PIN that controls the operation of the hardware token. both
shared-secret and hardware token PIN represent something you know
authentication. However, if a shared-secret something you know, is
divulged, it possibly enables others to fraudulently use the
shared-secret to impersonate (the security requirement for unique
shared-secret for every security domain). A hardware token PIN is also
a form of something you know ... but since it never has to be
divulged, it can drastically simplify the human memory issues. Instead
of having scores of shared-secrets ... the person has a single
hardware token, controlled by a single PIN ... that is never divulged
and is not a shared-secret.
It is in the non-shared-secret, hardware token PIN paradigm ... that
you can start talking about a threat model being against the PIN
itself, the length of the PIN, etc ... since the human memory issues
with large numbers of security domains and scores of shared-secrets
are significantly mitigated.
Note, a trojan horse that harvests a person's password file ... can
lead to being able to impersonate that person in large number of
different situations. Any sort of virus or trojan horse that harvests
a hardware token PIN still isn't able impersonate w/o also having
access to the hardware token. From a fraud return-on-investment
... the costs for harvesting a hardware token PIN and gaining access
to the hardware token itself is significantly higher than the cost of
harvesting password files (or in the electronic commerce scenario, the
merchant master transaction file). Such hardware token related
acquisition costs might even be larger than any expected fraud return
... making it more attractive for the criminals to go elsewhere.
and even more topic drift about security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61
lots of past stuff about non-shared-secrets
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aadsm12.htm#60 signing & authentication (was Credit Card Scam)
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#37 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#58 I-net banking security
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002h.html#40 [survey] Possestional Security
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
http://www.garlic.com/~lynn/2003e.html#57 Security in RADIUS (RFC2865)
http://www.garlic.com/~lynn/2003h.html#55 PKINIT
http://www.garlic.com/~lynn/2003i.html#2 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003j.html#25 Idea for secure login
http://www.garlic.com/~lynn/2003m.html#49 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003o.html#9 Bank security question (newbie question)
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
http://www.garlic.com/~lynn/2003o.html#44 Biometrics
http://www.garlic.com/~lynn/2003o.html#50 Pub/priv key security
http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Threat of running a web server?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Threat of running a web server?
Newsgroups: alt.comp.anti-virus,comp.security.firewalls,alt.computer.security
Date: Tue, 20 Jan 2004 20:25:56 GMT
"David Norris" writes:
majority of intrusions via webservers occur via scripts (CGI and so
on). If you are careful about use of scripts, your risk is much
lessened. DN
i had heard some number about fraud ... that about
- 1/3rd from buffer overflows and other implementation flaws,
- 1/3rd from viruses and trojan horses involving scripts/executables
arriving from the net and being executed, and
- 1/3rd from social engineering
some of the network originating scripts/executables also involve
social engineering as to the inducement it takes to have a person
click on the executable (as opposed to exploiting a flaw where the
secript/executable is automatically executed).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Two subjects: 64-bit OS2/eCs, Innotek Products
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Two subjects: 64-bit OS2/eCs, Innotek Products
Newsgroups: alt.os.development,comp.arch,comp.os.os2.programmer.misc
Date: Wed, 21 Jan 2004 05:31:58 GMT
Peter Flass writes:
I believe the 604 uses a segment table in memory vs. segment
registers in earlier versions. It's able to directly address *lots*
more memory.
ROMP had 16 segment registers with 256mbyte segments ... with 32 bit
addresses ... that was 4bits to index the segment register and 28bits
to address address within the segment. it used inverted tables ...
and "tagged" segment identifiers in TLB. ROMP used 12bit segment
identifiers in the TLB (i.e. the segment registers didn't contain a
pointer to virtual memory tables ... just a 12bit segment identifier).
lots of virtual memory infrastructures use tables in memory and the
TLB use some part of the table pointer to distinquish addresses in
different virtual memories. 370 (mainframe) had STO-associative TLB
.... i.e. the segment table origin address was used to tag entries in
the TLB.
The 801/ROMP flavor effectively had segment-associative tagging, using
an explicit id number. One of the side-effects is that virtual
addresses in the same "shared segment" could share the same TLB
entries .... while something like STO-associative TLB entries might
have different entries (even for identical shared code).
RIOS continued with the 801/ROMP 16segment registers and 32 bit
addressing ... but extended the size of the tag field to 24bits. The
size of the tag field ... plus the 28bit virtual address ... gave rise
to the claim that 801/ROMP was 40 bit addressing (i.e. 28bit segment
address plus 12bit segment-id tag) and 801/RIOS claim of 52bit
addressing (i.e. 28bit segment address plut 24bit segment-id tag).
Note that the limited number of distinct segments was originally
designed for a closed operating system and execution environment.
THere was justification for the limited number of distinct segments as
hardware/software trade-off ... where the application environment
would have all its privileges/integrity check before execution and
inline application code would be able to change segment registers as
easily as general purpose registers (for addressing purposes). There
was no separate security domain, authorization checking, and/or
kernel calls required.
In retargeting ROMP to unix environment .... security domain
and authorization checking (with kernel calls) had to be implemented
for changing memory mapping. Compared to some other unix environments
that might have dozens of unique shared memory objects/segments
simultaneously defined in the same virtual address space ... the 16
total segments was a limitation. This led to packaging multiple
different executable objects into shared library which could be mapped
into a single (shared) segment.
misc. past posts discussing original rios has having 52-bit addressing.
http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2001c.html#84 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
http://www.garlic.com/~lynn/2002l.html#60 Handling variable page sizes?
http://www.garlic.com/~lynn/2002m.html#33 simple architecture machine instruction set
http://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
BASIC Language History?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: BASIC Language History?
Newsgroups: alt.folklore.computers
Date: Wed, 21 Jan 2004 16:14:44 GMT
et472@FreeNet.Carleton.CA (Michael Black) writes:
That's got to be wrong. I thought the whole point of BASIC was
that it was an interpreter, so it was good for beginners. It
ran on the Dartmouth timesharing system originally. You could
type something in, and immediately see a response. You didn't
have to worry about that technical stuff, like compiling, so
it made inroads in non-computer science circles.
And certainly Microsoft did not have the the first interpreter,
even if BASIC had originally been a compiler.
David Ahl's computer games book predates the home computer,
and his work at DEC was precisely based on BASIC being available.
As I already mentioned, Bob Albrecht was using BASIC to
introduce computers to people, and that was in the early seventies.
Creative Computing was mostly about BASIC, and it predates 1975.
BASIC was something sought early on with home computers because
many were familiar with it, and so we saw those tiny BASICs
being written early on. What would be Microsoft wrote a BASIC
for the Altair because it was familiar.
CPS was conversational programming system done by the boston
programming system. They also had ROS RPQ for the 360/50 for new
instructions that improved the performance of CPS operation. It
supported conversational/interactive PLI and BASIC.
The Boston Programming Center was on the 3rd floor of 545