From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Tue, 10 Apr 2007 15:24:52 -0600 eugene@cse.ucsc.edu (Eugene Miya) writes: If that were true, then IBM would have stepped up to the plate and offered it. I suspect that Taylor, Kahn, Cerf and others would take issue with that. re: http://www.garlic.com/~lynn/2007g.html#84 The Perfect Computer - 36 bits? I'm waiting ... but while waiting for you to ask them to comment ... how 'bout sample of some RFCs references (from my RFC index) for some idea of the size of early arpanet: clicking on the the ".txt=nnn" field in the RFC summary, retrieves the actual RFC http://www.garlic.com/~lynn/rfcidx0.htm#293 293 - Network host status, Westheimer E., 1972/01/18 (3pp) (.txt=7639) (Obsoleted by 298) (Obsoletes 288) (Updates 288) http://www.garlic.com/~lynn/rfcidx0.htm#235 235 - Site status, Westheimer E., 1971/09/27 (4pp) (.txt=7994) (Obsoleted by 240) ... snip ... based on the stats in the various referenced RFC, the uptime of the early arpanet wasn't very good. since some number of the machines mentioned in the above RFCs, where ibm machines ... it should be obvious that SNA wasn't the only mechanism in use by ibm mainframes. In fact, SNA was primarily a master/slave terminal control infrastructure (aka "VTAM", virtual telecommunication access method ... somewhat terminal control follow-on to TCAM ... telecommunication access method) ... not really suited for doing peer-to-peer networking operations. and, in fact, SNA wasn't even announced until 1974: http://www-03.ibm.com/ibm/history/history/year_1974.html before that, there were (at least) two early internal network activities, 1) one was sometimes referred to as "SUN" ... os/360 batch oriented systems based on HASP (in large part growing out of the HASP network updates from TUCC) and 2) the work at the science center http://www.garlic.com/~lynn/subtopic.html#545tech with cp67 based implementation (between cp67 machines). Both of these didn't involve SNA ... and in fact, their origins predate SNA. The HASP-based network implementation actually suffered some of the same kind of limitations as the arpanet in terms of addressability and (mostly) requiring end-to-end homogeneous software operation of the network nodes; in the arpanet case, it was in the IMPs, while in the HASP case, all the support was in the mainframe, not outboard (the requirement for a separate, managed BBN box might even be considered one of the inhibitors to arpanet growth). The CP67 origin stuff was much more flexible, having a kind of layered gateway architecture (more akin to later internetworking protocol) ... and when a "HASP" gateway driver was created for CP67 ... the two groups/collections of internal machines then were able to form a common network. misc. past posts mentioning HASP, JES, HASP/JES networking implementation limitations, etc http://www.garlic.com/~lynn/submain.html#hasp eventually cp67/vm370 based infrastructure came to dominate the internal network (still not having anything to do with sna) ... and in fact was leveraged by the HASP/JES operations to provide format translations between different version/releases (of HASP/JES ... such incompatibilies were known to crash the respective MVT/SVS/MVS operating system, i.e. an intermediate cp67/vm370 node could be required to even allow two different HASP systems to communicate). misc. old email touching on the internal network http://www.garlic.com/~lynn/lhwemail.html#vnet for some completely random topic drift ... the primary person (associated with dataquest) doing the high-speed interconnect study for the ha/cmp scaleup activity, mentioned here: http://www.garlic.com/~lynn/2007g.html#81 IBM to the PCM market in relation to the work mentioned in these old emails http://www.garlic.com/~lynn/lhwemail.html#medusa had a decade earlier worked at Santa Teresa lab ... and a decade or so before that, as undergraduate at UCSB, had been hired to do network penetration testing (before the UCSB arpanet connection was activated) misc. past threads/posts where you've made similar comments on the subject: http://www.garlic.com/~lynn/2002b.html#53 Computer Naming Conventions http://www.garlic.com/~lynn/2002b.html#54 Computer Naming Conventions http://www.garlic.com/~lynn/2002b.html#56 Computer Naming Conventions http://www.garlic.com/~lynn/2002b.html#57 Computer Naming Conventions http://www.garlic.com/~lynn/2002b.html#58 ibm vnet : Computer Naming Conventions http://www.garlic.com/~lynn/2002k.html#19 Vnet : Unbelievable http://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable http://www.garlic.com/~lynn/2004g.html#26 network history http://www.garlic.com/~lynn/2004g.html#31 network history http://www.garlic.com/~lynn/2004g.html#32 network history http://www.garlic.com/~lynn/2004g.html#33 network history http://www.garlic.com/~lynn/2006j.html#45 Arpa address http://www.garlic.com/~lynn/2006k.html#8 Arpa address http://www.garlic.com/~lynn/2006k.html#9 Arpa address http://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 21st Century ISA goals? Newsgroups: comp.arch Date: Wed, 11 Apr 2007 09:52:42 -0600 Stephen Fuld <S.Fuld@PleaseRemove.att.net> writes: Lets look at the way that IBM mainframes do I/O for an example. I chose this because it is petty easy to explain, not that I think it is necessarily the best implementation. This is, of course a somewhat simplified description. just for the fun of it ... from a slightly different standpoint the 370/158 engine had two sets of microcode that were shared execution on the same processor ... the 370 microcode and the "integrated channel microcode" (that had support for up to six configured channels). for the "next generation" (after 370), the 303x ... they took the a 158 engine w/o the 370 microcode and packaged it as a independent box "channel director". A 3031 was a repackaged 370/158 with only the 370 microcode (and w/o the integrated channel microcode) and an external "channel director" (could be considered an two-processor SMP but with the two engines running different microcode). A 3032 was a repackaged 370/168 that could be configured with one to three external channel directors (for up to 16 channels). A 3033 started out as 168 wiring diagram mapped to faster chip technology.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Mainframe in 10 Years... Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 11 Apr 2007 10:42:04 -0600 abain@ibm-main.lst (Alan Bain) writes: I have been asked by my management as well as a couple of clients to try to predict the future of the mainframe. Although I have done some research and have talked to many client companies, I thought I would ask a very open ended question to this list since it is you who have your fingers on the true pulse. I also have enjoyed your many and varied responses to questions over the years and feel that this exercise may be informative as well as entertaining. So here goes: ref in post part of recent thread http://www.garlic.com/~lynn/2007g.html#81 IBM to the PCM market to older post containing summary of jun90 FORRESTER report "MAINFRAME R.I.P." http://www.garlic.com/~lynn/2001n.html#79 a.f.c. history checkup based on survey in mid-89 and some predictions out thru 99 doesn't sound like a lot has changed except possibly use of virtualization for server consolidation.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 21st Century ISA goals? Newsgroups: comp.arch,alt.folklore.computers Date: Wed, 11 Apr 2007 13:42:18 -0600 ChrisQuayle <nospam@devnul.co.uk> writes: Digging a bit further, one would assume that the channel commands and data / pointers are written to shared locations in memory by the driver or other os layer at some stage. That is, data and control must be setup somewhere prior to kicking off the i/o op. Then, the channel device uses dma or programmed io to get the data into the controller on exec of a channel instruction ?. If so, it's not too dissimilar in functionality to dec's (~ early 1980's) mscp disk protocol, where the os builds (from memory) linked lists of command/data descriptors in memory. The controller is told where to find the list head and the whole list is transferred by the controller using dma without further cpu intervention. slightly related previous post: http://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals? there were some differences ... the '60s flavor allowed that the program and/or data descriptors could be changed on the fly ... so there was a strict requirement for no prefetching (somewhat akin to very strong memory consistency in multiprocessor operation) the 60s had a lot more I/O capacity than there was real storage ... as a result there was trade-off keeping lots of file infrastructure on disk and use the disk-based infrastructure to control the channel program. a simple example was ISAM (indexed sequential access method) that would locate/search for particular record on disk (less-than, equal, greater-than, etc) ... then read the record that is to be argument to subsequent locate/search command in the same channel program. another example was long running channel programs ... a particular channel command word (CCW) could have the PCI flag set (program controlled interrupt) ... which would schedule an interrupt to the processor ... even tho the channel program hadn't completed. This gave processor code change to change subsequent parts of the channel program "on-the-fly" (either arguments and/or instructions). ISAM (or other implementations) channel programs could get even more complex ... not only changing arguments of subsequent commands ... but also changing the commands themselves (having read something from the device). the requirement for no prefetching ... in support of possible "on-the-fly" modifications .. placed some distance limitations on operations ... especially later when started looking at longer distance fiber extensions. for instance, even the record locate/search argument was refetched from (processor) memory as each record (on disk) was encountered ... so there some latency issues related to disk rotation. there was big deal made in 1980 when disk farm max channel cable length restrictions were doubled from 200ft to 400ft. sometime in the 80s ... larger clusters of processors sharing football sized arrangements of disk farms ... would sometimes start going to 3-d configurations ... because of channel cable distance limitations (related to end-to-end latency restrictions). Start with processors somewhat located in the center of disk farm expanse that possibly had 100yds radius ... and then go to 3-d multiple floor configuration with channel cable length restrictions starting to form an operational sphere. the storage size vis-a-vis i/o capacity trade-off changed in the 70s ... but you still had customers with configurations that had multi-cylinder file structure information (well into the 80s ... and possibly some continuing today). A full-cylinder "search" could take 1/3 sec. elapsed time ... and kept the channel resources dedicated the whole time because of the requirement to refetch the search argument on each record compare. some past posts discussiong effects of the characteristic and change in resource trade-offs w/o changing the implementation paradigm http://www.garlic.com/~lynn/submain.html#dasd the other thing that showed up in the 70s was the 1) increasing configuration size ... so a much higher probability of loaded systems and request queuing and 2) larger processors being built with processor caches. The asynchronous i/o interrupts could wreck havoc with cache hit ratios. The operating system resource manager that I released in the mid-70s had a hack that would dynamically tract the asynchronous i/o interrupts rate ... and at some threshold switch to dispatching tasks disabled for interrupts for short periods. This would slightly delay some i/o interrupts (and the associated processing, increasing i/o processing latency) ... but tended to improve application thruput and their cache hit ratio. It also had some tendency to result in interrupt batching (several i/o interrupts processed in series). This in turn tended to improve the kernel interrupt processing cache hit ratio ... and could even result in the avg. interrupt processing latency to decline. The other issue with high probability of queued requests would start showing up in "re-drive" latency becoming a measurable factor (i.e. latency between the time a pending i/o interrupt was processed and the next queued request was initiated) ... especially as the favorite son operating system became more and more bloated. To some somewhat address both issues, a queued initiation/termination interface was introduced in the early 80s with 370-XA (initially on 3081). Channel programs could be scheduled for initiation w/o the resource being available (360 SIO i/o initiation instruction was syncronized and interrogated availability of all resources ... clear out to the device ... prior to channel program initiation and proceeding with next instruction processing). The initiation could also specify that rather than an asynchronous interrupt on completion ... just update a defined control infrastructure. Actually, 370 (1970) first introduced an intermediate i/o initiation between the 360 SIO and the 370-XA start subchannel ... which was SIOF (sio "fast"). SIOF instruction would hand off the channel program to the channel but w/o waiting for interrogation delay clear out to the device (eliminating the "stall" associated with the SIO instruction). The 370-XA actual channel program execution still prevented prefetching and could still require the constant access to processor memory ... however initiation and termination of the channel program no longer required syncronized processor execution (eliminating the redrive latency and could be leveraged to minimize the detrimental effects of asynchronous interrupts on cache hit ratios). current description of operation http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/15.0?SHELF=DZ9ZBK03&DT=20040504121320 and since the operating system no longer was seeing exact operation initiation/termination ... some of the information gathered for dynamic resource management, reporting, and capacity planning was compromised ... so compensating processes and information gathering had to be added to the i/o subsystem http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/17.0?SHELF=DZ9ZBK03&DT=20040504121320 discussion of some of the make-over that changed from 370: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/F.3.2?SHELF=EZ2HW125&DT=19970613131822 I had first done something along these lines in 1975 when working on a 370 5-way smp machine (that was never announced/shipped). It had extensive microcode capability ... and I defined both a queued interface for disk i/o as well as a queued interface for dispatching/scheduling. Part of this was that it minimized some of the multiprocessor complexity ... no longer had to worry serializing which processor was doing a SIO for any specific channel at any specific time. Treat it purely as a multiprocessor multi-access shared storage control metaphor ... adding stuff and removing stuff from queues (microcode could worry about whether target processing unit was busy ... and would later get around to checking for additional work ... or was idle and had to be signaled to indicate arrival of new work). http://www.garlic.com/~lynn/submain.html#bounce
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 21st Century ISA goals?
Newsgroups: comp.arch
Date: Wed, 11 Apr 2007 14:10:22 -0600
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Indeed. And it caused a fair amount of trouble when IBM introduced
caches nearly a decade later. Now, exactly what has changed since
then?
somewhat long-winded
http://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals?
http://www.garlic.com/~lynn/2007h.html#3 21st Century ISA goals?
as to processor caches ... did the channel i/o processing require full
("multiprocessor") cache consistency support ... for commands, arguments,
and data.
i/o had to signal processor caches on all(?) storage alterations ...
and (especially store-into) caches had to possibly be interrogated for
all command fetches as well all i/o argument fetches (in some cases
there was little differentiation between what might be i/o command
control argument fetch ... and an i/o command data transfer fetch).
there sometimes have been strategies if it is purely data transfer
fetches ... during the i/o operation, unmap the related storage for
processor execution. However, if it is really stuff that can be
dynamically updated by either i/o transfer or processor during the
execution of the i/o operation ... then it requires much tighter
syncronization.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 21st Century ISA goals? Newsgroups: comp.arch Date: Wed, 11 Apr 2007 14:28:00 -0600 "MitchAlsup" <MitchAlsup@aol.com> writes: A) Design and implement a 486-class CPU with a modern x86-64 instructions set and embedd it into the SouthBridge chip. B) Extend the domain of cache coherence all the way out to the SouthBridge. C) Tweek the OS so that it schedules the I/O processes only on these tiny-little CPUs. re: http://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals? http://www.garlic.com/~lynn/2007h.html#3 21st Century ISA goals? http://www.garlic.com/~lynn/2007h.html#4 21st Century ISA goals? note with the 370-xa change over ... started using (independent) 801 processor chips to handle the extended channel control functions current i/o overview http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/13.0?SHELF=DZ9ZBK03&DT=20040504121320 i/o instructions http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/14.0?SHELF=DZ9ZBK03&DT=20040504121320 basic i/o functions http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/15.0?SHELF=DZ9ZBK03&DT=20040504121320 i/o interruptions http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/16.0?SHELF=DZ9ZBK03&DT=20040504121320 ... including all the additional statistical information ... since the actual sequence of individual events were being masked by the more sophisticated queued interface. i/o support functions http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/17.0?SHELF=DZ9ZBK03&DT=20040504121320
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 21st Century ISA goals? Newsgroups: comp.arch,alt.folklore.computers Date: Wed, 11 Apr 2007 15:10:55 -0600 Anne & Lynn Wheeler <lynn@garlic.com> writes: The other issue with high probability of queued requests would start showing up in "re-drive" latency becoming a measurable factor (i.e. latency between the time a pending i/o interrupt was processed and the nexted queued request was initiated) ... especially as the favorite son operating system became more and more bloated. part of long winded post http://www.garlic.com/~lynn/2007h.html#3 21st Century ISA goals? other posts in thread: http://www.garlic.com/~lynn/2007h.html#2 21st Century ISA goals http://www.garlic.com/~lynn/2007h.html#4 21st Century ISA goals? http://www.garlic.com/~lynn/2007h.html#5 21st Century ISA goals? so a little (long-winded) folklore about redrive latency and the (new) 3880 disk controller (late 70s). as before past posts getting to play in the disk engineering and product test labs http://www.garlic.com/~lynn/subtopic.html#disk the labs were doing all their testing with "stand-alone" machines ... i.e. dedicate, scheduled machine time with simple engineering test monitor software. In the past, they had attempted operation in operating system environment but had experienced 15min MTBF (with corporation's favorite son operating system). I undertook to rewrite an i/o subsystem to make it absolute bullet-proof ... allowing them to do on-demand multiple concurrent testing of engineering hardware. The disk labs. tending to get newest processors as they became available (processor developers would have the first engineering machine ... and the disk labs would get the 2nd or possibly 3rd engineering machine). As a result, the disk labs had significant processing power ... but it had been devoted to stand-alone testing. When I got i/o subsystem half-way bullet-proof ... they found themselves with operating system environment on their machines ... that had possibly 1-2% processor utilization (even with half-dozen engineering devices being tested concurrently). With all that extra processing power ... they initiated their own online interactive service ... scavenging some spare controllers and disk drives. The new generation disk controller under development was the 3880 ... it would have more features and also handle the enhanced syncronization (for the 400ft double length channel cables) and the coming ten times faster disk transfer (3mbytes coming with 3380 disk drives compared to the prior 3330 disk drives). The 3880 control processor was a vertical microcode cpu that was much slower than the horizontal microcode processor used in the previous generation 3830 disk controller. To somewhat compensate there was special hardware for data transfer. However, the control operations and command processing was significantly slower on the 3880 (compared to the 3830). So there was a requirement to show that the 3880 product was within five percent of the performance of the previous 3830 product. The command processing overhead was making the overall operation take much longer time (measure from what the processor saw). So to compensate ... they started doing some hacks ... realizing the redrive latency ... they took to signaling end-of-operation interrupt to the processor ... before the disk controller had actually finished doing all of the processing. At some point, somebody, somewhere ... ran a standard operating system product test suite against a 3880 controller and found test suite thruput to be within five percent of 3830 controller. Looks good? So one Monday morning about 10am, i get an upset call from the product test lab asking what I had done to their system over the weekend ... because their interactive service response had gone all to <somewhere> that morning (and, of course, they hadn't done anything over the weekend). so some amount of investigation, i find that they had replaced a 3830 controller on string of 3330s with a brand-new 3880 controller over the weekend. Turns out that my super enhanced i/o subsystem, also had an extremely short i/o redrive pathlength ... and I was getting around to I/O redrive (after i/o interrupt processing) before the 3880 controller had actually finished completely processing the previous operation. As a result, my I/O redrive was hitting the controller while it was still busy ... which then reflected a busy condition back to the processor. Now the processor had to go into a whole lot of extra processing and requeue the operation until the controller had signaled it was actually finallly not busy. The controller having been hit with an additional operation while it was still busy ... experiences a lot of extra processing ... which included having to signal a new interrupt when it finally was really "free" (having been forced to signal that it was really busy ... even tho it had previously signaled that it "completed" the previous operation, it then had to signal when it really was free). All this was fairly traumatic, effectively cutting disk i/o operations/sec thruput by at least half under moderate load. So now both the controller people and I have to see about work-arounds for the 3880 i/o redrive latency "problem" (they have to significantly cut their actual busy time that continues on after signaling finished with previous operation ... and/or i have to significantly delay how fast i get around to redriving operations after previous operation had signaled complete).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Mainframe in 10 Years... Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 11 Apr 2007 17:34:09 -0600 bdissen@ibm-main.lst (Binyamin Dissen) writes: ISAM did not "die". It changed into KSDS. Indexed-sequential access is used on almost every platform, some even now still called "ISAM". recent x-over from comp.arch mentioning ISAM: http://www.garlic.com/~lynn/2007h.html#3 21st Century ISA goals? other possible posts of interest in the thread: http://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals? http://www.garlic.com/~lynn/2007h.html#4 21st Century ISA goals? http://www.garlic.com/~lynn/2007h.html#5 21st Century ISA goals? some other recent posts mentioning ISAM and "self-modifying" channel programs ... and one of my first assignments after graduation was spending a week at customer site getting ISAM running in virtual machine under cp67 (and trying to get dynamic modifications reflected in the shadow channel program) http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007f.html#4 ISAM and/or self-modifying channel programs http://www.garlic.com/~lynn/2007f.html#34 Historical curiosity question previous post in this thread: http://www.garlic.com/~lynn/2007h.html#2 The Mainframe in 10 Years
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: whiny question: Why won't z/OS support the HMC 3270 emulator Newsgroups: bit.listserv.ibm-main Date: Fri, 13 Apr 2007 05:12:24 -0600 alan_altmark@ibm-main.lst (Alan Altmark) writes: I tell you 3 times: Yes. And XEDIT is way better than ISPF, too. And VM had TCP/IP first. And Rexx. Nyah. }:-) some old mainframe tcp/ip folklore ... the original implementation was done in vs/pascal ... but had some issues with its interface to external boxes. somewhat as a result, it would get about 40kbyte/sec aggregate thruput and could use a whole 3090 processor doing it. i did the rfc 1044 implementation and in some testing at cray research between a 4341 clone and a cray machine ... was getting 1mbyte/sec thruput using only a modest amount of the 4341 processor (i.e. about 25 times the aggregate thruput for about 1/20 the pathlength ... about 400-500 times difference in bytes/transferred per instruction executed). misc. past posts mentioning 1044 support http://www.garlic.com/~lynn/subnetwork.html#1044 the was "ported" to MVS and made available as a product by doing a vm kernel "diagnose" emulation for MVS (i.e. diagnose instruction use in vm is somewhat analogous to svc instruction in mvs). some really old folklore ... was that later there was a outside subcontract to implement tcp/ip support in vtam. the initial implementation came back with tcp support significantly faster than lu6.2 support. they were told that everybody knows that lu6.2 is much more efficient than tcp ... and therefor the only way that tcp implementation could be significantly faster than lu6.2 was if it was implemented incorrectly ... and the contract wouldn't be fullfilled unless there was a "correct" tcp implementation. past post reference http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes http://www.garlic.com/~lynn/2006f.html#13 Barbaras (mini-)rant http://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 21st Century ISA goals?
Newsgroups: comp.arch
Date: Fri, 13 Apr 2007 06:18:58 -0600
"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:
On S/360 this evolved from parallel channels, (fiber) ESCON, and now
FICON (basically Fibre Channel with a different top protocol layer),
which mostly impacted only the physical connections. There was one
major change in the I/O instructions themselves (which decoupled
channels from device addressing - so in stead of saying start I/O on
channel 6, device 13, it's now start I/O on device #12345, and the
system finds a channel with a path to that device that's not currently
busy), but the channel programs have largely stayed unchanged (so a
channel program for a 1964 2314 disk drive would work on a modern 3390
so long as you adapted it for the different track sizes, head counts,
and cylinder counts - although there are certainly enhancements you
could take advantage of on the newer driver which *would* require new
channel programs). This parallels SCSI, which has been implemented on
numerous physical interfaces (most obviously several versions of old
parallel SCSI, FC and SAS, but also over things like USB and IDE
connections for non-harddisk devices), but has retained the same
command set within the packets sent over those interfaces.
some real dynamic pathing topic drift.
In late 70s I had started commenting that the relative system thruput
of disks had been declining significantly (i.e. the processor and
memory were getting bigger/faster ... faster than disks were getting
faster). By the early 80s, I claimed that over a period of approx. 15
yrs, relative system disk thruput had declined by a factor of ten
times.
This upset some in the disk division, and the organization's
performance and modeling group was assigned to refute the
claims. After a couple weeks they come back and said that I had
actually understated the situation (it was actually somewhat worse).
So part of the issue was that the whole channel/controller/disk
infrastructure required dedicated "connection" during most of channel
program execution. Channel could theoretically executed multiple
channel programs at a time ... but only if there was a "solid" channel
connection. In 360, provisions were made for stand-alone "seeks"
(i.e. disk arm movement) to disconnect from the channel as soon as the
cylinder address had been transferred. This allowed for multiple disks
to be connected to the same channel and have concurrent arm motion
going on.
There was still the issue of disk rotation where no data was actually
being transferred ... but the channel/controller were
reserved/dedicated. For 370 (3830 controllers and 3330 disk drives),
"rotational position sensing" (RPS) was introduced along with the "set
sector" channel command. This allowed for a disk channel program to
disconnect from the channel while the disk was rotating to the correct
position for reading/writing a desired record (allowing other devices
to utilize the channel). The problem was that when the rotation got
into position, the disk had to "reconnect" ... if the channel was
busy, the disk would rotate past the start of the record and would
have to have a full, complete rotation to try again. This was called
"RPS-miss". My 15 yr period including the transition from 360 to 370
and the introduction of "RPS" and "RPS-miss".
Some rule-of-thumb configuration grew up that channel loading had to
be kept to 30percent or less ... in order to minimize RPS-miss
(i.e. rotating disks trying to dynamically reconnect to the channel).
So we roll forward to 3880. Not only did I run into problem with
device "redrive" hitting the controller while it was busy
http://www.garlic.com/~lynn/2007h.html#6 21st Century ISA goals?
but I had also done a superfast "dynamic pathing" algorithm purely in
software.
Disk controllers supported multiple channel connections ... which
could be used to connect to multiple different processor complexes
("CEC") for loosely-coupled (cluster) operation ... and/or connect to
multiple different channels for the same CEC (for
availability/thruput).
So standard multiple path support (processor complex with multiple
different channels to the same disk controller) tended to be
implemented as a primary with one or more alternates. When I was doing
I/O supervisor rewrite for the engineering and product test labs ...
lots of past posts
http://www.garlic.com/~lynn/subtopic.html#disk
I also did a highly optimized implementation of dynamic pathing with
load balancing (as opposed to primary/alternate). However, in the
transition from 3830 controller to 3880 controller this ran into
another kind of "busy" problem.
Turns out one of the other optimization done in the 3880 controller
microcode (to compensate for the slowness of the processor) was that a
lot of status was cached regarding the channel interface in use. The
3880 thruput and busy was significantly better if operations came in
thru a single (channel) interface. Starting to hit the 3880 randomly
from lots of different channel interfaces ... blew its "caching" and
significantly drove up the controller busy everytime it had to switch
from one interface to another. This additional overhead was so
significant ... that primary/alternate strategy had significantly
better thruput than dynamic load-balancing across all (available)
interfaces. misc. past posts mentioning experience redoing the
multi-path support (in software)
http://www.garlic.com/~lynn/2004d.html#65 System/360 40 years old today
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2006v.html#16 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2007.html#44 vm/sp1
So one of the other things that 370-xa i/o interface did was move the
"dynamic pathing" under the covers ... into what was sometimes called
"bump" processing/storage (i.e. new "hardware" function that sat
between the kernel drivers and the previous 360/370 channel
interface).
Separate from that is the whole continuing saga of the excessive 3880
controller busy overhead ... which spilled over into increased channel
busy (since a lot of the increased 3880 processing occured during
dedicated controller/channel handshaking).
The 3090 was built using a few number of TCMs ... each TCM represented
a significant part of the 3090 manufacturing cost. There was a lot of
work on balanced configuration to maximize 3090 thruput ... this
included having sufficient number of disks and channels (at avg. of
30percent busy or less ...harking back to the whole RPS-miss
description). The early 3090 configuration specification was done
effectively using 3830 disk controller characteristics. It eventually
dawned that with the significant increase in channel busy when talking
to 3880 (rather than 3830) ... that 3090 would require a lot more
channels (in order to try and meet the 30percent avg busy threshhold
requirement and minimize contention and problems like RPS-miss). It
turns out in order to add the additional channels, an additional TCM
would have to be used in every 3090. There were some snide remarks
that the "manufacturing cost" of an additional TCM in every 3090
should be billed against the 3880 disk controller organization and not
the 3090 processor organization. misc. past posts mentioning 3880
busy resulting in having to increase number of 3090 TCMs
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2002b.html#3 Microcode? (& index searching)
http://www.garlic.com/~lynn/2004n.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
Now processor-side "dynamic pathing" only addressed half of the
problem (at least for disks) ... which was find any available channel
path to the controller to initiate the operation (although with 3880
disk controller, if the dynamic pathing got too fancy, as i found out
with software, it could actually degrade thruput as compared to
simpler primary/alternate strategy). However, once started, channel
programs were bound to the initiating channel interface.
There was still the possibility of doing dynamic pathing (in the
reverse direction) to try and help address the "RPS-miss" situation
... i.e. dynamic path from the controller to channel on "reconnect"
when disk had rotated into position ... which would require a lot more
processing smarts in the disk controller ... and also a way of
indicating to the disk controller ... which of the channel paths were
grouped to the same CEC. This was something for later, more efficient
disk controller implementations (and more smarts on the processor side
to realize that a channel program was reconnecting on a different
channel). The channel program and channel commands can stay the same
... the "definition" of channel reconnect (for the controller)
changes.
other posts in this thread:
http://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals?
http://www.garlic.com/~lynn/2007h.html#3 21st Century ISA goals?
http://www.garlic.com/~lynn/2007h.html#4 21st Century ISA goals?
http://www.garlic.com/~lynn/2007h.html#5 21st Century ISA goals?
misc. past posts mentioning RPS-miss
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#46 MVS History (all parts)
http://www.garlic.com/~lynn/2002b.html#1 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002i.html#18 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms
http://www.garlic.com/~lynn/2004e.html#16 Paging query - progress
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s
old posts mentioning making claims about relative system disk thruput
drastically declining over the years
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2004n.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005f.html#55 What is the "name" of a system?
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#27 oops
http://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After Multi-Core?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Fri, 13 Apr 2007 07:08:42 -0600 jmfbahciv writes: A little history...size was The Issue back then. Everybody's fields had been defined to be too small. <snip> I think the comment is don't feed the troll I had included a simple statement that internal network was larger than the arpanet/internet from just about the beginning until possibly mid-85. http://www.garlic.com/~lynn/2007g.html#84 The Perfect Computer - 36 bits? there was a post that seemed to imply that there was some question regarding the assertion about the relative sizes of the internal network and the arpanet ... "from just about the beginning" ... and there was some specific names that might possibly contest the assertion. i then posted reply with some references that gave indication about the size of the early arpanet (as well as some of the dynamics driving the internal network implementation) ... of course, lets not reference RFCs with real specifics http://www.garlic.com/~lynn/2007h.html#0 The Perfect Computer - 36 bits and then there is a post seeming to imply that there was a discussion about something other than size. similar threads have happened before ... from the references to older posts related to the internal network subject (included in previous post) .. things like reference to some comment about specific period in time ... and then response comes back that the discussion was really about some totally different subject, date, and/or place. for other drift ... some of the ipv6 discussion was about the size increase in the address field. also a lot of y2k was about legacy applications and systems that were still around ... and had saved a few bits in the date by only using two digit year field. some old email about date processing http://www.garlic.com/~lynn/99.html#233 Computer of the century http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K) http://www.garlic.com/~lynn/2000.html#0 2000 = millennium? http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history... http://www.garlic.com/~lynn/2006r.html#16 Was FORTRAN buggy? In the reference to some of the HASP networking implementation (i believe originating at TUCC) ... they had leveraged a one-byte field that had been used to define "psuedo" unit record devices. This was also used to support a lot of telecommunication unit record devices (card readers, printer, punches at remote locations). This telecommunication support was deployed and used in large number of customer shops (i.e. lots of customer sites with single processor supporting one or more remote sites over telecommunication lines). The incremental enhancement was then to take that support and extend it to talk to other HASP systems. As a result, the single one-byte field was then being used to "address" psuedo-devices, remote telecommunication devices, as well as other hosts in the same network. This was a particular problem for most customers, since they tended to only have a limited number of hosts ... and the issues of cross-domain (cross corporate) interconnect was still quite a significant issue. However, there was (at least) one company with hundreds and then thousands of mainframes installed for internal use ... where inter-corporate jurisdictional issues wouldn't inhibit interconnecting processors. As previously mentioned, the HASP implementation had short comings where different versions of HASP (& then JES) couldn't interoperate ... and could require VNET intermidiate node to do format conversion (as countermeasure to prevent format incompatibilities resulting in whole system crashes ... shudder to think about what a hostile operational environment could do and things like denial of service attacks). However, the other HASP implementation issue was that since all definitions had to identified by that single byte ... 255 max. possible that included all psuedo devices ... a large HASP configuration could have 60-80 definitions and possibly several remote telecommunications devices ... the number of network node definitions might be as few as 150. This wasn't a problem for most closed corporate environments of the period ... but there was at least one where it was a significant problem. Also, it wasn't unusual for a corporation to keep all its HASP systems at the same version ... doing syncronized upgrades across a limited number of machines. However, syncronized upgrades doesn't scale well as the number of nodes increase significantly. The saving grace was the implementation originated at the science center for cp67. http://www.garlic.com/~lynn/subtopic.html#545tech Not only could it be used to handle the HASP/JES version interoperability problem ... but it didn't have the addressing limitation and could address the complete network. HASP/JES nodes then tended to migrate to boundaries ... with configuration definition that could only address some specific 100-200 node subset of the complete network. http://www.garlic.com/~lynn/subnetwork.html#internalnet
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Fri, 13 Apr 2007 08:07:00 -0600 Anne & Lynn Wheeler <lynn@garlic.com> writes: However, the other HASP implementation issue was that since all definitions had to identified by that single byte ... 255 max. possible that included all psuedo devices ... a large HASP configuration could have 60-80 definitions and possibly several remote telecommunications devices ... the number of network node definitions might be as few as 150. This wasn't a problem for most closed corporate environments of the period ... but there was at least one where it was a significant problem. Also, it wasn't unusual for a corporation to keep all its HASP systems at the same version ... doing syncronized upgrades across a limited number of machines. However, syncronized upgrades doesn't scale well as the number of nodes increase significantly. re: http://www.garlic.com/~lynn/2007g.html#84 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#0 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#10 The Perfect Computer - 36 bits? this also appeared to be a similar issue with the arpanet BBN box implementation ... in some of the past posts I've referenced RFCs with box downtime schedules across the whole arpanet where maintenance and software upgrades needed to be done and some of the software changes appeared to require coordinated maintenance across the whole infrastructure. This is not only an network interoperability issue between different boxes ... for the arpanet, there was none of these kinds of interoperability issues since there was only one kind of box ... but also the interoperability issue of different software versions. If you keep all the networking software the same (both the boxes and the versions) ... then interoperability (homogenous/heterogeneous) issues can be eliminated ... although you still can have significant scaling issues if you have to keep the software version of all the boxes coordinated. Supporting interoperability and eliminating the coordinated, homogeneous infrastructure operations ... helps with scaling ... since you no longer have to worry about keeping all boxes in coordinated sync. at all times. From an operational standpoint ... different implementations from different organizations ... all being able to interoperate was something of a mid-80s happening for the arpanet/internet. The internal network faced it very early since 1) the cp67 and hasp implementations were totally different and came from totally distinct background and organizations (in fact, a lot of the early hasp networking base implementation even originating outside the company). 2) both cp67 and hasp implementations were part of the mainframe software (not a separate box). the individual datacenters around the world controlled the maintenance, support, and release/version transition schedule of the mainframe software in their datacenters ... and might have very little coordination with the rest of the world. As a result there was a wide variation in the release/version of the different software being run around the world (there wasn't the luxury of a separate box that could have centralized, coordinated support). the base interoperable orientation of the networking software started at the science center eliminated needing to have coordinated, centralized support for world-wide operation (not only for the cp67/vm370 systems, but also for the hasp/jes systems). This was critical for the network size scalling. re: http://www.garlic.com/~lynn/subnetwork.html#internal
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Fri, 13 Apr 2007 12:46:01 -0600 jmfbahciv writes: In 1980, X25 was moving target. Nobody could implement anything and ship it (our development cycles were about two years/major software project). Perhaps you should get all the revisions of the specs that happened during those years. The guy who was trying to implement X25 was ready to shoot France. later in the '80s ... sort of between the time that we had gotten prevented from bid on the nsfnet backbone (even tho we had determined backing/support from NSF) http://www.garlic.com/~lynn/lhwemail.html#nsfnet and the time we were out pitching 3-tier architecture and middle ware/layer http://www.garlic.com/~lynn/subnetwork.html#3tier my wife did short stint as chief architect for Amadeus. she was backing x.25 for their world-wide operation ... but the SNA forces were instrumental in getting her replaced. it didn't do them much good, Amadeus went with x.25 anyway. misc. past posts mentioning Amadeus http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s? http://www.garlic.com/~lynn/2001g.html#50 Did AT&T offer Unix to Digital Equipment in the 70s? http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ? http://www.garlic.com/~lynn/2003d.html#67 unix http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe? http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads http://www.garlic.com/~lynn/2004m.html#27 Shipwrecks http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL) http://www.garlic.com/~lynn/2004o.html#29 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back http://www.garlic.com/~lynn/2006o.html#4 How Many 360/195s and 370/195s were shipped? http://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy? http://www.garlic.com/~lynn/2006y.html#14 Why so little parallelism? http://www.garlic.com/~lynn/2007d.html#19 Pennsylvania Railroad ticket fax service http://www.garlic.com/~lynn/2007e.html#52 US Air computers delay psgrs
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Question on DASD Hardware Newsgroups: bit.listserv.ibm-main Date: Fri, 13 Apr 2007 13:34:06 -0600 starsoul writes: I have a general question. Does anyone know where I can find information about how often a disk needs to be replaced or does dynamic sparing inside these new fangle DASD Boxes from IBM, EMC, or Hitachi? I am not talking about the mainframe dasd itself. But rather the disk in the box that the mainframe dasd is mapped (?) too? I have heard that a CE has to replace at least 1 disk per month on some of these boxes. (DMX3000 - EMC, DS8000 - IBM, etc....) So I guess I am looking at MTTF for the disk. here is some MTBF numbers of some disks http://www.digit-life.com/articles2/storage/maxtor15k2.html in the million-plus hrs. however, there has been some recent articles on how accurate published numbers might really be (and/or what the distribution actually works out to be) Hard disk test 'surprises' Google http://news.bbc.co.uk/2/hi/technology/6376021.stm Google Releases Paper on Disk Reliability http://hardware.slashdot.org/hardware/07/02/18/0420247.shtml Failure Trends in a Large Disk Drive Population http://labs.google.com/papers/disk_failures.pdf there have been articles in the past about disk MTBF can be highly skewed (some very early ... and then very late ... as opposed to any sort of even or random distribution).
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: conformance
Newsgroups: alt.religion.kibology,alt.folklore.computers
Date: Fri, 13 Apr 2007 14:41:09 -0600
Glenn Knickerbocker <NotR@bestweb.net> writes:
Exactly. And the former can't exist in a CMS file.
cms implements (in os semantics) "FIXED" record format file ... i.e. file
descriptor says that the file is recfm=F and the fixed record length of
each file (LRECL=80 ... effectively card format) ... and "VARIABLE"
record format file ... i.e. file descriptor says the files is recfm=V;
each record is preceeded by half-byte, file infrastructure "metadata"
given the length of the record following (not seen by the application).
this has somewhat been discussed in some of the buffer overflow threads
... about using "in-band" NULL characters as indicating end-of-line (and
therefor implicitly indicating line length) ... as opposed to recfm=V
used explicit (out-of-band infrastructure metadata) field for line
length.
http://www.garlic.com/~lynn/subintegrity.html#overflow
the various terminal/wire characters CR/LF (carriage-return and/or
line-fee) are terminal "control" constructs.
CMS deals with "virtual" 1052-7 (old style 360 machine console) for
line-mode terminal (with some special stuff for "full-screen" 3270).
CR/LF characters then get mapped into 1052-7 equivalent ... and
typically CMS would parse the "incoming" emulated terminal line/wire and
strip out terminal control characters.
The recfm=F, lrecl=80 file format is obviously inheritance from physical
card format. terminal/wire lines would typically/frequently get mapped
into recfm=V file format.
discussion of implementation of a POSIX compliant file system
"known" as the BYTE FILE SYSTEM (BFS) for CMS
http://www.redbooks.ibm.com/abstracts/SG244747.html?Open
reference to CMS now having support for (traditional
mainframe) RECFM=F, RECFM=V, RECFM=U, and also RECFM=D
("ascii variable length records")
http://www.vm.ibm.com/pubs/cms440/TVISECT.HTML
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: asymmetric cryptography + digital signature Newsgroups: sci.crypt Date: Fri, 13 Apr 2007 15:12:54 -0600 "Giorgio" <nacci.giorgio@gmail.com> writes: i need to send crypted signed data and i'm having some architectural doubt. The question is: does operations order affect security? I saw alot of schemas in which the process is described in the order: 1) Message -> signature (encrypted with private key) -> append signature to message -> encrypt with public key -> send. Instead doing operations in this order: 2) Encrypt message with public key -> signature of encrypted message (encrypted with private key) -> send distinctly encrypted message and signature. Mode 2) seems more efficient cause receiver doesn't need to decrypt the message if signature isn't verified, but i don't know if there are security issues in doing so. in general encryption is used to hide the information and digital signature is used for both 1) integrity of the message (i.e. it hasn't been modified) and 2) authentication/origin in some cases, the cleartext is digitally signed (first) ... in an attempt to imply that the digital signature is also associated with the meaning of the cleartext (as opposed to simply providing integrity and authentication) ... and/or the cleartext already carries a digital signature as means of integrity/authentication ... independent of whether it is going to be transmitted. and in reality ... (for efficiency) many infrastructures actually generate a random symmetric key ... encrypt the message with the symmetric key and then encrypt the symmetric key with the recipients public key. then, in the case of email to multiple recipients ... all you have to do is encrypt the symmetric key with the public key of each of the recipients (as opposed to having a separately encrypted copy of the full message for each recipient). on the recipient's side ... if the digital signature is on the cleartext ... then it is possible for the recipient to keep the unencrypted/cleartext message along with the digital signature for longterm integrity/authentication. If the digital signature is on the encrypted message ... if future/longterm authentication/integrity (of the content) is needed ... then the full encrypted message has to be also retained. Then to have ongoing high assurance as to the authentication/integrity, could require the digital signature (of the encrypted message) verified on each use ... followed by message decryption (compared to just having to reverify the digital signature of the cleartext message).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: conformance Newsgroups: alt.religion.kibology,alt.folklore.computers Date: Fri, 13 Apr 2007 17:03:25 -0600 ArarghMail704NOSPAM writes: half-byte ? Makes for an rather short line. :-) Probably meant half-word. (16 bits), IIRC that's what recfm=V uses. re: http://www.garlic.com/~lynn/2007h.html#14 conformance yep, oh well, brain check ... even when i had done the tty/ascii terminal support for cp67 in the 60s when i was an undergraduate ... the subsequent problem mentioned in these posts, involved "one byte" length arithmatic. http://www.garlic.com/~lynn/2007g.html#37 The Perfect Computer - 36 bits? also mentioned in the stories here http://www.multicians.org/thvv/360-67.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: MIPS and RISC Newsgroups: comp.arch Date: Fri, 13 Apr 2007 21:03:24 -0600 "MitchAlsup" <MitchAlsup@aol.com> writes: RICS is the name given to the whole genré of this style of computers. MIPS is an architecture from this genré that began as research at Stanford, and then spawned a company to design and manufacture industrial strength version of the acedemic architecture. The first generation (looseley) consisted of MIPS, SPARC, Motorola Mc88000, IBM ??, and Intergraph Clipper. The second generation added HP PA-RISC, ALPHA, IBM Power, and mabe a couple more. all the 801 stuff ... lots of past posts mentioning 801, iliad, romp, rios, fort knox, somerset, etc ... lots of past posts http://www.garlic.com/~lynn/subtopic.html#801 even some old email http://www.garlic.com/~lynn/lhwemail.html#801 maybe 2nd generation was various iliad note here on john: http://domino.watson.ibm.com/comm/pr.nsf/pages/news.20020717_cocke.html 801 wiki page: http://en.wikipedia.org/wiki/IBM_801 i've periodically claimed that (at least some) motivation behind 801 was to go to the opposite extreme from the extreme complexity of the (failed/canceled) Future System project http://www.garlic.com/~lynn/submain.html#futuresys somewhat after 370 fort knox activity in endicott was killed, there were some number of engineers that had worked on 801 efforts ... show up at other companies ... amd (29k), hp (snake). there is folklore that one of prime people showup on snake had given 2weeks noticed ... and then spent the last two weeks on blue iliad. somewhat separate from the 801 iliad stuff was 801 romp ... which started out as joint effort between research and office products for 801-based (cp.r, pl.8, etc) displaywriter follow-on. when that was killed they somewhat looked around and decided to turn it into a unix workstation ... which was released as pc/rt. Then work started on rios chipset (i've got a rios chipset paperweight that says 150 million ops, 60 million flops, 7 million transisters) ... which come out as "power" and rs/6000.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sat, 14 Apr 2007 11:41:00 -0600 jmfbahciv writes: We aren't using DECnet because it was too little too late. They took 10 f**king years to approve and implement functionality that TOPS-10 started shipping in 1976 or 1978. If the review process had passed and implemented Phase IV by 1980, TCP/IP would be in the folklore, not DECnet. post from last yr mentioning that wecker had worked on cp67 and virtual machines (i ran into him a number of times in this era) http://www.garlic.com/~lynn/2006m.html#21 The very first text editor post also mentions that by the end of '76, 16percent of the burlington mall dev. group were working for DEC ... aka result of POK getting approval to kill off vm370/cms product, shutdown burlington location, needing to move all the people to POK to support MVS/XA development. using search engine for decnet and wecker turns up lots of references ... include some mentioning Wecker as originator of DECnet (need login for following) http://ieeexplore.ieee.org/iel1/35/4759/x0321428.pdf others just say he was one of the architects of DECnet. misc. recent posts http://www.garlic.com/~lynn/2007h.html#0 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#10 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#11 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#12 The Perfect Computer - 36 bits? for other drift ... by the early 80s, the descendent of the network support originated at the science center http://www.garlic.com/~lynn/subtopic.html#545tech was starting to just ship the jes2 "gateway" drivers ... and stoped shipping any of the native drivers ... among other things, the native drivers performed/operated significantly better than the jes2 driver ... corporate decision to minimize comparisons(?). It was in this era that saw the start of bitnet using the product ... lots of past posts mentioning bitnet (and/or earn, its eurpean counterpart) http://www.garlic.com/~lynn/subnetwork.html#bitnet some old email from the person responsible for EARN in Europe http://www.garlic.com/~lynn/2001h.html#email840320 http://www.garlic.com/~lynn/2006w.html#email850607 Also, slightly later in this era, the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet passed 1000 nodes (and the internal network continued to utilize "native" drivers) http://www.garlic.com/~lynn/internet.htm#22 http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes) http://www.garlic.com/~lynn/2006k.html#3 Arpa address http://www.garlic.com/~lynn/2006k.html#8 Arpa address before jes2 revamp to support up to 1000 nodes (from its implementation based on HASP 1byte index table that had to be shared with several other functions) ... and later the internal network passed 2000 nodes before jes2 upgrade to support 1999 nodes. lots of past hasp/jes2 posts http://www.garlic.com/~lynn/submain.html#hasp
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Working while young Newsgroups: alt.folklore.computers Date: Sat, 14 Apr 2007 12:00:13 -0600 Car keys could go the way of tail fins http://news.com.com/Car+keys+could+go+the+way+of+tail+fins/2100-11389_3-6176121.html i learned to drive on an old flatbed truck the summer i turned nine. it had a pedal on the floor used to engage the starter motor (and all shifting was double clutch)past posts: http://www.garlic.com/~lynn/2002i.html#59 wrt code first, document later http://www.garlic.com/~lynn/2004c.html#41 If there had been no MS-DOS
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sat, 14 Apr 2007 14:20:02 -0600 Morten Reistad <first@last.name> writes: The two applications are X.509 and IS-IS. They work because the Internet needed them. i was at a sigmod conference in the early 90s and the question of what was all this x.50x stuff came up in a session ... and somebody explained it as networking engineers trying to re-invent 1960s database technology. later when we were consulting for this small client/server startup that wanted to do payments on their server ... they had this technology called SSL that required digital certificates. http://www.garlic.com/~lynn/subpubkey.html#sslcerts we also coined the term "comfort certificates" ... described in some of the referenced posts (a lot of them existing to make you feel better). We had to do a lot of auditing of various businesses associated with the digital certificate stuff ... somewhat as a result, we coined the term certificate manufacturing to differentiate from the stuff called PKI that was normally found in the literature associated with x.509 http://www.garlic.com/~lynn/subpubkey.html#manufacture the other issue was that by the mid-90s a lot of institutions were starting to realize that the earilier "identity" x.509 work (typically overloaded with a lot of personal information) represented significant privacy and liability issues. as a result there was quite a bit of retrenchment to what was called relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo however, it was normally trivial to demonstrate that rpo-certificates were redundant and superfluous. that nearly everything that could be done with rpo-certificates could be achieved with much simpler infrastructure, still involving digital signatures ... but w/o the enormous expense and trouble of digital certificates http://www.garlic.com/~lynn/subpubkey.html#certless old email suggesting/describing a simple certificate-less public key operation http://www.garlic.com/~lynn/2006w.html#email810515 some recent posts about vulnerabilities related to the existing SSL operation http://www.garlic.com/~lynn/2007f.html#31 Is that secure : <form action="https" from a local HTML page ? http://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks make the news http://www.garlic.com/~lynn/aadsm26.htm#56 Threatwatch: MITB spotted: MITM over SSL from within the browser
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: asymmetric cryptography + digital signature Newsgroups: sci.crypt Date: Sat, 14 Apr 2007 14:36:16 -0600 "Giorgio" <nacci.giorgio@gmail.com> writes: What really worries me about using "encrypt then sign" scenario is the possibility to read the signature (you just need public key) and the corresponding message togheter. I'm thinking about how easy (relatively; well, not so easy, but much easier then cracking crypting function) could finding a collision be. Am I wrong? If I'm not then integrity is lost, right? if that were serious ... then the whole digital certificate infrastructure might collapse. built into every browser is a whole lot of clear-text messages containing public keys along with digital signatures ... which happen to be called "digital certificates". these are the things nearly all SSL operates from. if there are significant vulnerabilities as you describe ... then the whole SSL infrastructure might come crashing down. previous post: http://www.garlic.com/~lynn/2007h.html#15 asymmetric cryptography + digital signature unrelated recent message ... that happens to mention different kind of vulnerability with ssl infrastructure http://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sun, 15 Apr 2007 09:46:08 -0600 Morten Reistad <first@last.name> writes: Yep, X.509 has degraded to non-security. Not because of the standard itself, which is workable but overly complicated. There is no auditing. Having a certificate proves absolutly nothing. So the whole house falls down. re: http://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits? the other issue is that digital certificates were a offline paradigm ... electronic emulation of credentials, certificates, licenses, etc ... essentially analogous to the letters of credit/introduction from the sailing ship (and earlier) days. they are useful to relying parties that have no other information about the entity. the x.509 identity digital certificates were billed as security feature ... which requires quite a bit of funding to cover the costs of audit, compliance, etc. however, in an online world, real-time, online information is significantly more valuable to relying parties ... than stale, static certificates. besides the privacy and liability issues with identity digital certificates grossly overloaded with personal information ... relying parties having growing access to (the much more valuable) online, real-time information ... starts to move digital certificates to the no-value market segment (i.e. applications that can't justify cost of online, real-time information). The problem then becames difficulty of justifying high prices in the no-value market segment ... and w/o a lot of revenue flow ... it is difficult to cover costs of stringent security features, audits, compliance, etc. so another aspect is that the whole digital certificate paradigm was targeted at a rapidly disappearing market segment ... with expanding, online, ubiquitous connectivity. we were called into consult with the small client/server startup that had ssl ... that wanted to do payment transaction on servers http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 was is now frequently referred to as electronic commerce. part of the issue is the ssl domain name digital certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert are being payed for by merchants ... supposedly in support of this electronic commerce stuff. the value of certificate is bounded by the fact that the merchants are already paying a significant amount on every transaction for real-time infrastructure ... and, in fact, had been for a couple decades prior to the appearance of SSL. In this period there were some number of x.509 advocates making statements about digital certificates being required to bring payment infrastructure into the "modern" era. We would respond that the offline paradigm offerred by digital certificates actually reverts the electronic payment infrastructure several decades. It was not too long after that, there was work started on OCSP (online certificate status protocol) ... which is another rube golberg type hack ... (along with relying-party-only certificates) that attempts to demonstrate an online infrastructure but attempting to preserve the fiction of (stale, static, redundant and superfluous) certificates serving a useful purpose in an online world. of course ... my oft reference old post about security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 and more recent posts concerning "armored" payments and transactions ... i.e. providing end-to-end strong authentication and integrity http://www.garlic.com/~lynn/x959.html#x959 ... but w/o enormous payload and processing bloat http://www.garlic.com/~lynn/subpubkey.html#bloat i.e. the payment protocols from the period that demonstrated appending digital certificates to payment transactions ... were sending (stale, static) information back to the relying party, when the relying party already had the real-time copy of the information (i.e. redundant and superfluous) ... however, these stale, static, redundant and superfluous digital certificates were increasing the payload transaction size and processing by two orders of magnitude. it was somewhat out of this experience that we did the certificate-less http://www.garlic.com/~lynn/subpubkey.html#certless digitally signed financial transaction standard http://www.garlic.com/~lynn/x959.html#x959 i.e. can have end-to-end integrity and authentication without having the enormous bloat of stale, static, redundant and superfluous appended digital certificates.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: MIPS and RISC Newsgroups: comp.arch,alt.folklore.computers Date: Sun, 15 Apr 2007 10:00:05 -0600 re: http://www.garlic.com/~lynn/2007h.html#17 MIPS and RISC for totally other topic drift, Varian was running early chip design applications on cp67/cms. Later you find some of the influence (and even engineers) at other places around the valley like AMD, LSI Logic, etc. ... and chip design applications still running on vm370/cms (cp67/cms followon) well thru the 80s. so separate from regularly visiting various of these places in the 70s and 80s ... related to chip technology ... also had lots of interactions about their vm370 operations. and old email that happens to mention amd 29k From: wheeler Date: Wed, 28 Sep 1988 13:42:59 PDT .... .... Our icharts show that the risc industry is doubling processing power every 18-24 months. Given that AMD introduced the 29000 in '87, then the window for a 2x 29000 opens sometime in early '89. The 29000 has been benchmarked at 40+k drystones (making a 2x 29000 85k-90k drystones). I believe that the current numbers are approx: original rt: 4k drystones 135: 12k drystones ps2m70 13k drystones 29000 40k+ drystones ... snip .... top of post, old email index of course, CISC processors then started to move onto similar technology curve.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sun, 15 Apr 2007 10:34:40 -0600 jmfbahciv writes: Wecker was one of the brilliant ones. The problem was the process of getting the work done. It took years to approve a dot in a spec. What people in PDP-10 land did was take the DECnet spec as it existed in mid-70s and implemented what later became ANF-10. In 1984, two of our developers attended a spec review meeting of DECnet. There was an agenda that listed the functionality that would be nice to put into DECnet. Our guys went down the list to see what ANF-10 did not have. It had implemented most of the items. So DECnet was not delayed because of non-existent hardware. I think it was the process where all specs had 20 meetings minimum with 20 people attending and all specs had to have signatory approval of 20-25 managers. Nobody just went and did it. They waited for all approvals before typing MAKE DECNET.MAC re: http://www.garlic.com/~lynn/2007h.html#18 sizeof() was: The Perfect Computer - 36 bits? all large corporations seemed to have their equivalent ... witness the future system stuff http://www.garlic.com/~lynn/submain.html#futuresys in the early 80s ... i had somewhat precipitated a new operating system rewrite project ... I had layed out a bunch of objectives ... programming technology, implementation language (some of the things being observed about the portability that unix was leveraging in the market), etc. this quickly got adopted and balooned into a fairly massive effert (with lots of people wanting to take advantage of the opportunity and get their favorite feature included ... a somewhat smaller scale repeat of what happened with future system project). one of my original objectives about small, highly focused group of individuals doing implementation got lost. just before the whole effort imploded ... there was something like a couple hundred people working on writting specifications. recent post http://www.garlic.com/~lynn/2007g.html#69 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits? of course something similar could be said about the workings of large bureaucratic organization in taking us out of the NSFNET backbone picture and attempting to substitute SNA (despite all the best efforts of NSF) http://www.garlic.com/~lynn/lhwemail.html#nsfnet or our experiece with MEDUSA, cluster-in-a-box http://www.garlic.com/~lynn/lhwemail.html#medusa and there used to be a joke that product announcements required nearly 500 different executive approvals.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sun, 15 Apr 2007 11:28:28 -0600 Anne & Lynn Wheeler <lynn@garlic.com> writes: and there used to be a joke that product announcements required nearly 500 different executive approvals. re: http://www.garlic.com/~lynn/2007h.html#24 sizeof() was: The Perfect Computer - 36 bits? for other drift ... the corporation periodically would release comments about encouraging wild ducks ... however somebody once wrote a byline for one of the series as long as they fly in formation. the other scenario was about encouraging people to self-select ... so they would have a list of people that needed to be delt with. post about being able to tell the people out in front by the arrows in their back http://www.garlic.com/~lynn/2007f.html#41 time spent/day on a computer and other related comments http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer http://www.garlic.com/~lynn/2007f.html#29 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007f.html#30 The Perfect Computer - 36 bits? and past post mentioning wild ducks: http://www.garlic.com/~lynn/2007b.html#38 'Innovation' and other crimes
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sun, 15 Apr 2007 15:52:15 -0600 Morten Reistad <first@last.name> writes: It can be done a whole lot better than that. If I have a web page up that says www.ford.com, (just to take an example, choosing one of the better operations) I want to be able to make a challenge to the system and make sure I am dealing with the Ford that is listed on Nyse as "F", or a company it has authorised. I need a trusted authority to issue those "first order" certificates. This is where Verisign has failed. The certificate is not audited, and is therefore just a stage prop. Potemkin security. re: http://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits? Your don't necessarily need "first order" digital certificates ... which are paradigm targeted at relying parties that have no other access to the information ... direct, online, real-time access to the authoritative agency responsible for the information is also a possible solution. This has been the process in place for electronic payments for decades ... the quality of the information for the merchant is sufficiently more worthwhile since not only do they get a real-time response about (supposed) validity of the consumer ... but also real-time response about real-time aggregated information (like credit limit) ... which isn't possible in a stale, static, offline paradigm. there were 3-4 separate scenarios ... all involving the authoritative agencies responsible for the information that certification authorities are supposedly using for the validity of the information being certified which are then represented in the (stale, static, redundant and superfluous) digital certificates. so with respect to certifications of merchant servers accepting payments, we initially suggested that the merchant financial institutions that already certify and take financial responsibility for ... as part of sponsoring them to participate in electronic transactions ... should just issue digital certificates for the merchants that they already certify. but that turns out to be redundant and superfluous since the merchant financial institutions have already been doing such oeprations for decades as part of real-time electronic payments. so with respect to domain name certificates ... as to the certification that the applicant for the domain name certificate is really the owner of the domain name ... SSL domain name certificates were originally intended as 1) encryption/hiding information in transit, 2) countermeasure to website impersonation, ip-address take-over, man-in-the-middle attacks, etc http://www.garlic.com/~lynn/subpubkey.html#sslcert as well as various things related to integrity issues with the domain name infrastructure. however, the process involves the domain name infrastructure as the authoritative agency as the source of the information that all the certification authorities rely on as to the real domain name owner (certification authorities have to check with the domain name infrastructure as to the true owner of the domain name ... when they are processing an application for domain name certificate). Now there have been some proposals that improve the integrity of the domain name infrastructure ... even backed by the certification authority industry (since the validity of domain name digital certificates tracks back to the integrity of the domain name infrastructure as the source). However, this represents something of a catch-22 for the certification authority industry since a major original justification for domain name digital certificates was because of domain name infrastructure integrity issues. Fixing those integrity issues reduces the justification for domain name digital certificates ... lots of past posts discussing this issue http://www.garlic.com/~lynn/subpubkey.html#catch22 Part of the improvements involve having domain name owner register a public key when they register their domain name (minimizing various forms of domain name hijacking on other vulnerabilities by requiring communication from the domain name owner be digitally signed and then verified with the onfile public key ... note certificate-less operation). Now there is additional opportunity for the certification authority industry. The current process has a domain name digital certificate applicant supply a lot of identification information with the application. Then the certification authority has an expensive, time-consuming, and error-prone process of matching the supplied identification information with the identification information on file with the domain name infrastructure. The certification authority can start (also) requiring that domain name digital certificate applications be also be digitally signed by the domain name owner. Then the certification authority can replace an expensive, time-consuming and error prone identification process with a much less expensive, simpler, and much more reliable authentication ... by doing a real-time retrieval of the onfile public key (from the domain name infrastructure) to validate the digital signature on the domain name infrastructure. The additional catch-22 for the certification authority industry (in addition to eliminating a lot of the original reason for their existance) ... is if they can do (certificate-less) real-time retrievals of public key ... then the possibility exists that the rest of the world could also. Rather than having all the digital certificate originated protocol chatter as part of SSL session setup ... the client can get the (valid) public key piggybacked from the domain name infrastructure in the transaction that responds with the domain name to ip-address. The client then just generates the random (symmetric) session encryption key, encrypts the message, encrypts the session key with the returned public key ... and sends the whole thing off to the server in a single message transmission. Is is then theoritically possible to have an SSL exchange in single transmisson round trip. In a online world ... it is theoritically possible to have direct real-time "first order" information from the authoritative agency and/or financially responsible institution, information that is significantly more valuable than what you could get from stale, static, redundant and superfluous digital certificate.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sun, 15 Apr 2007 16:42:38 -0600 Morten Reistad <first@last.name> writes: The first problem was that the banking world was a gentleman's club of trust between the participants. Opening this up to electronic security requires real authentication. re: http://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#26 sizeof() was: The Perfect Computer - 36 bits? part of the issue ... which side-tracked the whole process with extremely complex and costly processing was much of the digital certificate stuff (providing little fundamentally added value). fundamentally, digital signatures and asymmetrical key technology can provide for end-to-end integrity and authentication. the digital certificate stuff is an electronic analog of credentials, certificates, licenses, and/or similar to the letters of credit/introduction from the sailing ship days (and earlier) ... aka mechanism for trusted distribution of information for relying parties that otherwise had no access to the information (the two parties were anonomous strangers, having no prior interaction with each other ... and had no resource to direct interaction with an authoritative agency with regard to information about the other party). I've mentioned before that in the mid-90s, the certification authority industry appeared to take to wallstreet the prospect of a $20b/annum business ... i.e. the financial institutions would underwrite the cost of $100/person/annum digital certificate for their customers (i.e. approx. 200m). There was one scenario where a large financial institution was told that they could transmit their customer masterfile and the certification authority would reformat the bits and return them something called a digital certificate (for every record in the institution's customer masterfile) ... and the price would only be $100/account ... and oh, by the way, this would have to be repeated every year. The financial institution could then distribute this digital certificates to their customers ... and then for all future electronic communication/transactions, the customer would digitally sign electronic communication/transactions, and send off the communication/transaction, the digital signature, and the appended digital certificate to the financial institution. The financial instutition would retrieve the associated account record ... and use the onfile public key to verify the digital signature. Since the financial institution had the original realtime version of the information, there was never a situation when it would be necessary to refer to the stale, static, redundant and superfluous digital certificate. So the financial institution that had between 10m-20m such accounts ... came to the realization that there was no justification for a $1b-$2b annual transfer of wealth to the certification authority. We dropped into the institution and visited the people (that had already spent $50m on a pilot) just after the board became aware of the $1b-$2b/annum ongoing transfer of wealth requirement (and the responsible people had been advised that they should start looking for opportunities elsewhere). These sorts of realization sort of tanked the $20b/annum business case for the industry that had been floating around wallstreet. misc. past posts mentioning the $20b/annum business case scenario http://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack http://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down http://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...) http://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism" http://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the Internet http://www.garlic.com/~lynn/2005j.html#32 IBM Plugs Big Iron to the College Crowd so the next approach was attempting to get governments to pass legislation mandating digital certificates as part of all electronic signature operations. we ran into this when we were asked in to help word smith the cal. state electronic signature legislation (and later the federal electronic signature legislation). One of the big issues was that in attempting to equate digital signatures with human signatures ... the laywers pointed out they (certification authority industry) had left out the part of human signatures related to intent as part of the generating the signature ... or that the person had read, understood, agrees, approves, and/or authorizes what is being signed. lots of past post on the difference between digital/electronic signatures and the issue of showing intent http://www.garlic.com/~lynn/subpubkey.html#signature part of this was periodically attributed to attempts to take advantage of possible semantic confusion since both terms "digital signature" and "human signature", contain the word "signature" ... even tho, otherwise they are totally unrelated. past posts mentioning x9.59 financial standard protocol providing end-to-end integrity and authentication http://www.garlic.com/~lynn/x959.html#x959 w/o the enormous added payload and processing bloat of requiring appending digital certificates http://www.garlic.com/~lynn/subpubkey.html#bloat lots of related posts in this n.g. in the long running thread nhttp://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007 hhttp://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007 hhttp://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007 hhttp://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007 hhttp://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007 hhttp://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007 hhttp://www.garlic.com/~lynn/2007c.html#15 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#17 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#22 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#26 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#27 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#28 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#30 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#31 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#33 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#36 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#37 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#39 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#44 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#46 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#52 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007d.html#0 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007d.html#5 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007d.html#11 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007d.html#68 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007d.html#70 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#2 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#12 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#20 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#23 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#24 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#28 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#61 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#65 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007f.html#8 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007f.html#58 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007f.html#68 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007f.html#72 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007g.html#8 Securing financial transactions a high priority for 2007
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sun, 15 Apr 2007 17:22:35 -0600 Anne & Lynn Wheeler <lynn@garlic.com> writes: so the next approach was attempting to get governments to pass legislation mandating digital certificates as part of all electronic signature operations. we ran into this when we were asked in to help word smith the cal. state electronic signature legislation (and later the federal electronic signature legislation). One of the big issues was that in attempting to equate digital signatures with human signatures ... the laywers pointed out they (certification authority industry) had left out the part of human signatures related to intent as part of the generating the signature ... or that the person had read, understood, agrees, approves, and/or authorizes what is being signed. lots of past post on the different between digital/electronic signatures and the issue of showing intent http://www.garlic.com/~lynn/subpubkey.html#signature part of this was periodically attributed to attempts to take advantage of possible semantic confusion since both terms "digital signature" and "human signature", contain the word "signature" ... even tho, otherwise they are totally unrelated. re: http://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#26 sizeof() was: The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits? there was a similar but different foray in this period to try and get merchants to underwrite consumer (x.509 identity) digital certificates ... since the financial institutions had declined the privilege and it looked like getting the gov. to mandate (that consumers would have to pay for their own) might not succeed. now the merchants are already paying quite a bit on a per transaction basis ... and this would have further increased those payments. The offer basically implied that transactions that were consumer digitally signed and carrying the consumer's digital certificate ... might/could reverse the burden of proof. the current scenario in a merchant/consumer dispute ... puts the burden of proof on the merchant. If the burden of proof were to be reversed ... that met that in a merchant/consumer dispute ... the burden of proof would be on the consumer (enormous savings for merchants in disputes). (unfortunately?) A few raised the question that if this actually came to pass ... why would a consumer ever voluntarily want to digitally sign anything? This possibly is similar, but different to recent some comments about changes in the UK: Card victims told 'don't call police' http://www.thisismoney.co.uk/credit-and-loans/idfraud/article.html?in_article_id=418947&in_page_id=159 Concern over new fraud reporting http://news.bbc.co.uk/1/hi/programmes/moneybox/6513835.stm New rules to report fraud announced http://www.moneyexpert.com/News/Credit-Card/18106248/New-rules-to-report-fraud-announced.aspx Apacs: Report credit card fraud direct to bank http://www.fairinvestment.co.uk/credit_cards-news-Apacs:-Report-credit-card-fraud-direct-to-bank-18107160.html Anger at card fraud reporting changes - Law & Policy http://management.silicon.com/government/0,39024677,39166633,00.htm Banks charging to the top of the hate parade http://edinburghnews.scotsman.com/opinion.cfm?id=508912007 Warning Over Purge On Credit Card Fraud http://www.eveningtimes.co.uk/news/display.var.1303206.0.warning_over_purge_on_credit_card_fraud.php Anger at card fraud reporting changes http://www.silicon.com/financialservices/0,3800010322,39166633,00.htm Financial institutions to report on card fraud http://www.gaapweb.com/news/135-Financial-institutions-to-report-on-card-fraud.html UK Tells Consumers To Report Financial Fraud to Their Banks http://www.paymentsnews.com/2007/04/uk_tells_consum.html Financial institutions to be first point of contact for reporting banking crime http://www.cbronline.com/article_news.asp?guid=DE47801B-AE60-4073-8314-26AC46AC7C03 Card Fraud Changes 'Will Not Adversely Affect Police Response' http://www.fool.co.uk/news/your-money/credit-cards/2007/04/11/card_fraud_changes_will_not_adversely_affect_polic.aspx and related blog entry: http://www.lightbluetouchpaper.org/2007/02/08/financial-ombudsman-on-chip-pin-infallibility/ and for other drift ... some past posts mentioning some possible vulnerabilities in various chip deployments http://www.garlic.com/~lynn/subintegrity.html#yescard including a quote of somebody quipping about having spent billions of dollars to prove that chips are less secure than magstripe. for completely other drift ... a few past "interchange" fee references http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance http://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again? http://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging http://www.garlic.com/~lynn/aadsm7.htm#rhose3 Rubber hose attack http://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind? http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007 and misc. past posts mentioning burden of proof issue (in disputes): http://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists? http://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm21.htm#35 [Clips] Banks Seek Better Online-Security Tools http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world http://www.garlic.com/~lynn/aadsm23.htm#33 Chip-and-Pin terminals were replaced by "repairworkers"? http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues. http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ? http://www.garlic.com/~lynn/2001g.html#59 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001l.html#52 Security standards for banks and other institution http://www.garlic.com/~lynn/2002g.html#69 Digital signature http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2005e.html#41 xml-security vs. native security http://www.garlic.com/~lynn/2005m.html#6 Creating certs for others (without their private keys) http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols http://www.garlic.com/~lynn/2005o.html#26 How good is TEA, REALLY? http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc http://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message? http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: sizeof() was: The Perfect Computer - 36 bits? Newsgroups: alt.folklore.computers Date: Sun, 15 Apr 2007 20:50:05 -0600 Andrew Swallow <am.swallow@btopenworld.com> writes: Empire building - bosses in big organisations with 100 men working for them are paid more than bosses with 25 men working for them. Lack of resources is an excuse that personnel departments and accountants think they understand. re: http://www.garlic.com/~lynn/2007h.html#24 sizeof() was: The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007h.html#25 sizeof() was: The Perfect Computer - 36 bits? in past posts there has been passing references to failures can spawn significant promotions and empire building ... there was a recent corrollary mentioned in risk digest article, nothing succeeds like failure: http://catless.ncl.ac.uk/Risks/24.62.html in the past, the reference was comparing the 12 people developing cp67 for the 360/67 and eventually something like 1200 people developing tss/360 for the 360/67; some comments are that as the larger group appeared to be unable to deal with one problem or another ... the solution was to significantly increase the size of the organization (with sufficiently large organization any problem can be solved). so there is some significant incentive to not solve problems simply ... because there is always the chance that having difficulty in solving a problem will result in significant empire building. old posts mentioning the difference between the 12 w