2003 Newsgroup postings (04/08 - 05/91) Lynn Wheeler

2003 Newsgroup Postings (04/08 - 05/01)

Alpha performance, why?
Share in DC: was somethin' else
Share in DC: was somethin' else
Disk capacity and backup solutions
saving country music
Any DEC 340 Display System Doco ?
Oldest system to run a web browser?
Any DEC 340 Display System Doco ?
Redhat 9
Determining Key Exchange Frequency?
Speed of APL on 360s, was Any DEC 340 Display System Doco ?
Speed of APL on 360s, was Any DEC 340 Display System Doco ?
Page Table - per OS/Process
Page Table - per OS/Process
Page Table - per OS/Process
Page Table - per OS/Process
Disk capacity and backup solutions
Can someone clarify, X509 spoofing?
Can someone clarify, X509 spoofing?
Multiple layers of virtual address translation
Multiple layers of virtual address translation
price ov IBM virtual address box??
price ov IBM virtual address box??
303x, idals, dat, disk head settle, and other rambling folklore
price ov IBM virtual address box??
UltraSPARC-IIIi
303x, idals, dat, disk head settle, and other rambling folklore
IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
SYSPROF and the 190 disk
Any DEC 340 Display System Doco ?
Lisp Machines
One Processor is bad?
Lisp Machines
One Processor is bad?
price ov IBM virtual address box??
Lisp Machines
Mozzilla renamed to Firebird
netscape firebird contraversy
Lisp Machines
What is Meet In The Middle Attack
IE6 faster than O7.10?
How to cope with missing values - NULLS?
How to cope with missing values - NULLS?
What is the best strongest encryption
Codd's death (x-post from a.f.c)
Rewrite TCP/IP
Rewrite TCP/IP
death of Edgar F. (Ted) Codd
Disk capacity and backup solutions
Lisp Machines
Lisp Machines
switching to KDE
vnet 1000th node anniversary 6/10
Mercury News 04-20-2003 Computer pioneer, dead at 79,
Lisp Machines
Rewrite TCP/IP
Advantages of multiple cores on single chip
OT What movies have taught us about Computers
OT What movies have taught us about Computers
40th Anniversary of IBM System/360
can't close tab after abort 1.3/1.4a
IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
IBM zSeries in HPC
IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
UT200 (CDC RJE) Software for TOPS-10?
IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
software pricing
death of Edgar F. (Ted) Codd
IBM zSeries in HPC
rh9/evolution/filters
Simple resource protection with public keys

Alpha performance, why?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Alpha performance, why?
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 08 Apr 2003 20:01:21 GMT

Anne & Lynn Wheeler writes:
the clock that i did in the 60s .... and the stanford phd thesis on clock (over ten years later) .... didn't tic a hardware clock. The

the big difference between the clock i did in the 60s as an undergraduate (and the clock described in the stanford phd thesis over ten years later) and the slight-of-hand i did circa '71 was that traditional LRU replacement algorithms (including the various flavors of clock) have a pathelogical degrade to FIFO ... where the slight-of-hand trick i did ... degrade to random (and just like it was possible to show that LRU was tradtionally better than FIFO .... it was also possible to show ... in the region where LRU would degrade to FIFO ... that random was better).
https://www.garlic.com/~lynn/subtopic.html#wsclock

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

Share in DC: was somethin' else

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Share in DC: was somethin' else
Newsgroups: bit.listserv.ibm-main
Date: Wed, 09 Apr 2003 00:54:30 GMT

whp@MINDSPRING.COM (Bill Planer) writes:
More like 45 minutes in light traffic. The Pentagon is in Arlington, Va. The WSC is in Gaithersburg, MD.

the 495/270 split can really back up ... and then there is still all the construction going up the 270 side towards g'burg ... sometimes it looks almost easier to take the democracy exit and head up rockville pike.

WSC used to share the building with FSD ... i haven't been there since FSD was sold off .... so don't how they manage it now; or where federal marketing resides?

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

Share in DC: was somethin' else

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Share in DC: was somethin' else
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 09 Apr 2003 15:43:36 GMT

edgould@AMERITECH.NET (Edward Gould) writes:
It was early evening (6-7 PM) My friend had a corvette and I didn't pay much attention. He picked me up in Crystal City (I was attending an IBM 8100 class there)..

and that was? ... a question came up exactly when did 8100 get killed?
https://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
https://www.garlic.com/~lynn/2003f.html#22 Could somebody use SCSH, Sheme, or Lisp to create the "Lispm"

a couple times we had meetings in wsc ... we stayed in 'napolis; there was a hilton(?) on the water ... which i believe is a marriott now ... something of commute.

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

Disk capacity and backup solutions

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk capacity and backup solutions
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 09 Apr 2003 16:05:04 GMT

Jouni Matti Juhani Osmala writes:
There are basicly TWO strategies in getting reasonable reliability.
A) get mainframe (high costs)
B) Redundant Array of Inexpensive Computers =RAIC

i think for something like 20 years it has been documented that the major causes of failures has not been hardware, but software and people mistakes.

one of the major costs associated with mainframes ... has been the extensive software regression testing .... both from product perspective ... but also local installation/datacenter change control. the other is extensive automated processes eliminating human involvement. RAIC potentially are prone to both human error and software glitches.

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

saving country music

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: saving country music
Newsgroups: alt.folklore.computers
Date: Wed, 09 Apr 2003 17:15:35 GMT

well,
http://www.kfat.com/
http://www.kpig.com/kfat.htm

somewhere i use to have open-real, 3600', recorded mono (four tracks) at the slowest speed on the recorder ... the last two weeks of kfat.

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

Any DEC 340 Display System Doco ?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Thu, 10 Apr 2003 14:16:57 GMT

Mark Crispin writes:
I forget how the APL Life programs worked, since I never wrote any of them. At the time, I was still a baby programmer. Later on, I did write a basic wordprocessor in APL that I used to typeset a high school term paper.

I think though that APL\360 itself was slow. You didn't have all that large a workspace -- I think 32K -- yet even memory primitives took noticable time.

On the other hand, I don't know how fast a 360/67 was. It was supposed to have been one of the faster models of 360s (this was early 1970s) but I recall that a 360/30 was very slow. The stupid prime number calculation program (check all odd numbers from 3 to the square root to see if any are a factor) was faster in interpreted FOCAL on a PDP-8/e than in compiled Fortran on the 360/30.

if it was apl\360 on a '67 in the cambridge area in the early '70s, it might have actually been apl\360 port to cms (cms\apl) done at csc. workspace was opened up to be as large as the virtual memory space given to cms ... which was typically at least as large as a couple hundred k ... and might be a couple of meg. (although not likely for student accounts). cms had hacked the apl garbage collector so it wouldn't be so onerous in a virtual memory environment (with 16k-32k fixed workspace that was always swapped completely .... it wasn't so noticeable that apl wanted to frequently touch every memory byte it had available ... whether it needed it or not).

besides student accounts on csc machine ... there was at least the cp/67 machine at mit urban planning (across the tech. sq court yard?).
https://www.multicians.org/thvv/360-67.html

in the above ref ... i had done the TTY support as an undergraduate, and it was incorporated into the standard product. i had done some trick with one-byte arithmetic (255) since tty would never come close to exceedd that .... but later ascii devices did .. and when Tom increased the max. size to larger than 255 ... the hack with one byte arithmetic wasn't changed.

apl was interpreted ... and could easily be 10-50 times slower than the same code compiled in fortran running on the same machine.

random apl (& hone) refs:
https://www.garlic.com/~lynn/subtopic.html#hone

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

Oldest system to run a web browser?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oldest system to run a web browser?
Newsgroups: alt.folklore.computers
Date: Thu, 10 Apr 2003 16:43:18 GMT

also 10 years ago ... a good percentage of the isp accounts were shell ... and/or uucp; with typically uucp being to periodically dial-up, exchange email and then drop the line (aka uucp wasn't just used for broadcasting usenet stuff).

also, one of the premier modems was telebit trailblazer (i still have one in a box someplace) that had special optimization for uucp.

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

Any DEC 340 Display System Doco ?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Thu, 10 Apr 2003 18:43:02 GMT

jchausler writes:
The first light pen I saw in use was on an IBM 1130 in the late 60's. I had already used a "Rand Tablet" a few years before. The light pen was a 50's development which came out of the Project Whirlwind for the AN-FSQ/7 development and SAGE. I don't know when the "Rand Tablet" was developed. I used it attached to a Philco graphics controller being run by one of the Bendix G-20's at CMU in the 60's (as kind of a background task, the G-20 was doing other things as well).

light pen was on the 2250 ... there were several models of 2250s (any which could have light pen, tablet, some number of other things); ... 2250m1, controller that was direct 360 channel attach. 2250m4 had a 1130 as a controller. random past

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

Redhat 9

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Redhat 9
Newsgroups: redhat.general
Date: Thu, 10 Apr 2003 18:54:38 GMT

Lars Dybdahl writes:
I would recommmend RH9 for RH7.3 users, but RH8 users should wait a month or two.

i just upgraded from 7.3 to 9. most of it seem to have gone ok. the apache 2.0 stuff seemed to be not quite right. running any of the configurator stuff for http/apache on 9 ... doesn't actually do anything for starting apache. /etc/init.d http file from 7.3 for apache 1.3 is still left around and it looks like i have to manually add the http startup to rc file.

also i can't find the pointer for the smp browser-based configuration (which was used on 7.3)

also, i'm looking for a rh9 qmail.

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

Determining Key Exchange Frequency?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Determining Key Exchange Frequency?
Newsgroups: sci.crypt
Date: Thu, 10 Apr 2003 20:03:24 GMT

"Bret Schuhmacher" writes:
Can anyone direct me to texts/URLs covering the basics of determining how often Symmetric (3DES) keys ought to be changed? Can anyone give some guidelines for this decision? The act of actually exchanging keys is not that tough - I'm talking about how often you should actually perform that action based on industry standards and best practices. I thought I read somewhere that Visa/MC only do it once per quarter, but now I can't find that resource anymore :-(.

note that x9 & financial infrastructre are now specifying derived unique key per transaction (DUKPT) ... a type of one-way function that combines something like the account number, date/time and the secret key. brute force attack on each transaction only recovers the transaction specific derived key.

do search engine on dukpt, x9. etc; some quick examples:
http://www.trustedsecurity.com/POSsolutions.htm
http://www.futurex.com/products/excrypt/features.html
http://www.ccpcgroup.com/pinpad101.asp
http://www.advancedpayments.net/pinpad101.html
http://international.visa.com/fb/vendors/pin/faqs.jsp

you can also check my x9 glossary & taxonomy at:
https://www.garlic.com/~lynn/index.html#glossary

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

Speed of APL on 360s, was Any DEC 340 Display System Doco ?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Speed of APL on 360s, was Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Fri, 11 Apr 2003 03:04:31 GMT

johnl@iecc.com (John R. Levine) writes:
The /67 was a pretty fast machine for the mid 1960s with 32 bit integer datapaths, 200ns cycle time, and a 60 bit adder for floating point. Register to register integer load or add was 650 ns, memory-to-register load was 1.2us, add 1.4us. Floating add from memory 2.43us single, 2.45us double. Floating multiply 4.4us short, 7.6us long. Floating divide 7.3us short, 14.1us long. Floating compare 1.98us, conditional branch 800ns not taken, 1.1us taken. The dual processor machine was slightly slower, 690 ns load, to 14.33us floating divide.

memory cycle was 750ns (the original models 360 60, 62, 70 were going to have something like 1mic memory ... and the upgrade to 750ns created 65, 67, & 75). the uniprocessor 67 was essentially nearly identical to 65 with the addtion of associative array that could be used when running in virtual memory mode.

running in virtual memory mode ... added 150ns to the memory cycle time (for associative array aka TLB lookup) for 900ns.

i-fetch was double word ... so a 2byte register-to-register instruction timing includes 1/4th of 750ns (900ns in virtual memory) 8-byte i-fetch. a 4byte rs/rx/ri instruction timing includes 1/2th of the 750/900 i-fetch.

so in virtual memory mode (900ns)


                       prorated i-fetch
2byte instruction           225ns          + execution
4byte instruction           450ns          + execution
6byte instruction           675ns          + execution

just about all 4byte instructions have a storage load/store of some sort ... so a 4byte instruction would have 450ns+900ns or 1350ns running virtual memory mode (prorated i-fetch plus one load/store) base plus whatever instruction execution time.

what doesn't show in the manual is that the uniprocessor had single ported memory ... heavy i/o could significantly degrade the actual thruput because of contention for the memory bus.

The 67 dual processor was significantly different from the 65 dual processor. The 65 dual processor was basically two uniprocessors sharing the same, contiguous memory.

The 67 dual processor had tri-ported memory ... one port for each processor and one port for i/o. Tri-ported memory slowed down base memory cycle by about 150ns ... aka to around 900ns .... or 1050ns in virtual memory mode (however, it avoided much of the memory bus contention).

Note that a half-duplex 67 running in non-virtual memory mode with any sort of reasonable I/O activity had measurably higher thruput than the same workload on a simplex 67 or a 65 (aka while base memory bus time on half-duplex 67 was slower than either uniprocessor 65 or 67, it's tri-ported memory bus avoided much of the significant memory bus contention from i/o activity).

cp/67 on half-duplex 67 (aka a single processor 67 with tri-ported memory) outperformed same workload on simplex 67 (if there was any i/o involved).

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

Speed of APL on 360s, was Any DEC 340 Display System Doco ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Speed of APL on 360s, was Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Fri, 11 Apr 2003 03:14:44 GMT

Anne & Lynn Wheeler writes:
Note that a half-duplex 67 running in non-virtual memory mode with any sort of reasonable I/O activity had measurably higher thruput than the same workload on a simplex 67 or a 65 (aka while base memory bus time on half-duplex 67 was slower than either uniprocessor 65 or 67, it's tri-ported memory bus avoided much of the significant memory bus contention from i/o activity).

cp/67 on half-duplex 67 (aka a single processor 67 with tri-ported memory) outperformed same workload on simplex 67 (if there was any i/o involved).

.. and while apl\360 (under os/360 on 65 or 67 running in non-virtual memory mode) programs might be primarily computationally intensive ... there would typically be at least lots of i/o swapping workspaces in & out.

HONE (possibly the largest time-sharing services in the world at the time) ... was nearly all APL/CMS ... then vs/apl on cms, etc. The whole interactive environment was large APL application controlling the environment for the sales & field support people around the world. However, there were some number of the configuration applications that were so computationally intensive that it made it worth while to rewrite them in fortran ... and have them execute outside the APL environment (transparent to the end-user).

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

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

Page Table - per OS/Process

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page Table - per OS/Process
Newsgroups: comp.arch
Date: Fri, 11 Apr 2003 05:03:42 GMT

Joshua Jones writes:
Page tables facilitate mapping virtual addresses to physical ones. Each process has its own address space and therefore process A and process B must have their own page tables. Only having one page table wouldn't make much sense, as it would provide no multiplexing of memory (it would be simply an extra layer of indirection that would slow things down).

the initial port of the various (real memory) 360 OS to 370 virtual memory all did that. issue was the real storage sizes were typically much smaller than the addressing size ... and multitasking had some amount of contiguous memory per process. the larger virtual memory size allowed larger number of concurrent processes ... w/o significant rewriting of the base operating system. the increased flexibility of scheduling additional processes tended to offset the virtual memory overhead.

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

Page Table - per OS/Process

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page Table - per OS/Process
Newsgroups: comp.arch
Date: Fri, 11 Apr 2003 14:11:08 GMT

"Glen Herrmannsfeldt" writes:
I still remember lots of complaints about MVS when it came out, how slow it was. I don't know if that was really due to extra overhead of separate page/segment tables or not.

It might be that the original 370's had to do PTLB on every change of segment tables, and it would take some overhead to build the TLB back.

i don't think that the pathlength got any better ... the machines got faster. in early '80s, mvs (and vm) got "big pages" which helped any page I/O associated bottlenecks.

370/168 had 128 entry TLB ... but had a 7-entry STO-stack ... i.e. it could keep track of seven different address spaces ... switching to a new address space that wasn't in the STO-stack ... it would scavenge one of the current (STO-stack) entries ... and (only) that address space's TLB entries would be invalidated (aka a partial, implicit purge lookaside ... PTLB).

original 370 architecture had PTLB, ISTO (invalidate address space), ISTE (invalidate segment table entry), IPTE (invalidate page table entry). Because of implementation problem/schedule with 370/165, all but PTLB instruction were dropped in 370. The explicit instructions were only used when software had to invalidatte tables. If there was any page replaced and a virtual page table entry was invalidated, the software/kernel had to do a PTLB. This originally wasn't considered a problem by VS2 (original/official name) ... since they claimed implementation would never do more than five page replacements a second ... and that the implementation tended to do 5-10 replacement selections in a batch (requiring a single PTLB).

3033 finally did implement IPTE (selective page table entry invalidate ... single virtual page).

the low-end 370s (which mvs didn't run on) tended to have a single STO TLBS ... the TLBs typically only had 8 or so entries. While changing an address space resulted in all TLB entries being purged ... it wasn't as much of a problem. MVS didn't run on these machines ... so it wasn't a problem for them .... and the operating systems (except for VM/370) for the low-end machines ran with single address space.

some postings on 370 STO-stack:
https://www.garlic.com/~lynn/2000g.html#10 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001g.html#8 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
https://www.garlic.com/~lynn/2002l.html#60 Handling variable page sizes?
https://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text

recent posting on mvs performance(?):
https://www.garlic.com/~lynn/2003f.html#51 inter-block gaps on DASD tracks

some recent discussion of big pages implementation:
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#9 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#16 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?

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

Page Table - per OS/Process

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page Table - per OS/Process
Newsgroups: comp.arch
Date: Fri, 11 Apr 2003 23:43:23 GMT

"Glen Herrmannsfeldt" writes:
An STO stack sounds like a good idea. So they implemented it even though OS/VS2 wouldn't use it? They were already planning for MVS?

initial OS/VS2 was called SVS .... single virtual storage ... already getting ready for OS2/VS2 MVS ... multiple virtual storage. The issue was that SVS was the minimum amount that needed to be done to MVT to get it running in virtual memory environment.

Basically MVT was setup as if it had 16mbytes .... then hack ipl/boot to PIN/FIX the contiguous kernel and setup the segment & page tables. Start SVS (MVT-based) prototype (on 360/67) with the page fault handler from CP/67 to handle page fault and be able to task switch. Also hack CCWTRANS from CP/67 (function that copied CCWs aka I/O commands, from virtual address space, translated virtual to real addresses, fixed the associated pages in real memory for the duration of the I/O, etc) into MVT-based prototype. misc. refs on this:
https://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
https://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
https://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#36 History
https://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
https://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
https://www.garlic.com/~lynn/2002p.html#49 Linux paging
https://www.garlic.com/~lynn/2002p.html#51 Linux paging

Similar process was done for DOS/VS and VS1.

Then they started on a whole number of things for MVS ... which required a lot of restructuring. The base MVT design had the kernel as part of the application address space. The initial MVS design had a separate address space for each application with the same kernel segments as part of each application address space (aka common/shared segments, but since TLB was sto-associative ... there were lots of duplicate TLB entries for kernel pages).

Theree were problems were semi-privilege subsystems like JES2 ... which weren't part of the kernel but relied on the same pointer-passing convention used thru-out the OS/360 genre operating systems. With MVS, JES2 sitting in its own subsystem address space would get a pointer to some data in an application (totally different) address space. The solution was the COMMON area. The address space was 24-bit, 16mbytes, 16 1mbyte segments. The kernel had 8 1mbyte segments, and the application area was nominally 8 1mbyte segments. The COMMON area started out being a single 1mbyte segment taken out of the application area. Data needed to be exchanged between address spaces could be copied to/From the COMMON area, and the pointer passing convention preserved. A problem was that the appetite for space in the COMMON area grew quickly and it wasn't untypical for an installation to have a 4mbyte COMMON area (also duplicate TLB entries) So even tho there was now a 16mbyte address space for each application, in fact 8mbytes of that was taken up by the shared/common kernel and frequently 4mbytes taken up by shared/common COMMON ...leaving only 4mbytes for applications.

So come the 168 follow-on, the 3033; and there continued even more pressure to increase the size of the 4mbyte COMMON area (aka each subsystem running in the environment needed its own little dedicated space of COMMON) ... potentially with nothing left for applications. The solution was dual-address space support. When semi-privilege subsystem was running, it could be run with two different STOs (address space table pointer), its primary STO ... and a different/secondary STO for application space it was doing work on behalf of ... and it could use pointers passed from application programs and reach directly into their address space. This significantly alleviated the pressure for constantly increasing the size of the COMMON area. Dual-address space support did increase the pressure on the 3033 TLB entries.

primary/secondary address space refs (from later machine)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.2.1.4?SHELF=&DT=19970613131822
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.2.1.5?SHELF=&DT=19970613131822

move to primary & secondary instruction (from later machine)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.22?DT=19970613131822
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.21?DT=19970613131822

A common segment kludge was added to later machines for MVS to try and cut down on all the duplicate/identical TLB entries ... w/o having to make the change from STO-associative (aka address space) TLB to a STE-associative (aka segment) TLB. basically if MVS was running on the bare hardware ... and MVS flagged segment table entry as common ... then there need only be a single copy of associated page table entries in the TLB.
https://www.garlic.com/~lynn/2002l.html#57 Handling variable page sizes?
https://www.garlic.com/~lynn/2002m.html#0 Handling variable page sizes?

basically, if a segment table entry was flagged as common ... then it is almost as if it was a single/common address space hardware implementation. On TLB lookup ... accept a TLB for this virtual address ... if it is either 1) marked as a common entry or if it is 2) marked for this address space. On TLB miss ... if the segment table entry is marked as common ... load the new TLB entry as common (otherwise mark it as address space specific). It is a multi-address space environment with sort of kludge for a single system-wide shared common space (implemented using a restricted use of shared segments ... aka that all shared segment definitions have to be identical and the same in all virtual address spaces).

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

Page Table - per OS/Process

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page Table - per OS/Process
Newsgroups: comp.arch
Date: Sat, 12 Apr 2003 07:29:27 GMT

"Glen Herrmannsfeldt" writes:
I thought it wasn't called SVS until after MVS came out. Though I am not sure why they would keep calling it OS/VS2 after it was MVS. I would have called it OS/VS3.

try this ...
http://os390-mvs.hypermart.net/mvshist2.htm
qHmm. Did the 360/67 have IDALs? Otherwise it would have to keep contiguous pages for I/O operations?

nope ... that was added with 370 ... cp/67 used data-chaining which had some timing restrictions (that weren't encounted on the 360/67 but would have been on some of the entry level 370). the initial prototype for svs was mvt system running on 360/67 with the indicated hacks to fake out most of mvt to think it was running in 16mbyte real machine, kernel pinned, page fault handler, some stuff in task switch, and cp/67's ccwtrans. the switch to idal support was already available. However, the early testing on 360/67 was w/o the idal ... since the 360/67 didn't have idal support.

as related elsewhere ... there was joint project between cambridge and endicott to build a cp/67 that ran on 370/145. A set of modifications were done to a cp kernel that provided simulation for 370 instructions and 370 virtual memory tables (and idals). Then a different set of modifications were done to a cp kernel that used 370 instructions and virtual memory tables.

Because of various security concerns (like lots of mit, bu, etc. students using the cambridge machine), a version of the cp/67 kernel ran on the bare hardware. In a virtual 360/67 virtual machine a modified version of the cp/67 kernel was run that provided 370 virtual machines. In a 370 virtual machine, a modified version of the cp/67 kernel that ran on 370 real machines was run.


360/67 real hardare  ran cp/67 providing virtual 360/67
virtual 370/67 ran modified cp/67 providing virtual 370
  virtual 370 ran modified cp/67 providing virtual 360&360
virtual 360/370 ran cms

This was all completed and was operational a year before the first engineering model 370 hardware with virtual memory was available.
https://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?

note that when a 370/145 finally shipped to customers (see the mvs history ref above), it did have the necessary hardware support for virtual memory ... and only needed a microcode change to enable. however, the early engineering models didn't initially have virtual memory. the first software to be booted on the 370/145 engineering model with virtual memory was the modified cp/67 ... and the "ipl button" was a knife switch.

The joint development project was also one of the first production uses of vnet internal network for distributed development activity.
https://www.garlic.com/~lynn/internet.htm

topic drift with respect to the mvs history ref ... when i was hacking around in the disk engineering lab ... trying to run MVS in the late 70s with engineering hardware under development ... had a MTBF of 15 minutes for MVS. As a result ... the standard operational mode was dedicated machine time with simple "stand-alone monitor & test programs". I documented the failures & necessary approach for fixing them in a classified corporate document ... and put together a sytsem that never failed from any of the hardware errors that the engineer environment had (aka error activity in periods of minutes in the engineer & product test labs would possibly not be seen in a normal operation over a period spanning possibly years). There was some rumor that the MVS RAS manager tried to cause lots of problems because of the document (even tho is wasn't available to anybody outside of the company). It sort of reminded me of when CERN did the MVS/TSO comparison with CMS and published a report at SHARE in the early '70s. The copy available within the corporation was given one of the highest security classification and employees could only get copies if they demonstrated strick need-to-know (or they got a copy from some customer).
https://www.garlic.com/~lynn/subtopic.html#disk

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

Disk capacity and backup solutions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk capacity and backup solutions
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 12 Apr 2003 14:55:30 GMT

jmfbahciv writes:
Right. I also was sluing to another bandwagon of mine which had to do with reproducibility of bit patterns.

besides doing cp/67, virtual memory stuff (besides cp/67 virtual memory, things like vs/repack), the internal network,
https://www.garlic.com/~lynn/subnetwork.html#bitnet
https://www.garlic.com/~lynn/internet.htm

gml (precursor to sgml, html, xml, etc), multiprocessing (including the invention of the compare and swap instruction)
https://www.garlic.com/~lynn/subtopic.html#smp

etc .... there was lots of work at the science center on performance monitor/instrumentation/tuning and the early stuff that became capacity planning. there was a event simulator that could handle instruction/page traces and compare different kinds of page replacement algorithms in application that simulating cp/67.
https://www.garlic.com/~lynn/subtopic.html#545tech

with years of performance data ... not only from the cambridge machine, but later from other cp/67 systems and then vm/370 systems (some number of the thousands of internal corporate vm/370 installations) ... there was lots of early work done on workload profiling.

once the apl/360 port to cms\apl at been done at the science center ... there was also a detailed analytical model of systems ... and extensively calibrated from the years of recorded data. A version of this (called the performance predictor) was made available fairly early on the (field/sales support) HONE system ...
https://www.garlic.com/~lynn/subtopic.html#hone

salesman could take profiles on customer operations and then do what-if regarding hardware changes (faster cpus, more memory, more disk, different workload, etc).

A version of this was also done for preparing the resource manager for customer distribution :
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

A configurable synthentic workload was created and a automated benchmarking procedure was set-up. The nominal performance envelope (storage, page i/os, file i/os, workingset, interactive, mixed mode, batch, cpu, etc) was characterized from hundreds of internal installations. This was used to somewhat specify an initial run of several hundred benchmarks .... along the edge of the performance envelope, at evenly distributed points within the performance envelope ... and some extremely (stressful) benchmarks well outside the nominal performance envelope

one stressful benchmark had the avg. service time for a page fault of 1 second ... aka hardware running flat out at 300 page i/os per second ... the page request queue was so long it took an avg of full second to service a page fault. Early on, the stressing might cause various kinds system failures ... as part of the process all such failures were identified and fixed. It was also a way of precipitating hung-users/zombies (which a frequently some sort of timing stress) .. which required a redesign and rewrite of the kernel serialization process to eliminate all such instances (which then also became part of the resource manager).

This was similar but different to the rewrite of the i/o system that I worked on a couple years later to eliminate all instances of i/o activity related kernel glitches/hangs (for the disk engineering lab):
https://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process
https://www.garlic.com/~lynn/subtopic.html#disk

So after several hundred benchmarks to characterize the performance profile and the resource manager across wide range of factors ... the apl analytical model was modified to take into considerations factors from the previous benchmarks and then dynamically define the characteristics of the next benchmark (system parameters, workload profile, hardware resources, etc ... running as part of the automated benchmarking process), attempting to find things like anomolous points in the operational environment (basically trying to provide test coverage). eventually 2000 benchmarks were run over a period of 3 months
https://www.garlic.com/~lynn/submain.html#bench

the idea of software test matrix we applied a couple generations later when we were working on adding payment transaction processing for this small client/server startup (eventually come to be called electronic commerce):
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing

of course, in-between the generations ... we did ha/cmp product:
https://www.garlic.com/~lynn/subtopic.html#hacmp

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

Can someone clarify, X509 spoofing?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can someone clarify, X509 spoofing?
Newsgroups: sci.crypt,comp.security.misc
Date: Sun, 13 Apr 2003 01:25:29 GMT

Jem Berkes writes:
I wanted to make sure I had this point right about SSL and X.509 certificates. From what I understand, the X.509 certificate includes just about all the data about an SSL host, including their public key and signatures.

So if you connect to a host using SSL and record the hash of their X.509 certificate, and store ONLY this hash... does this protect you from spoofing on future connects? On each connect you can re-hash the X.509 certificate returned to you and check it against the known good hash.

i.e., can X.509 certs be spoofed so that their SHA-1 hashes meet a known value? (I already know about the computationally infeasible stuff.)

remember that the contents of the certificate have had SHA-1 which is then "encrypted" with the private key of the certification authority's private key to form the digital signature. This is assumed to be unique and non-forgeable. What you then get as a certificate ... is the content of the certificate with the certification authority's digital signature.

Part of the process of validating a certificate .... is to recalculate the SHA-1 of the contents of the certificate ... and then "decrypt" the digital signature with the certificate authority's public key (recovering the original SHA-1) and compare the two values.

So the process on receiving a message from a SSL webserver .... is that there sould be the contents of the message, the senders digital signature of the message (i.e. SHA-1 of the message sent "encrypted" with the sender's private key), with the certificate appended (which in itself is a kind of message with the certification authority's digital signature).

so you have the certification authority's public key stashed someplace ... and you get a message tuple (message, signature, certificate), you validate the signature on the certificate ... calculating the SHA-1 of the contents of the certificate against the "decrypted" signature, using the certification authority's public key. If that works, you take the sender's public key from the contents of the certificate, and qcalculate the SHA-1 of the sender's message and compare it against the "decrypted" SHA-1 (using the public key from the contents of the certifcate).

loads of SHA-1s and loads of public keys ... w/o having to keep your own SHA-1 ... just keep the public key of the certification authority.

Note to avoid "replay" attacks (imposter sending exact duplicate of some previous message) ... you have to perform some amount of the digital signature verfication.

If SHA-1 can be spoofed ... lots of other things fall apart ... long before worrying your use of SHA-1.

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

Can someone clarify, X509 spoofing?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can someone clarify, X509 spoofing?
Newsgroups: sci.crypt,comp.security.misc
Date: Sun, 13 Apr 2003 19:05:19 GMT

"Ernst Lippe" <ernstl-at-planet-dot-nl@ignore.this> writes:
When the client certificate does not correspond with the server private key, SSL will not be able to successfully negotiate a correct session key.

At the moment I can't think of any serious attack that would become possible if you happened to find two certificates with the same hash. Under very specialized conditions such attacks might exist, but until someone finds a very good counter example, I don't see how this would pose a threat against using certificates. After all compromise of the private keys is a far more realistic threat, and that doesn't appear to discourage most users from using certificates.

if the reference is being able to modify the contents of a certificate so that it matches any SHA of the original contents (whether it is a saved copy or the certificates authority digital signature of the contents) ... then one possibility is being able to alter the contents such a different public key (matching some private in the attacker's possession) is accepted. then the attacker could be accepted.

however, lots of discussions as to other points of attacks ... like domain name take-over (that don't involve either direct attacks on certificate contents or even direct attacks on private keys):
https://www.garlic.com/~lynn/subpubkey.html#sslcert

however, as mentioned in previous post ... if successful attacks can be mounted on SHA ... then the whole digital signature infrastructure is at risk (not just somebody's private use of SHA).

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

Multiple layers of virtual address translation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple layers of virtual address translation
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 14 Apr 2003 04:41:58 GMT

"Glen Herrmannsfeldt" writes:
Do you mean shadow page tables? The guest OS (running in the virtual machine) has its page tables, and VM has page tables mapping guest real to host real. Then VM generates shadow page tables that go from guest virtual to host real and actually uses those. Any change to either of the others must be reflected in the shadow page tables. I believe it is PTLB that notifies VM of changes to page tables, so it can update the shadow tables.

cp/67 & vm/370 were essentially the microcode of the virtual machine and the "shadow tables" are effectively the equivalent of the TLB of the virtual machine. CP/67 & VM/370 used similar rules for managing "shadow tables" as real hardware used for managing TLB. Anything that load entry into a TLB could also be used to load something into "shadow tables" and rules for deleting TLB entries, the "shadow table" maint used similar implementation (aka PTLB ... clear all entries, or IPTE ... clear specific entry).

the virtual memory architecture was defined sufficiently so that it could be arbritrary recursive ... the shadow table process could cascade arbritrarily deep ... aka a kernel supporting a virtual machine operation, couldn't differentiate between "standard" virtual memory tables built in that virtual machine and what might be "shadow" virtual memory tables. Maintenance of shadow table entries basically followed hardware definition rules for maintaining TLB entries. There were additional reasons why shadow table entries might get purged, like kernel was removing one of the virtual machine's pages from memory.

An early application was to implement a modified CP/67 that ran on a 370 architecture rather than a 360/67 architecture (for instance, there were incompatible differences between 360/67 virtual memory tables and 370 virtual memory tables). This was not only well before 370 virtual memory was announced and shipped to customers, but also well before any engineering 370 processors supporting virtual memory had even been built.

So a normal CP/67 ran on real CSC 360/67 (security issues because there were MIT, BU students and other non-employees had access to the CSC cp/67 service). This "first level" CP/67 built 360/67 formated virtual memory tables and emulated 2nd level 360/67 formated address space tables using first level 360/67 formated shadow tables.

In a virtual 360/67 machine, a "2nd level" modified CP/67 ran which provided virtual 370 machines. This modified cp/67 thot it was running on real 360/67 and built 360/67 address space tables for the virtual machines it provided. It emulated any 3rd level 370 formated address space tables using 2nd level 360/67 formated shadow tables.

In a virtual 370 machine, a "3rd level" modified CP/67 ran which provided virtual 370 machine (and believed it was running on real 370 machine). All its virtual memory tables (for the virtual machine address space as well as emulating and tables might be built by the "4th level" operation) were in 370 format.

recent related thread:
https://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process

all virtual memory tables built by the "3rd level" CP/67 cascaded into "shadow tables" built by the "2nd level" CP/67. All virtual memory tables built by the "2nd level" CP/67 cascaded into "shadow tables" built by the "1st level" CP/67. The real hardware couldn't differentiate between basic and shadow tables.

In any case, the "3rd level" Cp/67 (thinking it was running on real 370) was in regular operation a year before the first engineering 370 with virtual memory support was operational.

there is story that the ipl/boot button on the first engineering machine was a knife switch, and ipl/boot of the modified cp/67 was used to validate the hardware implementation. It turns out the initial boot failed and the diagnosis was the hardware had incorrectly implemented some facet of 370 (they had reversed the baker-two opcodes for PTLB & RRB) ... the CP/67 kernel was quickly patched to correspond to the incorrect hardware implementation (going thru and swapping the B2 op-codes) ... and then (re)booted successfully and ran.

the project was also an early example of distributed development project between endicott and cambridge ... using the internal network support.

little thread drift ... last august was 30th anniversary of the VM/370 product announce at SHARE 1/1 was the 20th anniversary of the cut-over to internet protocol march was the 35th anniversary of the CP/67 product announce at SHARE

coming up 6/10/2003 is the 20th anniversary of the 1000th node on the internal network
https://www.garlic.com/~lynn/internet.htm#22

aka internet connectivity didn't really take off until after the cut-over to internet protocol on 1/1/83 ... it wasn't until sometime in 1985 that the number of nodes on the internet overtook the internal network. In part, the internal network grew faster than arpanet because it essentially had gateway function from the start ... while arpanet was homogeneous network supported by IMPs and didn't get heterogeneous and gateway functionality until cut-over to internet protocol on 1/1/83.

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

Multiple layers of virtual address translation

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple layers of virtual address translation
Newsgroups: comp.arch
Date: Mon, 14 Apr 2003 04:49:23 GMT

"Andy Glew" <andy-glew-public@sbcglobal.net> writes:
Pardon me. I should have asked exactly how the PTLB works. I have a habit of guessing, based on how I would implement something, but I don't know what IBM actually did, and it may have done something else.

...
PTLB ... purge look aside buffer

original 370 architecture had
PTLB ... purge look aside buffer
ISTO ... invalidate segment table origin (aka address apce)
ISTE ... invalidate segment table entry
IPTE ... invalidate page table entry
RRB ... reset reference bit (little drift)

because of hardware implementation issues with 370/165 (that would have delayed announcement and ship of 370 virtual memory product), the selective invalidates; ISTO, ISTE, and IPTE were dropped from the introduction of 370 virtual memory. IPTE did finally make appearance with the 3033.

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

price ov IBM virtual address box??

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: price ov IBM virtual address box??
Newsgroups: alt.folklore.computers
Date: Mon, 14 Apr 2003 18:57:41 GMT

"Russ Holsclaw" writes:
The first large scale rollout of virtual address translation was in the System/370's. This line of computers was originally announced and shipped (in 1970) with no mention of DAT (Dynamic Address Translation) hardware, but the fact is that the hardware was already there in almost all models (except the 195, IIRC). When IBM finally announced the availability of VS system software (sometime in '71 IIRC), IBM CE's were given instructions on how to enable the DAT hardware already built into the 370's, so they could use it.

155-II and 165-II were field hardware retrofit ... while 145, etc had virtual memory hardware support with initial boxes shipped.

165-II was especially extensive and, in fact, some of the 370 architecture support for virtual memory was dropped ... because of difficulty in 165-II implementation would have added six month delay to general announcement (and customer ship) of virtual memory.

370/195 never did get virtual memory.

a specific reference ($200k for 155-II, and $400k for 165-II):
http://os390-mvs.hypermart.net/mvshist2.htm
http://os390-mvs.hypermart.net/mvshist.htm

recent mention of 165-II implementation issue:
https://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
https://www.garlic.com/~lynn/2003g.html#19 Multiple layers of virtual address translation

folklore discussion of leakage of 370 virtual memory document before product announce:
https://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000f.html#55 X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)
https://www.garlic.com/~lynn/2002n.html#15 Tweaking old computers?

note many 360 and 370 machines had several rows of lights on the front panel. there were "rollers" above above each light row which had legends as to the meaning of the lights ... and rotating the roller, switched the connections. On the 370/145 there was display of the PSW and a light that had the label "DAT" (aka dynamic address translation). This was on all 370/145 machines shipped to customers, even before DAT (aka virtual memory) was announced.

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

price ov IBM virtual address box??

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: price ov IBM virtual address box??
Newsgroups: alt.folklore.computers
Date: Tue, 15 Apr 2003 04:03:58 GMT

shoppa@trailing-edge.com (Tim Shoppa) writes:
But as I understand it, this required different microcode. Was there any difference in speed for VM vs non-VM? My experience is on PDP-11's, and there if you ran without MMU you generally got a speed advantage (varied depending on processor implementation).

discussion of 360/67 virtual memory hardware timing
https://www.garlic.com/~lynn/2003g.html#10a Speed of APL on 360s, was Any DEC 340 Display System Doco ?

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

303x, idals, dat, disk head settle, and other rambling folklore

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: 303x, idals, dat, disk head settle, and other rambling folklore
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 15 Apr 2003 13:44:37 GMT

so i could remember the 67 timings for dat ... but not any of the 370 ones. i went looking on the ibm.com site for any old online functional characteristic manuals (would give lots of the gory details of instruction timings). i didn't find any, but stumbled across the 3033 references on the history pages ... aka
http://www-1.ibm.com/ibm/history/exhibits/3033/3033_room.html

so as per the 67 dat timings reference,
https://www.garlic.com/~lynn/2003g.html#21 price ov IBM virtual address box??
https://www.garlic.com/~lynn/2003g.html#10a Speed of APL on 360s, was Any DEC 340 Display System Doco

i also referenced that i/o contention for the memory bus had a lot of impact on cpu instruction thruput. another issue was whether or not there were integrated channels (i.e. the processor engine was time-sliced between executing cpu instructions and executing i/o instructions).

the 360/67 (and 65) had outboard, hardware channels. the 370/135, 370/145, 370,148, 4331, 4341, 370/155, 370/158 had integrated channels, the 370/165, 370/168, and 303x processors had outboard channels.

in the late '70s, i was doing this stuff for the fun of it supporting the disk engineering and disk product test labs. one of the things was timings having to do with disk head switch time on 3330 disk drives. 3330 had 19 tracks per cylinder (arm position) and a track had enuf room for three 4k (page) records plus a little left over. the official 3330 specifications stated that if you wanted to read/write two records on different tracks (requiring a head switch), the end of the previous record read/wrote and the start of the next record read/wrote had to be separated by at least a 110-byte intervening record. The idea was to format every 3330 track with a three 4k records with intervening "dummy/spacer/filler" records of 110 bytes. However, the 3330 track only had sufficient room for 101-byte filler records. past discussion:
https://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001j.html#3 YKYGOW...

part of the issue was that i/o commands were executed by a sequence of channel, control unit, and disk drive components, each having their own latencies. Furthermore, i/o commands were stored in the processor main memory and had to be executed stricly in-order with no-prefetching (the archecture allowed that an i/o read from current command could overlay/modify the next i/o command and/or the argument of the next i/o command; so nothing could be fetched until the termination of i/o transfer of the currently executing i/o command). The impact was that command processing latencies were strictly serialized and prefetching couldn't be used to compensate.

performing a head switch, not only requred the head settle time, but also an additional i/o command in the process sequence (and the associated serialized command processing latency). however, the 3330 110-byte "filler" specification was worst case scenario across a wide range of processors and other hardware components;

processor model (145, 148, 4341, 158, 3033, etc) channel implementation, integrated, or outboard controller (3830, 3880, oem compatible) drive (3330, from ibm or oem compatible)

so i wrote an application that would reformat a 3330 cylinder (19 tracks) with various dummy record sizes starting at 50-bytes and increasing until it was no longer possible to fit three 4k records on the track. it would run a series read/write i/o command sequences testing to see if head switch was successful using that dummy record size. I then went to find a broad range of different configurations in the san jose area to run it on. Also asked some customer shops to run it also (bnr, cornell, etc).

data came back that there was some oem disk controllers that had reduced command latency so that the successful transfer of consecutive records with head switch could occur with 50-byte spacer records, regardless of the processor configuration.

The 148 and 4341 were succeful at 101-byte spacer records with standard ibm controllers. The 158 failed, the 168 succeeded. In addition, on all 303x processors failed, it failed. It turns out that 158 had integrated channels (the processor engine was time-sliced between performing 370 instructions and i/o commands). For the 303x series, they created something called a "channel director", an outboard dedicated channel processor. A channel director was actually the 158 processor engine w/o the 370 instruction processing capability, purely dedicated to I/O function. However, it retained most of the 158's integrated channel i/o command processing latency.

so in this other thread:
https://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process

the question about IDALs. CP/67 on 360/67 was able to simulate virtual machine contiguous i/o transfers that crossed (non-contiguous) page boundaries with the use of multiple data-chaining commands (separate i/o commands that were separately fetched specifying different i/o addresses). On various models of 370, morphing a single I/O command into multiple data-chained commands, the processing latency would have exceeded some timing constraints. Furthermore, not only was VM/370 going to be using this technique ... but all of the virtual operating system would be translating contiguous transfer i/o that crossed paged boundaries into non-contiguous transfers. The problem was addressed in 370 with the invention of IDALs ... instead of having the I/O command directly specify the memory location of the transfer ... it could point to "indirect address list", a series of address pointers. Furthermore, sicne these weren't part of the original 360 i/o architecture, they weren't subject to the constraint that they couldn't be prefetched. A channel could prefetch as much of the IDAL addresses as it needed in order to compensate for processing latency (and overcome the serialized processing latency associated with the data-chaining implementation).

now, the self-modifying i/o command stream was rarely used. NSC took advantage of this in their remote device (A51x) adapter implementation. The A51x adapter simulated an ibm channel and could be positioned at the end of a local HYPERchannel network or at a remote HYPERchannel network connected by a telco link. Basically, software in the processor would gather up all the I/O commands and preload them into the memory of the A51x (effectively prefetching the complete i/o sequence). This overcame any command processing latency associated with transfer delays thru the HYPERchannel network. We used this to relocate a couple hundred people of the IMS group out of the STL lab to a remote location ten miles away (using T1 telco link) and still provide them with "local" terminal support (see remote device adapter refs below).

this initially didn't work with disk, because there were both timing constraints associated with the actual I/O commands as well as arguments of some specific commands. NSC came up with an enhanced version of the A51x that supported preloading I/O commands as well specialized disk i/o commands arguments. Besides allowing disks to be placed at a remote distance, it also allowed implementation (originally by NCAR) of one of the first SANs. An IBM processor managed hierarchical storage of disk and tape for some number of other processors like Crays. The processors and disk drives were all interconnected by a common HYPERchannel network. Cray could request access to data from the IBM processor, the ibm processor would locate it on disk (transferring tape to disk if necessary) and return to the cray an argument enabling the cray to directly request the data from disk. This later showed up as requirement in IEES standard for HiPPI & IPI disks for 3rd party transfer support.

partway back to 3033 refs on the ibm historical site. cp/67 and then vm/370 was this non-standard product done initially by a couple people located on the mit campus. it was not the flagship product, however customers kept demanding it, despite the best efforts of the corporation to stamp it out. people working on the project were continuly told that the next release was the last and promotions and raises were only possible if you transferred to work on the flagship product. Despite the corporations best efforts, (cp/67 & then) vm/370 kept growing (both customers and the number of developers). Eventually the vm/370 group overflowed the space available in 545 tech. sq and they moved out to the old SBC building in burlington mall. During this period, CERN presented the tso/cms comparison at SHARE ... and copies of the document inside the corporation were promptly given one of the highest security classification and were only available on strictly need-to-know basis (unless you could get it directly from a customer).

In '76, the corporation told the vm/370 group that burlington was being shutdown, the last VM/370 release had been shipped and everybody had to move to POK to work on the VMTOOL (a virtual machine implementation that would never be shipped to customers, dedicated to supporting MVS/XA development). At this time, some number of people didn't transfer to POK but wandered off to DEC and worked on VAX/VMS (note customers did continue to get additional vm/370 releases and VMTOOL was eventually made available to customers as VM/XA).

and finally back to the 3033 historical site
http://www-1.ibm.com/ibm/history/exhibits/3033/3033_intro.html

it turned out that somebody realized that the first 3033 install was going to be some customer out west for vm/370. this was going to be horrible loss of face for the flagship operating system. with some quick last minute fiddling, truck routings and people scheduling ... a truck from POK to New Jersey managed to arrive first (there were some gov. constraints effectively about products having to be shipped out of the manufacturing loading dock in the sequence that the orders were placed, so there wasn't a lot of latitude available to the people trying to save face).

misc idal refs:
https://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
https://www.garlic.com/~lynn/2002d.html#52 Hardest Mistake in Comp Arch to Fix
https://www.garlic.com/~lynn/2002e.html#21 Crazy idea: has it been done?
https://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?

NCAR/SAN refs:
https://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2002.html#10 index searching
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives

other hyperchannel remote device adatper refs:
https://www.garlic.com/~lynn/93.html#2 360/67, was Re: IBM's Project F/S ?
https://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
https://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
https://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
https://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
https://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2003c.html#64 Surprising discovery
https://www.garlic.com/~lynn/2003c.html#66 FBA suggestion was Re: "average" DASD Blocksize

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

price ov IBM virtual address box??

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: price ov IBM virtual address box??
Newsgroups: alt.folklore.computers
Date: Tue, 15 Apr 2003 18:03:45 GMT

"Russ Holsclaw" writes:
I stand corrected. Interesting that folks with a lowly 145 got DAT for free, but the high-end customers had to pay big bux. Of course, I'm sure the performance was in a different league.

360/67 dat was fully associative eight entry array. however all entries flushed every time CR0 was reloaded (segment table/address space pointer). dat/tlb was/is hardware cached (page table) entries for virtual->real address mapping ... the DAT lookup added 150ns to every memory access (translating virtual->real address) ... if there was a dat entry ... otherwise a dat-miss had to reference the real segment/pagetables which were a couple full storage access).

370s were TLB ... table lookaside buffer ... and entries tended to be indexed, possibly 2-way or 4-way associative. CR0 became a series of flag/option bits, and the segment table/address space pointer was moved to CR1. 145 was 8(?) entry TLB and only handled a single address space (flushing all entries every time cr1 was reloaded). 165/168 tlb with 128 entries and 7-entry sto-stack discussed in refs indicated in previous posting.

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

UltraSPARC-IIIi

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: UltraSPARC-IIIi
Newsgroups: comp.arch
Date: Tue, 15 Apr 2003 18:59:09 GMT

hack@watson.ibm.com (hack) writes:
P.S. PAE looks stupid only when 64-bit registers are available for addressing. In a 32-bit system it wasn't stupid at all. IBM did its own 26-bit PAE to escape from 24-bit constraints over 20 years ago, before 31-bit XA was introduced. Why 24-bit addressing lasted so long (given that 32-bit registers were available -- and, in fact, 360/67 did support 32-bit virtual addrs) is a different (and sad) story... mostly software.

cp/67 didn't use 32bit ... in part because it's interactive monitor (cms) cribbed a lot of straight 24-bit stuff from os/360.

the official operating system for 360/67 was tss/360, which included support for both 24-bit and 32-bit modes. during the 1967 period, there was possibly at most 10 people in cambridge working on cp/67 and cms ... while the tss/360 group had something like 1000-1200 people.

it is possible that having two orders of manitude fewer people made it difficult to have a great deal of bloat with either software and/or pathlength (in cp/67).

in the first half of '68 (before I had done much of my performance optimization on cp/67), 30 users doing typical fortran development, edit, compile & test with cms ... had better thruput and response than four user doing same exact work under tss/360 on the same exact hardware.

another big distinction was that cp/67 deliverables included full source (where tss/360 provided some approximate microfiche).

I remember that the IBM SE (on the univerisity account) dedicated to TSS/360 had some offshift and weekend time for testing. This particular incident was at about tss/360 prerelease 0.69. Over a period of several weeks, he had found and fixed (via binary patches) something like six dozen bugs; documented everything and set it off to the tss/360 development group in mohansic. he got back a message saying that they couldn't use any of his work because they were in the process of shipping pre-release 0.70 ... but they would be happy to accept his work if repeated against the brand new 0.70 release (and he got it to them before the 0.71 release).

tss found renewed life as tss/370 in custom circumstances. One saw fairly wide use in AT&T with a port of Unix on top the "SSP" layer built from tss/370. minor unix/tss ref:
https://www.garlic.com/~lynn/96.html#4a

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

303x, idals, dat, disk head settle, and other rambling folklore

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 303x, idals, dat, disk head settle, and other rambling folklore
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 15 Apr 2003 23:20:33 GMT

"Glen Herrmannsfeldt" writes:
I wonder about data chaining. There was a story about someone writing a whole tape reel with one record using data chaining, as the maximum for one CCW was 64K-1. (I believe it is -1, unlike MVC). It wouldn't seem to have much time to fetch the next CCW, though.

MVC & other SS length instructions counted from zero ... i.e. to move one byte, specify zero, to move 256 bytes, specify 255 (note that assembler handled the conversion from assembler origin 1 specification to machine instruction origin 0 specification) ...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.2.2?SHELF=&DT=19970613131822

extract from above:
When SS-format instructions are written in the assembler language, lengths are given as the total number of bytes in the field. This differs from the machine definition, in which the length field specifies the number of bytes to be added to the field address to obtain the address of the last byte of the field. Thus, the machine length is one less than the assembler-language length. The assembler program automatically subtracts one from the length specified when the instruction is assembled.

.....

CCW length counted from 1 ... to move one byte, specify one. CCW count field is 2bytes ... so x'FFFF' is 64k-1.

there are now two different CCW formats; format 0 and format 1
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/15.6.3?DT=19970613131822

extract from above:
Count: Bits 48-63 (format 0) or bits 16-31 (format 1) specify the number of bytes in the storage area designated by the CCW.

....

description CCW chaining ...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/15.6.6?DT=19970613131822
data chaining
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/15.6.6.1?SHELF=&DT=19970613131822
command chaining ...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/15.6.6.2?SHELF=&DT=19970613131822

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

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
 monopoly
Newsgroups: alt.folklore.computers
Date: Wed, 16 Apr 2003 00:34:18 GMT

Charles Shannon Hendrix writes:
White collar has always been the best way to steal, especially from a government office... :)

while not strictly equivalent to white collar ... insider fraud has frequently represented 90 percent of total fraud (aka white collar isn't strictly insider and insider isn't strictly white collar).

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

SYSPROF and the 190 disk

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Wed, 16 Apr 2003 00:12:37 -0600
Newsgroups: bit.listserv.vmesa-l
Subject: re: SYSPROF and the 190 disk

At 12:01 AM 4/16/2003 -0500, wrote:
I'm fairly certain that INSTSEG did not come about until the days of VM/XA. I can't speak to HPO, as we never ran it. However, my understanding is that HPO simply contained performance enhancements on a VM/SP base. My recollection is that you couldn't load EXEC's into a DCSS until VM/XA. Perhaps the line was really in VM/SP 6. I don't suppose it really matters at this point. Prior to VM/XA, however, you had to code DMKSNT in order to do save segments. Remember those bad old days???!!! Its my recollection that INSTSEG came about after DCSS' became more dynamic and we waved good riddence to DMKSNT.

basically DMKSNT was left over from CP/67 .... and could only be accessed by IPL command.

tail end of cp/67 days ... i had done a page mapped file system for CMS on cp/67 with some enhanced capability for also specifying shared objects from the mmap'ed API. I ported this to an early release 2 version of VM/370 and put it up on some number of internal operations.

Possibly on of the largest online time-sharing system (anywhere) at the time was HONE which was vm/cms system supporting majority of the field and sales people around the world. It was primarily written in APL. Majority of accounts had login to automatically ipl "APLCMS" DMKSNT entry ... this was a CMS system that had been saved after APL had been loaded (and included both the CMS segment 1 and the segments in the user area occupied by APL.

The problem they HONE was facing was that some of the applications, possibly configurators (allowed salesman to actually fill-out processors orders) were getting quite computationally intensive. Some of these were recoded in Fortran getting a significant performance improvement. However, it was quite a problem to have a salesman who possibly never heard of CMS, APL, IPL commands, etc .... to get them to drop out of APL, re-ipl a standard CMS, run the fortran program, and then re-ipl APLCMS. So for their Relase 2 PLC system ... i installed the support for the CMS page mapped filesystem .... it would automatically recognize whether a minidisk was in page mapped format or normal format ... and do the correct thing.

This new function supported doing the standard CMS IPL thing .... with an additional shared segment that had a bunch of more stuff in it. There was also some slight of hand that I had done that supported floating shared segments .... so that the additional CMS "kernel" shared segment was positioned at the end of the virtual address space for each virtual machine. This met that the same exact shared segment could appear at different virtual address in different virtual machines/address spaces. I had done a quick and dirty hack for SVC 202 adcon ... by allocating an SVC202 and DC/AL4 return address in NUCON .... since it wasn't possible to use a DC AL4 following an SVC 202 ...... if the same R/O code might appear simultaneously at different virtual addresses.

It was also possible to load an APL module after IPL ... with all the appropriate segments initialized as R/O. It was now possible to have virtual machines setup to automatically IPL CMS (the same version, for all users, regardless of virtual machine size) and then automatically invoke APL (and get all the appropriate shared segments). It was then possible to write applications that dropped out of APL ... automatically invoke fortran programs and then re-enter APL .... and it all worked the same whether they were running a shared segment version of APL ... or a non-shared segment (normal CMS module) version of APL.

Come up to items for release 3, the CMS group wanted the additional shared segment definition for the kernel and the ability to invoke shared segments with something other than the IPL command. However, the CP group didn't want to pick up all of the function. So the CP group picked up some of the underlying infrastructure "as-is" (likes hits to routine responsible for creating/destroying segments ... shared or not shared) ... but they didn't pick up the rest of the code .... just defined a restricted subset API that became referred to as DCSS (discontiguous shared segments). The CP support to have the same shared segment appear at different virtual address in different address spaces also wasn't preserved. However, the CMS group picked up much of the code "as-is". I had gone thru some amount of code that previously had been in shared segments .... and made it operational in a R/O shared segment environment ... and at the same time "sanitized" it to remove address location dependency (aka instead of inline SVC202 & inline DC AL4 adcons .... it used the SVC202 & AL4 in NUCON .... and dynamically filled in the AL4 as part of the BAL to the SVC$202 in NUCON). So while the CP group drop pieces of the support in preparing it for release (like the support for "floating" shared segments) ... the CMS group picked up and distributed the code pretty much as is.

Now since the additional CMS nucleus shared segment couldn't float to the end of each virtual machine's address space ... the typical process was that two or three different copies of the same exact code were saved as different DCSS at different fixed virtual address. Then there was some installation stuff about which DCSS copy that different CMS configurations might load.

And of course ... then with DCSS, there was DMKSNT entries that could be defined for other things like APL, SCRIPT, EDIT, etc. This had to be generated and then savesys done with the respective DMKSNT entry.

In the page mapped file version (the other stuff not picked up as part of the extended virtual memory management features as part of the vm/370 release 3)... all of that had gone away. CMS just saved the module to a page mapped minidisk with optional additional segment specifications for the genmod command. The CMS loadmod command then looked for the additional information and passed it when invoking the CP page map API. Rather than needing DMKSNT entries for obtaining a page mapped image (or later VM/XA doing it in the spool file system) ... the page map format and API .... had everything on CMS minidisks already in page mapped format.

I had done some other things as part of the page mapped filesystem changes .... including interface for doing contiguous record allocation if the space was available. Before that, CMS would pretty much do scatter allocate on a record by record basis. You could sort-of get a kind of contiguous allocation by backing everything to something like tape, doing an access/erase, and then reloading all the files. However, you could still get some funny allocation with things like hyperbloks intermixed with datablocks.

Yorktown then did a number of things in the release 5/6 time-frame ... the work on being able to copy S/Y/etc minidisk file directory image into a DMKSNT saved segment and have it load when CMS ipl'ed. In that time-frame, they had also done the (non-shared) nucleus extension command ... being able to load a "module" at an arbitrary address. This had some of the same issues as relocating shared segments .... however it wasn't that they had r/o code, they had private memory which could support adcons pointing to correct location ... their problems was that the GENMOD module-image already had all its addresses fixed up. the nucleus extension loading a module at an arbitrary address didn't have any information that enabled it to go thru and fixup any adcons. At this time, the hack I had done for SVC$202 in low-core was replaced with the AL4(1) convention.

In any case, the full package that the DCSS stuff for VM/370 release 3 was extracted from, had already eliminated DMKSNT as well as eliminating any CP sensitivity for saving/loading shared stuff. The DCSS subset was what had re-introduced DMKSNT when it was incorporated for product release. The full implementation allowed quite a bit of flexibility for mapping data on page-mapped minidisks into the virtual address space (including shared segment specification options). It then became purely a CMS operational and administrative issue with no involvement of CP. It was only shipping a very restricted subset of the full package that required reverything to DMKSNT.

recent postings on relocatable/floating code:
https://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?

generail postings on mmap support:
https://www.garlic.com/~lynn/submain.html#mmap

Any DEC 340 Display System Doco ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers
Date: Wed, 16 Apr 2003 19:46:53 GMT

"Charlie Gibbs" writes:
Yup, it's a crap shoot. At a PPOE we ran 38400 bps over a twisted pair to an X terminal at the other end of the building (100 feet?) and never had any problems. You pays your money and you takes your chances.

in the mid-80s, the brand new research bldg that had been wired for CAT4 went almost totally to enet shielded twisted pair over CAT4 (using synoptic hubs).

in the same area, there was a large, older research facility built in the '60s that had a large excess of standard telco (unshielded) twisted pair thru-out the bldg. it took a little more work to get enet unshielded twisted pair working in all rooms and offices thru-out the facility (again using synoptic hubs). in cases, some twisted pairs were just dead ... guesses that various remodeling activities over the years had cut/broken wires.

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

Lisp Machines

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Wed, 16 Apr 2003 20:06:44 GMT

Toon Moene writes:
>There appears to be a common misconception in this thread that at the >time Unix was created it was the only 'real' operating system in the >sense that it provided a protected kernel.

Ye Gods ! Are there people out there who actually believe that ?!?!?

Read Fred Brooks's "Mythical Man Month", some history stuff about Multics and the conclusion is inevitable: Unix is Multics' second system effect.

cp/67 had a protected micro-kernel ... in the same time-frame as multics and had significantly wider deployment (some number of people that had worked on ctss went to 4th floor, 545 tech sq and worked on cp/67, others went to 5th floor, 545 tech sq and worked on multics).

cp/67 also had early deployment in some number of time-sharing service bureau operations ... where the rule-of-thumb would have been a large collection of essentially authorized and unauthorized users from all over the world, sharing the same system(s) ... and all requiring protection from each other.

the 545 tech sq cp/67 system was also used by corporate hdqtrs people for analyzing the absolutely most/highest senstive corporate data, while there was also concurrent availability to non-employees, like BU and MIT students (some with the apparent intent of cracking the system based on various indications).

there is some indication that cp/67 saw possibly wide-spread deployment in sensitive, secure operations ... based on some active participants at SHARE (customer organization).

the follow-on to cp/67 was vm/370 ... not exactly a 2nd system effect, just a port from 360/67 architecture to 370 architcture.

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

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

One Processor is bad?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One Processor is bad?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 16 Apr 2003 21:11:49 GMT

dba@DUDA.COM (David Andrews) writes:
IBM used to tell you that a dual-processor system would yield a 170-180percent increase in apparent capacity. I know things have improved since sysplex but probably not as much as you seem to think.

(I've always been a fan of large unis, BTW. When you're lightly loaded, those jobs run at the speed of the complex and not at the speed of a single processor.)

370 158/168 dual processor had a 10percent cycle slow down to allow for handling cross-cache invalidates ... aka base instructions timings were .9 of a uniprocessor. two processors running at .9 were 1.8. This was only for the slowdown that allowed for handling cross-cache invalidates, there was additional overhead for the actual handling of cross-cache invalidates (as opposed the slowdown to provide for handling them).

actual running dual processors at 1.8 could have handling of cross-cache invalidates that slowed the machine down further ... another 5-10 percent ... and the operating system overhead for running in multiprocessing environment could be as much as 20-30 percent. realistic thruput could easily be only 1.5 times.

the original VM/370 support for two processors came very close to achieving the 1.8 times (magic slight of hand for coordinating two processors with little or no measurable overhead). There were some later changes to make the vm/370 two processor support more analogous to mvs ... which introduced new measurable kernel activity directly attributable to multiprocessor specific handling pathlength of approx. ten percent of elapsed time.
https://www.garlic.com/~lynn/subtopic.html#smp

i first handled high priority compute bound jobs running away with (any) processor with the early cp/67 implementation of the dynamic adaptive resource manager (when i was an undergraduate). This was dropped in the initial port from cp/67 to vm/370 ... but was later re-introduced by the resource manager product:
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
https://www.garlic.com/~lynn/subtopic.html#fairshare

they played a trick on me, saying that i got to be the guinea pig for the first priced SCP software ... and I needed to spend a lot of time with the business people figuring out the rules for SCP software pricing.

part of the expertise was that a large amount of early 360 multiprocessor investigation was done at csc (cp/67, vm/370, 545 tech. sq) which also resulted in the Compare And Swap instructions for the 370 (CAS is the person's initials at csc responsible for a lot of pioneering MP work ... the challenge was to invent a mnemonic for his initials).

3081 initially came out with only multiprocessor configuration (and there was no mention of the multiprocessor "slow-down" since there was never going to be a non-multiprocessor). The 4-way 3084 had a really difficult time since the number of cache invalidate signals tripled; aka in a 2-way, a cache would see cache invalidates from one other processor; in a 4-way, a cache would see cache invalidates from three other processors).

However, TPF (ACP, whatever) didn't have multiprocessing support (although there were some number of standard 3081 configurations where there was two copies of TPF running under vm/370). The 3083 single processor was later addition ... and probably motivated by the lack of TPF multiprocessor support. In 370, the standard was a uniprocessor and reference to dual-processor was always with respect to "slow-down". The 3081 wasn't suppose to have a uni-processor ... and when the 3083 did appear, the reference was to how much faster it ran (i.e. the 10percent cache slow-down for catching cross-cache invalidates was turned off).

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

Lisp Machines

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Wed, 16 Apr 2003 22:16:06 GMT

aek@spies.com (Al Kossow) writes:
"Plan to throw the first one away"

Unfortunately, what happens is you make compromises to SHIP the first product, then the second product is the one with everything but the kitchen sink. Sometimes, the second one never ships at all, and you end up with product number one with a few new features as product number two.

On the other hand, the old rule of thumb is you never want even-numbered software releases, since the even-numbered one breaks everything, and the odd-numbered one gets it working again.

cp/67 ... did have an intermediate ... which was cp/40 (between it and the ctss 7094).

360/67 was official product with virtual memory hardware support.

before 360/67 was available, the csc group built special modified virtual memory hardware for a 360/40 and built cp/40 for that machine during 1966 (the 360/40 dat/virtual memory hardware had almost no resemblance to the 360/67 implementation). then during 1967, it was rewritten for 360/67 and installed on 360/67 that csc got at 545 tech sq ... and on lincoln lab's 67s. the last week in jan. 1968, three people came out from cambridge to install at the university i was at.

the official corporate product for 360/67, virtual memory support, time-sharing, etc was tss/360. this was a system that started out with extremely huge bloat (including the kitchen sink); recent tss/360 bloat reference:
https://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi

above having footnote regarding unix ported on top of tss/370 (subset) and deployed inside at&t.

and possibly the biggest bloat of all time .... which never saw the light of day and few people are even aware of was "future system" or "FS"
https://www.garlic.com/~lynn/submain.html#futuresys

the university found os/360 release 14 to be quite stable .... but there was never a (real?) os/360 release 15 ... the next release was called os/360 release 15/16 (aka combined release 15 and 16).

there is a bunch of stuff about ctss, multics, tss/360, cp/40, and cp/67 (some amount was 360/67 loosing multics bid to GE):
https://www.leeandmelindavarian.com/Melinda#VMHist

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

One Processor is bad?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One Processor is bad?
Newsgroups: alt.folklore.computers
Date: Thu, 17 Apr 2003 02:17:38 GMT

Ivan writes:
VM/HPO (The High Performance Option for VM/SP) Had an interresting approach to reduce MP induced overhead. I reckon some guy determined that some of the overhead was generated by handling the external interrupt used to communicate with SIGP from one CPU to another (probably 100-200 Instructions in External FLIH & Sigp SLIH) (not forgeting that IIRC SIGP & Interrupts both do a Checkpoint synchronisation.. But so do CS & CDS)

from my viewpoint all the additional SIGPs went into VM/SP to specifically handle the TPF (or possibly single-processor MVS?) type cases in the 3081 time-frame (aka as per previous post); i.e. an environment where there wasn't much of anything else running on the machine but the single guest and so the second processor was spending almost all of its time in wait state. You could gimmick the I/O simulation by doing a SIGP to the idle processor to handle SIOF, ccw translation, real i/o scheduling, etc ... on the idle processing while returning to the virtual guest. This basically overlaped I/O simulation on the idle processor with the guest running back on "its" processor (furthermore, the idle spin loop would also be characteristic of it being specifically targeted at such an environment ... single, single processor, virtual guest with the 2nd real processor nominally idle).

One could claim this in some sense the analogy of transition from 370/158 to 3031. The 158 had embedded channels, and the 158 engine was effectively time-sliced between emulating 370 execution and performing the io/channel function. For the 303x line, a 158 engine was taken with the 370 emulation removed and dedicated to io/channel function ... and called a "channel director". A 3031 was basically a 158 with two 158 engines ... one dedicated to 370 emulation and one dedicated to io/channel function (called a channel director).

the issue was that in loaded environment ... mixed guest plus cms, cms instensive, multiple guests, etc ... the SIGP change w/SP resulted in the SIGP, SIGP Interrupt handling and various lock contention overhead (as a result of the SIGPs) going from almost unmeasurable (pre-SP) to ten percent of both processors ... which didn't actually achieve any purpose (other than degrade thruput). There were some SHARE reports specifically about the 10% overhead change with VM/SP ... and being associated specifically with the SIGP changes.

Effectively, the implementation was fairly specificly targeted at the single-processor guest with idle 2nd processor, but it wasn't implemented in such a way that it was inactive in other environments. One might assert that the product got hijacked by a very specific market niche.

The pre-SP version actually had some environments where the thruput of two processors was more than twice that of a single processor. This had to do with some natural tendency in the implementation for cache affinity ... and twice the cache along with improved cache hit ratio, more than offset the various hardware and software MP overheads.

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

price ov IBM virtual address box??

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: price ov IBM virtual address box??
Newsgroups: alt.folklore.computers
Date: Thu, 17 Apr 2003 02:37:38 GMT

shoppa@trailing-edge.com (Tim Shoppa) writes:
But as I understand it, this required different microcode. Was there any difference in speed for VM vs non-VM? My experience is on PDP-11's, and there if you ran without MMU you generally got a speed advantage (varied depending on processor implementation).

oh and i forgot
https://www.garlic.com/~lynn/2000f.html#59 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

discussion of virtual memory modifications to 360/40 for cp/40 ... where 64 word associative array "dat box" ... didn't degrade 360/40 processing.

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

Lisp Machines

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Thu, 17 Apr 2003 03:50:07 GMT

Toon Moene writes:
Yes, even the original text of the chapter "Second System Effect" talks about "frill after frill, embellishment after embellishment". So people usually associate "Second System Effect" with "growth".

However, the crucial sentence of this chapter is: "The general tendency is to over-design the second system".

This can mean both "restrict it overly" as well as "expand it without limits".

Unix clearly is of the first kind.

"Novell to Make Linux Robust and Reliable"
http://www.computerweekly.com/articles/article.asp?liArticleID=121012
http://slashdot.org/articles/03/04/16/229244.shtml?tid=190&tid=106

wasn't it around 89 or 90 where the tandem lab in austin did something about making sysV.4 more robust and reliable by contributing source changes that eliminated/fixed something like 1000-1200 kernel panics (and not just a case of deleting the statement).

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

Mozzilla renamed to Firebird

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mozzilla renamed to Firebird
Newsgroups: netscape.public.mozilla.general,alt.folklore.computer
Date: Thu, 17 Apr 2003 15:02:43 GMT

"Martijn Tonies" writes:
Ahum, can a browse have security issues? Sure thing. Can a database engine have security issues? Sure thing. Does a database engine need a PHP driver for PHP stuff -> yups! Can you test your PHP pages with a browser -> yups!

i always thot fireberds were those things that every serious ISP has ... or anybody serious about communication links (search engine on fireberd and bit error tester) ... of course then somebody else had to come out with a phoenix (try fireberd, phoenix, bit error tester). we used to have loads of them, i may still have a turbo pascal 1.0 program around somewhere that supported the RS232 port and took ("printer") output from phoenix and fireberds and logged it to PC file ... and also scanned the data (different format in the two devices) and displayed a running summary on the screen.

from long ago and far away ...


$V+,R+,B-,C-,U-}   {note: the C- & U- aviods losing type-ahead}
(
To be done:
FIREBERD
minimize ERROR entries in cases of prolonged
high-error rate conditions. Calculate ERRORs/sec
          Make no more than one entry in ERROR per 15 minutes
unless ERRORs/sec change by more than 50%.

minimize ERROR entries for sync lost/sync acquired
loops.

   ULTRAMUX
recognize alarm messages
          define status flags for various alarm messages
when sync. is lost, include fireberd information in screen

COM2 asynch interrupt
          check for Asynch card interrupt
... if not asynch, restore status/regs and
           goto saved IRA (i.e. cascaded IRQ4 interrupt routines)
)

program m232(input,output);

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

netscape firebird contraversy

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: netscape firebird contraversy
Newsgroups: alt.folklore.computers
Date: Thu, 17 Apr 2003 20:47:57 GMT

my contribution to the firebird discussion:
https://www.garlic.com/~lynn/2003g.html#35 Mozzilla renamed to Firebird

i had intended to x-post to this n.g. but fumble fingered it.

in any case, how many people remember turbo pascal 1.0?

for the backbone that my wife and I operated ... we did detail line-quality monitoring .... typically with a mux on a T1 with a 56kbit channel split out dedicated to continuously running bit error testing.

this was backbone technology that we weren't allowed to bid for NSFNET ... although technical audit by NSF concluded that what we were running was at least five years ahead of all bid submissions. minor ref:
https://www.garlic.com/~lynn/internet.htm#0

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

Lisp Machines

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Fri, 18 Apr 2003 13:48:00 GMT

Brian Inglis writes:
Maybe you should contract the Wheelers to build you a nice big mainframe server with some nice big GB network pipes, possibly running a custom version of VM, like TPF but supporting SMP, async page mapped I/O with completion posting, and an optimized network stack to serve up the data as fast as the CPUs can crunch it.

the ibm system engineer on a financial services institution in southern california did a virtual machine based transaction driver for ATM machines ... basically a virtual machine per disk arm ... that he measured on a 370/158 outperforming TPF running on a 370/168. the big gain was a global disk arm scheduling algorithm that attempted to anticipate arm activity based on past history of ATM machine use patterns (aka all transactions came into a central scheduler ... that re-ordered and then released them to the individual transaction servers).

trivia ... i believe the same person also did the first pc version of SCRIPT (cms document formater done at science center ... originally in mid-60s by "mad" with runoff-like dot commands ... and then at csc circa 1970, "G", "M", and "L" ... added GML to. I believe his PC version first showed up on those PCs you could get from that chain of local electronic parts stores.

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

What is Meet In The Middle Attack

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is Meet In The Middle Attack
Newsgroups: alt.computer.security
Date: Sat, 19 Apr 2003 14:34:47 GMT

"Kevin" writes:
Would you please tell me what "Meet In The Middle Attack" is? It is not the same as "Man In The Middle" attack (I think, but I don't understand either one of them. Would SSL help to protect these two attacks? If so, could you please tell me how?

past refs:
https://www.garlic.com/~lynn/aadsm11.htm#17 Alternative to Microsoft Passport: Sunshine vs Hai
https://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aepay11.htm#49 A More Anonymous Internet
https://www.garlic.com/~lynn/2001c.html#63 SSL weaknesses
https://www.garlic.com/~lynn/2001d.html#36 solicit advice on purchase of digital certificate
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
https://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
https://www.garlic.com/~lynn/2002d.html#50 SSL MITM Attacks
https://www.garlic.com/~lynn/2002g.html#65 Real man-in-the-middle attacks?
https://www.garlic.com/~lynn/2002j.html#38 MITM solved by AES/CFB - am I missing something?!
https://www.garlic.com/~lynn/2002j.html#58 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
https://www.garlic.com/~lynn/2002k.html#51 SSL Beginner's Question
https://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
https://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
https://www.garlic.com/~lynn/2003.html#52 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003.html#64 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack

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

IE6 faster than O7.10?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IE6 faster than O7.10?
Newsgroups: opera.general
Date: Sat, 19 Apr 2003 15:39:18 GMT

Toman writes:
A quick unqualified estimate on time would be DNS(250ms) + (ping(220ms) x 3) = ~1 second. If this hack is indeed in place, initial load-time is cut by (ping x 2) = ~500ms. Thats quite a lot when you're assuming the page to load right after the click. I wouldn't be surprised if IIS servers give IE users a head start too..

most connections are setup w/DHCP ... will have client ip-address set to ISP value and DNS set to two or more local ISP's servers. The issue then is whether the entry is already cached at the local ISP DNS server ... or whether the ISP DNS server will need to request name->ip resolution from somebody else (possibly the root servers). If the address is already cached at the ISP ... then the latency is the travel over the connection from the client to the ISP plus whatever is involved on the ISP's backbone. Subsequent requests to the same name whould find it at the local ISP DNS (even if there was a requirement to visit the DNS root for the initial resolution).

note also that after any DNS stuff ... then HTTP uses TCP/IP for the connection. TCP/IP is a minimum 7-packet exchange (of course, one of those seven is the actual data and some are on the backside tear-down (ping is one round-trip, 2 packet exchange, tcp/ip is minimum three round-trips plus ... aka 7 packet exchange). For pages that are multiple packets ... then there can be several more round-trips for the additional packets (aka the 7 packet minimum is with respect to actual transferred data fitting inside a single packet).

extended delays after the initial name resolution by the ISP's DNS server ... is more likely traffic and/or server contention. Secondary consideration is whether client & server have negotiated for using the same TCP/IP connection for multiple operations ("persistent connections").

misc http performance overview:
http://www.w3.org/Protocols/HTTP/Performance/
http://nwi.dtv.dk/RENARDUS/D2.1/HTTP.html
http://www.comsoc.org/ci/public/1998/may/ciint.html

as an aside VMTP (rfc1045) is minimum five packet exchange and XTP is minimum three packet exchange (which has more applicability in transaction, oriented, single packet transfer). random vmtp & xtp refs:
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#17 A challenge
https://www.garlic.com/~lynn/aadsm13.htm#27 How effective is open source crypto?
https://www.garlic.com/~lynn/99.html#0 Early tcp development?
https://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#207 Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2000b.html#1 "Mainframe" Usage
https://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001b.html#57 I am fed up!
https://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?
https://www.garlic.com/~lynn/2002g.html#5 Black magic in POWER5
https://www.garlic.com/~lynn/2002g.html#50 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
https://www.garlic.com/~lynn/2002m.html#52 Microsoft's innovations [was:the rtf format]
https://www.garlic.com/~lynn/2003.html#53 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

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

How to cope with missing values - NULLS?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to cope with missing values - NULLS?
Newsgroups: comp.databases.theory
Date: Sat, 19 Apr 2003 16:50:01 GMT

pkl@mailme.dk (Peter Koch Larsen) writes:
How to cope with missing values - NULLS?

Simple 3-value Logic Comparison

There was an article, "An Explanation of why three-valued logic is a mistake (Why Accept Wrong Answers?)" by CJ Date on pg. 21 of Database Programming & Design, Dec. 1992,

In the article, Date presents the following example


Select E#
        FROM EMP
WHERE JOB='Clerk'
OR NOT JOB='Clerk';

and states that it will not correctly select for employees whose jobs are "null" (while article states that in the real world, one might assume that all employees would be selected, but NOT JOB='Clerk' is not selecting entries with NULL jobs).

The issue being addressed is that in relational databases all entries MUST have all specified relations. To ease the practical implementation, relational databases will fill-in NULL values for missing information. SQL logic operations are extended with "unknown" states to deal with NULL values.


SQL:
True
Unknown
False

and   T   U   F        or    T   U   F       not
-----------------      ----------------      --------
T     T   U   F        T     T   T   T       T     F
U     U   U   F        U     T   U   U       U     U
F     F   F   F        F     F   U   F       F     T

An alternative 3-value logic:


Logic:
Lo         Falsity.   The stated objective was not met
DontCare   Don't Care The stated objective may have been met
Hi         Truth      The stated objective was met

and   Hi   DC  Lo      or    Hi  DC  Lo      not
------------------     -----------------     ---------
Hi    Hi   Hi* Lo      Hi    Hi  Hi  Hi      Hi    Lo
DC    Hi*  DC  Lo      DC    Hi  DC  Lo*     DC    DC
Lo    Lo   Lo  Lo      Lo    Hi  Lo* Lo      Lo    Hi

• difference in logic operation results compared to SQL.

Effectively, for "and" and "or" logic operations involving a DontCare state, the result is whatever the other state is. A DontCare result only occurs when both states are DontCare.

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

How to cope with missing values - NULLS?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to cope with missing values - NULLS?
Newsgroups: comp.databases.theory
Date: Sat, 19 Apr 2003 17:14:47 GMT

Anne & Lynn Wheeler writes:
Select E# FROM EMP WHERE JOB='Clerk' OR NOT JOB='Clerk';

and slightly related to employees that might have multiple job classifications ... aka "Clerk" and one or more other classifications.

one solution is to come up with all possible composite job classifications involving "Clerk" and a table "Clerk" giving all possible composites ... and then all entries in the Clerk composite table are used when selecting employees that might possibly have job classifications which include Clerk.

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

What is the best strongest encryption

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the best strongest encryption
Newsgroups: alt.security
Date: Sat, 19 Apr 2003 16:36:14 GMT

"bella150" writes:
I am looking for the best encryption software availible, any country, anywhere. I am looking for something that is bigger than 4096-bit key and does not use a one time pad technique. You guys know of anything like that?

are you also considering dukpt, derived, &/or unique key techniques? misc. refs:
https://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC)
https://www.garlic.com/~lynn/aadsm13.htm#22 Encryption of data in smart cards
https://www.garlic.com/~lynn/aadsm13.htm#24 Encryption of data in smart cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2003g.html#9 Determining Key Exchange Frequency?

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

Codd's death (x-post from a.f.c)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Codd's death (x-post from a.f.c)
Newsgroups: comp.databases.theory
Date: Sun, 20 Apr 2003 18:36:57 GMT

"Jim Mehl" writes:
The San Jose Mercury News reported today that Ted Codd died on April 18 at age 79. I had the pleasure of knowing him when I was at IBM Research in San Jose. He was a fine gentleman. Jim Mehl

ditto
http://www.bayarea.com/mld/mercurynews/news/local/5676133.htm
http://www.bayarea.com/mld/mercurynews/news/local/5676110.htm

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

Rewrite TCP/IP

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Rewrite TCP/IP
Newsgroups: comp.protocols.tcp-ip
Date: Sun, 20 Apr 2003 20:04:59 GMT

Casper H.S. Dik writes:
unoriginal_username@yahoo.com (Le Chaud Lapin) writes: >"Start with the current TCP/IP, step back, reassess from wholistic >perspective, identitfy the set of functionally orthogonal virtuous >primitives that comprise it, re-engage and synthesize a new system >from those primitives, yielding one more attractive in form and >function than the old, perhaps augmenting the system with >not-yet-invented primitives so that the resulting model tends toward >the steady-state."

You mean like OSI?

i think osi was going on concurrently with IP ... IP started mid-to-late 70s and then there was the great cut-over of the arpanet to ip-protocol on 1/1/83.

http://www.commweb.com/techcenters/main/experts/3783/COM20011119S0004

OSI reference from above:
Work on the architecture began in 1977 and concluded in 1983, which actually is a fairly short span of time in the domain of standards development. The Model was intended to be a set of open standards by which computers of disparate origin could intercommunicate and interoperate.

....

A major difference that is frequently highlighted between the IETF process and the ISO process, is that the IETF has required two interoperable implementations for standards to move forward. Potentially, ISO can pass standards that could never be implementable.

The internal network started about the same time as arpanet. One of the distinguishing features of the internal network was that it effectively had the equivalent of gateway functionality in every node ... while the arpanet was homogeneous networking implemented with IMPs. I've contended that one of the reasons that the internal network was larger than the arpanet ... until sometime in '85 was that the arpanet didn't get that kind of gateway functionality until the great ip cutover on 1/1/83.
https://www.garlic.com/~lynn/internet.htm#0

Note that in the 7-layer OSI model, there is nothing that corresponds to the internetworking protocol layer (aka IP) ... which sort of sits between OSI level 3 (routing) and OSI level 4 (transport).

From something that was more of a step back and look at the issues, try XTP (disclaimer, my wife and i once served on the XTP technical advisery board):
http://www.ca.sandia.gov/xtp/
http://www.ca.sandia.gov/xtp/forum.html
http://www.cicese.mx/~aarmenta/frames/redes/xtp/biblio.html
http://www.ccii.co.za/products/xtp.html
http://www.prz.tu-berlin.de/docs/html/group_prot.index.html
http://www.elcom.pub.ro/idemcop/uk/real-cs/esv-xtp40/objectives.html

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

Rewrite TCP/IP

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Rewrite TCP/IP
Newsgroups: comp.protocols.tcp-ip
Date: Mon, 21 Apr 2003 00:54:38 GMT

Bjorn Borud <borud-news@borud.no> writes:
interesting. why has XTP remained obscure? is this changing?

some drift ... slightly related to the question asked:

as part of XTP, there was an attempt to do a standardization in x3s3.3 (ansi/us body responsible for OSI level 3 & level 4 standards) under the title "high speed protocol" or HSP. HSP would go directly from top of level 4 (transport, aka the level 5/4)) interface directly to IEEE 80x/LAN (effectively in the middle of level 3, routing .... aka LANs collapse OSI levels 1, 2, and some part of level 3).

the problem was that the iso charter for x3s3.3, in effect said that it couldn't standardize something that violated OSI. Since HSP was going directly to LAN interface (as well as collapsing the level 3/4 interface)... it was obviously a violation of OSI.

Now, ISO is something of a schizo organization with respect to OSI. IEEE is a chartered ISO organization and IEEE was able to achieve standardizations for LAN interfaces ... even tho OSI was being violated. In effect, while LANs became standardized, it would a violation of ISO/OSI to have a standard that interfaced to LANs.

misc. other refs to OSI, HSP and/or XTP:
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

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

death of Edgar F. (Ted) Codd

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: death of Edgar F. (Ted) Codd
Newsgroups: alt.folklore.computers
Date: Mon, 21 Apr 2003 13:50:37 GMT

"Jim Mehl" writes:
Yes, indeed. He described 1st, 2nd and 3rd normal form. There was later a 4th and 5th normal form by others. And then there was a Boyce-Codd normal form. The whole concept got rather out of hand. But those were fun times.

slightly related (from last week):
https://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
https://www.garlic.com/~lynn/2003g.html#41 How to cope with missing values - NULLS?

and I x-posted to comp.database.theory
https://www.garlic.com/~lynn/2003g.html#43 Codd's death (x-post from a.f.c)

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

Disk capacity and backup solutions

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk capacity and backup solutions
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 21 Apr 2003 15:39:27 GMT

Brian Inglis writes:
Who needs bits when you've got megabytes! Unless you're doing embedded systems, most programmers nowadays will use from a byte to a word for flag data to speed up access.

iso 8583 is still fairly conservative on total number of bytes (aka the debit, credit, atm,financial network).

a typical auth message is on the order of 60-80 bytes. when some of the past internet oriented proposals had digital signatures and a certificate appended ... it would add 4k-12k bytes to a 60byte message. the requirements given the x9a10 working group for the x9.59 standard was to preserve the integrity of the financial infrastructure for ALL electronic retail payments (regardless of kind, origin, etc; debit, credit, stored-value, point-of-sale, internet, face-to-face, non-face-to-face, etc).
https://www.garlic.com/~lynn/x959.html#x959

a 60byte to 12kbyte inflaction ... 200 times (not 200 percent, 200 times!) increase in the payload size if they were actually implemented end-to-end integrity/security. it seemed that the fascination with certificates (as opposed to real security) ... it was preferred to carry the certificates over the internet-part ... and then throw them away at the boundary with the real payment network. All sorts of vulnerability opportunities opened up because of the lack of end-to-end security/integrity; one of the payment associations gave a report at an ISO meeting on the number of 60byte packets carry a flag that indicated certificate processing had been performed when there was absolute evidence that there was no certificate processing involved.

past references to payload bloat from certificates:
https://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
https://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2001c.html#8 Server authentication
https://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/aadsm13.htm#10 X.500, LDAP Considered harmful Was: OCSP/LDAP

and only slightly related:
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts

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

Lisp Machines

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Mon, 21 Apr 2003 17:16:26 GMT

Charles Shannon Hendrix writes:
I somehow managed to cram a 4-years degree into only 8 years, so I saw a lot more than some other students. I started in 1986, about the time when the "programmer shortage" was causing pressure on schools to have a higher graduation rate among programmers.

there was some amount of angst during that period .... i believe schools like MIT and UCB had something like 50 percent of the freshman applicants in computer science; there was lots of hand-wringing about whether whole departments might evaporate ... being crowded out by computer science. this issue wasn't so much industry putting pressure on schools to turn out the CS graduates ... but the incoming freshman all wanting to be in CS program.

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

Lisp Machines

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Tue, 22 Apr 2003 02:35:59 GMT

Deborah Gronke Bennett writes:
obhistorytrivia: In the much earlier days of the web (I'm thinking 1994?) this link was the only hit for a search (using Yahoo when it was still inside of Stanford) for the text string "Ampex Core Memory".

1/21/94 "yahoo" reference
ncar.ucar.edu [128.117.8.111]
An archive of selected NCAR data and an inventory of what data is available from their Data Support Section. Some datasets and papers are available. Also includes Colorado weather and ski (yahoo!) reports.

......

12/30/94 reference



http://akebono.stanford.edu/yahoo/Computers/Internet/Newsletters/

Computers:Internet:Newsletters

    [Menu Bar]

Computers: Internet: Newsletters

Digital Future - focuses on the information media and related
technology. Abridged version for free.
 Edupage(2) - Edupage, a summary of news items on information
technology, is provided three times each week as a service by
  Educom
GNN NetNews
In, Around and Online - A Weekly Summary of Events in the Consumer
Online Industry
 LI NewsWire - Here you will find the news and views shaping the
world of Online Information.
 Matrix News@ (2) - Matrix News is a newsletter about cross-network
issues. Networks frequently mentioned include USENET, UUCP,
FidoNet, BITNET, the Internet, and conferencing systems such as
the WELL and CompuServe. Matrix News is not about any single one
  of them. It is about the Matrix, which is all computer networks
worldwide that exchange electronic mail.
 Netsurfer Digest@ (2)
Scout Report - The Scout Report is a weekly publication offered by
InterNIC Information Services to the Internet community as a fast,
convenient way to stay informed on network activities.
 SIMBA Media Daily
The Web Word
 Index - Information Showcase of the Los Angeles Internet Group

_________________________________________________________________

   [ Yahoo | Up | Search | Mail | Add | Help ]

_________________________________________________________________

yahoo@akebono.stanford.edu
Copyright ) 1994 David Filo and Jerry Yang

......
MOUNTAIN VIEW, CALIFORNIA, U.S.A, 1995 JUL 28 (NB) -- Yahoo plans to enhance its Internet navigation and directory site with a more sophisticated look and business plan. In little more than one year, Yahoo has changed from a university project to one of the most popular World Wide Web (Web) sites.

Two Stanford graduate students, David Filo and Jerry Yang, decided the Internet desperately needed an efficient directory, search and navigation tool. Their university project, now know as Yahoo, became a Web site and is visited by more the 300,000 users a day. Filo and Yang, along with a senior management team, are taking Yahoo to a more fully developed, more complete navigational guide.

With incorporation and other business matters settled, the company is demonstrating the first step of its evolution into an online business. On July 31, its Web site will debut a new graphic interface, faster navigational features, news updates from Reuters New Media, and advertisements from five sponsors. The charter sponsors are Internet Shopping Network, Mastercard, MCI, NECX and Worlds, Inc. All have agreed to a three-month trial advertising program.

For Web surfers who are unable to wait for the July 31 debut, Yahoo has a beta version of the site at: http://beta.yahoo.com . The new company says many more changes and new developments are planned for the site, but promises to remain true to the Internet community as a grass-roots guide to the Internet.

Yahoo's director of marketing, Tim Brady, said "We put ourselves into the shoes of a user and asked whether we would want subscriptions or advertising. Without a doubt the answer was advertising. While advertising on the Internet is still unmeasured in its effectiveness, we think it is the avenue which will allow Web sites to turn into effective businesses. We will work closely with our sponsors to make ads as interesting as possible. We are committed to keeping the site free for users."

Looking towards future developments, Brady said Yahoo will consider its own newsgroups or posting areas along with a chat feature. He also said the Yahoo search and directory capabilities would become even more efficient as smart agent technology and broader bandwidth access are integrated into Yahoo's technology.

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

switching to KDE

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: switching to KDE
Newsgroups: redhat.general
Date: Tue, 22 Apr 2003 03:05:03 GMT

Donald McDaniel writes:
How does one switch to KDE desktop in RedHat 9.0? Please, no one-word cryptic commands without apparent context? I would appreciate a clear, step-by-step explanation for accomplishing this task.

click little redhat on the menu bar select "system tools" select "more system tools" click "desktop switching tool" click "kde" click "ok"

directions say that you then have to restart x-windows (you could just log off and log back on again; make sure you haven't selected only applies to current session)

above invokes /usr/sbin/switchdesk .... you can also invoke switchdesk from some command line.

also try man switchdesk

look for filenames starting with .Xclient in your home directory.

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

vnet 1000th node anniversary 6/10

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Mon, 21 Apr 2003 21:56:52 -0600
Newsgroups: bit.listserv.vmesa-l
Subject: vnet 1000th node anniversary 6/10

CP/67 had 35th anniv. ..... product announced at the '68 spring share meeting

vm/370 had 30th anniv .... product announce at '72 summer/fall share meeting

great internet cut-over happened 20years ago on 1/1/83 ... from homogeneous IMP-based infrastructure to "internet protocol"

coming up on 6/10 is the 20th anniv of the 1000th node on the internal network (i have this plexiglass clear globe that says 1000 nodes at the top, a stylized world map in the middle and VNET 1983 IBM at the bottom).

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

effectively the original vnet had gateway functionality in every node from just about the start ... one reason that it grew so fast and it was so easy to add nodes (the internet didn't get this kind of functionality until the 1/1/83 switch-over). VNET had both native interfaces as well as various kinds of NJE interfaces. JES/NJE has made similar mistake as original arpanet, although even worse, misc. protocol issues were mixed in the NJE header .... to the extent that it was possible for a JES/NJE (operating at one release) to crash a JES/NJE (at a different release) just by sending it a message. Over the years, the native VNET/RSCS drivers stopped being shipped with the product, even tho the native drivers were more efficient and higher thruput than the NJE drivers. Because of several shortcomings with JES/NJE, it was relegated to boundary nodes in the internal network because

-- internal network had more nodes than could be defined in JES/NJE table; arriving traffic at a JES/NJE node would be trashed if either the destination node OR the originating node was not in the local JES/NJE table

-- needed VNET/RSCS interface node providing specialized NJE header translation/reformatting to make sure matched the release/version (to keep JES & MVS from crashing). there is this infamous incident where some traffic from San Jose MVS/JES boundary nodes was causing MVS/JES boundary nodes in Hursley to crash.

also bitnet & earn refs:
https://www.garlic.com/~lynn/subnetwork.html#bitnet

Mercury News 04-20-2003 Computer pioneer, dead at 79,

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mercury News  04-20-2003  Computer pioneer, dead at 79,
 revolutionized database
Newsgroups: bit.listserv.ibm-main
Date: Tue, 22 Apr 2003 04:07:41 GMT

related x-post from this weekend
https://www.garlic.com/~lynn/2003g.html#43 Codd's death (x-post from a.f.c)
https://www.garlic.com/~lynn/2003g.html#46 death of Edgar F. (Ted) Codd

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

Lisp Machines

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: alt.folklore.computers
Date: Tue, 22 Apr 2003 04:20:36 GMT

Charles Shannon Hendrix writes:
50% of the freshman applications... in the Boston area or the US? I would doubt the latter, big as MIT may be.

claim was 50 percent of the freshman applicants to MIT ... one of the people I had worked with at cambridge was on some sort of alumni committee looking at the issue.

similar for UCB ... my oldest was one ... UC was getting so many that the were shuffling them off to UCSB, UCSD, etc ... along with a letter explaining on how to appeal. had to have a number of discussions with the university about the issue; apparently it would have been simpler to switch to some engineering than appealing the CS quota(?).

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

Rewrite TCP/IP

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Rewrite TCP/IP
Newsgroups: comp.protocols.tcp-ip,alt.folklore.computers
Date: Tue, 22 Apr 2003 18:13:05 GMT

Bjorn Borud <borud-news@borud.no> writes:
interesting. why has XTP remained obscure? is this changing?

re:
http://www.news24.com/News24/Technology/News/0,,2-13-1443_1350339,00.html

Software breaks data transfer record; 22/04/2003 13:40; Pasadena - US scientists have broken the record for the top speed for transferring data over the internet.

... snip ...

as an aside both XTP and our internal backbone used rate-based pacing
https://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP

at the time of the slow-start presentation at IETF meeting (late '80s stanford), there was SIGCOMM proceedings article that showed that slow-start was non-stable in real world, bursty environments.

random slow-start &/or rate-based pacing refs:
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
https://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2002.html#38 Buffer overflow
https://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002c.html#54 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002k.html#56 Moore law
https://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
https://www.garlic.com/~lynn/2002p.html#31 Western Union data communications?
https://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
https://www.garlic.com/~lynn/2003.html#59 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)

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

Advantages of multiple cores on single chip

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Advantages of multiple cores on single chip
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 23 Apr 2003 16:23:25 GMT

ron@shell.core.com (Ron Peterson) writes:
I recall that one study showed that two processors sharing a cache would require much less than twice that cache size of a single processor.

there is a similar study with respect to global LRU vis-a-vis local LRU ... in paging algoritms and filesystem caches.

I had done global LRU replacement as part of clock while undergraduate at university in late 60s ... and it outperformed the various local LRU implementations; aka global LRU allowed all contending tasks to simultaneously compete for all of memory. the benefit was that working set tended to have an ebb & flow ... decreasing & increasing overtime. the increases of one application frequently was offset by decreases of another application. the caveat was some run-away pathelogical application that tromped over everybody else's pages.
https://www.garlic.com/~lynn/subtopic.html#wsclock

somewhat analogous study was done at SJR in the late 70s with detailed filesystem traces and modeling of cache sizes and cache placement. given fixed amount of electronic store ... filesystem caching performance of a single, system-wide cache always outperformed same amount of electronic store in various partitioned strategries aka channel/bus, disk controller, disk device, etc ... modulo:

1) pathelogical patterns allowed to trample on everybody else's cached records

2) nominal amount of electronic store on each disk used for a) track caching for rotational latency compensation and b) any system wide transfer latencies.

There was some work as part of the detailed filesystem caching regarding

a) large datacenters tended to have some long term patterns aka like payroll access patterns run on weekly or monthly bases; there was some investigation regarding pre-scheduling when there were known, predictable, application specific patterns

b) there was some early result that the record trace could be optimized and run constantly in production environments supporting real-time disk re-organizations.

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

OT What movies have taught us about Computers

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT What movies have taught us about Computers
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 23 Apr 2003 18:31:05 GMT

slight drift, 20 years since wargames, 1983
http://www.imdb.com/Title?0086567

trivia .... the ferry in the movie actually ran between steilicom and anderson island (next to ft. lewis). it has since been refurbished and is now doing tourist trips on lake washington .... out of kirkland; it now periodically cruises by who's estate?

random past refs:
https://www.garlic.com/~lynn/2000d.html#39 Future hacks [was Re: RS/6000 ]
https://www.garlic.com/~lynn/2001m.html#52 Author seeks help - net in 1981
https://www.garlic.com/~lynn/2002b.html#38 "war-dialing" etymology?

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

OT What movies have taught us about Computers

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT What movies have taught us about Computers
Newsgroups: alt.folklore.computers
Date: Wed, 23 Apr 2003 19:46:46 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Oh, is it time to mention the infamous Western State Nuthouse again already? :) (I can't remember if I said last time, but Frances Farmer's autobiography about her time there is so horrible it makes One Flew Over The Cuckoo's Nest sound pretty tame, and the derivitive Girl, Interrupted look a bit pointless)

there are two roads into steilicom ... one thru fort lewis from the south and one the next exit south of tacoma mall off i5, heading west past the institution you mentioned (just before you start down the hill to steilicom).

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

40th Anniversary of IBM System/360

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th Anniversary of IBM System/360
Newsgroups: alt.folklore.computers
Date: Fri, 25 Apr 2003 14:23:15 GMT

there is the ye old search engine
http://www.beagle-ears.com/lars/engineer/comphist/ibm360.htm
http://services3.ieee.org/organizations/history_center/Singapore/Pugh.html
http://www.mcraeclan.com/Links/Computers/IBMMainframeHistory/mvshist1.htm
http://www.chac.org/chac/chhistpg.html
http://www.historytech.org/html/books/chapter_11.html

Plain man's view of 360 at melinda's site:
https://www.leeandmelindavarian.com/Melinda#VMHist

mainframe history tree from vmshare archives:
http://vm.marist.edu/~vmshare/browse.cgi?fn=IBMHIST&ft=NOTE

some on Amdahl
http://www.thocp.net/biographies/Amdahl_gene.htm
http://info.computer.org/dt/dt1997/d2005abs.htm

there has been some claim that gene wouldn't have left and started his own company if it hadn't been for FS (aka his talk at MIT circa '72 was if IBM completely stopped 360 and switched to something else ... there was still enuf legacy 360 software that it would keep him in business thru at least the end of the century):
https://www.garlic.com/~lynn/submain.html#futuresys

and FS wouldn't have been an issue if it was for gov. unbundling and PCM controllers:
https://www.garlic.com/~lynn/submain.html#360pcm

another drift:
https://people.computing.clemson.edu/~mark/acs.html

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

can't close tab after abort 1.3/1.4a

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: can't close tab after abort 1.3/1.4a
Newsgroups: netscape.public.mozilla.general
Date: Fri, 25 Apr 2003 17:42:20 GMT

if i open a URL in a new tab ... and it aborts for any reason (time-out, etc), then it is not possible to make the tab go-away. it is possible to load other stuff in the tab ... but "c-w/close tab/close other tabs" won't make it go away.

i've done sequence of for 20-30 open in new tab, with maybe five having time-out or invalid domain name, etc. can make all go away except the ones that aborted.

both 1.3 and 1.4a

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

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
monopoly
Newsgroups: comp.os.vms,alt.folklore.computers
Date: Sun, 27 Apr 2003 17:41:36 GMT

jmfbahciv writes:
One of them is a 10% tax. If it had been called a tax, there would have been a revolt. But it's called a "fee for hunger" or something stupid like that to falsely portray that the gouging supposedly goes to schools or something educational or something else.

there was article in today's paper about some amount of PUCCs mandated tariffs for telephone company is in support of social programs

... aka rather than having it show up as a gov. tax ... that then subsidizes/grants in support of social programs (service for schools, service for old people, rural service, etc) ... various PUCCs (not just FCC) ... mandate certain tariffs such that telephone company is deliverying support for various social programs ... w/o it actually showing up on the gov. ledgers.

the point of the article was a lot of the excess charges were being made on long distance service in order to underwrite various of the social programs ... and that over the last couple years there has been a big shift from traditional long distance phone company to wireless from other providers (article claimed 12 percent per annum decrease in traditional long distance with a minimum 2 percent per annum increase in demand for social program services). As long as it was a single legal entity that PUCC & FCC were dictating to charge excessive fees on certain services in order to underwrite social programs ... then it could be kept off the gov. books.

with different legal entities starting to be involved in long distance service and the mandated local social program supports .... then it becomes much more difficult to keep the funding of such social programs off the gov. books.

Eventual solution is that each business has to charge the full going rate for service ... regardless of social program objectives ... and then the governemnt has to underwrite certain services .... bigger allotments to schools, tax rebate for elderly, subsidies for rural operations, etc. ... along with necessary increases in gov. tax collections to directly cover the social programs being underwritten.

WIth single legal entity ... the gov. could mandate certain funds move from one part of the operation to another part of the operation w/o it directly showing up on gov. books. It is when different legal entities are involved that taditionally the gov. needs to be involved ... shifting money from one entity to a different entity.

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

IBM zSeries in HPC

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM zSeries in HPC
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 28 Apr 2003 21:33:10 GMT

"Glen Herrmannsfeldt" writes:
I don't believe it is that bad in performance, but probably worse in price/performance. Well, what is the price for a 386 system today?

probably have to pay somebody to take a 386 ... possibly negative price/performance. some minor historical refs of 386 when i was trying to indicate pricing trends ... vis-a-vis some of the ps/2 strategy:
https://www.garlic.com/~lynn/2001n.html#81 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
https://www.garlic.com/~lynn/2001n.html#82 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)

slightly earlier than the above reference time-frame when bottom dropped out of 286 market. some far east companies had built up a large inventory (by the standards of the time) of 286 systems getting ready for the xmas season. 386sx20mhz came in at price that they were planning on selling the 286 systems for ... and the whole thing cratered.

remember the fun of trying to get a 10mhz crystal or even 12mhz crystal working in a 8mhz at?

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

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
 monopoly
Newsgroups: comp.os.vms,alt.folklore.computers
Date: Tue, 29 Apr 2003 19:22:35 GMT

Brian Inglis writes:
CMU SEI CMM level 5 organizations are also said to produce consistently unusable programs. Most developers I've met are lazy: some creatively so, others just bone idle, so I'd expect the thought of having to fill out (virtual) paper to implement a feature would ensure not much gets added to or changed in a program. Heavy weight processes are great for long lead time development, especially when user death is a critical factor, as in military/aerospace/medical machinery control systems, but for non-critical process support systems, usability is normally the critical success factor.

i've often commented about service level application for business critical operation are 4-10 times the effort of just writing the straightline application code ... and possibly four or more times the number of lines of code. Part of the issue is the degree that the underlying infrastructure have support for business critical operation.

we did a one week JAD a couple years ago with one of the object application development suites regarding the business critical issue ... and identified a 30 percent hit to all their existing operations and an additional 30 percent for new feature/function in support of business criticial operation.

in any event, thinking about the business critical issues can be more than ten times the effort of the straight line application implementation ... and whether it is four times or ten times more code depends on to what degree the underlying infrastructure has support for business critical operation.

when we were doing the payment gateway stuff in support of what has become to be called electronic commerce ...
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
we developed a failure-mode grid that was used after the straight-line stuff had all been done and extensively regression tested. The issue is the nominal service operation had the facility of doing first level problem determination and diagnostic within five minutes.

Part of the issue was that some amount of the payment protocol from circuit based infrastructure was morphed into a internet packet orientation .... and all the implicit diagnostic stuff (not in the higher level protocol) that was part of end-to-end circuit environment was gleefully ignored. The other part involved people that had experience doing stand-alone, desktop, straightline application ... trying to translate that into a business critical service environment ... and all of a sudden there are a whole set of issues which they didn't even know that they didn't know (aka who cares if customer calls in with a problem and first level support spends three hours on it and closes the trouble ticket: NTF; no trouble found).

in some sense this is analogous to the enormous increase in buffer overflow exploits because the way string handling was implemented (the buffer exploits weren't seen in platforms with other string handling paradigms).

note that lot of SEI has to do with total life cycle costs. many of the facilities that have been shown to practically address production quality & business critial rapid development and life cycle costs ... tend to have steep up-front learning curves.

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

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
monopoly
Newsgroups: alt.folklore.computers
Date: Tue, 29 Apr 2003 19:54:24 GMT

"Charlie Gibbs" writes:
Around here, when a clerk runs my credit or debit card through one of those little terminals, I hear the sounds of a 1200-bps (maybe sometimes 2400-bps) connection coming from the box. Anything faster would be well beyond the point of diminishing returns.

actually tests with faster modems have shown to increase the total transaction elapsed time ... i.e. single packet out and single packet in ... on the order of 60-90 bytes and the faster modems have longer negotiation times (the longer negotiation times more than offset any reduction in the small packet transmission time).

basically a lot of those little boxes can be viewed as repackaged PC/XTs.

we did some amount of timing when we were doing the initial payment gateway install for what became called electronic commerce. avg. total elapsed round trip for the original electronic store (where a lot of people bought a browser) ... was on the order of 300ms to 500ms ... and a lot of that involved the internet delay between the commerce sever and the payment gateway (depending on the interface used ... internet typically involved anywhere from 6 to 12 hops). Once it got to the payment gateway there was dedicated x.25 leased line into the acquiring processor.

so figure a hundred mills or so, plus the transmission time of two 60 byte packets at 1200 baud, plus the call connection and modem negotiation time.

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

UT200 (CDC RJE) Software for TOPS-10?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: UT200 (CDC RJE) Software for TOPS-10?
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Tue, 29 Apr 2003 23:40:11 GMT

Peter Flass writes:
HASP RJE would run rings around most of the other systems of the same vintage. It was a true full-duplex system. If you were doing both input and output from your RJE, instead of just ACKing each block it would piggy-back the ACK in a block of data going the other way. Also, I believe it allowed a number of blocks to be transmitteed without an ACK - standard now, but unusual back then. Nice little system.

we didn't need 2780 support ... and so I deleted most of the code (cut down on resident requirements) ... when i was doing a CRJE hack into HASP (on MVT 18) .... basically put in 2741 & ascii/TTY terminal support ... along with edit syntax borrowed from cms editor.

marginally related discussion about windowing and rate-based pacing
https://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP

CRJE - conversational remote job entry

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

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
monopoly
Newsgroups: comp.os.vms,alt.folklore.computers
Date: Wed, 30 Apr 2003 12:32:00 GMT

Brian Inglis writes:
CMU SEI CMM level 5 organizations are also said to produce consistently unusable programs.

and somewhat related to SEI at CMU is the dependable computing which CMU has grant from NASA
http://www.hdcc.cs.cmu.edu/index.html
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html

and various stuff on assurance:
https://www.garlic.com/~lynn/subintegrity.html#assurance

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

software pricing

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: software pricing
Newsgroups: alt.folklore.computers
Date: Wed, 30 Apr 2003 13:16:21 GMT

The Allure of Annuity Pricing Models
http://itmanagement.earthweb.com/cio/article.php/2198821
For most of the industry's history, software has been sold in-perpetuity via lump sum payments based a predetermined number of users

note that starting with unbundling 6/23/69 thru the '70s ... all the pricing of software that I knew about was all monthly licenses. in fact, for the resource manager ... I got told that it would be the first SCP (aka operating system) priced software and I would have the priviledge of working with the business people regarding how to price operating system software.
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

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

death of Edgar F. (Ted) Codd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: death of Edgar F. (Ted) Codd
Newsgroups: alt.folklore.computers
Date: Wed, 30 Apr 2003 16:21:43 GMT

"Jim Mehl" writes:
Now that's a good story. That ranks up there with the one about the professor coming in through the transom.

riding unicycle on campus?
https://www.garlic.com/~lynn/2003e.html#27 shirts

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

IBM zSeries in HPC

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM zSeries in HPC
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 30 Apr 2003 20:28:21 GMT

lindahl@pbm.com (Greg Lindahl) writes:
No. The journal articles pointed at elsewhere say it wasn't. The vector facility (VF) product died fairly quickly after introduction, because Joe Average HPC app ran better on workstations. Even IBM was recommending RS6000s over the VF.

VF was introduced with the 3090 .... I did hear some rumors that the 3090 could execute scalar floating point at nearly memory bandwidth saturation with some implication VF floating point didn't gain a whole lot more (i have no idea how true it was ... and I haven't run across any nominal mflops with & w/o VF; i'm sure they exist, i just haven't seen them). some misc. description (3090vf & FPS):
https://www.garlic.com/~lynn/2000c.html#61 TF-1

i think that the emerging high performance workstations dealt a pretty good blow to a lot of the mainframe, mini-super, & custom (like FPS) numerical intensive.

following linpack extract
https://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it?

has some numbers for the es/9000 (3090 follow-on that also had VF option) ... with cray2 (one processor), 6000/580, es/9000-520 (single processor), challenge (2 processor) all clocked at 38 mflops. Minor note with regard to comment in above ref'ed posting .... there was a thread involving national lab rain/rain4 benchmarks .... & they were used before linpack existed.

other past 3090vf refs:
https://www.garlic.com/~lynn/2000c.html#5 TF-1
https://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
https://www.garlic.com/~lynn/2003.html#1 cost of crossing kernel/user boundary

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

rh9/evolution/filters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: rh9/evolution/filters
Newsgroups: redhat.general
Date: Thu, 01 May 2003 14:52:48 GMT

two classes of email ... stuff I know is to be deleted and some that i'm not sure of. i move the possibles into a spam folder for later checking and use "deleted" on the ones i know to be deleted.

the problem is that deleted leaves the file in my inbox with a line thru it. i want them gone ... not even have to know they ever existed.

i try moving them directly to trash folder ... but filter option doesn't allow that.

compromized ... i first moved them into the same folder with the possibilities and then set deleted (aka when i get around to visiting the spam folder, i can automatically do an expunge ... which is still annoying, but not as annoying as having them in the inbox).

the files move, but they don't show up deleted. i use both deleted & set-status/deleted ... they still don't show up deleted.

so the work around seems i need two spam folders ... one that is really a substitute for trash into which i can move stuff & forgot about ... except to periodically clean up ... and the other, a possible spam folder.

what i really want is the ability to move a file directly into the trash folder (and never have to know it existed). it is also somewhat interesting ... that i can't seem to move a file and also mark it deleted.

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

Simple resource protection with public keys

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Simple resource protection with public keys
Newsgroups: sci.crypt
Date: Thu, 01 May 2003 15:28:41 GMT

Peter Fairbrother writes:
Forgot to mention that you should also keep a list of logins in the time delta, and refuse (and log!) duplicates, otherwise a replay attack is possible. Is eg the user's IP in the signed message?

Both of the last two are far more important than adding csprng bytes.

sha-1 & ecdsa (fips186-2) ... aads chip strawman hardware token actually performing the sha1 & ecdsa operation.

for replay attack, the choice is either two round trips .... with both the server and client providing unique values for the client to sign ... or a single round-trip where the server keeps a log of recently signed messages.

the radius example uses two round trips .... which is common for radius in any case ... which currently tends to be client contact with userid, server response, client authentication, server response. the signed version replace what is typically a passowrd for authentication with digital signature.

a single-round trip example is the x9.59 payment protocol ... also using ecdsa signature:
https://www.garlic.com/~lynn/x959.html#x959

in fact, the x9a10 standards group was pretty much given as one of the requiements that the (x959) payment protocol had to work in a single round-trip across a wide range of environments. in this case, the server is the consumer's financial institution ... where a log is required to handle duplicate/replays scenarios.

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

next, previous, index - home