2003 Newsgroup postings (09/7 - 10/03) Lynn Wheeler

2003 Newsgroup Postings (09/7 - 10/03)

Passwords multiply as users' rage rises
Password / access rights check
Seven of Nine
Password / access rights check
IBM Manuals from the 1940's and 1950's
Cryptoengines with usage accounting
The real history of comp arch: the short form
IBM Manuals from the 1940's and 1950's
post-doomsday computing
OSI not quite dead yet
OSI not quite dead yet
AES-128 good enough for medical data?
Seven of Nine
Cost of patching "unsustainable"
Seven of Nine
IEFBR14 Problems
OSI not quite dead yet
Throughput vs. response time
Threat Analysis and Threat Trees
Throughput vs. response time
360 Microde Floating Point Fix
Drivers License required for surfing?
Seven of Nine
Intel iAPX 432
Intel iAPX 432
Microsoft Internet Patch
Microsoft Internet Patch
Microsoft Internet Patch
SR 15,15
SR 15,15
Mail delivery failed: returning message to sender
SR 15,15 was: IEFBR14 Problems
SR 15,15 was: IEFBR14 Problems
MAD Programming Language
SR 15,15 was: IEFBR14 Problems
SR 15,15 was: IEFBR14 Problems
S/360 undocumented instructions?
S/360 undocumented instructions?
Questioning risks of using the same key for authentication and encryption
S/360 undocumented instructions?
MAD Programming Language
Issues in Using Virtual Address for addressing the Cache
S/360 undocumented instructions?
S/360 undocumented instructions?
MAD Programming Language
MAD Programming Language
OSI protocol header
Intel 860 and 960, was iAPX 432
Thoughts on Utility Computing?
public key vs passwd authentication?
public key vs passwd authentication?
public key vs passwd authentication?
public key vs passwd authentication?
model 91/CRJE and IKJLEW
Thoughts on Utility Computing?
public key vs passwd authentication?
model 91/CRJE and IKJLEW
wsmr-simtel20 shut down 10 years ago today
The End of Not-Moore's Law?
SR 15,15
S/360 undocumented instructions?

Passwords multiply as users' rage rises

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Passwords multiply as users' rage rises
Newsgroups: alt.folklore.computers
Date: Mon, 08 Sep 2003 04:35:14 GMT

Passwords multiply as users' rage rises
http://www.sunspot.net/news/bal-te.bz.passwords07sep07,0,5338372.story?coll=bal-home-headlines

Technology: As logins get more complex, people may be ones in need of memory upgrade.

.... and lighter side from past discussions:
https://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#53 April Fools Day
https://www.garlic.com/~lynn/2001d.html#62 OT Re: A beautiful morning in AFM.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Password / access rights check

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Password / access rights check
Newsgroups: sci.crypt
Date: Mon, 08 Sep 2003 14:28:23 GMT

alex221@pisem.net (Alex Prokhorov) writes:
I need to add security to my project and haven't done this before. What I have to do is to grant different users different levels of access to the features of the program. It is clear for me how to do it in case of simple allowed/denied access to the program. I just create text file with usernames and md5 hash of their passwords. But how and where to store access options? I suppose, that access options must be encrypted too (or maybe i'm not right?). Additionally i need an option for the admin to arbitrarily change access options for users without knowing their passwords. Anyone could please direct me. Thanks.

look at internet standard radius ... implementations in addition to storing userids, authentication information, and authorization information ... also tend to have infrastructures for managing the information. also internet AAA (authentication, authorization, and accounting):
http://www.aaaarch.org/index.html

pointer to current news article on passwords (shared-secrets)
https://www.garlic.com/~lynn/2003m.html#0 Passwords multiply as users' rage

some multics literature includes some discussion that security can't be added on, it has to be designed in:
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation

some recent radius discussions
https://www.garlic.com/~lynn/2003b.html#65 Storing digital IDs on token for use with Outlook
https://www.garlic.com/~lynn/2003e.html#59 Security in RADIUS (RFC2865)
https://www.garlic.com/~lynn/2003j.html#25 Idea for secure login

misc. past radius musings:
https://www.garlic.com/~lynn/subpubkey.html#radius

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Seven of Nine

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Seven of Nine
Newsgroups: alt.folklore.computers
Date: Mon, 08 Sep 2003 18:30:11 GMT

Pete Fenelon writes:
Most HR people are apparently ESFJs. There is no point of contact in the world view between a typical developer and a typical HR type. The developer (in broad terms) wants to be right, to be seen to be right, and to make things work. The HR types want to be seen to be part of the gang, to affirm that they're part of the gang, and to make everyone else feel like part of the gang. The developer doesn't even know or care that there's a gang. ;)

when group cohesiveness becomes the deliverable ... rather than one of the mechanisms used to achieve deliverables ... then aggressive accomplishment can be viewed as counter productive.

also, group cohesiveness is a refugee of the incompetent.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Password / access rights check

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Password / access rights check
Newsgroups: sci.crypt
Date: Tue, 09 Sep 2003 15:03:14 GMT

"Ben Mord" writes:
Vempu, I disagree that you cannot improve quality or security after the fact (although I would agree that each bug or security hole is typically harder to fix the later it is discovered and addressed.) Is not peer review itself an attempt to test and often add quality "after the fact"? Is SHA-1 not more secure than the original version?

I think that .. from previous post
https://www.garlic.com/~lynn/2003m.html#1 password / access rights check

the air force study with respect to multics is that it is hard to add-on qualtiy security. it is possible to patch bugs, but software products can be large enuf, that if things aren't done right from the start ... you can have hundreds or tens of thousands of little bug opportunities needing fixing that go on forever i.e. is the possibilty that each little bug gets fixed an indication of quality security ... or is that you are having to constantly fix little bugs an indication of poor security. There was a recent article on one of the security web pages about how many bugs per month are too many.

a trivial example might be that it could always be possible to add on initial authentication .... but unless there is only a single permission granularity (you either have access to everything or you have access to nothing), permissions may be a much more difficult thing to add.

Unless it is designed in from the start, it is much harder to add in fine granularity permissions that may even dynamically change based on context. fine-grain permissions can be much more difficult to add on after the fact.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IBM Manuals from the 1940's and 1950's

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Manuals from the 1940's and 1950's
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Tue, 09 Sep 2003 21:46:51 GMT

"John W. Kennedy" writes:
I assume that was a SABRE special?

9020 FAA air traffic control ... as opposed to SABRE/PARS/ACP/TPF/etc

There is story that CSC was trying to get a 360/50 to hardware modify for virtual memory ... but they were all going to the FAA ... so had to settle for 360/40 ... which is where CP/40 came from. Later when 360/67 was available ... they ported CP/40 to 360/67 and renamed it CP/67 (which then became vm/370 ... and eventually z/VM). past cp/40 refs
https://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
https://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
https://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction

more of the story can be found in melinda's historical reference:
https://www.leeandmelindavarian.com/Melinda#VMHist

some number of past 9020/faa threads:
https://www.garlic.com/~lynn/98.html#23 Fear of Multiprocessing?
https://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/2000b.html#82 write rings
https://www.garlic.com/~lynn/2000e.html#3 Ridiculous
https://www.garlic.com/~lynn/2001.html#3 First video terminal?
https://www.garlic.com/~lynn/2001b.html#9 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001i.html#14 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
https://www.garlic.com/~lynn/2002f.html#29 Computers in Science Fiction
https://www.garlic.com/~lynn/2002g.html#16 Why are Mainframe Computers really still in use at all?
https://www.garlic.com/~lynn/2003l.html#14 Cost of patching "unsustainable"

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Cryptoengines with usage accounting

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cryptoengines with usage accounting
Newsgroups: sci.crypt
Date: Tue, 09 Sep 2003 23:26:22 GMT

"Ernst Lippe" <ernstl-at-planet-dot-nl@ignore.this> writes:
I know that at least one electronic purse (Proton) had an option to maintain an audit trail of the most recent transactions. But apart from that, I have never seen any kind of auditing in Smart Cards or HSM's.

There is a good reason to avoid such a feature with Smart Cards. The memory contents of a Smart Card can only be rewritten a limited number of times and a counter that is frequently updated will reduce the life span of the cards.

there used to be all sorts of hoops jumped thru, technology, and patents around minimizing number of writes to EEPROM .... a lot of chipcards used EEPROM-based memory to maintain charge when there is no power ... most chipcards operate with out any sort of battery ... and 7816 smartcards draw their power from the contacts when inserted into reader ... and 14443 (contractless) smartcards draw power from the air when they are in proximity to a reader.

the late '80s and early '90s chips had no good random source and used EEPROM that had duty cycle in 10k writes to 30k write range.

you can get chips these days that have duty cycle with EEPROM rated for 800k writes and above. At hundred uses times per day and ten writes per usage, or thousand writes per day ... that has life cycle over two years. Using it five times per day and even ten writes per usage gives life cycle over forty years. Historically, getting writes down to one or two per usage and five uses per day ... increases life cycle to over 200 years.

aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

slightly related (trusted hardware token reference towards end of post):
https://www.garlic.com/~lynn/aadsm15.htm#6

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

The real history of comp arch: the short form

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The real history of comp arch: the short form
Newsgroups: alt.folklore.computers
Date: Wed, 10 Sep 2003 03:46:49 GMT

"del cecchi" writes:
At IBM the direct write ebeam systems (models not specific machines) were named after indians. There was Poca and Hontas and Apsra.

the disk drive list ... including winchester:
https://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill

it is missing names for 2301, 2303, 2311, 2314, 2321, 3340-70, 3344, 3830, 3880-23

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IBM Manuals from the 1940's and 1950's

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Manuals from the 1940's and 1950's
Newsgroups: alt.folklore.computers
Date: Wed, 10 Sep 2003 19:16:47 GMT

Lon Stowell writes:
Somewhere in Montana is a big road sign:

Home On the Range 1 Mile

Bad news is I can't rememeber where it is, even though I have a photo of the sign itself.

I remember all the burma-shave signs on long drives in montana.

misc burma shave websites:
http://www.mc.cc.md.us/Departments/hpolscrv/mthomas.htm
http://www.lincolnhighwayassoc.org/iowa/shaver/1930.html
http://www.lincolnhighwayassoc.org/iowa/shaver/1953.html
http://www.webcom.com/duane/bscontst.html
http://www.geocities.com/Heartland/Plains/6271/spoof003.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

post-doomsday computing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: post-doomsday computing
Newsgroups: alt.folklore.computers
Date: Wed, 10 Sep 2003 20:44:55 GMT

stanb45@dial.pipex.com (Stan Barr) writes:
Anyone know anything about the "Annals of Improbable Research"? It sounds like something I should know about...some googling is required :-)

there is mini-air mailing list (aka mini-Annuals of Improbable Research) ... and the web site "Hot A.I.R."
http://www.improbable.com/

most recent mini-air


Subject: mini-AIR Sept 2003 -- Breakfast similarity, Murphy and the Law

PLEASE FORWARD/POST AS APPROPRIATE
================================================================
mini-Annals of Improbable Research ("mini-AIR")
Issue Number 2003-09
September, 2003
ISSN 1076-500X
Key words: improbable research, science humor, Ig Nobel, AIR, the
----------------------------------------------------------------
A free newsletter of tidbits too tiny to fit in the
Annals of Improbable Research (AIR),
the journal of inflated research and personalities
=============================================================

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

OSI not quite dead yet

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OSI not quite dead yet
Newsgroups: sci.crypt
Date: Thu, 11 Sep 2003 15:08:13 GMT

pgut001@cs.auckland.ac.nz (Peter Gutmann) writes:
This used to be the case with the IETF when standards were written by implementors, so you knew that when a standard was published you could sit down and implement it and have a reasonable chance of it talking to other implementations. Unfortunately in recent years a number of IETF groups have gone down the OSI path, with standards being written by professional meeting- goers who haven't written 10 lines of code in as many years. The result is, as with many of the OSI standards, an unworkable, unimplementable mess which has little or no chance of succeeding in the real world.

but to progress to "Draft Standard" (instead of just proposed) is to demonstrate two interoperable implementations ... all sorts can write internet-drafts ... which can get adopted as "proposed" and show up as RFCs; but to make it to "Draft Standard" it then has to have the two interoparable implementations. There are a large number of RFCs that aren't official standards.

You can have "Internet-Drafts" which aren't yet RFCs
http://www.ietf.org/ID.html

and then there is a process that progresses them to an RFC as "Proposed Standard". The next stage is "Draft Standard". Possibly in the past, a larger percentage made to "Proposed Standard" that could easily transition to "Draft Standard"(???)

see
https://www.garlic.com/~lynn/rfcietff.htm
and scroll down to the standards overview ... or
https://www.garlic.com/~lynn/rfcietf.htm#overview

i.e. (from above):
Draft Standard Protocol

A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful.

....

After additional process and deliberation a "Draft Standard" may eventually achieve "Standard" status. For a current list of standards, see
https://www.garlic.com/~lynn/rfcietff.htm IETF Standards
https://www.garlic.com/~lynn/rfcstd.htm#ietfstd

As part of the above lists, I include how "old" the RFC is. There are supposedly certain requirement to make progress within 24 months. RFC951, BOOTP has been a "Draft Standard" for 215 months (for the heck of it, ages over 24 months, I list in bold) and RFC698, Telnet extended ASCII option, has been "Proposed Standard" for 337 months.

RFCs are never changed. If you have a RFC that documents a "Proposed Standard" and it gets updated as part of transition to "Draft Standard", the updated documented will be released as a new RFC and the previous RFC will be listed as obsoleted. An example is the regular process of updating STD1 that lists the current standards RFC. RFCs aren't necessarily numbered in cronological order. The email RFC replacements numbers (for RFC821/STD10 & RFC822/STD11) were reserved early so that they would have 2821 & 2822.

For a view of some of the inter-relations, see the overview of DNS activity
http://www.dns.net/dnsrd/
http://www.dns.net/dnsrd/docs/id.html
http://www.dns.net/dnsrd/rfc/

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

OSI not quite dead yet

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OSI not quite dead yet
Newsgroups: sci.crypt
Date: Thu, 11 Sep 2003 15:19:16 GMT

oh yes, and other agendas can go on in IETF meetings .... some past discussion regarding VPN:
https://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines
https://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003e.html#40 IETF meeting (Re: editors/termcap)
https://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

AES-128 good enough for medical data?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AES-128 good enough for medical data?
Newsgroups: comp.sys.mac.system,sci.crypt
Date: Thu, 11 Sep 2003 20:24:44 GMT

Joe Peschel writes:
Nope? Matt, what George and I were talking about was the distributed exhaustive key search in 1997. This was not a "academic" break.

I don't think we can consider the attacks of Biham, and, later, Matsui breaks in that the attacks, with their attendant workload, aren't significantly faster than brute-force.

note brute force attacks against specific keys are not against the algorithm; although once it becomes extremely trivial to attack all keys ... then presumably the algorithm infrastructure is at much more risk. In general, security & risk management view security/protection proportional to risk. If you are using a DES key to protect $500 thing and it still takes $50,000 to attack a specific key ... you might still consider yourself protected.

However, if you were using a DES key to protect a whole infrastructure ... then an attack on that DES key can create a systemic risk that puts the whole infrastructure at risk ... which possibly could represent much more at risk than the cost of an attack.

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

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Seven of Nine

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Seven of Nine
Newsgroups: alt.folklore.computers
Date: Fri, 12 Sep 2003 00:17:27 GMT

Peter Flass writes:
Unfortunately, you can run along happily for long periods without it. Then when you discover you don't have a good backup you might as well pack up and move to Tahiti, because you sure aren't going anywhere else. I've read lots of horror stores, none of which I can recall the details of just now. I always try to have several different levels of backup (incremental, vol dump, etc.) and once I had to fall back to my third level to rcover.

some study found half the businesses that had non-backed up disk failures (of some category) declared bankruptcy within a month of the filuare ... aka loosing customer/client billing information and not having cash flow to keep going

one large telco once lost month of long distance billing that way ... but managed to avoid bankruptcy; they were taking backups every night ... but found that there was some problem with the backup process and there was no good data on the tapes.

i once lost some data that had been backed up in triplicate .... but all three tapes were in the same datacenter tape library .... and the datacenter had some procedural problem with operators mounting randomly selected tapes as scratch.

random backup stories:
https://www.garlic.com/~lynn/submain.html#backup

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Cost of patching "unsustainable"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cost of patching "unsustainable"
Newsgroups: comp.arch
Date: Fri, 12 Sep 2003 00:51:23 GMT

eugene@cse.ucsc.edu (Eugene Miya) writes:
The one I was thinking and have thought about was the IRS procurement away from IBM hardware to Univac hardware (troll for Stephen F. or use comp.sys.unisys). The IRS being the main tax (revenue) collection agency of the US Govt. They did a very naive procurement literally presuming that all mainframe hardware was alive. This to try to remain

minor side note (and topic drift) ... something like 92(?) percent of the federal budget is done thru EFTPS directly into FMS. Effectively all corporations with something like $50k or more in corporate taxes and/or employee withholding are mandated to use EFTPS; electronic funds transfers every week or so.
http://www.fms.treas.gov/eftps/index.html

IRS is the tax return (paper-work) processor of the US gov ... but they see little actual money.

somewhere along the way i've heard comments about one of the contractors on IRS modernization ... drastically underestimating the sophistication of all that old 360 assembler code. somewhat random URL from search engine:
http://www.fcw.com/fcw/articles/2001/0108/web-irs-01-12-01.asp
http://www.fcw.com/fcw/articles/2002/0304/web-irs-03-07-02.asp
http://www.informationweek.com/575/75mtirs.htm
http://www.informationweek.com/575/75mtir2.htm
http://www.senate.gov/~finance/2-2whit.htm
http://www.whitehouse.gov/news/usbudget/blueprint/bud28.html
http://www.computerworld.com/governmenttopics/government/story/0,10801,81708,00.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Seven of Nine

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Seven of Nine
Newsgroups: alt.folklore.computers
Date: Sat, 13 Sep 2003 22:04:05 GMT

ab528@freenet.carleton.ca (Heinz W. Wiggeshoff) writes:
No, but there was another board game of that nature, and this brain can't recall it.

Anyone recall the first computer war games? (This would predate the graphics era by decades.)

spacewar on pdp1 graphics screen in the 60s:
http://www.mess.org/sysinfo/pdp1.htm
http://slashdot.org/articles/02/02/28/136217.shtml?tid=127

3d tic-tac-toe on tx-0 graphics screen in the 50s
http://coyote.csusm.edu/lynniebhist/comphist.htm

and

http://memex.org/cm-archive10.html
the following from above:
Les Earnest writes: I vaguely recall that someone at Bell Labs built a relay computer that played tic-tac-toe sometime in the late 1940s or early 1950s. The TX-0 computer at MIT also had a tic-tac-toe game when I started playing with it in 1959. It displayed the board on its CRT and you selected moves by pointing with a lite pen.

...

but tic-tac-toe wasn't war game(?).

spacewar was ported to 2250m4/1130 at cambridge science center in the late '60s

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IEFBR14 Problems

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IEFBR14 Problems...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 14 Sep 2003 13:42:10 GMT

vbandke@BSP-GMBH.COM (Volker Bandke) writes:
Well, this coincides somewhat with what I have heard, namely that a release change necessitated the change, with a small twist: As I heard, in earlier releases of OS/360 programs were loaded on a page boundary. That way a IEFBR14 would always have a RC of 0 (the last 3 nibbles of the entry point address R15 being 0). Later the entry point could be on a doubleword boundary, and thus the return code of IEFBR14 became somewhat "random", thus requiring a fix (SR R15,R15)

I ran OS/360 (release 6?) on 64k (16 4k pages) 360/30 ... can you imagine wasted space of loading all programs on 4k boundary?. However, storage protection support forced regions to 2k boundaries because of storage key graunularity (this was way back when before some machines forced storage keys to 4k boundary).

misc. past iefbr14 threads:
https://www.garlic.com/~lynn/99.html#81 Perfect Code
https://www.garlic.com/~lynn/99.html#85 Perfect Code
https://www.garlic.com/~lynn/99.html#96 IEFBR14 cookie from www.ibm.com
https://www.garlic.com/~lynn/2001e.html#60 Estimate JCL overhead
https://www.garlic.com/~lynn/2001n.html#48 The demise of compaq

one thread mentioning 4k storage protect keys
https://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

OSI not quite dead yet

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OSI not quite dead yet
Newsgroups: sci.crypt
Date: Mon, 15 Sep 2003 13:54:51 GMT

unoriginal_username@yahoo.com (Le Chaud Lapin) writes:
Yes. And unfortunately, this behavior results in large delays in recognizing where true insight and ability lies. Delayed recognition not only causes personal misfortune for the frustrated visionary, but it also portends significant material consequences for the beneficiaries of advancement. For example, in medicine, there might be a very young researcher who retains a certain sagacity not enjoyed by recognized experts in his/her area of research. But lack of objectivity on the part of the recognized experts, often the comittee members, could result in a decade or more of wasted time that demoralizes the young researcher and reduces his/her productivity for the remainder of his/her life.

as alluded to in previous posts ... both VPN and SSL can be considered response to how slow it was taking ipsec to make any progress. SSL went out in application level code ... long before anything progressed about SSL in standards body as well as long before there were much progress on ipsec.

minor previous posts on the subject
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

i would also claim that the whole cp/40, cp/67, vm/370 virtual machine stuff ... vis-a-vis time-sharing made a lot of progress .. originally by a small group of people. The corporate "official" time-sharing effort supposedly had something like 1200 people working on it at its peak ... and hardly anybody has heard of it today (tss/360) ... while cp/40 and cp/67 (along with cms) had most of it done with something like 12 people (two orders of magnitude difference).

minor 545 tech sq. ref
https://www.garlic.com/~lynn/subtopic.html#545tech

and some reference to early use of cp/67 by time-sharing service bureaus:
https://www.garlic.com/~lynn/submain.html#timeshare Misc. commercial time-sharing

in fact, i've made some claim that really new innovation is almost always done by very, very few people ... it is when the innovation becomes adopted that large number of other people become involve.

slightly related thread on things like system/r, relational database, gml/sgml/htm, etc.
https://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning
https://www.garlic.com/~lynn/aadsm15.htm#12 Resolving an identifier into a meaning
https://www.garlic.com/~lynn/aadsm15.htm#13 Resolving an identifier into a meaning
https://www.garlic.com/~lynn/aadsm15.htm#14 Resolving an identifier into a meaning
https://www.garlic.com/~lynn/aadsm15.htm#15 Resolving an identifier into a meaning

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Throughput vs. response time

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Throughput vs. response time
Newsgroups: comp.arch
Date: Tue, 16 Sep 2003 12:23:52 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
There is a lot of truth in it, but it is not absolute. A fair number of people can do more than one non-automatic thing in parallel, but it is very rare indeed for that number to be higher than three. And, with advancing age, the number drops off.

attempts to ban cellphone use by drivers ... claim that cellphone use is 2nd only to alcohol use as cause of accidents.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Threat Analysis and Threat Trees

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Threat Analysis and Threat Trees
Newsgroups: sci.crypt
Date: Tue, 16 Sep 2003 12:31:09 GMT

David Garnier writes:
Hello,

I work in this field and there is very little documentation available about this, especially on the pratical side. "Secret and Lies" from Bruce Schneier is the good start, but I guess that you already know about it. There is also the Common Criteria documentation or the Orange Book, but they are very verbose. I would also love to hear about other pieces of documentation ("secure programming" books cover another, related subject).

Otherwise the only way to make progress in this field is to learn it from someone else.

there are the security sources that I drew our merged security taxonomy/glossary
https://www.garlic.com/~lynn/index.html#glosnote

some of the following have the selectable URLs
Security
Terms merged from: AFSEC, AJP, CC1, CC2, CC21 (CC site), CIAO, FCv1, FIPS140, IATF V3 (IATF site), IEEE610, ITSEC, Intel, JTC1/SC27 (sc27 site), KeyAll, MSC, NIST 800-37, NCSC/TG004, NIAP, NSA Intrusion, NSTISSC/CNSS, online security study, RFC1983, RFC2504, RFC2647, RFC2828, TCSEC, TDI, TNI, and misc. Updated 20021108 with terms from CIAO. Updated 20021205 with terms from 800-37 glossary.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Throughput vs. response time

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Throughput vs. response time
Newsgroups: comp.arch
Date: Tue, 16 Sep 2003 19:19:29 GMT

Bernd Paysan writes:
Doing two things at once slows down your reaction time. I've done some measurements, with two monitors being switched on after a random amount of time, and then I had to hit a key of the associated keyboard (left or right hand). Reaction for single expected event was around 200ms, for two possible events (with corresponding selective reaction) at 400ms. Note that there are a lot of people out there that have single-event response times 400ms, but when they want to react to two things at once, I guess they'll double their response time, too. The time perceived as "present" is 3s, so with 200ms per task, you could handle 15 tasks percieved "at once". All of them equally bad, with 3s response time.

there was human factors presentation at conference in dc about 1970 (mills also gave talk on super programmer) ... that had threshold variance in being able to perceive "instant" response that ranged from about .10 seconds to almost .25 seconds across some reprentation population (no explanation why different people had different thresholds).

also there was something about if the response was longer than initially expected ... the human response was twice the system delay (presumably up to some threshold) ... something about attention started to wander ... and the longer the delay ... the futher attention wandered ... and the longer it took to refocus on the initial subject. So if response was normally .10 seconds and it started to look like five minutes ... the person got up and went for coffee.

random refs:
https://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
https://www.garlic.com/~lynn/2000c.html#64 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001m.html#19 3270 protocol
https://www.garlic.com/~lynn/2002i.html#48 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

360 Microde Floating Point Fix

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 Microde Floating Point Fix
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 18 Sep 2003 14:18:36 GMT

Petter Gustad writes:
GECO (Geophysical Company of Norway) used 3090's at Fjerndata of Norway for some of their seismic processing. GECO also had an Amdahl VP1100 if memory serves me right. They were also using FPS 120B array processors with an interface to Norsk Data computers.

misc. past 3090vector & fps refs:
https://www.garlic.com/~lynn/2000c.html#5 TF-1
https://www.garlic.com/~lynn/2000c.html#61 TF-1
https://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
https://www.garlic.com/~lynn/2002e.html#31 Hardest Mistake in Comp Arch to Fix
https://www.garlic.com/~lynn/2002j.html#30 Weird
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003d.html#35 Why only 24 bits on S/360?

earlier ... there was a lot of air bearing simulation work done on disk engineering 3033 developing disk "floating head" technology.
https://www.garlic.com/~lynn/2002j.html#30 Weird

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Drivers License required for surfing?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Drivers License required for surfing?
Newsgroups: alt.comp.virus,alt.computer.security,comp.security.firewalls,comp.security.misc
Date: Thu, 18 Sep 2003 14:35:05 GMT

"Fred_McGriff" writes:
Why not make it illegal to ship or offer for download an operating system unless all inbound and outbound ports are closed by default? The OS needs to be explicitly told which programs can access the internet. This could be done during the system install for web browsers and email clients. But, all other programs would need to be turned on after the install.

The average use does not know as much about security as the average OS vendor/packager. Responsibility for out the box security belongs to the OS provider. They cannot be allowed to hide behind assertions of limited liability -- especially when they ask for compensation.

the average user doesn't know much about repairing, building and/or servicing a car ... the other analogy is require safe vehicle inspection for PCs .... people get ticketed and fined for operating a vehicle in an unsafe manner or operating an unsafe vehicle ... regardless of whether the indiviudal knows how to service a vehicle or not.

individuals are required to carry accident insurance for their PC ... and while specific kinds of operating systems may not actually be street illegal ... they could be sufficiently prone to certain kinds of damage to require significanlty higher insurance permiums.

random past threads on this subject:
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2003i.html#17 Spam Bomb

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Seven of Nine

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Seven of Nine
Newsgroups: alt.folklore.computers
Date: Thu, 18 Sep 2003 18:39:42 GMT

Steve O'Hara-Smith writes:
Tennis I think, then Breakout, then Space Invaders. Missile Command was the first I saw built into a table.

i think the first pong i saw was possibly at ricky's on el camino in palo alto?

possibly first time I saw space invaders was when the first chucky cheese opened in I believe had been a supermarket (on kooser) behind the shopping center off blossom hill road (west of almaden x-way)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Intel iAPX 432

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel iAPX 432
Newsgroups: comp.arch
Date: Fri, 19 Sep 2003 13:19:36 GMT

"Brian Catlin" writes:
Google has let me down. Does anyone know where I can find detailed information about the 432? Other references to object-oriented CPUs would also be appreciated.

For those too young to remember, the 432 was an extremely complicated processor that was to be the follow-on to the 8086, but Intel bit off more than they could chew and they couldn't get enough performance out of it, which is too bad, because I would much rather have seen the world go that way instead of x86.

at '79 sigops(?) at asilomar there were a number of presentations. one item i remember was with so much high level operating system features in silicon ... patches for silicon chips was a major problem for 432

significant larger project was FS which was eventually canceled w/o even being announced:
https://www.garlic.com/~lynn/submain.html#futuresys
(there was supposedly a joke about any other company would have gone belly-up if they had spent as much money on such an unsuccessful/canceled project). it did see some rebirth as the s/38 .... which evolved into as/400 and now appears using power/pc chips.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Intel iAPX 432

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel iAPX 432
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 19 Sep 2003 19:30:27 GMT

Paul Repacholi writes:
Reflections on a Pool of Processors. Wulf, and Harbinson HYDRA/C.mmp. Wulf, Levin, and Harbinson Capability based Systems. Levy (not sure if this is correct UWA library has a copy) anything on IBM S/38 Also look for stuff on the Ferranti system and also CAP from Cambridge.

for capability-based system ... see keykos ...
http://cap-lore.com/CapTheory/upenn/
http://www.agorics.com/Library/keykosindex.html

random recent threads w/keykos:
https://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
https://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
https://www.garlic.com/~lynn/2003j.html#20 A Dark Day
https://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Microsoft Internet Patch

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft Internet Patch
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 20 Sep 2003 14:05:03 GMT

efinnell@SEEBECK.UA.EDU (Edward J. Finnell, III , Ed) writes:
Sure there has, very first one was the Christmas eMail in VM that brought down VNET worldwide. Then there was the dark zap in open that erased the disk that it was issued against. Inside jobs, one accidental, one retributive for long hours and low pay. Still see who the richest folks are! Bill, Warren, Paul, Mark, Scott and the Walton clan.

the internal network ... from which bitnet/earn was derived:
https://www.garlic.com/~lynn/subnetwork.html#bitnet

was larger than internet/arpanet until about mid-85. at the time of the cut-over to internet(working) protocol on 1/1/83 ... there were around 240 arpanet nodes .. while the internal network was approaching 1000. Almost all of the internal nodes were VM/CMS ... in part because of severe limitations and problems in the MVS/JES networking capability:

1) JES had traditional homogeneous networking architecture/design somewhat similar to arpanet (prior to internetoking protocol). JES was so bad that different versions of JES might not even interoperate ... there is the incident of a JES file from San Jose flowing thru the internal network to Hursley and bringing down Hursley MVS system.

2) VM/CMS networking had essentially gateway layer from the start (and no real practical network node limitation) the JES homogeneous support was so bad .. there was whole body of VM network drivers that talked to different versions of JES ... and eventually the various VM network drivers were given the implementation task of creating canonical JES network headers and making sure that what was delivered to a specific JES system was at the correct format as a MVS crash avoidance mechanism.

3) original JES network product announcement implemented network node definitions in the psuedo device table ... which was limited to 255 definitions max; as a result a typical JES node had 200 or fewer network definitions. at the time JES raised the network node definition limit to 1000, the internal network was well over 1000 nodes. The JES network node limitation including trashing files if either the destination node or the originating node wasn't in the table ... which made it extremely difficult to use JES as any sort of intermediate node (a local JES might have all the definitions of the local nodes and could deliver files ... but it would still trash a file if it originated from a node not in the definition).

one of the downsides of the bitnet/earn deployment was the vm networking code was soon restricted to only shipping JES networking compatible drivers ... and none of the (original) native VM network drivers (minimizing the comparison of VM having full, interoperable, heterogeneous networking support as compared to the much more limited JES homogeneous networking support).

i believe the first occurance of scripting email exploit was around '74 ... where somebody sent an email that was an exec file with the filename of some normal system command. The CMS command lookup (inheriied from CTSS?, early '60s) was that command lookup was regular/consistent across all kinds of script/exec files, executables as well as kernel calls ... it was even possible to create an exec file on local, private filesystem that was the same name as an internal SVC/kernel call (aka it was also possible to invoke internal SVC/kernel calls directly from command line).

In any case, somebody could read a file from the network, place it in their local filesystem ... and it could be an exec file with the same filename as a system executable or even a kernel call ... which would get invoked anytime that command was invoked.

Until the most recent activity ... exploits were approximately 1/3rd social engineering, 1/3rd buffer overlows, 1/3rd scripting files loaded from the network.

this most recent activity is sort of a combinationt of social engineering and network executable ... so it isn't an actual automatic scripting exploit; requiring social engineering to convince the recipient to manual invoke the command (somewhat was the case of the xmas exec).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Microsoft Internet Patch

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft Internet Patch
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 20 Sep 2003 14:10:14 GMT

PaulW@ENET.COM (Paul Wendt) writes:
Would this "email" have been PROFS? IBM's prescient answer to Outlook and a particularly horrid excuse for an "email" system.

PROFS was somewhat a menued (referred to at the time as "padded-cell") front-end to what was mostly an aggregation of internal online tools. In one case, an extremely, early, alpha level of somebody else's code was used to handle the actual mail processing (behind the menu front-end). In a disagreement about the origin of the code ... it was pointed out that every profs email in the world carried the initials of the original author in an internal control field.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Microsoft Internet Patch

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft Internet Patch
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 20 Sep 2003 14:24:07 GMT

ibm-main@LDWOREN.NET (Leonard Woren) writes:
By the way, VNET was impacted much more severely than BITNET because VNET ran on T1 and BITNET ran on 9600b. On BITNET we had time to get the word out and corral it. Of course, I was doing email on MVS via the UCLA/Mail program, so when I received the exec it wouldn't have run anyway.

the internal network ran on a whole range of different speed lines ... i consider one of the original lines was between cambridge and endicott ... supporting a project where CP/67 was enhanced to provide/support 370 virtual machines (the new instructions were trapped on operational exception and emulated).

the harder was that 370 virtual memory tables were significantly different than 360/67 .... so 370 virtual memory tables had to be remapped to 360/67 tables.

then to test that code ... a version was cp/67 was modified to run in 370 hardware (rather than 360/67 hardware). This was operational and regularly tested a year before engineering hardware was available for 370 virtual memory.

It was used to test the original 370 engineering model with virtual memory hardware support (something that had a knife-switch as an IPL/boot button). Turns out the engineers had a bug ... they had reversed the implementation of two of the B2 opccdes ... which required patching the kernel (modified CP/67) to correctly boot on the machine.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

SR 15,15

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SR 15,15
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 20 Sep 2003 20:22:39 GMT

ibm-main@LDWOREN.NET (Leonard Woren) writes:
But IBM also thought (in the 1950s) that 5 computers would serve all of the computing needs of the United States. That's why the computer center at UCLA was known back then as WDPC - the Western Data Processing Center.

guess who in 1986 was predicting that there would be a maximum of 200 T1 lines in the US by 1991?, in part because a certain 37xx product didn't support T1 and didn't really have any plans to.

this certain 37xx product supported 56kbit links and would support multiple 56kbit in "fat pipes". When they did a survey to find out the 37xx "fat pipe" install base .. they found lots of two-56kbit fat pipes, lots of three-56kbit fat pipes, lots of four-56kbit fat pipes and little or no five-56kbit fat pipes.

so the conclusion was that customers didn't need the bandwidth for more that 200kbit ... and would only be very slowly be growing to T1. Also ignore all the 2701 T1s and the S/1 zirpel T1s.

what they apparently failed to see was that tariff for five 56kbit lines was about the same as a full T1 (aka 1.5mbits or over 25 56kbit lines) ... customers would just buy a T1 and used it with a product that supported T1. An extremely cursory survey of mainframe non-37xx configurations easily turned up 200 T1 lines in 1986 (or as many that supposedly wouldn't be reached in total for the whole country before 1991).

it was also a little out of sync with the NSFNET1 T1 backbone (minor ref to NSFNET1 program and award announcement):
https://www.garlic.com/~lynn/internet.htm#nsfnet
https://www.garlic.com/~lynn/internet.htm#0

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

SR 15,15

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SR 15,15
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 21 Sep 2003 14:03:01 GMT

IBM-MAIN@ISHAM-RESEARCH.COM (Phil Payne) writes:
One of the performance-enhancing features of IBM mainframes (since at least the 3033) has been a thing called the "Segment Table Origin Register Save Stack" - although it has other names. This saves instances of the address of the segment table in use and associates TLB entries with each one, such that when a segment table is reloaded (after an address space switch) TLB entries can be re-recognised as belonging to that address space, saving retranslation.

360/67 had a single STO (segment table origin) associative array.

370/168 had 128 entry table look aside buffer with a 3bit identifier for each entry ... for a seven-entry "STO-stack" ... i.e. 3-bits, 8 identifiers ... one for unused entries and seven for which STO the entry was associated with.

The machines were considered to be STO-associative ... i.e. virtual addresses and the table look aside entries were identified as being with a specific segment table (represented by the segment table origin address).

when segment register 1 was reloaded with different STO ... it was checked for being in the STO-stack ... and if so, continued as that STO; if not, one of the entries in the STO-stack was scavanged and all the related entries in the table look aside buffer invalidated.

dual-address space was introduced for 3033. there was the various performance trade-offs between having hardware assist moving data between address space (as well as somewhat alleviating pressure on the common area) against increase in the pressure/use of the entries in the STO-stack (hardware assist for cross-memory moves was at the expense of increasing the nominal number of STO entries needed in normal execution period).

The increased pressure on TLB entries somewhat caused by multiple address space instruction architecture and a STO-associative hardware implementation ... when MVS was in large part a PTO architecture became more & more of a problem ... aka over half the TLB entries tended to be duplicated because half of each MVS address space was composed of identiable page table entries.

Original 370 architecture had regular architecture that allowed for STO-associative hardware implementation or even a STE/PTO associative hardware implementation i.e. rather than associate each TLB entry with a specific segment table or address space .... associate each TLB with a specific segment table entry ... page table origin address.

MVS was somewhat of a cludge from a operating system architecture ... that was partly left over from os/360 days with the kernel code occupying the same address space as the application. Part of the enormouse pressure on 24-bit address in MVS systems ... is that later versions of MVS/370 had the kernel occupying 8mbytes of each address space and some installations had common area growing to 4mbytes ... leaving only 4mbytes of the address space for application execution.

discussion of common system bit from early '80s
https://www.garlic.com/~lynn/2002m.html#0 Handling variable page sizes?

this was case of adapting the hardware to the MVS operating system kludge ... having an environment where certain segment table entries can be flagged as being "common" across all virtual memory address spaces ... aka the operating system would enforce the rule that segments flagged as common ... would be unique across all address spaces loaded. Then TLB hardware could treat TLB entries from segments flagged as common as not being address space unique ... they were the same in all address spaces.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Mail delivery failed: returning message to sender

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Fw: Mail delivery failed: returning message to sender
Newsgroups: bit.listserv.ibm-main
Date: Mon, 22 Sep 2003 00:36:10 GMT

richard.higson@GT.OWL.DE (Richard Higson) writes:
(HUMOUR, WARNING, a pinch of salt might be needed) Aw' co'mon Phil, next thing we know, you'll be asking that the Manufacturers of Operating-Systems provide road-worthy vehicules and not the Horse & Buggy (more buggy than Horse) stuff we have to put up with at the moment.

references to tickets for unsafe driving and/or operating unsafe vehicle .... as well as prior threads on the subjects:
https://www.garlic.com/~lynn/2003m.html#21 Drivers License required for surfing?

it isn't question as to level of technology ... but whether it is unsafe and/or hazard.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

SR 15,15 was: IEFBR14 Problems

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SR 15,15 was: IEFBR14 Problems...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 22 Sep 2003 13:15:23 GMT

Gerald.Kaiser@WW-INFORMATIK.DE (Kaiser, Gerald , IRB-BS) writes:
To my knowledge BAS and BASR were introduced with the XA-architecture introducing 31-bit-addressing to overcome the 16MB-barrier, so approx. 1982/83. 1967 was pre-VS (roughly at that time the 360-67 was introduced, the first virtual-storage machine for universities etc, which still was a 24-bit machine, so hardly in need of BAS/BASR), the IBM VS-operating systems were announced in summer 1972 and at that time BAS/BASR was definetely not introduced. Regards, Gerald

360/67 supported both 24-bit and 32-bit addressing (not that little 31-bit stuff introduced in the 80s) ... and had BAS/BASR instructions. 360/67 multiprocessing also had channel director with access to all channels by all processors ... something not seen again until the 80s). The channel director panel had lots of configuration switches allowing machine to be partitioned, memory banks allocated in various ways ... particular channels routed in specific ways, etc. The switch settings from the channel director control panel was available via bits defined in control registers. There was at least one model of 360/67 where the channel director configurations settings could be changed via the same control registers (not just sensed).

The flagship operating system for 360/67 was tss/360 ... which at its peak had comparable number of people working on it as os/360. lots of history about ctss, multics, 360/67, modified 360/40 with virtual memory, tss/360, cp/67 (original virtual machine operating system), cms (originally referred to as cambridge monitor system but renamed to conversational monitor system as part of transition to vm/370).
https://www.leeandmelindavarian.com/Melinda#VMHist

during that period, cms, cp/40, cp/67 had about 1/100th as many developers writing software for it as tss/360. all of this was going on csc, 4th floor, 545 tech sq.
https://www.garlic.com/~lynn/subtopic.html#545tech
Also where GML originated (which has since spawned SGML, HTML, XML, FSML, SAML, etc, etc) and the internal network.

some of information from 360/67 reference "blue card" (including bas/basr instructions and control register assignment):
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)

misc. other references to 360/67 "blue card":
https://www.garlic.com/~lynn/2001.html#69 what is interrupt mask register?
https://www.garlic.com/~lynn/2001.html#71 what is interrupt mask register?
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
https://www.garlic.com/~lynn/2003l.html#25 IBM Manuals from the 1940's and 1950's

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

SR 15,15 was: IEFBR14 Problems

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SR 15,15 was: IEFBR14 Problems...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 22 Sep 2003 17:42:39 GMT

tjpo@AIRBORNE.COM (Patrick O'Keefe) writes:
Guess I worked for a "nobody" company. I started system programming in 1973 and had several years before even hearing about VS.

Before that (1967-1972?) I was an operator in an IBM Datacenter and never saw or heard of VS. (There was definitely talk about CP67, but we didn't have a 67 so I never saw it.) The Seattle Datacenter was certainly not on the cutting edge of anything, but there would have been talk of VS if it had been around.

Excpet for special cases like CP67, I'm pretty sure VS operating systems didn't make their appearance until the S/370 line in the '70s.

Boeing formed BCS in 1969 ... I spent summer of '69 there helping install and train some of the staff on cp/67 ... first on uniprocessor 360/67 ... and then they got the Boeing Hunstville two-processor 360/67 sent up from Hunstville. There were possibly 25 people in BCS when I was there ... but they were in the process of trying to absorb commercial airplane datacenters in renton, everett, wichita, etc. BCS had been formed with hdqrts dataprocessing which, at the time, had a single 360/30 that ran payroll & checks (so it was a big step from a single 360/30 to possibly two of the larger datacenters in the world at renton and everett.

One of the IBM SEs on the Boeing account (out of the Seattle branch office) did a stripped-down CP using the "DIL" (?) instruction on standard (non-virtual memory) machine. DIL(?) had base & bound, contiguous storage relocation (think of it as an early form of LPARS). I believe he did some of his testing 3rd shift on one of the machines in the seattle datacenter (on the "first" floor).

TSS/360 was the mainstream operating system for the 360/67 and at one point had numbers approaching that of os/360 working on it.

cp/67 was done at cambridge science center ... with something like 1/100th the number of people working on tss/360.

MTS was another virtual memory system for 360/67 done at univ. of michigan.

Starting sometime in '70 ... the DP division started pioneering hone at three datacenters at 1) 1133 westchester, 2) someplace in chicago, and 3) wilshire blvd. ... allowing testing of 370 operating systems on 360/67.

As previously mentioned, one of the earliest applications of the internal network was a joint CSC/Endicott project to provide virtual 370 machine support (both non-virtual memory as well as virtual memory) ... running on 360/67. This started out as a series of changes to the CP/67 kernel to simulate the new (non-virtual memory) 370 instructions. This set of code was used by the emerging HONE operation at the three DP datacenters with 360/67s. The rest of the code provided full virtual memory 370 simulation ... and a set of modifications to cp/67 to make it run on 370 architecture instead of 360/67 architecture (this later set of code was operational for a year before the first engineering 370 hardware was available with virtual memory support).
https://www.garlic.com/~lynn/2003m.html#27 Microsoft Internet Patch

HONE was moved to 370s and US HONE operations were eventually consolidated in Cal ... with one of the largest time-sharing service bureau operations in the world (supporting all field and branch people). HONE was also cloned for branch, sales, marketing, and field support people around the world (I hand carried and installed some of the early deployments). misc. hone refs:
https://www.garlic.com/~lynn/subtopic.html#hone

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

MAD Programming Language

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAD Programming Language
Newsgroups: alt.folklore.computers
Date: Mon, 22 Sep 2003 17:13:01 GMT

Tom Van Vleck writes:
In 1965, the CTSS scheduler consisted of five modules, SCDA, SCDB, SCDC, SCDD, and SCDE. All but one were written in FAP. The SCDC module was written in MAD. This was the module that picked the next user to run, and contained the actual "scheduling algorithm." SCDC was worked on by many people but Tom Hastings and Corby were the two names that I remember. Because the algorithm was subject to much tweaking, MAD was used to avoid introducing bugs. (Time sharing scheduling was at the time an important research topic, and CTSS was the first system to implement a Greenberger-Corbato exponential scheduler, in which jobs were run with a little time slice first, then exponentially bigger slices at lower queues. In practice this caused long running jobs to starve, so there was a scheduler parameter QNTWAT that bumped a languishing job's priority backup. But I digress.) In the early 70s, CTSS was still being used by some projects while Multics matured: it was maintained by a group at MIT Information Processing Center. Some of the system programmers decided to rewrite SCDC in FAP for efficiency; I prevailed on them to keep the MAD statements as comments so we would know what was going on.

cp/67 "release 1" appeared to have had a nearly identical scheduler; however as the number of users went up ... the processing time in the scheduler increased non-linear. release 1 cp/67 was measuring something like 15 percent of total processor time in this bit of code with something like 30 logged-on users. Harold Fienlieb at Lincoln Labs rewrote the code to a much simpler (and faster) two level system that drastically cut the pathlength processing and was made available in "release 2" of cp/67 in '68 (the thruput of KISS more than offset any downside of it being simpler).

Harold then joined NCSS ... when they formed cp/67 time-sharing service bureau ... june of '68 ... slightly related:
http://www.decosta.com/Nomad/tales/history.html

some other people from Lincoln Labs and others formed another cp/67 time-sharing service bureau (IDC) some months later. misc. previous postings regarding time-sharing service bureau
https://www.garlic.com/~lynn/submain.html#timeshare

it was on harold's implementation that i did the dynamic adaptive, fairshare, non-fairshare, pathlength, etc. stuff in late '68 and '69. lots of old performance and scheduling posts:
https://www.garlic.com/~lynn/subtopic.html#fairshare
and the "clock" replacement stuff
https://www.garlic.com/~lynn/subtopic.html#wsclock

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

SR 15,15 was: IEFBR14 Problems

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SR 15,15 was: IEFBR14 Problems...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 22 Sep 2003 17:54:20 GMT

JMckown@UICIINSCTR.COM (McKown, John) writes:
Incorrect. As I recall from college (a very long time ago). The first computer system with "VS" or "Virtual Storage" was the Atlas. This was in 1956!

See:
http://portal.acm.org/citation.cfm?id=359331&jmp=abstract&dl=GUIDE&dl=GUIDE
http://sunsite.utk.edu/math_archives/.http/hypermail/historia/oct99/0165.htm

there was some discussion of this from early cp/40 days referenced in melinda's document:
https://www.leeandmelindavarian.com/Melinda#VMHist

some past posts referrning quotes in the above about the perception that virtual memory in atlas "didn't work":
https://www.garlic.com/~lynn/2000.html#52 Correct usage of "Image" ???
https://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
https://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#26 TECO Critique
https://www.garlic.com/~lynn/2002.html#42 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
https://www.garlic.com/~lynn/2003.html#72 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#1 Disk drives as commodities. Was Re: Yamhill

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

SR 15,15 was: IEFBR14 Problems

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SR 15,15 was: IEFBR14 Problems...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 22 Sep 2003 19:25:42 GMT

"Glen Herrmannsfeldt" writes:
But were the hex opcodes the same? I thought they were different, but I am not sure.

from 360/67 blue card &:
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)


Load Multiple Control           LMC     RS      M, A, S, D P    B8
Store Multiple Control          STMC    RS      M, P, A, S      B0
Load Real Address               LRA     RX      M, A, S         B1
Branch and Store                BASR    RR                      0D
Branch and Store                BAS     RX                      4D
Search List (RPQ)               SLT     RS      P, A, S, Relo   A2

and basr/bas Branch and Save instructions from
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7.5.9?SHELF=DZ9ZBK01&DT=20020416112421

are 0D and 4D op-codes (as in 360/67)

from above programming notes:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/5.3.3.1?SHELF=DZ9ZBK01&DT=20020416112421#SPTBSMNTS
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/5.3.3.2?SHELF=DZ9ZBK01&DT=20020416112421#SPTSBIPN
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/5.3.3?SHELF=DZ9ZBK01&DT=20020416112421#HDR05AH24

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

S/360 undocumented instructions?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 undocumented instructions?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 23 Sep 2003 15:59:22 GMT

charlie@ELEKTRO.CMHNET.ORG (Charlie Smith) writes:
I don't think there were "undocumented instructions", as much as instructions that were only present with some RPQ features. I remember reading of early experimentation with virtual memory implemented on a 360/44, I think maybe in a System Journal.

note that there was diagnose instruction ('83') that was priviledge and defined as machine/model dependent. some amount of diagnostics or other specialized service applications made use of diagnose instruction.

cp/67 (and then vm/370) co-opted the diagnose instruction for virtual machine usage ... i.e. defining virtual machine model depenedent diagnose instruction (i.e. diagnose instruction operational definition defined specific for a virtual machine model).

cambridge science center was trying to get a 360/50 to make the hardware modifications to support virtual memory ... however because so many 360/50s were going to FAA for the air traffic control system ... they had to settle for a 360/40 (this was all pending availability of the official virtual memory machine ... the 360/67). cambridge built cp/40 on the 360/40 ... and then converted it to cp/67 when 360/67 became available.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

S/360 undocumented instructions?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 undocumented instructions?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 23 Sep 2003 17:16:10 GMT

ibm-main@LDWOREN.NET (Leonard Woren) writes:
Yep; I remember in about 1972 when I was in Explorer Post 360 (really!) getting to play around with a S/370 model 145 among other equipment at an IBM CE training center. The 145 was the model that had a really nice implementation of alter/display on the integrated console: you hit STOP, then hit the A/D console key, and could type commands like "DM xxxxxx" and "AM xxxxxx" for Display Memory and Alter Memory, "DP" and "AP" for the PSW, "DG" and "AG" for the general registers, etc. It didn't take too long to decide to go through the whole alphabet to see what wasn't documented. The fun part is that most commands were rejected with "invalid command", but AV/DV were rejected with "invalid operand". The 145's microcode listing was on a table nearby, so we started reading it. Got to the AV/DV commands and there was a PRINT OFF. Sigh.

I imagine that they enabled virtual storage in the ucode and changed the nameplate on the machine to say 148. Was this available as a field-installed MES?

370/145 had a floppy load to enable virtual memory. also they shipped with the front panel "roller" lights having a label "XLT" in the PSW ... which raised a number of questions before virtual memory was announced.

370/148 was much later. 148 had faster floating point and a lot more room for microcode. virgil/tully (138/148) went with operating system microcode assists ... for both VS/1 and VM/370. We were given that there was about 6kbytes of microcode left to develope VM/370 microcode assist ... and that instruction bytes translated from 370 to microcde on about 1 for 1 ... however, for equivalent function ... the 148 microcode implementation ran approximately ten times faster than the equivalent implementation in 370 (for a whole slew of reasons). The VM/370 microcode assist increased performance by 1) 370 to microcode ten times speed up (for all code) and 2) for virtual machine emulation of priviledge instructions ... eliminating the priviledge interrupt into the vm/370 kernel, register saving, restoring, context switch, etc.

Note that on the high-end machines (168, 3033, etc) ... 370 instruction emulation had progressed until it was effectively one-for-one. 370/165 had about 2.1 machine cycles per 370 instruction, this was optimized in 370/168 until it was about 1.6 machine cycles per 370 instruction. By 3033 it was around one for one. There were even cases on 3033 that translation from 370 instruction stream into microcode actually ran slower. The 3081 had situations were 370 translation into microcode ran significantly slower because the microcode might have to be "paged" in off a picollo hard disk.

The vm/370 microcode assist on 138/148 for supervisor/kernel code translated into microcode was referred to as ECPS. The other part was additonal virtual machine assist of priviledge instructions by operating systems running in virtual machine (subset of all the stuff seen in current day LPAR support).

some past posts on the roller lights:
https://www.garlic.com/~lynn/99.html#204 Core (word usage) was anti-equipment etc
https://www.garlic.com/~lynn/2002n.html#15 Tweaking old computers?
https://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Questioning risks of using the same key for authentication and encryption

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Questioning risks of using the same key for authentication and encryption
Newsgroups: sci.crypt
Date: Tue, 23 Sep 2003 21:11:55 GMT

"Paul Sheer" writes:
The RFC does not say anything about using the same key for encryption and authentication. (Basically, you might encrypt with 3DES and then authenticate with MD5-MAC.)

I understand that using the same key for both is supposed to be a bad idea. Can anyone point me to some online articles that discuss why exactly?

two slightly related issues:

1) encryption and authentication are different business processes with different business requirements. in a corporate or institutional setting ... there is likely a business requirement for escrowing encryption keys involved in encrypting data at rest (corporate requirement for no-signle-point-of-failure and the ability to always be able to recover corporate assets) ... while there may be a total different business requirement that an authentication operation can only be under under control of specific person

2) there have been some early vague notions that authentication, digital signatures, and non-repudiation are related business processes. "legal" digital signature and non-repudiation tend to carry with it the requirement that not only could the signature only have originated with a specific entity ... but that entity also intended to "sign" some contents and furthermore demonstrates some agreement with any terms and conditions that might be specified in the contents being signed. encryption somewhat implies a business process that can willy-nilly encrypt strings of bits w/o necessarily requiring any awareness of the contents being encrypted.

the use of the same key for totally different business process purposes can be a bad idea when there is requirement for incompatible management of the key(s) and processes associated with the different business purposes.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

S/360 undocumented instructions?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 undocumented instructions?
Newsgroups: bit.listserv.ibm-main
Date: Wed, 24 Sep 2003 01:54:26 GMT

edgould@AMERITECH.NET (Edward A. Gould) writes:
Memory time... didn't Cambridge also offer a solid state drum as well?

Thing worked great except if we had a power "blip" it lost iits brains and you had to re-init the thing and redefine the pagespace (PLPA) we had on it.

Or am I in error?

and the 1655?

misc. past refs to the 1655:
https://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001l.html#53 mainframe question
https://www.garlic.com/~lynn/2002.html#31 index searching
https://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

MAD Programming Language

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAD Programming Language
Newsgroups: alt.folklore.computers
Date: Wed, 24 Sep 2003 16:50:56 GMT

Tom Van Vleck writes:
If quit/start got disallowed, users would find other ways to make their jobs look interactive. For example, we discussed modifying the compilers to demand a keyboard input every so often to make them look "interactive." When demand for resources exceeded supply, something had to be deferred. The quit/start trick penalized those jobs whose owners were least impatient, probably as good as we could do.

When we began using Multics to support itself, the scheduler had the same feature, but the quit/start sequence caused a lot of page faults and the community were all impatient system programmers. So we hid the EPL compiler and only allowed a daemon process to run it. Users submitted requests to have compilations done by the daemon, which put the results back in the user's home directory. It was a kludge but it worked until the GE version of PL/I became available.

cp/67 used terminal I/O as an indication of being interactive ... treating any kind of terminal i/o ... read or write ... as indicative. terminal i/o also had the characteristic of promoting to the top of the 10 level scheduling queue; release 1 ... sounds like it was out of ctss.

release 2 of cp/67 simplified things into two level queue ... "interactive" and "the rest". Task placed into interactive queue were ahead of "the rest" ... until they used a predetermined amount of cpu ... went idle ... or had another terminal i/o.

various cpu bound applications created extremly pathological and uncontrolled system-wide thruput characteristics.

One of the culprits was the CMS "BLIP" command which would do a terminal I/O (that did nothing more than "wiggle" the 2741 type-ball) after every two seconds of CPU use. A little creative hacking and the CPU-use interval could be reduced to a couple hundred milliseconds.

For the fairshare/non-fairshare dynamic, adaptive feedback scheduling ... I implemented smooth recent CPU utilization tracking and priority scheduling based on advisery deadlines (i.e. tasks were ordered for dispatching by their advisery deadline ... not something close to "interfactive" FIFO before all "the rest" FIFO). The advisery deadline was based on a number of things, including recent resource consumption, projected CPU use, as well as fairshare and non-fairshare administrative specifications. Part of the whole trick was being able to accumualte recent, smoothed resource usage ... and the advisery deadline in shorter pathlength than the existing much more simple minded implementation.

One of the characteristics was that live load situations became much more predictable ... with the elimination of whole classes of pathelogical situations. In effect, "interactive" had a slight preference as long as the task wasn't exceeding its resource allocation. Lots of "think time" (no recent cpu use) plus interactive was much more predictable.

misc. past
https://www.garlic.com/~lynn/subtopic.html#fairshare

some past posts with regard to CMS "BLIP"
https://www.garlic.com/~lynn/2000g.html#12 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2002i.html#56 wrt code first, document later
https://www.garlic.com/~lynn/2003b.html#71 Early attempts at console humor?
https://www.garlic.com/~lynn/2003b.html#72 Early attempts at console humor?
https://www.garlic.com/~lynn/2003c.html#16 Early attempts at console humor?
https://www.garlic.com/~lynn/2003c.html#18 Early attempts at console humor?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Issues in Using Virtual Address for addressing the Cache

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Issues in Using Virtual Address for addressing the Cache
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 24 Sep 2003 18:43:32 GMT

"Del Cecchi" writes:
Trick homework question. the part of the address used to address the cache is the same for virtual and real addresses.

370/168-3 doubled the cache size compared to 370/168-1 (32kbytes to 64kbytes). to address the additional cache lines, it used the "2k" bit from the address. however, 370 allowed for selective configuration using either 2k or 4k pages ... so the 168-3 had a special case when in virtual address mode with 2k pages ... it used only half the cache. also switching between 2k-page mode and 4k-page mode, it would flush the entire cache ... since the mapping of memory locations to cache locations was different.

some number of installations that had been running dos/vs under vm/370 on 168-1 and upgraded to 168-3 actually saw a significant performance degradation (because on entry to cp kernel it would always reload control registers to default specifying 4k-page mode ... and only load control registers for 2k-page mode when it was dispatching a virtual machine that was running in 2k-page mode.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

S/360 undocumented instructions?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 undocumented instructions?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Sep 2003 18:59:47 GMT

"Glen Herrmannsfeldt" writes:
What was wrong with the 2301? The ones I used to know about were used for storing WYLBUR active files on. At least that is what I was told they were for.

IBM seemed to like to call everything DASD, disk or drum, it was all DASD.

DASD was access storage device also because of things like data cells (2321) ... from a early period possibly when it wasn't clear what form factor might eventually dominate. also 2321 is where the "BB" in "BBCCHHR" came from.

2303 and 2301 drums were very similar ... except 2303 transferred data on a single read/write head ... while the 2301 transferred data on four read/write heads in parallel ... resulting in four times the transfer rate ... possibly be construed as an early/simple form of RAID parallel transfer.

for a while, csc had a heavily loaded 360/67 that would support 70-80 users with sub-second response and hit 300 page I/O transfers per second ... with nominal avg rate of 150 page I/O transfers per second.

some old threads comparing heavily loaded cp/67 360/67 configuration and 3081k configuration running similar workload (but separated in time by 10-15 years):
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#10 Virtual Memory (A return to the past?)
https://www.garlic.com/~lynn/98.html#46 The god old days(???)
https://www.garlic.com/~lynn/99.html#4 IBM S/360
https://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
https://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
https://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
https://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
https://www.garlic.com/~lynn/2002.html#5 index searching
https://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
https://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2003.html#21 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003d.html#21 PDP10 and RISC
https://www.garlic.com/~lynn/2003f.html#50 Alpha performance, why?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

S/360 undocumented instructions?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 undocumented instructions?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 25 Sep 2003 14:33:14 GMT

Rick.Fochtman@CLEARINGCORP.COM (Rick Fochtman) writes:
Phil, was that a 3880 or 2880 ?? ISTR that the 2880 was an outboard blk-mux channel box. But I don't remember the 3880.

3830 was the original 370, blk-mux disk controller for 3330 disk drives.

for 3380 disk drive 3mbyte/sec, a new controller was cutter/3880.

the 3830 was a horizontal microcode machine ... the 3880 controller was implemented with much slower vertical, "jib-prime" microprocessor. While the 3380/3880 was much faster transfer than 3330/3830, the processor was slower ... requiring custom dedicated hardware for data-flow ... leaving the jig-prime the task of handling just control operations.

3880 q/a acceptance required that its performance was within five percent of 3830. The acceptance test was done in STL with a one pack vs1 system. The problem was that the first time 3880 was used with full string of drives ... there was significant performance degradation compared to 3830 ... turns out it was a 16 drive string of 3330s that was recabled from 3830 controller to 3880 controller ..d. misc. tales from bldg 14 disk engineering an bldg 15 product test:
https://www.garlic.com/~lynn/subtopic.html#disk

What had happened was that the jib-prime was so much slower than the 3830 ... the jib-prime was coded to signal operation complete to the channel ... before the 3880 had finished its cleanup. This resulted in two problems:

1) if an error was discovered during post-complete cleanup ... the controller generated an unsolicited unit check ... which was violation of the architecture ... and they had to come up with some other strategy.

2) the operation complete to the CPU ... in an heavily loaded multi-drive string ... the processor typically had queued requests for some drive connected thru the same controller and it would immediately try to start the operation. Since the 3880 was actually still busy, the controller then would signal SM+BUSY (controller busy) and at some later time time signal CUE. In a busy system this resulted in just about doubling the number of SIOs and interrupts (compared to the same configuration with 3830) ... in addition to increased delay for all operations. The original acceptance tests with a single drive VS1 system didn't encounter the immediate controller redrive problem. Since we diagnosed this in bldg. 15 six months prior to first customer ship ... there was some window of additional changes before the product showed up in customer installations.

Note that the slower microprocessor in cutter/3880 propagated other kinds of performance related problems. One was a significant latency when the 3880 was hit by two succesive I/O operations on different channel interfaces and the jib-prime had to do significant internal bookkeeping overhead (one the order of millisecond) to switch channel interfaces.

misc. lists of disks & controllers:
https://www.garlic.com/~lynn/2001l.html#53 mainframe question
https://www.garlic.com/~lynn/2001l.html#54 mainframe question
https://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
https://www.garlic.com/~lynn/2002o.html#3 PLX
https://www.garlic.com/~lynn/2003b.html#3 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

MAD Programming Language

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAD Programming Language
Newsgroups: alt.folklore.computers
Date: Fri, 26 Sep 2003 11:29:26 GMT

Brian Inglis writes:
Standard multi-level round-robin scheduling. Separate priority queues for interactive (didn't use its scheduled timeslice run quantum), normal (may use run quantum), and compute bound processes (used all of its run quantum). Provides O(1) access: pick the process off the front of the highest priority queue.

so that was the 10-level queue stuff from release 1 cp/67 (and presumably ctss) ... as well as pretty much the two-level queue stuff from lincoln labs in release 2 cp/67.

what I did circa '69 (undergraduate ... but ibm shipped in products) for dynamic, adaptive, fairshare/non-fairshare, etc ... was to calculate an advisery deadline dispatching priority ... and all tasks (regardless of queue, interactive, batch, etc) were odered by their advisery deadline dispatching priority.

the advisery deadline was the current time plus an increment placing it some time in the future ... at which time they should have consumed the allocated resources ... and the process would be repeated.

the "increment" was a calculation based on their administrative priority, smooth avg. of recently used resources compared to target administrative resournce consumption ... and the size of CPU allocation for this queue stay. To the extent that "interactive" tasks had a "nearer" deadline than "outer" tasks ... was based on the amount of cpu/quanta being allocated was significantly smaller.

In effect, "interactive" no longer got better dispatching priority to consume more cpu resources .... however they were allowed to consume their target resources in much smaller, more frequent increments; but the "more frequent" calculation was strictly proportional to the size of the allocation. as previously mentioned ... one of the tricks in all this implementation was to actually use fewer instructions than the much more simple minded approach that it replaced.

minor refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

MAD Programming Language

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAD Programming Language
Newsgroups: alt.folklore.computers
Date: Mon, 29 Sep 2003 19:18:46 GMT

Morten Reistad writes:
Water is an even more complex and fragile affair; so you cannot put any large demands on the water supply. Security beyond the already existing building security is almost undoable in practice. You may try, but you will get bogged down in things like having to reinforce floors, ceilings and perimeter walls with an extremely tight weight budget. And you cannot mess with the building conduits; which normally run right through everything; making a swiss cheese of your security.

earlier threads about csc machine room in 545 tech sq, directly taking in city water and then dumping it down the drain .... no water tower/recycling on roof of the bldg.
https://www.garlic.com/~lynn/2000b.html#86 write rings
https://www.garlic.com/~lynn/2001m.html#40 info
https://www.garlic.com/~lynn/2002i.html#6 how to set up a computer system

as an aside ... one of the LAN benefits ... was that a number of places started running into "floor" loading limits with the weight of 327x coax cables ... snaking thru all the cable trays.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

OSI protocol header

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OSI protocol header
Newsgroups: comp.protocols.tcp-ip
Date: Mon, 29 Sep 2003 19:49:17 GMT

tcs_ganesh@yahoo.com (Ganesh) writes:
In many layered protocols, each layer has its own header. Surely it would be more efficient to have a single header at the front of each message with all the control in it than all these separate headers. Why is this not done?

is this a homework question?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Intel 860 and 960, was iAPX 432

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel 860 and 960, was iAPX 432
Newsgroups: alt.folklore.computers,comp.arch
Date: Mon, 29 Sep 2003 20:55:58 GMT

Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
The i860 was designed to put low-end supercomputing capability into a desktop or small server.

a litte on the iPSC/860 and the i860
http://www.netlib.org/utk/lsi/pcwLSI/text/node15.html
http://www.cacr.caltech.edu/resources/paragon/i860.tutorial.shtml
http://www.netlib.org/benchmark/top500/reports/report94/Architec/node21.html
http://www.wikipedia.org/wiki/Ardent
http://www.research.microsoft.com/~hollasch/misc/kubota.html

and NT started as an i860 project?
http://www.winsupersite.com/reviews/winserver2k3_gold1.asp

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 30 Sep 2003 14:46:44 GMT

"Harlan Messinger" writes:
It's older than the term "outsourcing". It used to be called "time share". Many companies and organizations accessed computing power that way without investing in their own equipment.

two parts ... "service bureaus" ... remember old SBC (spun off to CDC as part of gov. settlement) and "time sharing".

recent blurb on "virtual server services"
http://news.com.com/2100-7339_3-5083775.html?tag=nefd_top

or time-sharing service bureau by any other name

misc. past posts on time-sharing service bureaus
https://www.garlic.com/~lynn/submain.html#timeshare

previous post in this thread
https://www.garlic.com/~lynn/2003l.html#34 Thoughts on Utility Computing?

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

public key vs passwd authentication?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key vs passwd authentication?
Newsgroups: comp.security.ssh
Date: Tue, 30 Sep 2003 18:32:55 GMT

dkoleary writes:
Does anyone have any links to good solid white papers comparing the pros/cons of passwd vs public key authentication?

I have a client that's turned off public key authentication. In order to make them change their minds I have to develop a paper describing why public/private key authentication is so cool.

I have several sources already including the O'Reilly's book; however if someone's already done the comparison along with an indepth examination of the security aspect, it'd make my job a lot easier/ quicker, etc

passwords are shared-secrets ... and as such have a horrible scaling problem ... since the security requirement is that the same shared-secret can't be used in different security domains .... leading to situations where people have tens if not hundreds of shared-secrets that are impossible to remember.

it is possible to substitute public keys in place of passwords and perform digital signature authentication .... eliminating the problem with humans having to remember hundreds of different shared-secrets.

The very straight forward process is to register public keys in lieu of registering passwords and perform digital signature authentication in lieu of password comparison. This has the advantage of maintaining all the existing business processes while addresses the extremely significant human factors problems associated with shared-secrets.

However, most people have been exposed to public keys and digital signature authentication in the context of certificates, certification authorities and PKIs. A horrendous problem with the PKI scenario is that it creates significant new business processes and security operations. Nominally, certication authorities were invented to insert a certification authority inbetween the normal relying party (entity checking the password) and key owner (entity supplying the password) ... to address situations where there was no prior relationship between the relying party and the key owner ... and the relying party had no realtime/online access to the certificaiton authority (aka the letters of credit model from the days of sailing ships).

In situations where there is existing business relationship between the relying party (aka entity checking the password) and the key owner (entity supplying the password), it is trivial to show that the changes necessitated by a certification authority are redundant and superfluous (not to mention typically unnecessary, complex, and expensive).

Simple public key upgrade of existing authentication processes (besides SSH) are public key authentication by radius:
https://www.garlic.com/~lynn/subpubkey.html#radius

and kerberos pkinit
https://www.garlic.com/~lynn/subpubkey.html#kerberos
internet draft that specifies certificate-less public key operation.

other generalized comments about public key certificate-less operation for maintaining existing business processes while changing technology from shared-secret paradigm to non-shared-secret paradigm
https://www.garlic.com/~lynn/x959.html#aads

some discussion of relying-party-only certificates (common method of intergrating PKI-based operations into existing business process) being redundant and superfluous:
https://www.garlic.com/~lynn/subpubkey.html#rpo

misc pieces of recent threads related to the subject:
https://www.garlic.com/~lynn/aadsm15.htm#1 invoicing with PKI
https://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#3 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#5 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#9 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#10 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#16 End of the line for Ireland's dotcom star
https://www.garlic.com/~lynn/aepay12.htm#22 some X9.59 (and little FSTC) ... from crypto mailing list ... fyi
https://www.garlic.com/~lynn/aepay12.htm#31 End of the line for Ireland's dotcom star

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

public key vs passwd authentication?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key vs passwd authentication?
Newsgroups: comp.security.ssh
Date: Wed, 01 Oct 2003 02:50:25 GMT

Michael Sierchio writes:
One-time passwords work reasonably well, and if deployed everywhere in an org they have some nice properties:

They're supported in OpenSSH w/PAM

They require someone to remember only a single passphrase

They're immune to replay

They're interoperable across platforms

typically, one-time passwords have been used to address vulnerabilities with transmiting shared-secret in the clear.

single-sign-on systems have typically been used to address the issue of a plethora of passwords within a single organization or security domain. however, they haven't been very successful at cross business interoperability (like between a local ISP and my employer or bank).

>From RFC2289 ... see reference below ... basically, an institution provides a unique seed for initialization to the entity. THe entity combines the seed, their passphrase and iteratively encodes the combination with a hash algorithm (like SHA-1) possibly a couple hundred times. They then register the count and the resulting value with the institution. When logging on .... the institution sends a challenge in the form of the count decremented by one and the original seed. The entity then repeats the iterative hash encoding the number of specified times (which is one less than previous) and transmits the result. The institution receives the result and performs the hash encoding one more time ... and checks it with the recorded value. If it matches, the entity is authenticated; the institution then stores the decremented count and replaces the recorded hash value with the latest received value.

So what are the advantages of public key over OTP?:

1) digital signature authenticates both the entity as well as the message and 2) digital signature can operate with message originating from the sender w/o real time communcation.

#1) in the RADIUS implementation reference discussed at:
https://www.garlic.com/~lynn/subpubkey.html#radius

one of the issues is a server impersonation as a form of MITM attack. The MITM listens passively on the previous transmission. For the current scenario, the MITM impersonates the server and transmits the challenge (optianable from the previous evesdropping) and receives the results; the MITM impersonating the server then simulates a transmission error and totally hijacks the session.

In the above referenced RADIUS server "challenge" there is a unique number, easily a combination of date/time and random number, sent as the challenge. In the public key version, the entity logging on, digital sings the unique challenge. While it is possible to do a server impersonation to get a digitally signed value, it is not possible to predict the actual challenge that the server will use (defeating an actual MITM exploit). In OTP, it is possible to predict server challenges based on information gained from evesdropping.

#2) The x9a10 working group was given the requirement to preserve the integrity of the financial infrastructure for all electronic retail transactions. In the X9.59 case
https://www.garlic.com/~lynn/x959.html#x959

the client originates the message (w/o any real-time chatter with the server) and digitally signs it, then transmits it to the server. The server eventually receives the message and authenticates both the integrity of the message and the entity sending the message using the recorded public key and returns an approval.

There are two ways of preventing replay attacks: a) real-time challenge response chatter between the entities and 2) recording of previous transactions (and typically including date/time in the message). Some number of asynchronous operations and/or operations requiring a single round-trip implementation use logging as a replay defense.

Public key advantage vis-a-vis OTP
1) no count-down re-initialization
2) works in unique challenge/response paradigm
3) authenticates entity as well as integrity of message
4) works in non-challenge/response paradigm involving things like single round-trip transactions (where server uses something like a transaction log to prevent replay attacks).

aka, it would be possible to use the same public key for all login authentications (as in OTP) where real-time challenge/response is used (say with RADIUS public key or Kerberos certificate-less PKINIT, or digital signature SSH as well as somewhat more resistent to some kinds of MITM attacks) as well as message/transaction authentication requiring both message integrity authentication as well as entity authentication (including various kinds of financial transactions, ala x9.59).

one-time password ref:
http://www.ietf.org/html.charters/otp-charter.html

also go to
https://www.garlic.com/~lynn/rfcietff.htm
and click on Term (term->RFC#) in RFCs listed by section

then click "OTP" in the Acronym fastpath which will bring up:
one-time password (OTP)
see also password
2444 2289 2243 1938 1760

clicking any of the RFC numbers will bring up the RFC summary in the lower frame. clicking on the ".txt=nnnn" field will retrieve the actual RFC.

also in the Acronym fastpath is RADIUS:
remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058

and/or scroll to Kerberos:
kerberos
see also authentication , security
3244 3129 2942 2712 2623 1964 1510 1411

also of interest would be to scroll to
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3588 3539 3127 2989 2977 2906 2905 2904 2903

also see:
http://www.ietf.org/html.charters/aaa-charter.html
http://www.aaaarch.org/index.html

ssh:
http://www.ietf.org/html.charters/secsh-charter.html
http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-17.txt

kerberos:
http://www.ietf.org/html.charters/krb-wg-charter.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

public key vs passwd authentication?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key vs passwd authentication?
Newsgroups: comp.security.ssh
Date: Wed, 01 Oct 2003 14:20:30 GMT

"Lyal Collins" writes:
It's a simple choice, I believe.

PKI solutions depend on passwords to control access to, and use of private keys and public key certs. Thus PKI authentication = password authentication. PKI secures machines accessing other machines, not application security (which latter goal isn't and never was a design requirement for ssh)

In some cases PKI can minimise key management, as long as you can secure and trust the root public key/cert in the local and remote machines. Often, this complexity is as difficult as password or secret key models. Go with the lowest overhead option, imho.

while a password that is used to unlock a private key (which in turn is used to log into a system) and a password that is used directly to log into a system are both secret based, there is an enormous business process difference in their use.

a password used to unlock a private key (although doesn't necessarily have to imply a PKI and/or certificate-based operation) is a "secret".

a password used to directly log into a system, is a shared-secret.

frequently there is reference to 3-factor authentication:
• something you have
• something you know
• something you are

a secrets are vulnerable to social engineering ... but getting you you to dilvulge a shared-secret directly compromises the access. any kind of secret (something you know) is vulnerable to social engineering. However, a 2-factor authentication requires that both a) something you know (aka the secret) is compromised and b) something you have is compromised. In the private-key scenario, the container for the private key has to be obtained (something you have), in addtion to the secret (something you know).

It is actually possible to have a digital signature based protocol with two-factor authentication that is identical whether the private key is contained in a file on your PC or in a hardware token that nominally never leaves your possesion. Then the protocol is identical and the issue of the hardware token is purely the degree and cost of risk management (as opposed to requiring that both the protocol and the end-points be subject to risk management decisions).

the use of shared-secrets creates enormous human operatonal difficulties because of the requirement to avoid using the same shared-secret across different security domains .... leading to problems of not remembering, social engineering, recording them in ways that are vulnerable to compromise, etc.

In the case of current credit card operation over the network, the account number is effectively a shared-secret. Electronic harvesting of the merchant transaction file can put hundreds of thousands of accounts at risk. The use of x9.59 digital signed transactions removes the ability to generate fraudulant transactions just by harvesting the transaction file. misc. reference to security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk

In an x9.59 like environment, with the end-points and the protocol specified with digital signature, then the degree of risk can become one of institutional and/or personal choice .... whether or not your private key is contained in a PC file or a hardware token. If a hardware token, what kind of hardware token and the degree of tamper resistance ... aka given the same fixed digital signature environment, private key containers could run the risk spectrum from nearly was weak as a one-factor, shared-secret to orders of magnitude stronger.

It is possible to deploy a two-factor authentication scheme (using a non-shared-secret) that is nearly as vulnerable to social engineering exploit as a one-factor authentication, shared-secret scheme (i.e. get a person to divulge both the password for the private key file and transmit their private key file) ... however, it can eliminate much of the other vulnerabilities that shared-secret schemes are notoriously subject to (human inability to deal with exploding numbers of shared-secrets, massive harvesting of shared-secret aggregations, etc). Once such a digital signature infrastructure is deployed, it would be possible to perform a risk evaluation on an account by account basis to determine the cost/benefit of a better private key container ... with no impact to the rest of the infrastructre.

In the case of the merchant credit card file ... the existing process of harvesting a single merchant transaction file can directly enable fraudulant transaction against each individual accounts (potentially hundreds of thousands). Changing that to digitally signed X9.59 transactions with private key contained in hardware token, would require physically obtaining a hundred thousand individual hardware tokens and each associated password (at least six orders of magnitude more difficult).

misc. fraud references:
https://www.garlic.com/~lynn/subintegrity.html#fraud

lots of identity theft references ... a large percentage of identity theft is havesting of files containing massive numbers of shared-secrets that directly enable subsequent fraud. Many of these are now being categorized as account fraud within the overall identity fraud classification.
https://www.garlic.com/~lynn/aadsm7.htm#idcard AGAINST ID CARDS
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#rhose16 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
https://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
https://www.garlic.com/~lynn/aadsm12.htm#44 Identity Theft More Often an Inside Job
https://www.garlic.com/~lynn/aadsm14.htm#9 "Marginot Web" (SSL, payments, etc)
https://www.garlic.com/~lynn/aadsm14.htm#12 Tackling security threats from within
https://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expected to Hit $2 Trillion by 2005
https://www.garlic.com/~lynn/aadsm14.htm#51 Feds, industry warn of spike in ID theft scams
https://www.garlic.com/~lynn/aadsm14.htm#53 IT Managers Critical Front in War on Identity Theft
https://www.garlic.com/~lynn/aepay10.htm#1 Identity theft tops Consumer fraud complaints
https://www.garlic.com/~lynn/aepay10.htm#16 Worker Accused of Selling Colleagues' ID's Online (credit card scam)
https://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
https://www.garlic.com/~lynn/aepay10.htm#62 VeriSign unveils new online identity verification services
https://www.garlic.com/~lynn/aepay11.htm#0 identity, fingerprint, from comp.risks
https://www.garlic.com/~lynn/aepay11.htm#3 Ministers to Act on Rise in Identity Theft
https://www.garlic.com/~lynn/aepay11.htm#6 A Look into Banking Trends for 2003
https://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft jumped in 2002
https://www.garlic.com/~lynn/aepay11.htm#8 Internet Consumer Fraud Continues to Rise
https://www.garlic.com/~lynn/aepay11.htm#12 Star study: Identity Theft In The United States: An Update
https://www.garlic.com/~lynn/aepay11.htm#14 More Identity Theft ... Security Stands in Line Behind Other Priorities
https://www.garlic.com/~lynn/aepay11.htm#17 Criminals using high-tech methods for old-style crimes
https://www.garlic.com/~lynn/aepay11.htm#32 Don't-Ask-Don't-Tell E-commerce
https://www.garlic.com/~lynn/aepay11.htm#33 Spam's Being Used For Identity Theft And Blackmail, Symantec Says
https://www.garlic.com/~lynn/aepay11.htm#41 Be Prepared: Gartner Outlines Top Security Risks
https://www.garlic.com/~lynn/aepay11.htm#47 Actual Losses To Identity Fraud Top $1 Billion
https://www.garlic.com/~lynn/aepay11.htm#49 A More Anonymous Internet
https://www.garlic.com/~lynn/aepay11.htm#50 Concern Grows About ID Theft
https://www.garlic.com/~lynn/aepay11.htm#61 HIPAA, privacy, identity theft
https://www.garlic.com/~lynn/aepay11.htm#62 HIPAA, privacy, identity theft (addenda)
https://www.garlic.com/~lynn/aepay11.htm#65 E-merchants Turn Fraud-busters (somewhat related)
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#5 Law aims to reduce identity theft
https://www.garlic.com/~lynn/aepay12.htm#12 Identity theft rockets 80 per cent
https://www.garlic.com/~lynn/aepay12.htm#14 Technology and Crime, Criminal Intelligence Service Canada - 2003
https://www.garlic.com/~lynn/aepay12.htm#19 Tech firms band together on ID theft
https://www.garlic.com/~lynn/aepay12.htm#21 FTC Says ID Theft Greater Problem Than Originally Thought
https://www.garlic.com/~lynn/aepay12.htm#24 More on the ID theft saga
https://www.garlic.com/~lynn/aepay12.htm#26 Bank One Calls Attention to ID Theft
https://www.garlic.com/~lynn/aepay12.htm#30 ID Theft Often Goes Unrecognized
https://www.garlic.com/~lynn/2001d.html#19 [Newbie] Authentication vs. Authorisation?
https://www.garlic.com/~lynn/2001k.html#6 Is VeriSign lying???
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001l.html#29 voice encryption box (STU-III for the masses)
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

public key vs passwd authentication?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key vs passwd authentication?
Newsgroups: comp.security.ssh
Date: Wed, 01 Oct 2003 14:55:58 GMT

Anne & Lynn Wheeler writes:
frequently there is reference to 3-factor authentication:
• something you have
• something you know
• something you are

note that in the generic description of 3-factor authentication, there is nothing about private keys, public keys, digital signatures, etc.

digital signatures are a useful technology since they can both demonstrate that you posses the private key container (authenticating that the electronic transmission originated from you) as well as the integrity of the message in a single operation. As a result the same exact digital signature technology can be used in both a strong form of challenge/response where the challenge can be both

unpredictable and dynamically change

The use of digital signatures is a particularly efficient method of establishing the something you have (and at the same time being able to demonstrate message integrity).

The actual something you have ... can vary on an account by account basis ... meeting specific business needs and risk management profiles. In this scenario, the degree of risk countermeasures for a specific account can be based on the selection of private key container.

Note that none of these considerations and factors either require PKI, certification authorities, and/or certificates .... which can be considered a totally orthogonal business issue. It is trivially possible to deploy a digital signature based two-factor authentication mechanism w/o resorting to PKI business infrastructure in anyway what so ever ... i.e. certificate-less radius, certificate-less kerberos, and/or certificate-less ssh.
https://www.garlic.com/~lynn/2003m.html#49 public key vs passwd authentication
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication

Once something like a digital signature, two-factor authentication infrastructure is deployed (radius, kerberios, ssh, x9.59, etc), it is then possible for individuals to select the integrity of their private key container (pc file or hardware token) w/o impacting other aspects of the protocol (it can become purely an individual security/risk decision). For instance, it is possible to obtain a hardware token that manages a private key such that it can never become known (exploits require obtaining physical possesion of the hardware token).

Again, none of this specific digital signature factors related to the structure and/or security operation even remotely involve PKI, certification authorities, and/or certificates. PKIs, CAs, and certificates are a business process (analogous to the letters of credit from sailing ship days) that were designed to create some trust for two, otherwise, totally unrelated entities that had no previous business interaction and no direct and/or online way of referring to mutually trusted party. They are trivially shown to be redundant and superfluous in almost all present day business interactions involving an existing business relationship (bank/customer, employee/employer, IPS/customer, etc) or have direct timely-access to trusted third party (POS online debit and credit transactions).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

model 91/CRJE and IKJLEW

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: model 91/CRJE and IKJLEW
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 01 Oct 2003 15:34:25 GMT

PaulW@ENET.COM (Paul Wendt) writes:
Ah, CRJE...there's a text editor out of the past!

sometime late '68 (undergraduate at university), i had hacked HASP ... removed the 2780 support and misc. other stuff (to pick up size in the program) and substituted 2741 and TTY support along with an editor that implemented the CMS editor syntax for an early kind of CRJE (it wasn't the actual CMS editor since it was quite non-reentrant, but the same syntax rewritten from scratch).

I had previously added TTY support to CP/67 ... and had tried to implement dynamic terminal recognition (between TTY and 2741). After it seemed to be working, the IBM CE got around to telling me that they had taken short-cut on the 2702 and hardwired the oscilator to individual ports. While it was possible to use the 2702 SAD command to dynamically change the association of the line scanner type to each individual line ... it wasn't actually possible to change the baud rate on a line (since it was hard wired).

THis in turn kicked off the university effort where four of us got blamed for originating the PCM controller business:
https://www.garlic.com/~lynn/submain.html#360pcm

starting with an Interdata/3, reverse engineering the 360 channel interface, building our own channel interface for the Interdata/3 and writing 2702 emulator for the Interdata/3. All in order to get dynamic terminal type (and baud rate) identification.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 01 Oct 2003 20:07:55 GMT

Anne & Lynn Wheeler writes:
recent blurb on "virtual server services"
http://news.com.com/2100-7339_3-5083775.html?tag=nefd_top

or time-sharing service bureau by any other name

misc. past posts on time-sharing service bureaus
https://www.garlic.com/~lynn/submain.html#timeshare

there have been some number of recent references to gnosis/keykos from a security perspective. however within the contenxt of utility computing and time sharing service bureaus and stuff like:
http://www.infoworld.com/article/03/10/01/HNsunsema_1.html

when I was asked to perform due diligence on gnosis was that the fine grain capabiilty wasn't done so much for security isolation (that was also needed in an open time-sharing service bureau operation) .... but that they were trying to tie the fine grain capabilities to accounting/charging operation.

the cp/67 (and then vm/370) virtual machine operation that were used as basis for security isolation at a number of these service bureaus had only relatively gross resource consumption accounting. One of the stated goals that I was given for gnosis was that 3rd party clients could deploy a broad spectrum of applications and services on the time-sharing service bureau platform .... and that gnosis would be able to perform usage accounting by their customers on an application and service basis (remitting charges to the 3rd party clients) ... aka fine grain capabilities weren't so much a security construct (which it also provided) but an usage accounting construct.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

public key vs passwd authentication?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key vs passwd authentication?
Newsgroups: comp.security.ssh
Date: Wed, 01 Oct 2003 21:23:22 GMT

dkoleary writes:
I have a client that's turned off public key authentication. In order to make them change their minds I have to develop a paper describing why public/private key authentication is so cool.

as an aside ... somewhat continuing my previous post.

digital signature technology ... as an authentication mechanism can be deployed within existing business processes that are currently used to support password authentication ... as simply as registering public keys in lieu of registering passwords. Then it is strictly a technology authentication issue ... not a business process issue.

a significant problem frequently sometimes has been the equating digital signatures authentication (which is purely better technology, w/o changing the business processes) and PKIs (which is almost totally a business process change issue).

PKI certificates are there purely as a trust propagation mechanism, analogous to letters of credit (from the days of sailing ships); establishing trust between two parties that had absolutely no previous business relationship and/or any direct recourse to a trusted third party.

The difficulty has been

letters of credit have typically been done within the environment of ongoing financial operations. PKI has frequently attempted to establish trust propagation as a totally free standing business operation.

some of the more grandiose claims for certificates (possibly attempting to support offline trust propagation as a free standing business) would be considered analogous to claiming that it was impossible to have a valid contract w/o letters of credit and/or money couldn't be spent w/o letters of credit.

letters of credit (and certificates, PKIs, certification authorities) have been there as a trust propagation mechanism when there hasn't been any other recourse. however the modern business world has hundreds of mechanisms that can create trust w/o having to resort to a certificate.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

model 91/CRJE and IKJLEW

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: model 91/CRJE and IKJLEW
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 02 Oct 2003 13:18:55 GMT

IBM-MAIN@ISHAM-RESEARCH.COM (Phil Payne) writes:
It had an annoying habit of compressing its libraries online - and I could never find out how to stop it. When it decided to compress 10 cylinders of 3330, it locked up a /158-1 for about ten minutes.

running MVS tending to lock up disks. for a while SJR had MVS running on a 168 and VM/370 running on 158 with interconnected 3330 disk strings. there was guideline that operators were NEVER to mount a MVS 3330 on a nominal VM/370 string. In the cases that it happened, the CMS users would immediately start complaining about severe response degradation. In one situation when the MVS operators refused to immediately relocate the offending 3330 to a MVS string ... we brought up a (optimized) VS1 (for running) under VM with its packs on MVS string and started some applications that did full cylinder multi-track searches .... to so degrade MVS thruput ... that whatever multi-track searches that it might be doing on the pack mounted on VM-string were severely curtailed. The MVS operators at that point decided to quickly switch the drives of the offending MVS and VS1 3330 packs.

An ancillary issue was that TSO performance was so bad ... that the TSO users didn't notice the severe addtional response penalty of running in an MVS environment (or that they had just become accustomed to it). This was also reflected in the CERN (follow the thread of GML originating at CSC thru CERN to HTML and back to Cambridge & W3C for XML, et al) TSO/CMS comparison report presented at SHARE. The TSO comparison was so bad, that the copies of the report internally were classified IBM Confidential Restricted and available on a strictly need to know basis only.

In the early 80s, an attempt to provide MVS with FBA support to migrate it to modern(?) architecture disks was met with a claim that even provided with fully integrated and tested code to take it thru the product process would still cost $26m:
https://www.garlic.com/~lynn/97.html#16 Why Mainframes?
https://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe background
https://www.garlic.com/~lynn/2000.html#86 Ux's good points.
https://www.garlic.com/~lynn/2001.html#54 FBA History Question (was: RE: What's the meaning of track overfl ow?)
https://www.garlic.com/~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
https://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

wsmr-simtel20 shut down 10 years ago today

Refed: **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: wsmr-simtel20 shut down 10 years ago today
Newsgroups: alt.folklore.computers,comp.os.cpm
Date: Thu, 02 Oct 2003 17:39:48 GMT

wiesje_janssen@zonnet.nl (wiesje janssen) writes:
Yeah! Right! I forgot! I remember we could do something like TELL BLA AT BLA and then send some command or other. That way you could have simtel send files. Indeed, you would have to piece them together. Wasn't easy with an EBCDIC machine in the middle, I remember. Anyway, hetting these files took quite a bit of time. I remember there were special RSCS commands (or HASP?) with which you could trace the files. And when they finally crossed the ocean to France, to a machine called FRMOP11 (or something like that) I was home free. Man, these kids are spoiled these days! For good measure, they should teach computer science 101 on a C64, or worse, a ZX80!

misc. earn reference:
https://www.garlic.com/~lynn/2001h.html#65 UUCP email

other past bitnet/earn (& some internal network) references:
https://www.garlic.com/~lynn/subnetwork.html#bitnet

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

The End of Not-Moore's Law?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The End of Not-Moore's Law?
Newsgroups: comp.arch
Date: Thu, 02 Oct 2003 17:41:54 GMT

jbs writes:
No doubt there were many things wrong with the Ariane 5 software design process (starting with the choice of ADA) but nevertheless basically the same software worked well enough for Ariane 4. As far as I know the exception caused by an otherwise harmless overflow was the only fatal problem and hence the direct cause of the failure. Similarly no doubt NASA could do many things better but 98% of the shuttle launches have not failed. The foam striking the wing leading edge was the only fatal problem and the direct cause of the Columbia failure.

o-rings?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

SR 15,15

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SR 15,15
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 02 Oct 2003 18:02:13 GMT

Anne & Lynn Wheeler writes:
this certain 37xx product supported 56kbit links and would support multiple 56kbit in "fat pipes". When they did a survey to find out the 37xx "fat pipe" install base .. they found lots of two-56kbit fat pipes, lots of three-56kbit fat pipes, lots of four-56kbit fat pipes and little or no five-56kbit fat pipes.

slightly related to the above:
https://www.garlic.com/~lynn/2003m.html#28 SR 15,15

a definition that was distributed on a friday from raleigh regarding a new online discussion list:


low-speed               <9.6kbits
medium-speed            19.2kbits
high-speed              56kbits
very high-speed         1.5mbits

seen on the wall of a conference room in tokyo the following monday


low-speed               <20mbits
medium-speed            100mbits
high-speed              200-300mbits
very high-speed         >600mbits

above taken from old posting in a.f.c
https://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)

other high speed data transport (HSDT) project references:
https://www.garlic.com/~lynn/subnetwork.html#hsdt

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

S/360 undocumented instructions?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 undocumented instructions?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Oct 2003 15:59:34 GMT

ibm-main@LDWOREN.NET (Leonard Woren) writes:
In a mixed workload, the loop mode light still flickered a lot. It really wasn't hard to write code which ran in loop mode, at least if you were writing in assembler...

it was enuf of a problem that in the mid70s there was a project to do a dual i-stream 370/195 (although it never shipped); something that is all the rage in current chips .... add support for second instruction stream ... so that if there is some stall in one instruction stream, the processor might keep busy with the other instruction stream.

it wasn't really a multiprocessor ... just a second PSW, addtional set of registers, each instruction as part of decode would have a one-bit flag indicating the instruction stream.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

next, previous, index - home