From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Clustering ( was Re: Interconnect speeds ) Newsgroups: comp.arch,comp.sys.sgi.hardware,comp.sys.intel Date: Thu, 02 Jan 2003 17:16:04 GMTAlexis Cousein writes:
LANL was driving factor behind HiPPI .... wanting a industry standard (commodity priced?) for cray channel
LLNL was driving factor behined FCS ... wanting a fiber standards version of a copper serial non-blocking switch that they had installed.
SLAC was driving factor behind SCI ... comments recently posted (sequent, data general, and convex built SCI-based computers)
random ref:
https://www.garlic.com/~lynn/95.html#13
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: cost of crossing kernel/user boundary Newsgroups: comp.arch Date: Thu, 02 Jan 2003 17:22:48 GMTEmil Naepflein writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Thu, 02 Jan 2003 20:03:17 GMTMorten Reistad writes:
Timeline, from Google, Wiki, SGI, sympatico.ca etc. : ?? 1981 : IBM starts ROMP ?? 1981 : Stanford starts MIPS project ?? 1984 : First MIPS processor implementation April 1986 : First Fujitsu SPARC chips, 10 mips June 1986 : Mips 2000 introduced. October 1986 : PA-Risc introduced. March 1987 : 4D/60 R2000 based system, 7 mips, 0.7 mflops July 1987 : Sun announces SPARC spec officially ?? 1987 : ARM, Archimedes home computer, 4 mips ?? 1987 : AMD29000, mid 1988 : Motorola 88000 October 1988 : PowerSeries R2000 based systems from SGI, 20+++ MIPS, 2+++ mflop ?? 1988 : Mips R3000, 40++ mips ?? 1989 : Sparcstation 1, 12.5 mips For comparison, 6-8 mips was a pretty high end minicomputer in 1985.CP.r (control program for 801 processor) & PL.8 (programming language for 801 processor) was presented at an internal advanced technology meeting held in pok spring of '77 (may have been spring '76, i can't find the reference at the moment).
This was followed by Fort Knox ... which was a large project to replace all the low-end & mid-range microprocessors with 801s (i.e. the low & mid range 370 microprocessos, the rochester system/3 stuff, etc) ... and other control processors, like the things what the uc.5 & jib-prime were used for). While fort knox was killed some of the work still showed up as internal control processors in other products.
Fort Knox was eventually killed ... but office products division and research started up ROMP as the basis for displaywriter follow-on (using both CP.r and PL.8 as the basis). When the displaywriter follow-on was killed, the group tried to quickly adapt ROMP to the unix workstation market (contracting with the same company that had done the PC/IX port for the PC).
misc 801, romp, fort knox postings:
https://www.garlic.com/~lynn/subtopic.html#801
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Thu, 02 Jan 2003 20:23:45 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Thu, 02 Jan 2003 21:10:11 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Fri, 03 Jan 2003 04:39:47 GMTBrian Inglis writes:
3084 was a four way ... where each cache had to listen for cache line signals from three other processors (rather than just one). Later machines started running portions of cache hardware at significantly faster cycle times than the rest of the processor infrastructure .... just to keep up with the cache line invalidate signals.
the five-way project wasn't a cache machine (so didn't suffer the
cache consistency overhead issues) ... it was a 370/125. The 370/125
was physical a 9-way SMP machine .... nine positions on the memory bus
with some or all of the positions occupired by microprocessors. The
basic difference between the micrprocessors was what kind of microcode
was loaded .... aka traditional 370/125 had one of the microprocessors
loaded with 370 instruction set emulation ... and the other
microprocessors were loaded with various kinds of controller and I/O
functions. The five-way ... had up to five of the microprocessors
loaded with 370 instruction set emulation. There was also going to be
a superset of VM microcode assist that was done for virgel/tully
(ECPS) ... along with effectively task queue and task switch in
microcode (somewhat move akin to some of the 432 stuff than the XA SIE
instruction) and much of the page subsystem offloaded to the disk
controller microprocessor. misc m'code discussions:
https://www.garlic.com/~lynn/submain.html#360mcode
Effectively the remaining portions of VM kernel (not moved to microcode) had the old-style 360/65 OS kernel lock ... however it was unique in rather than a spin-lock ... it was a queued or bounce lock, aka if a processor microcode couldn't obtain the kernel lock .... it queued a lightweight kernel processing request against the kernel lock and went off to the microcode schedule/dispatcher to find some other work. The objective was that the virtual/kernel processing ratio was on the order of 9:1 or better (aided by various portions of the VM kernel dropped into the parallelized microcode). As long as it stayed better than 4:1 ... the workload wouldn't bottleneck on the kernel lock (and it was a very low-overhead lock since there was no spinning).
This was also the design model I used for the SMP support in the
VM/370 product release. Basically all of what was in the VAMPS
parallelized microcode had the necessary fine-grain locking support.
There was then a single "kernel" lock for main body of low usage
kernel code. If processing required the "kernel" lock ... and couldn't
obtain it ... it would queue a lightweight request off the kernel lock
and go to the parallelized dispatcher/scheduler to find some other
work not requiring the kernel lock. I claimed that this was the
maximum parallelized SMP thruput for the fewest number of code
changes. misc. smp threads/posts
https://www.garlic.com/~lynn/subtopic.html#smp
As i mentioned I was doing the resource manager at the same time ... aka
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
The resource manager had the distinction of being the first "priced"
operating system code .... and i got the opportunity to work with the
business people on the business rules for such pricing. However, there
was a lot of code that I put into the resource manager that wasn't
strictly algorithm control .... there was a lot of code that was
integrity oriented (failure resistant) and also oriented towards
structures supporting parallelized SMP operation. However, it went
out before the standard VM/370 support shipped with SMP support.
Some discussion of the integrity & benchmarking posts:
https://www.garlic.com/~lynn/submain.html#bench
When it came time to ship VM/370 release with SMP support ... it was decided that it would be a "free" release ... but containing something like 80 percent of the lines of code from the resource manager. The resource manager product for the first SMP VM/370 release continued to be charged the same as it had in the pre-SMP release version ... but it had only about 1/5th the lines of code (the rest of the code being absorbed by the still free operating system release).
16-way smp had a much weaker cache consistency memory model (than
traditional mainframes) .... allowing much less inter-cache
overheads. this required some additional operating system changes for
things like more pervasive use of compare&swap in certain
situations. it ran into other issues ... as mentioned in (executives
hammered some engineers for working with us when it was realized that
there was no chance of MVS supporting the machine):
https://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
Some of the degradation in scalable processors was how strong the memory model was maintained by cache hardware & associated protocols. Other issues affecting thruput was somewhat independent of the cache consistency protocols. One of the things that a lot of attention in the 3084 (4-way) time-frame was kernel storage allocation structures ... starting to align them on cache line boundaries and making them multiples of cache line sizes. The issue was that if two different data structures occupied the same cache line ... and were potentially in use by two different processes on two different processors at the same time ... there could be extremely extensive cache line trashing.
The other issues that operating system paradigm dependent .... is the locking granularity .... whether or not spin-lock paradigm was used .... or some other paradigm was used. The compare&swap instruction was the doings of charlie at cambridge scientific center ... original working on fine-grain locking for CP/67. The instruction was first invented and the mnemonic chosen to match charlie's initials (it is one of the few widely used instructions that are actually somebody's initials).
Another issue is what sort of paradigm does the kernel use to serialize/synchronize various operations across different processes. One of the last release of VM (aka for 370) ... before VM/XA significantly redid the structure for the use of the SIGP (signal processing instruction). When that release hit the streets ... the SIGP paradigm change was using ten percent of total elapsed time on both processors just for SIGP and related infrastructure processing (just on the off chance that it might be useful to tell the other processor something).
In this situation ... for two way operation ... there was the hardware loss of ten percent of both processors going to the caches listening for each others invalidate & synchronization signals ... plus this software kernel release introduced an additional ten percent of both processors going to the kernel on each processor waving to itself on the other processor (and then you get to talk about all the other normal single processor as well normal multiprocessor kernel overheads).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Fri, 03 Jan 2003 04:59:27 GMTAnne & Lynn Wheeler writes:
so all disk & file i/o became page I/O operations of one sort or
another ... majority of the processing offloaded to the disk
controller microprocessor. misc. page mapped postings
https://www.garlic.com/~lynn/submain.html#mmap
later when we were doing HA/CMP (High Availability Cluster Multi-Processing
product for the 6000) we also got involved in the
hippi, fcs, and sci standards activity. sci was scalable model used
by (at least) sequent, data general, and convex for scalable
processor configurations; recent reference ...
https://www.garlic.com/~lynn/2003.html#0 Clustering (was interconnect speeds)
misc. HA/CMP refs:
https://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Fri, 03 Jan 2003 16:10:48 GMTjmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
the five-way would have up to five of the microprocessors running the microcode to emulate 370 ... but with heavy modifications; a superset of both SIE instruction and ECPS (for virgil/tully) ... along with changes for parallelization in microcode including the dispatching/scheduling function in the microcode. also the disk controller microcode had most of the page i/o offloaded to it.
so based on above from original post .... if there was going to be that much microcode changes .... how hard would it be to support five-way 370? ... when the underlying hardware was already supporting nine-way.
actually ... almost all of the function for parallelization was in the microcode .... there was a trivial amount in the kernel for the single global queue or bounce lock ... and there serialization with compare&swap for queue management .... things going on/off the dispatch queue ... things going on/off the disk i/o queue, etc.
The design was actually for 16-way .... however the underlying hardware was only 9-way ... and given that some of the microprocessors had to perform i/o control functions .... needed a minimum of four processors doing the various i/o control functions .... leaving only five slots for microprocessors executing 370 code.
as an aside, remember that the original 360/67 was designed for 4-way ... nearly 20 years before the 3084 4-way (in xa mode).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Fri, 03 Jan 2003 16:26:13 GMTjmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
not directly related ... but there is whether all processors have access to all i/o. the tradtional 360/370 had dedicated i/o channels for each processor and the I/O controllers then had multi-path channel connections allowing each controller access to channels for each processor.
The 360/67 had a different architecture that allowed all channels to be address by all processors (in up to 4-way configuration). Such architecture for I/O channel addressing didn't show up again until XA. The limitation of lashing two 3081s together to form a 4-way 3084 was much more a hardware limitatin than a difficult architecture limitation.
Now, since for the 5-way 370/125 ... since we were doing all the microcode changes .... moving almost everything involving multiprocessing support out of the direct 370 architecture (and kernel) into the microcode ... and since the 370/125 didn't have real channels ... just other microprocessors on the same memory bus with the appropriate microcode .... there was also change to the i/o structure. As mentioned in the original post ... the interface between the processor and disks was changed from SIO/channel architecture to shared queues ... where most of the page & disk processing was offloaded into the microprocessor with the disk controller microcode. Rather than being SIO/channel there was queue of requests pending by the disk controller and there was the queue of requests that had finished.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Mainframe System Programmer/Administrator market demand? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 03 Jan 2003 16:54:53 GMTgsmith@NC.RR.COM (Greg Smith) writes:
later with Amdahl/fujitsu and national/hitachi processors (as well as some of the little guys 4pi, etc, i think late 70s & early 80s saw a number of entry/mid-range clones) there were similar questions regarding driving factors in processor architecture enhancements.
one of the big issues when pr/sm origination time-frame (leading to
lpars) was Amdahl's macrocode. the high-end mainframes tended to be
very complex horizontal microcode ... and architecture changes tended
to be quite complex code undertakings. Amdahl's macrocode was a 370
subset for microcode impelemtation .... making it significantly easier
to track (& even enhance) architecture changes (aka Amdahl's original
implementation was much simpler undertaking than ibm's response with
pr/sm).
https://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2002o.html#15 Home mainframes
https://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
https://www.garlic.com/~lynn/2002p.html#40 Linux paging
https://www.garlic.com/~lynn/2002p.html#44 Linux paging
https://www.garlic.com/~lynn/2002p.html#45 Linux paging
https://www.garlic.com/~lynn/2002p.html#46 Linux paging
https://www.garlic.com/~lynn/2002p.html#48 Linux paging
as to the low/mid range ... that market was taken over by high-end PCs
and workstations for everybody starting sometime in the mid-80s
.... not just the IBM 370 low/mid range (but most of the minis).
https://www.garlic.com/~lynn/2002q.html#3 Vector display systems
https://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Mainframe System Programmer/Administrator market demand? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 03 Jan 2003 17:38:07 GMTAnne & Lynn Wheeler writes:
TI had a project that they ordered 800 4341s for a project. STL was converting a conference room on every floor, in every tower to a 4341 room.
the orders for 4341s far outstripped the production (some rumor in part because of some intra-company issues between 4341 & 3031). clones were appearing to fill the gap. it was general market segment so there was also big increase for most minis (not just 370).
however, as all this was happening ... PCs and workstations were starting to appear ... and started to take over the market segment (transition year being about '85 ... which is about also when the nodes on the internet exceeded the nodes on the internal network).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Mainframe System Programmer/Administrator market demand? Newsgroups: bit.listserv.ibm-main Date: Fri, 03 Jan 2003 21:23:55 GMTedgould@AMERITECH.NET (Edward Gould) writes:
one of the oursourcing complexities is creating a larger disconnect between the users/clients of the data processing service and the actual service ... things tend to be much more contractual and formal (and using a boyd'ism ... creates resistance and reduces agility, boyd has some number of commercial examples .... but a military was why does the army want its own close air support rather than relying on the air force).
where there is little need for agility (because of no evolving circumstances and changing requirements) ... aka a relatively static environment ... then the lack of agility has little impact.
the counter argument is outsourcing may bring higher trained data processing specialists which can more than compensate for the resistance introduced by a more formal contractual relationship.
the other classical failure is where there is active animosity between the users and the executives making the out-sourcing decision (resulting in all kinds of subversion).
boyd OODA-loops and high agility for competitive rapidly changing
environments:
https://www.garlic.com/~lynn/subboyd.html#boyd
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: cost of crossing kernel/user boundary Newsgroups: comp.arch Date: Sat, 04 Jan 2003 15:03:57 GMTjfc@mit.edu (John F. Carr) writes:
old trivia ... and of course compare&swap mnemonic was chosen because they are charlie's initials.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FlexEs and IVSK instruction Newsgroups: bit.listserv.ibm-main Date: Sat, 04 Jan 2003 16:27:02 GMTxarax@email.com (xarax) writes:
some programs used mvcl with zero padding to clear storage and at the same time to check for end of memory ... the instruction should interrupt with addressing interrupt with registers set to last valid address processed. prechecking resulted in no execution at all and no register update ... and as result incorrect value for size of real storage.
story of bug in 360/67 with the virtual memory table look aside
(referred to associative array at the time):
https://www.garlic.com/~lynn/2002q.html#54 cost of crossing kernel/user boundary
some other recent 125 refs:
https://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
https://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
https://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
https://www.garlic.com/~lynn/2002i.html#24 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
https://www.garlic.com/~lynn/2002m.html#75 New Book
https://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2002o.html#16 Home mainframes
https://www.garlic.com/~lynn/2002p.html#47 Linux paging
https://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
https://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#8 vax6k.openecs.org rebirth
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Sat, 04 Jan 2003 16:55:12 GMTjmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
later the VAMPS architecture was translated to vanilla 158/168 multiprocessor support (w/o microcode enhancements) ... which required running a specific version of vm .... a vm modified to support multiprocessing .... and released as a product (course there is the intertwining of the resource manager which had a bunch of things down for multiprocessor environments and released prior to the vm release with full multiprocessor support .... and all that code had to be switched from the resource manager product ... to the base product).
the translation of VAMPS to vanilla 158/168 was about the same amount of code changes for specific version of vm.
I didn't see where VAMPS was all that different than what i was doing for ecps or the resource manager .... and it sure wasn't that different from the official smp support. just do it, get it into the product and ship it. much of the technique used for ecps could also be used for most of VAMPS.
for ecps, at boot ... there was a list of all the ecps instructions thru-out the kernel ... if ecps wasn't available on the machine ... all those instructions got no-oped ... and the kernel effectively dropped thru to the software instructions. if the ecps instruction was executed ... it continued after the instructions it replaced (as opposed to the following instruction). in some of the VAMPS cases ... it would have bypassed large bodies of instructions.
part of the reason that VAMPS didn't make it out was that it would have been competing in the same market segment as vigil/tully. since i was doing both ... in some of the product escalation meetings ... i got a chair on both sides of the table and had the opportunity to have extensive arguments with my opposing self as to which was better and why.
misc smp refs:
https://www.garlic.com/~lynn/subtopic.html#smp
misc. ecps refs:
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/2000.html#12 I'm overwhelmed
https://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000e.html#6 Ridiculous
https://www.garlic.com/~lynn/2000g.html#7 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
https://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
https://www.garlic.com/~lynn/2002i.html#80 HONE
https://www.garlic.com/~lynn/2002j.html#5 HONE, xxx#, misc
https://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
https://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
https://www.garlic.com/~lynn/2002o.html#15 Home mainframes
https://www.garlic.com/~lynn/2002o.html#16 Home mainframes
https://www.garlic.com/~lynn/2002p.html#44 Linux paging
https://www.garlic.com/~lynn/2002p.html#48 Linux paging
https://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth
misc. VAMPS refs:
https://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000e.html#6 Ridiculous
https://www.garlic.com/~lynn/2000e.html#7 Ridiculous
https://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
https://www.garlic.com/~lynn/2001j.html#19 I hate Compaq
https://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
https://www.garlic.com/~lynn/2002i.html#80 HONE
https://www.garlic.com/~lynn/2002i.html#82 HONE
https://www.garlic.com/~lynn/2002o.html#16 Home mainframes
https://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
other 4341 refs:
https://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
https://www.garlic.com/~lynn/96.html#1 360/370
https://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#7 IBM S/360
https://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
https://www.garlic.com/~lynn/2000.html#90 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
https://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#9 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#20 S/360 development burnout?
https://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#9 MIP rating on old S/370s
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001l.html#32 mainframe question
https://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2002.html#11 The demise of compaq
https://www.garlic.com/~lynn/2002b.html#0 Microcode?
https://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
https://www.garlic.com/~lynn/2002g.html#44 ibm icecube -- return of watercooling?
https://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
https://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#27 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#29 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#4 HONE, , misc
https://www.garlic.com/~lynn/2002j.html#7 HONE, , misc
https://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
https://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750)
https://www.garlic.com/~lynn/2002k.html#3 misc. old benchmarks (4331 & 11/750)
https://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
https://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
https://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
https://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2002p.html#48 Linux paging
https://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
https://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Sat, 04 Jan 2003 17:51:58 GMTAnne & Lynn Wheeler writes:
it eventually got to the point that the best optimized VS1 with handshaking ran faster under VM ... than a compareably best optimized VS1 (for standalone, bare hardware) ran on the bare hardware (although not all of these optimzations made out the door in VS1). Still there was frequently lots of situations where the product VS1 would had higher thruput running under VM than when running on the bare hardware.
we utilized an instance of this later at SJR. SJR for a long time ran 195 with MVT ... and then eventually installed 158 running VM (and also used for MVS testing in preparation to replacing the 195 with 168).
After the 168 was installed ... the whole disk pool was setup so that all controllers were connected to both 168/mvs and 158/vm. However, we learned early never ot intermix mvs packs on vm strings & vm controllers. typical situation was when operater accidentally mounted an mvs pack on a vm string ... the data center would start getting irate calls from users that vm thruput had gone down the toilet.
the cause, of course was mvs's use of multi-track search for VTOC & PDS operations .... where worst case busy could be on the order of 1/3rd of a sec. for the transfer of a record amounting to a couple hundred bytes at the most. since the MVS users always ran in this mode of operation ... they didn't know that they there standard of living was that thruput was always in the toilet.
some number of instances happened where the mvs people would say ... oops, sorry ... but it really isn't that important to stop things and move the pack.
so the solution was to bring up a VS1 under vm ... and mount one of its packs on a MVS string and then start a vs1 multi-track search application of our own .... using few spare cycles on the loaded vm/158 system to bring the mvs/168 system to its knees (which immediately improved thruput for the vm users). That happened a couple of times ... and the mvs people got a lot more careful about mounting mvs packs on vm strings.
misc. CKD technology:
disk (or dasd) "strings" were a number of drives that shared the same control unit. in the days of 3330s .... all of these had removeable/mountable disk packs. a multi-track search .... was a controller/device i/o operation that looked for a string match. A multi-track search .... could search all 19 tracks of a 3330 w/o finding a match ... and then switch to the next cylinder and do it again. Worst case per operation was 19 revolutions at 60 revs/sec ... or slightly under 1/3rd sec. per operation. The operation had the characteristic of making both the drive and the controller busy. A shared controller might have 16 drives .... in which case, during a multi-track operation to any one drive it wasn't possible to access any of the other (possibly 15) drives.
it turns out that while vm/cms supported CKD disks ... it didn't make use of the multi-track search paradigm .... since the original days of cms in the mid-60s ... it used a fixed-block paradigm ... and if necessary emulated that on CKD devices.
one of the tso (interactive) thruput issues running on any of the operating systems that made heavy use of the CKD multi-track paradigm ... they didn't know that their thruput was always in the toilet ... because they had no reference of not operating in that mode.
while doing some work in the engineering lab ....
https://www.garlic.com/~lynn/subtopic.html#disk
I did an optimized paging access method implementation
https://www.garlic.com/~lynn/submain.html#mmap
demonstration using both (software) emulated fixed-block on CKD as well as real (3370) fixed-block devices ... that showed three times thruput increase compared to typical multi-track searce based environments ... and then worked on the case for having MVS support fixed-block devices. STL came back that even if given fully tested code for MVS ... that it was still a $26m cost to release it. Instead they started down the ECKD path ... just that cost was eventually much more than $26m ... not to mention all the subsequent hardware gyrations/costs because all disks are now really fixed-block and CKD operation has to be emulated in the hardware.
random past ckd/multi-track postings:
https://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
https://www.garlic.com/~lynn/97.html#16 Why Mainframes?
https://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe background
https://www.garlic.com/~lynn/2000.html#86 Ux's good points.
https://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
https://www.garlic.com/~lynn/2000f.html#18 OT?
https://www.garlic.com/~lynn/2000f.html#19 OT?
https://www.garlic.com/~lynn/2000f.html#42 IBM 3340 help
https://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
https://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
https://www.garlic.com/~lynn/2001.html#19 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001d.html#60 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
https://www.garlic.com/~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
https://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
https://www.garlic.com/~lynn/2002.html#5 index searching
https://www.garlic.com/~lynn/2002.html#6 index searching
https://www.garlic.com/~lynn/2002.html#10 index searching
https://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002d.html#22 DASD response times
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
https://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
https://www.garlic.com/~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2002n.html#50 EXCP
https://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Sat, 04 Jan 2003 18:09:10 GMTAnne & Lynn Wheeler writes:
in addition to the ecps methodology ... it is also straight forward to have VAMPS binaries ... and VAMPS kernel ... which would run in vanilla single processor mode if it wasn't on a VAMPS multiprocessor.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers,comp.sys.prime Date: Sat, 04 Jan 2003 18:30:21 GMTAnne & Lynn Wheeler writes:
when i originally did the fair share scheduling and the paging
algorithm and the other resource manager stuff on cp/67 while an
undergraduate in the late '60s ... i did all this dynamically adaptive
stuff. In the translation from cp/67 to vm/370 all of that was dropped
in the product.
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
the initial standard vm/370 product went out with a table of cpuids (cpu model numbers) in the boot (dmkcpi) routine and boot/ipl did various things based on the model number.
I retrofitted all the resource manager stuff including dynamic adaptive to vm/370 ... which eventually shipped as the vm/370 resource manager (first charged-for/priced kernel software product). One of the dynamic adaptive things was to eliminate the processor model table and attempt to do everything based on determining characteristics dynamically.
part of this was that the kernel had much longer life over a broad range of products. an early version of this retrofit for vm/370 (along with 30k to 40k lines of other kernel modifications) disappeared into AT&T longlines .... and propagated there for something like ten years across a broad range of processors (both non-clones and some pcm/clones). Eventually somebody from the branch office responsible for AT&T longlines tracked me down ... since the next model of machine was XA-only .... and AT&T longlines had gotten use to this ten year old kernel that dynamically adapted to all sorts of machine models, machine configurations and loads.
the official version shipped as the resource manager was viewed with suspicion in some quarters since it no longer had the cpuid/model table ... and therefor was totally agnostic with regard to running on official 370s or pcm/clone 370s.
... and another dynamic adaptive story
also as an undergraduate I put tty/ascii terminal support into cp/67. cp/67 had this code already that dynamically attempted to identify between kinds of 2741s and 1052s ... w/o having to pre-specify what kind of terminal was on which port. I tried to integrate the tty/ascii support in so that it operated in the same way (aka dynamically adapt to the kind of terminaL). The terminal controller had a different line-scanners for different kind of terminals .... and it was possible to dynamically tell the terminal controller which line scanner to use with which line (either hard-wired lines or dial-up lines). So i got all of this working ... and proadly demo'ing it ... when one of the ibm field service people pointed out to me that while the type of line scanner was dynamically selectable ... they had taken a shortcut in the controller implementation and hardwired oscillators to specific lines.
this met that while i could dynamically switch a line from 2741 line scanner to a tty/ascii line scanner, i couldn't switch the baud rate.
this prompted us to start a project at the university to build our own
terminal controller ... that supported both dynamic baud rate
determination as well as dynamic terminal type determination, This
also led to getting blamed for originating the pcm controller market
(and some rumor also responsible for the convulated nature of the
pu4/pu5 interface):
https://www.garlic.com/~lynn/submain.html#360pcm
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: cost of crossing kernel/user boundary Newsgroups: comp.arch Date: Sun, 05 Jan 2003 13:49:08 GMT"Andy Glew" writes:
somewhat aside .... during project athena days (half funded by dec, half funded by ibm) .... jerry saltzer was director ... charlie was asst. director (or whatever they called the position) on the ibm side ... and i forget who it was on the dec side?
when we were doing HA/CMP ... we subcontracted much of the software
development to company that started out as some number of people
having worked at project athena (all within half mile or so
of tech sq). other past trivia
https://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs
in the above, i watched as they pried the letters off the building ... i keep thinking that i needed to ask the guy if I could have one of the letters.
other stuff from by-gone days:
https://www.garlic.com/~lynn/subtopic.html#545tech
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Message (authentication/integrity); was: Re: CRC-32 collision rate Newsgroups: sci.crypt Date: Sun, 05 Jan 2003 15:59:39 GMT"Tom St Denis" writes:
purposeful errors can defeat simple CRCs, FEC, HASH ... with resulting loss of the ability to detect if the integrity of the message is intact.
encryption of the hash can help with integrity issues of purposeful errors.
business processes that control who has access to the encrypting key (used for encrypting the hash) .... can be used to infer who sent the message.
the act of encrypting the hash doesn't establish the sender ... it is the business process controlling who has access to the key used for the encryption that establishes the sender.
that still doesn't necessarily establish authentic in the real world .... in the real world ... an authentic message would also imply that the sender wrote the message. this is touched on various past non-repudiation threads; one scenario was the use of public key encryption in a challenge/response scenario ... the sender may be signing something that they didn't write (say as part of some sort of access control challenge/response protocol).
1) message wasn't altered in transit 2) message originated from specific sender 3) message was authored by the sender
both #2 and #3 require various kinds of business processes ... in addition to simply using an asymmetric key for encrypting a hash.
random refs:
https://www.garlic.com/~lynn/subpubkey.html#privacy x9.59, identity, authentication, and privacy
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers Date: Sun, 05 Jan 2003 22:04:32 GMT"Charlie Gibbs" writes:
the other response was that i originally wrote the specific code over 25 years ago in an era when
1) kernels were only built for possibly a (or limited number of) specific machine model(s).
2) were typically decommuted within five years by the vendor
this was one of the first attempts to make dynamically adaptive kernel across a really wide range of machine models (both non-clone & clone) and over a fairly wide range of time.
several thousand benchmarks went into calibrating the resource manager with fairly detailed performance data down to subprocess level ... along with a fairly detailed model of the algorithms. we would put a synthetic mixed-mode workload on that totally saturated the machine ... and then do a whole series of additional benchmarks incrementally changing the workload (adding/subtracting various kinds of processes). the resulting detailed monitor information as to the overal system execution characteristics as well as the moment to moment execution characteristics of the individual processes had to correspond to the model.
this was possibly the only product (at the time, still?) that accepted customer bug reports when the real life operation of the resource manager deviated from the algorithm specifications (traditionally the response has been "broken as designed").
random refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/submain.html#bench
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers Date: Sun, 05 Jan 2003 22:44:09 GMTjmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
note ... however ... the resource manager in both DMKCPI and DMKSTP used the store timer instruction ... 64bit value with bit twelve defined to be a microsecond (and bit 32 was just slightly more than 1 second). Machines could have higher or lower resolution than a microsecond ... but bit twelve was a microsecond ... also two back-to-back stores were supposed to be defined as storing different values.
the location 80 timer had been used in cp/67 ... because that was the only timer on the 360/67 ... but everything would have been converted to store clock for 370 & vm/370. There were actually three 64bit values ...
1) the TOD clock ... 2) the clock comparator .... which would generate an interrupt when the TOD clock value and the clock comparator were the same 3) the interval timer that decremented at the same rate as the TOD clock incremented
the interval timer and the tod clock had the same resolution ... 64 bits and bit 12 being one microsecond.
this 370 64-bit interval timer is different than the location 80 32-bit interval timer from 360 days. one of the reasons that the location 80 interval timer was depreciated in the 370 ... was that it updated real memory ... which required getting the memory bus and storing into real memory on every tic. 360s would have hardware failures if the timer function couldn't obtain the memory bus for the timer value updates (say because of processor and/or i/o activity).
the low-end 360s and the 370s 32bit location 80 timer were tic'ed 1/300 second ... every 3.3mills (real storage update issues). the 360/67 had a high resolution 32-bit location 80 timer that tic'ed once every 13.?microseconds (had more real-storage update issues). The 32bits counted about 14?hrs elapsed time (wether they tic'ed at 3.3millis or 13.?microseconds)
all of the 370s tic'ed their 64bit timers at well under millisecond intervals ... been awhile but i believe in the low tens or even single digit microseconds.
kernel calculations would typically pickup the resulting 64bit value ... calculate the difference between starting and end ... and then do shift right logical 12 bits ... putting microsecond in bit 0. Then if you continued with 32bit arithmetic you had a maximum value of about 4k seconds with microsecond resolution ... supplied by hardware that typically tic'ed on the order of at least tens of microseconds (for the slower speed machines ... say rated in the kips rather than mips) and for higher speed machines the tic rate was to increase to less than microseconds (although most calculations shifted out the bits less than microsecond).
So my resource manager code on a high MIP machine that tic'ed at least once a microsecond .... would have been computing the BCTR loop based on the elapsed time measured in microseconds (and count up to 4k seconds).
The problem i ran into early with the prg9 failure in the calculations was somebody pressing the stop button in the middle of the timer calculations ... and the calculations overflowing 4k seconds (stop buttom pressed for least 70 minutes or so ... and then starting up again).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multics preservation: good news Newsgroups: alt.os.multics,alt.folklore.computers Date: Sun, 05 Jan 2003 22:48:12 GMT"Shmuel (Seymour J.) Metz" writes:
note/update:
I remember reading an early document about 360/6x machine with virtual
memory having one, two, and four processors. I sort of had vaque
recollection that it was model number other than 360/67.
however, i've subsequently been told that 360/60 was with 2mic memory
and 360/62 was with 1mic memory. both models never shipped, and were
replaced with 360/65 with 750ns memory. the 360/67 then shipped as
360/65 with virtual memory ... only available in one (uniprocessor)
and two processor (multiprocessor) configurations
https://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers Date: Mon, 06 Jan 2003 01:02:23 GMTAnne & Lynn Wheeler writes:
specifically from above:
The CPU timer is a binary counter with a format which is the same as
that of the TOD clock, except that bit 0 is considered a sign. In the
basic form, the CPU timer is decremented by subtracting a one in bit
position 51 every microsecond. In models having a higher or lower
resolution, a different bit position is decremented at such a
frequency that the rate of decrementing the CPU timer is the same as
if a one were subtracted in bit position 51 every microsecond. The
resolution of the CPU timer is such that the stepping rate is
comparable to the instruction-execution rate of the model.
======
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers Date: Mon, 06 Jan 2003 01:32:42 GMTgiven the official timer description .... the prg9 could occur if the whole bctr loop was executed in less than one microsecond elapsed time or greater than 4k seconds elapsed time (but i thot i had fixed the prg9s sometime in the past ... oh well).
a machine that could execute the bctr loop in less than one microsecond would have "stepping" of the clock at finer resolution than one microsecond .... but the shift operation would result in the timed interval being rounded down to one microsecond resolution (aka the full clock definition has ability for providing on the order of .2 nanosecond in the low order bit position).
if the current mechanism is tripping (prg9 exception) when the loop executes at a rate of 7mips and takes less than 3.3milliseconds .... then if the actual hardware clock definition was implemented ... the effective mip rate would have to be 3333 times that in order to lead to the prg9 (executing the loop in less than 1 microsecond) or a machine running at around 23,331 mips.
I know that the original code ran on machines on the order of 50kips (.05mips) ... trying to provide dynamic adaptive capability across a period of more than 30 years ... and from .05mips to 23,331mips (close to six orders of magnitude range) wouldn't seem unreasonable.
also referencing the previous document ... it lists the location 80
timer being dropped in the transition from 370 to 370/xa
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/F.3.5?DT=19970613131822
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers Date: Sun, 05 Jan 2003 19:23:10 -0700trying to reconstruct the location 80 timer.
the shift of the 370 cpu timer ... resulted low order bit position one microsecond and nearly 70 minutes of time for 32bit number.
the high resolution location 80 on the 360/67 ... tic the low order bit position something like 13.6microseconds and gave 14 or 15hr measurement in 32bits ....
13.6 times 70 minutes gives 15.8hr measurement.
tic'ing the 8th bit once every 1/300 sec ,,, yields a measurement interval of 15.4hrs (32bit number). that means that the high resolution timer that tic'ed bit zero ... was actually 13.02microseconds ... not 13.6microseconds.
now the location 80 timer would cause a machine check "red light" if it was unable to obtain the memory bus to update real location 80. basically there was almost a full tic window ... a update for storage would go pending with a tic .... if the next tic happened before the storage was updated for the previous tic ... the machine would red light.
we experienced this on the 360/67 at the university when we were
developing the first 360 non-ibm (i.e. clone) controller.
https://www.garlic.com/~lynn/submain.html#360pcm
the channel interface had been reverse engineered and a channel interface board had been built for the 360/67 channel. Some of the early testing resulted in "red lighting" (aka machine check) the machine. The controller got the channel interface ... and thru it, the memory bus and was transfering data .... but held it continuously for more than a tic interval (and voila a machine check). some amount of additional engineering had to be done to make sure that the channel interface (and therefor the memory bus) was released at least once every timer tic interval.
it was much more of a problem on the 360/67 with the high resolution timer and 13.02 microsecond windows ... than on the slower speed 360s ... or the 370s ... with tics only happending every 3.3mills.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers Date: Mon, 06 Jan 2003 01:54:21 GMT... and if it is really failing because it is using location 80 timer ... (stepping at 3.3mills) then it ain't my code .... because all of my stuff used cpu timer.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vax6k.openecs.org rebirth Newsgroups: alt.folklore.computers Date: Mon, 06 Jan 2003 04:51:25 GMTBrian Inglis writes:
the resource manager were update files ... except for two new assemble files DMKSTP ASSEMBLE and DMKSRM ASSEMBLE.
STP was taken from '60s televison advertisement ... the racer's edge.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multics preservation: good news Newsgroups: alt.os.multics,alt.folklore.computers Date: Mon, 06 Jan 2003 14:02:28 GMT"Shmuel (Seymour J.) Metz" writes:
sorry ... i wasn't commenting on hardwired issue .... it was that 70, 62, & 60 all had in common was that they were for 1mic memory and didn't ship .... and 75, 67, & 65 were presumably essentially the same models but with the faster memory (and whatever other changes were necessary).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Message (authentication/integrity); was: Re: CRC-32 collision rate Newsgroups: sci.crypt Date: Mon, 06 Jan 2003 14:10:54 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Round robin IS NOT load balancing (?) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Date: Tue, 07 Jan 2003 03:00:51 GMTarielgont@softhome.net (Fernando Gont) writes:
At least at some time in the past ... if there wasn't an example of it in a tcp/ip college text ... then some large amount of the world didn't believe it was possible.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: asynchronous CPUs Newsgroups: alt.os.multics,alt.folklore.computers Date: Tue, 07 Jan 2003 20:19:36 GMTTom Van Vleck writes:
LSM supported clock specification ... allowing simulation of asyhncronous chips ... as well as digital/analog chips ... aka used for the original disk thinfilm read/write heads.
random past refs to LSM:
https://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
https://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
https://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
https://www.garlic.com/~lynn/2002g.html#82 Future architecture
https://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Mainframe System Programmer/Administrator market demand? Newsgroups: bit.listserv.ibm-main Date: Tue, 07 Jan 2003 21:26:12 GMTAnne & Lynn Wheeler writes:
... and article on the subject
Managing the Outsourcing Relationship
http://itmanagement.earthweb.com/netsys/article.php/1565251
Managing the Outsourcer Relationship
January 7, 2003
By Drew Robb
Doing everything yourself may sound great, but it quickly becomes
tedious and inefficient. So we outsource everything from pumping our
water to ironing our shirts and educating our children, focusing
instead on our core functions.
snip
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Round robin IS NOT load balancing (?) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Date: Wed, 08 Jan 2003 04:50:41 GMTmarka@isc.org (Mark Andrews) writes:
random refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Calculating expected reliability for designed system Newsgroups: comp.arch Date: Wed, 08 Jan 2003 19:33:33 GMTjason_watkins@pobox.com (Jason Watkins) writes:
when the 3090 had been in customer shops for a year ... some corporate guy tracked me down trying to figure out some skewed data from the public reports. they had projected five total errors of particular kind across all machines at all customer installations for 12 month period. the stats from the reporting company was showing that a total of something like 15 such errors had been recorded (this is not total per machine per year ... this is total across all machines for 12 months) ... and there was serious concern about the difference between the projected five and the reported 15 ... which turns out to have been the error indication i had selected. turns out that i could change the simulated error to a different kind ... and still kick-off effectively the same error recovery process.
note that while some vendors talked at:
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html
nobody was giving up any kind of numbers ... at least not in that particular market segment
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Round robin IS NOT load balancing (?) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Date: Wed, 08 Jan 2003 20:03:59 GMTAnne & Lynn Wheeler writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: mainframe Newsgroups: bit.listserv.ibm-main Date: Thu, 09 Jan 2003 14:39:32 GMTTerry Sambrooks writes:
by the early '80s there was also a number in of 2nd tier(?) clones in
the low/mid-range marketplace. recent discussions:
https://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?
https://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
from earlier ... non-clones/non-PCM there use to be snow white and the
seven dwarfs ... or the BUNCH:
https://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Calculating expected reliability for designed system Newsgroups: comp.arch Date: Thu, 09 Jan 2003 15:08:21 GMT"del cecchi" writes:
when we were doing HA/CMP we also talked to guys developing 1-800
number system ... who were looking at a fault tolerant computer
... that would have to be taken down to do software
maint/upgrade. Doing this just once a year blew a minimum of five
years of budgeted/allowed outage. a replicated/fall-over solution
addressed the outage for software maint/upgrade ... but also subsumed
the advantage of having a fault tolerant computer.
https://www.garlic.com/~lynn/96.html#36 Mainframes & Unix (and TPF)
https://www.garlic.com/~lynn/99.html#143 OS/360 (and descendants) VM system?
https://www.garlic.com/~lynn/2001g.html#58 TECO Critique
https://www.garlic.com/~lynn/2001k.html#10 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2002e.html#67 Blade architectures
there are lots of other characteristics for well designed system.
when wereworking on this thing called a payment gateway for this thing
that came to be called electronic commerce ... one of the issues was
diagnosing the end to end environment ... if you got a problem call,
you wanted to be able to do first level problem determination within
five minutes ... not have it turn into NTF (no trouble found) after
three hrs.
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Calculating expected reliability for designed system Newsgroups: comp.arch Date: Fri, 10 Jan 2003 14:56:24 GMTAnne & Lynn Wheeler writes:
we coined the terms disaster survivability and geographic survivability to try and highlight some of these business critical issues ... distinguishing from simpler disaster/recovery scenarios.
there was one weekend in the early '90s that a lot of people couldn't get money out of atm machines .... most of them didn't really care that the roof of the primary datacenter had collapsed with snow load ... and the backup datacenter was out because of the WTC bombing.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Flex Question Newsgroups: bit.listserv.ibm-main Date: Fri, 10 Jan 2003 15:24:29 GMTpdw@MARCDATABASE.COM (Peter D. Ward) writes:
at least sequent, data-general, and convex have all done scalleable numa implementations with sci.
there is both the issue of direct processor instruction emulation thruput as well as various kinds of support operations. in the standard mainframe line .... something similar can be seen in the transition from 370 to 303x and integrated channels. Even tho the 3031 and the 158 were the same microprocessor .... the 158 shared the microprocessor between 370 emulation and (integrated) channel functions. For the 303x series ... a 158 engine was taken and had the 370 emulation removed ... leaving only the channel emulation microcode and called it a 303x channel director.
In some sense, a single-processer 3031 was actually a multiprodcessor system with two 158 microprocessor engines ... one with the dedicated 370 emulation and one with the dedicated channel function (instead of both functions sharing a single microprocessor engine as in the vanilla 370/158).
Earlier 115/125 was built on the same philosophy. The 370 115/125 had a nine-position memory bus for microprocessers ... standard configuration had one microprocessor with the 370 emulation ... and from two up to eight other (same) microprocessors with other kinds of microcode programs implementing other kinds of channel, controller, and I/O functions. The only difference between 115 and 125 was that the microprocessor used in the 125 for 370 emulation function ran somewhat faster than the other microprocessors in the configuration.
One could draw a very close analogy between flex-es on an eight-way SMP ... with the 115/125 implementation ... except running at a significantly higher thruput rate.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: InfiniBand Group Sharply, Evenly Divided Newsgroups: comp.arch Date: Fri, 10 Jan 2003 18:16:57 GMTyoung_r@encompasserve.org (Rob Young) writes:
recent posts:
https://www.garlic.com/~lynn/2003.html#34 Calculating expected reliability for designed system
https://www.garlic.com/~lynn/2003.html#37 Calculating expected reliability for designed system
https://www.garlic.com/~lynn/2003.html#38 Calculating expected reliability for designed system
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: InfiniBand Group Sharply, Evenly Divided Newsgroups: comp.arch Date: Sat, 11 Jan 2003 06:57:40 GMTJan Ingvoldstad <jani+news-comp@nntp.ifi.uio.no> writes:
now ... supposedly SSL was put into place to help catch some DNS vulnerabilities.
basically both SSL and DNS have some common vulnerabilities ... basically master domain name registration databases. corrupting those can result in DNS sending out bad data. Corrupting those also means that a bad guy can go to a SSL certificate manufacturing operation ... and get a valid certificate (since the CA/certificate manufacturing checks the master domain name database as to valid applications for SSL certificates).
from a client's standpoint ... dns can 1) not supply data (a DOS attack), 2) supply bad data (aka ip-address spoof/take-over) and 3) supply good data. SSL effectively addresses case #2 ... and turns it into case #1 (or DOS attack).
SSL doesn't improve #2 into #3 (say like a forward error correcting algorithm might), it is purely a detection and toss mechanism (meaning that a bad data attack is turned into a DOS attack).
now wandering a bit (because of some recent threads in pkix and elsewhere) ... i claim that it would be possible to eliminate the current TTP certificate manufacturing (term we coined to differentiate the current SSL infrastructure from a PKI) and replace it with one where DNS distributed signed packets. The signed packets effectively are a domain name, a public key, and a signature. A browser treats the signed packets exactly like it treats an SSL certificate ... but instead of getting it from a website it gets it from DNS.
My claim is that if the signing of the packets is done with the same care as the current certificates ... there is no decrease in the level of integrity (compared to the current DNS+SSL environment) ... DOS attacks are not affected and the same bad data attacks will be detected and turned into DOS attacks ... aka every case where an ip-address is corrupted or replace ... will be detected with the DNS distributed signed packets as with SSL certificates.
The advantage is that when there isn't corrupted data ... that a SSL can be setup in single exchange .. since the client already has the server's public key before the session initiation starts (there are some amount of micro protocol efficiencies).
One of my objectives in making the proposal is an attempt to highlight the actual DNS vulnerabilities ... and some of the macro level things that might be necessary to address them.
bunch of stuff on ssl "comfort" certificates:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
some reference to early ssl related activities (this little
client/server startup that was in silicon valley before moving to
mountain view):
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: basic pki question Newsgroups: sci.crypt Date: Sat, 11 Jan 2003 07:33:52 GMTmdalbis@smartronix.com (usmcpsu) writes:
one part of the pair can be made public ... and anybody wanting to securely and privately communicate with you can use that public key for encrypting messages ... and only you ... with the corresponding asymmetric key can decrypt it.
now sometimes because asymmetric key encryption is too heavy duty (compared to symmetric key encryption) ... a random symmetric secret key is generated (for each message/session), the message encrypted with the symmetric secret key ... and then just the symmetric secret key encrypted with the public key ... and the combined encrypted message and encrypted key are transmitted. again, only the person with the corresponding asymmetric key can read the message ... since only that key can decrypt the random symmetric secret key which is then used to decrypt the actual message. This is effectively the common SSL/HTTPS technique used by browsers for securing communication.
both cases, asymmetric cryptography is being used to address an issue in cryptography associated with key distribution.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Timesharing TOPS-10 vs. VAX/VMS "task based timesharing" Newsgroups: alt.folklore.computers Date: Sat, 11 Jan 2003 15:48:07 GMTjmfbahciv writes:
i did this thing i called fair share scheduler ... but that was just
the default if no other specifications were made (explicit
specifications could provide all sorts of UNfair resource management).
https://www.garlic.com/~lynn/subtopic.html#fairshare
one of the objectives was to explicitly control resource consumption ... and provide granularity of resources based on task type of activity that would still conform to the resource management rules (starting to eliminate the ability for individuals to attack the resource control mechanisms by exhibiting certain types of task characteristics).
the other thing involved was starting to control page thrashing with
controls on real storage allocation and competing tasks by the
scheduler. this involved both the page replacement algorithm (at a
micro level) and the scheduler controlling which tasks were
concurrently contending (at the macro level).
https://www.garlic.com/~lynn/subtopic.html#wsclock
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Will Apple ever offer a newsreader? Newsgroups: comp.sys.mac.comm,alt.folklore.computers Date: Sat, 11 Jan 2003 16:18:19 GMTPete Fenelon writes:
wais also morphed into standards activity as x39.50 along with sigwais and sigir.
random ref:
https://www.garlic.com/~lynn/2001c.html#67 What ever happened to WAIS?
total thread drift ... one morning walking to a meeting ... i stopped
and watched them pry the letters of the tmc building ... thread drift:
https://www.garlic.com/~lynn/2000d.html#64 "all-out" vs less aggressive designs
https://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs
https://www.garlic.com/~lynn/2001n.html#17 CM-5 Thinking Machines, Supercomputers
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: InfiniBand Group Sharply, Evenly Divided Newsgroups: comp.arch Date: Sat, 11 Jan 2003 19:35:42 GMTAndy Glew <andy-glew-public@sbcglobal.net> writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Horror stories: high system call overhead Newsgroups: alt.folklore.computers Date: Sun, 12 Jan 2003 03:29:26 GMTRoger Johnstone writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Timesharing TOPS-10 vs. VAX/VMS "task based timesharing" Newsgroups: alt.folklore.computers Date: Sun, 12 Jan 2003 13:33:40 GMTjmfbahciv writes:
at a point ... the scheduler calculated an incremental real-time that was proportional to the granularity of the slice plus a bunch of stuff about recent resource consumption ... and whether that was proportional greater or lesser than what the target resource consumption was. the target resource consumption could be calculated based on fair share ... or some number of other strategies. the incremental real-time value was then added to the current wall-clock and became the advisery deadline.
everything was ordered by the advisery deadlines (they weren't hard and fast deadlines like in realtime systems ... they were just basis for ordering). a large number of different scheduling strategies could co-exist simultaneously ... and then were all normalized down to the ordering of the advisery deadlines.
i started out having (implicit) idle queue, schedling/swap queue waiting for real memory, dispatchable (runtime) queue. advisery deadline was consistent ordering regardless of waiting for real memory or dispatchable. if you made too little progress ... both you immediate advistory deadline would pass ... as well as your recent rate of resource consumption.
a trivial interactive task that woke up after a long idle ... would get a very small granularity ... but also tend to have very low actual resource consumption compared to some target. as a result the calculated advisery deadline would be very near in the future.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: InfiniBand Group Sharply, Evenly Divided Newsgroups: comp.arch Date: Sun, 12 Jan 2003 13:46:23 GMTyoung_r@encompasserve.org (Rob Young) writes:
sabre has been tpf forever (well it use to be called acp). lots of airline reservation stuff can be handled by RAID equivalent for processor/systems.
random refs:
https://www.garlic.com/~lynn/99.html#17 Old Computers
https://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
https://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001c.html#37 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001g.html#45 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
https://www.garlic.com/~lynn/2001n.html#0 TSS/360
https://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
https://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
https://www.garlic.com/~lynn/2002g.html#3 Why are Mainframe Computers really still in use at all?
https://www.garlic.com/~lynn/2002h.html#12 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
https://www.garlic.com/~lynn/2002i.html#83 HONE
https://www.garlic.com/~lynn/2002j.html#83 Summary: Robots of Doom
https://www.garlic.com/~lynn/2002m.html#67 Tweaking old computers?
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: InfiniBand Group Sharply, Evenly Divided Newsgroups: comp.arch Date: Sun, 12 Jan 2003 13:50:27 GMTAnne & Lynn Wheeler writes:
...
keeping ahead of DNS attacks:
http://zdnet.com.com/2100-1107-979650.html
By Paul Mockapetris
Special to ZDNet
January 8, 2003, 9:12 AM PT
COMMENTARY--The domain name system--the global directory that maps
names to Internet protocol addresses-- was designed to distribute
authority, making organizations literally "masters of their own
domain." But with this mastery comes the responsibility of
contributing to the defense of the DNS.
The distributed denial-of-service (DDoS) attacks against the DNS root
servers on Oct. 21, 2002, should serve as a wake-up call. The attack
was surprisingly successful--most of the root servers were disrupted
by a well known attack strategy that should have been easily
defeated. Future attacks against all levels of the DNS--the root at
the top; top-level domains like .com, .org and the country codes; and
individual high-profile domains--are inevitable.
... snip ...
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Origin of Kerberos Newsgroups: comp.protocols.kerberos,alt.folklore.computers Date: Sun, 12 Jan 2003 16:56:19 GMT"allem_mike" writes:
kerberos originated at mit project athena. projec athena was jointly
funded by DEC & IBM (i think $25m each). overall director had been in
545 tech. sq on multics. there was DEC sub director (that i don't
remember name) and IBM sub director ... who had also been at 545 tech.
sq in the science center (who also originated the compare&swap
instruction, the mnemonic are his initials).
https://www.garlic.com/~lynn/subtopic.html#545tech
my wife and I had done periodic audits of stuff at project athena. I have some recollection of one all day session walking thru the initial pass at the cross-domain authentication process.
kerberos reference page
http://www-2.cs.cmu.edu/afs/andrew.cmu.edu/usr/shadow/www/kerberos.html
note that cmu lab was ibm funding ... spawning afs, andrew toolkit/widgets, mach (in somewhat the same genre as cp/67 as a microkernel ... which has been used in number of implementations), camelot (which begat transarc)
and the mit page:
http://web.mit.edu/kerberos/www/index.html
"what is kerberos" is at the bottom of the (above) index page.
page at isi/usc:
http://www.isi.edu/gost/info/kerberos
we have some interest in certificate-less digital signature
authentication
https://www.garlic.com/~lynn/x959.html#aads
in pk-init:
http://www.ietf.org/html.charters/krb-wg-charter.html
aka
http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-16.txt
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Top Gun Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 12 Jan 2003 20:32:43 GMTreview of boyd's biography made today's (sunday 1/12) book section in the washington post.
for a year he managed one of the largest (ibm mainframe?) data centers. It was possibly larger than a couple large ones that i had been in ... boeing renton datacenter (summer i spent helping set up bcs; which was then replicated at the 747 plant in everett) and the pok (ibm) data center (some 3rd shift time ... at the same time a couple of guys were crafting some code from cp/67 into mvt for initial SVS ... aka vs/2)
other boyd references:
https://www.garlic.com/~lynn/subboyd.html#boyd
other articles/reviews of the biography:
http://www.belisarius.com/
https://web.archive.org/web/20010722050327/http://www.belisarius.com/
above also includes URL pointing to the online version of the post's review (which appears on pg. 7 of the paper copy of the sunday book/world section).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SSL & Man In the Middle Attack Newsgroups: comp.security.misc Date: Mon, 13 Jan 2003 11:48:16 GMT"NEWS.DFN.CIS" writes:
client generates a random secret key, encrypts it with the server's
public key (from the certificate) and sends it to the server. from
then on the server and client encrypt everything using the generated
random secret key. only the server specified in the validated digital
certificate will be able to decrypt the random secret key (since they
should be the only one with the private key capable of decrypting
something that had been encrypted with the corresponding public key).
the client knows the random secret key because it generated it ... the
server knows the random secret key because it was able to decrypt it
with the server's private key.
recent refs:
https://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003.html#41 InfiniBand Group Sharply, Evenly Divided
https://www.garlic.com/~lynn/2003.html#42 basic pki question
there used to be an issue that a man-in-the-middle could play during SSL setup negotiation ... where it would fake messages as to the agreed upon secret key encryption protocol ... and force both the client & server to select the weakest encryption protocol (with the shortest key length). then once the secret key was exchanged ... the man-in-the-middle was out of the loop ... other than attacking the encrypted messages to determine the secret key (which it had forced to the shortest possible).
other attacks on SSL infrastructure ... as opposed to SSL protocol ... is to get the client redirected to a different site by substituting a different URL. The actual SSL check is does the URL in the certificate match the URL that the client entered. If the attack can get the client to enter the URL of the man-in-the-middle (i.e. a bogus URL) ... who has a valid certificate for their site ... then the SSL protocol works to the man-in-the-middle ... who then can fakes a client to the real web site.
basically the SSL certificate protocol was to handle an ip-address take-over in the domain name infrastructure ... aka man-in-the-middle corrupted a DNS cache entry for a URL->IP-address mapping with the wrong ip-address. The client typed in the correct URL ... but was sent off to the wrong ip-address. The server at the fraudulent website would be unable to establish a correct certificate for the original URL.
However, if the attack involved getting the client's browser somehow to go to the wrong URL ... then the fraudulent website could have a valid certificate for the fraudulent URL and everything proceeds. Since frequently a client is just clicking on something ... rather than actually typing in the actual URL ... there could be lots of opportunities for incorrect URLs (even to trying to obtain domain names for the common mistypings of URLs).
the other is trying to spoof getting an issued certificate for the desired URL (a recent case was an IE problem that accepted as valid, certificates generated by individuals).
misc refs:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat Ethernet, etc. Newsgroups: comp.arch Date: Mon, 13 Jan 2003 21:48:02 GMTRick Jones writes:
vmtp (rfc 1045) looked at doing same in 5packets
xtp looked at doing same in 3packets ... with no buffer copies and everything pipelined out the wire ... and intelligent chip could add trailor checksum on the packet as it was exiting on the wire.
random past stuff on packet exchange, buffer copies, header checksum, etc:
https://www.garlic.com/~lynn/93.html#32 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#00 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/99.html#0 Early tcp development?
https://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000b.html#1 "Mainframe" Usage
https://www.garlic.com/~lynn/2000b.html#5 "Mainframe" Usage
https://www.garlic.com/~lynn/2001b.html#57 I am fed up!
https://www.garlic.com/~lynn/2001d.html#59 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?
https://www.garlic.com/~lynn/2001k.html#62 SMP idea for the future
https://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
https://www.garlic.com/~lynn/2002g.html#5 Black magic in POWER5
https://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
https://www.garlic.com/~lynn/2002g.html#50 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002i.html#66 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Timesharing TOPS-10 vs. VAX/VMS "task based timesharing" Newsgroups: alt.folklore.computers Date: Tue, 14 Jan 2003 14:02:58 GMTBrian Inglis writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat Ethernet, etc. Newsgroups: comp.arch Date: Tue, 14 Jan 2003 16:19:45 GMTAndi Kleen writes:
rate-based pacing tends to directly adjust the inter-packet transmission interval (in effect, windowing tended to only indirectly address the primary problem). part of the lack of rate-based pacing was that many of the tcp/ip platforms during the '80s had poor timer-support facilities ... making control of inter-packet transmission intervals difficult to implement.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Wild hardware idea Newsgroups: comp.arch Date: Wed, 15 Jan 2003 01:40:58 GMT"Duane Sand" writes:
it started with Amdahl ... putting some extensive hypervisor support into the metal (firmware?) of their machine. IBM responded with PR/SM ... which then grew into LPARs.
the high end machines have had fairly complex wide/horizontal microcode that tended to be extgremely difficult to program. Amdahl had come out with an intermediate mode that they called macrocode (effectively an optimized 370 subset) which greatly simplified the development and support of new hardware features.
random lpar / pr/sm postings:
https://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
https://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
https://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
https://www.garlic.com/~lynn/2000.html#8 Computer of the century
https://www.garlic.com/~lynn/2000.html#63 Mainframe operating systems
https://www.garlic.com/~lynn/2000.html#86 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000c.html#8 IBM Linux
https://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
https://www.garlic.com/~lynn/2001.html#34 Competitors to SABRE?
https://www.garlic.com/~lynn/2001b.html#72 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#5 SIMTICS
https://www.garlic.com/~lynn/2001e.html#61 Estimate JCL overhead
https://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
https://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
https://www.garlic.com/~lynn/2001h.html#33 D
https://www.garlic.com/~lynn/2001l.html#24 mainframe question
https://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
https://www.garlic.com/~lynn/2001n.html#26 Open Architectures ?
https://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
https://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
https://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
https://www.garlic.com/~lynn/2002e.html#25 Crazy idea: has it been done?
https://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#6 Blade architectures
https://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
https://www.garlic.com/~lynn/2002n.html#6 Tweaking old computers?
https://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
https://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?
https://www.garlic.com/~lynn/2002o.html#0 Home mainframes
https://www.garlic.com/~lynn/2002o.html#15 Home mainframes
https://www.garlic.com/~lynn/2002o.html#16 Home mainframes
https://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
https://www.garlic.com/~lynn/2002p.html#4 Running z/VM 4.3 in LPAR & guest v-r or v=f
https://www.garlic.com/~lynn/2002p.html#40 Linux paging
https://www.garlic.com/~lynn/2002p.html#44 Linux paging
https://www.garlic.com/~lynn/2002p.html#45 Linux paging
https://www.garlic.com/~lynn/2002p.html#46 Linux paging
https://www.garlic.com/~lynn/2002p.html#48 Linux paging
https://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
https://www.garlic.com/~lynn/2002p.html#55 Running z/VM 4.3 in LPAR & guest v-r or v=f
https://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
https://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
https://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: If you lived as a child in the 50's, 60's or 70's, Newsgroups: bit.listserv.ibm-main Date: Wed, 15 Jan 2003 01:30:24 GMTi just got told that there is a new strain(s) of salmonella that has shown up in the last 10-12 years ... and a result it is much more dangerous to eat one of my favorite foods ... raw cookie dough.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Card Columns Newsgroups: alt.folklore.computers,comp.lang.pl1 Date: Wed, 15 Jan 2003 13:51:08 GMTrobin writes:
misc. ref:
https://www.garlic.com/~lynn/2002n.html#39 CMS update
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat Ethernet, etc. Newsgroups: comp.arch Date: Wed, 15 Jan 2003 14:27:26 GMTAndi Kleen writes:
at:
https://www.garlic.com/~lynn/rfcietff.htm
3390
Increasing TCP's Initial Window, Allman M., Floyd S., Partridge C.,
2002/09/31 (15pp) (.txt=36177) (Obsoletes 2414) (Updates 2581) (was
draft-ietf-tsvwg-initwin-04.txt)
2581 PS
TCP Congestion Control, Allman M., Paxson V., Stevens W., 1999/04/08
(14pp) (.txt=31351) (Updated by 3390) (Obsoletes 2001) (TCP-CC)
2001 -
TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast
Recovery Algorithms, Stevens W., 1997/01/23 (6pp) (.txt=12975)
(Obsoleted by 2581)
and in RFCs listed by section, from TERM (term->RFC#)
RFCs related to
congestion
see also performance
3451 3450 3436 3390 3309 3210 3209 3182 3181 3175 3168 3159 3124 3097
3042 2997 2996 2988 2961 2960 2914 2889 2884 2872 2861 2816 2814 2753
2752 2751 2750 2749 2747 2746 2745 2582 2581 2556 2490 2481 2414 2382
2380 2379 2309 2210 2209 2208 2207 2206 2205 2140 2098 2001 1859 1372
1254 1110 1106 1080 1018 1016 896 813 449 442 210 59 19
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: MIDAS Newsgroups: alt.folklore.computers Date: Wed, 15 Jan 2003 18:24:40 GMT"Russ Holsclaw" writes:
bob adair observed that i was violating the Princ of Ops ... and that CP/67 virtual machine implementations do everything possible to preserve the architecture integrity of the 360 princ of ops to address this delima he noted that the diagnose instruction was defined as undefined and model dependent ... and constructed this framework/paradigm of a virtual machine model dependent implementation of the diagnose instruction (aka cp/67 defined diagnose insturction operation for the virtual machine model of the 360 .. aka cp/67 kernel was in effect the top level microcode of the virtual machine).
I learned a lot about KISS and the meaning of architecture from Bob. A lot of the CP/67 microkernel, compact, KISS characteristics are because of him. It wasn't always easy ... KISS is frequently significantly harder work than various of the first-take, quck&dirty solutions.
my CMS changes were remapped into diagnose instruction with the same semantics ... i.e. the diagnose for cms disk i/o would perform as a cc=1, csw stored SIO-semantics. CMS was modified that on boot to see if it was running a virtual machine model or a real machine model. It it was running a virtual machine model ... it would use the diagnose instruction flavor rather than the sio instruction flavor. when cms was changed from the "cambridge monitor system" to the "conversational monitor system" as part of the cp/67 to vm/370 transition ... the ability for cms to run on bare iron was removed.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: MIDAS Newsgroups: alt.folklore.computers Date: Wed, 15 Jan 2003 18:28:05 GMTBrian Inglis writes:
random ref:
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Card Columns Newsgroups: alt.folklore.computers Date: Wed, 15 Jan 2003 18:40:25 GMTBrian Inglis writes:
the SID code started with four characters because the original process used "UPDG" & "UDPT" as the first four characters of the filetype leaving up to four characters for the update name. this was expanded when auxfiles were introduced.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SSL & Man In the Middle Attack Newsgroups: comp.security.misc Date: Wed, 15 Jan 2003 19:06:31 GMTBarry Margolin writes:
a whole table of corresponding public keys have been loaded into various browsers. when a browser gets one of these string of bits ... it can tell if the bits have been altered since the original signing ... by finding the public key (that corresponds to the private signing key) and verify the signature.
this just validates whether or not the string of bits have been altered since the (certificate) signature was originally signed.
so various exploits are:
1) somehow introduce a public key into the browser tables that shouldn't be there. one ways is a virus that modifies the browsre table. another way is get user to click on the "accept" button for unknown CA. another way is some ethically challenged party purchases the assets of some company going defunct that already has a key in standard browser table)
2. find a bug in the validation process. this is somewhat the IE bug. turns out that IE wasn't checking if a CA was really the CA. If somebody had a valid certificate signed by a valid CA ... and they then signed a fradulent certificate ... IE would accept the signing of the fraudulent certificate as if the original CA had signed it.
3. corrupt the database entry that the information in the certificate is taken from. I call this the irony or catch-22 exploit. The reason for SSL domain name certificates have been issues with the integrity of the domain name infrastructure. However, the authoritative agency for domain name ownership is the domain name infrastructures. CAs when asked to issue a SSL domain name server certificate, check with the domain name infrastructure to see if they are actually dealing with the owner of the domain name. If that answer comes back "yes", the CAs then issue the certificate. The attack that has happened on the domain name infrastructure to corrupt those database entries has been call "domain name take-over" ... you convince the domain name infrastructure to change the domain name database entry ... and then you get a certificate for that domain name. The irony is that all of the CAs in the world that are manufacturing SSL domain name server certificates (because of integrity issues of the domain name infrastructure) are actually dependent on the integrity of the domain name infrastructure for validating the information that they would put in a certificate. This can also be considered the security is only as strong as the weakest link exploit or the obfuscate the business process with a bunch of mathematical mumbo-jombo exploit. Note that the company name in the SSL certificate isn't likely to correspond to the company name that a consumer might expect ... but nobody actually examines these fields ... the protocol just does a match on the domain name field ... and the rest of the fields are ignored.
similar recent discussion:
https://www.garlic.com/~lynn/aepay10.htm#71 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aepay10.htm#73 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aepay10.htm#74 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
https://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
https://www.garlic.com/~lynn/aepay10.htm#80 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
https://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)
long history of threads on this issue:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SSL & Man In the Middle Attack Newsgroups: comp.security.misc Date: Wed, 15 Jan 2003 19:19:49 GMTAnne & Lynn Wheeler writes:
this just validates whether or not the string of bits have been altered since the certificate was originally signed.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Amdahl's VM/PE information/documentation sought Newsgroups: alt.folklore.computers Date: Thu, 16 Jan 2003 00:54:54 GMTi forwarded to one of the people that worked on it.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SSL & Man In the Middle Attack Newsgroups: comp.security.misc Date: Thu, 16 Jan 2003 12:19:48 GMTAnne & Lynn Wheeler writes:
the ssl domain name certificate ... basically amounts to fields from some account record in a domain name infrastructure database (possibly asn.1 encoded and then digitally signed) ... the security of the business process really revolves around the security that the domain name infrastructure uses for those account records.
not only do ssl domain name certificates owe their existance to concerns about various integrity issues regarding the domain name infrastructure ... but the originating business process integrity of the ssl domain name certificates is dependent on the integrity of the domain name infrastructure ... one irony/catch22 is while ssl domain name certificates existance are dependent on concerns about domain name infrastructure integrity issues ... those certificates' integrity are based on the integrity of the domain name infrastructure (integrity).
so somewhat from the CA industry there are various suggestions to improve the integrity of the domain name infrastructure ... in order that the CA industry can depend on the integrity of the domain name infrastructure for the information that they manufacture into ssl domain name certificates. however, improving the integrity of the domain name infrastructure ... could also be viewed as reducing the concerns about domain name infrastructure integrity issues ... and therefor reducing the need for ssl domain name certificates.
from that standpoint ... the ca industry walks a fine line ... they want to have the integrity of the domain name infrastructure improved/sufficient so that people can trust the information in ssl domain name certificates ... but not improved so much as to obsolete the need for ssl domain name certificates.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 3745 & NCP Withdrawl ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 17 Jan 2003 14:25:55 GMTted.macneil@mobile.rogers.com (ted.macneil) writes:
i actually ran into a descendent of the box running in a large datacenter 4-5 years ago.
note that "network" is somewhat a misnomer .... sna lacked any network layer at all. the first instance slightly related to networking was appn; however the sna group non-concurred with the announcement ... which was held up for a couple months for escalation and announcement letter was rewritten so that there would be no confussion between sna and networking ... aka sna was oriented to managing the communication infrastructure of large number of dumb terminals.
slightly related issue was that there was some attempt long ago and far away ... to get the peachtree processer as a choice for 37xx rather than the uc.5 processor (which had significant impact on ncp implementation abilities).
there are all sorts of design and architecture trade-offs. the tcp/ip mainframe product imphlementation had an 8232 as a standard controller attachment box; however the choice of the protocol between 8232 and mainframe could have been better. that implementation could hit 44kbytes/sec consuming a full 3090 engine.
for the product, i supplied the rfc1044 support ... which used a different controller box and different choice of protocol abstraction. the rfc1044 support in the shipped produced used a very modest amount of 4341 processing hitting sustained thruput of channel speed (1mbyte/sec) ... 1/50th the cpu for 20 times the thruput (about three orders of magnitude difference).
random hsdt posts
https://www.garlic.com/~lynn/subnetwork.html#hsdt
slightly related saa, sna, & 3-tier posts:
https://www.garlic.com/~lynn/subnetwork.html#3tier
misc. rfc 1044 specific posts:
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/96.html#14 mainframe tcp/ip
https://www.garlic.com/~lynn/96.html#15 tcp/ip
https://www.garlic.com/~lynn/96.html#17 middle layer
https://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
https://www.garlic.com/~lynn/2000.html#90 Ux's good points.
https://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000f.html#30 OT?
https://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002.html#11 The demise of compaq
https://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
https://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
https://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
https://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 3745 & NCP Withdrawl ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 17 Jan 2003 14:41:43 GMTj.grout@COMPUTER.ORG (John R. Grout) writes:
major problem was that JES2 and nje had a design that improperly intermixed fields belonging to different protocol layers in a jumble in the nje header. an early problem was that slightly different versions of JES2 with slightly different NJE header formats ... in the same network ... could crash each other's mvs systems (very poor interoperability characteristics). JES2 also had a secondary problem that it didn't have ability to define all nodes in the internal network ... and a JES2 node would trash any data where either the origin or destination nodes weren't defined in the local table.
a combination of the trashing data ... and inability to support generalized interoperability ... restricted JES2 nodes to boundary positions on the internal network. the family of NJE drivers that grew up for vm/vnet included the responsibility for rewriting NJE header fields. There would be a specific NJE driver loader in VM/VNET for the line that corresponded to the JES2/NJE version level on the other end of the line. It was the responsibility of the vm/vnet NJE driver to make sure that all data flowing thru vm/vnet had the NJE header fields rewritten so they conformed to the exact JES2 version on the other end of the communication line (to avoid MVS system crashes).
it became so institutionalized that when MVS system crashes did occur ... because somebody had upgraded a MVS/JES2 system w/o notifying the VM/VNET node to change the VM/VNET NJE driver with new header rewrite rules ... it was the VM/VNET system that got blamed ... aka the fundamental problem was lack of MVS/JES2 interoperability support ... but it became so institutionalized that vm/vnet was used to keep mvs/jes2 systems from crashing ... that when mvs/jes2 did crash ... vm/vnet got blamed.
eventually they stopped shipping the native vm/vnet drivers with vm/vnet ... just shipping NJE drivers ... in part because the native vm/vnet drivers had significantly better thruput than the NJE drivers.
random bitnet/earn posts:
https://www.garlic.com/~lynn/subnetwork.html#bitnet
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why did they make FORTRAN so hard to parse? Newsgroups: alt.folklore.computers Date: Sat, 18 Jan 2003 17:46:04 GMTJoe Morris writes:
other random refs:
https://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
https://www.garlic.com/~lynn/2002f.html#48 How Long have you worked with MF's ? (poll)
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk drives as commodities. Was Re: Yamhill Newsgroups: comp.arch Date: Sat, 18 Jan 2003 21:14:27 GMT"M. Ranjit Mathews" writes:
the 2311s were dasd ... both the drives (about like a dishwasher, top-loading) and the packs (removeable) were called dasd. the 2311s were followed by 2314s (also removeable packs) and then 3330s (also removeable packs). precursor to 2311 was 1301. both the 2314 and 3330s were two high drawers which would slide out and the pack be mounted or removed.
the 2301s were also dasd ... these were fixed-head per track "drum" (rotating cylinder with tracks on the outside surface of the cylinder, somewhat akin to the old edison recording cylinders but larger and instead of moving head ... there was head per track). the 2301s were followed by 2305s.
the 2321 were also dasd ... this was more like a washing machine ... with ten (removeable) bins arraigned inside the washing machine drum ... each bin contained magnetic strips. the washing machine rotated under the read/write position until the appropriate bin was in position ... then it was possible to retrieve an appropriate strip from the bin and wrap it around the read/write head. sometimes when inserting a strip back into a bin, it would catch ... and be crumpled into something that look like fan-fold configuration.
these were frequently referred to as count-key-data ... and used a seven byte addressing scheme:
BBCCHHR DASD addressing
BB ... bin except for 2321 this field was all zero CC ... cylinder HH ... head R ... recordconvention on the spinning round&brown with moveable arm actuator ... two byte "BB" bin selector was zero, two byte "CC" selected arm position .. and two byte "HH" selected one of the heads once the arm was moved into position.
some stuff:
http://www.sdisw.com/dasd_capacity.html
the exclusive dominance of the platter (aka disk) shape wasn't until the '70s.
slightly related postings:
https://www.garlic.com/~lynn/2000.html#9 Computer of the century
https://www.garlic.com/~lynn/2002.html#22 index searching
https://www.garlic.com/~lynn/2002m.html#40 Wanted: the SOUNDS of classic computing
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Card Columns Newsgroups: alt.folklore.computers,comp.lang.pl1 Date: Sat, 18 Jan 2003 21:34:40 GMT"John W. Kennedy" writes:
for various (non-technical) reasons, tj watson was the only executive that managed to get all the different manufacturing lines/plants to "toe the line" and maintain compatibility (with 360).
there was some hypothesis that if only a single vendor managed to achieve that single, most important objective ... then, in theory, that vendor could do nearly everything else wrong and still be successful.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk drives as commodities. Was Re: Yamhill Newsgroups: comp.arch Date: Sun, 19 Jan 2003 15:32:06 GMTAnne & Lynn Wheeler writes:
BBCCHHR DASD addressing BB ... bin except for 2321 this field was all zero CC ... cylinder HH ... head R ... recordnote that this is still being used today and originated before i ran into it in '66 ... so has existed for dasd addressing for going on 40 years or so.
and as previously alluded to, the use of the term DASD is at least explainable from the standpoint that spinning platters weren't the sole form factor.
misc:
http://www.os390-mvs.freesurf.fr/mvshist1.htm MVS ... long history: os/360
from above:
Shmuel's note. OS/360 was not the first operating system to require
DASD. Burroughs B5000 (MCP), CDC 6600 (CIPROS), Ferranti Atlas and GE
625 (GECOS, later GCOS) all required DASD, to say nothing of IBM's own
DCS.
====
and some total thread drift. the above page references:
http://izgudrojumi.lza.lv/eng/izgudrotaji/PadegsA.asp
andris padegs web page. when cambridge/charlie was trying to get compare&swap instruction into 370 ... padegs and ron smith were the "owners" of the principles of operation. it was ron smith who directed that more justification was needed than just multiprocessor atomic instruction .. that a use in uniprocessor environment was needed. as a result, cambridge came up with the various uses of compare&swap instruction for multi-threaded application (whether they ran in uniprocessor a multiprocessor environment).
random dasd refs:
http://www.vm.ibm.com/pubs/cms420/DTFSD.HTML
http://joshua.raleigh.nc.us/docs/linux-2.4.10_html/385056.html
http://www.conmicro.cx/hercules/hercload.html
http://homepages.kcbbs.gen.nz/nbree/saga.html
http://www.conmicro.cx/hercos360/blddrv.html
http://www.os390-mvs.freesurf.fr/mvs360.htm
http://www.rjbuntenconsulting.com/biography.htm
http://www.punch-card.co.uk/3701.htm
http://www.softwarehistory.org/history/important_people.html
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Card Columns Newsgroups: alt.folklore.computers,comp.lang.pl1 Date: Sun, 19 Jan 2003 19:30:10 GMT"Russ Holsclaw" writes:
7094/ctss had 2741 support ... as well as cp/67.
at the university i implemented tty support in cp/67 ... with a peculiar
characteristic that later resulted in the following bug story (some
amount of the code i did at the university was picked up and distributed
as part of the standard product):
https://www.multicians.org/thvv/360-67.html
at:
https://www.multicians.org/thvv/tvv-home.html#stories
as part of the TTY support ... I attempted to extended dynamic terminal identification using the SAD command in the 2702 ... being able to change different line-scanner. 2702 short-coming was that while it was possible to dynamically associate different line-scanners with each line (both hard-wired & dial-up lines) ... they took a short cut and hired wired the oscillator to each line (could switch between the 2741 line-scanner and the tty line-scanner on the same line ... but couldn't dynamically change the baud rate).
this led to a project at the university to build our own controller
(supporting automatic terminal identification and automatic baud rate
identification) starting with reverse engineering the 360 channel
interface and putting it into an interdata/3 ... then extended to an
interdata/4 using interdata/3s as line-scanners. we since got blamed
for originating the 360 pcm controller business:
https://www.garlic.com/~lynn/submain.html#360pcm
later it was bought up and the boxes were sold under the perkin/elmer label.
in effect ... each of the (many) controllers in a typical mainframe operation tended to be full-fledge minis in their own right
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: paper tape input Newsgroups: alt.folklore.computers Date: Sun, 19 Jan 2003 19:38:44 GMTbfranchuk writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm