2001 Newsgroup postings (09/02 - 09/11) Lynn Wheeler

2001 Newsgroup Postings (09/02 - 09/11)

E-commerce security????
Off-topic everywhere [was: Re: thee and thou
E-commerce security????
YKYGOW...
I hate Compaq
E-commerce security????
Losing our culture.
No Trusted Viewer possible?
PKI (Public Key Infrastructure)
E-commerce security????
PKI (Public Key Infrastructure)
PKI (Public Key Infrastructure)
OT - Internet Explorer V6.0
Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
OT - Internet Explorer V6.0
I hate Compaq
I hate Compaq
I hate Compaq
OT - Internet Explorer V6.0
Parity - why even or odd (was Re: Load Locked
Title Inflation
OT - Internet Explorer V6.0
Parity - why even or odd (was Re: Load Locked
Parity - why even or odd (was Re: Load Locked
Help needed on conversion from VM to OS390
Pentium 4 SMT "Hyperthreading"
Title Inflation
Title Inflation
Title Inflation
Title Inflation
Whom Do Programmers Admire Now???
Big black helicopters
Title Inflation
Military Interest in Supercomputer AI
Proper ISA lifespan?
Proper ISA lifespan?
Big black helicopters
Big black helicopters
Big black helicopters
Big black helicopters
Big black helicopters
Disaster Stories Needed
Does "Strong Security" Mean Anything?
OT - Internet Explorer V6.0
Big black helicopters
OT - Internet Explorer V6.0
Pentium 4 SMT "Hyperthreading"
Are client certificates really secure?
Title Inflation
Big black helicopters
Are client certificates really secure?
Are client certificates really secure?
Does "Strong Security" Mean Anything?

E-commerce security????

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Sun, 02 Sep 2001 22:44:52 GMT

Norm writes:
Why should the vendor keep the credit card information Forever? If you do not keep it online forever, then the risk is reduced significantly. You still have employee risk, but that will always be a problem. Any time you "trust" someone you accept the risk of getting burned.

Trust - giving someone enough information to damage/harm you.

If the vendor merely deletes the data after the transaction is completed the outside and inside cannot get to it but for a limited time frame.

first off the business rules (aka the credit card associations have rules that merchants must follow) have things about stuff like charge-backs and the merchant having the records associated with same (i.e. a customer may be able to dispute for 90-180 days ... and the material provided to the merchant may be as little as account# and date ... so merchant must keep records at least as long as there is possibility of chargeback &/or other dispute).

the initial translation of credit card (aka electronic commerce) to internet was relatively straight-forward since there was already provisions for non-face-to-face MOTO (mail-order/telephone-order) transactions ... ref to this effort:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

however, because account number is effectively shared-secret, there are all kinds of exploits ... not just limited to the internet. As a result, the financial standards body developed the X9.59 standard for ALL account-based payments (not just limited to internet but can be done at point-of-sale also and other types of environments). refs to debit implementation
https://www.garlic.com/~lynn/nacharfi.htm
https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

refs: to X9.59 mapping to iso8583 (aka international message standard used by both credit and debit networks):
https://www.garlic.com/~lynn/8583flow.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Off-topic everywhere [was: Re: thee and thou

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Off-topic everywhere [was: Re: thee and thou
Newsgroups: alt.folklore.computers,sci.lang,alt.usage.english
Date: Mon, 03 Sep 2001 00:59:24 GMT

Ric Werme writes:
While I agree with pretty much all the comments about card catalogs in libraries, note that in the future (i.e. now) people will search for information on the WWW. I often try to find something on Google and wind up distracted for half an hour by various other things Google comes up with. Conversely, most of my WWW site is devoted to abuse of families by Child "Protective" Service agencies. I have a Web counter that logs the referring URL, which often includes search engine search strings. A lot of people, looking for something else, have either had their eyes opened or think my wife and I are crackpots.

the (online) national library of medicine card catalogue had reached state of many current web search engines by the late '70s. It tended to be extremely bi-model on searches. For boolean search with 6-8 terms, it tended to switch from hundred of thousands of "hits" to zero "hits" with only minor refinements to the search.

In the early '80s an apple application called grateful med saw wide-spread deployment. It saved searches and interacted with the (online) query just by getting counts of hits. People would use grateful med to try searches that resulted in reasonable number of hits.

The holy grail has been to come up with methodology to get hits in the tens or hundreds ... rather than the bi-model tendency of switching from hundreds of thousands to zero hits ... with only minor changes to the search.

Part of the approach is attempting to migrate more intelligence of the indexing scheme out into the front-ends ... allowing more awareness of how medical knowledge is structured. Part of that is referred to as UMLS or unified medical language system.

When we worked in the area a couple years ago ... there were something like 40,000 medical librarians world-wide trained in searching NLM. A typical scenerio would be a doctor spends 3-4 hrs with the medical librarian who then goes off for a couple days doing queries and then gets back to the doctor with the most likely responses.

NLM now has web interface ... but the mechanics of the searching still is pretty much the same. I don't know if it has changed recently ... but a couple years ago, the index was still a large BDAM database designed in the late '60s (and despite large amounts of efforts investigating newer technologies thru-out the 80s & 90s ... there was still nothing that could beat it).

some random refs:
https://www.garlic.com/~lynn/94.html#26 Misc. more on bidirectional links
https://www.garlic.com/~lynn/2001c.html#67 What ever happened to WAIS?
https://www.garlic.com/~lynn/2001i.html#27 History of Microsoft Word (and wordprocessing in general)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

E-commerce security????

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Mon, 03 Sep 2001 02:13:39 GMT

Norm writes:
Generally you have 60 days to dispute a charge from the time you get a statement. So that would imply at least 90 days for the business to keep transaction data. Does that data need to be on a server connected to the Internet. No. It could be archived to an offline server that is a peice of junk but has lots of storage capacity. Only a few employees, those that handle disputes need access. In the CD Universe case a Russian attacker stole 300,000 credit cards. Some of the people had not had a transaction in 2-4 years. There really is no need to keep it forever is my point. This seems to be the mindset: never archive anything and hold on to all data on users as long as possible. This makes risk for the user increase. You could burn it to optical disks and have it stored offsite at a secure facility. Anyway, if it doesn't exist it is impossible to steal.

there are all sorts of things that can be done ... but have shared-secret account numbers is the fundamental problem ... x9.59 eliminates the account numbers as exploit/fraud objectives ... i.e. the account number no longer can be used in non-authenticated transactions.

as in the discussion about security proportional to risk ... the basic problem is that the degree of risk of account numbers in unauthenticated transactions bears little or no relationship to the risk/benefit scenerio at the merchant business i.e. the account number risk is significantly larger than any amount of merchant business at risk, and therefor there is no correlation between the amount of business & revenue that a merchant is doing and the amount of risk & security associated with the existing account numbers.

There are lots of security things that can be done proportional to the amount of risk represented by the account number file .... however, in principle, the amount of business a merchant is doing should be proportional to the risk the merchant is dealing with ... and therefor is able to fund/underwrite risk proportional to their business. However, the account number file tends to far exceed the risk in the merchant business and bears little or no correlation with that business

i.e.
https://www.garlic.com/~lynn/2001h.html#61 security proportional to risk

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

YKYGOW...

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: YKYGOW...
Newsgroups: alt.folklore.computers
Date: Mon, 03 Sep 2001 15:47:27 GMT

bill@wjv.com (Bill Vermillion) writes:
But it didn't rotate very fast. And old engineer told me that on machine they had years ago that the data was on head track four times to make up for rotational latency. This was in a process control environment.

the ibm count-key-data (CKD) disks tended to have same number of bytes on each track ... but you can physically format the records on each track. for random access arm efficiency there tended to be some games.

An example is original 3330. 19 tracks per cylinder (i.e. arm position, 19 heads, one head per track, actually a 20th head&track for position sensing). You could format three 4k records per track plus a little left over.

The standard I/O sequence involved channel command words or CCWs. A typical record access CCW program (for 4k pages) might look like:


Seek (cylinder)
set sector
search-id equal
tic -8
read/write 4k
nop

if you formated each track the same ... you knew the approximate rotational angle of each record ahead of time and could specify it in the "set sector" command. The "search-id equal" was a CKD command that allowed some pretty fancy outboard record searching operations ... but the trivial case is you knew the record number and just wanted it. The "tic -8" was a branch if the search was not successful. Then the read/write command.

It was also possible to "chain" sequences together for records on the same track or cylinder ... basically changing the "nop" to a tic/branch command to the start of the next CCW package (i.e. seek command).

The original design had the CCW sequences (and the CCW arguments, like the parameters for the seek, set sector and search-id commands) all stored in main processor memory and the "channel" processor sequentially retrieving each CCW one at a time and interpreting it. Note that all the time the "channel" processor was retrieving and interpreting the channel commands (and their parameters), disks were rortating. If the channel was slow enuf, it was possible (when doing sequential record processing) that the next sequential record had rotated passed the disk head while the channel was still processing the CCW command sequences. To compensate for this, disks were sometimes formated with short, dummy "filler" records between the normal data records (and assigned IDs that wouldn't be normally used by search-id commands).

In the 3330, 4k page record case, 50-byte dummy filler records were standard. This allowed the channel extra latency while processing normal CCW sequences to get to the search-id for the next sequential record before it had rotated passed the head; at least for sequential records on the same track. However, for "sequential" records on the same cylinder, but different track, there was also extra channel & disk controller latency that resulted in the next sequential record to rotate past the head (even with 50-byte dummy filler records).

With 4k-byte data records, the maximum sized dummy filler records was 110-byte before exhausting the maximum track length capacity on 3330s. Things now got processor and controller sensitive. Some processor channels and some PCM (plug compatible manufactur) 3330s were fast enuf that they could process the switch head operation before the next sequential data record had rotated past the head (using 110-byte dummy filler records); and some combinations had too much processing latency and would result in a "rotational miss" and have to go around an extra time.

In general 4341 & 370/168 channels were fast enough that they could sequentially access data records on adjacent tracks. 370/158s channels weren't normally fast enuf ... although some PCM 3330 controllers in combination with 158 channels could process the next (rotational) sequential data record on adjacent tracks (same cylinder, different track).

When the 303x machines were introduced, all of them exhibited the 3330 rotational access characteristic of the 370/158. The 370/158 had "integrated" channels where the 158 native (horizontal microcoded) processor engine was shared between emulating 370 instructions and emulation CCW I/O instructions. The 4341 had integrated channels, but were sufficient fast enuf implementation that it wasn't a problem. The 168 had dedicated, outboard hardware "channels".

3330 filler record discussion
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#44 Charging for time-share CPU time
https://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)

Something similar was done on the 2305 fixed-head disk that was normally used as a dedicated paging device and was formated with dummy filler/spacer records. The 2305 also had eight "logical" addresses. It was possible to schedule (queued) requests on all eight "logical" addresses and have the hardware manage which requests to service. The normal, ibm channel sequence was that after the previous CCW operation had finished, there was a series of events involving hardware interrupts, software processing, and other latency introducing events before the next queued request was (re-)driven on the I/O interface (all the time the disks were rotating).

misc. 2305 discussion
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
https://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
https://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#52 IBM 650 (was: Re: IBM--old computer manuals)
https://www.garlic.com/~lynn/2000d.html#53 IBM 650 (was: Re: IBM--old computer manuals)
https://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes

For the 303x line of machines, they took the processing engine from the 158 and created a "channel director" ... i.e. an outboard dedicated box that only performed CCW channel operations. The 303x channel directors (on all processor models) all shared the same channel director implementation (a somewhat repackaged 370/158 engine).

The 3031 was a revamped 370/158 where there was a dedicated processing engine for executing 370 instructions and the same processing engine outboard in a "channel director" dedicated for doing I/O. The 3031 had faster 370 processing execution (than the 370/158) ... but the channel director exhibited the same processing latency as the 370/158.

misc. 158/3031 processor comparison
https://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?

The 3032 was essential a 370/168 that was configured to use the 303x outboard channel directors rather than the 370/168 outboard channel boxes.

The 3033 started out being a 370/168 wiring diagram remapped to faster chip technology (as well as using 303x channel directors) ... but was enhanced along the way to improve its performance.

getting blamed for originating the 360 plug compatable manufactur (PCM) business:
https://www.garlic.com/~lynn/submain.html#360pcm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

I hate Compaq

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I hate Compaq
Newsgroups: comp.arch,comp.os.vms,alt.folklore.computers
Date: Mon, 03 Sep 2001 16:11:47 GMT

Kilgallen@SpamCop.net (Larry Kilgallen) writes:
Note that the DEC SVS A1 virtual monitor system (that never made it to market) was written in Pascal in order to allow the security proofs. The software running under that was ordinary VMS (the only OS they tried). To me this proves that writing lower level code in a higher level language is quite viable.

(For those who don't remember, the project was canceled when DEC marketing discovered that the market for A1 systems was not what they had thought it was going to be.)

I did something different. All of the CP virtual machine kernel (both CP/67, VM/370, etc) was written in assembler. Some of the services were questionably actually needed in the low-level kernel ... especially for security reasons like much of unit record simulation and the corresponding spooling infrastructure (aka effectively standard CP kernel already provided virtual monitor infrastructure that made a number of security-related paradigms standard).

I rewrote the spooling infrastructure in Pascal running in a virtual machine address space with upcalls out of the kernel into the spool machine to handle unit record/spool operations on behalf of other virtual machines.

The original purpose (of the effort) was to improve the performance of the spooling infrastructure by at least an order of magnitude for the HSDT (high-speed data transport) project i.e. turns out that local node network support depended extensively on the spooling infrastructure (which had become the major thruput bottleneck for high-speed network operations). The objective was an order of magnitude performance improvement ... even taking into account that assembler code was being replaced with Pascal and the code was migrated out of the kernel into virtual address space (both introducing numerous kinds of additional overhead).

Basically, a number of things were done (none of them that couldn't really have been done with kernel assembler code) 1) semantics for asynchronous spool I/O interface was implementated, 2) numerous sequential search operations were replaced with "tree-based" operations, 3) spool records were enhanced to signficantly improve availability and recoverability, 4) kernel was insulated from numerous kinds of spool related errors that previously would have resulted in system failure.

this was deployed on parts of the internal network (the internal network was larger than the whole internet/arpanet for much of its lifetime).

hsdt, networking
https://www.garlic.com/~lynn/subpubkey.html#networking
https://www.garlic.com/~lynn/internet.htm

misc hsdt & spool file rewrite discussion
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
https://www.garlic.com/~lynn/94.html#25 CP spooling & programming technology
https://www.garlic.com/~lynn/94.html#31 High Speed Data Transport (HSDT)
https://www.garlic.com/~lynn/94.html#33a High Speed Data Transport (HSDT)
https://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
https://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
https://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2000f.html#31 OT?
https://www.garlic.com/~lynn/2001.html#72 California DMV
https://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
https://www.garlic.com/~lynn/2001e.html#64 Design (Was Re: Server found behind drywall)
https://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001h.html#13 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#29 checking some myths.
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
https://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

E-commerce security????

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Mon, 03 Sep 2001 23:15:10 GMT

Norm writes:
I think you are missing my point. The credit card number should not be kept forever. This is why I periodically cancel all credit cards. Because I don't want to have to worry about the security of all the people I do business with. If they delete the data and/or archive it off-line, crackers cannot get to because it doesn't exist. The only reason they keep these large lists is marketing and impulse buying reasons. It really serves me little purpose to have buy.com store my address 10 years from now. If I am constantly doing business with them then great. But a lot of the time I buy once, because some site has a much lower price, and never again. Why keep that data forever? No data should be kept forever.

when we were working on the credit card transaction stuff (now frequently referred to as electronic commerce):
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

we tried to get various security measures specified:


• physical security for the data processing room, motion detecters, guards, etc
• multiple layers of firewalls & packet filtering routers
• actual financial transactions performed on backroom dataprocessing
equipment away from the actual web server
• fbi background checks for all employees
• security audits
• minimum business & security certification levels.

... didn't happen, oh well.

so faced with the prospect that there might someday be 20,000,000 or so e-commerce servers world-wide and all of them had to be implemented absolutely perfectly, none of them ever having the slightest security lapses with either technology or people ... the next choice seemed to be to eliminate the major source of risk ... i.e. account numbers as a risk.
https://www.garlic.com/~lynn/2001h.html#61 security proportional to risk

i.e. with security supposedly proportional to risk ... if it wasn't going to be easy to get ubiquitous security actually proportional to the risk (with real live security audit and certification for all such sites) ... then the next choice would be to change the associated risk ... aka the x9.59 solution ... which was done in such a way that it is applicable to ALL account-based transactions (not just credit, and not just internet).
https://www.garlic.com/~lynn/

the issue isn't just that even simple things could be done to improve the situation ... the consumer also has no way of telling what sites have implemented what levels of security (even if some sites were to implement even partial measures to improve the situation ... the customer has no way of determining who has implemented what).

some discussion regarding tieing information security implementation into business risk management and associated business rating (i.e. analogous to credit risk rating)
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads
https://www.garlic.com/~lynn/aepay3.htm#x959risk1
https://www.garlic.com/~lynn/aepay3.htm#x959risk2
https://www.garlic.com/~lynn/aepay3.htm#x959risk3
https://www.garlic.com/~lynn/aepay3.htm#x959risk4

longer list of risk & security related discussions
https://www.garlic.com/~lynn/subintegrity.html#fraud

general x9.59 financial standard discussions
https://www.garlic.com/~lynn/subpubkey.html#privacy

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Losing our culture.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Losing our culture.
Newsgroups: alt.folklore.computers
Date: Mon, 03 Sep 2001 23:28:56 GMT

"John Homes" writes:
Relying on GO TO instead of properly nested code structures encourages sloppy design, and that is the problem with GO TOs. Properly designed code can be implemented with GO TO (as someone in this tread has pointed out, compilers do just that generating the executable) and the result is still good code.

in the early '70s, I wrote a large application (in PL/1) that would read assembler code and perform a lot of analysis ... register usage, process flow, use-before-initialized graphs for registers, bunch of other stuff. I also generated a "higher-level" language level representation of the assembler code that included all sorts of non-GOTO process flows (since the low-level assembler just used various kinds of branching instructions). Even with various kinds of break and trap conditions ... there were still a number of assembler programs that had sections that were quite elegent in the original and were really terribly complex in nested & non-GOTO representation.

Part of the GOTO issue is in some sort of failure/fault situation being able to backtrack the program. Nested conditionals tended to make the process flow more obvious based on the associated conditions/variables i.e. process flow directly dependent on some other explicit language construct ... which isn't present in a simple branch/GOTO. The trick then was placing something in the process flow that made it obvious what paths might have been taken when attempting to backtrack from a failure/fault (even when GOTOs and/or other unconditional branch operations were involved).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

No Trusted Viewer possible?

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: No Trusted Viewer possible?
Newsgroups: comp.security.misc,comp.security.pgp.discuss
Date: Tue, 04 Sep 2001 02:23:07 GMT

skeptic <Use-Author-Supplied-Address-Header@[127.1]> writes:
Digital signatures are more secure than paper signatures.

while, once created securely ... digital signatures may be more difficult to counterfeit ... there is less obvious correlation between a person's intention and some computer mathematical calculations ... as compared to a paper signature ... where if you watch a person writing their signature, it is usually pretty obvious they intended to write it. it is much harder to show that the computer mathematical calculations (resulting in a digital signature) is being done exactly with the understanding and under the direct control of a specific human and can only be done at the specific direction of that human (and is otherwise totally impossible for the computer to perform those mathematical calculations).

the use of digital signatures as part of message authentication is much less problematical ... i.e. assuming that it was correctly originated, then there is little likelyhood that any alteration goes undetected.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

PKI (Public Key Infrastructure)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI (Public Key Infrastructure)
Newsgroups: sci.crypt
Date: Tue, 04 Sep 2001 16:30:52 GMT

"Novice" writes:
client A of the PKI system wants to send an encrypted message to client B. A makes a request of his CA (Certificate Authority or more appropriately a Certification Authority) for the public key of user B - this request could potentially be digitally signed by A to ensure that the request cannot be read by another user. The CA then replies with a message (digital certificate) that is digitally signed by the CA and contains the public key of user B. A then decrypts/deencrypts the message from the CA in order to obtain the public key of User B. A then encrypts his message using B's public key. He then sends that message to B. B is then able to decrypt/deencrypt the message using his private key.

PKIs were designed for offline operations (model is the "offline" email world from the early '80s; people called up, downloaded email, & then hung up; then digital signatures on email had to be validated while offline).

A, B, ... all have a root-key loaded somewhere. "A" requests a certificate for their associated public-key from a CA (that is signed by the root-key ... or have secondary certificate eventually signed by some root-key). "B" requests a corresponding certificate for their associated public-key.

"A" generates a message and digital signs the message. "A" then creates a package of the message, the digital signature and "A's" certificate and sends it to "B".

"B" receives the package, validates "A's" certificate with the root-key (so that it can trust "A's" public key), then it validates the message digital signature using public key from "A's" digital certificate.

here is sample of root-keys/certificaets preloaded into browsers:
https://www.garlic.com/~lynn/aepay4.htm#comcert14
https://www.garlic.com/~lynn/aepay4.htm#comcert16

note that for the majority of the deployed infrastructures ... they aren't full PKIs ... they are subset certificate manufacturing ... full PKIs imply that the certificates are managed and administrated ... aka infrastructure in place so that all possible clients in the world can be notified with regard to revoked &/or compromised certificates.

more discussion on SSL=related certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

discussion of client/server digital signature authentication w/o certificates
https://www.garlic.com/~lynn/subpubkey.html#radius

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

E-commerce security????

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Tue, 04 Sep 2001 17:19:12 GMT

Anne & Lynn Wheeler writes:
the initial translation of credit card (aka electronic commerce) to internet was relatively straight-forward since there was already provisions for non-face-to-face MOTO (mail-order/telephone-order) transactions ... ref to this effort:

the other part of MOTO that we translated to e-commerce was AVS ... address verification transaction; a simple form of authentication, basically matching name & address with mailing name & address on file; aka MOTO-transactions want name&address of record for AVS authentication.

this further (unnecessarily) propagates (more) privacy information.

X9.59 substitutes AVS with digital signature authentication which eliminates that bit of additional privacy information (in addtion to eliminating account number as a shared-secret exploit).

Hardgood shipments may still require some name&address (although softgoods & various other online services wouldn't) and there are a half-dozen or so hardgood shipment strategies that also eliminates merchant needing to know name&address for shipping.

now, there is an issue of point-of-sale ... and upgrading the magstripe cards with the addition of chips and deploying the readers. some of that is already going on ... but note that the same x9.59 transaction is defined for debit, credit, internet, point-of-sale, etc. Part of the driving force for magstripe card upgrade is that technology advances have been it extremely inexpensive to counterfeit large numbers of magstripe cards. The addition of a chip, significantly raises the bar.

misc. refs:
https://www.garlic.com/~lynn/subpubkey.html#privacy
https://www.garlic.com/~lynn/subintegrity.html#fraud

random specifics
https://www.garlic.com/~lynn/ansiepay.htm#cardsteal Stealing cards easy as Web browsing
https://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/aepay6.htm#fraud Online Card Fraud Thirty Times That Offline
https://www.garlic.com/~lynn/aepay6.htm#ccfraud latest credit scam puts plastic in peril ... is your credit card being cloned?
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
https://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
https://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

PKI (Public Key Infrastructure)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI (Public Key Infrastructure)
Newsgroups: sci.crypt
Date: Tue, 04 Sep 2001 19:19:43 GMT

"Novice" writes:
Ahh but the scenario you are describing is digitally signing a message using public key encryption. That is yet another perfectly valid scenario in a PKI system, but I believe mine is also valid. What if I didn't want to bother digitally signing my message. In that case, I could just encrypt the message with the public key of the recipient of the message, send the message and then the recipient could decrypt/deencypt the message with their private key, correct?

it can either be digitally signing or totally encrypting the message.

if encrypting the message, the sender obtains the recipient's public key from the recipient's digital certificate which the recipient had previously transmitted to the sender in a digital signed message (i.e. the previous description).

using the recipeint's public key (from the recipient's digital certificate, from a previously digitally signed message), the sender typically will encrypt a random secret key and then use the random secret key to actually encrypt the message. The sender will package up the publickey-encrypted random-secretkey and the secretkey-encrypted message and transmit it to the recipient. Typically, the sender may also digital sign the message (before encrypting) .. as prior previous posting.

Above is similar to the most common deployed existing certificate manufacturing infrastructure (aka PKI-subset) ... SSL domain name server operation.

However, there are lots of other ways of deploying public key operations ... PGP being one such example.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

PKI (Public Key Infrastructure)

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI (Public Key Infrastructure)
Newsgroups: sci.crypt
Date: Tue, 04 Sep 2001 22:01:45 GMT

"Novice" writes:
Don't all users obtain the public key of another user through the CA? I mean what you are describing is that user A would obtain the public key of user B from user B.

Also I believe the operation of encrypting a symmetric key using an asymmetric key was originally conceptualized by Diffie Hellman, correct?

PGP doesn't require a CA.

CA stands for "certification authority" ... they typically generate a certificate that represents some attribute (like identity) that they certify as having some relationship to a public key.

With PGP ... I can append my public key to my email and the recipient possibly uses some method to verify that the email with the public key actually came from me.

This is in fact, effectively what a CA (certification authority) is doing when it obtains a person's public key from the person (before any certificate is manufactured). This may be referred to as the registration part of the certification authority business process.

However, as in the PGP example, everybody could be their own registration authority ... and a certificate need never, ever be manufactured.

Effectively this is similar to the RADIUS and banking scenerios where "registration authority" of a public key is performed in much the same way that passwords and/or PINs are registered today.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

OT - Internet Explorer V6.0

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,comp.lang.cobol
Date: Wed, 05 Sep 2001 18:34:23 GMT

"Editor" writes:
Have you seen some of the newest Unisys "Mainframes?" 32 wide Intel Itanium processors with shared memory bus running Win2000. A fraction of the cost and maintenance expense for the same or better power as Unisys current "mainframes". And you don't even have to reboot them anymore, every time you install new software :-).

i believe that some number of the Unisys "mainframes" have at various times been logo'ed Sequent machines ... which has been doing scalable smp intel processors since the 80s (I think they started with national chip tho) ... and who has since bought Sequent?

we attempted to do various things with SCI standard in the very early 90s but didn't get very far at the time.

random refs:
https://www.garlic.com/~lynn/96.html#8 Why Do Mainframes Exist ???
https://www.garlic.com/~lynn/96.html#25 SGI O2 and Origin system announcements
https://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
https://www.garlic.com/~lynn/2001b.html#39 John Mashey's greatest hits
https://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
https://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query

misc. other
https://www.garlic.com/~lynn/subtopic.html#smp
https://www.garlic.com/~lynn/subtopic.html#hacmp

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 06 Sep 2001 13:53:36 GMT

jcmorris@mitre.org (Joe Morris) writes:
Most mainframe systems since the mid-60s had some degree of internal fault detection, and often fault recovery or at least a mechanism to record the details of the failure. (Some of the IBM systems included the ability for the CPU to automatically place a service call, which inevitably resulted in "E.T. Phone Home" jokes.)

note also that standard policy that a machine could be "scoped" in the field. when machines got too complex &/or other issues (like TCMs) for scoping, then there was a boot-strap scoping procedures; a "service processor" that could be scoped (for diagnosing problems in the service processor), and then the service processor has all sorts of probes and diagnostic capability into the "real" machine.

The 3081 had a UC.5 (a particular microprocessor also used in a number of other places, 8100, 3705, etc) as a "service processor". The 3090 had a pair of 4361s (small 370s, running a special version of vm/370 release 6) as the service processor (aka the service processors were redundant). One of the 4361 service processor would be the one to phone home.

I believe the 3090 had 64/80 ECC memory ... detect all 16 bit errors and correct all 15 bit errors.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
Newsgroups: alt.folklore.computers
Date: Thu, 06 Sep 2001 15:14:27 GMT

jcmorris@mitre.org (Joe Morris) writes:
Nope, 600 usec core memory (IBM 2365, for a 360/65). Each 256 KB on the /65 was housed in its own box, IIRC 6' high, 7' long, 30in wide, and requiring 208 VAC 3-phase power.

the ibm memory for the 65/67 was 750usec core memory (my understanding was that the 30, 40, 50, 60, 62, 70 designations were the original 360 model designations ... with 60, 62, 70 having something like 1000usec memory and the 65, 67, 76 model designation was for the faster, improved 750usec memory).

The 67 was effictively a 360/m65 with addition of virtual memory hardware and a fully associative TLB (table lookaside buffer) for hardware virtual memory address resolution. When running in virtual memory mode, the TLB look-up added 150us to all address cycles (virtual memory mode on 360/m67 turned it into 900us machine).

A lot of the 360m67s spent much of their time running in 360m65 mode (for the most part, os/360 ran identical on 360m67 & 360m65).

The 360m67 SMP was a different beast tho from the 360m65. The 360m65 SMP was basically two 360m65 uniprocessors bolted together so that they had common addressing for all memory (or could be partitioned two uniprocessor and each processor had half the real memory).

The 360m67 SMP had special tri-ported memory and a channel director. The tri-ported memory gave each processor and the I/O channel director independent paths to memory. The tri-ported memory introduced something like an extra 10% latency in memory operations (i.e. 750us to 825us or so, my memory is little weak on this value).

It was also possible to split 360m67 SMP into approximately two independent uni-processors ... however there was still the hardware memory latency difference between the normal 65/67 and a SMP 67 (i.e. numerical intensive operations ran slower on SMP 67 whether it was configured as a up or a SMP ... compared to 65 (uniprocessor or smp) or a uniprocessor 67. However, in workload mix that was 100% cpu and heavy i/o activity ... a "half-duplex" 67 had higher thruput than a uniprocessor 65/67. The standard memory bus with single port resulting in memory bus contention between the processor and I/O (slowing down the processor). The "duplex" memory bus while having slightly higher initial latency resulted in much lower memory bus contention when concurrent I/O and CPU accesses were involved.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
Newsgroups: alt.folklore.computers
Date: Thu, 06 Sep 2001 18:55:57 GMT

Neil Franklin writes:
Do I get that right? 600 or 750 microseconds for one memory access? That is about 1200 to 1300 memory access per second.

If you had said 6.00 or 7.50 usec (= 6000 or 7500 nsec) I would believe it.

Even a "cheap" PDP-8/E had something like 1.2 usec machine cycle (so memory must be less time than that).

360/m65/m67, etc nanoseconds ... 750 nanoseconds ... 8byte-wide interleaved.

360m50 was 2microseconds ... 2byte-wide

bulk (add-on) memory (8mbytes) from Ampex that could be attached to 360m50, 360m65, etc was 8microsecond memory.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

OT - Internet Explorer V6.0

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,comp.lang.cobol,alt.folklore.computers
Date: Thu, 06 Sep 2001 19:33:16 GMT

Charles writes:
I think the real strength of microsoft is you can buy a PC and install a program or an application with very little knowledge about Hardware, files or memory management. A trained monkey could be taught to use a PC. We use VSE/CICS with over 200 users hitting the mainframe, at our school and even more from the internet. Security of Data is also a key reason we still use the mainframe. It takes hundreds of PC's to access one mainframe so Microsoft PC's and IBM and other manufacturer's mainframes are good for each other, along with the servers and the network software it takes to access the mainframe. This is a Symbiosis going on here not necessarily direct competition.

In the early '80s before Apple Mac was announced, I would periodically have dinner with some of the Mac developers. We would have this argument about whether the Mac (then) was ever going to be profitable. I would somewhat characterize the Mac group at targeting the box for the kitchen table and they found the idea that it might ever be used in any other environment (especially any sort of business context) as an anathema.

My counter-argument was that the vast majority of the IBM/PC sales were into business (i.e. for a whole slew of reasons, personal computing wasn't really ready from the general, novice consumer market) .... possibly by a ratio of 10:1. A big factor in that was having mainframe terminal emulation on the PC ... so there was a single desk footprint ... aka with a single screen, keyboard, box, a person could both do local computing as well as do their mainframe accesses (aka a big factor in early IBM/PC market penetration was that it had at least some local computing capability and also could act as an ibm mainframe terminal). Being able to establish a (then) huge install base on the basis of single keyboard on the desk (capable of both mainframe & local computing) .. that created critical mass for motivating more applications to be written for the IBM/PC ... which started the snowball effect; once the initial base was established, then more applications were written, which increased the value proposition for having a PC, leading to further increases in the install base, motivating even more application development.

This characteristic allowed some graceful transition from mainframe centric operation to incremental local applications. The problem by the late '80s was the migration was starting to accelerate for both processor-centric applications as well as data-centric applications.

This was creating a horrible bind in corporate america ... the local computing processing power was a transient type of activity ... but when some of the corporate jewels (like finance data) started migrating to PCs & PC disks there were some serious episodes of disk failure and lost data that seriously impacted business operations.

At the same time, there was an internal corporate battle going on. The disk storage division generated a report that the head of the communication division was going to be personally responsible for the demise of the disk storage division. The 2nd level detail was that the disk storage division had come up with a number of very effective solutions that supported PC accessing mainframe resident data. The communication division was non-concurring on all such offerings ... effectively attempting to maintain that all PC mainframe access had to be channeled thru the communication division's terminal (emulation) products. The lack of bandwidth and function of the communication division's terminal (emulation) was accelerating the migration of data off the mainframe. That migration was also significantly increasing the risks & business continuity exposures of corporate american (since critical corporate assets were now resident on platforms that lacked any business continuity &/or disaster recovery scenerios).

Siding with the communication divison was the mainframe processor SAA strategy which could be interpreted as 1) all application could executed at either the mainframe or the PC ... and once that was achieved 2) some of the mainframe->PC processor migration could be reversed. The shortcoming was that there was some really valid reasons for much of the mainframe->PC processing migration; but an optimal business strategy would be to do it in such a way that critical business assets (aka information & data) could continue to reside at the mainframe.

The shortcoming is that once the PC began using the terminal emulation interface as a graceful migration & market penetration ... it later became a nearly impossible (internal) business problem to offer something that would take business away from the division responsible for terminal emulation (even if that limitation eventually resulted in significant, overall loss of business to the company).

From corporate america standpoint, I believe in the mid-90s there was some study that said that companies that had (non-backed up) disk failures with critical corporate assets, 50 percent went bankrupt within the first month (corporate assets could be billing file, accounts receivable, etc ... which could seriously impact a month's cash flow).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

I hate Compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I hate Compaq
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 06 Sep 2001 20:53:56 GMT

name99@mac.com (Maynard Handley) writes:
Hmm, Nick, you need to keep your exaggerations self-consistent.

A few posts ago you were telling us that MP was "widely available" sonce the 70's, yet hadn't led to widespread MP software.

Now you're telling us that actually MP HW that works is sufficiently hard to make useful that it wasn't really available till maybe the early 90's

60s & 70s had relatively wide-spread two-processor SMP support. The cached machines had very strong consistent caches ... that introduced a 10-15% performance penalty (in cycle time) compared to uniprocessor.

In the 70s, the "normal" machines were uniprocessor and two-processor SMPs had the 10-15% performance (i.e. a two processor was rated at best at 1.8times the instruction rate of a uniprocessor, not two times, all of this was due to cache consistency).

One could make the argument that one majors issue of the 801/risk architecture from the 70s that lacked cache consistency provisions ... was a re-action to the experience in designing cache-consistent mainframes.

So we cycle up to the start of the '80s with the 3081. The 3081 was going to only be available in 2-way (and 4-way; a pair of 3081s in a 3084 configuration).

However, there was some relatively important (but not widely deployed) operating system at the time ... which was ACP/TPF ... i.e. transaction processing factility aka airline control program which didn't have SMP support. It tended to be a few highly tuned, extremely high transaction rate, processor bound environment ... that carried the majority of the world's airline reservations (as well as supporting misc. other high transaction rate oriented businesses).

An ACP/TPF running on a 3081 in uniprocessor mode ... still had the 15% cache consistency performance penalty. The issue wasn't so much the cost of the unused hardware that led to the 3083 ... it was that ACP/TPF needed the additional 15% performance boost that came with eliminating the cache consistency cycles. The lack of SMP support in ACP/TPF giving rise to the 3083 is (at least) partially orthogonal to mainframes getting really scalable cache consistency implementations.

The very strong memory consistency and the distances between the caches ... made it hard to even limit the 3084 4-way to just a 15% performance penalty (in part, they ran the cache hardware cycle at faster than the machine cycle). This all further aggravated the 801/risc tendency towards avoiding cache consistency protocols all together.

The skunk works that my wife and I ran was both involved in SCI for scaleable SMP support as well as I/O-based clustering (including fiber-channel) ... the problem we had in the late '80s & early '90s is that the 801/POWER chips were so far over on not supporting cache consistency that there was no possible implementation (live oak was a 4-way RSC/.9 POWER ... but side-stepped the cache consistency issue by be able to mark segments as non-cachable ... i.e. if it was necessary to share data between processors ... don't cache it at all).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

I hate Compaq

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I hate Compaq
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 00:30:14 GMT

Tom Van Vleck writes:
There was a performance degradation as CPUs were added to Multics, but it wasn't due to cache consistency. In the 645/6180 architecture, memory was external to the CPU, and memory interference was one component of the slowdown. A much bigger component was queueing on software locks for the paging and scheduling mechanisms. We studied these factors and had designs for breaking down many of the big locks into smaller locks, to increase parallelism through the supervisor. This was one of the many projects the Multics team didn't get to do.

the original translation of the 5-way VAMPS to standard vm/370 product had nearly zero locking & queuing SMP overhead (and achieved hardware utilization thruput of the processors) i played some tricks

most recent VAMPS overview (posted here 18aug)
https://www.garlic.com/~lynn/2001i.html#2

however some number of people were uncomfortable with the approach and after a couple software releases changed the implementation and put in a more traditional locking, queuing, and signalling SMP design ... which drove the SMP "software" overhead to 10-15% of each processor ... i.e. traditional 2-way 370 SMP would have 1.8 times hardware thruput of a uniprocessor (because of the cache coherency protocol slowing down each cpu by 10% ... not even taking into account any actual cross-cache line trashing overhead). With the later version software change in VM ... system thruput was reduced to about 1.5 times thruput of uniprocessor running the same workload (each processor slow down was 10% plus another 15% of each processor tied up in various kernel SMP related operations).

I was involved in an attempt to build a 16-way 370/158 ... which was chugging along pretty good until the head of POK was informed that MVS SMP support was still limited to 2-way at the time (i.e. it is either "me" or the one other cpu) and then (effectively) threatened to fire everybody involved in the 16-way project.

The 3081/3084 finally saw MVS SMP support finally extended to >2-way. The 3081/3084 also saw a lot of effort go into minimizing cache-line thrashing. Storage allocation was redone to be cache-line sensitive and various modules with internal variables were redone to separate various things into different cache lines, various control blocks redone to separate certain critical variables into different cache lines. This didn't eliminate cache-line thrashing when different CPUs needed the same variable ... but at least it mitigated cache-line thrashin when different CPUs needed different variables that happened to reside in the same cache line.

smp & cluster refs:
https://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

I hate Compaq

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I hate Compaq
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 00:52:31 GMT

Anne & Lynn Wheeler writes:
the original translation of the 5-way VAMPS to standard vm/370 product had nearly zero locking & queuing SMP overhead (and achieved hardware utilization thruput of the processors) i played some tricks

most recent VAMPS overview (posted here 18aug)
https://www.garlic.com/~lynn/2001i.html#2

in fact, in the above translation from VAMPS to standard 370 ... there were a large number of situations where the above implementation saw greater than two times the effective thruput of a uniprocessor ... even when each processor was running 10 percent slower (nominal hardware rating of two processors were 1.8 time that of a uniprocessor).

the issue was that standard 370 of the era took big cache-miss penalties on interrupts ... i.e. application program chugging along just fine and in comes a I/O interrupt which jumps into the kernel, handles the I/O and eventually preculates back to the application. An implicit side-effect of the way that some of the code executed on a 2-way, in a large number of situations tended to keep the kernel execution on the same processor (w/o bottlenecking on a kernel lock) that it was already executing on (a kind of processor afinity). The improvement in cache-hit efficiency (corresponding reduction in cache-miss inefficeincy) would result in greater than twice the thruput of a uniprocessor (even tho the native hardware was effectively only 1.8 times that of a uniprocessor).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

OT - Internet Explorer V6.0

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 07 Sep 2001 14:16:08 GMT

Lars Poulsen writes:
A good ethernet adapter for S/370 coupled with "LAN Manager for MVS" would have served both IBM and customers very well. Never figured out why you guys didn't just do it.

we got in a whole lot of trouble when we presented the "invention" of 3-layer architecture with a ethernet-based example.

the T/R people were doing 16mbit T/R theoritical comparisons against a old-style e-net theoritical comparison (3mbit/sec e-net that didn't have listen before transmit). The SAA people that wanted to see client/server start to be much more server-based were also upset.

there were a couple of e-net articles in '88 ACM SIGCOMM with regard to typical e-net adapter card thruput being around 95% of media thruput ... and typical aggregate e-net thruput being at 95% of media thruput dropping off to around 85% of media thruput under some worse=case scenerios (typical LAN with all nodes in tight device-driver loop transmitting minimum sized packets as fast as possible).

by comparison the typical 16mbit t/r card sustained thruput was around under 2mbit/sec ... and typical aggregate 16mbit t/r media was less than 1/2 media thruput. The Austin group had done a custom ISA 4mbit t/r card for the PC/RT ... but the whole corporation had to use the PS/2 microchannel 16mbit t/r card. The PS/2 microchannel 16mbit T/R card had lower (per card) sustained thruput than the Austin ISA 4mbit T/R card.

Part of the issue was that both client/server as well as 3-layer have asymmetric traffic flows (i.e. some server has to see the aggregate traffic of all its individual clients) while all the 16mbit T/R cards (even the ones in 370 controllers) were essentially the same, targeted at effectively random, symmetrical traffic flows ... no single node seeing any more traffic than any other node.

misc sigcomm refs
https://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
https://www.garlic.com/~lynn/2000f.html#39 Ethernet efficiency (was Re: Ms employees begging for food)

the other issue was that SNA didn't have any networking protocol/layer ... as a result T/R had to be all bridged (all nodes effectively had to see all broadcasts). By comparison, TCP/IP with a network layer allowed for routers so that all segments didn't have to see all broadcasts. The twisted-pair enet standard even ran over the same CAT4 wiring that might have been originally installed for T/R.

I had worked on the original mainframe TCP/IP support and had done the RFC 1044 support doing some tuning of the thruput at cray research between a 4341 and a cray. The nominal mainframe TCP/IP support at the time would just about consume a single 3090 processor doing 44kbytes/sec. By comparison, the 1044 support on the 4341 ran with lots of waitstate doing channel thruput (1mbyte/sec) transfers to the cray.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Parity - why even or odd (was Re: Load Locked

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 14:21:58 GMT

jcmorris@mitre.org (Joe Morris) writes:
Part of this is my background: in the IBM mainframe world, the cylinder/head/record identifier for a particular unit of recorded information on a random-access device is referred to as the "disk address". (Then there's the "full disk address" of the form MBBCCHHR (pronounced "mumble"). Can anyone who never needed to set the BB field to a nonzero value tell the class what it was used for?)

the data noodle (sometimes turning it into spaghetti) ... random refs
https://www.garlic.com/~lynn/2000.html#9 Computer of the century
https://www.garlic.com/~lynn/2000b.html#41 How to learn assembler language for OS/390 ?
https://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
https://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Title Inflation

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Fri, 07 Sep 2001 15:43:19 GMT

Charles Richmond writes:
I prefer "The Master of Space, Time, and Dimension" as my title... IIRC, Isaac Azimov had business cards that said: "Isaac Azimov, Natural Resource". Perhaps that would be adequate for a title...

i once reported to an executive (for a time, i was the only person that reported to him, it was a form of punishment) ... who had business cards presented to him by the CEO that said corporate gadfly. I managed most of my career to have business cards w/o any title what-so-ever. A number of situations were interesting, people not knowing how to deal with you if you lacked a title.

On the other hand, i had one of the first business cards with an email address.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

OT - Internet Explorer V6.0

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,comp.lang.cobol,alt.folklore.computers
Date: Fri, 07 Sep 2001 17:12:33 GMT

"Editor" writes:
My point was - The line between "Mainframe" and "PC" is bluring very quickly. I don't care if it's MVS/Windows/Unix or some OS yet to be invented, the cost/size/technology involved is all mushing together. And what will drive existing "big iron" users to smaller systems based on RISC or Intel Processors is pure cost. Cost of the iron and mostly cost of the maintenance fees.

the counter-argument in the above is that many of the commondity/volume platforms may have much of the feature/function ... they are still lower down the curve in many of the business continuity areas.

in the late '80s ... after something like 20 years in the mainframe space, my wife and i started doing clustering on "commodity" priced platforms (she had done stint in POK in charge of loosely-coupled architecture and originated Peer-Coupled Shared Data ... later basis for ims hot-standby & sysplex). some number of the biggest current proponents of clusters were some of staunchest advisaries at the time.

we were also doing things like disaster survivability & geographic survivability (terms we had coined). we got a chance to author sections of the corporate continuous availability strategy document ... but both rochester & POK non-concurred ... and most of our stuff was pulled from the document.

random refs:
https://www.garlic.com/~lynn/subtopic.html#hacmp
https://www.garlic.com/~lynn/99.html#47 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
https://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
https://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
https://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
https://www.garlic.com/~lynn/2001d.html#47 Just a guick remembrance of where we all came from
https://www.garlic.com/~lynn/2001g.html#44 The Alpha/IA64 Hybrid
https://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2001i.html#48 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2001i.html#49 Withdrawal Announcement 901-218 - No More 'small machines'

a big factor in iron cost started being volume (lots of huge up-front costs that had to be amortized across the pieces).

in the mid-80s, I once observed that a $300 CDROM player had more advanced technology than a $20,000 fiber-optic modem, claiming that I could essentially build a better fiber-optic modem from parts out of a $300 CDROM (in fact there were then some fiber-optic modems built from essentially CDROM optical drivers, the 6000 SLA was essentially a 10% faster escon ... running full-duplex instead of half-duplex, and optical drivers cost that were at least 1/10th that of escon's).

in the late '80s there was big government push in the HDTV area ... the commerce department essentially taking the position if non-US corporations dominated HDTV area ... that the associated technology volumes would allow them to then dominate all aspects of electronics hi-tech industry.

some random HDTV refs:
https://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2001.html#73 how old are you guys
https://www.garlic.com/~lynn/2001b.html#2 FCC rulemakings on HDTV

Effectively, the volumes associated with consumer electronics provided sufficient R&D funding that they could pass the pure hitech computer industry ... aka the volumes could drive design of better, faster, & less expensive chips.

There were some issues with quality ... but once the volumes got large enuf, many areas started finding that it was cheaper to put a lot of upfront costs into quality than the costs of the associated trouble calls & returns (commodity priced disks going from MTBF of 40k hours to 800k hours). In the disk area, if RAID was then layered on top, it really became a no-contest.

This carried over into the software arenea, for instance could (relative) low-volume operating systems maintain the new R&D technology investments that was going into the high-volume operating systems tracking newest technology advances.

In that sense, at some point a threshold was passed ... and the big iron environments had to start playing catchup (they still had their legacy apps of 30+ years). Some issue is does the legacy apps represent sufficient value and revenue flow to underwrite the necessary new R&D investment to keep abreast of what is going on in some of the higher volume market segments.

Amdahl gave a seminar at MIT around '71 analysing what part 360s would play in the marketplace (the audience did somewhat roast him for being a front for foreign interests based on the Amdahl corp business plan/funding). It included some observation about the amount of software investment in the legacy applications and the, then, projected costs of rewriting applications for a new or different platform ... which wasn't likely to happen any time in the next 30 years (it has now been 30 years). Part of the issue is that there has been some advances in software technology ... and there are some now standardized product offerings that offer the feature/function of the roll-your-own, ground-up legacy implementations (potentially significantly mitigating the rewriting argument).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Parity - why even or odd (was Re: Load Locked

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 17:17:27 GMT

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Parity - why even or odd (was Re: Load Locked

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 17:20:16 GMT

Anne & Lynn Wheeler writes:
can you imagine being a beta-test site for the original CICS AND doing it on one of the mumble/noodle things.

and the noise at IPL/boot time ... ker-chunk, whirl, ker-chunk, whirl, ker-cunk, whirl, ker-chunk, whirl ... as the VOLSERs were being read.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Help needed on conversion from VM to OS390

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Help needed on conversion from VM to OS390
Newsgroups: bit.listserv.ibm-main
Date: Fri, 07 Sep 2001 18:12:06 GMT

FarleyP@BIS.ADP.COM (Farley, Peter x23353) writes:
Sort of a poor-man's one-way "named pipe" for small amounts of data. In the VM world, this allows disconnected virtual machines (running but not connected to any terminal) to perform services for logged-on users who send their requests to that disconnected VM by name via the SMSG command.

Without having to do your own socket programming, is this capability not available under OS390? Did IBM (or anyone else) port the VM/CMS WAKEUP/SMSG code to OS390 by any chance?

it was used by the author of rexx in the very early '80s to implement and deploy a multi-user spacewar game. since the internal networking supported SMSG ... is was possible to propagate SMSG across the network (the internal network was the largest network in the world at the time) ... and have mulit-user spacewar with users on multiple different machines.

random refs
https://www.garlic.com/~lynn/2001f.html#10 5-player Spacewar?
https://www.garlic.com/~lynn/2001f.html#12 5-player Spacewar?
https://www.garlic.com/~lynn/2001f.html#13 5-player Spacewar?
https://www.garlic.com/~lynn/2001f.html#14 5-player Spacewar?
https://www.garlic.com/~lynn/2001f.html#51 Logo (was Re: 5-player Spacewar?)
https://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
https://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Pentium 4 SMT "Hyperthreading"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pentium 4 SMT "Hyperthreading"
Newsgroups: comp.arch
Date: Sat, 08 Sep 2001 04:09:03 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
The point is that using a basic SMP model, yet using a pool of execution units for all CPUs, is an old idea. I can't offhand think of an old system that did it at the ALU level, but it was and is absolutely standard practice at the I/O and memory access level. And there is no CONCEPTUAL difference between those and ALUs in this context. Well, let's ignore the term and consider the known properties.

in the early to mid 70s there was a dual i-stream 370m195 project (that never shipped). basically branches drained the 195 pipeline (unless they branched/looped within the pipeline) ... and very few codes kept the pipeline feed and all the units busy.

The project added 2nd instruction stream with 2nd PSW and 2nd set of registers and a 1bit flag on all work in the pipeline (used to indicate the instruction stream).

The idea was that the dual i-stream had a better chance of keeping the pipeline & units fed ... at a relatively trivial incremental hardware cost.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Title Inflation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Sat, 08 Sep 2001 15:58:14 GMT

jcmorris@mitre.org (Joe Morris) writes:
What time frame, and what network?

internal network, 70s (I had already moved to san jose, so late '70s). world-wide internal network was larger than arpanet/internet until '85 or so. got to add a arpanet mailing address to the card in late '82 when the gateway was installed.

misc. ref:
https://www.garlic.com/~lynn/internet.htm#0

in the great cut-over to IP/internet protocol jan83 there were 200 or so arpanet nodes, at which time the internal network was nearing 1000 nodes, which it passed later that year:
https://www.garlic.com/~lynn/internet.htm#22
https://www.garlic.com/~lynn/internet.htm#27
https://www.garlic.com/~lynn/internet.htm#29

random refs:
https://www.garlic.com/~lynn/subpubkey.html#networking

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Title Inflation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Sat, 08 Sep 2001 17:11:46 GMT

Anne & Lynn Wheeler writes:
internal network, 70s (I had already moved to san jose, so late '70s). world-wide internal network was larger than arpanet/internet until '85 or so. got to add a arpanet mailing address to the card in late '82 when the gateway was installed.

i think in '78, i managed a 16,000 entry email "nickname" file (which wasn't even a significant percentage of the total possible). The internal network nodes tended to be large time-sharing systems with hundreds or thousands of userids each (world-wide number of employees was nearing half million). The nickname file almost doubled in size over the next year ... this was slightly before we started building & deploying the online internal phone book infrastructure and put in the infrastructure for adding email addresses to the entries.

In the '80s there was a student that sat in the back of my office for 9 months taking notes on how i communicated (phone calls, face-to-face, meetings) ... and had access to all my email and log of all my immediate messages. The analysis resulted in Stanford PhD thesis on computer mediated communication (joint with language and computer AI departments). The author has since done a number of books and papers, one of the more recent is Knowledge Machines, Language and Information in a Technological Society.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Title Inflation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Sat, 08 Sep 2001 19:51:11 GMT

Anne & Lynn Wheeler writes:
i think in '78, i managed a 16,000 entry email "nickname" file (which wasn't even a significant percentage of the total possible). The internal network nodes tended to be large time-sharing systems with hundreds or thousands of userids each (world-wide number of employees was nearing half million). The nickname file almost doubled in size over the next year ... this was slightly before we started building & deploying the online internal phone book infrastructure and put in the infrastructure for adding email addresses to the entries.

and the little oops in the 80s where i accidentily bcc: the wrong list and it went out to over 20,000 people

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Title Inflation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Sat, 08 Sep 2001 20:00:35 GMT

Anne & Lynn Wheeler writes:
i once reported to an executive (for a time, i was the only person that reported to him, it was a form of punishment) ... who had

oh, and the reason for the above ...
https://www.garlic.com/~lynn/2001g.html#6
https://www.garlic.com/~lynn/2001g.html#5
https://www.garlic.com/~lynn/2001g.html#7

from the above
Tandem Memos n. Something constructive but hard to control; a fresh of breath air (sic). "That's another Tandem Memos." A phrase to worry middle management. It refers to the computer-based conference (widely distributed in 1981) in which many technical personnel expressed dissatisfaction with the tools available to them at that time, and also constructively criticized the way products were [are] developed. The memos are required reading for anyone with a serious interest in quality products. If you have not seen the memos, try reading the November 1981 Datamation summary.

it was made worse by some ref in the datamation article to the effect that i was worth my weight in gold (don't i wish) & some anonomous person(s) put together a 300 page compilation in tandem 3-ring binders and sent one to each member of the corporate executive committee.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Whom Do Programmers Admire Now???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Whom Do Programmers Admire Now???
Newsgroups: alt.folklore.computers
Date: Sat, 08 Sep 2001 20:16:47 GMT

Bernd Felsche writes:
I think it's spelt "JAVA" now. :-)

precursor to JAVA ... the spring project ... i've got the collection hardcopy (at one point, we had been invited to work on the project) but the softcopy URL no longer seems to work.

http://www.sun.com/technology-research/spring/
NOTE: above gone 404, current: (also gone 404):
http://java.sun.com/people/kgh/spring/
BUT: there is the wayback machine:
https://web.archive.org/web/20030404182953/http://java.sun.com/people/kgh/spring/

From one of the Spring Papers:
A Client-Side Stub Interpreter

Petere B. Kessler

Abstract

We have built a research operating system in which all services are presented through interfaces described by an interface description language. The system consists of a micro-kernel that supports a small number of these interfaces, and a large number of interfaces that are implemented by user-level code. A typical service implements one or more interfaces, but is a client of many other interfaces that are implemented elsewhere in the system. We have an interface compiler that generates client-side and service-side stubs to deliver calls from clients to services providing location transparency if the client and server are in different address spaces. The code for client-side stubs was occupying a large amount of the text space on our clients, so a stub interpreter was written to replace the client-side stub methods. The result was that we traded 125k bytes of stub code for 13k bytes of stub descriptions and 4k bytes of stub interpreter. This paper describes the stub interpreter, the stub descriptions, and discusses some alternatives.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Big black helicopters

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big black helicopters
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 08 Sep 2001 22:45:30 GMT

"del cecchi" writes:
Sorry charlie, the consent decree against IBM was in 1956 and involved punch cards. The case that was filed in the 60's, last day of the Johnson administration as I recall, was eventually totally dropped, many years later.

The government couldn't even prove what the market was that IBM was alleged to have monopolized.

i was recently talking to somebody that worked with TJW jr. ... who quoted him as saying something to the effect that the johnson case had taken all the interest out of running the company ... that it was no longer possible to make business decisions based on the business ... but all decisions were being made with respect to perceived gov. reaction.

random refs:
https://www.garlic.com/~lynn/94.html#44 bloat
https://www.garlic.com/~lynn/96.html#20 1401 series emulation still running
https://www.garlic.com/~lynn/99.html#231 why couldn't others compete against IBM
https://www.garlic.com/~lynn/2001j.html#23 ot - internet explorere v6.0

from above:
An "expert witness" representing one of the companies (that left the business) testified regarding the state-of-the-art in the late 50s. Supposedly in the late 50s ALL of the computer companies realized the SINGLE MOST IMPORTANT criteria to be successful in the computer business was to have compatibility across the whole computer line, from entry level to the largest machine. The witness went on to observe that only one company was successful in meeting this goal, all the other companies failed. The remaining companies failed to adequately deal with multiple plant operations (each responsible for a particular model in the product line) that locally optimized the hardware architecture/implementation for the specific model.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Title Inflation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Sat, 08 Sep 2001 22:53:01 GMT

Anne & Lynn Wheeler writes:
oh, and the reason for the above ...
https://www.garlic.com/~lynn/2001g.html#6
https://www.garlic.com/~lynn/2001g.html#5
https://www.garlic.com/~lynn/2001g.html#7

oops, finger slip ... sorry about that

https://www.garlic.com/~lynn/2001g.html#6
https://www.garlic.com/~lynn/2001g.html#5
https://www.garlic.com/~lynn/2001g.html#7

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Military Interest in Supercomputer AI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Military Interest in Supercomputer AI
Newsgroups: comp.sys.super,sci.military.naval,us.military.army,alt.military
Date: Sun, 09 Sep 2001 01:01:19 GMT

rick303@hotmail.com (rick++) writes:
They were the primary funders of university computer science and AI from the 1950s to the 1980s (when commercial funding increased). The ARPA in the ARPANet and the InterNet was called before 1988 stands for [Defense Department] Advance Research Projects Agency.

This invoked feelings of guilt in leftist compsci profs. For example read Terry Winograds of Stanford essays on the issue.

from:
http://www.212.net/business/jargon.htm
https://web.archive.org/web/20020601123619/http://www.212.net/business/jargon.htm
[artificial intelligence]
n. The opposite of natural silliness. n. A research topic in Computer Science. Some in the computer industry seem to think that nothing useful can come out of artificial intelligence (but they don't trust the natural kind, either).

then there is

p.b.andersen, a theory of computer semiotics, cambridge university press,1990.

basically saying that as one of the fathers of AI ... he realizes that it was all wrong.

somewhat off-topic, terry was thesis adviser for phd in following
https://www.garlic.com/~lynn/2001j.html#29

related to supercomputers:
https://www.garlic.com/~lynn/95.html#13

and really off-topic ... relation to electronic commerce
https://www.garlic.com/~lynn/2001i.html#52

lot of money was channeled thru ONR ...
https://www.garlic.com/~lynn/2000b.html#41

random discussions about arpanet (and the internal network)
https://www.garlic.com/~lynn/internet.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Proper ISA lifespan?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proper ISA lifespan?
Newsgroups: comp.arch
Date: Sun, 09 Sep 2001 02:57:46 GMT

cecchi@signa.rchland.ibm.com (Del Cecchi) writes:
The S/38 had a tag bit per 4 bytes as I recall. The PowerPC/AS has a 65th bit, or tag bit for every 8 bytes. How could they argue about needing it?

620, wasn't that the abortive attempt to make a processor that was both Power and X86? To run the Workplace OS?

from an old news article (note end of last paragraph)
THE AS/400 - TAKE A NEW POWERPC, ADD WORKPLACE, TOP WITH TALIGENT (October 7th 1994) Where will the Workplace microkernel appear first? Which machine will get the most powerful PowerPC processors first? The new parallel RS/6000s? No. The SP2? No. In fact, the PowerPC 630 will debut in IBM's AS/400. You've probably glazed over already at the mention of IBM's workhorse midrange system, but IBM's Rochester division is one of the most technologically hungry operations around. Pushing technology to the limit is a brave (read risky) strategy for a machine which has made its name by appealing to the non-technical user with a penchant for shrink-wrapped software and low maintenance bills. However if things go to plan, within a couple of years the AS/400 will be transformed into a catch-all machine, capable of running Unix and OS/2 applications and Taligent frameworks alongside its traditional OS/400 programs. That's all thanks to a software strategy based around the Workplace microkernel. At the same time the division is hoping to broaden the spread of applications through an increase in processing power - hitherto, the sensible user has not tried to use the AS/400 for processor-intensive work.

Such was Rochester's impatience for high-end PowerPC processors that it has been forced to design its own variants. Rochester's silicon had its first outing this week, with the resurrection of the System/36. Actually, resurrection isn't the best word, since the System/36 resolutely refused to die, despite the company's best efforts to move users onto the AS/400. According to official IBM figures there are still around 208,000 System/36 units chugging away worldwide. The new box, (see story 1189) marks the System/36's re- habilitation - but it also provides the Rochester labs with a dry run for the PowerPC AS/400 proper.

The machine's single-chip processor is a Rochester-designed 64-bit device which can almost, but not quite, be called a PowerPC. The only reason it cannot is that it only runs in 64-bit mode and cannot be switched to run as a 32-bit device, according to Frank Soltis, the AS/400's Senior Engineer and Scientist. Since the System 36's operating system is a 64-bit affair anyway, that is fine. Soltis says that while the processor shares some common technology with the PowerPC 620, it cannot really be called a variant.

Next summer the chip will be modified to incorporate a 32-bit/64-bit switch and it will become a true PowerPC processor. This will be used in the System/36 but also in a low-end AS/400. At the same time, a high-end RISC AS/400 will be launched using the multi-chip implementation of the PowerPC 630 (story 1178). Exactly how wide this chip's data registers are has been the cause of some confusion; it is a straightforward 64-bit PowerPC, says Soltis. The confusion is caused by the logical tag bit that the AS/400 uses to maintain data integrity. The bit is flagged when an object has a valid address and prevents unauthorised object usage. About three years ago, there was a suggestion that these bits should be incorporated into the processor (making the registers 65 bits wide) but this idea was junked to ensure compatibility with the 64-bit PowerPC according to Soltis. The tag bits are actually packaged with the error correcting code for the main memory and caches.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Proper ISA lifespan?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proper ISA lifespan?
Newsgroups: comp.arch
Date: Sun, 09 Sep 2001 03:12:58 GMT

Anne & Lynn Wheeler writes:
from an old news article (note end of last paragraph)

while i was at it (little problem with states in the following) ...
MORE POWERPC 630 DETAILS REVEALED; AS/400 EARLY VERSION NEXT YEAR (October 7th 1994) Next year IBM will launch a high-end AS/400 containing a multi-chip implementation of the PowerPC '630' (nee POWER3) processor. According to Frank Soltis, chief architect of the AS/400, the aim is to get the 630 onto a single chip during 1996. In the meantime, IBM's Rochester, Illinois facility has designed its own multi-chip variant: "We wanted the 630 architecture and could not wait for the single chip", he said.

Rochester's proto-630 implementation uses seven chips. All the execution units together with an instruction cache are bundled onto the first. The floating point unit gets chip two to itself, while chips three, four, five and six provide 256kBytes of data cache. The final part handles I/O. Details of exactly how many execution units are present were not to hand, but Soltis says that the multi-chip implementation can dispatch four instructions per cycle and up to 13 instructions can be executing concurrently. This disparity between maximum number of instructions dispatched and maximum executing sounds a little odd, but if right, this will be a very highly scaled processor which should be virtually stall-proof.

In order to compensate for the comparatively sluggish inter-chip connections, the AS/400 unit is fabricating the multi-chip module in BiCMOS. However the "proper" single chip 630 will be fabricated in the cheaper & slower CMOS like the rest of the PowerPC family. Soltis says that the multi-chip part is currently sampling and running in the labs at 200MHz. Initially, it will be driven at a lower clock-speed, giving IBM some headroom for performance expansion - expect next year's AS/400s to run at something like 150MHz or 166MHz. Whether the finished 630 will actually squeeze down onto a single chip is still a moot point. There is a possibility that it will end up with the cache on a separate piece of silicon to the rest of the processing units.

In a departure from the PowerPC norm, the 630 contains extra instructions, requested by IBM's RS/6000 and AS/400 divisions. So, according to Soltis, it contains special hooks for interfacing with matrix-manipulation processors, as requested by the RS/6000 division. Meanwhile the AS/400 developers asked for, and got, special memory-addressing modes, string manipulation and decimal arithmetic. Historically, the PowerPC 630 started life as the POWER3 architecture, and was subsequently handed over to the Somerset joint design lab.

The inclusion of IBM-specific (and possibly undocumented) instructions into the 630 looks a little strange in the context of promoting PowerPC as a vendor-neutral processor standard. Indeed, Soltis admits that Motorola is currently muttering that it doesn't really want matrix-manipulation hooks and the like. However, he says that the extra functions take up very little extra silicon real estate and that by the time the chip comes out, Motorola and Apple might be grateful for the extra facilities.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Big black helicopters

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big black helicopters
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 09 Sep 2001 03:25:38 GMT

"Rostyslaw J. Lewyckyj" writes:
Yes. But the pressure of the government anti monopoly suit caused IBM, as part of the defensive maneuvering, to change some of its behaviour and policies so that they would no longer be held up as accusations by the other aggrieved companies. IBM unbundled its software, opened up on interface specs to third party oems, changed rules about hardware support for things like non IBM central memory, changed some marketing practices. etc. So that by the time the suit was dropped the goals of the suit had been achieved anyways. Unfortunately the US vs MSFT suit has not dragged out long enough to bring about the same kind results.

as per previous posting ... some of the vendors testified in the case that it wasn't IBM practices, it was their problem not getting right & meeting the acknowledged single most important market/business requirement.
https://www.garlic.com/~lynn/2001j.html#33

on the other hand ... i've also been blamed for originating the PCM (plug compatible manufactur aka OEM, other equipment manufactur) controller business
https://www.garlic.com/~lynn/submain.html#360pcm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Big black helicopters

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big black helicopters
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 09 Sep 2001 13:12:04 GMT

"Rostyslaw J. Lewyckyj" writes:
Whatever some vendors testified, and whatever you have been blamed for doesn't matter. The suit caused IBM to change many of its business policies and practices so as to make the suit moot by the time it was dropped. I wish that was also the case in US vs MSFT, but I don't see it. --Rostyk

no, i believe that over the course of the case the position changed (possibly numerous times), effectively that original position was not valid based on what vendors testified (that they went out of business because of various ibm business practices).

almost all the things that is cited about ibm changing had essentially nothing to do with those vendors going out of business ... the things cited had to do with encouraging brand new business in the ibm customer marketplace aka rather than other computer manufactures having relief with regard to the data processing customer ... "relief" had to do with brand new little guys being able to compete for bits & pieces of ibm data processing business ... the PCMs, maint. contract, software, etc (not relief for other computer manufactures).

from that stand-point one might conjecture that once the case had been filed and went on for so long ... something was needed to show for the efforts ... even if it may not have had nothing at all to do with the original filing.

In that sense, one might conclude that there was no real problem found with the majority of ibm business practices ... but IBM was still big (not necessarily because it did something unethical & drove other vendors out of business, but because it was the only vendor that met the single most important market requirement) ... and just being big was somehow bad.

If it couldn't be made less big because of the original definition of data processing market ... then the whole definition of what was the market would be changed and attempt to make IBM less big that way (pcm gear, maint. contract, leasing business, software, etc).

The point was that the original target (computer vendors being forced out of business based on various policies & practices) was moot based on those vendor testimonies ... so the whole focus changed in order to achieve an objective of size reduction. From that standpoint, one could conclude that big is bad ... regardless of the reason.

During the course of the case, some of the things were humorous in retrospect. The ruling about arbritrary retention of paper was one such. At one point, because of running out of normal room for storage ... offices were being taken over and used. At one location (about 3 percent of total employees), they were consuming an office a day for paper storage and one building was in danger of exceeding the floor loading rating (presumably if there had been accurate prediction about the length of the case and the elapsed time of the paper retention ruling ... then massive new paper storage facilities could have been started earlier).

1) the comment about vendor's testimony was with regard to the original point of the case ... which, since there was no case on that basis ... there was some random walk that occurred to find some other reasons.

2) the comment about PCM market forces ... was that it didn't exist when the original case was filed ... it only emerged during the long course of the case. since it didn't exist when the case was filed ... then one might conclude that it was added afterwards, after the original target didn't pan out (because of those vendor's testimony).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Big black helicopters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big black helicopters
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 09 Sep 2001 13:30:39 GMT

Anne & Lynn Wheeler writes:
2) the comment about PCM market forces ... was that it didn't exist when the original case was filed ... it only emerged during the long course of the case. since it didn't exist when the case was filed ... then one might conclude that it was added afterwards, after the original target didn't pan out (because of those vendor's testimony).

... aka, if i get blamed for originating the pcm controller market ... there is a small chance that I might know when I did the work.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Big black helicopters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big black helicopters
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 09 Sep 2001 15:34:58 GMT

Anne & Lynn Wheeler writes:
During the course of the case, some of the things were humorous in retrospect. The ruling about arbritrary retention of paper was one such. At one point, because of running out of normal room for storage ... offices were being taken over and used. At one location (about 3 percent of total employees), they were consuming an office a day for paper storage and one building was in danger of exceeding the floor loading rating (presumably if there had been accurate prediction about the length of the case and the elapsed time of the paper retention ruling ... then massive new paper storage facilities could have been started earlier).

office a day ... about 10x10x6 or 600 cubic feet of paper per day per 3 percent of employees or 200 cf/1 percent of employees per day or possibly 20,000 cf of paper per day for the company ... all under mandated court order retention.

a dump on 14inx11in paper (say approx. sq foot) would be 4in to 12in thick. just for debugging there would between one and three dumps per cubic foot. a location with 12,000 employees at minimum of 3 dumps per cubic foot & 600 cubic feet ... works out to about 1.5 dumps per day per person (or only .5 dumps per day per person at 12in thick dumps). Then there would be compilations, program listings, and a bunch of other stuff ... maybe 2-3 times per day.

This would have been those 1403N1 printers at 1100 lines per minute; at 66lines per page, about 1000 pages/hr. at about 250 pages per inch, that is 4inch, square foot, per hr per printer or about 8 cubit feet per printer per day (lots of output might only have 2/3rds the line density per page of dumps ... resulitng in 5in to 6in square foot, per hr per printer). 600 cubic feet would be about 75 such printers or about one such printer for every 160 employees. Such a location probably had closer to 100 mainframe systems with 2-3 1403N1s per system (more like 200-300 1403N1 printers).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Big black helicopters

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big black helicopters
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 09 Sep 2001 18:25:55 GMT

the gov. decides to file an anti-trust case against a vehicle manufactur because it has 60 percent of the muscle car market ... and think that they had to have done something bad to obtain 60 percent market share. They bring in all the other vehicle manufactures to testify about all the bad stuff. The other vehicle manufactures testify that all the customer serveys have shown that what the market really wants is a metal-flake, candy-apple red paint job and none of them could bring themselves to produce a car with such a paint job (and the only manufactur that was willing to produce what the customer wanted is the reason that manufactur got 60 percent market share).

The gov. mulls this over for a large number of years ... and finally says that they will drop the case if the company unbundles its muscle car manufacturing and allows customers to just buy the (metal-flake, candy-apple red) shell and force the customer to do after-market assembly of the motor, wheels, transmissions, steering, brakes, glass, seats, dashboard, interior, brakes, etc.. Furthermore, unbundled car manufacturing wasn't a standard business practice (by anybody) prior to filing the case and the gov. had to help invent/promote whole new industries and businesses practices in the market (like the after market vehicle assembly industry which never existed anywhere prior to the filing of the case ... i.e. at best, the gov. could claim that industry-wide business practices by all vehicle manufactures where inhibiting the invention of businesses like the after-market vehicle assembly industry).

Also, during the lifetime of the case, the total vehicle market share of muscle cars declines by a factor of 3-4 times.

Now, many years later, there are a whole bunch of businesses in all segments of the after-market vehicle assembly industry (not just muscle cars) ... and a new manufactur comes on the scene and attempts to capture the industry with integrated, bundled, fully-assembled and tested vehicle. While in the original case, there was no competition that could complain about business practices under the gov. anti-trust regulations (the original case had effectively been filed under a completely different premise than what was settled) ... there are now large number of businesses that wish to complain about business practices.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Disaster Stories Needed

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disaster Stories Needed
Newsgroups: alt.computer.consultants,alt.disasters.misc,comp.arch.storage
Date: Sun, 09 Sep 2001 23:54:27 GMT

Tony Toews writes:
So the moral here is make sure your offsite backup is a good distance away, at least several miles.

in past discussions on this ... it was suggested 40 miles ... but even then there should be some checking regarding common failure modes ... like on the same flood plain.

then there are little things like the financial transaction data center that had their roof collapse in a snow storm and their disaster backup site was in the world trade center

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Does "Strong Security" Mean Anything?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Does "Strong Security" Mean Anything?
Newsgroups: comp.security.misc
Date: Mon, 10 Sep 2001 00:09:54 GMT

"Andrew" writes:
I've noticed that MS uses the terms to generally indicate 56 bit or 128 bit Encryption.

generically, security is typically considered to be needed proportional to the risk ... in that case, strong/weak would be considered with regard to some security relative to what is being protected.

ancilliary is strong/weak authentication in conjunction with strong/weak security. strong authentication as part of strong security then could also be relatively to what is at risk ... but strong authentication is more likely to be associated with two or three factor authentication (than just single factor authentication).

also see security glossary at
https://www.garlic.com/~lynn/secure.htm
& related
https://www.garlic.com/~lynn/index.html#glossary

somewhat related ... risk management (assessing relative security against risks):
https://www.garlic.com/~lynn/subintegrity.html#fraud Risk, Fraud, Exploits
https://www.garlic.com/~lynn/2001c.html#61 Risk management vs security policy
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aepay3.htm#riskaads AADS & RIsk Management, and Information Security Risk Management (ISRM)
https://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
https://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay3.htm#x959risk3 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay3.htm#x959risk4 Risk Management in AA / draft X9.59

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

OT - Internet Explorer V6.0

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,comp.lang.cobol,alt.folklore.computers
Date: Mon, 10 Sep 2001 02:33:50 GMT

"Peter E. C. Dashwood" writes:
Could I suggest a reason here?

It has to do with "granularity".

Wherever a "collection" of objects is required to achieve a purpose, "small" is very often more useful than "big".

Consider the following examples...

1. Building a house from bricks. Selecting a larger brick size will allow the house to be built with less effort, but it will constrain the dimensions and details. A balance must be struck. If the artistic integrity is more important than the time to construct, then smaller bricks are better.

2. A LARGE collection of SMALL objects has more inbuilt redundancy and consequent durability, than a SMALLer collection of LARGE objects.

Consider ARPANet (from which the Internet largely evolved). It was a military network designed to sustain heavy damage in the event of Nuclear attack, without failing completely. Whole nodes could be eliminated but, as there were thousands of them, command and control traffic could re-route itself and continue to flow.

some of the rest of it ... if the bricks are actually too small .. then you loose structural integrity because all of the loading is basically carried by the mortar (until you switch paradigms with something like reinforced concrete).

while the ARPANet packet design addressed self-healing in relatively constrained infrastructure ... it didn't address what was important in networks and that was independent heterogeneous operation (aka ARPANet was relatively small number of homogeneous nodes). The internal network was actually larger than the ARPANet for most of the lifetime, which I claim was largely due to the fact that the primary internal network nodes effectively had the equivalent of heterogeneous gateway support in every node (something that the arpanet didn't get until the the great jan83 switch-over to ip protocol).

JES2 NJE implementation suffered many of the same short-comings as the original arpanet ... and in fact was so bad that frequently dissimilar releases of NJE could take down the whole MVS local node by attempting to process a package from a JES at a different release level. As a result, the JES2 nodes on the internal network were typically relegated to end-nodes with intermediate VNET nodes which had special gateways to produce/translate NGE headers that were guaranteed to be compatible with the specific release of JES2/NGE. This was not only a common shortcoming of arpanet and JES2 ... but a great many other network products of the 70s ... and even the lower-function communication products like various members from the SNA family.

the effectiveness of huge numbers of replicated smaller components can be inhibited because of faulty management & control infrastructures. Getting production quality, business continuity level self-repairing implementation right can be tricky.

An example is a strickly homogeneous implementation (like much of those done in the 60s and 70s ... with the possible exception of vnet of the internal network) can lead to lots of other kinds of failure modes and associated service outages (for instance simple release upgrades requiring that the whole infrastructure be taken down for an extended period of time ... the length of the outage that can be proportional to the number of units involved).

random refs:
https://www.garlic.com/~lynn/subpubkey.html#networking
https://www.garlic.com/~lynn/subtopic.html#hacmp Cluster, High Availability and/or Loosely-Coupled
https://www.garlic.com/~lynn/2001j.html#43 Disaster Stories Needed

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Big black helicopters

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big black helicopters
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 10 Sep 2001 13:02:50 GMT

Alan Greig writes:
And it is just so ironic that had IBM not had anti-trust worries they would never have given Microsoft the licensing terms they did. Bill Gates likes to say that he pulled the wool over IBM's eyes but the truth is IBM knew they had to tread carefully entering the PC game.

there was also more than a little bit of internal politics.

for some time there was a 20 person (growing to about 40 people) effort in the san jose area to do software. every month Boca would be polled about did it have any software intentions and did it mind if we did it; & boca would say, no it didn't have any software intentions. Then after quite a bit of time, Boca reversed its position and the San Jose group was disbanded (this was before announce and delivery)

frequently, from a corporate empire standpoint, it was "better" to have contracts with outside agencies for deliverables than to have other internal operations providing the deliverables.

for whatever reason, IBM also walked away from the option for 1/3rd ownership of Intel (and sold the 11?12? percent stake). I don't remember if this was before some internal groups were claiming that they could build a better and enhanced 386.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

OT - Internet Explorer V6.0

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,comp.lang.cobol,alt.folklore.computers
Date: Mon, 10 Sep 2001 13:15:03 GMT

Joseph J Katnic writes:
Mainframe clusters do this by having a whole other mainframe dedicated to the management of the data and locks across the cluster.

Super computers don't have this problem, because typically they only work on one task at a time. They take the partitioning approach. Each element of the super computer performs the same task on a different piece of data. A mainframe never knows what transaction will be coming next and so cannot make use of the partitioning scheme.

for the distributed lock manager in HA/CMP, we started with implementation that didn't require dedicated processor. This was what was used with parallel oracle (although the floating commits stuff didn't get deployed).

general ha/cmp references:
https://www.garlic.com/~lynn/subtopic.html#hacmp cluster, loosely-coupled

random connections
https://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Pentium 4 SMT "Hyperthreading"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pentium 4 SMT "Hyperthreading"
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 10 Sep 2001 13:28:11 GMT

Jan Vorbrueggen writes:
Indeed. Their closest relative probably are the CDC6600 PPUs, which alternated ten (IIRC) threads round-robin. Also IIRC, Tera doesn't waste cycles on non- runable threads, as the PPUs did, and can support many more (128?) simultaneous threads.

another would have been if VAMPS had shipped. This was 370/125 with two to five processing units ... the threading and dispatching was all done in the "micrcode" (i.e. hardware) ... although the thread ordering was updated by the CP dynamic, adaptive feedback scheduler. Since the control blocks for the threading were resident in real storage and had shared access with the kernel ... arbritrary large number of threads were supported.

There was some other similarity with the PPUs ... in that the 125 (and 115) memory bus had nine positions for microprocessors and the microprocessors could have arbitrary microcode/personalities loaded for them to act as various kinds of I/O processing units or (370) execution processing units.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Are client certificates really secure?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are client certificates really secure?
Newsgroups: comp.security.misc
Date: Mon, 10 Sep 2001 13:52:20 GMT

martin_macbean@hotmail.com (Martin MacBean) writes:
If we use a client certificate to authenticate one of our business partners, what's to stop one of their staff copying the certificate & using it on their own PC? As far as I can tell, the only thing protecting the client certificate store is a password, which in my book makes it less secure than a username/password pair (at least there are 2 elements to crack!).

Are there any other authentication options that allow installation onto 1 client & prevent copying onto other clients?

the certificate contains the public key ... the corresponding private key is the thing in the file protected by a password (this password is typically not stored &/or written down and is not known to other entities).

1) the public/private key pair has the advantage that there is no shared-secret (password) authentication that has to be stored at servers

2) in theory the same private key (since it isn't a shared-secret) can be used in lots of difference security domains. The public key may be known, but the public key is only used for authenticating, it can't be used for originating (as in the case of a shared-secret, one of the advantages of password protected private key as opposed to a shared-secret password). by comparison, in the case of a shared-secret password, the same value can be used for both originating & authenticating; thus the requirement that different shared-secret passwords be used in different security domains.

The short-comings of the software file private key is that the file can be copied and is subject to offline brute-force attacks.

The advantages of the public/private key implementation is that it is transparent to the server authentication implementation whether the client is using a software file private key or a private key hardware token rated at E4-high, i.e. it is possible to initially deploy a software implementation and then incrementally upgrade to hardware tokens starting with clients that have the highest risk exposure (giving 2-factor authentication ... something you have and something you know).

Note however, that public/private key implementations don't have to be deployed as certificate-based, they could also be deployed in a userid/public-key variety. An example would be a public-key enhanced RADIUS authentication server ... which could simultaneously support different userids using password authentication, challenge/response authentication, as well as public key authentication (where the public key is recorded in the RADIUS userid-associated database in place of a password).

NACHA recently finished a very successful pilot for ATM public-key authenticated debit transactions that involved a certificate-less deployment
https://www.garlic.com/~lynn/aadsm6.htm#aadsatm

security glossary
https://www.garlic.com/~lynn/secure.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Title Inflation

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Mon, 10 Sep 2001 14:08:55 GMT

jcmorris@mitre.org (Joe Morris) writes:
Curiosity question: how large was VNET in early 1985? The reason I'm asking is that in cleaning up my files in preparation for my every-two- years-move-to-a-different-office I ran across a listing dated 2/7/85 that listed all the nodes for ... um ... rummage through file cabinet...

i don't remember the date, but i seem to remember sometime in 1985, the internal network exceeded 2000 mainframe nodes (and had exceeded 1000 nodes in jun83) ... it took two years to double in size ... i've got a clear plastic "globe" round paper-weight that says VNET 1000 nodes, 1983 and had run across a '83 file of all node changes for that year ... but I don't seem to have any of the 2000 mark ... although I think there was a flat sq. paperweight (may be in a box someplace)

by comparison, with the arpanet cut-over to IP and gateways in Jan83, its growth really accelerated (although some large number of the nodes were things like sun workstations) ... i.e. there were something like 250 arpanet nodes at the time of the cut-over.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Big black helicopters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big black helicopters
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 10 Sep 2001 14:17:27 GMT

Alan Greig writes:
Yep agreed there were multiple actors but the decision making process you query above would have undoubtedly been influenced by anti-trust worries themselves. I've just noticed that in Time's coverage of recent developments in the Microsoft case they say:

my original posting in this thread:
https://www.garlic.com/~lynn/2001j.html#33

decisions were made at all levels of a company ... some lower-level decisions could have been compatible with worries about the anti-trust cases (but made for totally different reasons) ... and if some lower-level decisions were made differently, upper level executives could have reversed the decisions because of the anti-trust worries.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Are client certificates really secure?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are client certificates really secure?
Newsgroups: comp.security.misc
Date: Tue, 11 Sep 2001 13:03:29 GMT

martin_macbean@hotmail.com (Martin MacBean) writes:
As I suspected, once you release a public key into a third party's hands you are reliant on that party not to distribute the key further. As the clients are distributed in several remote branches, the chance of the key being copied & installed onto an unauthorised PC is quite high.

We have used hardware tokens for internal staff but the administrative overhead, cost & acceptability to our customers makes these prohibitive for this application. I'm not saying that the administration of software certs is a walk in the park, but in comparison it is easier.

What we really need is a key that can be installed once & once only onto a known client so that authentication of the client location can be guaranteed (I accept we won't be able to guarantee the user identification). Anything out there that'll give us this with costs & administrative overhead equivalent to digital certificates?

the issue isn't the public key in the certificate .... which is only the "authentication" part of the operation.

In shared-secret key scenerios the same key is used to originate the signing of a message as is used to authenticate the signature. As a result all the shared-secret based authentication mechanisms stipulate that different keys are used in every domain (since somebody at a server in one domain ... say your ISP ... could use your secret to origiante transactions with your bank).

in public/private key paradigms ... the operations are asymmetrical (not symmetrical, shared-secret) ... they key that origiantes &/or signs transactions is totally different than the key that authenticates transactions.

while a shared-secret paradigm almost works if a human only participates in a single security domain ... it real-life that is far from true ... an individual may have tens or hundres of security relationships ... and the shared-secret paradigm tends to totally disintergrate ... from a real-world practical view-point; although it is possible for institutions to ignore reality and choose to believe that the only relationship that an individual is ever involved in for their whole life is a single relationship with that institution.

a properly protected private key avoids much of such shortcomings. A single PIN/password is used to establish access to the private key in a hardware token. Since the PIN/password (and private key) is never divulged to any outside agency ... it represents a totally different risk/exploit paradigm aka shared-secret PIN/passwords are at risk & represent a totally different because they are shared with multiple parties; PIN/passwords for token activiation represent a totally different kind of PIN/password paradigm.

In an authentication model ... using a private key hardware token that is PIN/password activated ... you can have 2-factor authentication ... something the person "has" and something the person "knows" (typically both of them are assumed to be relatively unique ... aka the token is unique and the associated knowledge is unique and not-shared). By comparison, 3-factor authentication involves something you have, something you know and something you are (aka typically implemented as some form of biometrics).

In any case, 2-factor authentication that uniquely originates/signs transactions is significantly more secure than any shared-secret authentication paradigm ... even if the corresponding "public key" (used for message/signature authentication) is extremely widely distributed.

In fact, to keep from falling into some of the same human factors shortcomings as the current shared-secret paradigm (where a person is required to have a unique & different shared-secret authentication PIN/password for every type, kind, and instance of relationship) it would be preferrable not to require a person to possess and utilize hundreds of different tokens. In fact, one of the biggest "at risk" problems in the current shared-secret paradigm is that an individual is forced to actually use a few number of easily remembered shared-secret PIN/passwords. Since they are few in number, they are utilized in multiple different contexts ... opening the exploit that one institution can attack other institutions (using common shared-secrets). Also, since they are easily remembered, the are subject to brute-forced guessing.

Some institutions believe that isn't true and choose to assign arbitrarily difficult shared-secret PIN/passwords ... which results in the real-world scenerio of the individual recording all their (difficult) PIN/passwords ... which are then subject to copying.

specific artical from postings
https://www.garlic.com/~lynn/aepay3.htm#passwords

Password problems account for 20-50% of all calls to help desks, costing about a million dollars per year for a typical mid-sized company. About time we start taking the human factors of security seriously.

Passwords don't work: except for certain circus performers, nobody can remember a large number of random strings. And yet, how many security groups include a usability expert? (New York Times article: access requires free registration.). (August 5)

also referenced in similar thread last month in this n.g.
https://www.garlic.com/~lynn/2001i.html#36

effectively, shared-secrets paradigms quickly break down. It is then either hardware tokens &/or biometrics. However, to avoid having a shared-secret biometrics (i.e. like fingerprint centrally recorded at every institution), it has to be implemented in conjunction with some form of hardware token. The challenge then seems to be addressing the hardware token market inhibitors (cost, value proposition, ease-of-use, etc).

security glossary (see authentication related entries):
https://www.garlic.com/~lynn/secure.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Are client certificates really secure?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are client certificates really secure?
Newsgroups: comp.security.misc
Date: Tue, 11 Sep 2001 13:06:30 GMT

alun@texis.com (Alun Jones) writes:
I've seen other means of storing certificates, including little USB "keychain" devices that can be used as a certificate store.

the protection and storing (public-key) certificates isn't at issue ... since they are widely distributed and shared ... the protection and care of the private key is what is important in public/private key authentication paradigms.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Does "Strong Security" Mean Anything?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Does "Strong Security" Mean Anything?
Newsgroups: comp.security.misc
Date: Tue, 11 Sep 2001 13:20:38 GMT

Chanchao writes:
In my opinion there is no such things as weak security. Things are either secure (as secury as humanly possible) or they're not. Weak security sounds like getting your girlfriend 'a little bit' pregnant.

all security is relative ... ideally it is proportional to what is at risk ... so that the cost of an exploit is significantly higher than any expected benefits.

a recent similar discussion in some other security-related n.g.
https://www.garlic.com/~lynn/2001j.html#5


• physical security for the data processing room, motion detecters, guards, etc
• multiple layers of firewalls & packet filtering routers
• actual financial transactions performed on backroom dataprocessing
• equipment away from the actual web server
• fbi background checks for all employees
• security audits
• minimum business & security certification levels.

in many circumstances (and even with the internet today) ... possibly 90+ percent of security violations are "insider" exploits (like embezzling money) so protection against insiders is typically where 90 percent of security is focused in many environments (protection from outsiders might only represent 10 percent of the security procedures; aka the 10' thick bank vaults, armed guards, etc).

misc. risk, fraud, exploit threads:
https://www.garlic.com/~lynn/subintegrity.html#fraud

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

next, previous, index - home