List of Archived Posts

1999 Newsgroup Postings

Early tcp development?
Early tcp development?
IBM S/360
IBM S/360
IBM S/360
3330 Disk Drives
IBM S/360
IBM S/360
IBM S/360
IBM S/360
Old Computers
Old Computers
Old Computers
Old Computers
Glass Rooms (was Re: drum memory (was: Re: IBM S/360))
Old Computers
Old Computers
Old Computers
Most embarrassing email?
APL/360
Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
BA Solves Y2K (Was: Re: Chinese Solve Y2K)
You count as an old-timer if (was Re: Origin of the phrase
IBM S/360
Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese
IBM S/360
You count as an old-timer if (was Re: origin of the phrase
You count as an old-timer if (was Re: origin of the phrase
Old Computers
Roads as Runways Was: Re: BA Solve
why is there an "@" key?
why is there an "@" key?
why is there an "@" key?
why is there an "@" key?
why is there an "@" key?
Internet and/or ARPANET?
Internet and/or ARPANET?
1968 release of APL\360 wanted
Internet and/or ARPANET?
Internet and/or ARPANET?
Internet and/or ARPANET?
Internet and/or ARPANET?
Internet and/or ARPANET?
[netz] History and vision for the future of Internet - Public Question
A word processor from 1960
Enter fonts (was Re: Unix case-sensitivity: how did it originate?
Enter fonts (was Re: Unix case-sensitivity: how did it originate?
Internet and/or ARPANET?
Internet and/or ARPANET?
Internet and/or ARPANET?
Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Living legends
Internet and/or ARPANET?
Enter fonts (was Re: Unix case-sensitivity: how did it originate?
Internet and/or ARPANET?
Fault Tolerance
Modem history [was ba.b: Re: Gender Gap's Wildest Show!!! Tonight!!!]
Living legends
Living legends
When did IBM go object only
Living legends
Living legends
Living legends
Living legends
System/1 ?
Old naked woman ASCII art
Old naked woman ASCII art
System/1 ?
System/1 ?
The Melissa Virus or War on Microsoft?
System/1 ?
Series/1 as NCP (was: Re: System/1 ?)
High Availabilty on S/390
IBM/computer chronology
The Chronology
Read if over 40 and have Mainframe background
Read if over 40 and have Mainframe background
Mainframes at Universities
Are mainframes relevant ??
Mainframes Relevant?
Authentication in eCommerce applications
Authentication in eCommerce applications
Perfect Code
"Pirates" -- what about Paul Allen?
"Adventure" (early '80s) who wrote it?
"Adventure" (early '80s) who wrote it?
Perfect Code
1401 Wordmark?
1401 Wordmark?
FIne-grained locking
FIne-grained locking
CPU's directly executing HLL's (was Which programming languages)
Documentation query
MVS vs HASP vs JES (was 2821)
MVS vs HASP vs JES (was 2821)
MVS vs HASP vs JES (was 2821)
Early interupts on mainframes
IEFBR14 cookie from www.ibm.com
Power4 = 2 cpu's on die?
Early interupts on mainframes
The Translate (TR) instruction
Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
Future Cryptology
IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
IBM Mainframe Model Numbers--then and now?
Computer History
IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
The Translate (TR) instruction
OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
What is the use of OSI Reference Model?
What is the use of OSI Reference Model?
IBM S/360 microcode (was Re: CPU taxonomy (misunderstood RISC))
OS390 bundling and version numbers -Reply
Schneier/Publsied Algorithms
Computer, supercomputers & related
atomic History
Painting machines (the colour the customer wants)
Computer supersitions [was Re: Speaking of USB ( was Re: ASR 33 Typing Element)]
Speaking of USB ( was Re: ASR 33 Typing Element)
Speaking of USB ( was Re: ASR 33 Typing Element)
Q: S/390 on PowerPC?
Dispute about Internet's origins
Dispute about Internet's origins
Examples of non-relational databases
High Performance PowerPC
early hardware
early hardware
Q: S/390 on PowerPC?
EBCDIC binary Conversion Question
Computer supersitions [was Re: Speaking of USB ( was Re: ASR 33
sysprog shortage - what questions would you ask?
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
Mainframe emulation
Dispute about Internet's origins
OS/360 (and descendents) VM system?
Dispute about Internet's origins
OS/360 (and descendents) VM system?
OS/360 (and descendents) VM system?
OS/360 (and descendents) VM system?
Q: S/390 on PowerPC?
Q: S/390 on PowerPC?
Dispute about Internet's origins
Dispute about Internet's origins
OS/360 (and descendents) VM system?
OS/360 (and descendents) VM system?
Q: S/390 on PowerPC?
Q: S/390 on PowerPC?
Uptime (was Re: Q: S/390 on PowerPC?)
Uptime (was Re: Q: S/390 on PowerPC?)
Are there any really large commercial databases?
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
Uptime (was Re: Q: S/390 on PowerPC?)
Uptime (was Re: Q: S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
OS/360 (and descendents) VM system?
What is "Firmware"
IBM Assembler 101
Uptime (was Re: Q: S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
Crowther (pre-Woods) "Colossal Cave"
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
checks (was S/390 on PowerPC?)
S/360 history
amusing source code comments (was Re: Testing job applicants)
S/360 history
S/360 history
checks (was S/390 on PowerPC?)
S/360 history
The Watsons vs Bill Gates? (PC hardware design)
Merced Processor Support at it again
Clustering systems
Clustering systems
Clustering systems
Clustering systems
Clustering systems
Merced Processor Support at it again
Merced Processor Support at it again
Internet Credit Card Security
Merced Processor Support at it again
Merced Processor Support at it again
offline RFCs (RFC439)
Back to the original mainframe model?
1403 printer on a 1401?
Anti trust suits--IBMs' compared to Microsoft
Anti trust suits--IBMs' compared to Mi
Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
Life-Advancing Work of Timothy Berners-Lee
amusing source code comments (was Re: Testing job applicants)
Life-Advancing Work of Timothy Berners-Lee
Middleware - where did that come from?
Middleware - where did that come from?
Non-blocking synch
Core (word usage) was anti-equipment etc
Life-Advancing Work of Timothy Berners-Lee
Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
Life-Advancing Work of Timothy Berners-Lee
Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
Core (word usage) was anti-equipment etc
AES cyphers leak information like sieves
How did you learn to program?
GEOPLEX
Why is Pascal no longer a leading development Language?
Ask about Certification-less Public Key
Ask about Certification-less Public Key
Ask about Certification-less Public Key
AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
Mainframe acronyms: how do you pronounce them?
Study says buffer overflow is most common security bug
VM History
VM History
Looking for a (working) PERQ
Paradigm Shifted (was: Re: BBSs vs. The Internet)
X9.59/AADS announcement at BAI this week
BBSs vs. The Internet
Attacks on a PKI
Why couldn't others compete against IBM?
Attacks on a PKI
Digital Signature on SmartCards
Radius Help help!!!
Why couldn't others compete against IBM?
Need Unix system call to get the CPU time taken by a thread
Computer of the century
Computer of the century
Attacks on a PKI
Attacks on a PKI
I can't believe this newsgroup still exists
Attacks on a PKI
IBM UC info
Attacks on a PKI

Early tcp development?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Early tcp development?
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,alt.folklore.computers,alt.culture.internet,alt.culture.usenet
Date: 03 Jan 1999 16:15:25 -0800
it is even more interesting using TCP for HTTP transactions ... which (if i remember right) requires for reliable transmission a minimum of 7 packet exchange compared to five packet minimum for VMTP (rfc1045)
http://www.ca.sandia.gov/xtp/
http://web.archive.org/web/20020209014400/http://www.ca.sandia.gov/xtp/

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Early tcp development?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Early tcp development?
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,alt.folklore.computers,alt.culture.internet,alt.culture.usenet
Date: 07 Jan 1999 11:45:07 -0800
also ... while huge images might dominate in terms of bandwidth there is still a significant large number of short HTTP/TCP session. An early issue was the enormous number of dangling FINWAITs ... and design assumptions that since FINWAITs are only associated with long-running activity ... there would never be more than a couple on the list at any time ... and therefor it was acceptable to do a serial searh of the list (some webservers circa '95 were spending 90% of processing running FINWAIT list).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 08 Jan 1999 08:55:26 -0800
I think it was somebody at Princeton that did a port of Unix to 370. There were two people in IBM that tried to hire him when he graduated ... but were not able to get authorization. Amdahl hired him and produced gold (aka Au, amdahl unix) which became UTS.

AT&T & IBM had an effort that had unix running on top a modified TSS/370 kernel.

I believe that the AT&T and Amdhal efforts were pretty much unrelated.

AIX/370 was a Locus port that included AIX/PS2 in the package.

About 85/86, at one of the science centers, IBM had a project to port BSD to 370 ... but part way thru the activity ... the effort got redirected to porting BSD to the IBM PC/RT.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 09 Jan 1999 15:08:10 -0800
current description:


http://ppdbooks.pok.ibm.com:80/cgi-in/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/CCONTENTS

.. specifically
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/13.0
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/14.0
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/15.0
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/16.0
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/17.0

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 10 Jan 1999 09:32:13 -0800
simplex 67 was single ported memory .... the two-processor 67 had a channel controller with dual-ported memory. Heavy load had a "half-duplex" 67 (i.e. single processor with channel controller and dual-ported memory) outperformed simplex 67.

anyway from the alt.folklore.computers and comp.arch archives ...
Subject: Re: Virtual Memory (A return to the past?)
From: lynn@garlic.garlic.com (Anne & Lynn Wheeler)
Date: 1995/09/27
Newsgroups: comp.arch

.. some of you are probably getting tired of seeing this ... but a typical '68 hardware configuration and a typical configuration 15 years later


machine         360/67  3081K
mips            .3      14       47*
pageable pages  105     7000     66*
users           80      320      4*
channels        6       24       4*
drums           12meg   72meg    6*
page I/O        150     600      4*
user I/O        100     300      3*
disk arms       45      32       4*?perform
bytes/arm       29meg   630meg   23*
avg. arm access 60mill  16mill   3.7*
transfer rate   .3meg   3meg     10*
total data      1.2gig  20.1gig  18*

Comparison of 3.1L 67 and HPO 3081k

========================================

360/65 is nominal rated at something over .5mips (reg<->reg slightly under 1mic, reg<->storage start around 1.5mic and go up). running relocate increases 67 memory bus cycle 20% from 750ns to 900ns (with similar decrease in mip rate). 67 was non-cached machine and high I/O rate resulted in heavy memory bus (single-ported) contention with processor.

drums are ibm'ese for fixed head disks.

disk access is avg. seek time plus avg. rotational delay.

the 3.1l software is actually circa late 70 or earlier 71 (late in the hardware life but allowing more mature software). the 3081k software is the vm/hpo direct descendant of the cp/67 system.

90th percentile trivial response for the 67 system was well under a second, the 90th percential trivial response for the 3081k was .11 seconds (well under instantaneous observable threshold for majority of the people).

the page i/o numbers is sustained average under heavy load. actual paging activity at the micro-level shows very bursty behavior with processes generating page-faults at device service intervals during startup and then slowing down to contention rates during normal running. the 3081k system had pre/block page-in support (i.e. more akin to swap-in/swap-out of list of pages rather than having to individually page fault).

big change between 68 and 83 ... which continues today is that processor has gotten much faster than disk tech. has gotten faster. real memory sizes and program sizes have gotten much bigger than disk has gotten faster (programs have gotten 10-20 larger, disk get twice as fast, sequentially page faulting a memmap'ed region 4k bytes at a time takes 5-10 times longer). Also while current PCs are significantly more powerful than mainframe of late '60s and the individual disks are 5-10 times faster, the aggregate I/O thruput of todays PCs tend to be less than the aggregate I/O thruput of the mainframe systems.

In any case, when I started showing this trend in the late '70s that disk relative system performance was declining (i.e. rate of getting better was less than the getting better rate for the rest of the system) nobody believed it. A simple measure was that if everything kept pace, the 3081K system would have been supporting 2000-3000 users instead of 320.

Somewhat bottom line is that even fixed head disks haven't kept up with the relative system performance. Strategy today is whenever possible do data transfers in much bigger chunks than 4k bytes, attempt to come up with asynchronous programming models (analogous to weak memory consistency & out-of-order execution for processor models), and minimize as much as possible individual 4k byte at a time, synchronous page fault activity.

3330 Disk Drives

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.garlic.com (Anne & Lynn Wheeler)
Newsgroups: alt.folklore.computers
Subject: Re: 3330 Disk Drives
Date: 18 Jun 1995 17:10:56 GMT
following from report i originally did in '81 ... part of the numbers were excerpted in postings in this group early last year (archived at
ftp://ftp.netcom.com/pub/ly/lynn). 3330 numbers for 3330-ii. overall
system numbers showed that 3380 technology had a relative decline in system performance by at least a factor of five compared to 2314 relative system performance. also 4k acc/sec/meg declined by more than an order of magnitude (absolute).

Some of the numbers were done in late '70s where it was shown that upgrading from 3330-ii to 3350 only improved performance if allocated data was limited to approx. same as on 3330-ii. The 3380 are the original (single density) 3380.


		2305	2314	3310	3330	3350	3370	3380

data
cap, mb		11.2	29	64	200	317	285	630
avg. arm
acc, ms		0	60	27	30	25	20	16
avg. rot
del. ms		5	12.5	9.6	8.4	8.4	10.1	8.3
data
rate mb		1.5	.3	1	.8	1.2	1.8	3
4k blk
acc, ms		7.67	85.8	40.6	43.4	36.7	32.3	25.6
4k acc.
per sec		130	11.6	24.6	23	27	31	39
40k acc
per sec		31.6	4.9	13.	11.3	15.	19.1	26.6
4k acc
per sec
per meg		11.6	.4	.38	.11	.08	.11	.06

======================================================================

slightly different table ... assuming a uniform access distribution, loading the indicated max. data on the drive (i.e. not filling the whole thing) gives the resulting 4kbyte-block-access/sec/mbyte (i.e. 3380 with only 40mbyte loaded gives approx. the same performance as 2314).


		2305	2314	3310	3330	3350	3370	3380
data
cap, mb		11.2	29	64	200	317	285	630
4k acc.
per sec		130	11.6	24.6	23	27	31	39
20 meg		-	.041	.091	.082	.098.	.122	.152
40 meg		-	-	.023	.021	.025	.031	.039
60 meg		-	-	-	.009	.011	.014	.017
80 meg		-	-	-	.005	.006	.008	.010

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 10 Jan 1999 15:05:45 -0800
370s were 115, 125, 135, 145, 155, 165 (and sort of 195)

initial 155 & 165 had no virtual memory (relocation) hardware

it was possible to open the front panel of the 155 and disable the cache ... and the thruput of the machine dropped to that of about a 145.

to announce virtual memory ... the 155s & 165s in customer shops needed a hardware retrofit. Turns out for the full virtual memory announcement ... an extra hardware line thru much of the 165 would have had to be designed and built ... and would have delayed virtual memory announcement by an additional six months. Since SVS (effectively MVT remapped to a virtual memory space) stated that they had no need for the full architecture ... they would be perfectly happy to go with abbreviated virtual memory hardware roll-out. The other machines shipped day one with the virtual memory support built in ... but had to wait for 155/165 & software before it was turned on.

155s and 165s were upgraded with 158s & 168s ... and 135s and 145s then with 138s and 148s.

The 168-1 had an interim upgrade to a 168-3 which doubled the size of its cache (although there were a couple shops who installed the 168-3 field upgrade and saw performance decline).

The 158s&168s were then upgraded by 3031, 3032, and 3033. The big feature of the 303x line was the channel director (somewhat analogous to the channel director on the 360/67 duplex configurations ... and actually a separate stripped down 158 processer with a different microcode load). The 3031s and 3032s were 158s and 168s repackaged with I/O support going thru the channel director. The 3033 started out as a 168 wiring diagram remapped to a faster chip technology.

The 138s & 148s were upgraded to 4331 and 4341 ... and then to 4361 and 4381.

The internal network was tagentially involved in the 145 support. The internal network was larger than the arpanet/csnet pretty much from the start up thru sometime in the mid-80s. One of the first links in the internal network (besides those running between machines in the same building) was between cambridge (mass) and endicott (ny).

Most of the virtual machine work was done in cambridge and the 370/145 work was being done in endicott. Endicott came to cambridge and proposed a joint project to build a 370 virtual machine capability ... which ran within a CP/67 (i.e. 360/67) virtual machine ... simulating the features that were different between the 360 and 370. A version of CP/67 was created that would provide 370 virtual machine architecture (this was reference to as 3.1h). Then a version of CP/67 was modified so that it ran on the 370 relate architecture (referred to as 3.1i).

For various security reasons ... partly because there were people like MIT students that had access to the Cambridge CP/67 service ... the environment looked like:


standard CP/67 running on real 360/67
    providing 360/65 and 360/67 virtual machine service
a 3.1h operating system running in a 360/67 virtual machine
providing 370/145 (both relocate and non-relocate) virtual machines
a 3.1i operating system running in a 370/145 relocate virtual machine
        providing 370/145 (both relocate and non-relocate) virtual machines
cms running in a 370/145 non-relocate virtual machine

This evironment had been running for a year before the very first 370/145 engineering machine (of any kind) was up to the point that it could be tested. The first time that the "3.1i" system was booted on the first engineering 370/145 machine ... it failed. After some quick diagnostic, it turned out that the engineers had implemented some of the architecture wrong. The operating system was quickly patched to correspond to the incorrect hardware implementation ... and the testing then proceeding successfully.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 11 Jan 1999 08:45:42 -0800
drums are ibm'ese for fixed head disks.

well ... alright ... i added it to the '95 posting after getting questions from the posting in early '90s seemingly coming from no knowledge of either DASD nor drums ... "fixed head disks" seemed to be the simplest throw-away to get over that bit.

i tried to get a separate read/write data path (ala 2505 device "exposures") to the 3350 but it got shot down by the vulcan crowd.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 12 Jan 1999 10:30:45 -0800
cp/67 started out being less than a single tray of "binary" cards.

vm/370 simulated card decks got much larger ... not only because there was much more code ... but also typically upwards of half the cards in any particular txt/binary deck was the source code tracking information (PTFs, macro libraries, updates, source libraries, etc).

the output of such a load was printed output of all the entry points in each module ... plus all the source code tracking information.

I remember being in madrid in the mid-80s ... and going to a theater showing some 30? minute drama "short" done at the university ... in several shots there was a wall of TV sets (20-30?) all "scrolling" the same information at around 1200 baud. I felt funny being able to recognize it was the VM/370 "loadmap" (i.e. output from the binary program load) ... i felt even funnier being able to recognize the year & month of the system based on the source code information scrolling past at 1200 baud.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 12 Jan 1999 23:36:17 -0800
cp/67 originated with people from cambridge science center and some work being down by people from lincoln labs ... summer of 68 ... a couple of the people left and formed NCSS offering enhanced CP/67 online service ... another group left and formed IDC (interactive data) ... NCSS was down in Stanford Conn ... IDC was out in waltham mass. I was undergraduate ... there was an IBM sponsored class on CP/67 that summer down someplace in LA ... I got pressed into teaching part of the CP/67 class ... possibly because one or more of the IBM'ers had left and gone to NCSS.

back then you could get CP/67 from IBM ... sort of like you can get linux today ... all the source and do whatever you wanted with it. Lots of places ... including universities got copies with source ... and large numbers (well not large numbers by today's standards) ... but still significant numbers ... took the system & source and did various things with it.

all of this well before VM/370. Tymshare later used VM/370 to offer online service ... mid-70s

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old Computers

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers
Newsgroups: alt.folklore.computers
Date: 17 Jan 1999 22:31:07 -0800
found green cards ... GX20-1703-7 yellow cards are GX20-1850-3 ... 1976 and the blue cards are 229-3174-0

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old Computers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers
Newsgroups: alt.folklore.computers
Date: 18 Jan 1999 18:07:48 -0800
I was involved in getting Interdata3 (and later array of interdata3s with an interdata4) to simulate an IBM mainframe communication control unit (bus&tag channel card, etc) ... I've been told that this activity was documented as having originated the IBM "OEM" (other equipment manaufacter) control unit business. Somewhere along the line interdata was bought by Perkin/Elmer. Recently somebody told me that they were selling Perkin/Elmer boxes in the early 80s with 360/370 bus&tag wire-wrap channel board ... potentially the same board design that we had done something like 15 years earlier.

If you look at other threads in this newsgroup ... the interdata 7? from the late 70s was one of the early efforts making Unix portable.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old Computers

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers
Newsgroups: alt.folklore.computers
Date: 18 Jan 1999 19:11:16 -0800
360 had 8 bit bytes and standard i/o read a card column into single 8-bit byte. ... since a card column could contain up to 12 bits of information (12 rows) ... 360 defined a restricted subset of possible card punch combinations.

1401 supported binary .... to support processing 1401 binary decks (with more than 8 bits punched per column) ... 360 card punch controller had a "column binary" mode which read 80 columns into 160 byte positions ... in order to represent all information. From 360 green card 2540 operation:


read, feed, select stacker SS:             SSD00010

where SS: 00 stacker R1
01 stacker R2
          10 stacker RP3

       D: 0  EBCDIC
1  column binary

character mode on 1401 was BCD 6bit code and almost proper subset of EBCDIC in punch card definition.

it was possible to read/punch BCD cards using standard EBCDIC mode, but required column binary to read/punch 1401 binary cards.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old Computers

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers
Newsgroups: alt.folklore.computers
Date: 19 Jan 1999 10:50:03 -0800
yep ... there was very little structural integrity left in a card that you had bunched all 80x12 holes ... didn't even necessarily require high speed reader.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Glass Rooms (was Re: drum memory (was: Re: IBM S/360))

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Glass Rooms (was Re: drum memory (was: Re: IBM S/360))
Newsgroups: alt.folklore.computers
Date: 20 Jan 1999 19:58:58 -0800
my wife was UMich engineering graduate school ... and remembers blockades and riots ... having to cross picket lines to classes; once being in engineering lab with nose pressed to the window watching the rioters came thru the square trashing everything in their wake ... and somewhat surprised afterwards that they had broken out every window facing the square except the one she had her nose pressed to.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old Computers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers
Newsgroups: alt.folklore.computers
Date: 23 Jan 1999 07:46:46 -0800
there is another place that batch systems have worked ... almost any server deployment. the platforms that have grown out of interactive&desktop have paradigm that if something goes wrong ... they've tended to assume a human there to recognize and take action.

the batch paradigms have tended to provide extensive trap & recovery features to the application level (default to system define recovery and/or operator message ... but 7x24 applications could implement extensive support if that level of availability was required).

for the first webserver doing payments/e-commerce ... after they had done the straight-line and stress testing ... i went back with a failure-mode array (something like 40+ failure modes and 5-6 states), webserver code had to demonstrate automatic recovery ... and/or sufficient logging that on a trouble call ... the trouble desk could diagnose the problem within five minutes (none of this NTF on the trouble ticket after 2-3 hrs). Application couldn't inline trap on something like ICMP host not reachable ... and so had to do some contortions to produce something even approaching 7x24. I had to browbeat to even get multiple A-record support.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old Computers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers
Newsgroups: alt.folklore.computers
Date: 23 Jan 1999 11:58:29 -0800
my view point is that the old computers hosted both sequential batch as well as almost all of the major online applications currently in existance (airline res, payroll, banking, financial, insurance, securities, etc).

In some cases there have web gateways done to access those online capabilities.

as mention in prior note ... the old computers tended to follow the paradigm that things ran w/o people present (except for operators doing tape mounts) ... this has led to a rich set of semantics for trapping failures and being able to automate various recover strategies ... even up thru the application layer.

the desktop&interactive systems (and their derivatives) have tended to operate with a paradigm that person was issuing a "command" ... and therefor could determine a recovery strategy.

the legacy stuff ... has assumed that people weren't interactively determining the execution strategy (either in batch or in the big OLTP systems) ... and so sophisticated automated processes were developed.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old Computers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers
Newsgroups: alt.folklore.computers
Date: 23 Jan 1999 19:54:25 -0800
following from posting to alt.folklore.computers made here in 94mar. there was issue in early '80s regarding stanford PhD thesis on "clock" algorithms for page replacement ... meeting severe resistance because it talked about stuff that wasn't local LRU and/or as defined per true "working-set". I had done the global "clock" global LRU in the late 68 time-frame with a dynamic adaptive thrashing control that worked significantly better than working set (as found in the literature of the time). the following direct comparison ... same processor, same I/O, similar workload and configurations ... was instrumental in removing objections to thesis and PhD.

Genoble Science Center published a paper in CACM sometime in the early '70s describing their implementation of a "working-set" dispatcher on CP/67 (effectively faithful implementation described in Denning's article). They had a 1mbyte 360/67 (which left 154 4k "pageable-pages" after fixed kernel requirements). They provided about the same level of performance for 30 users as we did for 70 user on a 768k 360/67 (104 4k pageable pages).

The differences (circa '70-71):


grenoble                  cambridge
machine               360/67                    360/67
# users               30-35                      70-75
real store             1mbyte                     768k
p'pages               154 4k                     104 4k
replacement          local LRU               "clock" global LRU
thrashing            working-set             dynamic adaptive
priority             cpu aging               dynamic adaptive

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Most embarrassing email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Most embarrassing email?
Newsgroups: alt.folklore.computers
Date: 07 Feb 1999 14:28:22 -0800
late 80s, i agreed to forward a "farewall" email written by my former boss saying that he was leaving the company and moving on to other opportunities. I selected the wrong distribution list and it went out to some 23,000 people inside the company. got quite a bit of flack back from around the world about who was I and why was I sending them the email.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

APL/360

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: APL/360.
Newsgroups: alt.folklore.computers
Date: 09 Feb 1999 13:27:52 -0800
big problem with apl/360 was its relatively small workspace ... typically 32k or less. when we ported to CMS (71?) we opened up the workspace to full virtual machine size (up to 16mbytes). One of the biggest problems with apl/360 was storage allocation ... every assignment (even to existing variables) went to new storage location. Instruction traces of apl/360 showed stair-step use of storage until it reached end of memory ... and then a sharp drop back by garpage collection moving everything down to lowest available address ... and then the stair-step use again. The storage allocation plus garbage collection created very saw-tooth pattern of storage usage. In a real storage environment it wasn't a problem ..... but in a virtual memory environment it was guaranteed to touch every virtual page ... and have very poor LRU characteristics (i.e. if you used it recently ... it might get re-assigned to totally new location and not be re-used). One of the things that had to be done for the apl/360 port to apl/cms was a storage management rewrite to make it useful for real-world problems.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
Newsgroups: alt.folklore.computers,sci.skeptic,alt.folklore.urban,alt.folklore.military
Date: 10 Feb 1999 11:44:27 -0800
i've noticed what appear to be taxi way leading off into the trees at various places on roads in sweden.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
Newsgroups: alt.folklore.computers,sci.skeptic,alt.folklore.urban,alt.folklore.military
Date: 11 Feb 1999 08:31:25 -0800
resilliance of runways needed to handle repeated impact of landing ... something that didn't need to be considered for roads.

even at that ... there was story about early landing approach signal at SeaTac ... and they noticed 747s landing within six feet of each other and the runway was starting to crack under the beating ... so they introduced randomization in the signal which spread touch-downs over 100 foot area.

on the other hand ... when I first drove on interstate on the east coast I noticed some with frost heave problems that was significantly worse than mountain county roads out west. the natives of the eastern state commented that it was a characteristic of the road industry in the state ... if they had actually done a 6'+ road bed initially ... then they wouldn't get paid to go out every year and repair the frost heaves.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve    Y2K)
Newsgroups: alt.folklore.computers,sci.skeptic,alt.folklore.urban,alt.folklore.military
Date: 12 Feb 1999 12:34:50 -0800
I've been told that highways may need up to 6' roadbed ... especially in frost heave situations.

A couple years ago I was at some road seminar that claimed 95+% of road and interstate wear & tear is by 18 wheelers ... that passenger cars don't exert enuf poinds per sq. inch to affect road materials ... but compression/decrompression of 18 wheelers on surface and roadbed was measurable ... and that was where almost all road wear came from (exceptions scenerios with frost heave and inadequate roadbed).

The net was that once roads were built ... almost all highway tax dollars is for repair ... and shouldn't the tax rate for repair be proportional to damage caused (<5% of total highway taxes spread across all non-18 wheeler use ... and 95+% of all highway taxes solely levied on 18-wheelers).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

BA Solves Y2K (Was: Re: Chinese Solve Y2K)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
Newsgroups: sci.skeptic,alt.folklore.urban,alt.folklore.computers
Date: 12 Feb 1999 14:20:17 -0800
date problems posted by somebody to a newsgroup in 1984:

Date: 7 December 1984, 14:35:02 CST
To: Distribution

1.In 1969, Continental Airlines was the first (insisted on being the first) customer to install PARS. Rushed things a bit, or so I hear. On February 29, 1972, ALL of the PARS systems cancelled certain reservations automatically, but unintentionally. There were (and still are) creatures called "coverage programmers" who deal with such situations.

2.A bit of "cute" code I saw once operated on a year by loading a byte of packed data into a register (using INSERT CHAR), then used LA R,1(R) to bump the year. Got into a bit of trouble when the year 196A followed 1969. I guess the problem is not everyone is aware of the odd math in calendars. People even set up new religions when they discover new calendars (sometimes).

3.We have an interesting calendar problem in Houston. The Shuttle Orbiter carries a box called an MTU (Master Timing Unit). The MTU gives yyyyddd for the date. That's ok, but it runs out to ddd=400 before it rolls over. Mainly to keep the ongoing orbit calculations smooth. Our simulator (hardware part) handles a date out to ddd=999. Our simulator (software part) handles a date out to ddd=399. What we need to do, I guess, is not ever have any 5-week long missions that start on New Year's Eve. I wrote a requirements change once to try to straighten this out, but chickened out when I started getting odd looks and snickers (and enormous cost estimates).


... snip ... top of post, old email index

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

You count as an old-timer if (was Re: Origin of the phrase

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: You count as an old-timer if (was Re: Origin of the phrase
Newsgroups: alt.folklore.computers
Date: 13 Feb 1999 11:03:29 -0800
• could whistle and get a 110 acoustic modem to talk back to you
• had AJ(?) "portable terminal" in two 30lb(?) cases at home
• have had uninterrupted computer access at home for more than 25 years
• bought golden's Fortran IV programming and computing ('65) new.
• programmed on (709 or other) tube machine

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 15 Feb 1999 05:46:55 -0800
3270s operate analogous to restricted version of HTTP forms. There is control format for writing things to a page/screen .. output only areas, input areas, output&input areas, etc. Imagine early version of web/tv ... initially no color and no graphics, 25+ years ago, and interface between processor and controller ran at 640kbytes/sec.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese
Newsgroups: alt.folklore.computers
Date: 15 Feb 1999 14:40:38 -0800
I thot I remember being told that unpowered a 727 has absolutely no aerodynamic characterisitcs at all ... drops like a rock ... in fact there was something about early on having to change to "powered" landings for 727 because of stall danger.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM S/360

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360
Newsgroups: alt.folklore.computers
Date: 16 Feb 1999 04:47:03 -0800
the original 3270 was 3272 controller and the 3277 (24x80) terminal which had keyboard & other logic in the head. The 3274 controller moved much of the head logic back into the controller ... reducing the per terminal costs and introduced the 3278 (43x80 & other modes), 3279 (color and graphics), 3290(?) (flat panel).

The 3270 terminals had and annoying habit of dropping characters and locking the keyboard if you happened to be typing a character at the very moment that there was a write to the screen. Repeat and cursor positioning speeds were also maddening slow. On the 3277, because the logic was in the head ... some user modifications were possible ...

1) little soldering on the board inside the keyboard and you adjust the repeat delay, repeat rate, and cursor positioning speeds. It was actually possible to overdrive the repeat rate so that the screen update fell behind the keyboard repeat ... it took a little practice to position the cursor under a specific character ... since the cursor would continue to move for several positions after you lifted the cursor positioning key.

2) FIFO box inserted between where the keyboard plugs into the head which eliminates drop character and keyboard lockup.

It wasn't possible to fix the 3274-based terminals because the logic had moved back into the controller.

The 3270 card for the IBM/PC offerred the opportunity to do some creative programming to enhance the user interface characteristics.

In the early 80s my brother was a regional apple sales rep. I attended dinners with the mac developers during the early mac period ... and getting into heated arguments about tainting the "kitchen table only" machine with something as unthinkable as a terminal emulator (3270) adapter

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

You count as an old-timer if (was Re: origin of the phrase

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: You count as an old-timer if (was Re: origin of the phrase
Newsgroups: alt.folklore.computers
Date: 17 Feb 1999 07:06:52 -0800
highly skilled programmers working closely with the customer on day to day basis over extended period of time ... developing software that exactly met the needs and refining as necessary in live production work ... frequently resulted in solutions that better met customer requirements than something done at some central site by people hypothesising what the actual requirements might be.

the crux with the vast amounts of IBM people in the field doing customer software apps was June 23rd, 1969 .... what was that date?

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

You count as an old-timer if (was Re: origin of the phrase

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: You count as an old-timer if (was Re: origin of the phrase
Newsgroups: alt.folklore.computers
Date: 17 Feb 1999 14:16:55 -0800
june 23rd, 1969

government got ibm to unbundle hardware, software, services, etc. ... now if somebody was at customer site or doing something for a customer it was billed time to the customer , phone calls became billed time, everything, pretty much got broken out into billed time. all the friendly people helping the customer disappeared and replaced with cash registers that kept going ding, ding, ding, ding, ding, ding.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old Computers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers
Newsgroups: alt.folklore.computers
Date: 18 Feb 1999 16:44:56 -0800
worked with the engineers over the the disk development lab in the late 70s ... they were running standalone environment and using OLTEP and other stuff to exercise disks that they were developing.

problem was that typical mean-time between failures in that environment was something like 15 minutes for MVS. Environment was dozen or so disk engineering "test cells" (each engineering device was inside a steel wire cage that contained combination lock ... dozen of these cages on the machine room floor, each with own engineering device).

They tended to have the largest, newest mainframe processor (in order to test that the cpu worked with the disks)

I worked on building an absolute bullet proof i/o subsystem so that no single test cell or combination of test cells would crash the operating system. That allowed them to concurrently test all test cells ... instead of having to schedule dedicated machine time. Simultaneous testing of all test cells would utilize maybe 5% of a processor ... at the most. The rest of the processing power then was available for working on interesting problems.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Roads as Runways Was: Re: BA Solve

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Roads as Runways Was: Re: BA Solve
Newsgroups: alt.folklore.computers
Date: 20 Feb 1999 10:24:57 -0800
i did a stint at boeing (during the dawn of BCS) ... back when the 747s were being introduced and the marketing claim that a 747 would alwas be serviced by at least four jetways ... serial #3 would be periodically seen flying thru skys of seattle.

the story I remember was that tex barrel-rolled both 707 and 727 coming off of renton field. a "problem" was that these were test configurations ... 50 gal drums in place of passenger seats; complex set of pipes and pumps would move water into different drums to test all sort of weight distribution configurations ... in any case, the barrel rolls tore a lot of this loose and there was lot of repair that had to be done.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

why is there an "@" key?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: why is there an "@" key?
Newsgroups: alt.folklore.computers
Date: 26 Feb 1999 08:01:44 -0800
CSC did cpremote ... something like hasp for cp/67 ... and then what became vnet. i believe one of the first vnet links was cambridge to endicott ... in support of the virtual 370 relocate project (modify a version of cp/67 to provide virtual 370 machines ... which had different relocate architecture than 360/67, and then do another modification of cp/67 that ran on 370 relocate hardware ... at cambridge there was "3.1l" running on the bare hardware ... pretty vanilla cp/67 ... in part because of security concerns because it had general users ... even MIT students using the system ... then in a virtual 67 run "3.1h" ... which ran in virtual 360/67 machine ... but provided virtual 370 machines ... then in a virtual 370 machine run "3.1i" ... which was a modification of cp/67 running on 370 relocate hardware architecture ... this was all done and in regular use a year before there was a real 370 engineering hardware that could be booted/ipled).

i believe the internal vnet was larger than the arpanet/internet from nearly its start up until sometime in the mid-80s.

i believe that vnet was one of the first things that had a truely layered architecture and implementation. This was used extensively to allows JES systems to participate in the internal network. JES networking started out mapping network nodes into the HASP 99-entry table (network nodes had to share entries with spool & real device entries ... so might only have 30 entries available). Later this was expanded to 255-entries and then to 999-entries ... however at all times the internal network had more nodes that could be mapped by JES table. As a result, JES nodes were regulated to end nodes ... because they had bad habit of discarding traffic involving nodes (either source or destination) that weren't in their local table.

The other JES problem is that they confused the network driver with the rest of the system function. As a result, one release of JES could cause other releases of JES (and the whole operating system) to crash by sending data with slightly different headers.

As a result, a VNET system might be deployed with a wide range of drivers ... standard VNET-to-VNET driver as well as a variety of JES drivers ... to handle different JES versions as well as doing JES protocol release-to-release translation to prevent JES subsystems ... and JES based operating sysetms from crash & burn (i.e. instances of modified JES systems on the west coast causing JES machines in europe to crash & burn ... because the west coast system had modified JES and moved a couple header byte definitions around and then tried to send europe some data).

in the mid-80s my wife and i ran skunk works ... one of the things was something we called high-speed data transport ... with a backbone that part of internal traffic was carried over. at the time of NSFNET1 RFP ... we attempted to get permission to bid and weren't allowed. We did get a technical audit by NSF that said what we were operating was at least five years ahead of all bid submissions (to build something new). I had done a number of things in the implementation ... included rate-based flow & congestion control ... something that they are now looking at for Internet2 (so maybe it was more than five years ahead).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

why is there an "@" key?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: why is there an "@" key?
Newsgroups: alt.folklore.computers
Date: 26 Feb 1999 08:59:18 -0800
one of the problems with vnet implementation was that it was store&forward and used the cp/67-vm/370 "spool" file system interface ... which included problems like synchronous filesystem semantics (a vnet node frequently bottlenecked somewhere between 20kbytes-40kbytes per second aggregate thruput ... primarily because of synchronous semantics at the disk interface).

for HSDT did a virtual passthru driver that would support local node store&forward bypass (i.e. end-to-end transmission). This eliminated problem with synchronous semantics at intermediate nodes.

for HSDT I also did a port of the "spool" filesystem to a virtual machine subsystem, completely rewritten in pascal and featured asynchronous semantics, block/contiguous allocation for large files, high-level multi-data block pointers (supporting multi-block read/writes), low-level forward/backward block threading for filesystem disaster recovery, and multi-device spool filesystem independence (large installation would have spool filesystem spread across large number disks ... failure of any single disk would corrupt/crash whole infrastructure).

hsdt had to deal with both intermediate and end nodes sustaining mbyte thruput rates ... 50-100 times (or more) what a typical vnet was capable of.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

why is there an "@" key?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: why is there an "@" key?
Newsgroups: alt.folklore.computers
Date: 26 Feb 1999 09:13:39 -0800
pr*fs had picked up source (about 60klocs of 370 assembler) of prerelease .8 or so of something called VMSG ... and wrappered their own command & gui interface around the feature/function ... and then claimed they had done the whole thing. One of the stoppers was that all VMSG based implementations had the author's initials in comment/unused control fields of all messages.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

why is there an "@" key?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: why is there an "@" key?
Newsgroups: alt.folklore.computers
Date: 26 Feb 1999 10:56:27 -0800
sligthly related
From: Automatic digest processor <LISTSERV@UAFSYSB.UARK.EDU>
Date: Thu, 11 Feb 1999 19:21:21 -0800
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: LINUX on VM (history?).

during early '86 i was talking to one of the two guys that had originated vs/pascal (the other had left the company to go to a start up) about doing a C front-end ... so I could have C code on CMS. That summer, I left on a six week seminar series in europe and when I got back ... the person I was talking to had left IBM for a small compiler-compiler company near santa cruz.

about a month later, the academic unit decided to do a BSD port to run under VM ... and the head of the APL2 group in STL was brought in to head up the project. I spent the first week with the group looking at all the issues to get the BSD port done. One of the prime things that needed to be done was a C compiler for the 370 ... and so I suggested we go to the santa cruz company and get them to do it ... since the guy there had effectively already done much of the work..

well into the project ... the academic unit decided that they would retarget the BSD port to the PC/RT instead of under VM/370 ... calling it AOS ... but keeping the same santa cruz compiler company as the c compiler.

A little later ... work began on getting native TCP/IP product support for vm/370 ... running thru the 8232. Since I had done a lot of other kinds of VM device drivers ... I did the device driver and pathlength tuning to support RFC1044. To fully test it ... I had to go to cray research in minneapolis. I remember the trip because the plane left SFO about 20 minutes late for Minneapolis ... and what we learned just before touch done in Minneapolois was that we left the ground five minutes before the big earthquake. At Cray ... they had a 4341-clone for me to test the RFC1044 support running to the Cray machine ... after some tuning we got RFC1044 support running between the 4341-clone and the Cray at sustained thruput rate of the 4341 channel hardware .... using only a modest amount of CPU utilization on the 4341 clone. It was a little embarrasing since the 8232 support could nearly max. out a 3090 processor getting 44kbytes/sec thruput. The product implementation was done in vs/pascal ... not C ... since we still didn't have a C compiler product and not a lot of C programmers.


--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

why is there an "@" key?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: why is there an "@" key?
Newsgroups: alt.folklore.computers
Date: 26 Feb 1999 14:23:36 -0800
ctss carried over to 2741 on cms had "@" as the character erase and "cent-sign" as line erase ... "@" and "cent-sign" were on the same key ... right-most key in the u-i-o-p row ... just above home position ... "@" as lower-case of the key ... "cent-sign" was upper-case ... so one or more "@" deleted one or more characters ... upper-case "@" ... i.e. "cent-sign" deleted the whole line.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subjet: Internet and/or ARPANET?
Newsgroup: alt.folklore.computers
Date: 01 Apr 1999
reposted ... originally 31dec1998 alt.folklore.computers

not so much from technical standpoint but

... arpanet/telenet/tymnet -> csnet -> nsfnet -> internet

my wife and I were effectively (a?) red team on both nsfnet1 and nsfnet2 ... weren't actually allowed to bid (although nsf technical audit of backbone my wife and I operated claimed what we were running was at least five years ahead of submitted bids ... to build something new).

Date: 10/22/82 14:25:57
To: CSNET mailing list
Subject: CSNET PhoneNet connection functional

The IBM San Jose Research Lab is the first IBM site to be registered on CSNET (node-id is IBM-SJ), and our link to the PhoneNet relay at University of Delaware has just become operational! For initial testing of the link, I would like to have traffic from people who normally use the ARPANET, and who would be understanding about delays, etc. If you are such a person, please send me your userid (and nodeid if not on SJRLVM1), and I'll send instructions on how to use the connection. People outside the department or without prior usage of of ARPANET may also register at this time if there is a pressing need, such as being on a conference program committee, etc.

CSNET (Computer Science NETwork) is funded by NSF, and is an attempt to connect all computer science research institutions in the U.S. It does not have a physical network of its own, but rather is a set of common protocols used on top of the ARPANET (Department of Defense), TeleNet (GTE), and PhoneNet (the regular phone system). The lowest-cost entry is through PhoneNet, which only requires the addition of a modem to an existing computer system. PhoneNet offers only message transfer (off-line, queued, files). TeleNet and ARPANET in allow higher-speed connections and on-line network capabilities such as remote file lookup and transfer on-line, and remote login.


... snip ... top of post, old email index

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp
Date: 02 Apr 1999 08:47:54 -0800
jmfbahciv writes:
In article <ur9q45d5u.fsf@garlic.com>,
1982? Just what timespan have we been talking about. I've been talking about 1968-1978 or thereabouts.
/BAH
Subtract a hundred and four for e-mail.


i didn't comment about when/what you were talking about ... & I wasn't commenting about the technical issues. Part of the arpanet/internet evolution was participation, deployment and funding of different entities. CSnet (and NSFNET) was a NSF funded/deployed activity ... while ARPAnet nodes had a lot of funding/control by other government agencies i.e. there can be facets considered other than protocol/technology

looking at it from other facet ...

.. misc rfcs:
894 - Standard for the transmission of IP datagrams over Ethernet networks 1984/04/01

826 - Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48 bit Ethernet address for transmission on Ethernet hardware .. 1982/11/01

791 - Internet Protocol 1981/09/01

761 - DOD Standard Transmission Control Protocol 1980/01/01

739 - Assigned Numbers 1977/11/11


.... misc IEN:
IEN#1 - Issues in the Interconnection of Datagram Networks 1977/07/29
IEN#3 - Internet Meeting Notes 1977/08/15
IEN#5 - TCP Version 2 Specification 1977/03/
IEN#10 - Internet Broadcast Protocols 1977/03/07
IEN#11 - Internetting or Beyond NCP 1977/03/21
IEN#14 - Thoughts on Multi-net Control and Data Collection Factilities 1977/02/28


... and from IEN#16:


IEN # 16
Network Working Group                                         Jon Postel
Request for Comments: 730                                        USC-ISI
NIC: 40400                                                   20 May 1977

Section: 2.2.4.2      Extensible Field Addressing

Introduction

This memo discusses the need for and advantages of the expression of
addresses in a network environment as a set of fields.  The suggestion
is that as the network grows the address can be extended by three
techniques: adding fields on the left, adding fields on the right, and
increasing the size of individual fields.  Carl Sunshine has described
this type of addressing in a paper on source routing [1].

Motivation

Change in the Host-IMP Interface

The revised Host-IMP interface provides for a larger address space for
hosts and IMPs [2].  The old inteface allowed for a 2 bit host field and
a 6 bit IMP field.  The new interface allows a 8 bit host field and a 16
bit IMP field.  In using the old interface it was common practice to
treat the two fields as a single eight bit quantity.  When it was
necessary to refer to a host by number a decimal number was often used.
For example host 1 on IMP 1 was called host 65. Doug Wells has pointed
out some of problems associated with attempting to continue such useage
as the new interface comes into use [3].  If a per field notation had
been used no problems would arise.

Some examples of old and new host numbers are:

Host Name       Host IMP old #   new #
  --------------------------------------
SRI-ARC            0   2     2       2
  UCLA-CCN           1   1    65   65537
ISIA               1  22    86   65558
ARPA-TIP           2  28   156  131100
BBNA               3   5   197  196613

Multinetwork Systems

The prospect of interconnections of networks to form a complex
multinetwork system poses additional addressing problems.  The new
Host-IMP interface specification has reserved fields in the leader to
carry network addresses  [2].  There is experimental work in progress on
interconnecting networks [4, 5, 6]. We should be prepared for these
extensions to the address space.

The addressing scheme should be expandable to increase in scope when
interconnections are made between complex systems.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

1968 release of APL\360 wanted

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1968 release of APL\360 wanted
Newsgroups: comp.lang.apl,comp.sys.ibm,alt.folklore.computers
Date: 04 Apr 1999 10:44:12 -0700
might find a flavor of it on one of the VM user group archives. Early '70s, CSC ported APL/360 to CP/67-CMS, eliminated the monitor & other multi-user stuff (since CP/CMS provided that part), opened up the workspace to 24bit, rewrote garbage collect (original apl/360 memory management never re-used storage ... alwas allocated new slot for assignment, when it got to end of workspace it collapsed everything back to low-memory (not too bad on 32kbyte workspace but running even a small program in 16mbyte workspace could be disasterous), and added stuff to interface to external things (like doing file i/o).

The last kick off big ruckus between cambridge science center and the phili science center (where falkoff was) ... which eventually lead to "shared variables" ... as paradigm for accessing external features.

The cms/apl version of apl/360 had significant more useage and wider distribution than the original apl/360. One of the major applications was on HONE which not only provided all the online support for field people (sales, marketing, SEs, CEs, branch, etc) ... but was also main stay of corporate hdqtrs for planning, forecast, business management, etc aspects.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp
Date: 07 Apr 1999 23:34:58 -0700
re: RFCs available ...

see the RFC index at http://www.garlic.com/~lynn/

many of the IENs are available as either IEN files or RFC files.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp
Date: 08 Apr 1999 00:17:37 -0700
re: files

for some related information see rfc2555 just released today

files can be found at ftp.isi.edu ... rfcs in directory in-notes (which is where my rfc index points to retrieve the actual rfc). iens can be found in directory in-notes/ien. just checking ien-index.txt might be of some interest to see the IP evoluation from 77 to 82.

from ien111:


August 1979
IEN: 111
Replaces:  IENs 80,
54, 44, 41, 28, 26

Internet Protocol Specification

1.  INTRODUCTION

1.1.  Motivation

The Internet Protocol is designed for use in interconnected systems of
packet-switched computer communication networks.  Such a system has
been called a "catenet" [1].  The internet protocol provides for
transmitting blocks of data called datagrams from sources to
destinations, where sources and destinations are hosts identified by
fixed length addresses.  The internet protocol also provides for
fragmentation and reassembly of long datagrams, if necessary, for
transmission through "small packet" networks.

1.2.  Scope

The internet protocol is specifically limited in scope to provide the
functions necessary to deliver a package of bits (an internet
datagram) from a source to a destination over an interconnected system
of networks.  There are no mechanisms to promote data reliability,
flow control, sequencing, or other services commonly found in
host-to-host protocols.

1.3.  Interfaces

This protocol is called on by host-to-host protocols in an internet
environment.  This protocol calls on local network protocols to carry
the internet datagram to the next gateway or destination host.

For example, a TCP module would call on the internet module to take a TCP segment (including the TCP header and user data) as the data portion of an internet datagram. The TCP module would provide the addresses and other parameters in the internet header to the internet module as arguments of the call. The internet module would then create an internet datagram and call on the local network interface to transmit the internet datagram.

In the ARPANET case, for example, the internet module would call on a local net module which would add the 1822 leader [2] to the internet datagram creating an ARPANET message to transmit to the IMP. The ARPANET address would be derived from the internet address by the local network interface and would be the address of some host in the ARPANET, that host might be a gateway to other networks. --
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet (TM) and USPTO
Newsgroups: comp.protocols.tcp-ip.domains,misc.int-property,misc.legal,alt.folklore.computers
Date: 08 Apr 1999 13:09:34 -0700
bitnet (and its european cousin, earn) was a corporate sponsored network for universities ... somewhat similar to nsfnet's sponsored csnet. bitnet was based on technology from the corporate internal network ... the courporate internal network was larger than arpanet/csnet/nsfnet just about from day one thru about mid-80s (possibly one of the biggest factors in arpanet/csnet/nsfnet exceeding the corporate internal network in size were workstations that started to come into vogue in the early '80s ... while the internal corporate network remained mainframes, thousands of machines with hundreds of thousands of users).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp
Date: 08 Apr 1999 14:58:15 -0700
the IEN documents imply that what they were working on in the 77-80 time-frame was an "internet protocol" (IP) for infrastructures referred to as multinetwork systems (IEN-16) and catenet (ien-32).

both an "internet protocol" layer (ien-111) and "gateway" (ien-32) are integral components of being able to accomplish multinetwork systems.

from ien-32 ...


                 CATENET MONITORING AND CONTROL:
A MODEL FOR THE GATEWAY COMPONENT
John Davidson
Bolt Beranek and Newman, Inc.
                             IEN #32
Internet Notebook Section 2.3.3.12
                         April 28, 1978

Catenet Monitoring and Control:
A Model for the Gateway Component

1.  INTRODUCTION

At the last Internet meeting,  some  concern  was  expressed
that  we don't have a real "model" for what a gateway is, what it
does, and how it does it, and that without such  a  model  it  is
somewhat  dificult  to  describe  the  kinds  of activities which
should be monitored or controlled by  a  Gateway  Monitoring  and
Control  Center  (GMCC).   To  respond  to  that concern, we have
written this note to express our recent thoughts about a  gateway
model.  Although the note centers primarily around the topic of a
gateway  model,  we  have  also  included  a  few  thoughts about
possible  models  for  the  other   components   of   a   general
internetwork structure.

The  note  proceeds  as  follows.   In  Section  2 we try to
establish a reason for wanting a model of  a  given  internetwork
component, and present a brief overview of the potential benefits
of   Monitoring   and  Control.   This  presentation  is  largely
pedagogical since it is assumed that this document  will,  for  a
while  at least, be the only introduction to the topic available.

In Section 3 we discuss the fundamental kinds of  activities
which  must  be  performed  by any internet component if it is to
participate in Monitoring and Control.  This section  establishes
motivation  for  some  of the mechanisms discussed in the rest of
the paper.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 12 Apr 1999 15:31:39 -0700
somewhat digression

many/most of the networking protocols seemed to assume a relatively homogeneous environment ... i.e. arpanet with the IMPs providing connectivity.

IEN (internet) work in the 77/78 timeframe resulted in gateways and a "internet" layer (i.e. prior references to various IEN documents).

with ISO defining level3/network and level4/transport ... the internet layer effectively fit someplace in-between ISO level3/level4.

this is similar to the internal corporate network (corporate time-sharing product and the corporate network technology ... which later was used in bitnet and earn) was done starting in the late 60s in 545 tech. sq (in some extent shared common heritage with multics back to ctss) ... which effectively had a gateway layer implemented at ever node. That in part was responsible for the corporate network being larger than the arpanet/internet from almost the beginning up thru mid-80s (the other was the corporate time-sharing system that also originated at 545 tech. sq. was running on a couple thousand internal corporate mainframes). One of the things that drove the arpanet/internet passed the internal corporate network was advent of workstations as nodes.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

[netz] History and vision for the future of Internet - Public Question

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [netz] History and vision for the future of Internet - Public Question
Newsgroups: alt.internet-media-coverage,alt.culture.internet,alt.folklore.computers,news.misc,sci.econ,comp.org.ieee,alt.culture.usenet
Date: 13 Apr 1999 16:07:01 -0700
somewhat conjecture ... is that NSFNET1 contract covered possibly 1/4th to 1/10th the resources put into NSFNET1 ... the rest put in by commercial corporations. Conjecture on my part is huge amount of dark fiber laying around ... and necessary to break checken/egg situation at the time with few apps to use the bandwidth, tariffs at the time were barrier to new apps that might be evolve to use the bandwidth. Strategy was to make significant bandwidth available as seed environment that applications could evolve that would eventually be able to utilize the excess capacity. While ARPANET activity has some technology/protocol relationship to current Internet ... the huge resources provided by commercial entities starting (at least) with NSFNET1 ... significantly define the current Internet infrastructure (in that sense ... commercialization happened over ten years ago).

Interop '88 had lots of vendors and loads of academic/arpanet people that had or were in the process of making transition to commercial companies.

folklore trivia question .... what was causing floor-net meltdown on sunday before Interop '88 started (and led to configuration option that is now required in all tcp/ip implemenations).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

A word processor from 1960

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A word processor from 1960
Newsgroups: alt.folklore.computers
Date: 15 Apr 1999 16:20:23 -0700
I did something much simpler and later ... in 1968, I took the 2250 library that lincoln labs had ported to CMS ... and crafted it as device for the CMS context editor (somewhat evolved from CTSS editor) to support full screen operation

It was a 2250m1 graphics display ... mainframe channel attached that ran at a couple hundred kbytes/sec.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Enter fonts (was Re: Unix case-sensitivity: how did it originate?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Enter fonts (was Re: Unix case-sensitivity: how did it originate?
Newsgroups: alt.folklore.computers
Date: 16 Apr 1999 16:53:27 -0700
the precursor of SGML/HTML was GML (generalized markup language ... acronym were actually a hack on the three peoples last names) done at the cambridge science center and implemented in the cms script processor in the late 60s and early 70s. the script processor was ported to a number of other environments and (at least in the ibm mainframe world) could use output devices like the 3800 and the 6670 (san jose research hacked what was essentially an ibm copier3 with a computer interface to create the 6670 ... it was the first computer output device that I used that directly supported printing on both sides of the paper). There was general deployment of 6670s and the associated support by at least 1979.

Earlier implementations of font changes on 2741, ibm typerwritters and ibm word processors was achieved by manual switching of the typeball, in fact the early 3800/6670 font change processing relied on using the existing script font/typeball change processing.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Enter fonts (was Re: Unix case-sensitivity: how did it originate?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Enter fonts (was Re: Unix case-sensitivity: how did it originate?
Newsgroups: alt.folklore.computers
Date: 16 Apr 1999 16:53:27 -0700
the precursor of SGML/HTML was GML (generalized markup language ... acronym were actually a hack on the three peoples last names) done at the cambridge science center and implemented in the cms script processor in the late 60s and early 70s. the script processor was ported to a number of other environments and (at least in the ibm mainframe world) could use output devices like the 3800 and the 6670 (san jose research hacked what was essentially an ibm copier3 with a computer interface to create the 6670 ... it was the first computer output device that I used that directly supported printing on both sides of the paper). There was general deployment of 6670s and the associated support by at least 1979.

Earlier implementations of font changes on 2741, ibm typerwritters and ibm word processors was achieved by manual switching of the typeball, in fact the early 3800/6670 font change processing relied on using the existing script font/typeball change processing.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 17 Apr 1999 10:16:03 -0700
re: homogeneous/heterogeneous

I was thinking in terms of the networking hardware and the protocol being homogeneos. the end-point host machines (might be heterogeneous) were attached to the IMPs and the IMPs managed the network protocol. The 360s (lincolns '67 and UCLA's '91) would have an IBM telecommunication controller (2702 or 2701) which would then talk to the IMP.

ibm360s had interesting problems interacting with a ascii-based infrastructure ... in part because of the ebcdic/ascii character translation.

I had written tty/ascii support for CP/67 while I was an undergraduate (circa 68) that IBM shipped to customers in CP/67 (VanVleck immortalizes a y2k-type calculation "bug" at http://www.multicians.org/thvv/360-67.html, since ttys were limited to 72 characters ... i did message transfer information using one-byte/255 values; since cp/67 was shipped w/source it was relatively straight-forward to modify it to support devices that did transfers longer than 255 ... but they didn't change my one byte code stuff ... as a result calculations resulted in bad lengths and resulted in data operations off the end of the buffer, which corrupted stuff leading to system failure).

About the same time (late '68) ... a couple of us at the university built a replacement (using our own minicomputer) to replace the 2702 communication controller (which is supposedly credited with originating the ibm OEM controller business). One of the reasons was that we had original thot it was possible to dynamically associate different line scanners with different lines (i.e. dynamically determine protocol at time of modem connection on dial-up lines). It turned out it almost work except IBM had taken short-cut and hardware strapped the oscillator to a line ... so dynamic switching of line scanner worked as long as all protocols operated at the same bit rate. In any case, one of the things we implemented was strobbing of bit raise/lower signal to support dynamic speed recognition.

Back to the ebcdic/ascii problem ... ebcdic is a 256bit code and ascii is a 127bit code ... and even tho ebcdic had more bit positions ... there were also ascii characters that were not defined in ebcdic (as well as vis-a-versa). Typically, character translation was done at the 360 from ebcdic->ascii (on outgoing) and ascii->ebcdic (on incoming) ... so the ascii network didn't have to worry about dealing with non-ascci machines (it was done in the 360 host). Defining the in-bound and out-bound character translation tables got to be tricky.

in any case, the arpanet started out protocol, hardware, and character set homogeneous ... with some of the end-point hosts (360s, with different character set) trying to simulate homogeneous operation.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 17 Apr 1999 15:21:59 -0700
... from a slightly different perspective I know somebody that as a UCSB undergraduate was hired by ARPA to do host/network penetration studies prior to turning ARPANET on ... a couple years ago she observed that after nearly 30 years she could still penetrate a number of todays systems.

unless prepared it is hard to only fake strong-arm tactics.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 17 Apr 1999 18:41:17 -0700
... slightly related ... at least with regard to not being able to trap ICMPs associated with specific sessions at the application ... being a tcp/ip "bug".

Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Newsgroups: comp.arch
Date: 16 Apr 1999 11:26:41 -0700
for service based applications ... where the design point is that operation runs continuously with no human present ... the exception code for service operation can easily be 4* as much as the code supporting traditional straight-forward implementation ... frequently there are numerous domain specific exceptions and domain specific exception processing so that it is necessary to handle them in the application (and not take the default of the infrastructure).

... and of course my motherhood statement ... many of the infrastructures that grew up out of "batch" systems tend to be richer in their support of exception since the design point assumption was there wasn't a person directly connected to the application for operation (as compared to infrastructures that grew-up out of desk-top and/or interactive environments that had design point assumptions that a person might ultimately deal with the situation).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Newsgroups: comp.arch
Date: 16 Apr 1999 13:19:41 -0700
... oh yes, trivial example.

in the summer of '95 i got to diagnose an epidemic system failure at a large service provider. turned out to be the machine(s) were crashing with resource exhausion because of large number of half-open sessions (almost exactly to the day, a year prior to the denial of service attack problem hit the press in the summer of '96).

in any case, ... it reminded me of network services deployed 20+ years early that trap/caught similar error condition and appropriately released the resources. However, ... there was no way that I could set a trap on a tcp/ip half-open session so that all associated ICMP errors (like port not available and host not reachable) specific for that half-session. From a service offering stand-point, I consider that an error in both the tcp/ip implementation as well as in the protocol (regardless of the architecture purity appearance of the protocol).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Newsgroups: comp.arch
Date: 16 Apr 1999 13:30:17 -0700
oops, 2nd trivial example ... also from '95.

one of the web/browser companies had developed a lot of code that would support server's doing web financial transactions. they had done all the straight-line function and extensively stress-tested the code.

I went in with a failure-mode grid of 30-40 conditions and 4-5 states and required that the server being able to recognize and take some appropriate action (although as mentioned ... things like half-open session traps were outside the capability of the infrastructure and needed recommendations for other approaches for handling).

In any case, there was essentially 4* as much effort to try and turn the application into a service-quality implementation as went into the straight-forward base function.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Living legends

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Living legends
Newsgroups: alt.folklore.computers
Date: 18 Apr 1999 09:45:31 -0700
well then what are 013, 813, A13 ...

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 18 Apr 1999 09:55:18 -0700
Joel Winett at Lincoln did a number of early RFCs ... somewhat related to the '67 ... unfortunately most of them aren't online:
109 Level III Server Protocol for the Lincoln Laboratory NIC 360/67 Host, Winett J., 1971/03/24 (12pp)
110 Conventions for using an IBM 2741 terminal as a user console for access to network server hosts, Winett J., 1971/03/25 (4pp) (Updated by 135)
147 Definition of a socket, Winett J., 1971/05/07 (2pp) (.txt=6438) (Updates 129)
167 Socket conventions reconsidered, Bhushan A., Metcalfe R., Winett J., 1971/05/24 (7pp) (.txt=7643)
183 EBCDIC codes and their mapping to ASCII, Winett J., 1971/07/21 (15pp)
393 Comments on Telnet Protocol changes, Winett J., 1972/10/03 (5pp) (.txt=9435)
466 Telnet logger/server for host LL-67, Winett J., 1973/02/27 (8pp)


--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Enter fonts (was Re: Unix case-sensitivity: how did it originate?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Enter fonts (was Re: Unix case-sensitivity: how did it originate?
Newsgroups: alt.folklore.computers
Date: 18 Apr 1999 13:40:37 -0700
re: 6670 stories & off topic;

in 77/78 time-frame, 2 of the 3 people responsible for GML, the person responsible for the internal network, and I transfered from 545 tech sq (csc) to sjr.

into the 6670 line-driver went the obvious support using the alternate paper draw to print the file-seperator page (typically loaded with green or blue paper). To make the file-seperator page a little more interesting ... a feature called "6670 sayings" was added ... where the line driver randomly selected a quotation that was printed following the file ownership information.

SJR was having a security audit ... and the auditors were roaming around buildings after hours looking to see if there was classified information left out. One of the areas of interest was the 6670 output rooms to see if there was classifed information printed and left out (not immediately picked up). On the top of one 6670 was a pile of output ... the top file having a seperator page with the definition of an auditor being a person that goes around the battlefield after a war stabbing the wounded. The auditor took it as personal insult & that somebody had placed it on top the 6670 specifically to make a statment about the character of auditors. Some amount of time was spent trying to identify the individual responsible for the insult to auditors.

Lots of stuff used to be sent to me (back in the late '70s when global networking was new & fresh it was exciting to be processing hundreds of messages a day, ... as an example somebody had sent me the fortran source for adventure that compiled on cms ... within three months of adventure showing up at stanford ... one corporate type once claimed that they had statistics that for some months they could blame me for upwards of 30% of all traffic on all links on the whole internal network).

One year, the last week in march, somebody from an unnamed east coast location sent me a "corporate memo" dated April 1st (which was on sunday) that claimed to be a corporate password security memo outlining 10-15 rules for password selection. The memo concluded that there was only a single alphanumeric string that met all the criteria and each individual was to contact their local security officer to obtain that password. The first thing Monday morning (april 2) ... all the corporate bulletin boards in the building had a copy of the memo printed on corporate letterhead (and i wasn't responsible and/or had prior knowledge).

By noon, quite a storm was brewing ... not withstanding the content of the memo ... the date of the memo (april 1st) ... or that the date was sunday (and corporate memos are never issued on sunday) ... a very large percentage of people didn't realize it was an april 1st memo, and got quite angry when it was pointed out. After much investigation, the final outcome was that all corporate letterhead paper was to be moved from open shelves in the 6670 print rooms to locked cabinets.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Internet and/or ARPANET?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 18 Apr 1999 14:39:01 -0700
re: multics/cms ... off topic;

with respect to tom's comments at http://www.multicians.org/thvv/360-67.html about one of the reasons that multics started on the new file systems being poor comparison with cp/67 ... taking hour to restart the system (mostly in recovering the file system) ... while cp could crash 27 times in a single day ... restart and still have people getting useful work done.

cms filesystem made all filesystem changes to blocks that were written to "versioned/new" locations ... and then at periodic syncs the single MFD block would be rewritten which reflected the new locations for changed filesystem blocks. Except for one problem ... the filesystem on disk was alwas consistent ... it was either the old version (before the MFD was rewritten) or the new version (after the MFD was rewritten).

There was a file system scramble problem if there was a power failure exactly at the instant the MFD was being written ... there could be scrambled bits in the MFD (there were no intermediate disk buffers ... all data being written was coming directly from processor memory, there would be sufficient power to complete the write ... but not enuf power to maintain processor memory ... could to result in disk writes with trailing zeros in a block ... and valid CRC ... i.e. no error indication on read).

In the 70s, a cms enhanced file system was done that had a pair of MFD record locations that writes would ping/pong to (that fixed the power failure write problem). On restart, both MFDs would be read, checked for consistency and then the consistent MFD for the most recent version would be used.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Fault Tolerance

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Fault Tolerance
Newsgroups: comp.arch,alt.folklore.computers
Date: 18 Apr 1999 17:31:06 -0700
both my wife and I had done mainframe cluster stuff in the 70s and then in the 80s ran skunkworks where we did HA/CMP and fiber-channel scaleup (precursor to SP1/SP2, was going to start at 128-way). you would be surprised at the people now espousing clusters that we had to battle with at the time.

one of the bag of tricks for ha/cmp was ip-address take-over ... required that MAC addresses be aged out of the client ARP-caches. Turned up a bug in reno/tahoe (a lot of the products/systems then were built on reno/tahoe) ... the IP code had a one-address MAC as a special speed-up ... if new packet was the same ip-address as the previous ip-packet ... it would use the previously saved MAC address and not call the ARP code.

for some common client sysems that frequently interacted with a single server over & over ... the ip/mac address would never change regardless of the rules/processes flushing the ARP-cache. work-around was for ha/cmp to ping all clients it could find ... from a totally different ip-address ... in order to get the ip routine to change the hidden MAC address.

then there are counter examples. in the late 70s, i was also playing around in the disk engineering labs ... they had all these mainframe processors dedicated to disk testing (and were significantly under-utilized). If they tried to do concurrent testing of multiple test-cells (there was lots of security around disk development ... final level being individual units in small steel-mesh cages ... maybe 4' sq and 7' high with combination locks ... called test-cells) under an operating system ... it had MTBF of about 15 minutes (engineering disks tended to have some rather random & severe error modes). I redesigned and rewrote input/ouput supervisor so that it would never fail ... even if there were 6-12 test cells as well as normal operating system use happening concurrently. The resulting code was actually smaller than when I started (as well as much shorter path length). Of course the secret was that the code had evolved incrementally over a number of years ... and it was way overdue for redesign and cleanup.

The upside ... were the processors were maybe 5% used ... even with dozen test cells ... and the other 95% could be put to interesting uses. The downside ... I had to learn something about disk engineering ... when the disk testing didn't produce the correct results ... it wasn't uncommon for the operating system to be blamed ... I would have to go in and figure out what and heck they were doing.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Modem history [was ba.b: Re: Gender Gap's Wildest Show!!! Tonight!!!]

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Modem history [was ba.b: Re: Gender Gap's Wildest Show!!! Tonight!!!]
Newsgroups: ba.broadcast,alt.folklore.computers
Date: 18 Apr 1999 23:10:51 -0700
from alt.folklore.computers, re: Internet and/or ARPANET
17 Apr 1999 10:16:03 -0700
About the same time (late '68) ... a couple of us at the university built a replacement (using our own minicomputer) to replace the 2702 communication controller (which is supposedly credited with originating the ibm OEM controller business). One of the reasons was that we had original thot it was possible to dynamically associate different line scanners with different lines (i.e. dynamically determine protocol at time of modem connection on dial-up lines). It turned out it almost work except IBM had taken short-cut and hardware strapped the oscillator to a line ... so dynamic switching of line scanner worked as long as all protocols operated at the same bit rate. In any case, one of the things we implemented was strobbing of bit raise/lower signal to support dynamic speed recognition.

we didn't have more than 110-134.5-150 to test against at the time ... however, strobbing was at about ten times the 150 rate ... so might have work at higher rates.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Living legends

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Living legends
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: 19 Apr 1999 07:11:01 -0700
re: 001;

there was one of those darn things sitting on file cabinet next to the 709 (serial #2?) ... never had to use it tho except to fiddle with it while i was waiting for something else.

what i don't have a strong recollection of ... but wasn't there something of similar shape that CEs used on 360 capacitor ROM

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Living legends

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Living legends
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: 19 Apr 1999 07:23:18 -0700
how 'bout all those little tools in the CE toolkit for working on selectric typewriters ... I ordered a CE tooklit once because I wanted to keept a set of tools in my office for working on things ... but maybe half of the stuff in the briefcase i never used (it also took me several weeks to week the order accepted ... apparently you just don't have people ordering one of those things).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

When did IBM go object only

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When did IBM go object only
Newsgroups: alt.folklore.computers
Date: 21 Apr 1999 22:00:54 -0700
VM/CMS would ship the exact source that created the running system build.

there is the story about a request for the exact source that corresponded to (any) particular running system for MVT (applies to mvs & vse later). supposedly it was decided to be infeesable when the running cost estimate exceeded $10m (and climbing) ... even for a one time effort. there apparently was no straight-forward way of correlating the program listings cut for microfiche and the shipped executable code.

one of the significant dates was june 23rd, 1969 ... that was the unbundling of services. Prior to that date, IBM tended to have large numbers of people at customer sites, helping the customer get their work done. The result frequently was the creation of applications that were useful to the customer (since they evolved with close participation of the customer to meet the customer needs) ... at least HASP (JES2), ASP (JES3), IMS, and CICS originated from such customer environments. june 23rd, 1969, IBM started billing the customer for all time these ibm'ers spent with the customer ... and the sense of joint, close-cooperation evaporated.

There is somewhat offhand comments that the real IBM development groups were the customer shops ... where new (successful) application creation and development actually occured. Such applications were then frequently transferred to IBM Development organizations (which actually didn't originate or develop things ... they were responsible for maintaining things and keeping them running over the years after they had been developed someplace else).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Living legends

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Living legends
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: 22 Apr 1999 09:25:40 -0700
my first programming job when I was a sophmore was to effectively write my own stand alone operating system that replaced the 1401 MPIO (unit-record<->tape) front-end process for 709 ... with a 360/30.

The 360/30 replaced the 1401 and the 7track tapes, 2540reader/punch, and 1403 printer were moved from the 1401 to the 360/30. I designed & wrote my own task switcher, interrupt supervisor, device drivers, command functions, storage manager, buffering, etc. Was eventually about a box of cards (around 2000 360 assembler statements).

The easy stuff was the BCD stuff since EBCDIC was a superset ... the harder stuff was the binary ... since it was 36bit word rather than 32bit word ... and the cards could punch all 12 rows (which was invalid in 360, a column with all 12 holes punched couldn't be represented in a single 360 8bit byte). The 360 compatibility devices had a column binary feature that would map 80 columns of data into 160 (360) byte positions.

The standard for reading cards ... was to do a read/fead/select stacker ... all in a single operation. The problem was knowing ahead of time whether a card was bcd or binary. To get around the problem, you had to do a card read (no fead) in standard ebcdic ... and if there was an error, reread the card in column binary. What I tried to do was to be able to do the buffer/tasking necessary to do card->tape at full card reader speed while concurrently doing tape->printer at full printer speed.

I look back now ... what I wrote then is about the size of what is going into some of the smaller chipcards.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Living legends

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Living legends
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: 22 Apr 1999 12:07:36 -0700
all of my 360 cards from the 60s and 70s are green

... i have a 360/67 specific card that is blue ... but i don't have any 360 cards that aren't green.

i have some 370 cards from the 70s that are yellow.

long ago I did an ios3270 version of the green/yellow card ... which should translate easily into html (i don't have a copy ... maybe somebody else does).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Living legends

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Living legends
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: 22 Apr 1999 12:30:02 -0700
a side question ... does anybody know if the service processors are still vm machines running cms ... with all the service screens IOS3270.

the first such service processor implemenation of that was 3090 ... with two repackaged 4361s (for redundancy) ... both running a modified version of VM/370 release 6 and all the service screens done in cms IOS3270.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Living legends

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Living legends
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: 22 Apr 1999 19:36:40 -0700
these are the display interface or the service processors?

the service processors contained the diagnostic logic and probe connections into the machine to diagnose failing characterisitcs (or do the machines even have a separate service processors). The modified 4361s had modifications so that they had special hardware probes into all parts of the machine to diagnose hardware failures and identify things like what part should be replaced.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

System/1 ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/1 ?
Newsgroups: alt.folklore.computers
Date: 01 May 1999 17:51:54 -0700
sure you don't mean series/1 ... someplace I had around the original "peachtree" specification document ... before it shipped to customers. it had a tremendous interrupt architecture and numerous people tried to get it designated the mainframe telecommunication controller (instead of the uc.5/37xx ... uc.5 was also used in the ibm 8100 and various other controllers).

the "official operating system" was called RPS ... the joke was that the former MFT group from kingston moved to boca and wrote MFT a 2nd time around ... it was difficult since peachtree was a 16bit minicomputer and cramming MFT into the machine didn't really go well.

the comingly used system for the Series/1 was EDX which was done by some physicists at ibm san jose research for the process control & lab instrumentation environment. S/1 picked up quite a bit of the ibm 1800 and ibm system/7 market segment.

IBM palo alto center ported both unix and locus to s/1 in 80s.

The S/1 started seeing use in the 80s for telecommunication operation. A T1 card was also done for the S/1 in the 80s for telecommunication environment. The 37xx couldn't touch the T1 speed ... and the only official controller supporting T1 was 2701 from the 60s ... and was getting a quite long in the tooth. In any case, S/1 started to see a lot more use in the telecommunication area thru the 80s.

in serveral cases it competing against a perkin/elmer box that was being sold as a telecommunication controller (which traces a lineage back to some undergraduate work some of us did in the 60s).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old naked woman ASCII art

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old naked woman ASCII art
Newsgroups: alt.folklore.computers
Date: 01 May 1999 18:09:52 -0700
PASC had done unix & locus ports to S/1 and some other platforms.

PASC then started on a project to port BSD to ibm mainframe/370.

This was going on in parallel with the austin work to retarget the 801/ROMP from the word processor market to the unix market. system was going to be called AIX, basically system V vIII but built on top of a hypervisor layer that looked like it was left over from the word processor effort ... called VRM. This is somewhat analogous ... but totally different from the AT&T work that ported unix on top of TSS/370.

part way thru all this ... PACS/ACIS decided to retarget the BSD port from mainframe/370 to the PC/RT ... calling it AOS.

Eventually, the mainframe port was revisited by the PASC/ACIS people ... but using Locus as the base ... which resulted in AIX/370 (and its companion AIX/PS2 ... both from the Locus base).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Old naked woman ASCII art

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old naked woman ASCII art
Newsgroups: alt.folklore.computers
Date: 02 May 1999 07:48:01 -0700
oh yes, AOS trivia

now what was the C-compiler on AOS and why?

there was work going on to do 370 backend for various compilers by a guy in STL. part way thru the activity ... he left and joined a small compiler company in santa cruz.

a couple months later the BSD->370 port was launced. first couple weeks working out the details for the port ... I convinced the group to talk to guy that had left and was in santa cruz (since he was probably the most experienced and was most likely to provide 370 backend on the shortest possible schedule). In any case, that compiler was well integrated into the operation of the project by the time it was decided to redirect the effort from a 370 port to a PC/RT port.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

System/1 ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/1 ?
Newsgroups: alt.folklore.computers
Date: 02 May 1999 08:44:03 -0700
"Andrew McLaren" writes:
It was alleged that the Series/1 was superior to the 3705 as a communications controller - but since there was never a port of NCP for the Series/1 I duno how this was reckoned. However, when IBM announced Unix for the s/370 (AIX/370), the Series/1 showed up as a controller for remote terminals.

It could have been a early precursor to real-time RISC computers, in a parallel universe .... :-)


... note that series/1 implementation was not just NCP/PU4 ... but also SSCP/PU5 ... both running on the same series/1 with lots of additional features not found in standard NCP/PU4-SSCP/PU5.

the port to RIOS would have been a screamer. we had actually did some work earlier on such configuration using blue iliad (first 32-bit 801, contemperary of 16-bit ROMP 801, but never made it much past first silicon) for such a purpose. we had tentatively targeted an '88 FCS for the RIOS version.

the port to RIOS would have also opened up a whole slew of additional new features that were then being constrained by the available S/1 addressing & memory

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

System/1 ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/1 ?
Newsgroups: alt.folklore.computers
Date: 02 May 1999 08:44:03 -0700
there was a port of NCP to the series/1 ... actually it was re-implementation of the NCP function on series/1 ... bascially both PU4 and PU5 emulation done on series/1 ... the "inside" of the network was then peer-to-peer packet ... there was a 3705/ncp emulation board done for mainframe channels ... and then the series/1 emulated pu5 cross-domain support to the vtam/pu5 running on the 370 host.

there was also a project to port the whole infrastructure to RIOS base.

however ... misc pages from old overheads giving the series/1 to 3725 comparison:


System verses 3725NCP System:

• Higher availability
• More reliable
• More function
• Improved Useability
• Non-IBM Host Support
• Much better connectivity
• Much better performance
• Fewer components
• Easier to tune
• Easier to tailor
• Easier to manage
• Less expensive

a typical operation was taken and configured & costed for both 3725 and the series/1 based system. configuration was multiple distributed datacenters with large end-user population with realistic distribution (from actual measured data at customer shops) of messages going to "owning" host ... as well as to other hosts in the environment. The peer-to-peer internal packet networking was more reliable than the sessions maintained by VTAM. The Series/1 would replicate the session end-point and then could dynamically route the actual message flows. Except for the end-points to the user's desk ... the infrastructure was no single point of failure. The 3725 configuration was less available ... since 80% of the terminal sessions were cross-domain ... both the "owning" 3725 and the "owning" SSCP/PU5/VTAM had to be available for session setup (in addition to the end-points). It was possible to roll-in configuration updates into the Series/1 on the fly w/o taking anything down. Configuration updates in the 3725 infrastructure typically involved taking everything down and updating both the 3725 and VTAM configuration and then restarting (and hoping that everything worked ... or you would have to reverse the process).

3725 is more expensive

• 3725 configuration is operating at saturation.
- 80 3725s chosen for minimal acceptable
   connectivity and availability
- Configurator rates the 3725 at 60 messages/sec.
   for this type of activity.
• There are 2700 terminal messages a second
• 95% of messages are forwarded (processed twice)
• Configuration needs to handle 5265 messages/sec (1.95*2700)
• 5265/80 = 66 messages/sec

3725 is more expensive

• System requires 117 3725s to handle load
- Maintain average operation at 75% capacity
 - 45 messages/sec is 75% capacity
- 5265/45 = 117 3725s

• Configuration needs a 47% increase
- 3725s increase from 80 to 117
- 19.2kb links increase from 760 to 1112
 - 19.2kb modems increase from 1520 to 2224
- Costs increase from $25.7m to $37.8m

System is less expensive

• $14.2m for System hardware + $120k for modems
 - $11.5m 20 8-plex S/1 nodes @ $573k
. Duplex S1 (two processors) @ $90k (*4=$360k)
  . Lines/duplex @ $39k (*4=$157k)
. Host interfaces/duplex @ $11k (*4=$44k)
. A400 interface/duplex @ $3k (*4=$12k)

 - $1.8m for 40 A400 @ $45k
- $900k for 20 A715 @ $45k
 - $120k for 20 T1 modems @ $6k

The port to RIOS would have increased processor power by orders of magnitude. Also, the emulation software was really starting to bump its head against the 16bit addressing (as well as available real memory) of the Series/1. Numerous new functions for the emulator were being severely restricted because of the addressing & memory constraints.

Of course, Raleigh wasn't very happy with this. They weren't very happy with me as an undergraduate when I worked on the original telecommunication clone (credited with originating the ibm OEM controller business). This was potentially as/more significant. misc. 360 pcm posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

The Melissa Virus or War on Microsoft?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Melissa Virus or War on Microsoft?
Newsgroups: alt.folklore.computers
Date: 02 May 1999 14:58:55 -0700
we used cluster analysis in the early '70s for a product called vs/repack that would do instruction/memory trace of a program and then re-organize the program for improved virtual memory operation. could be looking at hundreds of millions of data points for typical instance, would also look at number of different kinds of runs to see if program execution was sensitive to data being operated on.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

System/1 ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/1 ?
Newsgroups: alt.folklore.computers
Date: 03 May 1999 09:13:25 -0700
... as an aside ... at least for 3277s ... a FIFO box was built where you unplugged the keyboard from the head ... plugged the box into the head ... and then plugged the keyboard into the box ... and fixed the type-ahead problem. the other hardware modification that could be done to the 3277 was fast cursor.

pvm also had a ascii->3270 emulator ... which was software running on the host ... i was running 3101 (glass teletype) from home with pvm 3270 emulator by mid '80 (pvm was a mainframe telnet-like function)

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Series/1 as NCP (was: Re: System/1 ?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Series/1 as NCP (was: Re: System/1 ?)
Newsgroups: alt.folklore.computers
Date: 06 May 1999 06:41:15 -0700
oops ... not '85, '86 ... COMMON Spring '86 Conference (session 43U, Series/1 As A Front End Processor by John Erickson).

SSCP EMULATION

• Emulates PU5 host SSCP (System Services Control Point)
• Supports SNA cross domain protocols
• Support provided for following RU types:
  - ER-OP, NC-ER-OP, ER-INOP, NC-ER-INOP
- NC-ER-ACT, NC-ER-ACT-REPLY
  - NC-ER-TEST, NC-ER-TEST-REPLY, ROUTE-TEST, ER-TESTED
- NC-ACT-VR, NC-DACTVR
- ACTCDRM, DACTCDRM, SDT, CLEAR, RQR, CDTAKED, CDTAKEDC
- CDINIT, CDCINIT, CDTERM
  - CDSESSF, CDSESSST, CDSESSTF, CDSESSEND
- INIT-OTHER-CD, TERM-OTHER-CD
  - DSRLST, BINDF, UNBINDF
• Handles start-up, shut-down, and control for SSCP-SSCP sessions
• Uses cross domain protocols to control terminal to host sessions
• Supports multiple explicit and virtual routes
• Uses virtual route pacing to prevent buffer overflow
• Can emulate multiple SSCPs to bypass MAXSUBA problems
• Supports both ENA and Pre-ENA addressing
• Uses DSRLST to obtain host application status

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

High Availabilty on S/390

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Availabilty on S/390
Newsgroups: bit.listserv.ibm-main
Date: 09 May 1999 12:40:46 -0700
denisb@interlog.com (Denis Belton) writes:
I have been tasked with providing 7/24 availability or as near as possible on the S/390 server platform. Environment is 9671 RB6 under OS/390 V2R6. There are no plans to implement parallel SYSPLEX.

I plan to inventory the reasons why we currently do IPLs and attempt to eliminate or reduce them. Other areas to investigate are dynamic LLA and LPA, dynamic I/O config using HCD.

Any other suggestions would be most appreciated. Thanks in advance.


when my wife was con'ed into going to POK to be responsible for loosely-coupled ... she origanted the peer-coupled shared data architecture that was eventually the basis for IMS hot standby and then parallel sysplex.

later when she & I were running the skunk works turning out high availability cluster multiprocessing product ... I got a chance to author a section in the corporate continuous availability strategy document ... unfortunately both the rochester and the POK groups non-concurred with the section as not being able to be met (by them).

recently one of the large financial settlement infrastructures credited the two primary things contributing to them having 100% availability for the last six years are
• ims hot standby
automated operator


i.e. as other kinds of failure modes have been dealt with ... operator "failure modes" have started to become significant percentage of all failures

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

IBM/computer chronology

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: IBM/computer chronology
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Followup-To: alt.folklore.computers
Date: 17 May 1999 09:58:11 -0700
following picked up from bit.listserv.ibm-main


http://www.isham-research.demon.co.uk/chrono.txt

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

The Chronology

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Chronology
Newsgroups: bit.listserv.ibm-main
Date: 18 May 1999 11:33:03 -0700
370/195 also had some instruction retry .. some business case about MTBF and total number of components in box.

there was also a project that looked at implementing dual i-stream on an otherwise normal 195 (would have two PSWs, two sets of registers, .... but only one pipeline execution unit ... but would have everything in the pipeline tag'ed). the problem was that for majority of applications, the 195 pipeline could never be kept full because of pipeline stall/drain conditions. Having two i-streams had better chance of keeping the pipeline full.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Read if over 40 and have Mainframe background

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Read if over 40 and have Mainframe  background
Newsgroups: bit.listserv.ibm-main
Date: 18 May 1999 14:32:02 -0700
we had big problem with a pair of 168s cross-connected in shared disk pool ... one 168 dedicated to large mvs and one dedicated to large vm/cms.

the rule was to never mount a mvs 3330 pack on a vm "owned" controller ... because vtoc & pds searches totally destroyed interactive response.

one day a mvs pack was mounted on a drive on the vm side of the configuration ... and within 15 minutes started getting irate calls from users complaining about severe performance degradation.

the mvs operator said it was a long running job and couldn't stop it &/or remove the pack

the vm crowd brought up a virtual VS1 on the heavily loaded VM system and mounted its packs on a MVS string ... and started some interesting virtual vs1 jobs (running under vm) ... doing various kinds of vtoc & pds searches ... that brought the real MVS system to a crawl ... so that the CMS users no longer noticed degradation from the MVS vtoc & pds search activity.

i actually had to shoot a similar problem at a large MVS customer shop that had six interconnected 168s and 3033ws all running MVS and sharing a common program library. performance was great most of the time ... but periodically it would have severe performance slow

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Read if over 40 and have Mainframe background

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Read if over 40 and have Mainframe  background
Newsgroups: bit.listserv.ibm-main
Date: 18 May 1999 17:20:13 -0700
.... oops, finger slip

large corporation with operations in nearly every state ... half dozen 168s & 3033s all running MVS sharing the same disk pool. Large program library ... most of the time performance was really great ... but periodically things would slow to almost a stop. They had been looking at the problem for several months when I got called in.

they had a class room with dozen tables ... pretty much covered with performance reports stacked a foot high on all the tables. After a couple hrs ... the correlation with good and bad performance was somewhat tenuous ... there was little or nothing out of the ordinary in the CPU reports and the disk I/O rates to some 50-60 drives ... except I noticed a slightly funny drive that nominally had 3-4 disk i/os per second under almost all cases ... but had aggregate disk I/O rate of 6.5 disk I/Os per second when system was under heavy load.

Looking at the drive in more detailed ... it contained the shared program library for all of the complexes ... with a 3.5 cylinder PDS directory. Turns out that under heavy load ... all the systems were doing multi-track search on the 3330 PDS directory ... 19 tracks, 60 revs/sec ... 19/60 seconds elapsed time per search I/O operation. Typically what would happen is there would be 3 searches per second plus 3-4 record reads per second (aggregate of 6.5 disk I/Os peak I/O rate across all the machines).

The problem is the 19/60 second I/O busied out the drive, controller, and channel. When I came back from this one ... I started strongly campaigning for a improved structure that didn't use multi-track search. I did a prototype ... but I think STL quoted me $26million to integrate and ship it to customers ... so had to come up with something that wasn't obviously something completely different (or do it in a very contrived and complicated manner ... costing significantly more over a very long period of time ... rather than trivial striaght forward).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Mainframes at Universities

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframes at Universities
Newsgroups: alt.folklore.computers
Date: 23 May 1999 09:49:43 -0700
CMS on 360/370 was much more interactive growing up out of the CTSS heritage.

TSO grew much more up out of the CRJE heritage (originally RJE ... remote job entry ... basically card images sent over a network ... and then effectively card images entered from a terminal for conversational remote job entry). I had done an early CRJE hack on HASP running on MVT18 at university ... supporting teletypes and 2741s ... basically I ripped out the 2780 support out of HASP (in part to get addressability and storage) ... and replaced it with 2741 and TTY support ... along with the syntax from the CMS conversational editor (not much code from CMS was directly usable ... since it was all single treaded and the HASP code had to be at least re-entrant and multi-treaded).

for some related RJE info ... see RJE at
http://www.garlic.com/~lynn/rfcterms.htm

there were a number of 360/370 CRJE type implementations ... basically all giving terminal user access to OS support services ... but they were rarely considered serious time-sharing.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Are mainframes relevant ??

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Are mainframes relevant ??
Newsgroups: bit.listserv.ibm-main
Date: Mon, 21 Jun 1999 23:48:59 GMT
while undergrad ... i added 2741 & tty support to HASP-III running on MVT18 and implemented the CMS editor syntax for doing CRJE stuff (actually I ripped out the 2780 support in order to gain some addressability in order to stuff in the 2741, tty, and the editor stuff).

later on my wife got con'ed into leaving the JES2 group in gburg to go to POK to be responsible for loosely-coupled ... created peer-coupled shared data ... eventually became the basis for ims hot standby and then parallel sysplex.

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

Mainframes Relevant?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Mainframes Relevant?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 21 Jun 1999 23:54:57 GMT
Y2K is even worse on embedded systems ... seems like a lot of chips that needed intervals ... used clock circuits instead of doing interval circuit

story about somebody set the clock on their video camera to 2000 and the thing opened the tape door ... but wouldn't shut it. they set it off to be repaired and got it back 3 months later with a note saying "don't do that again".

wonder if there are car engines that will have y2k problems

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

Authentication in eCommerce applications

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Authentication in eCommerce applications
Newsgroups: comp.security.misc
Date: Fri, 18 Jun 1999 19:00:36 GMT
X9.59 is draft standard by the financial industry standards organization for all account based payments in all (electronic) environments ... i.e. web, point-of-sale, settop boxes, etc. It specifically defines a signed payment object ... but does include something that is defined as the hash of purchase order ... providing binding of the payment authorization to something like a purchase order (it doesn't sign the purchase order ... it signs something that authorizes payment for the purchase order ... with a binding to that purchase order ... which ... in effect ... signs the purchase order ... although indirectly).

at point-of-sale it implies a hardware token capability supporting the digital signing of the payment object.

for related info ... see

http://www.garlic.com/~lynn/

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Authentication in eCommerce applications

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Authentication in eCommerce applications
Newsgroups: comp.security.misc
Date: Fri, 18 Jun 1999 23:17:04 GMT
... also ... slightly related ... there is IOTP work going on in IETF and other activities ... however
To: Robert Hettinga <rah@shipwright.com>
cc: dcsb@ai.mit.edu
Subject: Re: Interoperable Micropayment Order

Note that there is an X9 draft standard for all account-based payments in all electronic environments (web, point-of-sale, set-top, etc) ... X9.59. X9 is the financial industry standards body and the US interface to ISO for financial standards.

I had proposed & did a draft version of the underlying authentication model for IETF standardization. However, there was intense push to (also) process it as an X9 standard ... regardless of any possible standardization effort in other bodies (including IETF). In part, the use of X9 (and/or ISO financial) standards by financial institutions meets due diligence requirements that aren't characteristic of standards done by other bodies.

for reference there is description at
http://www.garlic.com/~lynn/

For help on using this list (especially unsubscribing), send a message to "dcsb-request@ai.mit.edu" with one line of text: "help".


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

Perfect Code

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Perfect Code
Newsgroups: alt.folklore.computers
Date: Tue, 22 Jun 1999 20:23:22 GMT
the call/entry to iefbr14 would be

l    r15,address iefbr14
balr r14,r15

which enters iefbr14 with r15 set to the iefbr14 entry point and r14 with the caller's address after the branch & link reg. instruction.

from ibm-main, courtesy of deja.com


> Forum: bit.listserv.ibm-main
> Thread: JCL-Question
> Message 2 of 4
Subject: Re: JCL-Question
Date: 1997/10/02
Author: John Wolf <wolfjc@IBM.NET>

In <3431BCC3.A4D4F3B6@cpuperform.com>, on 09/30/97
at 08:00 PM, Bob Halpern said:

IEFBR14 has more apar activity than lines of code.
1. As stated below, to do the SR 15,15 before the BR 14.
2. To be marked re-entrant (I used it to stub off some modules
for testing, and got 17 copies of a rather large module before
the 80A. I did the second apar.

John Wolf wrote:
>
> > ----------
> >>
> >> >Can IEFBR14 really set a return code or do you have a modified IEFBR14
> >that
> >> >verifies the DSN's?
> >> >
> > --snip--
> IEFBR14 is the ONLY one instruction program, that I know of, that had an
> APAR made up for it. Way back like ten years ago IBM changed how R15 was
> setup on return and BR14 started to give non zero return codes. This of
> course changed how some JCL streams worked.  So IBM had to change BR14 so
> that it zeroed out R15 before it returned via R14.
> -----------------------------------------------------------
> wolfjc@ibm.net
> -----------------------------------------------------------

As has been pointed out to me I misspoke. The first cut of IEFBR14 had ONLY ONE
instruction in it BR R14.
When IBM fixed it they ADDED a SR R15,R15 before the BR R14 so the return code
would be zero. IEFBR14 does NOTHING but send your JCL through allocation. The
resulting data set,assuming you are allocating a new dataset, will not be opened and
therefore will not have any DCB stuff set up ie: LRECL BLKSIZE RECFM.

--
-----------------------------------------------------------
wolfjc@ibm.net
-----------------------------------------------------------

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

"Pirates" -- what about Paul Allen?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: "Pirates" -- what about Paul Allen?
Newsgroups: rec.arts.tv,alt.folklore.computers
Date: Sun, 27 Jun 1999 16:39:29 GMT
i remember when the chuck-e-cheese open'ed just off blossom hill (circa 79/80?). It was the after hours place for the spring vmite conference in 80(?).

later they bought the toy store (with the giant toy soldier) at the corner of 101 and king for corporate hdqtrs (replaced the soldier with giant chuck-e-cheese).

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

"Adventure" (early '80s) who wrote it?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: "Adventure" (early '80s) who wrote it?
Newsgroups: alt.folklore.computers
Date: Fri, 09 Jul 1999 20:22:39 GMT
i got a mainframe fortran copy within 3 months of adventure appearing (by a somewhat circuitous route ... went from stanford to the UK back to the states and finally to san jose). I made the binary available on the internal network ... and would send the source to people that had completed the 300 pts. Within another six months somebody sent me back a PLI source version with something like 450 pts.

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

"Adventure" (early '80s) who wrote it?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: "Adventure" (early '80s) who wrote it?
Newsgroups: alt.folklore.computers
Date: Fri, 09 Jul 1999 20:24:53 GMT
oh yes ... this had the 100 move limitation if being played between 8am-5pm.

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

Perfect Code

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Perfect Code
Newsgroups: alt.folklore.computers
Date: Fri, 09 Jul 1999 20:46:36 GMT
one of the uses of iefbr14 could have condition code check ... set by sr r15,r15 (or xr)

nominally SR/XR would be faster than LA ... except in some machine specific cases. there have been all sorts of examples ... when I was doing CP/67 ascii support ... I found something like a IC/IC/STC/BXLE loop was nominally faster than the EX/TR instruction on the 360/67.

which brings up lots of the system exploits that I consider attributable to the C programming convention for strings being null terminated ... instead of having explicit lengths as in most of the mainframe cases. Uses of explicit lengths seems to have established convention that results in significantly lower buffer-overrun bugs ... which at times seems to be over half of the basis for internet intrusions/exploits.

with respect to the EX/TR & BXLE loop stuff ... the loop would either have to preprocess the string to obtain the length ... or embed a compare/branch ... in environments where string length isn't explicitly carried with the string.

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

1401 Wordmark?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: 1401 Wordmark?
Newsgroups: alt.folklore.computers
Date: Fri, 16 Jul 1999 15:51:47 GMT
it was possible to put-up prepare on older terminal controllers ... 2702/2703 ... and achieve the same benefit of allowing the cpu meter to coast to a stop. one of the major turning points in cp/67 for 24x7 services was having prepare in the terminal CCW sequence on 2702/2703 ... which allowed the CPU meter to coast to a stop (if there was no activity). this single characteristic changed a lot of shops from 1st shift operation to four shift operation (that and some stuff having to do with automatic re-ipl and some of the original automated operator support).

i don't remember the coasting interval on 360s ... but the coasting interval on 158/168s was 400ms ... i.e. if the processor had a timer driven daemon that woke-up every 400ms ... if even for only a couple hundred instructions the cpu meter would never get the chance to go idle.

one of the break-thrus was having dynamic adaptive daemon intervals related to workload ... rather than static build-time values.

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

1401 Wordmark?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: 1401 Wordmark?
Newsgroups: alt.folklore.computers
Date: Fri, 16 Jul 1999 15:57:20 GMT
the 1st shift to four shift ... also was enabler for the cp/67-based (and later vm/370 foloow-on) time-sharing services ... allowing them to go 7x24 world-wide.

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

FIne-grained locking

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: FIne-grained locking
Newsgroups: comp.arch
Date: Mon, 19 Jul 1999 00:39:39 GMT
for some things in the early 70s i address things a different way with what I called a bounce lock ...

basically there was

"long" locks on a processes

"medium" locks on various services link specific kernel functions

compare&swap instructions for either locking &/or queue management

this was back in the days when I was working with the guy who invented compare&swap (i.e. a couple of use spent 2-3 months coming up with a mnemonic that was his initials CAS)

In any case ... coming into kernel code with kernel resource request ... it would use compare&swap to obtain/test the lock ... if the lock failed ... the code dropped the process into a queue waiting for that resource and the processor went off to look for other work.

It was an interesting trade-off ... since it sacrificed the cache locality associated with the process ... for the cache locality of the kernel resource function (i.e. when the specific kernel function completed current activity it would check to see if it had any queued process requests before actually exiting).

it allowed smp'ing a uniprocessor kernel by putting medium locks around various functions ... and not having to rewrite them for fine-grain smp operation. it reasonably worked up thru eight to ten-way w/o causing either lots of rewrite of the kernel and w/o having hardly any lock contention (request if it failed would bounce off the held lock, queue the request and go on to other work).

For the workload and the machine characteristics of the time the process-line/kernel-line cache sacrifice was beneficial ... with efficiency of the overall system actually going up ... the processor that fell into executing specific kernel code functions was actually running faster since because of cache locality improvements ... and the balance was such that the other processors didn't starve because of any possible bottleneck queueing up (and it was major, significant improvement over various processors spinning on lock contention). Part of the success was extremely light-weight queueing mechanism against the contended for lock/resource.

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

FIne-grained locking

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: FIne-grained locking
Newsgroups: comp.arch
Date: Mon, 19 Jul 1999 15:48:15 GMT
charlie a. salisbury ... this was late 60s, early 70s.

an interesting requirement put on getting compare&swap into processor architecture was writing a description of how compare&swap could be used in uniprocessor machines (a description that went into principle of operation book as programming notes). this gave raise to description of various methods of using compare&swap in multi-threaded application code on uniprocessor machines.

current version of that document:
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/CCONTENTS

along the way both a single-word and double-word versions of the instruction was introduced so the CAS mnemonic got corrupted to CS & CSD. Following specific &/or pointers
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/7%2e5%2e23

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

CPU's directly executing HLL's (was Which programming languages)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: CPU's directly executing HLL's (was  Which programming languages)
Newsgroups: alt.folklore.computers,comp.arch
Date: Mon, 26 Jul 1999 17:09:38 GMT
Palo Alto Science Center did the 370/145 APL microcode for APL/CMS ... speeded up APL execution by factor of 10* or so .... would give 370/145 APL better performance than 370/168 APL (vague recollection that it was done by Randy Scarboro)

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

Documentation query

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Documentation query
Newsgroups: alt.folklore.computers
Date: Mon, 26 Jul 1999 17:16:04 GMT
donw thru CSC side ... madnick did SCRIPT on CMS ... that had period/two-digit-codes ... then the G/M/L guys added GML to SCRIPT ... which also begat SGML ... which begat HTML, XML, etc.

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

MVS vs HASP vs JES (was 2821)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: MVS vs HASP vs JES (was 2821)
Newsgroups: alt.folklore.computers
Date: Thu, 29 Jul 1999 20:42:40 GMT
HASP was done in Houston by Simpson, Crabtree et, al

I worked on HASP starting with OS release 11 ... up thru OS release 18 (HASP-III). One of the things was putting in CMS edit syntax as well as 2741 & TTY support for early form of CRJE support.

there was also ASP (asynchronous spooling program) done out on the west coast.

Migrating HASP into the IBM official product (instead of TYPE-III program) ... group finally landed in G'burg and HASP was renamed to JES2. The G'burg group also eventually picked up ASP ... renamed to JES3. My wife worked on JES2 & JES3 in the g'burg group until she was con'ed into going to POK to be responsible for loosely-coupled (she originated peer-coupled shared data ... original basis for IMS hot standby ... and then parallel sysplex).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

MVS vs HASP vs JES (was 2821)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: MVS vs HASP vs JES (was 2821)
Newsgroups: alt.folklore.computers
Date: Sun, 01 Aug 1999 03:59:01 GMT
posted here previously .... work I did as undergraduate ... presented at fall share meeting in Atlantic City.

the university was running studant fortran jobs on 709... tape-to-tape ibsys ... with 1401 providing front end unit-record<->tape support. I believe thruput was in jobs per second.

initial conversion to OS Release MFT 9.5 on 360/67 (running in 65 mode) resulted in changing from jobs per second (on 709) to minutes per job (on 360).

adding hasp got the times to around 20-30 seconds per job i.e. w/o hasp system was running synchronous unit-record input (card-reader) ... processed by the compiler and almost as each card processed ... synchronous unit-record (printer) output. HASP provided asynchronous processing for the unit-record gear ... allowing "jobs" to be run effectively at asynchronous buffered disk-to-disk speed.

However that was still slower than the 709 with ibsys & fortran monitor running tape-to-tape.

waterloo introduced a fortran monitor (watfor) that would accept multiple student jobs for compile and execution ... and would do it very efficiently ... and finally we started to see fortran student workload thruput on the 360 surpase the 709.

--


OS Performance Studies With CP/67

OS              MFT 14, OS nucleus with 100 entry trace table, 105 record
in-core job queue, default IBM in-core modules, nucleus total
                size 82k, job scheduler 100k.

HASP            118k Hasp with 1/3 2314 track buffering

Job Stream      25 FORTG compiles

Bare machine    Time to run: 322 sec. (12.9 sec/job)
times        Time to run just JCL for above: 292 sec. (11.7 sec/job)

Orig. CP/67     Time to run: 856 sec. (34.2 sec/job)
   times        Time to run just JCL for above: 787 sec. (31.5 sec/job)

                Ratio   CP/67 to bare machine
2.65    Run FORTG compiles
2.7     to run just JCL
2.2     Total time less JCL time

1 user, OS on with all of core available less CP/67 program.

Note:  No jobs run with the original CP/67 had ratio times higher than
the job scheduler. For example, the same 25 jobs were run under WATFOR,
where they were compiled and executed. Bare machine time was 20 secs.,
       CP/67 time was 44 sec. or a ratio of 2.2. Subtracting 11.7 sec. for
bare machine time and 31.5 for CP/67 time, a ratio for WATFOR less
       job scheduler time was 1.5.

I hand built the OS MFT system with careful ordering of
cards in the stage-two sysgen to optimize placement of data sets,
       and members in SYS1.LINKLIB and SYS1.SVCLIB.

                     MODIFIED CP/67

OS run with one other user. The other user was not active, was just
available to control amount of core used by OS. The following table
gives core available to OS, execution time and execution time ratio
for the 25 FORTG compiles.

CORE (pages)    OS with Hasp            OS w/o HASP

104             1.35 (435 sec)
 94             1.37 (445 sec)
74             1.38 (450 sec)          1.49 (480 sec)
 64             1.89 (610 sec)          1.49 (480 sec)
54             2.32 (750 sec)          1.81 (585 sec)
44             4.53 (1450 sec)         1.96 (630 sec)

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

MVS vs HASP vs JES (was 2821)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: MVS vs HASP vs JES (was 2821)
Newsgroups: alt.folklore.computers
Date: Sun, 01 Aug 1999 17:26:29 GMT
re: hasp-II version 3;

okk .... hasp-i would work on pcp & mft ... and could take over the machine by modifying the svc new psw directly.

for mvt there was storage protection support and some misc. convention changes ... which required the installation of a TYPE-1 svc handler for HASP to assume the privileges it needed.

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

Early interupts on mainframes

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Early interupts on mainframes
Newsgroups: alt.folklore.computers
Date: Sat, 07 Aug 1999 18:12:43 GMT
one of the reasons that diagnose was chosen ... was that it was a supervisor instruction and the architecture book defined it as machine dependent ... i.e. it was unlikely to be used by any ... but very special purpose software ... and we could claim that a "virtual" machine was a specific kind of machine ... and therefor we were within the architecture book's "rules & regulations" when we claimed that a "virtual" machine was a specific kind of machine and had the latitude to define the operation of the diagnose instruction in the "virtual" machine environment.

mostly the use of diagnose instruction in CP/67 was to return time information (this was before s/370 which had a store clock instruction).

one of the path length profiles that I had done as an undergraduate was in i/o simulation and ccw translation. Since all of CMS's disk I/O was very predictable ... seek/search/tic/read-write, etc. I had implementated an "immediate" x'FF' CCW that would expand into the whole operation; and since CMS's disk supervisor was simulated synchronous ... control wouldn't return to the SIO until the disk I/o was complete ... and would store CC=1, csw stored (i.e. as if it was an immediate CCW I/O operation).

The 360 SIO (start I/O) could return cc=0 (operation successfully started), cc=1 (csw stored, effectively some sort of immediate operation), cc=2 (subchannel busy), cc=3 (device not available). Simulating a cc=1 ... allowed the operation to look immediate, eliminating the necessity for CMS to do a bunch of programming to enter wait state ... and then take a subsequent I/O interrupt.

the pathlength stuff I had done for MFT was only partial benefit to the CMS environment ... since CMS had very low priviledge instruction ratio ... except for I/O. The x'FF' CCW cut the ccw translation overhead as well as bunch of tasking, idle PSW loading, and subsequent interrupt simulation, etc. which showed significant improvement in CMS intensive environment. The development group converted this to custom simulation with a diagnose instruction (but effectively the same semantics) ... in part since x'FF' CCW op-code wasn't protected in any way ... but essentially had a sanctioned "charter" based on what was in the rules & regulations set down in the 360/370 architecture red book.

rather than repeat ... now have urls
http://www.garlic.com/~lynn/94.html#18
http://www.garlic.com/~lynn/94.html#20
http://www.garlic.com/~lynn/94.html#21
http://www.garlic.com/~lynn/94.html#27

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

IEFBR14 cookie from www.ibm.com

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: IEFBR14 cookie from www.ibm.com
Newsgroups: alt.folklore.computers
Date: Sat, 07 Aug 1999 20:43:53 GMT
in the early 70s, I named one of the modules in my performance enhancements DMKSTP ... having come out of the 60s with muscle cars and "the racers edge" ... and I was able to include it in the resource manager product in '76.

another iefbr14 reference ...
http://www.garlic.com/~lynn/99.html#81

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

Power4 = 2 cpu's on die?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Power4 = 2 cpu's on die?
Newsgroups: comp.arch
Date: Sat, 07 Aug 1999 20:54:15 GMT
older ibm design for two "processor" SMP ... where either processor could in fact utilize all hardware resources ... this is little over 25 years old (early '70s)

re:
http://www.garlic.com/~lynn/99.html#73 The Chronology

370/195 also had some instruction retry .. some business case about MTBF and total number of components in box.

there was also a project that looked at implementing dual i-stream on an otherwise normal 195 (would have two PSWs, two sets of registers, .... but only one pipeline execution unit ... but would have everything in the pipeline tag'ed). the problem was that for majority of applications, the 195 pipeline could never be kept full because of pipeline stall/drain conditions. Having two i-streams had better chance of keeping the pipeline full.


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

Early interupts on mainframes

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Early interupts on mainframes
Newsgroups: alt.folklore.computers
Date: Tue, 10 Aug 1999 02:52:56 GMT
"Don Chiasson" writes:

Edward Rice wrote in message ...
>..........
>
>Uh... polling is generally very inefficient and is avoided whenever
>possible.  An interrupt system (including faults) is designed into a system
>to /avoid/ polling, not to perform more efficient polling.
>
There can be other problems. In real time systems driven by
hardware interrupts if a device goes awry and generates a contunuous
stream of interrupts, the whole system may hang because no program
can get any processor time. Alternate scenario: interrupts are often
handled by pushing machine status on a stack. If the interrupt rate is
high or errors happen with errors the stack may overflow and crash the
system.
With a polling system, the program would test the device, note that it
is not working and then go on to the next device. In a benign world these
things do not happen.
Don

actually I did a variation on this for 370 cache machines in the mid-70s.

critical sections of the kernel ran disabled for all interrupts. prior to selecting some non-disabled work for execution I inserted a pair of instructions that enabled/disabled for interrups. This eliminated the uneccesary overhead of selecting and dequeueing some piece of work when there was interrupts pending that required other work.

recognizing that high rate of interrupts did terrible things to cache locality ... would monitor the I/O interrupt rate and if it exceeded some threshold for the machine ... the code dynamically switched normal workload from being enabled for all interrupts to being enabled for interrupts except I/O (and scheduled a timer event interrupt).

strategy that some I/O interrupts would be delayed for a small interval (than they would have been if normal workload ran enabled for all interrupts) ... and then the system would accept all pending I/O interrupts effectively in a batch. This would only kick-in when interrupts exceeded a threshold ... where the batch processing actually improved both the thruput of I/O interrupt handling as well as thruput of the workload processing (by improving the cache hit characteristics of both).

this was separate from the work done to "bullet-proof" I/O supervisor from things like hot interrupts as well as lost interrupt ... i.e.

http://www.garlic.com/~lynn/95.html#3
http://www.garlic.com/~lynn/99.html#31

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

The Translate (TR) instruction

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: The Translate (TR) instruction
Newsgroups: alt.folklore.computers
Date: Tue, 10 Aug 1999 20:27:48 GMT
in addition to the translate instruction there was translate and test instruction.

translate would take and input string and a 256 byte table ... each byte in the input string was used to index into the 256 byte table and then the value from the table would replace the byte in the input string.

the translate and test would take and input string and a 256 byte table and each byte in the input string was used to index into the 256 byte table and keep processing until it found a non-zero entry in the 256 byte table.

translate tables were available for most terminal types ... both "input" translate table and an "output" table ... used to translate from/to terminal character code & ebcdic.

ascii characters were peculiar because ibm controllers would process an incoming byte by storing leading bit in low order position in a byte before transferring the full byte to mainframe memory. as a result the ascii translate tables ... weren't actually ascii<->ebcdic translation but between ebcdic and "bit-reversed" ascii.

on many 360/370 translate&test was not a very well optimized instruction and it was frequently faster to perform the logic using a bxle loop.

misc. ref.
http://www.garlic.com/~lynn/96.html#37
http://www.garlic.com/~lynn/98.html#35a
http://www.garlic.com/~lynn/99.html#44

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

Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
Newsgroups: alt.folklore.computers
Date: Fri, 13 Aug 1999 01:49:50 GMT
there was possibly 5 levels of hardware indirection between the software and actual data. one of the nails was an analysis (I believe by the houston science center) that calculated that PARS application (precursor to ACP & TPF ... aka airline res. system) ... running on a 195-speed hardware implementing FS architecture would have thruput lower than PARS running on 370/145.

there were 12 or 13 areas/sections. at the time, my wife worked for person heading up one of the sections (inter-system coupling, before she went to pok with responsibility for loosely-coupled and did the peer-coupled shared data architecture) ... she had come out of UofMich engineering and thot that it was fantastic that every blue-sky idea that might possibly ever have existed was being discussed & considered.

On the other hand ... I thot resource management ... (chapter 8?) wasn't even up to the level of what I had deployed at the time. At the time, there was a cult film playing (non-stop for 13 years?) down the block in central square ... queen of hearts(?) (actually "king of hearts") ... it crossed my mind that it might be a case of the inmates being in control of the institution.

the other interesting thing was super-tight security around all the documents ... which were available online. One weekend, I had a machine room that contained a copy of the documents with all the super-tight security. They made a point of saying that they could leave me in the machine room by myself all weekend and I wouldn't be able to access the documents. I was able to show that in less than five minutes elapsed time that I had access to everything in the room.

... part of this was discussed before ... see one of my earlier postings here under "old manuals" at
http://www.garlic.com/~lynn/96.html

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

Future Cryptology

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Future Cryptology
Newsgroups: sci.crypt
Date: Fri, 13 Aug 1999 20:13:21 GMT
tomstdenis writes:
In article <7ov8e9$f6i$1@quine.mathcs.duq.edu>, juola@mathcs.duq.edu (Patrick Juola) wrote: > I don't believe that it's at all a good question; I'm not sure a > cryptosystem exists that will protect me from the NSA but not > from "thieves and pesky hackers [sic]."

That's not my point. My point was to stop focusing on stopping the NSA and focus on the real task at hand. I can't believe cryptograpers related to banking are thinking 'I wonder if the NSA can read these messages'. I bet they are thinking 'how much effort will it take for an attacker to forge transactions ...' or something like that.


as an aside the charter given the X9A10 working group for X9.59 protocol (for all account based transactions) was to preserve the integrity of the financial infrastructure for all electronic retail payments with just a digital signature. much of current use of financial cryptography is for message (transaction) authentication (independent of privacy issues).

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

IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
Newsgroups: alt.folklore.computers
Date: Sat, 14 Aug 1999 15:57:23 GMT
the 3081/3/4 (370s & beyond) has 64bit tod clock with bit 12 being a microsecond (although architecture didn't require that all/any machine actually provide microsecond resolution). that made bit 32 slightly more than a second. its epoch was first day of this century (i actually got to spend 3 months with some other people resolving what that was).

most groups initially set zero to 1970 ... rather than the start of the century (and the rest set it to a year earlier than the start of the century). with bit 32 slightly larger than a second (1024/1000), 2**32+ seconds (clock period) is almost 140 years ... with epoch at start of this century it carries well past year 2000.

for more detailed description of current 390 architecture (effectively a superset) see:
http://ppdbooks.pok.ibm.com:80/cgi-in/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/CCONTENTS

(although most of the time I find that this url is not operational on the weekend)

the guy that ran the FAA project went on to be president of IBM's FSD (now owned by loral) & then left and formed his own company. I believe he retired last summer.

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

IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
Newsgroups: alt.folklore.computers
Date: Sat, 14 Aug 1999 16:17:00 GMT
total aside ... 3083s were never intended to be built just 3081 and 3084. IBMs SMPs prior to the 3081 were two totally independent machines cobbled together ... so that the components could actually be unhooked and run as two independent processors. running as multiprocessor the machines were typically slowed down 15% of so to allow for memory contention resolution (and in cache machines to handle cache invalidation signals). when run as two independent processors the machines would run at full speed.

the 3081 was two processors in a single box ... it was not possible to partition it and run it as two independent machines. the 3084 was two 3081 tied together to make a 4-way SMP.

The initial 3081 ... 3081D was also only about 5mips per processor ... hardly showing any performance improvement over the 3033. It wasn't until the 3081K machines that it started to show over 7mips per processor.

ACP/TPF (airline res system) didn't have any SMP support (although they would take VM and could run two copies of ACP/TPF on 2-way system) ... the ACP/TPF market was looking for flat-out fast performance uniprocessor thruput ... which wasn't available on the 308x line. To satisfy the ACP/TPF market, a 3083 uniprocessor was built ... which immediately picked up a 15% processor hardware thruput (and somewhat reduced the cost of the 2nd processor which they couldn't effectively use ... but there was a lot of stuff done in the 3081 adding the 2nd processor w/o doubling the cost).

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

Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
Newsgroups: alt.folklore.computers
Date: Fri, 20 Aug 1999 15:29:28 GMT
the other problem was that the 3350 fixed head area didn't have a separate I/O transfer address ... if the single (logical) address assigned to the 3350 was busy doing arm motion ... it was not possible to do data transfers from the fixed head portion. I had a proposal similar to the multiple-exposure capability available on the 2305 (an all fixed head device) ... that supported eight logical request interfaces. The eight logical request interfaces could be used to help mask rotational delay ... i.e. with requests queued on all eight logical interfaces ... the first target that came under a rotating head would be serviced. In any case, any moderate use of the moveable arm on the 3350 would effectively make the fixed-head portion busy (& unavailable) over half the time.

The vulcan group was instrumental in getting the multiple-exposure 3350 proposal killed (perceived competitive threat) ... and then they were finally disbanded.

in another project (about the same timeframe) we collected significant amounts real live trace disk access data and simulated numerous caching strategies ... and a single global shared cache was alwas higher thruput than multiple sub-caches (i.e. a 20mbyte located at the processor and shared with all I/O devices was alwas more effective than 40 2mbyte caches spread out locally to each device). Of course this confirmed my work from the late 60s where global LRU for page replacement and working set management alwas outperformed the local LRU strategy documented in the working set literature of the time. The only caveat was a electronic track-line located at each rotating device that helped in rotational delay compensation (start reading data continuously from the current head position ... even if not at start of record, possibility that head is in the middle of the record desired so that when the head does come around to start of record it only has to transfer the data not yet read).

other reference ...
http://www.garlic.com/~lynn/95.html#8
http://www.garlic.com/~lynn/99.html#8

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

Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
Newsgroups: alt.folklore.computers
Date: Fri, 20 Aug 1999 15:36:10 GMT
... ok, there was 2nd caveat ... large data sequential operations that would wipe the global cache had to be managed (but that has alwas been true of global caches).

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

IBM Mainframe Model Numbers--then and now?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: IBM Mainframe Model Numbers--then and now?
Newsgroups: alt.folklore.computers
Date: Sat, 21 Aug 1999 00:34:16 GMT
uc.5 was the processor in the 8100 and the 3705 (and others) ... peachtree in the S/1 was much better processor and numerous of us attempted to get it designated the base for communication controllor

my wife is one of the ring patent holders on (chat) ring used by S/1.

related discussion:
http://www.garlic.com/~lynn/99.html#63
http://www.garlic.com/~lynn/99.html#66
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#69
http://www.garlic.com/~lynn/99.html#70

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

Computer History

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Computer History
Newsgroups: alt.folklore.computers
Date: Mon, 23 Aug 1999 15:57:10 GMT
other aspects of unattended computer operation was automated re-ipl (masking some of the failure types), automated operator, and the way off-shift time would be charged for
http://www.garlic.com/~lynn/99.html#86
http://www.garlic.com/~lynn/99.html#87
http://www.garlic.com/~lynn/99.html#72

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

IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
Newsgroups: alt.folklore.computers
Date: Mon, 23 Aug 1999 16:02:17 GMT
and what is really wierd is the 3090 service processors were a pair of (somewhat modified) 4361s running a highly modified copy of VM/370 release 6 (service panels were written in CMS IOS3270). Old VM releases did have a problem switching DT/ST ... but never seem to have had a problem with the year (unless this was some of the new service processor specific modifications).

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

OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
Newsgroups: alt.folklore.computers
Date: Tue, 24 Aug 1999 23:44:25 GMT
but CMS in 1971 still looked pretty much the same way it looked when it was implemented in 1966.

in 1969 i crafted the CMS editor syntax (along with 2741 and tty) support into HASP/MVT18 to provide a CRJE type implementations ... i.e. it was pretty straight forward to make a MVT based implementation have the look and feel of CMS (in 1968, I had also borrowed the LL 2250M1 libraries originally written for Fortran display aps ... and crafted them into CMS edit for a form of full-screen editor).

In terms of usage of CMS ... all of those developers weren't using VM so much for testing ... they were using CMS for editing, software development, email (the internal network was larger than Arpanet/Internet from pretty much the start up until sometime into the mid-80s with the majority of the nodes all VM).

possibly the people that specified TSO (as opposed to implemented) didn't use online computing of any kind (and TSO was a much more specification driven project)

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

OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
Newsgroups: alt.folklore.computers
Date: Tue, 24 Aug 1999 23:54:47 GMT
i recently ran across a internal network weekly update file on an old floppy disk ... example of activity. Frequently all changes only VM machines ...

•          Date Sent     1-21-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ LITVM             * SWPVM/C    158/VM    CHQ  White Plains, N.Y. 8-236-2207
+ MLVFSC3           * MLVFSC1/9  4331/VM   EMEA Marne LaValle, France
+ OWGVM3            * OWGVMX/4   3033/VM   FSD  Owego, N.Y.        8-662-3787
+ PISAVMSC          * ROMESC/4   4331/VM   EMEA Pisa, Italy        8-39-50-4783
+ PKVMWFB1          * PKSMRVM/9  4341/VM   DSD  Poughkeepsie, N.Y.
+ RCH38AD1          * RCHVMV/9   SYS38/S38 SPD  Rochester, Mn.     8-456-6297
+ SMAVMDP0          * SMAVM1/9   4341/VM   EMEA Sainte Marie, France
+ SMAVS33H          * SMAVM1/9   3033/JES2 EMEA Sainte Marie, France 38-825000
+ STLVM24           * STLVM10/9  4341/VM   GPD  Santa Teresa, Ca.
+ STLVM25           * STLVM10/9  4341/VM   GPD  Santa Teresa, Ca.
+ STUTVMX           * STUTVM1/C  3033/VM   EMEA Stuttgart, Ger.  49-711-7817-288
+ TORVM2            * TOROVM1/C  3033/VM   AFE  Toronto, Canada    8-942-6050
+ TUCVMTC3          * TUCVM3/9   4341/VM   GPD  Tucson, Arizona    8-461-4576
+ VIMVM01           * WINH6/4    168/VM    EMEA Vimercate, Italy
+ WELVMNZ1          * WTSCPOK/2  3033/VM   AFE  Wellington, New Zealand

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

The Translate (TR) instruction

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: The Translate (TR) instruction
Newsgroups: alt.folklore.computers
Date: Wed, 25 Aug 1999 17:41:20 GMT
i actually have possible/probable problem with the ibm TR for ASCII->EBCDIC.

In X9.59 mapping to X9.15, we are adding a binary field to a record that was previously all alphanumeric and regularly translated from ASCII->EBCDIC as in

http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/A%2e3%2e41?SHELF=

note that the typical IBM ASCII->EBCDIC translate tables have been bit reversed since the ibm line controllers have had a convention of storing the leading bit in the low-order bit position ... and ASCII transmits the leading bit from the high-order bit position (i.e. an ascii x'3F' would show up x'FC' im mainframe memory).

A possible problem is that some of the ASCII<->EBCDIC translate table sets are not reversible (not all ASCII characters occur in EBCDIC and not all EBCDIC characters occur in ASCII). Since IBM "TR" replaces the original data ... it can be impossible to recover the exact original binary data if incorrectly/inadvertently translated.

X9.15 is a subset of ISO8583 and is the typical protocol used to transmit point-of-sale (as well as mail-order/catalog-order and other) financial transactions.

X9.59 is the financial industry's draft standard for authenticating all account-based payments in all environments (point-of-sale, internet, settop, atm, credit, debit, etc) ... actually the charter is to preserve the integrity of the financial infrastructure for all electronic retail payments with just a digital signature.

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

OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
Newsgroups: alt.folklore.computers
Date: Thu, 26 Aug 1999 04:46:11 GMT
from the 83 file .... 1000 mainframes on the internal worldwide network 6/10/83.

•                     Date Sent     6-14-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ CPHVMCE           * CPHVM1/9   4341/VM   EMEA Copenhagen, Denmark
- CPHVMEC           * CPHVM1/9   4341/VM   EMEA Copenhagen, Denmark
•    I have just received word that CPHVMEC, the 1000th node that
• appeared 6/10/83 was the incorrect node name due to some misunder-
• standing in Copenhagen.   CPHVMCE is the correct name.

couple more samples from the 83 file

•                     Date Sent     7-29-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ BPLVM             * PKMFGVM/9  4341/VM   DSD  Brooklyn, N.Y.     8-868-2166
+ FRKVMPF1          * STFFE1/9   4341/VM   CSD  Franklin Lakes, NJ 8-731-3500
+ FUJVM1            * FDLVM1/4   3033/VM   AFE  Fujisawa, Japan
+ GBGMVSFE          * GBGVMFE3/C GUEST/MVS FED  Gaithersburg, Md.  8-372-5808
+ LAGVM5            * LAGM3/9    168/VM    CPD  La Gaude, France
+ LAGVM7            * LAGM1/9    3032/VM   CPD  La Gaude, France
+ MVDVM1            * BUEVM1/2   4341/VM   AFE  Montevideo,Uruguay 98-90-17
+ RALVMK            * RALVMA/C   4341/VM   CPD  Raleigh, N.C.      8-441-7281
+ RALVMM            * RALVS6/C   4341/VM   CPD  Raleigh, N.C.      8-227-4570
+ RALVMP            * RALVM2/C   3081/VM   CPD  Raleigh, N.C.      8-442-3763
+ RCHVM1PD          * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ RCHVM2            * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ RCHVM3            * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ SJMMVS16          * SNJMAS2/9  4341/MVS  GPD  San Jose, Ca.      8-294-5103
+ SJMMVS17          * SNJMAS1/9  4341/MVS  GPD  San Jose, Ca.      8-276-6657
+ TUCVMJ            * TUCVMI/5   148/VM    GPD  Tucson, Arizona    8-562-7100
+ TUCVMN1           * TUCVM2/C   4341/VM   GPD  Tucson, Arizona    8-562-6074
+ UITECVM1          * UITHON2/9  4341/VM   EMEA Uithoorn, Netherlands

•                    Date Sent    12-15-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ ADMVM2            * ADMVM1/9   4341/VM   EMEA Amsterdam, Neth.   20-5133034
+ BOEVMN            * BOEVM1/9   4361/VM   SPD  Boeblingen, Ger. 49-7031-16-3578
+ BRMVM1            * MTLVM1/9   4341/VM   AFE  Bromont, Canada    514-874-7871
+ DUBVM2            * RESPOND/4  3158/VM   EMEA Dublin, Ireland    785344 x4324
+ ENDVMAS3          * ENDCMPVM/C 3081/VM   GTD  Endicott, N.Y.     8-252-2676
+ KGNVME            * KGNVMN/C   3081/VM   DSD  Kingston, N.Y.
+ KISTAINS          * KISTAVM/9  4341/VM   EMEA Stockholm, Sweden
+ MDRVM2            * MDRVM1/9   3031/VM   EMEA Madrid, Spain      34-1-4314000
+ MSPVMIC3          * MSPVMIC1/9 4341/VM   FED  Minneapolis, Minn. 8-653-2247
+ POKCAD1           * PKDPDVM/9  4341/VM   NAD  Poughkeepsie, N.Y. 8-253-6398
+ POKCAD2           * POKCAD1/C  4341/VM   NAD  Poughkeepsie, N.Y. 8-253-6398
+ SJEMAS5           * SNJMAS3/S  4341/MVS  GPD  San Jose, Ca.      8-276-6595
+ TOKVMSI2          * FDLVM1/9   3031/VM   AFE  Tokyo, Japan

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

OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
Newsgroups: alt.folklore.computers
Date: Thu, 26 Aug 1999 15:23:51 GMT
another inhibitor to people using MVS as their standard platform on the internal network was the JES limitation in number of nodes that could be addressed.

HASP mapped pseudo unit record devices into a one-byte/two-decimal-digit indexed table. JES carried over this design ... and also used the same table for network nodes ... but expanded the limit to three-decimal-digits (but still one byte). This allowed support for up to 256 definitions ... combination of pseudo unit record devices plus network nodes. A typical JES implementation might have 40-60 pseudo unit record devices allowing for 200 or so network node definitions. Sometime after the internal network passed 1000 nodes, JES did increase the number of definition slots to 999 (from 256).

As a result, somebody on a MVS system only was able to send/receive mail & files with other nodes that happened to be defined in their local 200 node table (JES also had a feature of disposing of incoming files/email from sites not defined, w/o warning anybody).

Aggravating all of this was JES feature that changes to the network definition required new JES generation and a scheduled MVS system re-boot/ipl ... something that most operations only did once or twice a month (even if you could establish a critical need for communicating with a specific node ... it could take 2-6 weeks before the changes were made and system re-ipled).

JES network support also had a downside that it scrambled network, file and other fields in the header (as well as scrambling processing in the network driver) ... and small version-to-version changes in various header information could preclude any network interoperability ... and incoming files from out-of-synch JES systems could even lead to MVS system crashes (there was well documented case of San Jose GPD JES enhancements causing repeated MVS system crashes in Hursley). Typical configurations were to only have MVS nodes at end-node locations "protected" by intermediate VM systems with special VM network modifications to sanitize/convert header information that would be acceptable to specific JES systems.

VM from the start had cleanly separated out all the various fields and processing and had large family of different line & protocol drivers which were easily modified ... and VM was frequently used as intermediate processor for JES/HASP machines talking to each other. (i.e. A VM system might be required just to enable two different JES systems to exchange information).

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

What is the use of OSI Reference Model?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: What is the use of OSI Reference Model?
Newsgroups: comp.programming
Date: Sun, 29 Aug 1999 19:59:47 GMT
the OSI reference model (and federally mandated GOSIP in the late 80s and early 90s) in ISO was different from the IETF tcp/ip model.

one characteristic difference betwen ISO and IETF was that IETF requires at least two different interoperable implementations before becoming a standard ... ISO effectively requires a lot of people to vote on a paper description.

In late 80s ... trying to get high-speed protocol implementation thru ANSI X3S3.3 (ansi is US recognized standards body by ISO, X3S3.3 worries about matters corresponding to level 3&4 of the OSI model). To do high-speed ... some of the work effectively involved collapsing stuff in levels 3 & 4 ... which found hard slogging because of violation of levels 3 &4. Note this was despite the fact that IEEE803 LAN already accepted collapsing levels 0, 1 and part of 2

misc. references:
http://andrew2.andrew.cmu.edu/rfc/rfc1169.html
http://andrew2.andrew.cmu.edu/rfc/rfc994.html
http://www.ansi.org/
http://www.ieee.org/
http://www.ietf.org/
http://www.iso.ch/
http://www.scit.wlv.ac.uk/~cm1901/spos/comms/osirm.crit.html
http://web.archive.org/web/20020410124538/http://www.scit.wlv.ac.uk/~cm1901/spos/comms/osirm.crit.html

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

What is the use of OSI Reference Model?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: What is the use of OSI Reference Model?
Newsgroups: comp.programming
Date: Sun, 29 Aug 1999 22:15:57 GMT
there were significant number of people who were startled when TCP/IP prevailed over the federally mandated GOSIP (OSI).

with regard to high speed protocol ... it had several design points ... some

• a very thin layer in the kernel (osi level 4 or TCP) which would interface to HSP implemented in a chip ... which could talk directly to a LAN MAC layer (i.e. collapse almost all of OSI layers 0, 1, 2, 3, & 4).

• usable for transactions ... HTTP use of TCP/IP requires a minimum of seven packet exchanges ... HSP was designed to due the same in a minimum of 3 packet exchanges.

OSI (and to some extent early TCP/IP) had slow-speed, high-error rate, point-to-point copper design point ... predating fiber, satellites, FEC, encryption and LANs (vestiges even in TCP/IP with things like checksum in a header record).

HSDT (high speed data transport) project in the early and mid 80s was using satellites, fiber, fec (things like 15/16th reed-solomon), encryption (even something that looked similar to today's IPSEC/VPNs) and LANs.

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

IBM S/360 microcode (was Re: CPU taxonomy (misunderstood RISC))

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: IBM S/360 microcode (was Re: CPU taxonomy (misunderstood RISC))
Newsgroups: comp.sys.amiga.advocacy,comp.sys.amiga.misc,comp.arch
Date: Mon, 30 Aug 1999 18:01:31 GMT
the low end 370s tended to be verticle microcoded machines ... tended to look very RISC'y ... 145 avg. about 10 microcoded instructions per 370 instruction. higher end 370s were horizontal microcoded ... 165 was 80ns cycle machine ... slow main memory and avg. about 2.1 machine cycles per 370 instruction (assuming didn't take cache miss). The 168 had same cycle time, faster main memory and optimization & other stuff in the microcode reduced things to about 1.6 machine cycles per 370 instruction.

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

OS390 bundling and version numbers -Reply

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS390 bundling and version numbers -Reply
Newsgroups: bit.listserv.ibm-main
Date: Thu, 02 Sep 1999 22:48:42 GMT
i first heard bony fingers at share meeting in '70s (denver '77/'78?) at the HASP songfest ... with the words rewritten to apply to JES2. It was a C&W song supposedly written by cousin of one the JES2 committee members who got it rewritten for JES2 and performed by his cousin (at least that was the story i was told). I also remember KFAT playing the original periodically.

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

Schneier/Publsied Algorithms

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Schneier/Publsied Algorithms
Newsgroups: sci.crypt
Date: Sun, 05 Sep 1999 22:22:30 GMT
as i've possibly mentioned before ... the charter given the X9A10 working group for X9.59 (standard for all account-based payments, credit, debit, ACH, check, ATM, etc) was to preserve the integrity of the financial infrastructure for all electronic retail payments with only a digital signature (independent of privacy issues)

Eric Lee Green writes:
I'm primarily interested in encryption as a mechanism for protecting financial data from criminals, not as a political statement. In my

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

Computer, supercomputers & related

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Computer, supercomputers & related
Newsgroups: alt.folklore.computers
Date: Tue, 07 Sep 1999 15:59:52 GMT
from eugene in comp.benchmarks
To Sid:

I will always get a chuckle when reminded that you felt that the Cray Time Sharing System (CTSS, as distinct from the Cambridge Time Sharing System or the Compatible Time Sharing System) would have made a good VAX operating system along with the Trix editor. Sid passed away on the day he was to speak at a local ACM SIGBIG meeting. The VMS people would have had a great fit.

To George with whom I used to occasionally share an office one day a week here at Ames: thanks for the stimulating discussion and even bowing to the new generation for computists. Your contribution is undervalued by many. All of your friends remember you.

Additional, special mention:

Seymour Cray is unquestionably credited with making "supercomputer" a household word (which was apparently missed by some people in the mid-1980s).

To quote Nolan Bushnell, Cray embodies: Remember engineers drive the boat. We are here because of Seymour and others.

And Seymour is here because of Jim Thornton.


I didn't know Jim when he was doing computer architecture ... but in the '70s he formed Network Systems with Gary Cristenson and a couple others. I worked with them off & on from '80 up thru mid-90s. Gary was instrumental in getting the High Performance Storage System lab initially started at LLNL.
http://www.sdsc.edu/hpss/hpss1.html
http://web.archive.org/web/20021208040943/http://www.sdsc.edu/hpss/hpss1.html

misc. NSC references from my archives
http://www.garlic.com/~lynn/94.html#23
http://www.garlic.com/~lynn/94.html#24
http://www.garlic.com/~lynn/99.html#67

they had a product line was called HyperChannel ... which is gone (and there is now a new company called hyperchannel which is a ... what else? ... internet solutions provider).

NSC had initially done the (HyperChannel adapter) A720 in a project for my wife.

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

atomic History

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: atomic History
Newsgroups: alt.folklore.computers
Date: Thu, 09 Sep 1999 15:01:18 GMT
i knew american officer (taught at war college, there was article on him during desert storm about the current crop of cols. and majors as his jedi knights ... titled the fight to change how america fights) that spent a lot of time debriefing US, Russian, and Germans in the 50s ... one of his comments was that german tank corp had 5-to-1 kill ratio over the americans and the americans prevailed by throwing 10-to-1 numerical superiority at them (and that it was a conscious decision on the american government part to win by being able to absorb 5-to-1 death ratio) ... his observation was the strategic planners in washington didn't factor in the moral effect that had on the troops being sent in as cannon fodder.

German officers were predominately professional soldiers with army having something like 3% officers with philosophy of making a decision as low in the organization as possible. By comparison, US army was something like 11-17% officers and decisions were made as high as possible with lots of paper trail (he quoted Guderian's order going into the blitzkrieg as verbal orders only ... government auditors being prone to looking to place blame after a battle ... regardless of how well it went ... and Guderian wanted the man on the scene to make the decision w/o having to go back up thru a chain of command for CYA ... and not have to fear any reprisals if things that didn't go perfectly)

his belief was that US won the war because of the logistics management of huge amounts of cannon fodder.

he also observed one of the problems of american business during the 80s was that too many of the (commercial) business CEOs had gotten their strategic training on how to run an operation as army officers during WW2 (top-heavy management, rigid command and control, lots of CYA and push decision to highest level possible).

going forward to vietnam war ... he tells story about the air force air-to-air missile. At some point in its development he was giving a briefing ... they fed him all the specs and showed a film that the missile hit the target every time it was fired ... claiming at .99KP. At the end of the film he said that they had just told him that it would only have a .09KP (1/10th); they said that wasn't true ... he said replay the film ... at the point where the missile was just about to hit the drone ... he said stop the film and asked what kind of guidance does the missile have?; A: heat-seeking; Q: what kind of heat-seeking?; A: pin-point heat-seeking; Q: what is the hottest part of a jet plane?; A: the engine.

"No it isn't ... the hottest point is the plume 15-30 yards behind the plane ... the only time you will score a hit in air-to-air combat is if you happen to be shooting out the other guy's tailpipe ... which is only about 10%."

So sometime in the middle of vietnam ... one star air force in vietnam had all the fighters switch from air force missile to sidewinder (which had .2kp to .24kp ... better than twice what they found the air force missile to have). he lasted almost three months before being called on the carpet at the pentagon; he had violated a cardinal rule of the services ... budget share ... he had reduced the air force's budget share (fewer US planes being shot down and air force missiles weren't being used up) and increased navy's budget share (sidewinder was an navy missile).

another story was the F16 design ... the "official" plane was the F15 ... but he was doing the F16 design anyway. MD kept trying to shut him down and couldn't. Finally, president of of MD went to ass. sec. of def. and demanded that john be charged with theft of government property (plane designed required lots of supercomputer time ... and therefor john was obviously stealing government computer time worth millions of dollars) and thrown in Leavenworth for 20 years. An intense audit of all government supercomputers followed but after three months they gave up without finding a trace. Finally the person heading up the investigation went to john and said ok, we give up ... we know you are doing it but we can't find any evidence ... but by the way can you privately tell me how you are doing it.

misc. other reference from the past ...
http://www.garlic.com/~lynn/94.html#8

a book recently sent us about the asian side was "A Different Kind of War" by Miles.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Painting machines (the colour the customer wants)

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Painting machines (the colour the customer wants)
Newsgroups: alt.folklore.computers
Date: Fri, 10 Sep 1999 18:36:24 GMT
similar thread ....

Newsgroups: alt.folklore.computers
 From: lynn@netcom11.netcom.com (Lynn Wheeler)
Subject: Re: painting computers
 Date: Sun, 10 Apr 1994 16:21:48 GMT

it wasn't authorized, but CSC painted the disk drives in its machine
room (2nd floor 545 tech sq). There were five 8-drive 2314 strings and
a short 5-drive string. Each string was painted a different color so
that strings could be referred to by color for mounting/unmounting
disk packs.

--
Lynn Wheeler          | lynn@netcom.com, lhw@well.sf.ca.us

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Computer supersitions [was Re: Speaking of USB ( was Re: ASR 33 Typing Element)]

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Computer supersitions [was Re: Speaking of USB ( was Re: ASR 33 Typing Element)]
Newsgroups: alt.folklore.computers,alt.sys.pdp8,alt.sys.pdp11,alt.sys.pdp10
Date: Mon, 13 Sep 1999 14:33:32 GMT
jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
This worked in the mainframe time-sharing world as well. While running a computer-bound process some systems would drop your priority because of the lack of keyboard activity (with the Good Intention of improving response time for interactive users). Occasionally hitting the RETURN key would keep the process in the interactive queue, providing it more access to CPU cycles.

Joe Morris


but it lead to all sorts of pathelogical cases ... what i finally did was have the interactive queue change the granularity of the quanta and the deadline was proportional to smoothed average of recent resource use (cpu, page-space, etc) & the size of the quanta.

smaller quata made the deadline sooner ... and not using any resource made the deadline sooner.

one pathelogical case noticed early on with APL on early cp/67 was large memory useage and compute bound processing ... with people playing with the keyboard to increase their proportional cpu consumption. the change said that playing with the keyboard provided better response for interactive type stuff ... but wouldn't allow consumption of more than "fair" share of resources.

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

Speaking of USB ( was Re: ASR 33 Typing Element)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Speaking of USB ( was Re: ASR 33 Typing Element)
Newsgroups: alt.folklore.computers,alt.sys.pdp8,alt.sys.pdp11,alt.sys.pdp10
Date: Mon, 13 Sep 1999 15:43:21 GMT
re: networking use ....

following were two '96 posts in comp.infosystems in response to where did 3-layer architecture originate. these were my candidates for earliest proposal that I had made for 3-layer architecture.

http://www.garlic.com/~lynn/96.html#16

there is slight typo in the ... "<50mbit" should have been "<50kbit" ... i.e. 1044 support was getting mbyte+/sec sustained thruput using modest cpu on 4341 and standard support could get <50kbit/sec thruput nearly saturating a 3090 cpu.

http://www.garlic.com/~lynn/96.html#17

We use to go visit the corner office in somers of the guy that had repsonsibility for SAA ... the idea that the middle layer provided most of the adaptability and flexability support for the desktop ... rather than client/server, mainframe & SAA drove those guys up the wall.

one of the big issues back in 1988 was the identified support costs of all those desktops.

I actually had a different one earlier from 1983 which talked about intermediate distributed computers between the desktop and the backend mainframes ... but that was much more of a hierarchical ordering compared to the referenced 1988 flavor which was much more of a mesh.

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

Speaking of USB ( was Re: ASR 33 Typing Element)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Speaking of USB ( was Re: ASR 33 Typing Element)
Newsgroups: alt.folklore.computers,alt.sys.pdp8,alt.sys.pdp11,alt.sys.pdp10
Date: Mon, 13 Sep 1999 16:26:04 GMT
wasn't just crash free desktops ... but being able to quickly and easily adapt the desktop to individuals' requirements w/o affecting the integrity of the operation .... dynamic tension between availability/reliability (usually implied by more structure) and adaptability/flexibility (usually implied by less structure).

part of the middle layer proposal (original 3-layer architecture) included support for doing stuff to the desktop.

and ... of course ... my reference on adaptability/flexibility
http://www.garlic.com/~lynn/99.html#120
http://www.garlic.com/~lynn/94.html#8

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

Q: S/390 on PowerPC?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Q: S/390 on PowerPC?
Newsgroups: comp.arch
Date: Tue, 14 Sep 1999 01:00:53 GMT
Del Cecchi writes:
As some of you might know I work for a company that does not do 390 emulation on other hardware, as far as I know, although they did make a more or less bizarre attempt to do a 370 using a couple of 68000s modified and lashed together. It doesn't seem to have made much of an impact.

del cecchi


370 on the 68000s initially was going to go out with 384k byte memory which resulted in significant page thrashing for lots of applications. I got that increased to 512k byte for FCS (by some amount of benchmarking and page thrashing curves on pre-shiped boxes ... I also some other software page optimization code into the release).

The other problem was that a lot of the applications were relatively disk intensive ... which moving from 16ms (& less) disk technology to 100ms+ disk access technology (along with still quite a bit of page thrashing in the 512k byte memory space ... to the same 100ms+ disk technology) ... made it relatively painful to use ... except for all but the most tailored applications.

On top of that ... the pair of 68000s delivered well under 100kips 370 processing rate.

In the same time frame ... I tried to get a 2.5mip 370 processing rate with 2mbyte memory and <15ms disk technology.

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

Dispute about Internet's origins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Dispute about Internet's origins
Newsgroups: alt.folklore.computers
Date: Thu, 16 Sep 1999 19:40:16 GMT
significantly larger timesharing install during the late 60s and during the 70s; see
http://www.leeandmelindavarian.com/Melinda/

although some of the people doing early development in the mid-60s had previously also worked on ctss.

ignoring the actual customer install base, at various times during the 70s I was personally building & distributing to larger (internal corporate) install base than some of the other systems total customer install base.
http://www.garlic.com/~lynn/95.html#14
http://www.garlic.com/~lynn/96.html#35
http://www.garlic.com/~lynn/97.html#15

from the customer install base, the resource manager I released in spring of 76 (it was the first IBM "priced" SCP code ... I spent six months learning how to price operating system software), at a license fee of $990/month hit a 1000 licenses within six months of release (I don't know the total size of the customer install base ... just for some of the stuff I was involved in).

as mentioned before, the just internal network was larger than the arpanet/internet from effectively the start up into the '80s.
http://www.garlic.com/~lynn/99.html#112

which was also the basis for BITNET and EARN.

also
http://www.garlic.com/~lynn/99.html#52
&
http://www.garlic.com/~lynn/99.html#53

and my part of the earlier thread on parts of this subject.
http://www.garlic.com/~lynn/internet.htm

small extract from Melinda's paper ...
II. A BRIEF HISTORY OF VM

CTSS

In the beginning was CTSS, the "Compatible Time-Sharing System". CTSS was written by a small group of programmers at the Massachusetts Institute of Technology (MIT) in Cambridge, Massachusetts, under the leadership of Professor Fernando Corbato.

One of the CTSS programmers was Robert Creasy, who was later to become the leader of the CP-40 project. Papers discussing the idea of a time-sharing system began being published about 1959.

There followed a period of experimentation at MIT and other institutions. An early version of CTSS was demonstrated on an IBM 709 at MIT in November, 1961. From that beginning, CTSS evolved rapidly over the next several years and taught the world how to do time-sharing.

CTSS was developed on a series of IBM processors. In the 1950s, IBM's president, T.J. Watson, Jr., had very shrewdly given MIT an IBM 704 for use by MIT and other New England schools.

Then, each time IBM built a newer, bigger processor, it upgraded the system at MIT.

The 704 was followed by a 709, then by a 7090, and finally by a 7094. IBM also gave MIT the services of some highly skilled Systems Engineers and Customer Engineers, who formed its MIT Liaison Office, which was housed at the MIT Computation Center.

As CTSS evolved, Professor Corbato and his students and colleagues began to encounter problems that they knew were better addressed by hardware than by software, so they asked IBM for modifications to their processor. The IBMers in the Liaison Office had the job of finding engineers in Poughkeepsie to build the hardware extensions that MIT had determined were necessary to do time-sharing properly.

By the time CTSS was in full production in 1963, the 7090 at MIT had been modified to have a second memory bank (32K words), an address relocation register, and memory protection. With these extensions to the hardware, Corbato's group was able to build CTSS into the system that became the exemplar for time-sharing systems.


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

Dispute about Internet's origins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Dispute about Internet's origins
Newsgroups: alt.folklore.computers
Date: Thu, 16 Sep 1999 21:02:47 GMT
... from footnote in melinda's paper

From the preface to the "candy-striped manual" (F.J. Corbato, M.M. Daggett, R.C. Daley, R.J. Creasy, J.D. Hellwig, R.H. Orenstein, and L.K. Korn, The Compatible Time-Sharing System: A Programmer's Guide, The MIT Press, Cambridge, Mass., 1963): The only other general purpose time-sharing system known to be operating presently, that of the Bolt, Beranek and Newman Corporation for the PDP-1 computer, was recently described by Professor John McCarthy at the 1963 Spring Joint Computer Conference. Other time-sharing developments are being made at the Carnegie Institute of Technology with a G20 computer, at the University of California at Berkeley with a 7090, at the Rand Corporation with Johnniac, and at MIT (by Professor Dennis) with a PDP-1. Several systems resemble our own in their logical organization; they include the independently developed BBN system for the PDP-1, the recently initiated work at IBM (by A. Kinslow) on the 7090 computer, and the plans of the System Development Corporation with the Q32 computer. To establish the context of the present work, it is informative to trace the development of time-sharing at MIT. Shortly after the first paper on time-shared computers, by C. Strachey at the June 1959 UNESCO Information Processing Conference, H.M. Teager and J. McCarthy at MIT delivered an unpublished paper Time-Shared Program Testing at the August 1959 ACM Meeting. Evolving from this start, much of the time-sharing philosophy embodied in the CTSS system has been developed in conjunction with an MIT preliminary study committee (initiated in 1960), and a subsequent working committee. The work of the former committee resulted, in April 1961, in an unpublished (but widely circulated) internal report. Time-sharing was advocated by J. McCarthy in his lecture, given at MIT, contained in Management and the Computer of the Future (MIT, 1962). Further study of the design and implementation of man-computer interaction systems is being continued by a recently organized institution-wide project under the direction of Professor Robert M. Fano.

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

Examples of non-relational databases

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Examples of non-relational databases
Newsgroups: comp.databases
Date: Fri, 17 Sep 1999 19:15:33 GMT
IMS
related ..

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Availabilty on S/390
Newsgroups: bit.listserv.ibm-main
Date: 09 May 1999 12:40:46 -0700
> >
denisb@interlog.com (Denis Belton) writes:

> I have been tasked with providing 7/24 availability or as near as possible on
> the S/390 server platform. Environment is 9671 RB6 under OS/390 V2R6. There
> are no plans to implement parallel SYSPLEX.
>
> I plan to inventory the reasons why we currently do IPLs and attempt to
> eliminate or reduce them. Other areas to investigate are dynamic LLA and LPA,
> dynamic I/O config using HCD.
>
> Any other suggestions would be most appreciated. Thanks in advance.

when my wife was con'ed into going to POK to be responsible for
loosely-coupled ... she origanted the peer-coupled shared data
architecture that was eventually the basis for IMS hot standby and
then parallel sysplex.

later when she & I were running the skunk works turning out high
availability cluster multiprocessing product ... I got a chance to
author a section in the corporate continuous availability strategy
document ... unfortunately both the rochester and the POK groups
non-concurred with the section as not being able to be met (by them).

recently one of the large financial settlement infrastructures
credited the two primary things contributing to them having 100%
availability for the last six years are

• ims hot standby
• automated operator

i.e. as other kinds of failure modes have been dealt with ... operator
"failure modes" have started to become significant percentage of all
failures

--

Anne & Lynn Wheeler   | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/

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

High Performance PowerPC

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: High Performance PowerPC
Newsgroups: comp.arch
Date: Sat, 18 Sep 1999 05:12:44 GMT
Del Cecchi writes:
Well, ROMP stands for Research OPD Micro Processor, where OPD was Office Products Division, the division that owned Austin at the time. MMm Metal Gate NMOS. I forget if it had depletion mode loads.

And I stand by my story. I don't care what the geniuses say, ROMP was originally intended for a typewriter, and OPD killed the project. I didn't say who was designing the ROMP processor. Could have been Brad Dunham for all I know. The processor ended up in the Unix box whose name I can't remember.

And don't forget, Research will always tell about how they had something far superior to the stuff turned out by "the divisions" if only someone had picked it up.

del cecchi


I believe austin had romp set up to be a display writer follow-on. i vaguely remember the story was entry-level romp version was going to cost more than the top end of that market.

It was being written in PL.8 and at one point at something like 120 PL.8 programmers working on it (between austin and ykt)

To save the hardware/software project they decided to try the "new" unix game ... and got the company that did the IBM/PC unix to do one for Austin ... turning the wordprocessor into PC/RT.

The caveat was that the wordprocessor team already understood the hardware (but not C or Unix) and so were going to provide an machine abstration layer to the 3rd party unix developer (the VRM ... written in PL.8 by the wordprocessor team). The claim was that the 3rd party unix would be able to port to the VRM abstration layer faster than the real hardware.

The problem was that the VRM abstration layer introduced a totally different device driver model ... and had other problems ... so the port in fact took significantly longer than if the port had been to the bare hardware.

By comparison the Palo Alto AOS team ported BSD4.3 to the (PC/RT) bare hardware using less than 1/10th the people and 10% of the time that went into just the VRM (not even comparing the combined VRM+UNIX effort).

somewhat related:
http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/99.html#64
http://www.garlic.com/~lynn/98.html#25
http://www.garlic.com/~lynn/98.html#26
http://www.garlic.com/~lynn/98.html#27

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

early hardware

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: early hardware
Newsgroups: bit.listserv.vmesa-l
Date: Thu, 16 Sep 1999 18:19:27 -0700
my first (studeent summer) programming job was re-implementing 1401 MPIO on 360/30.

University had a 709/1401 pair where the 1401 did tape<->unit record front end for the 709. My job was to re-implement the MPIO program on the 360/30 ... where the same (1401) unit record gear had been switched (I designed my own device drivers, interrupt handler, multitasker, storage manager, console/command interface, etc). The 1403/2540 were moved from the 1401 to the 360/.30 (and the 1401 retired) ... until I got the 360 version running, the 360/30 ran the 1401 MPIO program in 1401 emulation mode.

Boeing formed BCS Jan. 1969 and that spring they con'ed me into giving a one week computer class for the BCS technical staff (i was still undergraduate and taking classes ... but they wanted me to teach the BCS technical staff a computer class). I was then hired for the summer as a full-time, supervisor level grade employee. I rented part of a house from one of the 747 test engineers (you could see 747 serial #3 periodically flying over seattle ... and the 747 "sales" group had a mock up and a write up that 747 carried so many passengers that they would be never serviced with anything less than four jetways).

That fall, I was a full-time BCS employee on educational leave of absence, a full-time student, and a IBM time-slip employee (all at the same time). IBM had a beta-version of the first CICS installed at the university and my job was to debug it and get it running.

'69 was the last summer I was in Seattle until last May when I came back to work with a company to do the X9.59 reference implementation.

there recently has been quite a bit of early hardware discussion on alt.folklore.computers ... especially with respect to time-sharing, ctss, and early 7090/7094.

Anne & Lynn Wheeler lynn@garlic.com http://www.garlic.com/~lynn/

early hardware

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: early hardware
Newsgroups: bit.listserv.vmesa-l
Date:    Fri, 17 Sep 1999 23:01:48 -0700
re: teaching computing systems at boeing ....

IBM also had me teach part of a one week class the summer before down at some IBM ed center location near beverly hills hilton. Also, I periodically had evening time at the IBM datacenter (on university in seattle) and they would let me help with the MVT class.

some related stuff in that period (including part of presentation I gave at Atlantic City share in '68):
http://www.garlic.com/~lynn/94.html#1
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/94.html#18
http://www.garlic.com/~lynn/96.html#9
http://www.garlic.com/~lynn/96.html#10
http://www.garlic.com/~lynn/96.html#39
http://www.garlic.com/~lynn/99.html#44
http://www.garlic.com/~lynn/99.html#76
http://www.garlic.com/~lynn/99.html#77

Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com http://www.garlic.com/~lynn/

Q: S/390 on PowerPC?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Q: S/390 on PowerPC?
Newsgroups: comp.arch
Date: Tue, 21 Sep 1999 16:12:12 GMT
there is electronic check presentment project with the FRB & others here in the states ... deploying POS terminals that handle the paper integrated with other kinds of card processing (credit & debit) ... however that still leaves settlement.

somewhat related:
http://www.garlic.com/~lynn/99.html#71

slightly related
http://www.garlic.com/~lynn/95.html#11
http://www.garlic.com/~lynn/95.html#13
&
http://www.garlic.com/~lynn/aadsm3.htm#imicro
http://www.garlic.com/~lynn/aadsm2.htm#integrity
http://www.garlic.com/~lynn/aadsmail.htm#comfort

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

EBCDIC binary Conversion Question

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: EBCDIC binary Conversion Question
Newsgroups: bit.listserv.ibm-main
Date: Tue, 21 Sep 1999 19:15:13 GMT
the mainframe telecom ebcdic<->ascii translate tables (btam, qtam, etc) were flaky because the ibm controllers assumed the leading bit went into the low-order bit position ... while tty/ascii stuff put the leading bit in the high-order bit position (i.e. incoming telecom ascii streams in mainframe memory appeared bit reversed). All of this was futher complicated because 7bit ascii could be no-parity, odd-parity, or even-parity (i.e. the 8th/parity ascii bit could be zero or one when it appears in mainframe memory depending on no-parity, even-parity, or odd-parity).

so ebcdic<->ascii translate tables depends not only on parity ... but whether or not they are on the mainframe side and are taking into account the difference in transmission convention.

slightly related:
http://www.garlic.com/~lynn/95.html#14
http://www.garlic.com/~lynn/96.html#30
http://www.garlic.com/~lynn/98.html#2
http://www.garlic.com/~lynn/98.html#34
http://www.garlic.com/~lynn/99.html#99

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

Computer supersitions [was Re: Speaking of USB ( was Re: ASR 33

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Computer supersitions [was Re: Speaking of USB ( was Re: ASR 33
Newsgroups: alt.folklore.computers
Date: Tue, 21 Sep 1999 19:50:15 GMT
in early 70s for vm/370 we did a user level "INDICATE" command that gave smoothed system average of cpu utilization, real memory utilization, paging rate, and "expansion" ... ( (queuing delays) + use) / use

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

sysprog shortage - what questions would you ask?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: sysprog shortage - what questions would you ask?
Newsgroups: bit.listserv.ibm-main
Date: Wed, 22 Sep 1999 01:25:40 GMT
cp/67(precursor to vm/370;vm/esa;etc) was generated as card deck and had a modified copy of the BPS loader in front ... so that it could be IPL'ed from cards ... or card image on tape & IPL'ed from tape. The CP/67 card deck image would load itself into memory and then write itself back out to disk ... from which it could be ipl'ed normally.

BPS (basic programming system) had lots misc. card stuff ... loader was required to load stuff from standard cards. There was also a trick with "3card loader" and BPS program that would generate ipl'able card image decks. This was the process that was used to generate the BPS loader ... but could be used on programs other than the loader.

All of the card stuff worked ipl'ing real cards ... or card images on any tape drive.

CP/67 (and virtual machine follow-ons) also had to simulate the hardware IPL process on devices that the real hardware supported IPL. By version 3 of CP/67 very few people were punching real cards ... they were punching virtual cards and running the production sysgen process in a virtual machine ... and/or writing the card image to tape.

This was also the process used thru-out VM/370 ... although the modifications to the original BPS loader got a little more extensive.

somewhat related
http://www.garlic.com/~lynn/94.html#11
http://www.garlic.com/~lynn/94.html#15
http://www.garlic.com/~lynn/98.html#9
http://www.garlic.com/~lynn/99.html#9

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch
Date: Wed, 22 Sep 1999 03:13:31 GMT
... from the archives ... I don't remember if the number was from an FRB report or a FSTC report.

------------------------------


From: Lynn.Wheeler@xxxxxxxx
Date: Mon, 25 Jan 1999 13:47:12 -0800
Subject: Re: UCC attribution procedures

note that financial industry draft standard payment standard x9.59
postulates securing any retail payment transactions (credit, debit,
atm, etc) with just a digital signature ... w/o requiring encryption
of any data ... and can do this for all electronic payment
environments (including point-of-sale) and reducing the level of fraud
in all environments that it is used (actually says something about
preserving the integrity of the financial infrastructure for all
electronic retail payments with just a digital signature)

the issue then is the amount of fraud reduction & infrastructure
improvement greater than the cost of the infrastructure change.  one
such benefit postulated (including the epay/check example) is the
infrastructure costs of processing a paper check is significantly
higher than the cost of an x9.59 debit transaction (there is a
slightly correlated fraud assumption ... that w/o a paper check,
random people can't arbritrarily make withdrawals from you checking
account).

there is a strong desire to eliminate all paper check processing, one
claim is that current paper check processing in the US represents a
(unjustifiable?) noticable percentage of the GNP.

the issue isn't just that electronic things need to be done just
because of the advent of the internet ... but also that the internet
can help be a catalyst as well as reduce some of the deployment costs
for transition to digital signed electronic transactions that have
additional justifications.

i also like to think that the x9.59/aads community was one of the
first to highlight the distinction between prior & no-prior business
relationships in relationship to electronic transactions.

Please respond to Digital Signature discussion <DIGSIG@LISTSERV.TEMPLE.EDU>

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 23 Sep 1999 01:32:45 GMT
with respect to running legacy applications on PC hosted virtual machine, see
http://www.garlic.com/~lynn/99.html#17
http://www.garlic.com/~lynn/99.html#24
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#100
http://www.garlic.com/~lynn/99.html#103
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/96.html#29
http://www.garlic.com/~lynn/96.html#35
http://www.garlic.com/~lynn/94.html#2

with respect to PARS from above reference, it was the precursor to ACP (airline control program) which evolved into todays' TPF (transaction processing facility) ... which forms the basis of a number of the airline res. systems.

with respect to using legacy code hosted on various PC platforms ... there may be various price/performance considerations favoring the PC platform ... but the legacy system attributes offer various advantages (pre-existing function, automated operator infrastructure, etc). For existing applications, the use of less expensive components to host the application may be an attractive alternative to rewriting (as in reference above regarding airline res "routes" rewrite).

With regard to check processing costs in the US ... large percentage of the checks are monthly bill mailings. The paper processing includes biller receiving the envelope, opening the envelope, transcribing the paper information, transporting the check to the commercial bank, commercial bank processing the check again. If the check isn't drawn on the same bank ... the check then has to be forwarded to the bank (there is a national clearing center where lots of planes from all over arrive late at night ... trucks take the paper to the sorters, they sort for a couple hrs and the trucks take the paper back to the planes ... and the planes return ... supposedly something like half of the high-end check sorters in the world are there), when the checks finally get to the consumer bank then they have to be sorted again (at least once more), microfilm, and in some cases stored so that they can be returned to the originator.

One of the problems with early high-end check sorters were they required real-time interrupt processing ... special modifications to operating system had to be done to support handle real-time interrupts.

some trivia ... there was previous activity to map 370 to 801 ... something like 15 years ago ... called fort knox ... i helped author report that killed it.

given price/performance & feature/function ... how somebody chooses to deploy their legacy applications should be straight forward business decision.

another trivia ... what is the connection between:
http://www.garlic.com/~lynn/internet.htm

& demise of RP3?

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Mainframe emulation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Mainframe emulation
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 24 Sep 1999 02:35:02 GMT
there are lots of mainframe programs that don't require 4-5 nines availability ... and could be retargerted to platforms with other types of characteristics ... assuming the price/performance and feature/function made sound business sense.

i know of one place that had developed a 407 accounting package ... and it was ported to a 1401 emulating a 407 (plug boards, sense switches, etc) ... which was then ported to a 360 mainframe emulating a 1401 emulating a 407 ... and eventually upgraded to a 370. question of whether the program ran correctly or not was based on the emulated 407 sense switches that was printed on the last page of output. after many years if the sense switch printout was not what they were accustom to .. they just reran it.

there are very broad range of applications running on existing mainframes with a very broad range of availability & reliability requirements. claims about there being a single, homogeneous class of mainframe requirements for all mainframe applications are false.

Mainframe emulators can make very sound business sense with applications that have the appropriate requirements.

couple references to mainframe availability and operation:
http://www.garlic.com/~lynn/94.html#23

for IMS database development group allowed them to remote one 300 person organization 15 miles away (in one case) and in another case remote 300 person group in a new building on the other side of an interstate. I emulated a 370 channel (at the time expected BER of 10**-15) with a T1 communication link ... in the case of remoting the development group across the interstate ... used a optical (infrared) T1 modem and exhibited increase BER during rain and snow conditions (although during one heavy snow storm where there appeared to be total white out and nobody could get into work ... still managed to successfully get data from one side of the interstate to another).

This led to problems several years later
http://www.garlic.com/~lynn/94.html#24

where the expected channel error occurance for the total world-wide (latest model) mainframe install base over the period of 12 months (i.e. somewhat equivalent to a scsi buss error) was three ... and because I chose to simulate a channel error under certain conditions ... the total install base of all machines for all customers in the world for the whole year showed a total of 15 (instead of 3) such errors in the reports. This was of very serious concern to some people.

On the other hand ... fixing the following problem
http://www.garlic.com/~lynn/99.html#31

was "nice" ... even tho it only had significant effect on very small percentage of customers were seeing mean-time between MVS system crash of 15 minutes.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Dispute about Internet's origins

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Dispute about Internet's origins
Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens
Date: Fri, 24 Sep 1999 16:24:54 GMT
with regard to nsfnet costs ... it that the calculation based on the amount of the nsfnet contract ... or based on the cost of the amount of resources actually involved in nsfnet (which possibly were supplied by commercial companies far in excess of the size of the nsfnet contract)???

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

OS/360 (and descendents) VM system?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 (and descendents) VM system?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 24 Sep 1999 21:47:48 GMT
cambridge had a special, custom relocation box added to an ordinary 360 model 40 ... on which they developed cp/40 ... there was only one of a kind built supporting virtual memory

when the standard 360/67 product came along (a standard product offering, essentially a 360/65 with relocation hardware added ... the 67 could run in either 65 mode or 67 mode) ... the cambridge group ported cp from the model 40 to the 67 (resulting in the cp/67 product).

there was a "duplex" 360/67 (two processor model) that had a lot more engineering done to it ... and was quite a bit different from the two processor 360/65 SMP product.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Dispute about Internet's origins

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Dispute about Internet's origins
Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens
Date: Fri, 24 Sep 1999 22:23:21 GMT
somewhat related article:
http://www.sjmercury.com/svtech/columns/gillmor/docs/dg092499.htm
http://web.archive.org/web/20000124004147/http://www1.sjmercury.com/svtech/columns/gillmor/docs/dg092499.htm

IBM'S MISSED OPPORTUNITY WITH THE INTERNET

Source: DAN GILLMOR column

IN 1980, some engineers at International Business Machines Corp. tried to sell their bosses on a forward-looking project: connecting a large internal IBM computer network to what later became the Internet. The plan was shot down, and IBM's leaders missed an early chance to grasp the revolutionary significance of this emerging medium. This is one of those who-knows-what-might-have-been stories, an intriguing little footnote in Internet history. It's a cautionary tale

Published on September 24, 1999, Page 1C, San Jose Mercury News (CA)

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

OS/360 (and descendents) VM system?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 (and descendents) VM system?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 24 Sep 1999 23:03:18 GMT
also ... some discussion about virtual memory on 370 at:
http://www.garlic.com/~lynn/99.html#7

(i.e. 370 was initially shipped prior to virtual memory announcement).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

OS/360 (and descendents) VM system?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 (and descendents) VM system?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 25 Sep 1999 06:45:38 GMT
CP/67 was done by the cambridge scientific center at 545 tech. sq in Cambridge ... by some of the same people that had worked on CTSS. The original system had been implemented on a custom modified 360 model 40 and referred to as cp/40 ... and then later ported to 360/67 when it became available.

see

VM and the VM Community: Past, Present, and Future, revised 08/16/97
http://www.leeandmelindavarian.com/Melinda/

three people from cambridge came out and installed CP/67 at the university that i was at in jan. 1968 ... this was the third installation after Cambridge and Lincoln Labs.

We also had TSS available for testing ... in jan. 1968, TSS with four users doing interactive work had poor performance and poor response times. CP/67 running on the same hardware doing similar type of edit and fortran compile and execute would support 10-15 users with reasonable response.

misc. reference
http://www.garlic.com/~lynn/94.html#37
http://www.garlic.com/~lynn/94.html#46
http://www.garlic.com/~lynn/94.html#53
http://www.garlic.com/~lynn/94.html#54
http://www.garlic.com/~lynn/94.html#55
http://www.garlic.com/~lynn/98.html#28

one set of 360 cronology
http://web.archive.org/web/20010218005108/http://www.isham-research.freeserve.co.uk/chrono.txt

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

OS/360 (and descendents) VM system?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 (and descendents) VM system?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 25 Sep 1999 15:01:50 GMT
after first starting on fair share in the late '60s (& trying to integrate fair share advisory ... with scheduling to the bottleneck ... i.e. biasing the fairshare calculations to the resource consumption representing the system bottleneck) ... i did a specific guideline non-fair-share advisory integrated with fair share in the '70s ... which operated at both the user as well as collections of user level.

I was dealing with a number of internal computing sites to which I offered to install the new feature.

The typical response was no way.

Head of IS departments frequently have to sit around in regular user review meetings and listen to complaints about all the bad things that have happened and demands for new types of services.

The comments were pretty uniform that if there was a facility to offer non-fair share with explicit controls ... the squabling between the different departments demanding explicit non-fair-share would never allow the review meetings to adjourn.

reference to internal computing sites:
http://www.garlic.com/~lynn/99.html#112

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

Q: S/390 on PowerPC?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Q: S/390 on PowerPC?
Newsgroups: comp.arch
Date: Sat, 25 Sep 1999 15:06:19 GMT
to put some of this perspective ... 800-number lookup (i.e. 800 numbers are table lookup mapping to some real number) had requirement of maximum of five minutes of downtime per year (both scheduled and unscheduled, including operating and application system upgrades).

related post about 100% for six years:
http://www.garlic.com/~lynn/99.html#128

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

Q: S/390 on PowerPC?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Q: S/390 on PowerPC?
Newsgroups: comp.arch
Date: Sat, 25 Sep 1999 15:19:27 GMT
oh yes ... a couple of years ago one of the large national realtime financial processing centers had its roof collapse from snow and the hot backup had been in the world trade towers ... and they hadn't gotten around to recreating it at new location. it was gone for several hours until they got a site up and fully operational.

about ten years ago when I was doing high availability ... i coined the terms disaster survivability & geographic survivability (in part to distinquish from simple disaster recovery).

typically this means harden, bunkerred sites with UPS, generators, large onsite resovoirs of fuel ... near hospitals or other emergency facilities so they share in utility service with highest class of availability ... and then replicated at minimum of two sites with large geographic seperation that are chosen from 100 year studies to be suseptible to different kinds of problems.

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

Dispute about Internet's origins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Dispute about Internet's origins
Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens
Date: Sat, 25 Sep 1999 15:40:30 GMT
the question wasn't how much did NSF pay for NSFNET1 & NSFNET2 ... the question was what was the price of the resources that commercial companies actually installed for NSFNET1 & NSFNET2.

misc comments:
http://www.garlic.com/~lynn/99.html#40
http://www.garlic.com/~lynn/98.html#59

NSFNET1 contract called for T1 backone between a number of sites ... I was in the NCAR room and a couple others. Large room with rack of IBM PC/RTs with interface adapter cards supporting 440kbit transmission connected to IDNX telco multiplexors ... multiplexing multiple 440kbit channels into T1 trunks operating between sites.

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

Dispute about Internet's origins

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Dispute about Internet's origins
Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens
Date: Sat, 25 Sep 1999 15:48:41 GMT
i would even guess that they learned something by the time they tried the high performance storage system lab and the high performance network initiatives ... the vendors were asked to contribute equipemnt for free and the vendors could bask in the glow of the publicity.

I remember talking to some of the participants somewhat after some of the press releases ... one of the pacific rim countries had invited all the US participants in the US high performance network initiaive over and ordered/payed for a duplicate of the US installation.

it somewhat idlely crossed my mind who were they going to be most responsive to, an organization that asks for free donations or organization that pays in full for the installation.

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

OS/360 (and descendents) VM system?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 (and descendents) VM system?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 25 Sep 1999 16:40:25 GMT
there were a couple other things did.

I did a lot with paged map file system in the 70s on VM that was never released outside of internal installations. It had all sorts of advisory parameters that affected the region of virtual memory occupied by the mapped object.

another was work done at Cornell by Bob Cowles ... they developed scheduling and other performance modifications to virtual machine product ... that was eventually being sold as a product add-on to the base IBM product.

VM ran both converstational time-sharing (CMS) and batch (typically some form of guest operating system) and frequently concurrent in mix-mode operation.

Part of Bob's work was to be able to create advisory guidelines regarding the page fault rate for specific virtual memories (i.e. rather than optimize to virtual memory size objectives ... directly drive off of page fault rate). The most trivial implementation was when selecting a page for replacement ... if the page fault rate was higher than the objective for the task that owned the associated virtual memory space ... possibly return the page to active state and keep searching.

The issue here is the shift in computing resource bottleneck between the 60s and the late 70s.

reference:
http://www.garlic.com/~lynn/95.html#5

i.e. in situations where real memory is the bottleneck ... place greatest weight based on various real memory related consumption optimizations (pages currently active in real memory). however, when bottleneck shifts to moving pages between real memory back&forth backing store ... then rather than trying to indirectly optimize that resource by management associated with number and kind of pages resident in real memory ... tie the optimization directly to the resource bottleneck ... i.e. frequency of pages having to be moved.

the only URL reference I've got at the moment to cornell work is
http://www.marist.edu/~mvmuajs/vmoutlook/vmprog.html

Bob is currently at SLAC (or last time I talked to him)

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

OS/360 (and descendents) VM system?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 (and descendents) VM system?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 25 Sep 1999 18:25:33 GMT
other virtual machine activity ... ADMS ... now

http://www.bfsorg.com/main.htm
http://web.archive.org/web/20000530102359/http://bfsorg.com/main.htm

in 1977, I transferred to San Jose Research to work with VM system that they were going to install. While waiting for the machine to install, I would commute up to Palo Alto to help with the HONE consolidation at 1501 California.

I had been supplying HONE system with CP & CMS infrastructure from nearly the beginning. When EMEA moved to La Defense in Paris (from the states) I hand installed a HONE clone for them. When HONE needed first install in Asia, I did it for them.

One of the most prevelent uses of the early virtual memory management work was HONE. The original VM support for additional virtual memory features was limited to the "IPL" command simulation i.e. an image of specific virtual pages were captured and stored in a CP area that was only accessable via the "IPL" command simulated ... which included a complete reset of the virtual machine operation in addition to mapping specific virtual page contents into the virtual machine address space.

The IPL by name feature was used to do 1) fast starts for guest operating systems (the image saved was well after lots of guest operating system functions had been performed ... which might normally take several minutes) and 2) "share pages" (i.e. IPL-by-name control tables could specify shared memory areas where all virtual machines would point to a single set of pages in memory).

The major HONE deployed application to all of the world-wide field had been implemented in APL. There was a mechanism where a combined image of CMS plus the APL application were saved and automatically "IPLed-by-name" when branch office personel logged into the system.

An opportunity for HONE was that while the main online environment for the branch office people was platformed & encapsulated within APL but several of the applications that they needed access to might be other kinds of CMS applications (high on their prioriety were various "configurators" written in Fortan ... starting with 370/125 all mainframe configuration orders had gotten so complex that they could not be done w/o using HONE ... most of these were APL applications but several involving performance & thruput modeling were done in Fortran for performance). IPL-by-name provided no facility for dynamically switching back & forth between multiple different applications.

As part of my CMS paged-mapped file system that I had original started on CP/67 ... I included numerous flavors of page sharing specification at the application level within the CMS file system w/o having to resort to IPL-by-name command.

A major use of this feature was by the various deployed HONE systems to effect transparent transition back & forth between APL operation and FORTRAN applications.

For VM/370 verison 3, the development group picked up most of the internal CP kernel changes ... but none of the CMS changes ... so they had to platform the API off the existing IPL-by-name facility ... resulting in the LOADSYS/diag98 api implemenation.

HONE had also done a simple EXEC for backing up all the branch office file system areas ... it would cycle thru all the file areas for the various branch offices people ... dumping their files to tape using the VMFPLC command.

The main work during the fall of 1977 in Palo Alto was implementing SMP support in VM/370 release 3 so that by YE77, they were running production SMP operation.

One of the other tasks I undertook was to completely rewrite their simple backup exec. The first thing I did was to rewrite the tape I/O interface. The CMS "VMFPLC" command that they had been using for tape operation when writing to tape were generating tapes that were 50%-90% inter-record gap on the newer 6250 BPI tape drives. Other functions done to the exec was:

1) tape library ... keeping track of which tapes were used and not used 2) CMS simulated tape label function (similar to OS/360 tape label function ... in part as safety catch when operators might mount the wrong tape 3) history of files backed up (and which tape they were on). 4) incremental file-backup capability 5) interface to find & restore files on user's behalf

I called the rewritten function CMSBACK and by 1979 it was the production backup facility for HONE, San Jose Research, and many of the disk engineering locations in the San Jose area.

During 1980 the number of instatllations continued to grow, adding Los Gatos, Santa Teresa,

In 1981, I worked with Mark Brown to do a version two of CMSBACK, which included migrating of some number of the functions out of EXEC into compiled code and creating a demon that can directly accessed by users for restoring files (rather than having to go thru support person for restore requests). Mid-1981 was the first attempt to make CMSBACK available to a larger audience as a prodduct (instead of simply internally developed tool).

Mark Brown left IBM in the spring of 1982 (and went to work on similar activities for vm backup and archive products for another vendor after "version 2" was finished). Bob Rees replaced him on the CMSBACK effort and started work on CMSBACK version 3.

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

Q: S/390 on PowerPC?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Q: S/390 on PowerPC?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 25 Sep 1999 18:34:11 GMT
for another comparision ... dialog (online library information & abstracts, was subsidary of Lockheed at the time) computing center had around 300 drives in the early 80s attached to IBM mainframe.

tymshare, dialog, and HONE (ibm branch office and field online support) datacenters were probably all within 8-9 miles of each other at the time.

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

Q: S/390 on PowerPC?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Q: S/390 on PowerPC?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 25 Sep 1999 18:47:52 GMT
back then a large mainframe computing center installation easily running to tens of millions of dollars and 60% or more would be for the disks.

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

Uptime (was Re: Q: S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 27 Sep 1999 16:37:49 GMT
I think TPF has similar type of availability numbers for unscheduled downtime ... based on large collection of clustered mainframes. However, I've seen them have scheduled outages. I believe part of it is that the disk/data management facilities (TPF data management has been relatively primitive ... highly streamlined for specific kind of transactions) periodically require some sort of offline re-org. My youngest had a job with air freight forwarder during college and he said it wasn't unusually for some to overrun their offline window and still be down when he started his shift.

In the past, I've been in the far east and trying to change schedules bright and early Monday morning and told that the system was still down.

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

Uptime (was Re: Q: S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 27 Sep 1999 18:10:52 GMT
and when i was asked to redo routes several years ago ... that particular operation had a top ten problem list which included offline re-org ... misc ref:
http://www.garlic.com/~lynn/96.html#29
http://www.garlic.com/~lynn/96.html#31
http://www.garlic.com/~lynn/96.html#32
http://www.garlic.com/~lynn/96.html#33
http://www.garlic.com/~lynn/96.html#34
http://www.garlic.com/~lynn/96.html#35

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

Are there any really large commercial databases?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Are there any really large commercial databases?
Newsgroups: comp.databases
Date: Tue, 28 Sep 1999 00:28:20 GMT
some of the nasa databases have been talking about growing to petabytes (1000 terabytes) ... but they are typically mulit-megabyte records, relatively small number of records, and few update/inserts per day. others playing in this area are possibly oil exploration ... with maybe hundreds of terabytes.

there are commercial databases that are much smaller (few number of terabytes) but have much smaller records and only process from half million to 20 million insert/updates per day and only have tens of billions of items.

while total physical size is one measure of database limits ... total number of records managed and number of insert/updates can be a much more telling characteristic of the database capability.

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 28 Sep 1999 04:14:27 GMT
1419s on MVT could be done with PCI (flag in I/O commands to generate a program controlled hardware interrupt) and interrupt appendage (application specified routine that received control during kernel interrupt processing)

VS1 on 370 required "SCP PRPQ" (kernel modification) to support check sorter (early 70s ... starting circa 1973).

description of A national processing center .. but it has grown somewhat since then
http://www.unisys.com/news/releases/1995/jan/01045747.html

there are also urban legends about local exchange operation in the san fran area.

description of the federal reserve hub/spoke system
http://www.federalreserve.gov/boarddocs/testimony/1997/970916a2.htm

real early 1419 reference ...
http://www.geocities.com/SiliconValley/Lakes/5705/1401.html

some processing notes about check sorting:
http://www.comdisco.com/bc/disaster_nashville.html
http://www.comdisco.com/bc/item_processing.html

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 28 Sep 1999 06:52:46 GMT
and for some interesting discussion about federal reserve settlement (as distinct from paper check forwarding) ... especially with regard to the difference between intra-district versis inter-district settlement
http://financialservices.house.gov/91697mil.htm

the GOA report referenced in the above with regard to systemic risk is:
Payments, Clearance, and Settlement: A Guide to the Systems, Risks, and Issues (Chapter Report, 06/17/97, GAO/GGD-97-73)

and is available from the www.gao.gov site.

Some time ago, I merged the glossary from that report with others and it is available at:
http://www.garlic.com/~lynn/payment.htm

and also
http://www.garlic.com/~lynn/financial.htm

although I suggest checking the glossary notes at
http://www.garlic.com/~lynn/

before referencing the financial glossary

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 28 Sep 1999 18:27:02 GMT
we had a good update & demos on iris scan (not nearly as intrusive as retina scan) at FSTC last week
http://www.americanbanker.com/PSUser/ABO_Story.htm?NS_adv_search=0&NS_search_set=svcoFUKy_f105168095f7f1&NS_doc_offset=2

a problem is that it still requires secure sensor/scanner (normally not owned by the person being sensed).

one of the things that I hadn't realized was not only is iris different in identical twins ... but that left & right iris are different (i.e. DNA doesn't handle cases of identical twins) and it even works with blind people (unless they lack both eyeballs totally).

we are within goal of being able to put finger-reader right on an AADS card owned by the person... and use it only for card activation (so that biometric information never leaves the person's control) ... part of the discussion is at:
http://www.garlic.com/~lynn/aadsm2.htm#straw

although finger-reader on some of the non-card form factors is still an issue (not as bad on cell phone or PDAs).

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

Uptime (was Re: Q: S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 29 Sep 1999 17:48:14 GMT
actually have had some amount of problem with TCP/IP and some of the browser vendors. Most large servers have POP (point-of-presence) attachment to the internet at least one place ... and with hierarchical routing in the Internet ... can't have multiple POPs into different places into internet backbone with different IP address. Only some of the IP boxes are now just starting to show signs of "telco provisioning" technology.

So standard process is to have multiple attachments into the backbones all with different IP addresses and rely on DNS name server to map multiple IP addresses to the same host name. The problem I had was getting the browser companies to actually support multiple DNS "A-records" ... the brain dead example in most TCP books just has the code pulling the (one & only) ip address out of the ip-lookup reply and doing connect. If the connect fails they give up.

The HA logic was if the connect failed ... check to see if the address-lookup returned more than one ip address ... and try connects on the other ip addresses. Mid-90s, some of the browser developers would tell me that multiple A-record support was too new/advanced ... even tho I could pull examples from source code on the 4.3 tahoe distribution .. nearly ten years previous ... real problem was that it didn't show up in any of the examples used by college student texts.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Uptime (was Re: Q: S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 02 Oct 1999 16:53:25 GMT
my comment about multiple A-record support was the example didn't show up in the typical college text on tcp/ip. it was trivial to pull code example from TELNET/FTP clients on BSD 4.3 TAHOE (base code for large percentage of commercial implementations during the late 80s and early 90s).

related reference:
http://www.garlic.com/~lynn/94.html#34

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 02 Oct 1999 16:46:02 GMT
easier for crooks? .... quick hit & run robbery typically is much simpler than maiming/killing and carrying around degradable biological material.

one of the big issues on biometrics (fingers, iris, face recognition, retina scans, etc) has nearly alwas been building in methods to check for liveness (i.e. it isn't being spoofed by some method that would result in the scanner reproducing the same electronic signature for the biometric sensor). The other for secure scanners has been evesdropping ... just recording the biometric signature produced by the scanner ... and injecting the signature directly into the infrastructure (with scanner cut-out).

the traditional 3-factor authentication security scenerio has alwas been
something you have, • something you know, and • something you are.

ATM so far has only been two-factor ... something you have (card) and something you know (pin ... but really rather weak). Going to 3-factor authentication doesn't seem to be easier for 3rd world crooks (they've alwas had the option of killing ... there are the stories about people being killed mailing a letter for the value of the stamp).

Issue for security has alwas been does the cost outweight the benefit ... i.e. are the significant drops in technology costs for biometric sensing enuf to deploy resulting in net benefit to the infrastructure.

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

OS/360 (and descendents) VM system?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: OS/360 (and descendents) VM system?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 02 Oct 1999 17:31:43 GMT
oh yes ... example of supercharged VS1 (... rather long-winded example from the archives)
http://www.garlic.com/~lynn/94.html#35
&
http://www.garlic.com/~lynn/97.html#16

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

What is "Firmware"

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: What is "Firmware"
Newsgroups: alt.folklore.computers
Date: Sat, 02 Oct 1999 20:42:03 GMT
i think the WOM may have been done in conjunction with the paper (from Berkeley?) on recursive compression algorithm ... showing that arbritrary number of bytes could be compressed into a single byte ... it went well with what i knew of black holes ... until they published the paper on black holes evaporating.

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

IBM Assembler 101

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: IBM Assembler 101
Newsgroups: bit.listserv.ibm-main
Date: Sat, 02 Oct 1999 20:51:20 GMT
wpb@JPS.NET (Bill Becker) writes:
I agree with Jim here. After having worked in a programming stevedore mode for a while, I have also decided that writing the code for the best fit on all possible platforms is the way something "should" be done.

Heck, I even write my assembler programs so they look like C. I wrote some routines that mimic the way scanf and printf work, along with calloc, strlen, strcat, etc.


aargh ... i've asserted for quite some time that over half (maybe 90%) of the internet, c-based operating system, & c-based application exploits are systemic of C's implicit string length architecture (i.e. being able to exploit buffer overruns because the programmer has relied on implicit string lengths ... something that is relatively less frequent on systems that rely on explicit string/buffer length paradigms).

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

Uptime (was Re: Q: S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Uptime (was Re: Q: S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computer
Date: Sat, 02 Oct 1999 21:20:19 GMT
other problems with telnet/ftp/http TCP connection:

1) getting it connected reliably in the first place ... HTTP has exhaserbated (&/or helped) the problem with high frequency of very short TCP (transaction-like) connections

2) few if any of the components are telco provisioned and as soon as internet infrastructure started going to hierarchical routing ... it became very difficult to mask failures by advertising different routes for end-points

3) multiple DNS A-records would work if the client application was smart enuf to use value returned in ip-lookup as a list instead of single address and retry with each address on the list in case of failure (this has lot more benefit in HTTP case since there are all of these very short, transaction-like connections with little or no state history ... compared to telnet long running connections with potentially significant state). DNS round-robin for load-balancing slightly mitigates the problem with braindead client applications. Geographic/hop/load sensitive DNS try to make the first entry in the list ... the closest resource. However, almost all ISPs do local DNS caching (with timeouts typicaly set to hours) which negates majority of the fancy DNS list re-ordering.

4) in smaller configurations IP address take-over was also possible for helping mask failures ... except in cases of IP implementation bugs (ref: http://www.garlic.com/~lynn/96.html#34)

5) the HTTP short transaction severely stressed implementations in the mid-90s because of nearly all TCP FINWAIT implemenations (after close ... keep around dangling status in case of stray packets ... FINWAIT lists were assumed to be at most a couple so there were sequential list search strategy on ever incoming packet ... until they found HTTP was resulting in 20,000+ dangling FINWAIT on the lists and 95-99% of the processor was taken up running down the list)

extraneous information

VMTP (RFC1045) with proposal to reduce minimum transaction to five packet exchange (compared to TCP seven packet exchange).

XTP
http://www.ca.sandia.gov/xtp/
http://web.archive.org/web/20020209014400/http://www.ca.sandia.gov/xtp/
would even do better, reducing it to three packet exchange.

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 03 Oct 1999 15:59:59 GMT
note that simple deployment for iris scan is ATM cards where people write their PIN on the card. I believe they said that there are pilots currently in Houston.
http://www.zdnet.co.uk/news/1999/19/ns-8130.html
http://www2.kingston.net/iknet/alliance/iriscan.html
http://www.techweb.com/wire/story/TWB19971202S0001
http://www.iriscan.com/

Comparison isn't that it is impossible to spoof the iris scan ... just that it is (much) harder than finding/stealing somebody's card with PIN written on it (larger percentage than some people might think) and using it. all the technology for iris spoofing would also appear to be more complicated than forcing somebody at gunpoint to withdraw $20 from their ATM.

the finger-reader ... in addition to higher error rates ... has problems in public places ... plan, standard use with people that show up with dirty & greasy fingers ... not only causing problems for them ... but also leaving the sensor possibly inoperable for others.

from privacy standpoint ... finger-reader has slight advantage ... it is possible to package finger-reader on a card and use it for card activation ... so that the person's biometric information never leaves device under the person's control. iris scan is still shared sensor device ... so the biometric signature is exposed to devices owned & shared by others (i.e. finger-reader on the card is only used to turn the card on & off ... ATM machine iris sensor is used to authenticate the transaction) ... ref AADS strawman:
http://www.garlic.com/~lynn/aadsm2.htm#straw

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 03 Oct 1999 16:33:20 GMT
still easier to force somebody to perform the operation at gunpoint ... the way some ATM robberies happen today.

iris scan looks at the face and figures out where the eye is on the face ... and then focuses in on the center of the eye & images the surface of the eye to get the iris signature. there are much easier ways to steal $20-$100 than removing an eyeball and spoofing an iris scan ... that it would seem to be well down on the list of probable actions.

for higher value security infrastructures they might be looking at multi-factor biometrics ... say face-scan, iris-scan, retina-scan, finger-length, finger-print & voice-recognition ... in conjunction with computer command/response (computer asks for randomly selected action/response) ... and all done under surveillance monitoring. the easier attacks are still forcing someone or attacks on the electronics behind the sensors ... spoofing the sensors would still way down on the list.

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 03 Oct 1999 19:35:51 GMT
is stealing somebody's atm card, performing non-intrusive capture of their iris, and creating an iris print on the backside of the iris ... more or less expensive than stealing/finding somebody's atm card with the PIN written on the back???

most security techniques aren't totally fail-safe ... they just have to make the level of difficulty higher than other methods yielding similar rewards &/or reduce the frequency of fraud by measurable percentage points yielding positive cost/benefit.

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 03 Oct 1999 19:42:39 GMT
i.e. the cost of deploying the iris scan (or any biometric authentication) methodology needs to be offset by the reduction in the rate of fraud (not necessarily make the possibility of fraud zero ... just reduce the amount of fraud by more than the cost of deploying the infrastructure).

with current reduction in technology costs ... it appears to have tipped the scales in the favor of even simple iris scan being able to reduce amount of fraud by more than the cost of the technology deployment (even if there are known possible methods of defeating the iris scan ... the cost/difficulties of those methods of defeating simple iris scan have to be higher threshold than possible investments in other form of fraud payback).

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

Crowther (pre-Woods) "Colossal Cave"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Crowther (pre-Woods) "Colossal Cave"
Newsgroups: alt.folklore.computers
Date: Sun, 03 Oct 1999 20:36:42 GMT
following is reply that I received when I was trying to track down copy of ZORK (in the late 70s). At the time I already had numerous copies of adventure in fortran and several enhanced versions written in pli ... ref:
http://www.garlic.com/~lynn/98.html#56

> ZORK is a PDP-10 program written in MUDDLE, a LISP-derivative language
> for which no compiler exist outside the PDP-10.  It is friendly with
> the I.T.S. operating system and no other.  One Tim Anderson of the
> Lab for Computer Science is its proprietor.
>
> Someone at DEC apparently took the MUDDLE source and
> transliterated it to FORTRAN.  I don't know how faithful
> the transliteration is.  It is supposed to b e  available through
> the DEC Users group association, DECUS.  A letter to them
> may turn up some information.
>
> Beware.  ZORK is addictive.  Untold man-hours will disappear into
> its use, and some people will decide they want to analyze the game
> itself, which is said to require a man-month or so before solutions
> and algorithms become clear.

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 05 Oct 1999 02:44:42 GMT
in fact the AADS CHIP strawman ...
http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/aepay3.htm#x959risk1
http://www.garlic.com/~lynn/aepay3.htm#x959risk3
http://www.garlic.com/~lynn/aepay3.htm#x959risk4
http://www.garlic.com/~lynn/aadsm3.htm#cstech5
http://www.garlic.com/~lynn/aadsm3.htm#cstech12
http://www.garlic.com/~lynn/aadsm3.htm#kiss2

proposes the person own the biometric sensor and the biometric data never leaves the person's control

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 05 Oct 1999 03:44:33 GMT
look at draft X9.59 protocol that we've been working on for a couple years (charter given the X9A10 working group was to preserve the integrity of the financial infrastructure for all electronic retail payments with just a digital signature) ... and preparing the way to fasttrack to ISO. the underlying AADS is also being looked at as an implementation for FSTC FAST ... so it would be possible to not only eliminate fraudalent transactions by knowing the account number ... but be able to not have to provide web servers your name/address ... even for hardgood shipments.

various ref:
http://www.garlic.com/~lynn/aepay2.htm#aadspriv
http://www.garlic.com/~lynn/aepay2.htm#privrules
http://www.garlic.com/~lynn/8583flow.htm
http://www.garlic.com/~lynn/aadswp.htm
http://www.garlic.com/~lynn/aadsover.htm
http://www.garlic.com/~lynn/aadsm2.htm#privacy
http://www.garlic.com/~lynn/aadsm3.htm#cstech13
http://www.fstc.org/
http://www.americanbanker.com/PSUser/ABO_Story.htm?NS_adv_search=0&NS_search_set=tuc07kRZxf973468095f7f1&NS_doc_offset=0
http://www.elistx.com/archives/ansi-epay/199907/msg00026.html
http://web.archive.org/web/20010727182920/lists.commerce.net/archives/ansi-epay/199907/msg00026.html

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 05 Oct 1999 04:09:11 GMT
it is much simpler to coerce/blackmail than it is to go to the trouble of killing/maiming somebody, hijacking their biometric material and then using the biometric material for impersonation. killing/maiming for biometric impersonation seems to be much more along the lines of terriost activity than fraud (i.e. financial return on investment is much lower than other methods) ... or out of the movies.

the deployment of iris scan for ATMs would appeal to people that currently write their PINs on their cards ... i.e. PIN security is frequently much weaker than hypothesized because of dealing with real live humans ... i.e. the iris scan brings ATMs up to the security hypothesized for PINs ... because real live humans frequently don't conform to what the manual specifies in the regulations.

in fact ... PIN/password lack of security is starting to be widely recognized ... not that the technologists & security experts designed poor PIN/password technology ... but because there is large percentage of the population that doesn't follow the rules laid down in the security manuals (the technology may not have been weak ... but it is weak because of PIN/password infrastructure required human actions that doesn't happen in real life).

an issue for biometrics for ATM is does the cost come down enuf so that it can be used economically to fix recognized human factor failings associated with existing PIN/password infrastructures.

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

checks (was S/390 on PowerPC?)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 05 Oct 1999 04:13:18 GMT
related on PIN/passwords:
http://www.elistx.com/archives/ansi-epay/199908/msg00003.html
http://web.archive.org/web/20010727175135/lists.commerce.net/archives/ansi-epay/199908/msg00003.html
http://www.elistx.com/archives/ansi-epay/199908/msg00008.html
http://web.archive.org/web/20010727180453/lists.commerce.net/archives/ansi-epay/199908/msg00008.html

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

S/360 history

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: S/360 history
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 07 Oct 1999 04:28:54 GMT
one other relocate for 360/67 (cp/67, mts, tss) was done by Boeing Huntsville ... for handling storage fragmentation under MVT when supporting a large number of 2250M1 involved in long running applications. This was done against a OS/360 release 13 MVT (there may have been some MVT in release 12 ... but our shop went directly from OS/360 release 11 MFT to OS/360 release 14 MFT ... MVT for most shops didn't start to look practical until the combined OS/360 release 15/16).

I didn't actually see the Boeing Huntsville system ... just talked to some of the people that transferred with the machines (two 360/67s) to Seattle around summer of '69 ... and brought up CP/67.

note that CP/67 was done originally as cp/40 on a custom, one of a kind 360/40 which had relocate box tacked on to it.

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

amusing source code comments (was Re: Testing job applicants)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: amusing source code comments (was Re: Testing job applicants)
Newsgroups: alt.folklore.computers
Date: Thu, 07 Oct 1999 04:15:26 GMT
would be wall clock ... on 360/65, a three step fortran (compile step, link-edit step, and execution step) could be over a minute ... even for null program ... with almost all job scheduler.

before WATFOR ... our shop did a custom monitor that would do all three steps under monitor control (involving only single job scheduler step instead of three) ... but when WATFOR came along ... it was significantly better.

the other was to almost triple the thruput of job scheduler by careful tuning ... compared to standard system ... as per:
http://www.garlic.com/~lynn/94.html#18

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

S/360 history

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: S/360 history
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 07 Oct 1999 15:15:34 GMT
my understanding was that the only triplex 360/67 that was built was for lockheed ... for MOHO(?) project. the normal channel director for duplex 67 was manually set (mesh interconnect between I/O channels, memory banks and CPUs ... with switches that controlled what went where).

the triplex channel director was also under program control ... hardware could be reconfigured by changing the switch settings ... addressed by combination of control registers.

one of the IBM SEs that worked on the project later joined CSC in cambridge ... and was responsible for the compare&swap instruction ... his initials are CAS ... so the mnemonic came first ... and then it was necessary to come up with words that went with the mnemonic.

ron smith in architecture insisted that multiprocessor support wasn't sufficient and it was necessary to invent some use for the instruction in uniprocessor mode ... which lead to the programming notes about how "interrupt enabled" applications could safely update fields and chains (even in uniprocessor configurations).

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

S/360 history

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: S/360 history
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 08 Oct 1999 02:06:33 GMT
footnote, pg 11, melinda varian's
VM and the VM Community: Past, Present, and Future

http://www.leeandmelindavarian.com/Melinda/

30. A.V. Lindquist, R.R. Seeber, and L.W. Comeau, ''A Time-Sharing System Using an Associative Memory'', Proceedings of the IEEE, vol. 54, no. 12, December, 1966, pp. 1774-9. The Center actually wanted a 360/50, but all the Model 50s that IBM was producing were needed for the Federal Aviation Administration's new air traffic control system.


footnote, pg 12
32. R.U. Bayles, private communication, 1989. "The Model 40 was a Hursley (UK) product, announced in 1964. It used the first programmable ROS (invented by Tony Proudman, I believe) called Transformer Read-Only Storage (developed in 1961/2). In the Model 40 the circuit on the Mylar sheets wound around 60 cores, hence allowing the storage of 60-bit words; the Model 40 had 4096 60-bit words. It was this re-programmable storage that made the Model 40 modifiable, as you describe." (M.F. Cowlishaw, private communication, 1990.)

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

checks (was S/390 on PowerPC?)

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: checks (was S/390 on PowerPC?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 14 Oct 1999 12:30:34 GMT
somebody associated with program on information resources policy (http://pirp.harvard.edu/) in australia did surveys of several countries around the world on things like ATM & checks (electronic transaction, non-electronic). One of the results of the survey from several countries with regard to ATMs is that there is positive confirmation on withdrawals but not on deposits. For ATM deposits it may be at least a day or more before there is confirmation that what you thot got deposited is also what the bank believed was deposited. For deposits, having a bank employee confirm on the spot that they agree or disagree with you (and if disagree, both of you can immediately resolve the differences) is viewed as very positive beneift.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

S/360 history

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: S/360 history
Newsgroups: bit.listserv.ibm-main
Date: Mon, 11 Oct 1999 22:41:18 GMT
when burlington (mass, it was in the old service bureau bldg in burlington mall) was closed and the group told they could move to pok ... many of them left the company and got jobs developing vms.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

The Watsons vs Bill Gates? (PC hardware design)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: The Watsons vs Bill Gates? (PC hardware design)
Newsgroups: alt.folklore.computers
Date: Sun, 17 Oct 1999 14:40:19 GMT
we setup up process for regular releases and then monthly releases for PLC or program level changes. PLC for the most part were bug fixes (although there were periodic exceptions for special function). PLC would be something like 2.15 (or release 2, PLC 15).

source control numbered changes sequentially so both bug fixes and enhancements tended to be identified by their sequential number from source code change system (even if the change spanned several modules). after 7-8 years, the numbers went past the ten thousand mark (this was when both binaries and source was shipped to customers, where the source was the internal source code infrastructure).

for the resource manager ...
http://www.garlic.com/~lynn/94.html#2

we created a set of regression tests that initially took 3 months elapsed time to run. I had been asked to do an maint. release of the resource manager tracking the PLC base product schedule. The problem was that a minimum regression tests set took 10-14 days to run. I could see no way that I could do the normal resource manager stuff, do the integration and test with the monthly PLC and also do minimum regre ssion tests at monthly intervals .. so I insisted that the resource manager PLC schedule had to be a release every three months (instead of every month).

misc. other references ...
http://www.garlic.com/~lynn/94.html#5
http://www.garlic.com/~lynn/94.html#7
http://www.garlic.com/~lynn/94.html#52
http://www.garlic.com/~lynn/95.html#1

somewhat related threads ....

http://www.garlic.com/~lynn/97.html#11
http://www.garlic.com/~lynn/97.html#14
http://www.garlic.com/~lynn/97.html#15
http://www.garlic.com/~lynn/97.html#16
http://www.garlic.com/~lynn/99.html#16
http://www.garlic.com/~lynn/99.html#17

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

Merced Processor Support at it again

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Merced Processor Support at it again . . .
Newsgroups: comp.arch
Date: Tue, 19 Oct 1999 19:19:07 GMT
also trout 3090.

308x were done by the 158 group

3090s were done by the 168 group

rather than coming out simultaneous ... they started leapfrogging each other.

misc ref:
http://www.garlic.com/~lynn/95.html#3

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

Clustering systems

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Clustering systems
Newsgroups: comp.arch
Date: Thu, 21 Oct 1999 03:01:14 GMT
many of the customers are just looking for up time. both fault tolerant and clustered systems can address the requirements in different ways ... including combinations of the two.

several years ago looked at an environment that had a requirement for <5mins downtime per year. There was a fault tolerant message handling box that had two T1 links out the back-end to database processor. The message was sent out one T1 and if the reply didn't come in ... it was sent out the other T1. The initial assumption that they needed a fault-tolerant database processor on the backend ... however the fault-tolerant candidates at the time needed several hrs of scheduled downtime per year for various things. It was relatively straight forward to show that a clustered database implementation could meet the outage requirement ... and that the message processing to compensate/mask for T1 serial failures would also work equally well for compensating/masking a cluster member failure.

However, as general purpose hardware has been getting more & more reliable ... the frequency of outages/failures have started to drift to other areas.

great quote of off sci.crypt today
> Yes, "in theory there is no difference between theory and practice, but
> in practice there is."


misc. references
http://www.garlic.com/~lynn/96.html#13
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/96.html#27
http://www.garlic.com/~lynn/96.html#28
http://www.garlic.com/~lynn/99.html#71

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

Clustering systems

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Clustering systems
Newsgroups: comp.arch
Date: Fri, 22 Oct 1999 17:32:31 GMT
big characteristic between fault tolerant and clusters tend to be how well transient state information is kept ... with clusters tending to maintain consistency on more of a macro stage and fault tolerant tending to maintain information consistency at much lower micro stage.

fault tolerant tend to be better at maintaining state information for things with long running state like telnet connections. clusters tend to work well where there is relatively short transactions in environment where transactions are likely to be redriven (for one reason or another).

one example of transaction redrive is from previous post:
http://www.garlic.com/~lynn/99.html#182

The mentioned backend fault tolerant hardware provided 5-6 nines (<5 minutes downtime per year) but the associated software needed scheduled downtimes on the order of hrs per year. A proposed solution to the backend downtime was to have clusters of fault tolerant boxes ... but given the frontend transaction redrive ... it was not possible to show any significant difference between clusters of fault-tolerant backend boxes and clusters of non-fault-tolerant backend boxes (except in cost & price/performance) ... they both met requirements.

other types of situations involving transaction redrive are some of the tcp/ip related protocols (http, nfs). but there can be misc. gotchas like:
http://www.garlic.com/~lynn/96.html#34

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

Clustering systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Clustering systems
Newsgroups: comp.arch
Date: Fri, 22 Oct 1999 17:51:51 GMT
also in the late 80s when we were running around doing this sort of stuff, i coined the terms disaster survivability and geographic survivability (in part to distinquish from disaster recovery). geographic clusters address things like data center getting flooded.

situation involving large cornerstone of the financial system ... i.e.
http://www.garlic.com/~lynn/99.html#71

where neither of the two "most important" availability pieces is fault tolerant hardware.

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

Clustering systems

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Clustering systems
Newsgroups: comp.arch
Date: Fri, 22 Oct 1999 18:18:40 GMT
<5min per year, <hr per decade, or approx. one shift per century; 100 year flood taking out the data center for 2-3 days can totally destroy your availability statistics for a millenium.

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

Clustering systems

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Clustering systems
Newsgroups: comp.arch
Date: Fri, 22 Oct 1999 21:42:23 GMT
various things that take out data center
bomb construction accident digging operations earthquake fire flood gasline explosion hurricane operator mistake snow collapsing roof tornado transformer explosion volcano waterpipe break

focus on various hardware issues have started to put them in the availability noise range when compared to other things that now have higher probability of occurrence.

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

Merced Processor Support at it again

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Merced Processor Support at it again . . .
Newsgroups: comp.arch
Date: Sat, 23 Oct 1999 16:28:09 GMT
misc. 303x ref:
http://www.garlic.com/~lynn/95.html#3
http://www.garlic.com/~lynn/97.html#20
http://www.garlic.com/~lynn/99.html#7

3031&3032 were actually 158 & 168 with new covers and setup to use "channel directors" for I/O. the channel directors were actually 158 with different microcode (instead of 370 instruction set ... did i/o).

3033 started out being 168 wiring logic mapped to newer/faster chip technology (got about 20% increase in performance) and then some logic tweaking (that got the rest of the performance).

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

Merced Processor Support at it again

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Merced Processor Support at it again . . .
Newsgroups: comp.arch
Date: Sat, 23 Oct 1999 16:36:09 GMT
i believe the amdahl machine (amdahl 7? or 8?) was something like 36 ciruit/chip technology and the 168 logic was mapped to something like 40 circuit/chip technology. the 168 was 4 circuit/chip technology and the initial mapping of 168 to newer technology continued to use the same 4 circuits per chip (and got its 20% performance boost just from the chips being faster). tweaking of the logic to do more onchip operation in critical areas got the remaining performance (168-3 was about 3.1mip machine ... 20% got it to about 3.7mip ... tweaking the logic then got 3033 up to something like 4.5mip).

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

Internet Credit Card Security

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Internet Credit Card Security
Newsgroups: sci.crypt
Date: Sat, 23 Oct 1999 17:36:59 GMT
"Gary" writes:
Why don't credit card companies give us secret internet pin numbers (by snail mail)? We'd just securely hash Account No+Secr.et Pin No+Time and Date. Credit card company would then (knowing the pin number their end) authorise the transaction. The system could be extended to a calculator like credit card. We'd enter the pin number to authorise a transaction in a restaurant etc generating a unique credit card number that can't be re-used.

in effect debit works something like that (although part of the current debit issue is that it is DES based).

we are trying to do something with X9.59 ... misc refs: at
http://www.garlic.com/~lynn/

for all electronic payment infrastructures (i.e. preserve the integrity of the financial infrastructure for all electronic retail payments with just a digital signature)

the digital signature and a couple other values by themselves are small enuf to push thru in interchange (banknet) addenda field. two issues, 1) current debit/credit typically are on the order of 60-80 bytes ... so the additional data shouldn't significantly bloat the current number of bytes flowing and 2) additional data fitting in existing interchange addenda field infrastructure (although new work item has gone to ISO to identify specific addenda field).

the other issue is the computational effort ... some work with AADS chip strawman
http://www.garlic.com/~lynn/aadsm2.htm#straw

the device could be pin/biometric activated ... so there is no shared-secret &/or biometric/privacy information anywhere in the infrastructure.

misc. other
http://www.garlic.com/~lynn/aadsm2.htm#privacy
http://www.garlic.com/~lynn/aadsm3.htm#cstech
http://www.garlic.com/~lynn/aadsm3.htm#cstech5
http://www.garlic.com/~lynn/aepay2.htm#aadspriv
http://www.garlic.com/~lynn/aepay2.htm#privrules
http://www.garlic.com/~lynn/aepay3.htm#x959risk1

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

Merced Processor Support at it again

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Merced Processor Support at it again . . .
Newsgroups: comp.arch
Date: Tue, 26 Oct 1999 00:08:33 GMT
"Shmuel (Seymour J.) Metz" writes:
Was Amdahl still working on the 470V/6 (/7, /8) series when the 3033 came out, or had they already switched to their new line?

--
Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz


i found following from file at:
http://web.archive.org/web/20010218005108/http://www.isham-research.freeserve.co.uk/chrono.txt

Product
or Event          Ann.  FCS            Description

CDC 6600          63-08 64-09     LARGE SCIENTIFIC PROCESSOR
IBM S/360-67      65-08 66-06 10  MOD 65+DAT; 1ST IBM VIRTUAL MEMORY

AMH=AMDAHL        70-10           AMDAHL CORP. STARTS BUSINESS
AMH V/6           75-04?75-06 02  FIRST AMDAHL MACHINE, FIRST  PCM CPU
AMH V6-2          76-10 77-09 11  (1.05-1.15)*V6 WITH 32K BUFFER
IBM 3033          77-03 78-03 12  VERY LARGE S/370+EF INSTRUCTIONS
AMH V7            77-03 78-09 18  AMDAHL RESP. TO 3033 (1.5-1.7)* V6
IBM 3031          77-10 78-03 05  LARGE S/370+EF INSTRUCTIONS
IBM 3032          77-10 78-03 05  LARGE S/370+EF INSTRUCTIONS
IBM 3033MP        78-03 79-09 18  MULTIPROCESSOR OF 3033
AMH PLANT         78-05           AMDAHL OPENS DUBLIN, IRELAND PLANT
AMH V8            78-10 79-09 11  (1.80-2.00)*V6, FLD UPGR. FROM V7
IBM 3033AP        80-06 80-08 02  3033 ATTACHED PROCESSOR
IBM 3033          80-06 81-10 16  Ext. Addr.=32MB REAL ADDR.;MP ONLY
AMH UTS           80-09 81-05     UTS=Amdahl Unix Op. System (under VM)
IBM 3081D         80-11 81-4Q 12  FIRST H MODEL, 10MIPS IN DP, WATER COOLED
AMH 580/5860      80-11 82-09 22  (2*V8, 12+ MIPS) UP, NEW,AIR COOLED TECH.
AMH 580/5880      80-11 85-05 54  MP OF 5860 AT 21+ MIPS
IBM 3081K         81-10 82-2Q 08  NEW DP FUM: 1.35*3081D, 64K BUFFER/OVLAP
IBM 370-XA        81-10 83-03 17  NEW ARCH 3081: 31 BIT REAL/VIRT, NEW I/O
IBM 3084          82-09 83-4Q 15  1.9*3081K Perf., 4 way MP, 3081K upgrade

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

Merced Processor Support at it again

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Merced Processor Support at it again . . .
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 28 Oct 1999 15:23:23 GMT
Anne & Lynn Wheeler <garlic.com> writes:
AMH UTS 80-09 81-05 UTS=Amdahl Unix Op. System (under VM)

& recent post to ibm-main
IBM talked about (but did not announce) LINUX/390. The future tech session showed foils about LINUX/390. There will be 2 versions ... 1st is LINUX/390 under VM only and the 2nd will be LINUX/390 on S/390 (bare metal). LINUX/390 under VM is ready now. LINUX/390 on bare metal will take more time (but soon). They had hoped to announce LINUX/390 at WAVV but the decision had not been made yet (or so the rumor went).

Seems the LINUX is 2.2 kernel and about 1,000,000 of C code. About 30,000 are hardware dependent. I understand that most software runs by just re-compiling for LINUX/390. No X-Windows of course ...

LINUX/390-VM uses DIAGnose to make the port simplier.

Ideas were discussed like LPAR on MP-3000. VSE/ESA in 1 LPAR and LINUX/390 in the 2nd. Connected via CTC. Or running an ISP on S/390. Run VM/ESA with many LINUX/390 machines .. each with its own ip address for virtual hosting. With S/390 hardware no LINUX virtual host could effectanother. Very stable.

If you want this released I suggest you send IBM your thoughts and ideas on how this would make S/390 hardware more popular.


slightly related:
http://www.garlic.com/~lynn/93.html#19
http://www.garlic.com/~lynn/99.html#2
http://www.garlic.com/~lynn/99.html#36

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

offline RFCs (RFC439)

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: offline RFCs (RFC439)
Newsgroups: alt.folklore.computers
Date: Sun, 31 Oct 1999 04:23:42 GMT
recent history of old RFCs project

901 Oct  7 10:32 rfc591.txt
    2579 Sep 29 11:51 rfc436.txt
2242 Sep 29 11:48 rfc434.txt
    7998 Sep 29 11:40 rfc589.txt
7093 Sep 28 12:50 rfc377.txt
9059 Sep 28 12:50 rfc387.txt
10925 Jun 10  1998 rfc31.txt
    8360 May 21  1998 rfc57.txt
2330 May 21  1998 rfc53.txt
    5343 May 21  1998 rfc47.txt
2534 May 20  1998 rfc34.txt
2216 May 20  1998 rfc32.txt
5088 Mar  4  1998 rfc52.txt
    1813 Feb  5  1998 rfc314.txt
7941 Jan 23  1998 rfc339.txt
    6103 Jan 23  1998 rfc390.txt
58074 Jan 23  1998 rfc354.txt
10643 Jan 22  1998 rfc559.txt
17774 Jan 22  1998 rfc469.txt
    1130 Jan 16  1998 rfc45.txt

and from
http://www.rfc-editor.org/overview.html
OLD RFCs

The RFC-Online project is working to put all existing RFCs into electronic format. We are currrently working on RFCs ranging from 1-600. However, this process has necessarily had lowest priority; keeping up with new RFCs must take precedence. It is our objective to make substantial progress towards getting all RFCs online before the end of the year 2000.


Some RFC #'s were issued to documents and then the documents were never actually published. This explains some of the gaps between numbers.

Other RFCs have been physically lost. If you have a physical version of RFC 79, 94, 178, 282, 351, 387, 455, 456, 457, 468, 478, 487, 488, 489, 491, 496, 500, 501, 504, 506, 508, 513 and 590, please send us a copy. Thanks

.....................

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

Back to the original mainframe model?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Back to the original mainframe model?
Newsgroups: bit.listserv.ibm-main
Date: Sun, 31 Oct 1999 18:04:29 GMT
not just memory but most other features ... between 3272 and 3274 controllers they even moved a lot of the logic back into the controllers to cut down the per head costs
http://www.garlic.com/~lynn/99.html#28
http://www.garlic.com/~lynn/94.html#23

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

1403 printer on a 1401?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: 1403 printer on a 1401?
Newsgroups: alt.folklore.computers
Date: Fri, 05 Nov 1999 18:15:09 GMT
the N1 cover was hydraulic cover because it was so heavy with soundproofing material .... the problem that almost everybody has experienced is that the cover would automatically raise if something happened unexpectantly inside the printer (like if it ran out of paper) ... and the top of printer was very handy surface for card trays and cups of coffee.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Anti trust suits--IBMs' compared to Microsoft

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Anti trust suits--IBMs' compared to Microsoft
Newsgroups: alt.folklore.computers
Date: Mon, 08 Nov 1999 15:43:15 GMT
little note on PCM (plug compatible) / OEM (other equipment)
http://www.garlic.com/~lynn/93.html#2
http://www.garlic.com/~lynn/98.html#2

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Anti trust suits--IBMs' compared to Mi

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Anti trust suits--IBMs' compared to Mi
Newsgroups: alt.folklore.computers
Date: Mon, 08 Nov 1999 19:14:17 GMT
also ... possibly interesting reference to the ibm case
http://www.garlic.com/~lynn/94.html#44

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
Newsgroups: alt.folklore.computers
Date: Thu, 11 Nov 1999 15:29:55 GMT
silverpelican writes:
I thought it was fair, logical and true. Mainframes are the computer equalivalent of the "rust belt". Crude, huge and close to history.

mainframes seem to be very alive and well & its batch paradigm can even benefit the web; batch paraidgm; programs, systems, subsystems, etc that were designed to run w/o human interaction & unattended. Most of the desktop paradigms and their derivatives tend to have all sorts of stuff revolving around the design point that if something goes wrong I can display an error message to the user ... and the user will fix it (instead of the program handling it automagically).

lots of people see the web as the browser thing that sits on their desktop ... but in fact, large parts of the web, is the stuff that sits in some closed room somewhere, running unattended w/o hiccups for days and months at a time. the mainframe/batch derivatives tend to be much better at that than the interactive derivatives.

also ... gml->sgml->html->xml markup history is as long as the networking history
http://www.sgmlsource.com/history/roots.htm
http://web.archive.org/web/19981206171107/http://www.sgmlsource.com/history/roots.htm

my stuff from the internet history thread earlier this year:
http://www.garlic.com/~lynn/internet.htm

other misc.
http://www.garlic.com/~lynn/96.html#7
http://www.garlic.com/~lynn/96.html#8
http://www.garlic.com/~lynn/99.html#12
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#136
http://www.garlic.com/~lynn/99.html#136a
http://www.garlic.com/~lynn/99.html#163
http://www.garlic.com/~lynn/99.html#184

& for something completely different:
http://www.funsoft.com/

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Life-Advancing Work of Timothy Berners-Lee

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Life-Advancing Work of Timothy Berners-Lee
Newsgroups: sci.econ,comp.ai.philosophy,comp.society.futures,soc.history.science,alt.folklore.computers
Date: Thu, 11 Nov 1999 15:34:15 GMT
genew@shuswap.net (Gene Wirchenko) writes:
Why can't the OS recognize that a process is a zombie and terminate it?

been there ... done that ..
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/95.html#1
http://www.garlic.com/~lynn/97.html#15

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

amusing source code comments (was Re: Testing job applicants)

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: amusing source code comments (was Re: Testing job applicants)
Newsgroups: alt.folklore.computers
Date: Fri, 12 Nov 1999 02:53:42 GMT
wasn't there something about weather bureau datacenter burning and loosing the cray1 and they are currently lost capability of 7day ... they are making do with some fill-in computers ... but are only doing 3day & 4day???

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Life-Advancing Work of Timothy Berners-Lee

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Life-Advancing Work of Timothy Berners-Lee
Newsgroups: alt.folklore.computers
Date: Mon, 15 Nov 1999 18:45:30 GMT
compared to long ago, pathlengths today can be orders of magnitude longer to do the same thing ... put some aspects of the hardware has increased faster than pathlengths have increased ... in other areas the increase hasn't been so noticable.

my old standby ... just going from 68 to 83 ...
http://www.garlic.com/~lynn/99.html#4

in part ... starting to advocate for things like raid architectures.

the difference is even more pronounce another 15 years later.

what might be supported by a 286 class machine 30 years ago
http://www.garlic.com/~lynn/98.html#2

... random posting regarding more recent scale-up
http://www.garlic.com/~lynn/96.html#15

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

Middleware - where did that come from?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Middleware - where did that come from?
Newsgroups: alt.folklore.computers
Date: Tue, 16 Nov 1999 04:12:55 GMT
the first/origin of 3-layer architecture was asked in comp.inforsystems a couple years ago ... the HSDT stuff was the earliest reference that was submitted.

http://www.garlic.com/~lynn/96.html#16
http://www.garlic.com/~lynn/96.html#17

http://www.garlic.com/~lynn/98.html#50

http://www.garlic.com/~lynn/99.html#123

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

Middleware - where did that come from?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Middleware - where did that come from?
Newsgroups: alt.folklore.computers
Date: Tue, 16 Nov 1999 04:34:42 GMT
some of the stuff that I discussed going into the middle layer of the 3-layer architecture

• management
• administration
• problem determination
• fault isolation
• configuration
• non-stop operation
• capacity planning
• accounting
• authentication
• access control
• audit trails
• application interfaces
• software maintenance

much of the "middleware" discussed today are just those things clients &/or client software directly interact with i.e. the application interfaces stuff ... however, in the original architecture I put several things for effective infrastructure operation.

related to various things like
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/96.html#18
http://www.garlic.com/~lynn/99.html#48
http://www.garlic.com/~lynn/99.html#49

the problem in administration is who knows about what ... the mainframe doesn't know about the PCs and the PCs hardly know about the mainframes ... leaving only the middle layer with connectivity, visibility, and awareness into all camps.

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

Non-blocking synch

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Non-blocking synch
Newsgroups: comp.arch
Date: Tue, 16 Nov 1999 05:03:32 GMT
when charlie originally did CAS in the early 70s, it was single argument ... but within very short time, the very first enhancement was to be able to handle two arguments ... giving rise to the arguments being CS & CSD ... while it require the two arguments to be consecutive ... it did allow for paired pointers and other types of operation ... and justified for even non-blocking operations on multi-threaded user level code on uniprocessors (which might have race conditions because of interrupt preemption of different threads)
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/93.html#14
http://www.garlic.com/~lynn/93.html#22
http://www.garlic.com/~lynn/94.html#02
http://www.garlic.com/~lynn/94.html#28
http://www.garlic.com/~lynn/94.html#45
http://www.garlic.com/~lynn/97.html#10
http://www.garlic.com/~lynn/97.html#19
http://www.garlic.com/~lynn/98.html#8
http://www.garlic.com/~lynn/98.html#16
http://www.garlic.com/~lynn/98.html#40
http://www.garlic.com/~lynn/99.html#88
http://www.garlic.com/~lynn/99.html#89

& not quite the original write-ups that got the instruction accepted but ...
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/A%2e6

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

Core (word usage) was anti-equipment etc

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Core (word usage) was anti-equipment etc.
Newsgroups: alt.folklore.computers
Date: Tue, 16 Nov 1999 21:09:21 GMT
135/145 shipped with virtual memory hardware ... but required microload to turn it on ... after ibm announced virtual memory for the 370s (i think the standard 145 panel "light rollers" even had a light with label: "xlate" ... which raised a number of questions prior to announcement).

155/165 had to have field upgrades to add relocate hardware to them.

the original base 370 architecture included selective relocate table entry invalidate instructions (in addition to PTLB). In escalation with architecture, the 370/165 engineers said that it would delay hardware relocated retrofit package by six months if they had to support the selective invalidation instructions. The SVS (aka soon to be MVS) group claimed that an SVS/MVS system would never do more than five page invalidations per second ... so that the difference between selective invalidation and purging the whole lookaside buffer wasn't a critical performance issue ... so selective invalidation was dropped out of base 370 relocate architect on initial announce (and 135/145 microcode had to be retrofitted to not enable the corresponding instructions).

slightly related discussion of sto-stack/look-aside
http://www.garlic.com/~lynn/93.html#8
http://www.garlic.com/~lynn/93.html#25
http://www.garlic.com/~lynn/94.html#46

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

Life-Advancing Work of Timothy Berners-Lee

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Life-Advancing Work of Timothy Berners-Lee
Newsgroups: alt.folklore.computers
Date: Wed, 17 Nov 1999 02:02:26 GMT
Gene Ome writes:
Boy, you sure post a lot.

yes ... there was a joke made of that from postings in the early '80s (by comparison, I've mellowed considerably since then). there was also stanford phd from the mid-80s that was based on analyzing something like 9 months of my postings & email.

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

Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy   Berners-Lee
Newsgroups: sci.econ,comp.ai.philosophy,comp.society.futures,soc.history.science,alt.folklore.computers
Date: Thu, 18 Nov 1999 17:19:00 GMT
note that IP provided the internet characteristic ... there was lots of networking & packet switching before internet ... but it was almost all homogeneous implementation ... all the players in the network communicated by having the same hardware box in the same network.

a big IP contribution in the late '70s were things like the idea of gateways and being able to do internetworking (of non-homogeneous participants).

some of this from similar internet discussion that ran earlier this year in alt.folklore.computers:
http://www.garlic.com/~lynn/internet.htm

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

Life-Advancing Work of Timothy Berners-Lee

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Life-Advancing Work of Timothy Berners-Lee
Newsgroups: sci.econ,comp.ai.philosophy,comp.society.futures,soc.history.science,alt.folklore.computers
Date: Thu, 18 Nov 1999 17:55:43 GMT
we tended to call it graceful degradation ... design for situation were some non-trivial, common failures could occur and it wouldn't be noticed ... and if faced with a catastrophic failure do a fast recovery (tradional disaster/recovery scenerio)

misc. references:
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/99.html#31
http://www.garlic.com/~lynn/99.html#54
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#145
http://www.garlic.com/~lynn/99.html#164
http://www.garlic.com/~lynn/99.html#184

& story/ref about fast restart:
http://www.garlic.com/~lynn/99.html#44
http://www.multicians.org/thvv/360-67.html

& somewhat directly related
http://www.garlic.com/~lynn/99.html#0

for some of the people participating in the XTP/TRB meetings during the late 80s and early 90s ... there was a great deal about protocol not only supporting traditional packet rerouting ... but also reliable multicast ... multiple redundant sources at multiple different physical locations doing reliable multicast to multiple redundant destinations at multiple different physical locations (not only were the networking paths redundant but the senders and receivers were also redundant).

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

Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Computing As She Really Is. Was: Re: Life-Advancing Work of  Timothy   Berners-Lee
Newsgroups: alt.folklore.computers
Date: Thu, 18 Nov 1999 18:04:01 GMT
based the RFCs and the IEN references ... TCP appeared on arpanet and was supported by the host-to-host protocol well before the IP & internetworking with gateway work was done.

from various discussions on the subject at
http://www.garlic.com/~lynn/internet.htm

IEN111 discussing applying IP/internet to the ARPANET:
In the ARPANET case, for example, the internet module would call on a local net module which would add the 1822 leader [2] to the internet datagram creating an ARPANET message to transmit to the IMP. The ARPANET address would be derived from the internet address by the local network interface and would be the address of some host in the ARPANET, that host might be a gateway to other networks.

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

Core (word usage) was anti-equipment etc

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Core (word usage) was anti-equipment etc.
Newsgroups: alt.folklore.computers
Date: Fri, 19 Nov 1999 05:51:06 GMT
the following excerpts from:
http://web.archive.org/web/20010218005108/http://www.isham-research.freeserve.co.uk/chrono.txt

IBM S/360-67      65-08 66-06 10  MOD 65+DAT; 1ST IBM VIRTUAL MEMORY
IBM PL/I LANG.    66-?? 6????     MAJOR NEW LANGUAGE (IBM)
IBM S/360-91      66-01 67-11 22  VERY LARGE CPU; PIPELINED
IBM PRICE         67-?? 67???     PRICE INCREASE???
IBM OS/360        67-?? 67-12     MVT - ADVANCED MULTIPROGRAMMED OS
IBM TSS           67??? ??-??     32-BIT VS SCP-MOD 67; COMMERCIAL FAILURE
1Kbit/chip RAM    68              First commercial semicon memory chip
IBM CP/67         68+?? 68+??     MULTIPLE VIRTUAL MACHINES SCP-MOD 67

....

IBM SW UNBUNDLE   69-06 70-01 07  IBM SOFTWARE, SE SERVICES SEP. PRICED
IBM S/360-195     69-08 71-03 20  VERY LARGE CPU; FEW SOLD; SCIENTIFIC
IBM 3330-1        70-06 71-08 14  DISK: 200MB/BOX, $392/MB
IBM S/370 ARCH.   70-06 71-02 08  EXTENDED (REL. MINOR) VERSION OF S/360
IBM S/370-155     70-06 71-01 08  LARGE S/370
IBM S/370-165     70-06 71-04 10  VERY LARGE S/370
IBM S/370-145     70-09 71-08 11  MEDIUM S/370 - BIPOLAR MEMORY - VS READY
AMH=AMDAHL        70-10           AMDAHL CORP. STARTS BUSINESS
IBM S/370-135     71-03 72-05 14  INTERMED. S/370 CPU
IBM S/360-22      71-04 71-07 03  SMALL S/360 CPU
IBM LEASE         71-05 71 06 01  FixTERM PLAN;AVE. -16% FOR 1,2 YR LEASE
IBM PRICE         71-07 71+?? +8% ON SOME CPUS;1.5% WTD AVE. ALL CPU
IBM S/370-195     71-07 73-05 22  V. LARGE S/370 VERS. OF 360-195, FEW SOLD
Intel, Hoff       71              Invention of microprocessor
IBM MVS-JES3      72+?? 75-10     LOOSE-COUPLED MP (ASP-LIKE)

IBM VSAM          72+?? 7?-??     NEW RANDOM ACCESS METHOD
IBM VM ASSIST     72+?? 7?-??     MICROCODE ASSIST FOR VM/370
IBM 3705          72-03 72-06     COMMS CNTLR: 352 LINES; 56KB/SEC
IBM S/370 VS      72-08 73-08 12  VIRTUAL STORAGE ARCHITECTURE FOR S/370
IBM 135-3         72-08 73-08 12  INTERMED. S/370 CPU
IBM 145-3         72-08 73-08 12  INTERMED. S/370 CPU
IBM 158           72-08 73-04 08  LARGE S/370, VIRTUAL MEMORY
IBM 168           72-08 73-08 12  VERY LARGE S/370 CPU, VIRTUAL MEMORY
IBM OS/VS1        72-08 73-??     VIRTUAL STORAGE VERSION OF OS/MFT
IBM OS/VS2(SVS)   72-08 72+??     VIRTUAL STORAGE VERSION OF OS/MVT
IBM OS/VS2(MVS)   72-08 74-08     MULTIPLE VIRTUAL ADDRESS SPACES
IBM VM/370        72-08 72+??     MULTIPLE VIRTUAL MACHINES (LIKE CP/67)
IBM 125           72-10 73-04 06  SMALL S/370 CPU
IBM MVS-JES2      72-?? 72-08     JOB-ENTRY SUBSYSTEM 2 (HASP-LIKE)

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

AES cyphers leak information like sieves

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: AES cyphers leak information like sieves
Newsgroups: sci.crypt
Date: Fri, 19 Nov 1999 17:51:10 GMT
a lot of hardware transmission gear currently incorporates various kinds of FEC ... typically something like reed-solomon or viterbi. long ago & far away we worked on doing standard hardware 15/16ths reed-solomon & then on selective resend, transmit the 1/2rate viterbi ... instead of the original block.

on links with bit-error-rate (BER) of 10-**9, 15/16ths reed-solomon can give six orders of magnitude correction ... i.e. resultiing in BER 10-**15.

by sending the 1/2rate viterbi on selective resend ... instead of the original message ... there is still high probability of message recovery even if both individual messages have uncorrectable transmission errors (also the total number of bits transmitted is the same as in the simple selective resend protocol).

this was applying FEC to the encrypted message. wouldn't work in the simple hardware link encryptor desings ... since the selective resend logic wouldn't have access to the original encrypted message for calculating the 1/2rate viterbi FEC.

monitoring the frequency of transmission errors ... the process could decide to switch from selective resend of the 1/2rate viterbi ... to alwas transmitted the 1/2rate virturbi with the original message (pretty lossy conditions ... say BER 10-**2). Trade-off of loosing half the effective thruput vis-a-vis overhead of doing selective resend.

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

How did you learn to program?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: How did you learn to program?
Newsgroups: comp.lang.misc,comp.ai.edu,rec.arts.sf.science,sci.edu,alt.folklore.computers
Date: Sat, 20 Nov 1999 16:46:35 GMT
uj797@victoria.tc.ca (Arthur T. Murray) wrote:
>> For those of you who are computer professionals,
>> how did you learn your job? College? Grad School?
>> On the job training? Self taught? Online classes?


spring of my sophmore year, took a 2credit hr introduction to programming fortan course, that summer was hired by the computing center to design and write a 360 assembler monitor (i.e. my own operating system with interrupt handler, device drivers, task manager, storage management, command processor, etc) for doing tape<->print/punch/cardreader operation; turned out to be about 6k bytes. the following fall got part-time job as prof's assistant on advance programming courses. following summer was hired by the computing center to be responsible for all the systems & subsystems.

misc.
http://www.garlic.com/~lynn/98.html#9
http://www.garlic.com/~lynn/98.html#49

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

GEOPLEX

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: GEOPLEX
Newsgroups: bit.listserv.ibm-main,alt.folklore,computers
Date: Sun, 21 Nov 1999 21:07:03 GMT
long ago & far away we had that problem with JES2 link between STL and Hursley being switched from a land-line to a double-hop satellite link. They brought up JES2 pair on the link and couldn't establish a connection ...so they stopped and brought up VNET on the link and everything would transfer fine w/o any errors. They dropped the link and brought up pair of JES2 again and were unable to establish a connection. Somebody's conclusion was that the line was full of errors and VNET was just too stupid to realize it (of course the problem was that JES2 had a keep-alive ping that had time-out shorter than the satellite double-hop round trip).

misc. references (including hardware FEC for reliable transmission, also frequently used in many satellite systems):
http://www.garlic.com/~lynn/99.html#210
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#77
http://www.garlic.com/~lynn/99.html#91
http://www.garlic.com/~lynn/99.html#110
http://www.garlic.com/~lynn/99.html#145
http://www.garlic.com/~lynn/99.html#184
http://www.garlic.com/~lynn/99.html#209

gad writes:
>Can I have a GEOPLEX player several thousand miles away and have >a minimum of 1 structure list i.e. logger?

No. No can do.

There is a finite limit to the distance allowed for the communication protocols used for the Sysplex Timer and Coupling Facility, which is the limiting factor to a Geographically dispersed Sysplex. Greg

Greg Dyck IBM Poughkeepsie, OS/390 BCP Platform team


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

Why is Pascal no longer a leading development Language?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Why is Pascal no longer a leading development Language?
Newsgroups: comp.programming
Date: Thu, 25 Nov 1999 19:02:59 GMT
most of the pascal's are weak in several areas ... a couple years ago i did a port of a 60,000+ statement pascal application to a different platform ... my impression was it was probably the largest application ever processed by the target platform's pascal ... i was in contact with the platform vendor a couple times a week during the port with bugs

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

Ask about Certification-less Public Key

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Ask about Certification-less Public Key
Newsgroups: sci.crypt
Date: Fri, 26 Nov 1999 17:33:01 GMT
"Lyal Collins" writes:
I think you are talking about a Public Key registered or stored with a counter-part.

When you exchange messages, the counter-part retrieves your public key and uses it to verify a message signature. You no longer have to send around your public key or certificate, saving a lot of bandwidth - 5kbytes/message.

Search for AADS or ANSI X9.59 to see a standard that uses this model.

The deployment costs are similar - you need a secure database, and a reliable, trusted registration process to store the public key.

the deployment costs are similar if you are starting from scratch ... however if you already have a secure infrastructure (like for financial transactions) ... the incremental costs to upgrade the existing facility may only be a couple percent and the public key specific operationl costs of the overall infrastructure may can even be a smaller percentage.
http://www.garlic.com/~lynn/aadsmail.htm#variations
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1

other opportunities possible for incremental costs is to leverage the existing pin debit ... where the card is personalized, pin is securely recorded, handled, and transmitted. Incremental costs for adding a chip to magstrip card, generating key pair, and securely recording public key is also rather small. In many respects, the shared-secret/pin actually requires higher integrity processes than corresponding processes for public key (i.e. the infrastructure isn't compromised just by learning a person's public key).
http://www.garlic.com/~lynn/aadsm2.htm#straw

the scenerio is that it is possible to deploy PKI small pilots for relatively small up front investment ... much less than the 2%-3% costs to modify an existing infrastructure (public key enabling an existing infrastructure is well under the Y2K remediation costs).

Claim has alwas been that the trade-off cross-over is approx. when the public key enabled market penetration exceeds 4%-5% it becomes much less expensive to modify the existing infrastructure than building a new infrastructure from scratch.

the biggest actually costs is the customer call center ... general consumer market expectation is that they have a 1-800 to contact if anything hiccups (one of the things that small pilots frequently pass over).

misc. other references:
http://www.garlic.com/~lynn/aadsover.htm
http://www.garlic.com/~lynn/aadswp.htm

& of course
http://www.garlic.com/~lynn/

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

Ask about Certification-less Public Key

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Ask about Certification-less Public Key
Newsgroups: sci.crypt
Date: Fri, 26 Nov 1999 17:46:45 GMT
... also ....

Subject: AADS/X9.59 cost sharing intuition

Several times at X9A10 meetings there have been statements about the advantages of infrastructure cost sharing associated with AADS operation.

assertion #1: majority of a certificate authority is account-based management

assertion #2: cryptography for digital signature infrastructure can be added to existing financial account infrastructure at 1%-5% of the cost of the current infrastructure

corollary: cost sharing with integration of digital signatures into an existing financial account based infrastructure will have existing non-digital signature applications carrying 95%-99% of the total account costs.

assertion #3: high value digital signature financial applications can carry 90%-95% of the digital signature infrastructure cost

corollary: non-financial application use of a integrated financial digital signature infrastructure can be done at 1/200th to 1/2000th the per account cost of an independent non-financial digital signature infrastructure.

In a financial AADS infrastructure:

fraction of account costs covered by non-digital signature applications

.95 to .99

fraction of account costs covered by digital signature applications

.05 to .01

fraction of digital signature account costs covered by financial digital signature applications

.90 to .95

fraction of digital signature account costs covered by non-financial digital signature applications

.10 to .05

fraction of account costs covered by non-financial digital signature applications

.1*.05 to .05*.01 or .005 to .0005 (1/200th to 1/2000th)

This is applicable to the integration and use of AADS/X9.59 in an existing financial account infrastructure.

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

Ask about Certification-less Public Key

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Ask about Certification-less Public Key
Newsgroups: sci.crypt
Date: Fri, 26 Nov 1999 23:23:39 GMT
also, at recent FSTC/FAST meeting where we were discussing a number of AADS implementations (www.fstc.org) there was also reference to NPKI project in michigan (i.e. no public key infrastructure, i.e. public keys ... but not public key infrastructure as currently commonly constituted).

there was also an AADS Radius demo'ed at PC/EXPO in NYC last spring (i.e. radius is the dominant authentication mechanism thruout the world).

AADS for all electronic retail financial transactions, aka X9.59 ... to preserve the integrity of the financial infrastructure for all eelectronic retail payments with digital stignature, at least both debit & credit (while preserving privacy).
http://www.garlic.com/~lynn/

AADS for non-financial electronic commerce transactions (age, address, location, eligibility). FSTC/FAST:
http://www.fstc.org/

AADS Radius for majority of all internet authentication transactions.
http://www.garlic.com/~lynn/

there is also various activities involving AADS for all wholesale financial transactions and various kinds of business-to-business operations.

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

AADS/X9.59 demo & standards at BAI (world-wide retail banking) show

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@adcomsys.net (Anne & Lynn Wheeler)
Subject: AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
Newsgroups: gov.us.topic.ecommerce.standards
Date: 1 Dec 1999 13:41:33 -0500
AADS X9.59 (reference implementation) integrated with one of the major web merchant systems looks like it will be demo'ing in several booths at next week's BAI show in miami. It will use aads digital signature chipcard for signing the x9.59 transaction.

In addition, the AADS FSTC/FAST-like demos are also working, i.e. age, location, etc. and will be at the show (for instance allowing verification of non-minor status before allowing to proceed at a website). This will be able to use the same aads digital signature chipcard.

The only demo that might not make to the show is the AADS RADIUS demo (i.e. RADIUS is utilized by the majority of internet service providers around the world to authenticate connections by their customers ... as well as the major method for dial-in authentication to corporate intranets). This will also will work with the same AADS digital signature chipcard.

The AADS operations can be done securely w/o divulging privacy information. X9.59 financial transactions can be w/o requiring name & address. Signed AADS shipping transactions can be done allowing web sites to ship hard goods w/o requiring name&address. Minor/non-minor status can be affirmed w/o divulging name&address. Location for shipping costs & sales takes can be provided w/o divulging name&address

The AADS Policy & Practices consistency writeup is available at
http://www.garlic.com/~lynn/

several of the privacy issues have been discussed previously on various mailing lists and are selected postings are also archived at
http://www.garlic.com/~lynn/

X9.59 is an emerging standard of the ANSI Financial Standards body:
http://www.x9.org/

FSTC/FAST is effort to expand the financial authentication infrastructure to areas other than payment transactions.
http://www.fstc.org/

There has been similar AADS activity out of NACHA
http://web.archive.org/web/20020122082440/http://internetcouncil.nacha.org/

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

Mainframe acronyms: how do you pronounce them?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Mainframe acronyms: how do you pronounce them?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 02 Dec 1999 16:49:42 GMT
i was doing support at customer site in fall of '69 when we were selected to be one of the original CICS beta-test sites ... it was for an online library catalogue project. i seem to remember that hard C was "Customer" had hard C (but that was a long time ago).

one of the first bugs I had to shoot was CICS BDAM open was failing on some of our files.

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

Study says buffer overflow is most common security bug

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Study says buffer overflow is most common security bug
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 30 Nov 1999 23:12:16 -080
ever since we started ha/cmp in the late 80s ... we've been making that claim ... & in many cases it is severely aggravated by C-language convention null terminated implicit string lengths.

misc. other reference:
http://www.garlic.com/~lynn/99.html#163

--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com http://www.garlic.com/~lynn/

VM History

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: VM History
Newsgroups: bit.listserv.vmesa-l
Date:    Sat, 4 Dec 1999 10:18:50 -0800
there also have been lots of s/360 threads in alt.folklore.computers ... & in one of those threads
http://www.garlic.com/~lynn/99.html#209

there is URL pointer that has hardware & software announcement & ship dates

--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com http://www.garlic.com/~lynn/

VM History

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: VM History
Newsgroups: bit.listserv.vmesa-l
Date:    Sat, 4 Dec 1999 10:19:05 -0800
and slightly more network related ... but with some VM content:
http://www.garlic.com/~lynn/99.html#109
http://www.garlic.com/~lynn/99.html#112
http://www.garlic.com/~lynn/99.html#113

& some of the internet/network specific thread
http://www.garlic.com/~lynn/internet.htm

--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com http://www.garlic.com/~lynn/

Looking for a (working) PERQ

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Looking for a (working) PERQ
Newsgroups: alt.folklore.computers,alt.sys.perq
Date: Tue, 07 Dec 1999 15:11:12 GMT
slightly PERQ related .... in the following reference
http://vm.marist.edu/~piper/party/jph-12.html#wheeler

there is mention of different groups reviewing the proposal for a new workstation ... and all of the groups concluded what they were doing was better than the proposal and so the proposed new workstation (SUN) didn't need to be done.

the workstation group that participated in the evaluation was using mostly/all PERQs. One of the PERQ demos that i remember was a phone application.

the perq would pull off the calling phone number on the incoming call and show it in a pop-up window on the PERQ. numbers could also be looked up in a directory and if found also display the person's name. I also seem to remember you could classify numbers and associate activity with them ... send the call directly to phone mail, only display the window, play a specific ring/tune, play a specific message at phone mail, etc. For outgoing ... you could give a name ... and it would look up the number and do the dialing. In phone mail ... you could look at the phone mail log, it would give the incoming number, person's name if available, date/time of the call, length of recorded message, whether the message had been heard, etc.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Paradigm Shifted (was: Re: BBSs vs. The Internet)

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Paradigm Shifted (was: Re: BBSs vs. The Internet)
Newsgroups: alt.folklore.computers
Date: Fri, 10 Dec 1999 14:59:43 GMT
agree ... one of the motivations for doing the IOS rewrite and getting an operating system that could tolerate the disk/dasd engineering & product test labs was to be able to co-op the remaining CPU (say 95%) on whole slew of really big mainframes.

misc ref (some even posted from lynn@netcom.com ... which is still active, I think I first got "lynn" in '92 ... even tho it was a intra-lata per minute call ... they didn't have local access for the next town just south of san jose):
http://www.garlic.com/~lynn/94.html#15
http://www.garlic.com/~lynn/95.html#3
http://www.garlic.com/~lynn/97.html#15

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

X9.59/AADS announcement at BAI this week

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: X9.59/AADS announcement at BAI this week
Newsgroups: alt.technology.smartcards
Date: Fri, 10 Dec 1999 23:54:33 GMT
managed to get announcement at BAI this week (www.bai.org). Have demos for X9.59 transactions (retail payments, credit, debit, check, etc). First draft talked about both point-of-sale and internet ... but things got simplified when the final press release went out. Also wed's American Banker had a front page article.

demos at BAI include both financial transactions as well as privacy broker transacrtions (provide adult/minor status and address for shipping companies ... w/o having to divulge name, address and/or other personal details at web sites).

A similar AADS announcement was made by nacha about a month ago:
http://web.archive.org/web/20020122082440/http://internetcouncil.nacha.org/

Work also been done on integrating AADS support into RADIUS (what the majority of the internet service providers and corporate intratnets use for authenticating access).

This provides for the same AADS infrastructure to support financial transactions, privacy broker transactions as well as internet/intranet access and web server access.

other details on AADS and X9.59 can be found at
http://www.garlic.com/~lynn/

====================================
Media Contacts:

First Data Corp.: Caroline Hoke, (770) 857-7178, caroline.hoke@firstdatacorp.com CyberSafe: Steve Birge, (425) 837-1057, steve.birge@cybersafe.com TSA: Joel Molyneaux, (402) 778-1590, molyneauxj@tsainc.com Interworld: Chris Faust, chrisf@interworld.com

Six Companies Announce Plans to Support Proposed Digital Payments Industry Standard First Data Corp., Compaq, TSA, Certicom, InterWorld and CyberSafe cooperating to develop AADS digital payments infrastructure

MIAMI - Dec. 7, 1999 - A group of leading technology companies today announced its support and plans to develop the Account Authority Digital Signature (AADS) and proposed ASC X9 digital payments standard. First Data Corp., Compaq Computer Corp., Transaction Systems Architects (TSA) Corp., Certicom, InterWorld and CyberSafe together made the announcement at the Bank Administration Institute (BAI) Retail Delivery 1999 Conference here.

These companies are developing solutions for a secure digital payments infrastructure based on AADS, to be used on either the Internet or at point-of-sale terminals. A demonstration - including a reference implementation and Internet-based merchant web site - is available at the conference. (To make an appointment to see the demo, visit booth #1242.)

An implementation of this secure digital payments solution uses a smart card and personal identification number (PIN), that, when combined, provide a secure "digital signature" for purchases transacted either on the Internet or at a point-of-sale terminal. The PIN activates the signing key in the smart card to give each transaction a unique digital signature. Once initiated, the secure transaction is authenticated as being uniquely associated with the buyer, and is securely transferred through the authentication process.

This digital signature system provides the purchaser with a greater degree of security and privacy than traditional systems while simultaneously providing the merchant with greatly reduced charge-back and transaction repudiation. With AADS, the card issuer, which has the existing consumer relationship, handles both the authentication and the transaction authorization. By eliminating the need for third-party authorization, the theft of credit card content and information - including numbers on the Internet - is reduced. The AADS solution applies equally to credit card or debit card processing.

"First Data is supporting this and other security and authentication solutions and protocols desired by consumers, merchants and bank card issuers. We are committed to ensuring that electronic transactions - whether over the Internet or at the point of sale - are as safe and secure as possible," said Lee Adrean, executive vice president of First Data Corp. and responsible for the company's Internet Commerce initiatives.

"CyberSafe and First Data have been working together to meet an important market requirement for digital payments - security infrastructures that provide a worry-free environment for consumers and merchants in conjunction when using real or virtual smart cards" said Jim Cannavino, chairman and CEO of CyberSafe Corp. "CyberSafe believes that AADS is the basis for financial settlement, security, and on-line shopping experiences that directly address consumer security and privacy concerns as well as eliminate merchant concerns related to charge-backs and repudiation of charges".

Each of the companies supporting the statement of direction will contribute a unique and important part of the infrastructure:

§ First Data Corp. intends to support its customers by providing AADS-enabled transaction processing services and smart cards.

§ TSA intends to support AADS in software and services based on its BASE24®, i24™ and e24™ product lines, with particular focus on implementation of a "PIN Debit on the Internet" capability.

§ Certicom intends to provide the elliptical curve encryption technology for smart card and authentication engines.

§ Compaq currently ships certain components of the Compaq desktop, server, and laptop product lines enabled for reading/signing AADS smart cards. Compaq also provides the Compaq NonStop? Himalaya S-series product line that supports TSA BASE24® software product offerings.

§ InterWorld intends to offer digital signature support as part of its web site development offerings.

§ CyberSafe will enable security for AADS, by providing e-commerce application developers a software development kit (SDK) and other security infrastructure products and services to enable rapid deployment of an AADS infrastructure.

About First Data

Atlanta-based First Data Corp. (NYSE: FDC) helps move the world's money. As the leader in electronic commerce and payment services, First Data serves more than two million merchant locations, 1,400 card issuers and millions of consumers, making it easier, faster and more secure for people and businesses to buy goods and services. For more information, please visit the company's web site at
http://www.firstdatacorp.com/.

About InterWorld

InterWorld Corporation is leading the Enterprise Commerce movement that enables businesses to compete and evolve in today's new digital economy. With InterWorld's Commerce Exchange solution, manufacturers, distributors and retailers can get to market quickly, scale to meet growing demands, as well as, evolve to keep pace with changing market conditions and customer demands. For more information, visit
http://www.interworld.com/
http://web.archive.org/web/20000229152004/http://www.interworld.com/

About TSA

Transaction Systems Architects' (NASDAQ:TSAI) software facilitates electronic payments by providing consumers and companies access to their money. Its products are used to process transactions involving credit cards, debit cards, smart cards, home banking services, checks, wire transfers as well as automated clearing and settlement. TSA solutions are used on more than 3,200 product systems in 75 countries on six continents. For more information, visit
http://www.tsainc.com/

About Certicom

Certicom is a leading provider of next-generation encryption technology used to build strong, fast, and efficient security solutions. Major computing and communications companies, such as 3Com/Palm Computing, BellSouth Wireless Data, Hewlett-Packard, Motorola, Pitney Bowes and VeriFone, incorporate Certicom technology into electronic commerce software, wireless messaging applications, and smart cards. For more information, visit
http://www.certicom.com/

About Compaq

Compaq Computer Corporation is the second-largest computer company in the world and the largest global supplier of computer systems. Compaq develops and markets hardware, software, solutions, and services, including industry-leading enterprise computing solutions, fault-tolerant business-critical solutions, enterprise and network storage solutions, commercial desktop and portable products, and consumer PCs. Customer support and information are available at
http://www.compaq.com/

About CyberSafe

CyberSafe is a privately held corporation founded in 1991. Its award-winning TrustBroker? Security Suite, Defensor®, and Centrax? product lines are designed to enable secure electronic business, while reducing administration costs. CyberSafe is headquartered in Issaquah, Wash., and on the World Wide Web at
http://www.cybersafe.com/
For additional information, please send requests to info@cybersafe.com.

# # #

CyberSafe, Defensor and the CyberSafe logo are registered trademarks of CyberSafe Corporation and its wholly owned subsidiaries. TrustBroker and Centrax are trademarks of CyberSafe Corporation and its wholly owned subsidiaries. All other products and trademarks are the property of their respective owners.


--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

BBSs vs. The Internet

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: BBSs vs. The Internet
Newsgroups: alt.folklore.computers
Date: Sat, 11 Dec 1999 02:23:28 GMT
Dave writes:
Remember, YOU were a "Great Unwashed" at one time, too. Someone somewhere was pissing and moaning when YOU posted YOUR first message!

Dave


in the late '70s i worked on the precursor to listserv ... and a lot of people started moaning about some of my messages when they begain to realize that it was more like tv broadcast than person-to-person letters (which had been the perception during most of the 70s)

minor references:
http://www.garlic.com/~lynn/95.html#7
http://www.garlic.com/~lynn/97.html#2
http://www.garlic.com/~lynn/internet.htm

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/

Attacks on a PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Attacks on a PKI
Newsgroups: sci.crypt
Date: Sun, 12 Dec 1999 16:46:08 GMT
lcs Mixmaster Remailer writes:
PKI is Public Key Infrastructure. Fundamentally this is any system for determining the validity of a public key for some intended purpose.

more specifically, PKIs have tended to have an offline email design point from the early to mid 80s, i.e. you connected to a store&forward node, exchanged email, disconnected and processed your email. The email was somewhat assumed to be from various & random entities, including entities that you had no prior knowledge of. The authentication solution was to have an appended credential (analogous to letters of credit from financial institutions in the sailing ship days, before fax machines and telephones) from recongized institution which asserted authentication & possibly identification characteristics bound to a public key. The message could be authenticated with the public key carried in the appended credential, and the characterisitcs asserted in the credential could be assocated with the message (based on the implied trust in the credential issuing institution and the applicability of the attributes in the credential to the requirements of the relying party).

much of many PKIs are pretty much orthogonal to existing online authentication infrastructures, many of which are currently shared-secret based and could be incrementally upgraded from shared-secret authentication to public key authentication w/o introducing PKI and/or changing existing business policies and practices.

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

Why couldn't others compete against IBM?

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Why couldn't others compete against IBM?
Newsgroups: alt.folklore.computers
Date: Mon, 13 Dec 1999 04:04:39 GMT
misc. reference:
http://www.garlic.com/~lynn/94.html#44

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

Attacks on a PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Attacks on a PKI
Newsgroups: sci.crypt
Date: Mon, 13 Dec 1999 23:13:46 GMT
Helger Lipmaa writes:
Secure electronic commerce necessitates wide-scale employment of public-key cryptography that, in turn, requires secure and efficient methods of certificate management in the {Public-Key Infrastructure} (PKI). Most of the known techniques for the latter

AADS looks at just upgrading existing online authentication schemes from shared-secret to public-key ... which inherits infrastructure improvements from the transition from shared-secret to public-key.

certificates provide great introductory credentials for offline comfort involving parties that have no previous knowledge of each other and/or no prior business relations.

however, certificates have poor transactional characteristics in both consumer<->business e-business and business<->business e-business (simple offline analogy is oldtime purchase department checks with printed "signing" limit authority ... of something like $5,000 until they discovered $1m projects were being funded by signing 200 such checks, i.e. aggregation involves online accounts).

also in the consumer to business e-business, consumer certificates tend to violate all sorts of privacy guidelines. solutions have been things like relying-party-only certificates ... with only identifier is the account number. In this scenerio, the account record has to be "hit" ... in which case it can be trivially shown that certificate is at least redundant and superfluous and likely also introducess unnecessary risk.

In general, AADS has gone to great deal of trouble to support KISS (several observations have then that is is frequently much harder to do something simply than to do something in complex fashion).

To some extent we did violate the KISS principle in the convoluted mapping of Certification Authority policies and practices; we started by defining a CA-based infrastructure with certificates ... and then using existing CA policies and practices show that a certificate doesn't actually exist in that portion of the business operation. From that build a whole e-business series of certificate-based operations where the certificate(s) never actually appears.

for those interested in such convoluted exercises (as opposed to straight-forward KISS) see the business policies & practicies discussion at
http://www.garlic.com/~lynn/

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

Digital Signature on SmartCards

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Digital Signature on SmartCards
Newsgroups: alt.technology.smartcards
Date: Tue, 14 Dec 1999 01:17:55 GMT
is the question about digital signatures with smartcards or x.509 certificates on smartcards? they aren't the same.

at BAI last week (world-wide retail banking show) we had smartcards demo'ing digital signatures for financial transactions (financial industry retail payment standard) and privacy broker transactions (as mentioned in this NG a couple days ago). The only demo missing was for AADS RADIUS digital signature authentication ... for doing all ISP and webserver access.

the smartcards had no x.509 certificates and/or any need for such things for doing high integrity transactions.

for recap and some related material see:
http://www.garlic.com/~lynn/

and more recently discussion on sci.crypt about PKI "problems"
http://www.garlic.com/~lynn/99.html#226

& ietf-pkix with respect to high integrity AADS chipcards and bio-sensors
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3

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

Radius Help help!!!

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Radius Help help!!!
Newsgroups: comp.security.misc
Date: Tue, 14 Dec 1999 17:11:49 GMT
look at http://www.garlic.com/~lynn/ ... pick out IETF/Internet std information, select TERM index, and pickout RADIUS from the Acronym fastpath, that will give you all the current RADIUS RFCs.

RADIUS is only used by the majority of ISPs and corporate intranets around the world for authenticating connections.

random other URL
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/cs_unx/csu212ug/nasconra.htm

or try any of the search engines for RADIUS

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

Why couldn't others compete against IBM?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Why couldn't others compete against IBM?
Newsgroups: alt.folklore.computers
Date: Wed, 15 Dec 1999 18:32:49 GMT
from reference ...
http://www.garlic.com/~lynn/94.html#44

I ran across this description at the time of the government anti-trust suit (in the early '70s) ... I never ran across any validation/repeat, so I don't know if it is real:
An "expert witness" representing one of the companies (that left the business) testified regarding the state-of-the-art in the late 50s. Supposedly in the late 50s ALL of the computer companies realized the SINGLE MOST IMPORTANT criteria to be successful in the computer business was to have compatibility across the whole computer line, from entry level to the largest machine. The witness went on to observe that only one company was successful in meeting this goal, all the other companies failed. The remaining companies failed to adequately deal with multiple plant operations (each responsible for a particular model in the product line) that locally optimized the hardware architecture/implementation for the specific model.

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

Need Unix system call to get the CPU time taken by a thread

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Need Unix system call to get the CPU time taken by a thread
Newsgroups: comp.programming.threads
Date: Thu, 16 Dec 1999 04:11:11 GMT
there are times when what I get back from unix system call wasn't sufficient &/or didn't take into account all the effects.

For those environments ... & to do a sanity check on whether the cpu gotten really represents all CPU consumed by the operation I created a background application that was in a tight cpu loop that took a measurable amount of real time) when there was no other activity on the system).

I then ran the base case operation while the background task was operational and noticed the increase in elapsed real time for the background task. This represents the aggregate of all cpu resources needed by the base case operation (regardless of how/where/when the CPU time was being accounted for).

I then would run the incremental cases, taking note of the increase in the background task elasped real time for each incremental case.

the base case & the incremental cases might involve some number of interative operations ... given the noted increase in background elapsed time being representative of the CPU used for the task/cases, and the counted number of iterations in each case, ... it is possible to calculate the per interation CPU required.

IN the thread/no-thread case ... the a no-thread run could be taken as the base case, and the threaded run would represent the incremental case.

This process may be more useful on a server system where some amount of the workload operation (for instance low level LAN & network drivers) may be going on in the kernel and not directly charged off against a specific user task ... and result in a much more comprehensive measurement for capacity planning purposes.

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

Computer of the century

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.unisys
Date: Wed, 29 Dec 1999 19:25:42 GMT
from posting earlier this year:
http://www.garlic.com/~lynn/99.html#24

1.In 1969, Continental Airlines was the first (insisted on being the first) customer to install PARS. Rushed things a bit, or so I hear. On February 29, 1972, ALL of the PARS systems cancelled certain reservations automatically, but unintentionally. There were (and still are) creatures called "coverage programmers" who deal with such situations.

2.A bit of "cute" code I saw once operated on a year by loading a byte of packed data into a register (using INSERT CHAR), then used LA R,1(R) to bump the year. Got into a bit of trouble when the year 196A followed 1969. I guess the problem is not everyone is aware of the odd math in calendars. People even set up new religions when they discover new calendars (sometimes).


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

Computer of the century

Refed: **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers
Date: Wed, 29 Dec 1999 19:35:42 GMT
first mini that i worked with was interdata/3 ... circa late '60s.

we built a 360 channel attachment card for it and programmed it to be 360 telecommunications controller

minor ref:
http://www.garlic.com/~lynn/96.html#4
http://www.garlic.com/~lynn/99.html#12

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

Attacks on a PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Attacks on a PKI
Newsgroups: sci.crypt
Date: Wed, 29 Dec 1999 19:54:40 GMT
"Lyal Collins" writes:
Authentication of individuals using PKI is about as strong as the passwords they use to control access to their priate key.

Why not stick to passwords and integrity checking databases, for non-ecommerce uses?

Lyal


strictly shared-secret based systems tend to have the shared-secret in a lot more places and have a lot simpler exploit modes ... shared-secrets can be be attacked with social engineering (i.e. call the person and tell them you are bank examiner and need to test the bank's security & ask them for their bank account number and their mother's maiden name ... or call and tell them you are the ISP security manager and need to test their login account).

Account Authority Digital Signature (AADS) public key ... eliminates those exploit modes, preserves existing authentication business processes and establishes the basis for parameterised risk management.

In the paramemterized risk management portion ... the AADS public protocol and processes can be the same across a wide-range of business processes & requirements ... but the risk parameters are adjusted based on the integrity level of the environment housing the private key and doing the digital signing (simple example is credit limit and transaction authorization are different whether the private key is a PC housing with password access ... or a separate 140-3 smartcard with both PIN and biometrics).

This is easily generalized to authentication infrastructure ... using the same infrastructure for things like financial transactions, web access, & ISP login (straight-forward RADIUS enhancement) ... all sharing the same technology infrastructure and level of integrity adjusted to meet the requirements of the business.

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

Attacks on a PKI

From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Attacks on a PKI
Newsgroups: sci.crypt
Date: Wed, 29 Dec 1999 19:57:40 GMT
... and of course ... lots of AADS description and discussion at
http://www.garlic.com/~lynn/

& recent X9.59/AADS announcement
http://www.garlic.com/~lynn/99.html#224

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

I can't believe this newsgroup still exists

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: I can't believe this newsgroup still exists.
Newsgroups: alt.os.multics
Date: Wed, 29 Dec 1999 21:58:06 GMT
westin*nospam@graphics.cornell.edu (Stephen H. Westin) writes:
As for concepts introduced in MULTICS,

o The single-level store was adopted by IBM's mid-level AS/400. The invocation of programs as command names, allowing simple extension of the command language, also came from Multics.


TSS/360 had page-mapped file characteristic which dates from 67/68 time-period. A early TSS problem with single-level store is that it had poor file semantics hints to the paging system (i.e. sequential file access patterns did really poorly using an LRU replacement algorithmn ... especially on memory constrained configurations).

CMS/360 had invocation of programs as command names from the cp/40 days ... say 65 (going on in the same building as Multics ... but more due to a common heritage than one getting it from the other).

IBM Future System project that went on in the early '70s drew on the above plus everything else it could find (including Multics, even tho no product ever shipped).

Numerous FS and CMS people eventually turned up in IBM Rochester and did the S/38 with the characteristics that also propagated into the S/38 follow-on, the AS/400.

some of this from VM history paper at:
http://www.leeandmelindavarian.com/Melinda/

misc. other
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/99.html#44
http://www.garlic.com/~lynn/99.html#100
http://www.garlic.com/~lynn/99.html#126
http://www.garlic.com/~lynn/99.html#127

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

Attacks on a PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Attacks on a PKI
Newsgroups: sci.crypt
Date: Thu, 30 Dec 1999 01:30:56 GMT
"Lyal Collins" writes:
I have yet to see such a simple policy approach address what I call the 30 - 1million issue. i.e. Why should the rules for 30 people doing $1m transactions be different from those for 1 million people doing $30 transactions?

The overall business or systemic risks are approxiamently equivalent.


some of the attack points are the same and some are different.

the old style checks with signing limits has been one model proposal for certificate pki ... build into the certificate language similar to signing limits. the attack point turned out to be aggregation ... certificates can be used for atomic operations but have very poor operational characteristics where aggregation can be involved (fraud where somebody with a $5000 signing limit discovered that they could do million dollar transactions by writing 200 checks)

for the points that are in common to the different transaction types (a million $30 transactions or 30 million dollar transactions) need to have similar integrity levels ... and it does need to be account based to handle aggregation-like issues.

an AADS signing chip is an attack point for a specific account ... not for the infrastructure as a whole (for one thing it doesn't have any system-wide shared-secret &/or systemic risk characteristics). the integrity of any single chip has to be compareable to the benefit gained from attacking it. A specific AADS signing chip might possible have parameterised risk management specifying things like the maximum individual transaction size, the transaction velocity, the maximum aggregated number of transanctions in some interval and the maximum aggregated value of transactions in some interval.

the transaction authorization and execution infrastructure has to have integrity compareable to the aggregation of all possible transactions it might process ... however any single AADS signing chip only needs integrity compareable to the transactions that the specific chip might be used for.

The AADS case has been that the account-based transaction authorization and execution infrastructure for financial operations has to exist regardless of any other operational characteristics. Given that such an account-based infrastructure has to exist, then it is trivially shown that having CA & certificates as part of that infrastructure's transactions represents redundant and superfluous operations and needlessly increases the infrastructure's systemic risk.

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

IBM UC info

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: IBM UC info
Newsgroups: alt.folklore.computers
Date: Thu, 30 Dec 1999 18:04:28 GMT
"Henk Stegeman" writes:
Hi,

I recently found an IBM reference card of a Universal Computer (UC) of IBM. I believe the IBM UC was used between +/- 1975 and 1985 (???)

I believe that the IBM 3274 contained a so-called UC.5 (???)

Does any one has any information regarding this UC ? In which IBM products was it used ?

Any information regarding the UC is welcome.

My thanks

Henk.


uc.5 was also used in (at least) the ibm 3705 and ibm 8100.

we had an effort to try and get peachtree used in the 3705 rather than the uc.5 ... since it was much more suited for a telecommunications controller (peachtree was used in the s/1).

minor peachtree (& telecommunication) references:
http://www.garlic.com/~lynn/93.html#2
http://www.garlic.com/~lynn/94.html#33a
http://www.garlic.com/~lynn/99.html#63
http://www.garlic.com/~lynn/99.html#64
http://www.garlic.com/~lynn/99.html#66
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#70

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

Attacks on a PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <garlic.com>
Subject: Re: Attacks on a PKI
Newsgroups: sci.crypt
Date: Fri, 31 Dec 1999 00:24:03 GMT
Greg writes:
> the old style checks with signing limits has been one model proposal
> for certificate pki ...

Wouldn't you agree that PKI is in many ways an electronic emulation of classical check banking and that once someone thinks (imagines) beyond classical architecture, PKI may actually simplify and strengthen at the same time?


I should have said PKI works well in 'offline', atomic transactions.

I think it is pretty well accepted that PKI design point is offline, electronic. The models they have/fit correspond to the world before it started moving to online.

checks/debit/credit have had failure modes like forgeries ... but also there are other failure modes like insufficient funds &/or credit limit.

PKI can be used for addressing offline forgery issues.

however, starting sometime in the '60s, telecommunication and computers costs started coming down to the point where it started being economically attractive to do online transactions ... & being able to address the insufficient funds and credit limit failure modes (i.e. card swipe online terminals at point of sale) ... i.e. cost of the telecommunications and computers was much less than the benefit of doing online transactions (cost/benefit ratio).

since the '60s, the cost of telecommunication and computers have continued to decline, making online transactions even more attractive, improving the cost/beneift ratio with online starting to become more and more ubiquitous (further reducing the attractiveness of offline solutions like PKIs). The internet itself is just one example of the move to pervasive, ubiquitous online operation.

AADS chip card & X9.59 for all electronic retail transactions addresses both the forgery as well as insufficient funds using integrated online solution.

A CA/PKI only offline solution would be going back to a pre-60s solution only addressing the forgery failure mode.

And as stated previously, given an online digital signed solution (ala X9.59) which addresses forgery issues, end-to-end authentication (financial institution doing the authentication/forgery checking and not relying on intermediaries), as well as insufficient funds & credit limit failure modes ... then it is trivially shown that also having a CA/PKI as part of the transactions is at best redundant and superfluous and typically introduces unnecessary systemic risk and unecessary additional failure modes.

and as usual ... more AADS & X9.59 at
http://www.garlic.com/~lynn/x959.html#x959

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


next, previous, subject index - home