List of Archived Posts
2002 Newsgroup Postings (05/20 - 06/27)
- Search for Joseph A. Fisher VLSI Publication (1981)
- DISK PL/I Program
- DISK PL/I Program
- Future architecture
- Future architecture
- Coulda, Woulda, Shoudda moments?
- Biometric authentication for intranet websites?
- disk write caching (was: ibm icecube -- return of
- Biometric authentication for intranet websites?
- Biometric authentication for intranet websites?
- Digital signature
- Why did OSI fail compared with TCP-IP?
- Why did OSI fail compared with TCP-IP?
- Biometric authentication for intranet websites?
- Why did OSI fail compared with TCP-IP?
- Coulda, Woulda, Shoudda moments?
- Why did OSI fail compared with TCP-IP?
- disk write caching (was: ibm icecube -- return of
- Address Spaces
- PowerPC Mainframe?
- PowerPC Mainframe?
- PowerPC Mainframe
- Why did OSI fail compared with TCP-IP?
- System/360 shortcuts
- PowerPC Mainframe
- Coulda, Woulda, Shoudda moments?
- Future architecture
- Why are Mainframe Computers really still in use at all?
- backup hard drive
- Computers in Science Fiction
- Multics hardware (was Re: "Soul of a New Machine" Computer?)
- Computers in Science Fiction
- Computers in Science Fiction
- The multiverse is out there !
- Computers in Science Fiction
- Computers in Science Fiction
- Computers in Science Fiction
- Computers in Science Fiction
- The 64-bit landscape in 2005
- Oh, here's an interesting paper
- [survey] Possestional Security
- Biometric authentication for intranet websites?
- Looking for Software/Documentation for an Opus 32032 Card
- IBM doing anything for 50th Anniv?
- 50 years ago (1952)?
- Future architecture [was Re: Future micro-architecture: ]
- Future architecture
- Why did OSI fail compared with TCP-IP?
- Why did OSI fail compared with TCP-IP?
- Coulda, Woulda, Shoudda moments?
- crossreferenced program code listings
- Why did OSI fail compared with TCP-IP?
- Bettman Archive in Trouble
- Bettman Archive in Trouble
- Bettman Archive in Trouble
- Future architecture [was Re: Future micro-architecture: ]
- history of CMS
- Future architecture [was Re: Future micro-architecture: ]
- history of CMS
- history of CMS
- Java, C++ (was Re: Is HTML dead?)
- Java, C++ (was Re: Is HTML dead?)
- history of CMS
- Sizing the application
- history of CMS
- Bettman Archive in Trouble
- How does Mozilla 1.0 compare with Opera?
- history of CMS
- Are you really who you say you are?
- history of CMS
- history of CMS
- history of CMS
- history of CMS
- Where did text file line ending characters begin?
- Where did text file line ending characters begin?
- time again
- time again
- time again
- Q: Is there any interest for vintage Byte Magazines from 1983
- Al Gore and the Internet
- Al Gore and the Internet
- Al Gore and the Internet
- Al Gore and the Internet
- Signing with smart card
- history of CMS
- Al Gore and the Internet
- Al Gore and the Internet
- Atomic operations redux
- IBM 2540 Card Read Punch - documentation wanted
- How secure is SSH ?
Search for Joseph A. Fisher VLSI Publication (1981)
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Search for Joseph A. Fisher VLSI Publication (1981)
Newsgroups: comp.arch
Date: Mon, 20 May 2002 20:06:15 GMT
cyril.chevrot@asim.lip6.fr (Cyril Chevrot) writes:
And more generally, Is there anyone who knows a place on the WEB where
I could find a publication search engine.
possible the major (generalized) library (as opposed to NLM) search
engine around the world ... since at least the 70s sometime has been
Dialog ... original a Lockheed subsidiary .. now "A Thomson Company"
(i think it passed thru a number of hands after lockheed sold it
off). I use to visit them periodically in the '80s .. they had one of
the larger disk farms & cluster mainframe operations in silicon
valley.
http://www.dialog.com/
This is Dialog.
Providing more than 12 terabytes of content from the world's most
authoritative publishers, and the products and tools to search every
bit of it with speed and precision. We are a company founded on the
idea that information matters -- that it really can make a difference
in the world -- or your corner of it.
================================
(libraries pay subscription for it, looks like you can use a credit
card).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
DISK PL/I Program
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DISK PL/I Program
Newsgroups: bit.listserv.ibm-main
Date: Mon, 20 May 2002 23:04:57 GMT
Mark.Thompson@MOTOROLA.COM (Mark Thompson) writes:
Looking for source code to an MVS program called DISK, circa 1984. It is
written in PL/I and apparently used to break up a long MVS record into
smaller chunks. The program accepts parameters like LOAD and DUMP and each
record in the output file (on MVS) is prefixed by "CMS" in column 2 and a
VM file name on the end. I think the resulting file is transmitted to a VM
system and reassembled there by some programs called MVSGET/MVSPUT.
the format is standard CMS DISK utility (going back to CP/67
... mid-60s). If the MVS is done right ... the standard CMS DISK
(load) utility should be able to process the file.
>From CMS Logic Manual (60s):
DUMP: DISK copies the file designation from the parameter list into
bytes 58-76 of an 80-byte buffer (The first four bytes of the buffer
contain an identifier consisting of an internal representation of a
12-2-9 punch and the characters 'CMS'). Then DISK temporarily changes
of the characteristics of the file in the 40-byte FST entry to make it
appear as a file of 800-byte fixed-length records (The correct FST
entry is restored when the file has been dumped, of course). DISK
moves the initial value for sequencing (0001) into bytes 77-80 of the
buffer. DISK next acll the RDBUF function program to read the first 50
bytes of the temporary copy into bytes 6-55 of the buffer and then the
CARDPH function program to punch the contents of the buffer. Having
punched the first card, DISK increments the sequence number (bytes
77-80 of the output buffer) and overalys bytes 6-55 of the buffer with
the next 50 bytes of the file by calling RDBUF. It then punches the
contents of the buffer. DISK repeats this process for each subsequent
50 bytes of data in the temporary disk file. When the end-of file is
encountered, DISK generates an end card (one with N in column 5) and
punches it, calls the CLOSIO command program to close punch
operations, restores the FST entry to it correct value and returns to
the caller.
.....
58-76:
58-65 8 byte filename
66-73 8 byte filetype
74-75 2 byte filemode
76 1 byte .. (blank?)
doesn't say in the description and long time since I looked at the
code ... but presumably byte 5 is cleared to a blank.
Also, some portion of the 40-byte FST should be on the "N" card ... in
cols 6-55 ... aka
... date written last
... number of items
... F/V flag
... fixed length or variable max. length
... year
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
DISK PL/I Program
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DISK PL/I Program
Newsgroups: bit.listserv.ibm-main
Date: Tue, 21 May 2002 15:11:36 GMT
Breton.Imhauser@ACXIOM.COM (Imhauser Breton - bimhau) writes:
I wrote one in assembler many moons ago, but would be hard pressed to find
it. You might look at file 149 on the CBT. Keep in mind, that the newer
DMSDDL ("NetData") format is supported by both CMS ("sendfile") and TSO/E
("xmit"), which is a bit more efficient (specifically run-length encoding).
"newer" as in late 70s rather than mid-60s ... after NJE was released
for JES2 (significant issue for netdata format was jes2 compatibility)
... only 25 years old instead of almost 40 years old.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Future architecture
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Future architecture
Newsgroups: comp.arch
Date: Tue, 21 May 2002 14:59:29 GMT
cecchi@signa.rchland.ibm.com (Del Cecchi) writes:
My belief is that it will take non-procedural languages to allow wide spread used
of parallel computation. The EDA world is full of them at a high level. It
would be pretty tough if I had to simulate a circuit by writing a fortran
program. Rather I describe it in SPICE (which ends up in C or fortran or
something) and let the computer take care of it. The fact that the Spice gets
made into a sequential vrs a parallel type program is of no concern to me.
hspice had large grain parallelism in the early/original versions
... based on some of the comments, for some of the 80s mini-supers.
that code atrophied and a friend of mine got the assignment several
years ago to re-activate it ... testing up thru 8-way. tidying up the
code so that the process/signal were again operational was an
interesting task. at that level, I don't think the (procedural)
implementation language made much difference ... but being able to
take specification and parallize it did.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Future architecture
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Future architecture
Newsgroups: comp.arch,comp.sys.super
Date: Tue, 21 May 2002 18:40:16 GMT
David Gay writes:
In an attempt to be clearer than my other post: I'd like to see some
evidence that people can effectively program by thinking concurrently
(or whatever you're implying is opposite to "thinking sequentially").
I think a lot of people do that today already ... it is just dealing
with problems that are not sequential in nature ... but lets say more
holographic. the hspice scenario was that the domain semantics for the
nets don't have stricly sequential procedural requirement ... although
it would be hard to discover that from the procedural language that
loops on the arrays. the set of domain problems that can be expressed
in nets/graphs semantics lend themselves somewhat better to
parallelization than those that have been expressed stricly in
sequently steps.
the converse is also true ... i once had to listen to a long diatribe
about a new fighter plane heads-up display that was scrolling digital
read-outs ... rather than more of an analogy graphical display (aka
thesis was that human brain is actually much less efficient with
strictly sequential digital processing).
One might contend that the human brain has a problem thinking about
concurrent sequential operations ... lets say in contrast to various
modes of simultaneous parallel processing. possibly one of the banes
of programming all these years is just that problem ... trying to
translate relatively parallel thinking into a set of sequential steps;
and then once forced into that paradigm ... then trying to again do a
paradigm jump to concurrent sequential steps.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Coulda, Woulda, Shoudda moments?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Tue, 21 May 2002 19:59:16 GMT
ehrice@his.com (Edward Rice) writes:
DARPA recognized where the bandwidth was going and tightened things up a
LOT. People with legitimate university access could still play without
restriction; people with legitimate contractor contacts could still play
without restriction (unless you posit that everybody associated with MITRE
was connecting up to the un-metered network only to do MITRE official
business, a theory I've never heard proposed before); but the basic
civilians on the street no longer had access. Unless someone slipped them
a password to a TIP or IMP dial-up number.
there was a claim that the IMP-based route-finding administrative
chatter was starting to use up a significant portion of the available
bandwidth. One of the reasonse that it was going to be unlikely that
the IMP-based stuff was ever going to scale much past 200 nodes in any
case.
the 1/1/83 change-over from IMP-based network to "internet" changed
all that (and the gateway stuff in the internet architecture started
to open up networking .... one of the reasons I claim that internet
finally caught up and passed the internal network size).
one of the other reasons that the internet took off was the
availability of BSD tcp/ip support ... which DARPA told UCB (a number
of times) that BSD specifically wasn't suppose to work on networking
support.
in the recent osi thread there were comments that the 80s bandwidth
was nickle and dime stuff ... it wasn't until the NSFNET1 backbone
came along ... and the enormous resources put in by commercial
companies (far in excess of what gov. was paying for) ... that the
issue of "acceptable use policies" started to rear its head (and the
facade that it was even a significantly gov. funded activity).
if you went around all the booths at Interop '88 (aka the internet was
making a major transition to signification commercial involvements)
... the majority of booths were demonstrating support/productes that
were tahoe4.3 based (which the gov. had specifically forbidden to
happen ... possibly because BBN had the IMP networking ... they
believed BBN should have all of the internet networking activity; does
anybody know of any significant BBN derived "internet" support? ... as
opposed to tahoe/reno).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Biometric authentication for intranet websites?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric authentication for intranet websites?
Newsgroups: comp.security.misc,comp.security
Date: Wed, 22 May 2002 00:50:03 GMT
Todd Knarr writes:
They generally digitize the relevant information and send it to a server,
which matches it against a database and tells your software the record the
biometrics match. The software then decides whether the action is OK for
the holder of that record.
There was a major biometrics project that started just recently, with a
supermarket chain using fingerprint readers to augment or replace credit
card readers at the checkout stands. Within a week of deployment an amateur
found a way to fool the readers ( including the ones with temperature and
resistivity sensors designed to distinguish between living human fingers
and artificial material or dead fingers ) 80% of the time, using nothing
more than common gelatin, some superglue and hobbyist PCB etching supplies.
He even managed to apply it with guards watching for fakery. This is not
a good sign. And worse: if your biometrics do end up being faked, how do
you change your password ( the biometric data ) so that the thief can't
gain access anymore?
note that for x9.84 biometrics standard where transmittal of biometric
matching data is involved, has huge section on security of the sensor
and the security of the transmittal and the security of the backend
database and the security of the matching function.
I think that there is a pilot kind of deployment in the houston area
involving armored-platted ATM machines under video camera survelliance
and highly encrypted, secure private network and financial institution
backends that have external fips140-3 or fips140-4 external boxes.
note that the above faking of fingerprints is in an environment that
some amount of the population writes their PIN numbers on their card.
The issue is that both PIN numbers and the owners fingerprints are
left laying around on the card. The question is: is it easier to read
a PIN number left written on the card and type it into a PIN pad
fraudulently or is it easier to do the above process on a fingerprint
left on the card and enter it fraudulently on a fingerprint
sensor. Say within a 4hr window of time can I find a lost card, read a
PIN written on the card, take it to a ATM machine, stick the card in
and fraudulently enter the PIN ... or is it simpler/faster to retrieve
fingerprints from the card and do the above process, entering a
fingerprint fraudulently (instead of entering a PIN fraudulently).
note that whether it is the PIN scenario with a lost/stolen card or a
fingerprint scenario with a lost/stolen card ... the card gets
reported lost/stolen and is invalidated and a new card is issued.
while you may not have much opportunity to change the fingerprint
associated with the new card ... and you can write a different (or
same) PIN on the new card; the thief would still have to re-steal the
new card. I'm still somewhat amazed that we don't have demos of
somebody stealling a card and showing how hard it is to fraudulently
enter a PIN that has been written on the (stolen) card.
now for the population that claim that they would never, ever write
their PIN on the card ... and really aren't comfortable with anything
less than random 8digit PINs ... let them have the option of 8digit
PINs.
all of these considerations change significantly if you happen to be
reducing it to purely electronic (random pc, connecting randomly to
some random ISP, going to some random website); digital evesdropping
of the whole transaction and then fraudulently replying the same bits
doesn't require any of the above physical stuff (whether it is the PIN
bits or the fingerprint bits).
one of the issues is where there is requirement for some physical
presense you can somewhat be sure that it is at least 2-factor
authenticationn ... aka at least something you have (a physical
card) and either something you know (i.e. PIN) or something you
are (i.e. biometric). going to the purely electronic environment (aka
typical web surfing) reduces to just a bunch of bits (no longer can
prove the physical card). To migrate to the internet electronic
environment starts to need tamper-evident chipcards with correct
operation influenced by PIN &/or biometric entry. None of these are
absolutely 100% bullet-proof ... an issue is the difficulty level
vis-a-vis the reward.
misc. recent random threads:
http://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002f.html#28 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002f.html#32 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002g.html#56 Siemens ID Device SDK (fingerprint biometrics) ???
http://www.garlic.com/~lynn/2002g.html#72 Biometrics not yet good enough?
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio1 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio2 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio4 Fingerprints (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio8 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aepay10.htm#5 I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aepay10.htm#15 META Report: Smart Moves With Smart Cards
http://www.garlic.com/~lynn/aepay10.htm#20 Security Proportional to Risk (was: IBM Mainframe at home)
misc. other fraud threads:
http://www.garlic.com/~lynn/subtopic.html#fraud
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
disk write caching (was: ibm icecube -- return of
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: disk write caching (was: ibm icecube -- return of
watercooling?)
Newsgroups: comp.arch,comp.arch.storage
Date: Wed, 22 May 2002 15:23:29 GMT
"Bill Todd" writes:
Can't it just read backward from EOF, using the LF delimiters which should
be present in most files 'tail' is used on?
I believe it uses direct byte addressing and then (internally)
simulates records using line delimiters.
zippy also does this ... attempting to extract a random item
(collections from the zippy file). since filesystem doesn't directly
know about items ... zippy uses random byte location and then moves
forward to start of item ... this is only truely random if all items
are the same length ... however not being able to directly address
items means that longer items are over selected compared to shorter
items (and special case if random is in the middle of the last item).
now somebody did something similar for the 6670 separator sheet
... but using the ibm jargon file; however by making each entry a
variable length record; the filesystem gives the total number of
(variable length) records, run random to come up with a pro-rated
record number ... and then read that record. the 6670 was early page
printer (built on ibm copier-3 base). The cover sheet was printed from
the alternate paper tray (loaded with different colored paper). Name &
file information only occupied the top couple lines of the page ... so
there was plenty of room to print a random entry from the jargon file.
long ago and far away i found there was also a "feature" in zippy/unix
attempting to run it against the ibm jargon file. zippy was using
16bit int for the random byte location calculation ... zippy file was
about 30kbytes ... while jargon file is more like 300kbytes. total
coincidence but the issue of 16bit (or actually 15bit since sign gets
truncated) for random number was just raised in sci.crypt and
cryptography mailing list with regard to the msoft VC6 library random
number function.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Biometric authentication for intranet websites?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric authentication for intranet websites?
Newsgroups: comp.security.misc,comp.security
Date: Wed, 22 May 2002 15:53:43 GMT
Todd Knarr writes:
2-factor authentication would work, but you need to be really careful
because you're depending _entirely_ on the non-biometric factor for
your whole system's security. When you boil the probabilities for the
fingerprint readers down, they become equivalent to a single-digit
password, digits 1-5, where any 4 of the 5 digits are valid and only
1 would be considered a miss. Would you trust that half of a system
to protect anything if the other half failed? I wouldn't. And aren't
you down to depending on the single other factor then?
there is a statement/premis that there is significant portion of the
population that writes their PIN number on their card (and/or leaves
their fingerprint on their card). The question raised is if i found
such a card in front of an ATM machine and wanted to use it
fraudulently ... would it be easier to insert the card into the ATM
machine and fraudulently enter the PIN number written on the card or
easer to lift the fingerprint off the card and fraudulently enter the
fingerprint?
PINs represent some real-world challenges regardless of how many
documents say that nobody is every allowed to write their PIN number
on their card.
Then there could be choice ... just offer people their choice with
regard to PIN or fingerprint ... and for the population that would
never write their PIN on their card ... and would only use a PIN that
was a random 8digit number ... let them have that choice.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Biometric authentication for intranet websites?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric authentication for intranet websites?
Newsgroups: comp.security.misc,comp.security
Date: Wed, 22 May 2002 16:16:18 GMT
"Scott Bussinger" writes:
misc. recent random threads:
Thanks for the pointers, but in all that there wasn't any apparent
references to real products. Do you have any links to some real products
that work in this arena?
Thanks!
there is some discussion of possibility of biometrics in conjunction with
the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads
a PIN version of the aads chip strawman had a booth at
cardtech/securetech in new orleans a couple weeks ago.
there were a number of other booths at the show demonstrating
biometric products ... see some of the exhibtors at:
http://www.ct-ctst.com/ctst2002/
infineon had an interesting demo in their booth. they've been working
on a fingerprint sensor that meets iso 7816 card flexing standards
... i.e. the sensor is actually on the card. they showed 8inch chip
wafer (i.e. the sensor is manufactured in the same way computer chips
are manufactured with silicon wafers) ... the wafer was held
vertically with the top and bottom attached to two arms ... the two
arms started with the wafer flat & vertical ... and then would pull
the top & bottom points nearly together so that the wafer was bowed &
nearly doubled in half. The wafer then was straightened ... this
flexing and straightening ran continuously in the booth.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Digital signature
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Digital signature
Newsgroups: comp.security.misc
Date: Wed, 22 May 2002 16:01:23 GMT
"Dodger" writes:
Do you think they'd reduce the bank charges if fraud stopped?
an alternative view is that debit already provides a different fee
structure thatn credit. if the aads implementation used in the nacha
pilot for internet atm/debit was widely deployed ... would you see a
change in bank charges?
misc. aads refs and pointer to nacha ATM/debit aads trial
http://www.garlic.com/~lynn/x959.html#aads
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Why did OSI fail compared with TCP-IP?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++
Date: Wed, 22 May 2002 16:30:30 GMT
"Rudvar Alswill" writes:
This confirms my suspicions for many years that IBM understood very
little about networking and communications.
SNA was terminal communications ... and did it very well ... managing
huge numbers of terminals ... a medium size corporate installation
might have 65,000 terminals connected to a mainframe.
The (IBM) internal coporate network had effectively the equivalent of
gateways from the beginning and one of the attributes that the
internal network was larger than the arpanet/internet until
approx. mid-85 (with arpanet/internet not getting internetworking and
gateways until the 1/1/83 switch-over).
now it may be true that SNA didn't have networking ... but it had one
of the most sophisticated communication structures for supporting
terminals. on the otherhand, the people responsible for the internal
network (and the technology for bitnet) understood networking quite
well ... having effectively supported gateways from the very beginning
(circa 1970 ... versis arpanet/internet not getting it until 1/1/83).
people with SNA infrastructures could get service level agreements
... contractual commitments for operational characteristics with
penalties for not meeting the commitments. when did internet start
providing service level agreements?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Why did OSI fail compared with TCP-IP?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++
Date: Wed, 22 May 2002 18:49:40 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Well, as far as I recall, UK academia was already largely networked,
and certainly the University of Cambridge was. Various serial line
protocols, the Coloured Books and so on. Back in 1972, we regarded
IBM (as seen through its products) as understanding very little
about networking and communications - and we we right. Which
doesn't mean that the revisionists are correct that the pre-TCP/IP
cabal of the day understood much more about how deliver solutions
to real users, reliably and on a budget.
many of the large communication infra-structures were ibm mainframe
... things like airline reservation systems ... connecting to every
reservation office in the world ... even in the '60s ... things as
little as thousands of locations could be considered small ... getting
into tens of thousand of connections in the '60s & '70s wasn't
uncommon ... along with service level agreements, contractual
commitments with penalty clauses. Then along came things like ATM
machines in the '70s. For some infrastructures .... it isn't real
communications unless you have SLAs ... otherwise it is just toys for
playing.
not that this kind of infrastructure isn't a peer-to-peer operation
... but it surely is communicaiton. my wife did a short stint in the
SNA architecture group and got into trouble for trying to do
peer-to-peer. She also authored the peer-coupled shared data
architecture when she was in pok in charge of loosely-couple (aka
mainframe cluster) architecture (which took a while to emerge in
products).
it is like some of the threads about interactive time-sharing ... and
ibm not supporting interactive time-sharing. the counter argument was
that IBM may have had one of the largest interactive time-sharing
install bases ... but because 99 percent of the market was commerial
batch ... that when people thot of IBM they tended to think of
commercial batch. The corollary is that there was also a large
networking install ... but because possibly 99 percent of the market
was non-peer-to-peer terminal communication ... the dominant image was
non-peer-to-peer terminal communication (and possibly the majority of
the people/products that came into contact were the ones specialized
in non-peer-to-peer terminal communication).
misc. refs to APPN networking, SNA architecture review board presentation,
etc:
http://www.garlic.com/~lynn/2000.html#53 APPC vs TCP/IP
http://www.garlic.com/~lynn/2001i.html#21 3745 and SNI
http://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
http://www.garlic.com/~lynn/2001k.html#21 OT: almost lost LBJ tapes; Dictabelt
i worked on the first ibm telecommunication controller clone when i
was an undergraduate in the '60s. that spawned the 360 pcm controller
business. during the last 30 plus years pcm controller industry wasn't
exactly small potatoes (and the pcm controller manufactures didn't even
have a majority of the business).
http://www.garlic.com/~lynn/subtopic.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Biometric authentication for intranet websites?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric authentication for intranet websites?
Newsgroups: comp.security.misc,comp.security
Date: Wed, 22 May 2002 19:08:58 GMT
"Scott Bussinger" writes:
Actually, it'd be much easier for a variety of reasons (there are bound to
be some people that can never get the knack of using the fingerprint device
for instance). The problem is that the users will get lazy and just leave
the token inserted into the machine the entire time (and probably walk away
from it periodically since these are generally shared-access machines).
The idea with using fingerprints is that they won't leave their fingers in
the sensors all the time. Another possibility is using a cardswipe system
and make them swipe the card each time. I'm just trying to figure out what
will work best.
many of the current hardware tokens have "personalities" and/or at
least their applications have personalities. financial transactions
require that PIN/biometric re-entry is required for every operation
... not only from the stand-point of authentication but from the
standpoint that the re-entry of the PIN/biometric re-entry implies
intent, agrees, approves, and/or authorizes, with respect to the
specific operation.
Many access-card personalities just require that the PIN/biometric has
been entered since the token was powered on (as opposed to every
time).
In one of the standards meetings there was some consideration to the
design of hardware tokens for laptops ... that it was not possible to
leave the token connected when the laptop was closed. One of the
suggested advantages for dongles on a keyring ... was that you would
take the keyring with you when you closed the laptop ... also you
wouldn't leave it in your office PC overnight. Other suggestions that
it served dual-purpose as door-badge access to get out of the building ...
again addressing the issue of leaving it plugged in when you
left. Requiring that you use your dongle to visit the restroom wasn't
an issue of wanting to know when you were visiting the restroom but
addressing the human nature problem of people leaving their hardware
tokens connected when they got up for some reason.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Why did OSI fail compared with TCP-IP?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++
Date: Wed, 22 May 2002 21:28:07 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Yes, I know of its size, but it was unbelievably primitive! Perhaps
10 years behind ICL in terms of (software) technology, and even
further behind the leaders. I present MVT+TSO as evidence, and doubt
that I need to say more!
mvt was batch processing ... tso was crje under any other name (in
fact in the late '60s i did a modified version of HASP that supported
2741s and teletypes with CMS editor syntax). that is not to say that
there wasn't internal politics. cern did a tso/cms bake-off in '74 and
published the results at share. Inside the company this public
document was given a classification of IBM Confidential Restricted
(available on a need to know basis only).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Coulda, Woulda, Shoudda moments?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Thu, 23 May 2002 14:46:38 GMT
Dennis Ritchie writes:
I don't have enough connected material to write the full history,
but offer these snippets:
at least one line from:
http://www.be.daemonnews.org/199909/usenix-kirk.html
about Fabry "yes them to death" ... "much to the frustration of the
DARPA advisory board"
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Why did OSI fail compared with TCP-IP?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch
Date: Thu, 23 May 2002 15:00:31 GMT
Bernd Paysan writes:
IMHO the primary design mistake in TCP/IP is that it does not use a split
control/data stream approach, but uses the header for all possible controls
(which falls short, because the TCP designer only anticipated controls for
a stream-oriented pipe). That makes the packets larger than necessary and
the handling more complex, especially of higher-level protocols like FTP
and HTTP, which have control messages and data channels, and either must
try to use a single TCP socket for both (HTTP), or goes through hoops to
create a second one for data transfers (FTP).
see RFC721 ... Out-of-Band Control Signals in a Host-to-Host Protocol
and problem with TCP using in-band.
small extract at
http://www.garlic.com/~lynn/2000.html#72 Difference between NCP and TCP/IP protocols
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
disk write caching (was: ibm icecube -- return of
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: disk write caching (was: ibm icecube -- return of
watercooling?)
Newsgroups: comp.arch,comp.arch.storage
Date: Thu, 23 May 2002 14:51:57 GMT
Terje Mathisen writes:
I believe we could borrow the currently accepted term from the DB
people:
BLOB, for Binary Large OBject
lorie (the "L" in GML, goldfarb was "G" and Moshe was "M" ... GML
being all done at CSC) did a lot of work on BLOB after transferring
from CSC to SJR ... but I don't think the blob work started until
after the tech transfer of System/R from SJR to Endicott for SQL/DS
... possibly in R* (r-star) timeframe ... mid 80s.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Address Spaces
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Address Spaces
Newsgroups: comp.lang.asm370
Date: Thu, 23 May 2002 16:49:28 GMT
"Sven Pran" writes:
Well, I distinctly remember when we replaced our four 2311
disk stations (each holding 7,5MB of data) with 2314.
Quadrupling the on-line storage capacity was an immense
improvement!
(VSAM????? We had DTFSD, DTFIS and DTFDA)
Sven
and the whole vtoc design point was 2311s.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
PowerPC Mainframe?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PowerPC Mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 23 May 2002 20:53:19 GMT
jcewing@ACM.ORG (Joel C. Ewing) writes:
Based on the obvious lack of familarity of the writers of that article
with the mainframe world, I would expect a misinterpretation. The quote
from the editor of Microprocessor Report (Krewell) that this "...would
allow Big Blue to take advantage of more modern features ... the ability
to carry out several operations simultaneously" obviously shows a total
lack of familiarity with the parallelism that has been in mainframe
processors for decades.
note that fort knox was going to have all the low & mid-range machines
(including endicott machines, but not restricted to 370s) use 801
"micro-engines" as their base. fort knox got killed, in part because
they were pushing direct hardware implementations down into the
midrange i.e. trade-off was next generation mid-range being 801 with
micro-code implementation for 370 ... or chips that had move of the
370 directly implemented in hardware. fort knox got killed ... which
freed up some number of 801 engineers ... I believe some of which
started appearing in other companies working on RISC chip
implementations. I believe that 801s were used in 3090 IOCP engines.
I think the next big push was getting 390 processor into similar cmos
technology that was being used for risc.
there was some recent discussion of the pipelining problem for 360
over in comp.arch ng ... and pioneering efforts in this area with
360/91, 360/195, 370/195. The issue back then was branch instructions
draining pipeline because of the lack of circuits to implement
speculative execution. Now speculative execution past branches is
fairly common.
an innovative thing done by 801 was the separtion of I & D streams
(harvard architectures). One of the cost items that has been carried
from 360 days is the overhead checking for self-modifying instruction
streams (which doesn't need to be done in risc machines).
some part of fort knox was eventually sort-of achieved with the
migration of as/400 to power/pc.
pieces of the thread:
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
for the rest search on the above subject in comp.arch ng in google
groups ... there were some other posts about cost/penalty of
supporting self-modifying instruction streams on 370.
misc. fort knox references:
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
http://www.garlic.com/~lynn/2001h.html#69 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002g.html#39 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
past 801, risc, pl.8, CPr, etc posts
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
http://www.garlic.com/~lynn/94.html#47 Rethinking Virtual Memory
http://www.garlic.com/~lynn/95.html#5 Who started RISC? (was: 64 bit Linux?)
http://www.garlic.com/~lynn/95.html#6 801
http://www.garlic.com/~lynn/95.html#9 Cache and Memory Bandwidth (was Re: A Series Compilers)
http://www.garlic.com/~lynn/95.html#11 801 & power/pc
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/97.html#5 360/44 (was Re: IBM 1130 (was Re: IBM 7090--used for business or
http://www.garlic.com/~lynn/98.html#25 Merced & compilers (was Re: Effect of speed ... )
http://www.garlic.com/~lynn/98.html#26 Merced & compilers (was Re: Effect of speed ... )
http://www.garlic.com/~lynn/98.html#27 Merced & compilers (was Re: Effect of speed ... )
http://www.garlic.com/~lynn/98.html#31 PowerPC MMU
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/99.html#129 High Performance PowerPC
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#16 Computer of the century
http://www.garlic.com/~lynn/2000.html#49 IBM RT PC (was Re: What does AT stand for ?)
http://www.garlic.com/~lynn/2000.html#59 Multithreading underlies new development paradigm
http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000c.html#3 RISC Reference?
http://www.garlic.com/~lynn/2000c.html#9 Cache coherence [was Re: TF-1]
http://www.garlic.com/~lynn/2000d.html#28 RS/6000 vs. System/390 architecture?
http://www.garlic.com/~lynn/2000d.html#31 RS/6000 vs. System/390 architecture?
http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000d.html#65 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#84 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#12 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984??
http://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
http://www.garlic.com/~lynn/2001f.html#45 Golden Era of Compilers
http://www.garlic.com/~lynn/2001f.html#58 JFSes: are they really needed?
http://www.garlic.com/~lynn/2001g.html#23 IA64 Rocks My World
http://www.garlic.com/~lynn/2001h.html#69 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
http://www.garlic.com/~lynn/2001k.html#23 more old RFCs
http://www.garlic.com/~lynn/2001l.html#50 What makes a mainframe?
http://www.garlic.com/~lynn/2001n.html#12 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#80 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2001n.html#87 A new forum is up! Q: what means nntp
http://www.garlic.com/~lynn/2002b.html#29 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002g.html#5 Black magic in POWER5
http://www.garlic.com/~lynn/2002g.html#11 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#14 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
http://www.garlic.com/~lynn/2002g.html#39 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
PowerPC Mainframe?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PowerPC Mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 23 May 2002 23:36:34 GMT
gah@ugcs.caltech.edu (glen herrmannsfeldt) writes:
Is this because RISC architectures define not allowing self-modifying
code? Presumably some way to tell the processor to flush whatever
buffer exists, so that program loaders can be written.
harvard architectures didn't maintain consistency between I & D cache
... and the D-cache could be store-in, not even store-thru. So a
loader implementation required both operation to force altered D-cache to
storage and operation invalidating of any corresponding i-cache lines.
i think there was some post in comp.arch of somebody looking at 165
microcode and they got a 25 percent performance improvement by
separating code & data by 256 bytes (see nick's posting in "pipelining
in the past" in comp.arch on 16may ... a couple before your posts on
17may).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
PowerPC Mainframe
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PowerPC Mainframe
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 24 May 2002 13:25:12 GMT
j.grout@COMPUTER.ORG (John R Grout) writes:
True... but, ever since the days of the 360 Model 91, hasn't
the POP also stated that self-modifying programs must protect
_themselves_ on processors that pre-fetch instructions and/or
cache instructions and data by executing a "serialization"
instruction (the general form being BCR 15,0) between the
modification and execution of recently modified instructions?
Do processors do extra checking out of fear that some programs
don't do this, or are some self-modification scenarios not
covered by this requirement? [along these lines... back in
1997, Seymour Metz stated that scenarios where BCR 15,0 was
required were "few and far between"].
I don't know, but searching ESA/390 POP just now ...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/CONTENTS?SHELF=
i get:
Thus, it is possible for an instruction to modify the next succeeding
instruction in storage.
from 5.13.1 Conceptual Sequence ... see attached.
There are also words said about multiprocessing operations ... where
one processor modifying instruction stream, may or may not be (immediately)
seen by another processor because of instruction pre-fetch.
The exception are test&set & compare&swap stuff which are serialize
the complex (as if you would use these instructions to modify the
i-stream). I did some worked with charlie during the invention of
compare&swap. Two scenarios for compare&swap ... was the selection of
the words were based on coming up with a mnemonic that were charrlie's
initials aka CAS, that got changed by Ron Smith to support the forms
CS & CDS. The other thing that Ron Smith (Padegs & Ron Smith owned the
370 "red book" ... this was a document written in CMS script with
conditionals, printed one way it resulted in the 370 POP w/o all the
370 architecture manual sections ... and printed the other way, it was
the full 370 architecture manual ... which was distributed in a red
3-ring binder) insisted on was the compare&swap programming notes
... aka the claim was that there wasn't sufficient justification for
an MP-specific new instrucation so the group had to come up with a set
of specifications showing the use of compare&swap applicable to single
processor environment ... thus was born the whole stuff about atomic
updating of link-lists and other stuff for interruptable (possibly
application-space) multi-threaded operation in single processor
operation.
The original posting referenced some other postings in the thread made
in comp.arch ... one claiming that after investigation of the 165
microcode ... there was a recommendation of creating 256-byte pad
between instruction & data which resulted in 25 percent performance
increase (aka a quick, inexpensive check if current store operand
address is within 256bytes of current instruction address ... and then
move expensive checking if it was).
==============================================================
ESA/390 POP
5.13.1 Conceptual Sequence
In the real mode, primary-space mode, or secondary-space mode, the
CPU conceptually processes instructions one at a time, with the
execution of one instruction preceding the execution of the
following instruction. The execution of the instruction designated
by a successful branch follows the execution of the branch.
Similarly, an interruption takes place between instructions or, for
interruptible instructions, between units of operation of such
instructions.
The sequence of events implied by the processing just described is
sometimes called the conceptual sequence.
Each operation of instruction execution appears to the program itself
to be performed sequentially, with the current instruction being
fetched after the preceding operation is completed and before the
execution of the current operation is begun. This appearance is
maintained even though the storage- implementation characteristics and
overlap of instruction execution with storage accessing may cause
actual processing to be different. The results generated are those
that would have been obtained had the operations been performed in the
conceptual sequence. Thus, it is possible for an instruction to modify
the next succeeding instruction in storage.
Operations in the access-register mode or home-space mode are the same
as in the other translation modes, with one exception: an instruction
that is a store-type operand of a preceding instruction may appear to
be fetched before the store occurs. Thus, it is not assured that an
instruction can modify the succeeding instructions. This exception
applies if either the storing instruction or the instruction stored is
executed in the access-register or home-space mode.
Regardless of the translation mode, there are two other cases in which
the copies of prefetched instructions are not necessarily discarded:
(1) when the fetch and the store are done by means of different
effective addresses that map to the same real address, and (2) when
the store is caused by the execution of a vector-facility
instruction. The case involving different effective addresses is
described in more detail in "Interlocks for Virtual-Storage
References" in topic 5.13.4.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Why did OSI fail compared with TCP-IP?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did OSI fail compared with TCP-IP?
Newsgroups: comp.arch,comp.protocols.iso,comp.protocols.tcp-ip,comp.lang.c++
Date: Fri, 24 May 2002 13:44:23 GMT
Brian Inglis writes:
There was the party line, as stated above, which was rigidly
enforced, and then there was the reality, which had users on
(skunk) VM/CMS systems doing a lot of interactive and networking
stuff, like HONE and VNET internally.
and VNET had the equivalent of a gateway in every node. The MVS
networking in JES2 was more traditional ... being a traditional
homogeneous design ... more like the original arpanet NCP-based
networking (both vnet & jes2 were host-to-host designs like
arpanet/ncp ... but w/o the IMP FEPs). however this resulted in a
large number of complications trying to integrate MVS/JES2 systems
into the internal network ... which tended to be at end-nodes
only. One of the early experiences was that the homogenity of JES2 was
so ingrained that a message from one JES2 at one release level that
slight header changes would cause a JES2 at another release level to
crash (which in turn brought down the whole MVS system). There is the
case of a Hursley MVS/JES2 system sending messages to a San Jose
MVS/JES2 system and causing it to crash. As a result, not only were
MVS/JES2 systems relegated to end-nodes, but the (intermediate-node)
VNET node that a directly connected MVS/JES2 ... not only had gateway
code for doing JES2 header rewrites ... but also made sure that the
JES2 header rewrite code matched the version of the connected
MVS/JES2. There were even cases where a simple two-node MVS/JES2
network would have an intermediate VNET node between them that would
supply the necessary JES2 header rewrite rules when necessary
(i.e. when one JES2 system was upgraded but not syncronized with the
other JES2 system upgrade).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
System/360 shortcuts
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/360 shortcuts
Newsgroups: alt.folklore.computers
Date: Fri, 24 May 2002 13:58:40 GMT
"George R. Gonzalez" writes:
I vaguely recall some glossy IBM document of long ago that explained how
some advanced 360 model did some on-the-fly loop optimization. O'course
this was decades ago, before $39 Pentiums did all kinds of shortcuts.
Does anybody recall exactly what the 360's could do, and did it really help
in a typical program?
(I know, I'm suggesting that a glossy IBM document would be telling a tad
less than the whole truth-- must be my suspicious alter-ego).
see "Pipelining in the past" thread in comp.arch along with the
recently posted reference in the "PowerPC Mainframe" thread
cross-posted to this n.g. from ibm-main newsgraoup. basically 91 & 195
.. including imprecise interrupts because of concurrent execution of
multiple instructions (standard 360s had precise interrupts).
The issue was a 63 instruction pipeline/cache and a branch instruction
would stall/drain the pipelining ... unless the branch was to an
instruction already in the pipeline.
misc. post posts:
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/94.html#39 IBM 370/195
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/95.html#11 801 & power/pc
http://www.garlic.com/~lynn/96.html#24 old manuals
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/99.html#209 Core (word usage) was anti-equipment etc
http://www.garlic.com/~lynn/2000.html#72 Difference between NCP and TCP/IP protocols
http://www.garlic.com/~lynn/2000b.html#1 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#15 How many Megaflops and when?
http://www.garlic.com/~lynn/2000c.html#23 optimal cpu : mem <-> 9:2 ?
http://www.garlic.com/~lynn/2000d.html#2 IBM's "ASCI White" and "Big Blue" architecture?
http://www.garlic.com/~lynn/2000f.html#21 OT?
http://www.garlic.com/~lynn/2000f.html#27 OT?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#0 First video terminal?
http://www.garlic.com/~lynn/2001.html#39 Life as a programmer--1960, 1965?
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#11 Review of the Intel C/C++ compiler for Windows
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#42 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#27 Massive windows waisting time (was Re: StarOffice for free)
http://www.garlic.com/~lynn/2001h.html#22 Intel's new GBE card?
http://www.garlic.com/~lynn/2001h.html#49 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001l.html#34 Processor Modes
http://www.garlic.com/~lynn/2001l.html#42 is this correct ? OS/360 became MVS and MVS >> OS/390
http://www.garlic.com/~lynn/2001n.html#2 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#41 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2001n.html#86 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002.html#50 Microcode?
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002h.html#19 PowerPC Mainframe?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
PowerPC Mainframe
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PowerPC Mainframe
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 24 May 2002 14:42:32 GMT
Anne & Lynn Wheeler writes:
an MP-specific new instrucation so the group had to come up with a set
of specifications showing the use of compare&swap applicable to single
processor environment ... thus was born the whole stuff about atomic
updating of link-lists and other stuff for interruptable (possibly
application-space) multi-threaded operation in single processor
operation.
random refs:
http://www.garlic.com/~lynn/subtopic.html#smp Multiprocessor, tightly-coupled, SMP & compare&swap
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Coulda, Woulda, Shoudda moments?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coulda, Woulda, Shoudda moments?
Newsgroups: alt.folklore.computers
Date: Fri, 24 May 2002 17:38:48 GMT
spam+@orion-com.com (Joe Thompson) writes:
From what I remember from the early 90s, Excel was actually a latecomer to
the MS stable, being actually (in its first version) a spreadsheet called
Wingz that MS bought and slapped an MS logo on. There was the spreadsheet
in MS-Works but I don't know which derived what from where or if they were
two entirely separate projects at the time.
If my memory serves, Access was also a product bought and renamed and then
released essentially unchanged as Access. -- Joe
I remember lotus & multiplan on dos/windows ... and wingz on unix platforms ...
i don't believe wingz became excel.
doing some quick search engine:
http://www.wingz-us.com/wingz/news/linux.html
http://www.faqs.org/faqs/spreadsheets/faq/
I didn't find any refs: to derivation of excel ... but
the following site lists Oct87 for excel
http://www.tcs.uni.wroc.pl/~jja/ASK/HISZCOMP.HTM
misc. other stuff
http://www.bricklin.com/firstspreadsheetquestion.htm
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Future architecture
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Future architecture
Newsgroups: comp.arch,comp.sys.super
Date: Fri, 24 May 2002 18:32:48 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
One example of that is in serious signal handling and error recovery
and another is in serious asynchronous I/O (in both cases, ignore
the current jokes). Forcing the parallel operations into a serial
model can make the communication problems MUCH worse!
there is some story about some group at CMU attempting to do an SNA
LU6.2 implementation on top of unix TCP/IP ... and it supposedly
turned out to be extrodinarily difficult ... partially LU6.2 is
half-duplex (serialized).
there is also story of some mainframe cluster project in the early
days of 3088/trotter with eight concurrent mainframes ... where the
syncronization primitive started out multicast ... and achieved
consistency in subsecond time. they then were asked to remap to LU6.2
and it took upwards of a minute to achieve the same state consistency.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Why are Mainframe Computers really still in use at all?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Mainframe Computers really still in use at all?
Newsgroups: alt.folklore.computers
Date: Sat, 25 May 2002 18:57:21 GMT
"Rupert Pigott" <dark.try-eating-this.b00ng@btinternet.com> writes:
Depends on the economist/pundit/spin doctor you're listening
to. Fact of the matter is the finance institutions smelt
trouble 4 years ago. I know, I was working inside one. :)
there was hedge fund crises ... partially because a lot of the hedge
stuff is based on continuous ... and real life can have a lot of
discontinuity and/or chaos.
misc. hedge fund posts.
http://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
http://www.garlic.com/~lynn/2001l.html#56 hammer
http://www.garlic.com/~lynn/2001l.html#58 hammer
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
there is also englightenment ... you have all the information but it
takes some time before you can piece it together ... see discussion of
ARMS and the englightenment that occured in 1989:
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
from the above:
Prior to 1989, institutions aggregated their assets and liabilities
into generalized pools. Not much attention was paid to transaction
level detail. The most common product and generalized pools were
Adjustable Rate Mortgages (ARMS). Everyone assumed that an ARM was an
ARM was an ARM. Not so when you consider there are hundreds, perhaps
thousands of different ARM products all booked at various times with
different coupons and varying teaser rates. All behaving in completely
unpredictable, uncorrelated fashion depending on a specific interest
rate scenario. To magnify the problem imagine a situation where the
analysis superimposes instrument credit risk valuations along with
interest rate risk valuations of the ARM as part of the analysis to
fully dimension the transactional and overall institutional risk
profile. Each individual ARM behaves differently in a particular
interest rate scenario relative to its interest rate risk component
and credit risk. A risk manager must also calculate the credit risk
profile of each ARM along a particular interest rate curve for a
complete valuation process to be accurate. Hence each dimension of
risk management is calculated in the risk measurement valuation
process. When institutions began to create financial models measuring
the entire individual transaction level detail of their portfolios
they discovered the gapping error. No one could predict a) the
multitude of embedded options that were going unmeasured across an
organizations entire balance sheet, b) the individual portfolio
behavioral characteristics of these embedded options, c) the
unmeasured aggregate earnings impact of these options across a
multitude of interest rate scenarios. In one example, Citicorp failed
to recognize that a 2% rising rate phase would cause an 80% loss of
core holding company earnings. If the cycle was to occur for an
extended period Citicorp would fail. This discovery caused Citicorp to
get out of the mortgage business in 1989. At the time the company was
the largest player in the mortgage market. Coincidentally, Citicorp's
stock traded at an all time low of $ 6.00/share and needed a private
bailout to continue functioning as an entity. Board and senior execs
have learned to take risk management very seriously. In an Internet
centric business model what is the proper assessment and valuation of
information security risk? How does this component of risk management
integrate with other factors like interest rate risk and credit risk?
In general what is the nature of information security risk? How is it
measured? How does one develop strategies to manage this risk?
Finally, how do I manage this risk?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
backup hard drive
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: backup hard drive
Newsgroups: alt.folklore.computers
Date: Sat, 25 May 2002 22:50:27 GMT
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
Never met one. Haven't been in a machine room with big iron
since '93.
dates from article on thin-film heads:
http://researchweb.watson.ibm.com/journal/rd/403/chiu.html
ga (general availability) for
3380 was 1981 ... 630mbytes
3380E was 1985 double density 1260mbytes
3380K was 1987 triple density 1890mbytes
also see:
http://web.utk.edu/~mnewman/ibmguide13.html
3380 hda description:
http://www.classiccmp.org/mail-archive/classiccmp/2001-03/1089.html
http://www.classiccmp.org/mail-archive/classiccmp/1998-07/0872.html
also see 360/370 timeline at (processor, software, disk, etc dates)
http://www.isham-research.com/chrono.html
another early timeline
http://www.cs.clemson.edu/~mark/acs_timeline.html
misc. other info from
http://www.cmg.org/conference/refs2001/papers/01p6001.pdf
from above paper
Table 1: IBM Physical Disk Geometry and Performance [6]
Average Average Volume
Device Type Seek Latency Capacity
msec msec MB
2314 60 12.50 29.2
3330-1 30 8.33 100.0
3330-11 30 8.33 200.0
3350 25 8.33 317.5
3380A 16 8.33 630.2
3380D 15 8.33 630.2
3380E 17 8.33 1260.4
3380J 12 8.33 630.2
3380K 16 8.3 1890.6
3390-1 9.5 7.10 946.0
3390-2 12.5 7.10 1892.1
3390-3 15 7.10 2838.1
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Computers in Science Fiction
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Sun, 26 May 2002 18:41:34 GMT
"Rupert Pigott" <dark.try-eating-this.b00ng@btinternet.com> writes:
I hate "losing" or "modifying" original data. Massaging figures amounts to
fraud in the strictest terms IMHO. Of course, this hardline attitude of mine
frequently gets me into trouble.
It's a sad state of affairs when being honest it gets you into trouble
because people are expecting you to lie...
misc. refs to data backed up in triplicate:
http://www.garlic.com/~lynn/2000.html#43 Historically important UNIX or computer things.....
http://www.garlic.com/~lynn/2001b.html#76 Disks size growing while disk count shrinking = bad performance
basically one of the operators would periodically pull random tapes
from the library and re-assign them as scratch. in one case I lost
files that somebody came looking for in support of some IP litigation
... and they were gone.
when i use to do "system build" tapes ... new kernel ... the standard
process was to just put a copy of the kernel build on the tape. I
extended the procedure to include all the stuff to build the kernel as
well as the tools needed to build the kernel (starting in cp/67 days).
Some of those tapes survived ... and I was able to supply Melinda with
some of the source to early tools:
http://www.princeton.edu/~melinda/
concerned about deep replication, one of the reasons that I write a
tape backup/archive system for SJR that was also used at HONE. Version
2 was done at SJR by me and another person; effectively version 3 was
redone again at SJR/ARC and saw product life as workstation datasave
facility (WDSF); and version 4 was a combined project between ARC (SJR
moved up the hill to the new complex) adstar (newer name for GPD disk
& file divison) as ADSM (aka adstar distributed storage manager).
I instigated similar stuff for email processing.
http://www.its.queensu.ca/pubs/netnote/gen02_1.html
simple from the above:
The centralized backup software called Workstation DataSave Facility
(WDSF) is now called "AdStar(TM) Distributed Storage Manager (ADSM)"
[ADSTAR(TM) Distributed Storage Manager is a copyright product of IBM
Canada Limited and is distributed under license by Queens University
Computing and Communications Services].
ADSM is now product of Tivoli.
random refs:
http://www.garlic.com/~lynn/2001n.html#66 Holy Satanism! Re: Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2002e.html#3 IBM's "old" boss speaks (was "new")
http://www.garlic.com/~lynn/2002e.html#10 Deleting files and emails at Arthur Andersen and Enron
we use to work pretty closely with some people in austin before they
left to form Tivoli ... which then went thru several iterations and
eventually were bought.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Multics hardware (was Re: "Soul of a New Machine" Computer?)
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics hardware (was Re: "Soul of a New Machine" Computer?)
Newsgroups: alt.folklore.computers,alt.os.multics
Date: Sun, 26 May 2002 21:21:46 GMT
"Robert A. Matern" writes:
That's pretty early for a cutoff. ENWGS (CSC/U.S.Navy) used Multics
until 1996, writing updates to our application right up to the last
year. The last major upgrade was written around 1992. To be fair, we
were one of the last sites...
then there is dockmaster ... seeing email in various standards bodies
up thru 1998 ... and all this stuff about dockmaster-2 (supposedly a
DG something? ... tie-in to soul thread). I was at 21st NISSC in fall
of 98 (I was speaker on PKI panel) ... and nissc email still said
dockmaster.
this says final shutdown 3/31/98:
http://www.multicians.org/mgd.html#DOCKMASTER
at least up thru oct of 98 (nissc '21) ... dockmaster.ncsc.mil was
being used interchangeable with dockmaster2.ncsc.mil.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Computers in Science Fiction
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Sun, 26 May 2002 21:35:41 GMT
"Rupert Pigott" <dark.try-eating-this.b00ng@btinternet.com> writes:
I hate "losing" or "modifying" original data. Massaging figures amounts to
fraud in the strictest terms IMHO. Of course, this hardline attitude of mine
frequently gets me into trouble.
It's a sad state of affairs when being honest it gets you into trouble
because people are expecting you to lie...
one of the things we have been working on is digital signed
transactions ... including ACH and addenda records ... making it
harder to fiddle the original information.
one the other hand ... some of this stuff just gets fiddled for one
reason or another. we worked with this little client/server startup in
silicon valley on being able to perform financial transactions (credit
card stuff). it turned out to eventually be pretty succesful:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 Assurance, e-commerce, and some x9.59
http://www.garlic.com/~lynn/2001i.html#52 loosely-coupled, sysplex, cluster, e-commerce
now as part of the effort in addition to selling the product ... they
also used it in their own online store. they were initially thot all
the stuff just happened automagically ... but the online store
eventually grew into one of the larger staffed organizations. there
turned out to be all sorts of things that had to be fiddled with
manually.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Computers in Science Fiction
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Sun, 26 May 2002 21:38:54 GMT
Anne & Lynn Wheeler writes:
I instigated similar stuff for email processing.
slightly related post
http://www.garlic.com/~lynn/2002e.html#10 Deleting files and email at Arthur Andersen and Enron
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
The multiverse is out there !
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The multiverse is out there !
Newsgroups: rec.arts.sf.science,rec.arts.sf.written,alt.folklore.computers
Date: Sun, 26 May 2002 23:27:57 GMT
lmh@TheWorld.com (Larry M Headlund) writes:
Consider a shorter example of your objection, a single short line of a
poem or even better a single word like "positron" or aluminum. It is
not unreasonable that a number representing that word in a mapping of
your choice was actually written down or used prior to the word being
coined. Is this also nonsense?
Pick a short word of recent coinage, say "NAFTA", and you can probably find
its mapping in a book of random numbers published prior to its first
use. What does this imply for your objection?
there has been some amount of work done on fractal compression/representation,
given sufficiently large computing resournces almost anything can be
represented by the appropriate fractal. random refs pulled up from
search engine (most image related, but there has been work on straight data):
http://links.uwaterloo.ca/
http://citeseer.nj.nec.com/raouf96fractal.html
http://links.uwaterloo.ca/fractals.papers.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Computers in Science Fiction
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Mon, 27 May 2002 14:15:38 GMT
jmfbahciv writes:
YES!!! That was my number one goal when I began to work on
designing our in-house tape building processes. I wanted
the customer to be able to build from scratch. A side effect
of insisting we do this for every tape we made ensured that
WE did not lose sources or the knowledge of how to make the
product.
CP/67 distribution tapes from the start always had full binary and
full source ... so that customer could rebuild from source if necessary.
CSC (4th floor, 545 tech sq) had 1) the machine room (actually located
on the 2nd floor), 2) the cp67/cms group and 3) all the rest. The
machine room ran time-sharing service ... primarily in-house in
support of the people on the 4th floor ... but the cp67/cms group also
could build new systems and test ... besides the production system.
The machine room, at various times supported other people along the
way ... typically some number of MIT students ... and for awhile
before they got their own machine, the corporate business planning &
forcasting people down in armonk hdqtrs running APL models with much
of the corporate (really, really sensitive) business data.
A new system build for the machine room might be a couple times a
month to a couple times a week. The machine room production build was
done directly to disk but also written simultaneously to tape (as
backup). The tapes were used primarily to "fall-back" to previous
system if something was discovered about current build (or even
previous couple builds). They originally were just the kernel image
alone. I expanded the production process (as opposed to the customer
distribution process) to include everything necessary to rebuild the
kernel from scratch (including the kernel source as well as the kernel
build procedures). This was possibly pathelogical overkill ... but
every once in awhile in came in useful.
The production system also collected activity numbers ... typically
every five minutes ... total system activity, number of users,
individual user activity, etc. These were written to disk in
real-time, but the files were accumulated to tape. Cambridge kept this
information starting possibly in 66. By 1976, there was possibly 10
years of production system "performance" data spanning a couple
machine upgrades, numerous system changes, etc (various cp/67 releases
on 360/67 uniprocessor, 360/67 multiprocessor, various vm/370 releases
starting on 370/155, etc).
By the mid-70s, standard new VM/370 release went out to customers
every six month or so ... and there were monthly maint. tapes called
PLC (or program level change) that went out every month. There might
be a couple concurrent releases in the field support
... i.e. customers talked about Release 3PLC15 ... aka 15th monthly
update after the start of Release 3. The product group had split off
from CSC in the late CP/67 time-frame ... before actual start of port
to VM/370. By the mid-70s, the VM/370 group had outgrown any space in
the tech sq. building and had moved out to an (old/previous) SBC
building in burlington mall (as part of some legal deal, SBC had been
sold off to CDC, i.e. out of the service bureau business).
When I (re-)did the resource manager for vm/370 (for direct customer
ship) ... I did this initial (mostly automated) benchmarking thing of
2000 some odd benchmarks that took three month elapsed time to
run. This was for initial performance validation/calibration.
Everytime that I released a subsequent PLC tape ... I would rerun 100
or so of the benchmarks (taking a full weekend) ... my PLC tapes only
came out every three months ... in part because I had to do much of
the work myself ... and in part because I always did stress testing as
well as performance regression testing for everything that shipped (as
well as comparing it to full history of previous runs). The base
product only had a small performance regression for full releases
... but not for the monthly builds. Also the base product didn't
maintain a full history off all performance benchmarks across all
releases for comparison.
misc. past postings
http://www.garlic.com/~lynn/subtopic.html#technology
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Computers in Science Fiction
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Mon, 27 May 2002 16:28:21 GMT
Brian Inglis writes:
>:Am i dreaming/senile or do I remember there being a
>:"DDR BACKUP NUC[leus]" command to save the kernel image on
>:VM/SP/HPO?
original kernel build was just writing an image of the "card" binaries
to tape ... and ipl the tape to (re)build the kernel (of course it had
been a long time since real cards were used ... cp/67 supporting
"virtual" cards in the spool). the original procedure just wrote the
couple thousand card images to a single/first tape file. the "loader"
at the front ... worked equally well reading from 2540 card reader
(real or virtual) or tape. The last thing that was done after the
loader had placed everything appropriately in memory was "savenuc" was
invoked which wrote a core image to disk with a little glue for
"loadnuc". loadnuc was small program that got invoked when booting the
disk ... and knew how to reload the kernal image from disk back into
memory.
I then would dump cms file image (originally using tape ... but later
using vmfplc) of base source & binary files to the 2nd file, followed
by all the local source changes & binary files to the 3rd tape file,
followed by all the tools used for the build. since these were stored
on different cms filesystems ... it just amounted to writing to tape
everything in that particular cms file system.
ddr was a disk image copy to tape ... DDR dump of the nucleus disk
area was picking up all the kernel image off of disk and writting it
to tape. The issue was whether a "card" image of DDR had first been
written as the first file on the tape ... with the DDR "nuc" version
as the 2nd file on tape. restore would mean that DDR was booted from
tape (or card image) and then operator interacted with DDR to specify
restore of the "Nuc" image back to disk.
the kernel card image was the binary "card" image output from the
compilers which could be booted and would write image to disk in
single operation. the DDR image ... required first booting DDR and
then telling DDR to restore disk image to idsk.
"tape" was the original cms command from the 60s which read/wrote to
tape with 800 byte record blocking. vmfplc was essentially tape using
4k byte record blocking. a lot of the source distribution was small
files (4k bytes or less) ... which represented the individual change
files. after some months of change ... any particular source module
would have the original source and possible 10-15 individual
incremental change files. For the full system there could be a couple
thousand of these change files. vmfplc took a lot less tape than tape.
however, for the original archive/backup system i did
http://www.garlic.com/~lynn/2002h.html#29 Computers in Science Fiction
i further modified vmfplc into something called vmxplc. vmfplc would
first write a 64-byte record containing the file descriptor
information followed by 1-n 4k byte records containing the file data.
for 1 record data files ... on a 6250 bpi tape ... there were two
interrecord gaps ... which was almost as much tape for interrecord
gaps as there were for data. I merged the 64-byte file descriptor
record into the same physical block as the first data tape record. I
would also block up to four 4k physical blocks into single tape
record. For large files the larger physical blocking could save 15-20
percent tape ... but for small files ... it doubled the amount of data
on tape (using vmxplc compared to vmfplc).
> In VM/SP/HPO days there were PUT tapes that came out
> monthly-quarterly depending on volume, still using VMFPLC2
> format: not sure if there were binaries for source supported
> modules.
>
> Always remember the fun of waiting to see if one of my APAR fixes
> would be released officially and trying to figure out how they
> came up with the PTF code distributed (presumably after changing
> PL/S source and recompiling to get the assembler sources
> distributed to customers).
note that CP/67 and VM/370/SP/HPO etc were all assembler source, with
binaries and source distributed (60s & 70s). It wasn't until vm/xa
(i.e. 3081 31-bit support, etc) that things started getting into PL/S
source.
as an aside, the one thing that the card image kernel loading did
... was that it recreated the module loadmap each time it was booted
... as well as the comment cards. each compiled binary "card" image
for each compiled module had "comments" giving the data/time of what
went into the compile of the module ... base source filename with
date/time, all the incremental update source file names with
date/time, etc. The resulting loadmap had the full original source
file history for each module (in comments) along with the module
storage locations. None of this was available with DDR since it was
just read/writing disk image records.
I've told this before ... but in the mid-80s, I was in madrid visiting
the science center. They were working with the gov. on project to
digitize as many documents as possible related to the uncoming 500th
anniversary of columbus and the americas. While I was there, I went to
movie theater. Along with the main feature they also had a 15-20
minute drama "short" made at the university. I forget the plot but a
major set was this 2nd floor apartment that had a floor to ceiling
wall of television sets. All of the screns were slaved to computer
monitor display that had continuous scroll of text (looked like about
1200 baud glass teletype). After awhile I realized that it was
repeatedly scrolling a vm/370 loadmap ... what is worse I could tell
the release and PLC level from the incremental source filenames in the
loadmap. The standard incremental source file name would include any
related PTF number and if you worked with the system a lot ... you
tended to know what PTFs appeared in which PLC/PUT.
As an aside ... as part of the system debugger that I wrote for VM ...
I also modified the kernel "savenuc" program. The "loader" program in
front of the card deck ... that turned compiled binaries into core
image (wrote the loadmap, etc) was a slightly modified "BPS" 370
loader from the early 60s. When it was all done, it passed control to
the appropriate entry in the loaded program (aka savenuc). The savenuc
program was the last module mapped into memory ... it would then
proceed to write everything, including itself to disk. Now it turns
out that the BPS loader (besides writing the loadmap to printer) also
passed to the first module a pointer to its internal loader tables
(the ESID enttries, name & location) in registers. The kernel had all
the appropriate connections made ... but the standard kernel didn't
have a symbolic table of those entries. The modification that I made
to savenuc was to copy into the kernel memory image the loader table
before writing the image to disk. That way I was able to add the raw
ESID entries and locations to kernel image ... for any later debugging
purposes.
misc. debugging posts:
http://www.garlic.com/~lynn/94.html#11 REXX
http://www.garlic.com/~lynn/2000b.html#32 20th March 2000
http://www.garlic.com/~lynn/2000b.html#33 20th March 2000
http://www.garlic.com/~lynn/2001c.html#0 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2002g.html#27 Security Issues of using Internet Banking
misc. posts on ESID entries
http://www.garlic.com/~lynn/2001.html#8 finding object decks with multiple entry points
http://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)
misc. madrid posts
http://www.garlic.com/~lynn/99.html#9 IBM S/360
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2000.html#14 Computer of the century
http://www.garlic.com/~lynn/2000g.html#36 stupid user stories
http://www.garlic.com/~lynn/2001e.html#66 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
http://www.garlic.com/~lynn/2001l.html#54 mainframe question
http://www.garlic.com/~lynn/2001n.html#16 Movies with source code (was Re: Movies with DEC minis)
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Computers in Science Fiction
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Mon, 27 May 2002 19:32:38 GMT
Anne & Lynn Wheeler writes:
"tape" was the original cms command from the 60s which read/wrote to
tape with 800 byte record blocking. vmfplc was essentially tape using
4k byte record blocking. a lot of the source distribution was small
files (4k bytes or less) ... which represented the individual change
files. after some months of change ... any particular source module
would have the original source and possible 10-15 individual
incremental change files. For the full system there could be a couple
thousand of these change files. vmfplc took a lot less tape than tape.
the method "tape" used to read/write files (and similarly vmfplc) is
similar to the way that DISK read/writes files. description of DISK
http://www.garlic.com/~lynn/2002h.html#1 DISK PL/I Program
http://www.garlic.com/~lynn/2002h.html#2 DISK PL/I Program
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Computers in Science Fiction
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Tue, 28 May 2002 12:37:25 GMT
Brian Inglis writes:
Thanks again -- that was useful on a number of occasions, despite
IPCS!
ipcs had something like 20k assembler instructions and had a group
of 5-10 people supporting it. back in the early days when rex was
still rex
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
i wanted to demonstrate that rex was not just another shell language
but could be used for serious programming. I made the claim that I
could rewrite ipcs in rex in half time over a 3 month period and it
would have ten times the function and run ten times faster. "dumprx"
was the result and it had 10 times the function and ran 10 times
faster ... at least for the equivalent functions ... there were (new)
debugging scripts that ran thru dump images making the most common
storage consistency checks automatically looking at all the major
control blocks and checking for things that looked out of the ordinary
... that took a little time.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
The 64-bit landscape in 2005
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 64-bit landscape in 2005
Newsgroups: comp.arch
Date: Tue, 28 May 2002 13:03:42 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Never forget marketing. I thought that about the original IBM PC
on the grounds of its technical uselessness :-(
i was at dinners with some of the mac developers early in the mac
development cycle where I argued that IBM PC was going to be success
because it was going to provide a business terminal, a single keyboard
and display on the desk that could do both mainframe terminal
connection and some other local computing (eventually lotus).
effectively the mac guys were claiming that they would never allow mac
to be used anywhere but the kitchen table and never for any useful
business purpose.
IBM PCs and IBM 3270s were in the same price range ... and the single
keyboard/display on the desk got to be a very powerful argument.
there was an internal period that "terminals" on individuals desks
required VP approval. we put together a case that 3-year amortized
terminal cost was less than monthly business telephone cost (and it
was taken for granted that employees got phones on their desks w/o vp
approval). At some point, PCs on the desk (in place of a terminal)
became a general business status symbol ... even for people that never
used it in any kind of "local" mode.
originally there was a lengthy waiting period on the employee PC
purchase plan. i remember picking up my first PC on the day that the
external price was dropped to less than what i had signed up to pay on
the employee purchase plan.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Oh, here's an interesting paper
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oh, here's an interesting paper.....
Newsgroups: comp.dcom.modems.cable,comp.security.firewalls
Date: Tue, 28 May 2002 13:41:10 GMT
Cichlidiot writes:
The large majority of computer users that are contributing to the problem
would not be able to find their way around a command line if their lives
depended on it. This is the crux of the problem. There are people who only
know how to use the GUI, who depend on CompUSA to do everything for them,
who would scream in horror at the thought of doing a Linux install, etc.
This is the "Average Joe"... the one who took 10 years to figure out how
to program his VCR... the one who only knows how to point and click.
another area of consumer device requiring security has been
automobiles ... from technical expertise standpoint has lots of
similarities to computers (how many people rebuild ignitions and locks
in their automobiles to be more secure). lots of joy-ridding is not
treated as serious felony.
over possibly last 20 year period there was some improvement ... in
part because of competition between manufactures ... especially after
some of the foreign imports beame a serious consideration (the
corollary would probably mean basic operating system competition
... since serious security requires support by the basic operating
system). also insurance rates/policies had some role in rating
competing models and adjusting the rates. Insurance possibly plays a
similar role in security devices for homes.
there are possibly only a couple after-market security devices for
automobiles ... with significant market penetration ... and they took
possibly 100 years to show up.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
[survey] Possestional Security
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [survey] Possestional Security
Newsgroups: sci.crypt
Date: Tue, 28 May 2002 20:24:17 GMT
Gus writes:
shrug. So I have to pick your pocket, or burgle your house to get it. It
does go on. Ok, thats a bit spook stuff for most, but since having the
extra layer of a 6-digit PIN with a "3 incorrect tries and I blow
irrevocably" mechanism on the smartcard is very easy to build in and (most
importantly) very easy to operate day-to-day, while adding tremendously to
the overall security of the system it is almost a no-brainer as to wether
to include it.
there are (at least) two kinds of hardware tokens out there ... the
infrasructure shared-secret based ... that you can attack one token
... even to destruction to extract the infrastructure shared-secret
... and then use in conjunction with other devices. some of these were
created with shared-secret "in-waiting" already loaded into the device
... on the off-chance somebody did an exhaustive search of the current
shared-secret ... then they could somehow propagate a signal to all
devices to upgrade to the shared-secret in-waiting ... w/o having to
re-issue all new toakes.
the non-shared-secret ... might have a unqiue secret per device or
support public/private key operation (one way or another, a unique key
per token). such systems are more considered to have
no-single-point-of-failure ... aka attacks on one token yields no
fraudulent capability in conjunction with any other token.
given approximately the same level of hardware technology for the two
types of tokens ... it can be obvious that attacks on infrastructures
with shared-secrets yield higher return on investment compared to
attacking the same kind of hardware token that is part of an
infrastructure that has no global secrets.
given a financial account scenario with the token used for
authenticating transaction ... and a non-shared-secret implementation;
if a hardware token was acquired ... could anything be done with the
token before the token is reported lost/stolen ... where most attacks
result in zeroization of the chip.
scenario currently with magstripe (both with & w/o PIN requirements)
is that it is possible to harvest magstripe information and create
counterfeit transactions. the purpose of the chip technology is to
significantly increase the difficulty of counterfeiting transaction
(say compared to currently being able to copy a magstripe from one
card to another).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Biometric authentication for intranet websites?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric authentication for intranet websites?
Newsgroups: comp.security.misc,comp.security
Date: Wed, 29 May 2002 14:17:49 GMT
Bernd Eckenfels <ecki-news2002-05@lina.inka.de> writes:
Be aware that in recent tests again all biometric systems failed misserably.
IT should never be used in a 2-factor authentication. Always add another one
like something you know.
somewhere earlier in the thread there was mention of an environment
where people write there PIN numbers on the card and also leave their
fingerprints on the card.
so from a fraud standpoint (given that environment) is it easier for an
attacker to
1) read the PIN number off the card and enter the PIN number (read from
the card) into a PIN pad
or
2) extract the fingerprint from the card and create some fraudulent
fingerprint entry
for both #1 and #2, a) what is the skill level required to read a pin
number vis-a-vis lift a fingerprint and b) what is the elapsed time it
takes to fraudulently enter a pin number vis-a-vis create a fraudulent
fingerprint and enter it.
miserable can be relative ... how does people leaving their
fingerprint on their card compare to population that writes their pin
number of their card ... and the relative ease & technology needed to
exploit either.
misc ... see 2-factor and 3-factor authentication defs in
http://www.garlic.com/~lynn/secure.htm
random bio refs:
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio1 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio2 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio4 Fingerprints (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio8 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aepay10.htm#5 I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aepay10.htm#15 META Report: Smart Moves With Smart Cards
http://www.garlic.com/~lynn/aepay10.htm#20 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002e.html#38 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002f.html#32 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002g.html#56 Siemens ID Device SDK (fingerprint biometrics) ???
http://www.garlic.com/~lynn/2002g.html#72 Biometrics not yet good enough?
http://www.garlic.com/~lynn/2002h.html#6 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#8 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#9 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for intranet websites?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Looking for Software/Documentation for an Opus 32032 Card
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Looking for Software/Documentation for an Opus 32032 Card
Newsgroups: alt.folklore.computers
Date: Sat, 01 Jun 2002 16:08:30 GMT
Steve O'Hara-Smith writes:
Sequent kept Dynix and dropped the 32032 - I met Dynix on a box
with 32 486-DX50s with separate memory on each processor - it was very nearly
32 ATs on a fast interlink bus at the hardware level but from inside it just
seemed like one big system that was better at lots of little jobs than at one
big one. The hoops it must have jumped through to make SYSV shared memory
work cannot have been pretty - but they were transparent and the system
didn't perform at all badly on a complex multi part application that used
a lot of shared memory segments.
sequent then did sci-based interconnect processor complex ... using
same chip that DG used for their similar design. Convex also did a
sci-based interconnect using their own chips and HP processors
(exemplar).
steve chen (remember chen supercomputers and cray) showed up at
sequent for awhile as their CTO ... and my wife and I did some
consulting for him.
from recent soul of new machine thread:
http://www.garlic.com/~lynn/2002g.html#10
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
IBM doing anything for 50th Anniv?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM doing anything for 50th Anniv?
Newsgroups: alt.folklore.computers
Date: Sat, 01 Jun 2002 16:16:40 GMT
Stefan Skoglund writes:
I can name two examples:
KeyKOS (a capability based system from TYMnet - ran tymnets bbs
on standard ibm 360 hw a lot faster than their previous VM
based implementation)
Multics - Ford found out that a multics based CAD system was 50 %
cheaper than the competing UNIX solutions.
gnosis was done by tymshare ... at that time well over 30 percent of
the processor time was updating capability and accounting information
that happened when switching domains. target for gnosis was being
able to allow 3rd party offerings on tymshare service that would produce
revenue stream back to their authors based on direct tymshare customer
use. gnosis had a lot of domain and accounting stuff in order to implement
that function.
after md bought tymshare and spun off gnosis ... a lot of gnosis design
point changed for keykos ... into a transaction oriented system (as
opposed to platform for deliverying 3rd party software). In that sense,
keykos and tpf (transaction processing facility ... current name for
ACP ... airline control program ... in part because some number of
financial institutions use it for transactions in addition to the large
airline res systems) ... are similar design points.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
50 years ago (1952)?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50 years ago (1952)?
Newsgroups: alt.folklore.computers
Date: Sat, 01 Jun 2002 19:02:36 GMT
lwinson@bbs.cpcn.com (lwin) writes:
In the 1960s, govt rumblings encouraged IBM to "unbundle" its hardware
and software. Originally, one got a S/360 with peripherals and software
as a single package. After the changes (about 1969), one could buy
peripherals separately (fueling growth of a huge industry). Also,
software was separated, fueling growth of another industry.
date was june 23rd, 1969 for unbundling
note I was undergraduate on four person project that built first ibm
360 pcm (plug compatible) control unit ... reverse engineered the
channel interface and built channel interface board that went into an
interdata/3.
http://www.garlic.com/~lynn/subtopic.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Future architecture [was Re: Future micro-architecture: ]
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Future architecture [was Re: Future micro-architecture: ]
Newsgroups: comp.arch
Date: Sat, 01 Jun 2002 19:32:44 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Really? Now please analyse Lamport's algorithm in the face of
arbitrary pattterns of contention. I will analyse the behaviour
of compare&swap in preference any day.
somewhat aside charlie came up with CAS working on 360/67 smp
support. the mnemonic CAS was chosen because they were charlie's
initials and then we had to invent the term compare&swap to go with
the intials. the guys that owned the 370 hardware architecture said
that there was insufficient justification to put in a pure SMP
instruction into the hardware ... and what was required as a
justification for the instruction that could be used in non-SMP
environments ... from that was born the description of using atompic
C&S for multi-thread applications ... independent of the number of real
processors (aka concurrent could be processor interrupts and
pre-emption scheduling ... and/or concurrent could mean simultaneous
execution on multiple real processors). The description was orginally
included as programming notes with the instruction in the POP ... but
has since been moved to an appendix.
http://www.garlic.com/~lynn/subtopic.html#smp
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Future architecture
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Future architecture
Newsgroups: comp.arch,comp.sys.super
Date: Sat, 01 Jun 2002 19:20:35 GMT
"Stephen Fuld" writes:
I don't know what you mean by significance, but the Univac 1108A had true
SMP style multiprocessing since the late 1960s. There were many
installations used for a variety of applications ranging from transaction
processing through general purpose to scientific applications.
ibm 360/65 smp ... two processor versions from the 60s. ibm used the
definition to include the ability that the real storage and machine
could be cleaved and operate as two independent processors. They
shared memory but didn't share I/O ... however, in SMP configurations,
large percentage of device configuration used the cluster capability
(device able to connect to multiple different i/o paths) to give
multiple processors i/o access to the same device. In that sense the
straight forward 360 smp had real shared memory ... but the i/o
configuration operate as if it was cluster.
the exception was the 360/67 smp (a modified verion of 65 with
hardware address translation for virtual memory). It had a "channel
director" box ... that preserved the ability to partition the hardware
into multiple inedependent operating units ... but also provided the
ability for each processor to access the i/o channels/bus of all
processors in smp mode.
then there were the large number of modified 360/50s & 360/65s for the
FAA in the mid-60s
the work that charlie did on 360/67 smp resulted in the compare&swap
atomic instruction (the choise of CAS mnemonic was made because they
are charlie's initials, then the words had to be invented to go with
his initials). the "owners" of the 370 architecture said that we
couldn't get it into the 370 machines unless we came up with a non-smp
kernel use for the instruction. That prompted what was originally the
programming notes of the CAS instruction (since moved to the appendix
of the principle of operations) on how to use compare&swap semantics
in multithreaded applications (whether running on real SMP or simple
uniprocessor).
the 370 smp