List of Archived Posts

2002 Newsgroup Postings (03/13 - 04/06)

Storage Virtualization

More on Aging Legacy Workforce

IBM's "old" boss speaks (was "new")

IBM's "old" boss speaks (was "new")

Mainframers: Take back the light (spotlight, that is)

What goes into a 3090?

LISTSERV(r) on mainframes

Bus & Tag, possible length/distance?

What are some impressive page rates?

What are some impressive page rates?

Deleting files and emails at Arthur Andersen and Enron

What are some impressive page rates?

Progress? (was Re: Way up north in Alaska ...)

Back to the H20Cooler

EMV cards

Deleting files and emails at Arthur Andersen and Enron

Deleting files and emails at Arthur Andersen and Enron

Smart Cards

Opinion on smartcard security requested

What goes into a 3090?

What goes into a 3090?

Crazy idea: has it been done?

Opinion on smartcard security requested

Opinion on smartcard security requested

Back to the H20Cooler

Crazy idea: has it been done?

Crazy idea: has it been done?

moving on

moving on (typo)

Crazy idea: has it been done?

Progress? (was Re: Way up north in Alaska ...)

Hardest Mistake in Comp Arch to Fix

What goes into a 3090?

Mainframers: Take back the light (spotlight, that is)

Lisp Chips

Replacement for RFC 1700?

Crypting with Fingerprints ?

Would the value of knowledge and information be transferred or shared accurately across the different culture??????

Crypting with Fingerprints ?

Why Use *-* ?

Smart Cards

REVIEW: "Authentication: From Passwords to Public Keys", Richard E. Smith

What goes into a 3090?

Hardest Mistake in Comp Arch to Fix

SQL wildcard origins?

REXX and its designer (was: IBM 7090 instruction set)

What goes into a 3090?

Multics_Security

flags, procedure calls, opinions

PKI and Relying Parties

IBM going after Strobe?

IBM 360 definition (Systems Journal)

PKI and Relying Parties

Mainframers: Take back the light (spotlight, that is)

Mainframers: Take back the light (spotlight, that is)

Mainframers: Take back the light (spotlight, that is)

PKI and Relying Parties

Mainframers: Take back the light (spotlight, that is)

O'Reilly C Book

Computers in Science Fiction

Browser Security

Computers in Science Fiction

Computers in Science Fiction

Computers in Science Fiction

Computers in Science Fiction

Digital Signatures (unique for same data?)

First images in email?

Blade architectures

Blade architectures

Computers in Science Fiction

Computers in Science Fiction

Blade architectures

Digital certificate varification

Blade architectures

Computers in Science Fiction

Computers in Science Fiction

Storage Virtualization

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Storage Virtualization
Newsgroups: comp.arch.storage
Date: Wed, 13 Mar 2002 17:15:37 GMT

"Bill Todd" writes:

IOPS is indeed a fairly standard figure of merit quoted by disk vendors.  It
has a pretty standard definition:  sequential (non-queued) random small read
requests (effectively averaging a 1/3 stroke seek and 1/2 rotation in
latency, though with minor biases due to disk zoning).

aka random arrival with FIFO (or non-queued) queueing vis-a-vis random
arrival with some sort of optimized queue re-ordering.

with FIFO (or non-queued) queueing, the avg seek & rotation between
serviced operations will be the same as the arrival.

with some sort of optimized queueing, the order that the operations
are serviced are different than the order that they arrive,

aka operations have been re-ordered so that the avg seek & rotation
between serviced operations is minimized. depending on queue depth,
total thru-put with queue re-ordering can easily double or triple
total thruput per second.

a possible easier comparison to understand is fixed-head disks
... where arm motion isn't a factor and only rotational delay comes
into play. random/FIFO results in approx. two requests per revolution.
optimized re-order queueing can reach requests per revolution
equivalent to number of records per track (which for small records &
large tracks .. can be significant number).

with deep enuf queue, non-fixed-head disks could even result in
servicing multiple requests per arm position (with some sort of
optimized queue re-ordering).

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

More on Aging Legacy Workforce

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More on Aging Legacy Workforce
Newsgroups: bit.listserv.ibm-main
Date: Wed, 13 Mar 2002 22:15:31 GMT

jfregus@IX.NETCOM.COM (John F. Regus) writes:

Maybe this is the answer, but one thing is for sure...we should not as a
nation, allow an increase in foreign worker visas for system engineering
jobs, just because employers know these people are willing to work at a
fraction of what the American worker is willing to work for.....

it isn't just a matter of foreign work visas ... it is foreign workers
make up a large percentage of qualified workers. During the early '90s
there was some report that there was 1) severe shortage of advance
degree technical graduates and 2) half of the advance degree technical
graduates in the US were foreign.

it was verging on implying that 1) a lot of US kids weren't motivated
to work that hard, 2) a large amount of the technology advancements
during the '90s was fueled by foreigners, 3) it wasn't a question of
salary ... it was a question of having them at any price.

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

IBM's "old" boss speaks (was "new")

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's "old" boss speaks (was "new")
Newsgroups: bit.listserv.ibm-main
Date: Wed, 13 Mar 2002 23:57:43 GMT

IBM-MAIN@ISHAM-RESEARCH.COM (Phil Payne) writes:

IBM is still in need of a breakup, but an internal one.  Software
Division should be broken up and handed to the product houses.
Middleware products should go into a hat and be pulled out by the
respective VP&GMs of the server divisions.

middleware and servers had been no-no words ... it was suppose to have
been SAA at least until the year ibm went into the red.

the other part was that there was prediction that ibm mainframe
business was going to shortly double again ... so there was big
spending on doubling manufacturing capacity just as growth went flat
or some declined.

random middleware, saa, server:
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#19 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#48 Speaking of Gerstner years

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

IBM's "old" boss speaks (was "new")

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's "old" boss speaks (was "new")
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 14 Mar 2002 05:07:29 GMT

ted.macneil@mobile.rogers.com (ted.macneil) writes:

Does anybody remember ADSTAR?
It never really got off the ground when IBM realised that storage and storage management was too profitable to spin off.

For years, the only remnant was ADsm, which is now TSM.
:-{)}

and adsm lineage was workstation datasave (out of sjr/arc before being
transferred to adstar) ... and before that some other stuff.

random refs:
http://www.garlic.com/~lynn/2001n.html#66 Holy Satanism! Re: Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2001n.html#92 "blocking factors" (Was: Tapes)
http://www.garlic.com/~lynn/99.html#149 OS/360 (and descendents) VM system?

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

Mainframers: Take back the light (spotlight, that is)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: alt.folklore.computers
Date: Thu, 14 Mar 2002 15:25:05 GMT

"Russell P. Holsclaw" writes:

No. That started somewhere else, AFAIK.  RAID started with the idea that all
those teeny little disk drives made for PCs could be bundled together and
compete effectively with the big-platter drives that IBM was still building
then. That, and achieve all sorts of speed and redundancy at the same time.

I can't find the reference ... but I believe the first implementation
was by rochester/as400 (note the patent predates the as/400). There
was also disk stripping in early '80s.

from IBM disk history:
http://www.papyrusweb.ch/Syspinner/IBMHistoryOfFirsts.asp

1978

First patent for RAID (Redundant Arrays of Independent Disks)
technology. IBM subsequently co-sponsored the research by the
University of California at Berkeley that led to the initial
definition of RAID levels in 1987.  The first two-speed tape unit,
raising streaming speeds to 160 kb/second.

Hierarchical Storage Manager (HSM), which provided customers
system-delivered migration of inactive data from disk to less
expensive tape.

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

What goes into a 3090?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What goes into a 3090?
Newsgroups: alt.folklore.computers
Date: Thu, 14 Mar 2002 15:34:47 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:

One final thing which struck me as a bit strange is that
neither unit seemed to have the traditional front panel with
interesting lights; they just had a couple of rather
uninteresting looking buttons to power the things on and off.
Had the S/370s done away with front panels by that time, or
did it just live elsewhere (ops room, for example?)

two things that went into a 3090 ... were a pair of 4361s (small 370s,
from line 135, 138, 4331, 4361) running vm/370 release 6.

IBM service had a policy that they could bootstrap diagnose machine in
the field starting with a scope. Starting with 3081 it was no longer
possible to scope ... so there was a "service processor" that had all
sorts of probes into the machine for diagnosing ... and the service
processor could be scoped. The service processor on 3081 was a uc.5
microprocessor (also used in 37xx, 8100, and some number of other
products). The service processor on the 3090 was redundant 4361s.  All
the service menus were written in IOS3270.

random refs:
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#41 IBM 4361 CPU technology
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#61 Living legends
http://www.garlic.com/~lynn/99.html#62 Living legends
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#181 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
http://www.garlic.com/~lynn/2000c.html#5 TF-1
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2001.html#54 FBA History Question (was: RE: What's the meaning of track overfl ow?)
http://www.garlic.com/~lynn/2001.html#62 California DMV
http://www.garlic.com/~lynn/2001b.html#28 So long, comp.arch
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#2 Alpha:  an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001j.html#13 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#4 hot chips and nuclear reactors
http://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
http://www.garlic.com/~lynn/2001k.html#73 Expanded Storage?
http://www.garlic.com/~lynn/2001l.html#14 mainframe question
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001n.html#58 Certificate Authentication Issues in IE and Verisign
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#3 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#32 First DESKTOP Unix Box?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#10 IBM Mainframe at home

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

LISTSERV(r) on mainframes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: LISTSERV(r) on mainframes
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 14 Mar 2002 17:29:32 GMT

gabe@GABEGOLD.COM (Gabe Goldberg) writes:

Not true.  LISTSERV for VM has been continuously available since 1986 and

misc. additional ref, listserv, bitnet, earn (& visit to paris, 1985)
http://www.lsoft.com/products/default.asp?item=listserv-history

start of bitnet in europe (earn, early 1984)
http://www.garlic.com/~lynn/2001h.html#65 UUCP email

bitnet & csnet 1980/1981
http://www.garlic.com/~lynn/2000d.html#72 When the Internet went private

random bitnet/earn/listserv
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
http://www.garlic.com/~lynn/99.html#38c Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#39 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#126 Dispute about Internet's origins
http://www.garlic.com/~lynn/99.html#225 BBSs vs. The Internet
http://www.garlic.com/~lynn/2000.html#38 Vanishing Posts...
http://www.garlic.com/~lynn/2000b.html#67 oddly portable machines
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000f.html#22 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#51 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2000g.html#39 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#19 What is "IBM-MAIN"
http://www.garlic.com/~lynn/2001e.html#12 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001e.html#25 Pre ARPAnet email?
http://www.garlic.com/~lynn/2002b.html#54 Computer Naming Conventions
http://www.garlic.com/~lynn/2002b.html#56 Computer Naming Conventions
http://www.garlic.com/~lynn/2002b.html#57 Computer Naming Conventions

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

Bus & Tag, possible length/distance?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Bus & Tag, possible length/distance?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 14 Mar 2002 21:03:13 GMT

Ken.Porowski@CIT.COM (Porowski, Ken) writes:

IIRC 400 was the max. except on 3803/3420 which was temperamental (although
the '45 could be too).
If you are going to push the limits use the 'blues' with as few (preferably
no) butts.
Not sure but could you use 2 escon converters (1 @ CPU, 1 @ device and run
escon between?

blk mux & data streaming was introduced at the same time. blk mux
channels had protocol that allowed channel disconnect/reconnect (aka
set sector disk CCW). old channels had synchronous hand-shake per byte
and 1.5mbyte transfer and 200'. data streaming did the 8byte trick,
extended/doubled the max. distance to 400' and added 3mbyte/sec
support.

The max. distance is the "daisy-chain" distance ... if you have
multiple controllers on the same channel ... there is cable from the
channel to the first controller, then cable from first controller to
second controller, etc. The sum of all the cable distances for the
same channel is the 400' limit. This would be a single 400' cable if
there is only one controller (and the controller supports data
streaming).

random refs:
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?></pre>
http://www.garlic.com/~lynn/2001h.html#28 checking some myths.

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

What are some impressive page rates?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What are some impressive page rates?
Newsgroups: alt.folklore.computers
Date: Fri, 15 Mar 2002 15:19:59 GMT

"John Lynn" writes:

I was trying to impress some young Compaq jock the other day on the speed of
IBM processors with expanded storage and a good OS (like VM/XA, VM/ESA or
maybe even Z/VM)... but I could not swear to any really really massive
pages/second on super-busy systems... Does anyone have any true numbers?
Thanks...

garlic baiting huh?

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

span of time nearly 15 years (late '60s to early '80s) ... relatively
normal, mix-mode workload with sub-second response (3081k was around
.11secs 90th percentile for trivial interactive). primary paging
device ("drums") were fixed-head disks. '67 had paging drums on single
1.5mbyte/sec I/O channel capable of little over 300
4k/sec. Interactive workload paging in 105 pages tended to bursty
(periods of 100 percent utilization). 3081k had two 3mbyte/sec
channels ... but 2305 were still 1.5mbyte/sec transfer ... mixed-mode
workload also tended to be somewhat bursty (short periods of 100
percent utilization ... with avg. at 50 percent utilization).

there were some configurations in the '80s that had STC or Intel
"electronic" drums ... aka devices emulated 2305 fixed head disks that
were all electronic (neither arm latency or rotational latency). Lore
was that these devices were built from "memory" chips that had failed
Q&A test ... the disk emulation electronics could compensate for all
sorts of failing bit locations and map around them. However, with the
real 2305s and rotational delay ... and any load ... page queueing
strategy would re-order pages to do full-track I/O transfers
(effectively operated with very low avg. latency per page) mitigating
the latency difference between rotating drums and electronic drums

later in '80s (early to mid '80s) VM got "big pages" .... i.e. a page
I/O operation could be a single 4k page transfer ... or a full-track
transfer of pages (10 at a time on 3380) ... using a journaling
(write-optimized) strategy (attempting to optimize moving arm 3380
devices to be close to fixed-head devices in thruput). 2305 fixed-head
could re-order queue so that it could pick any page from any track in
order to get a full track of page transfer in single revolution. The
probability of finding large numbers of pages in the queue at the same
arm position to allow full track transfer was low. However, the 3380s
were 3mbyte/sec data transfer (twice 2305 fixed-head).

Big pages was a strategy to cluster tracks worth of a process's
virtual pages in a single transfer. This tended to increase the total
number of pages transferred ... compared to a straight single page at
a time strategy. The trade-off was that ten pages were transferred in a
single arm/rotation latency instead of having ten arm/rotation
latencies. In effect, it was trading off less efficient use of real
memory and transfer bandwidth against significant reduction in
arm/rotation latency per page. Lets say "big pages" resulted in 30
percent more pages (3 out of 10) transferred than necessary compared to
a single page strategy ... however, the overall system thruput went up
because of the reduced avg. arm/rotation latency for the other 70
percent (7 out of 10).

The point of the 360/67 and 3081k comparison was that the relative
system thruput of disk technology had declined by a factor of five to
ten times over a ten to 15 year period (aka processor and real memory
resources had increased by factor of 50 times, but avg disk record
access latency had only improved by a factor of less than four). With
somewhat similar workload, the total number of simultaneous users
supported had increased proportional to overall disk latency. The
strategy was to try and trade-off transfer bandwidth (which had
increased by factor of ten) and real storage against access latency
... aka increase significantly the amount of data transferred per
access.

This was similar to various RAID and journaling file system strategies
motivations later in the '80s; aka ... in part ... do much larger
transfers per access operation ... also attempt to use real memory for
caching to minimize reads ... and optimize for a write mostly
environment (journaling file system). The problem with the journaling
file system was that garbage collection frequently negated the
write-oriented optimization. The write-optimized advantage in the big
page strategy was that there was high re-use of pages once written ...
and reading a page effectively made it evaporate from disk eliminating
the need for garbage collection.

The write-optimized strategy was to dedicate 3380s arms and 3380 track
space. The 3380 track space needed to be possibly ten times larger
than the total expected number of allocated pages. Arm motion tended
to be one of the elevator-type algorithms. When it came to write out
the next big page, the closest unallocated track in the direction of
travel was where the big page went. Because of the sparse allocation
(ten percent) that tended to be at the same arm position ... until all
tracks on that cylinder filled and it moved to the next nearest
cylinder. The is similar to the write-optimized journal file system
stuff ... except they didn't have the luxury of old pages evaporating
and had to do garbage collection ... and they couldn't mandate ten
percent or lower space allocation.

In any case, big-pages possibly increased the number of pages
transferred per application by 10 to 50 percent (compared to strict
single page at a time strategy) ... however, big page strategy
increased the system capacity for page transfer by possibly 500
percent (compared to single page at a time on movable arm disk). As a
result, both application and total system thruput went up (aka even if
the number of page transfers doubled, being able to do five times as
many came out a net win).

zero latency, 3mbyte/sec transfer across four dedicated channels of
dedicated 3380 paging devices is 3072/sec. 3mbyte/sec is 1.3 mills for
4k-transfer. 16mills avg latency per 10 page transfer comes out to
1.6mills per page. write-optimized allocation tended to do multiple
writes per arm position as a result avg latency was closer to 10 to 12
mills or around 1.2mills per page transferred ... or about 50 percent
latency and 50 percent transfer ... reducing the 3072/sec in half to
1536/sec. With the smarter track caching controllers and multiple
track writes at the same arm position, even avg. rotational delay
between writes could be eliminated (avg. latency dropping below
10mills/transfer) ... possibly raising the peak thruput into the
2000-2500/sec range ... aka mid to late '80s.

past discussions:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001k.html#60 Defrag in linux? - Newbie question
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
http://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names

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

What are some impressive page rates?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What are some impressive page rates?
Newsgroups: alt.folklore.computers
Date: Fri, 15 Mar 2002 15:53:40 GMT

Anne & Lynn Wheeler writes:

garlic baiting huh?

machine         360/67  3081K
mips            .3      14      47
pageable pages  105     7000    66
users           80      320     4
channels        6       24      4
drums           12meg   72meg   6
page I/O        150     600     4

the other factor for high page rates is pathlength. when i started on
cp/67 ... the aggregate pathlength to do 150 page i/os per second
would have been around something like 70 to 80 percent of the
processor (page fault, page replacement, i/o supervisor, dispatching,
etc). Many systems of the era had similar pathlengths.

i got the aggregate cp/67 pathlength down so 150 page i/os was around
15 percent of the processor.

as an aside ... even with the high page i/o rate in the mentioned ('67
& 3081) configurations and low page i/o pathlength overhead ... total
processor utilization was still around one hundred percent (aka
productive system thruput ... not just page thrashing environment).

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

Deleting files and emails at Arthur Andersen and Enron

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Deleting files and emails at Arthur Andersen and Enron
Newsgroups: comp.arch.storage,alt.folklore.computers
Date: Fri, 15 Mar 2002 19:50:35 GMT

cthomaier@mindspring.com (Conrad Thomaier) writes:

I was listening to the news today and they talked about how AA and
Enron were deleting files and emails.

It brought up this question: How easy is it to completely delete files
and emails?

I would assume that large companies like these have sophisticated
backup systems that would keep copies of emails and files on tape.
They would certainly be backing up data stored on the networks.   And
typically (but not necessarily always) wouldn't data stored on an
individual's PC's hard drive be also backed up across the network?

So, just because I "delete" an email or file, does that mean the email
or file is deleted from wherever it was backed up?

Or are the AA and Enron folks fooling themselves into thinking their
files and emails are gone?

say you have a disaster/recovery plan and at least weekly backups and
the email was on a disk for two months. depending on onsite and
offsite tape cycle ... the email could exist on 8 tapes, several
stored onsite and at least a couple stored offsite.

if it is full media backup ... such tapes will contain an quite a bit
of data ... other than email ... so it wouldn't normally be a case of
just burning all the tapes.

possibly the most famous of all of these was ollie (and I don't know
if I get any of that blame because of some of the email backup
practices I propagated in the '70s ... long-term email could be
sitting around possibly on multiple tens of tapes).

For PCs ... besides any of the local backup that may be done by
individuals, there are all sorts of enterprise copying/backup to
central/enterprise servers, which, then in turn do backup (workstation
datasave, adsm, etc) as part of general recovery as well as enterprise
disaster/recovery plans.

random refs:
http://www.garlic.com/~lynn/2001n.html#66 Holy Satanism! Re: Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2002e.html#3 IBM's "old" boss speaks (was "new")

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

What are some impressive page rates?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What are some impressive page rates?
Newsgroups: alt.folklore.computers
Date: Sat, 16 Mar 2002 14:14:32 GMT

Anne & Lynn Wheeler writes:

later in '80s (early to mid '80s) VM got "big pages" .... i.e. a page
I/O operation could be a single 4k page transfer ... or a full-track

the other characteristic of "page pages" is it is a "no-dup" algorithm.

a "duplicate" algorithm remembers the disk location of a page after it
has been read into real memory (a copy of the page exists on both disk
and in real storage). if the page is subsequently selected for
replacement and hasn't been changed during its most recent stay in
real memory, a write to disk can be avoided by remembering its
previous disk location.

a "no-duplicate" algorithm discards/forgets any previous disk location
for a page (when it is read into real memory, aka a page either exists
on disk or in memory, but not both) and any time a page is selected
for replacement it is always written out to (a new) disk location.

A no-duplicate algorithm increases the page write activity as a
trade-off either to minimize disk space requirements or (in the big
pages case) as part of strategy for minimizing disk access latency per
transfer.

As previously mentioned a "big page" implementation also typically
increases page transfer rates (compared to a page at a time
implementation). On page out, a cluster of pages equivalent to track
capacity is gathered together and written out as a single unit
(minimizing disk access latency per page transfer). If there is a
subsequent page fault for any page in a "big page" cluster, the whole
"big page" is fetched as a single transfer. An attempt is made to
select members of a "big page" based on some probability that if any
particular page is used that all of them will be used. As a program's
access patterns change over time, members of particular big page can
also change. As a result, it is not always true that just because a
program had previously referenced all pages in a particular big page
cluster that it would continue to in the future ... aka a subsequent
big page "read" will fetch into memory some virtual pages that the
program wouldn't be referencing.

misc. dup/no-dup previous discussion:
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching

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

Progress? (was Re: Way up north in Alaska ...)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Progress? (was Re: Way up north in Alaska ...)
Newsgroups: alt.folklore.computers
Date: Sun, 17 Mar 2002 15:59:35 GMT

Ric Werme writes:

Here in NH, all the income from the state lottery goes to schools.  I have
a fantasy of being asked to be a substitute teacher one day when the
subject is probability and statistics.  I doubt I'd be asked back.  :-)

I once saw an analysis of the cal. lottory.

The first week, a community "invests" 1 million dollars in the
lottory.  The cal. lottory (has something like a 80 percent paybacK)
pays back $800,000 and the other $200,000 goes to the state. Much of
the $800,000 is taxed as income by both federal & state ... something
up to 30 percent goes to taxes. or possibly $240,000 leaving
$560,000. In this scenario ... the gov(s) take more in income taxes on
the pay back .. than the amount they keep directly off the lottory.

the second week the remaining $560,000 is "invested" in the lottory.
The lottoray pays back $448,000, of which 30 percent goes to taxes
leaving $313,600.

For the big sum paybacks ... the gov(s) have been able to "take" on
the order of 50% each week between the take off the top directly by
the lottory plus the remaining take from income taxes.

There have also been some questions as to the costs of operating the
lottory ... and what of the lottory net each week actually makes it to
the schools (analogous to some of the consumer issues raised as to
non-profit charities).

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

Back to the H20Cooler

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Back to the H20Cooler
Newsgroups: earthlink.watercooler
Date: Sun, 17 Mar 2002 20:55:59 GMT

"rowe" writes:

But Earthlink never really had a "watercooler"...that was a MindSprung
thing. EL always had the coffeehouse.--jonathan

no netcoms that still had their shell accounts ... until the
take-over?

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

EMV cards

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EMV cards
Newsgroups: sci.crypt
Date: Mon, 18 Mar 2002 16:39:31 GMT

"Gaetano Lazzo" writes:

Ok, forget MPCOS.
Let's talk of EMV (hey, the subject was EMV card anyway!!!)

a lot of the cards have 8-bit chip, low tamper-evident
characteristics, and poor random number generation characteristics
(keys are injected at personalization). card vendor typically
multi-sources the chip ... so even hard to know characteristics of any
particular card.

big part of the standard is the protocol handshake with the (7816,
contact) point-of-sale terminal to communicate what apps loaded on the
cards so that POS terminal can light-up the appropriate buttions.
another characteristic is that the card issuer has all the secret keys
... including the one controlling the card die command.

more in alt.technology.smartcards ng, from alt.technology.smartcards
FAQ

Europay, MasterCard and Visa formed working group to create their
Integrated Circuit Card Specifications for Payment Systems, commonly
called "EMV'96" or just "EMV"
www.mastercard.com/emv/emvspecs02.html
The specification was intended to create common technical basis to
compete with the Mondex specifications.

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

the above URL is not longer valid, try
http://www.mastercardintl.com/newtechnology/smartcards/tech1.html

Note that somewhat orthogonal to EMV specification is the x9.59
standard for all retail electronic payment transactions;
point-of-sale, internet, non-internet, debit, credit, atm, payment
cards, non-payment cards, stored-value; aka ALL.

x9.59 reference:
http://www.garlic.com/~lynn/x959.html#x959

authentication, hardware-tokens, ATM payments, etc:
http://www.garlic.com/~lynn/x959.html#aads

discussion of NACHA/debit-network (secure ATM payments) trials with
both software and hardware tokens:
http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

random stored-value discussions (as per above, much of mondex was
targeting stored-value transactions):
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
http://www.garlic.com/~lynn/aadsm9.htm#cfppki12 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#smallpay Small/Secure Payment Business Models
http://www.garlic.com/~lynn/aepay10.htm#10 InfoSpace Buys ECash Technologies
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#24 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#36 economic trade off in a pure reader system
http://www.garlic.com/~lynn/2002d.html#41 Why?

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

Deleting files and emails at Arthur Andersen and Enron

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Deleting files and emails at Arthur Andersen and Enron
Newsgroups: comp.arch.storage,alt.folklore.computers
Date: Mon, 18 Mar 2002 19:10:33 GMT

"Mike Swaim" writes:

Enron uses MS Exchange server as their email system. It usually runs on
dedicated hardware, with its own disks, so email would be a separate set of
tapes from the databases and fileservers. I have no idea what AA uses.

one issue is are they directly doing backups of the server to tape
... or do they have a backup server (mainframe or not) which copies
files over the lan and do backups from the backup server.

larger corporations ... are doing some amount of their regular data
backups over LANs to a centralized backup facility ... rather than
having to backup lots of individual servers (a medium sized corporate
site could easily have hundred plus servers in need of backups
... plus attempting to address some issues with regard to providing
backup services for thousands of desktop machines).

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

Deleting files and emails at Arthur Andersen and Enron

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Deleting files and emails at Arthur Andersen and Enron
Newsgroups: comp.arch.storage,alt.folklore.computers
Date: Mon, 18 Mar 2002 20:03:49 GMT

Anne & Lynn Wheeler writes:

one issue is are they directly doing backups of the server to tape
... or do they have a backup server (mainframe or not) which copies
files over the lan and do backups from the backup server.

random enterprise backup refs:
http://www.tivoli.com/products/solutions/storage/
http://portal2.legato.com/products/networker/
http://microsoft.net/ntserver/partners/findoffering/serversolutions/legatoexchange.asp
http://www.gartnerweb.com/public/axl/reprints/tivoli/00086113.html
http://www.peapod.co.uk/products/legato/index.html
http://mlarchive.ima.com/msexchange/1999/Jan/0558.html
http://www.networkcomputing.com/920/920r2.html
http://www.gmasterinc.com/security/brightstor.htm?source=overture
http://www.compaq.com/products/storageworks/ebs/ebsdatacenters.html

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

Smart Cards

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Smart Cards
Newsgroups: comp.security.misc
Date: Mon, 18 Mar 2002 20:45:01 GMT

phn writes:

The first application for smart cards ( satelite decoders) was broken
before the first year.  Latest generation of smartcards was broken
last summer by Shamir ( 'S' in RSA)

No, cards alone does not solve anything. Except maybe new limits in
marketing budgets.

there are a wide variety of chips used in hardware tokens ... with a
wide variety of protection available. many of the smartcards
multi-source their chips ... so for a particular smartcard, it might
even be difficult to tell what chip is inside.

some of the infrastructures are implemented with a common shared-secret
 ...  making it a lot more worthwhile to extract the shared-secret
from a single chip (possibly several weeks using multi-million
dollar equipment) ... which results in compromise of the whole
infrastructure.

other infrastructures have no common shared-secret and the PIN is only
used to enable the correct operation of some function ... but doesn't
result in divulging any sensitive information (significantly reducing
the possible ROI for tampering with a particular resistant chip).

besides the infrastructure security characteristics (i.e. do all
chips/tokens work with a common shared-secret, etc), things to look for
are evaluations, like FIPS140, Common Criteria, EAL, etc

a number of url refs:
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested

some fips140, common criteria, eal, etc
http://csrc.nist.gov/cc/sc/sclist.htm
http://csrc.ncsl.nist.gov/cryptval/140-1/1401val2000.htm
http://www.cl.cam.ac.uk/Research/Security/tamper/
http:/http://www.cl.cam.ac.uk/users/rja14/tamper.html
http://www.commoncriteria.org/epl/AssuranceLevel/index.html

random other refs:
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#24 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#25 the same question was asked in sci.crypt newgroup
http://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#14 EMV cards

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

Opinion on smartcard security requested

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Opinion  on smartcard security requested
Newsgroups: sci.crypt
Date: Tue, 19 Mar 2002 16:45:25 GMT

tabuelnaga@hotmail.com (Tarek) writes:

Dear all,

Frankly the Smart Card security concept is not clear for me. And i got
involved in it so i need some support.
Now, i know memory cards use PIN to read or write data on the card ..
But once the PIN is available the data is clear with no encryption.
While, smart cards plus having PIN, they use other encryption
algorithms like RSA 1024 or 3DES to encrypt data on the card. right ??

Now, i wana use card to store value with no processing - something
like telephone calls - and i want to choose betweem memory cards and
smart cards .. The price is critical issue u know .. but taking into
consideration, no compromises in security - here i got my problem ..
which one to choose !?

Anyone can tell me the difference in security between memory cards and
smart cards from security point of view ?? i see they both dependent
on the PIN .. if i have the PIN, i got the data .. in memory cards i
got the data clear .. while in smart cards i got them encrypted BUT i
have the encryption algorithm on the card so i can use it to decrypt
the data .. right ?? or there is something i miss ??

basically the HK transit (octopus card) is stored value memory
contactless card, no-pin, data encrypted. The terminals have the
shared-secret, the encrypted data is read by the terminal (as card is
passed over the reader going thru the turnstyle), decrypted, updated,
re-encrypted and rewritten. While passing thru the turn-style there
isn't enuf time for PIN entry (i think time constraints is that it all
has to happen within 100 ms with card within 10cm of reader).

with some simple asic ... it would be possible to make the chip
active/in-active w/o the correct pin ... and die if too many
consecutive incorrect PINs are entered.

it is possible to go to something like multi-app "smart-chip" ... say
like EMV and the stored value still works the same way ... PIN for
enabling actions, terminal read encrypted value, decrypt with
shared-secret, update, re-encrypt, write encrypted updated value back. The
"smart-chip" isn't so much for doing a specific application ... it is
for supporting multiple applications on the same chip, negotiating
with the terminal, telling it how many & what kind apps there are,
letting terminal specify/select the application (stored value,
loyalty, etc, ... aka the chip multi-app info allows terminal to
light/display specific buttons for application selection).

These stored-value chips/apps are subject to brute-force attack on the
encrypted value to recover the (system-wide shared-secret) key. One of
the security increments is "derived key" ... basically the terminal
reads chip data that is a combination of the account/serial number
plus the encrypted information. It computes a derived key that is a
combination of the system-wide secret key and the account/serial
number, the data is decrypted with the derived key, updated,
re-encrypted, rewritten. To derive the key ... use something like a
one-way hash ... brute-force attack that recovers any specific chip
derived key doesn't get the shared-secret key in all the terminals.
This works for stored-value implementations, memory/chip, pin/no-pin,
etc (it doesn't protect from an exploit that recovers the secret key
by a terminal attack ... but they could possibly be FIPS140 level 4
devices which are more resilient to attacks). Derived key stored-value
with "armored" terminals housing secret-key aren't uncommon.

Slight variation with chip is to make derived key a combination of the
sysetm-wide shared-secret key, the chip account number and the entered
PIN. The chip doesn't need the PIN-processing (whether memory or
smart, it is all in the terminal). This also works with "memory"
magnetic stripes. Progression to memory chip is partially 1) contact
vis-a-vis contactless in high-volume transit applications and 2) more
difficult to counterfeit card by just duplication (just copy a valid
magstripe onto a thousand cards, even memory chips can have engraved
serial numbers so more than simple information recording is required).

Fraudulent terminals can invalidate value by writing back bad data.

suggest looking for descriptions of mondex, EMV, stored-value, etc.

Above describes the offline transactions. There is some trends towards
online transactions (even in high volume transit, with time
limitations like 100ms). Here the chip just performs some
authentication operation on the transaction (like a digital
signature).

This can apply to any type of online transaction that is signed by the
chip. In this scenario things move into areas like 3-factor
authentication:

1) something you have (a hardware token)
2) something you know (a pin)
3) something you are (fingerprint, biometric)

hardware token can be configured so that it doesn't work correctly w/o
pin &/or fingerprint and the information doesn't need to be otherwise
divulged (a correct pin/fingerprint can be implied by correct hardware
token operation). other implementations require transmission of
pin/biometric ... effectively turning them into shared-secrets
(although not system-wide shared-secrets).

A transaction is passed to the chip, the chip can digital sign the
transaction and return the digital signature. The online server can
authenticate the transaction with the digital signature and then
authorise/execute to the corresponding transaction.

The digital signature case for online transactions is that the chip
has tamper-resistant techniques to protect the chip-specific private
key and a public key is recorded with the online server. this
eliminates the shared-secret exploit with secret/symmetric keys, aka
attacking the server ... possibly by an insider ... and recovering a
shared-secret it is possible to generate fraudulent
transactions. Also, since it is a chip-specific private key, a correct
digital signature implies possesion of the hardware token.

Receiving a digitally signed transaction from an appropriately configured
hardware token can imply 3-factor authentication ... aka

1) possesion of the token, something you have
2) knowledge of a pin, something you know
3) valid fingerprint, something you are

x9.59 standard is targeted at this for all payment transactions
(credit, debit, pos, internet, stored-value, atm, etc).
http://www.garlic.com/~lynn/x959.html#x959

misc. stored value refs:
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
http://www.garlic.com/~lynn/aadsm9.htm#cfppki12 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#smallpay Small/Secure Payment Business Models
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
http://www.garlic.com/~lynn/aepay10.htm#10 InfoSpace Buys ECash Technologies
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#24 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#36 economic trade off in a pure reader system
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#14 EMV cards

misc. shared-secret, biometrics, 3-factor authentication refs:
http://www.garlic.com/~lynn/aadsm10.htm#cfppki17 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio1 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio2 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio8 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy are not Antinomies
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm3.htm#cstech2 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech12 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#3dvulner 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
http://www.garlic.com/~lynn/aadsmore.htm#biosigs2 biometrics and electronic signatures
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/aepay10.htm#5 I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aepay10.htm#15 META Report: Smart Moves With Smart Cards
http://www.garlic.com/~lynn/aepay10.htm#20 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay3.htm#x959risk3 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
http://www.garlic.com/~lynn/aepay4.htm#comcert Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
http://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
http://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
http://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay8.htm#vulner account number & shared-secret vulnerabilities
http://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000.html#60 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
http://www.garlic.com/~lynn/2000b.html#90 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#7 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card numbers safely
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#49 Use of SET?
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#19 [Newbie] Authentication vs. Authorisation?
http://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#6 Is VeriSign lying???
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#58 I-net banking security
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
http://www.garlic.com/~lynn/2001n.html#94 Secret Key Infrastructure plug compatible with PKI
http://www.garlic.com/~lynn/2002.html#9 How to get 128-256 bit security only from a passphrase?
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#31 You think? TOM
http://www.garlic.com/~lynn/2002c.html#35 TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#17 Smart Cards
http://www.garlic.com/~lynn/99.html#157 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#166 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#168 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
http://www.garlic.com/~lynn/99.html#214 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI

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

What goes into a 3090?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What goes into a 3090?
Newsgroups: alt.folklore.computers
Date: Tue, 19 Mar 2002 17:20:28 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:

I guess that these 4361s were fairly small units?  The 3090 was big, but
it didn't seem quite big enough physically to contain a pair of mini-
equivalents as well as, I assume, the main memory, channel adaptors,
power supply, intercooler and God knows what else went in there!

I also assume that the two service processors didn't double up as FEPs?

about the size of small desk or file cabinet ... air-cooled.  big
things could have been any interface for bus&tag cables ... but
packaging for 3090 service processor wouldn't have needed that.

hardware & software was modified to have lots of probes all over the
3090 for fault detection, diagnostics, etc.

boxes were dedicated to service processor function.

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

What goes into a 3090?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What goes into a 3090?
Newsgroups: alt.folklore.computers
Date: Tue, 19 Mar 2002 17:48:19 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:

I've seen a few pictures (not as detailed as I'd have liked) of some
varieties of S/360s and early 370s, which seemed to have banks (of 9?)
TCMs plumbed together.  It took me quite a while to figure out what
they were...

TCMs were 3090 ... they weren't in 360s or 370s.
http://www-mae.engr.ucf.edu/~jtt/heat_transfer.htm
http://ref.cern.ch/CERN/CNL/2001/003/comp30/
http://www.cctec.com/maillists/nanog/historical/0

sorry, couldn't find a picture.

for some 360 & 370 pictures
http://www.cs.ncl.ac.uk/events/anniversaries/40th/webbook/photos/index.html

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

Crazy idea: has it been done?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Crazy idea: has it been done?
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 19 Mar 2002 18:10:59 GMT

"Stephen Fuld" writes:

Terje is right, of course, but scatter/gather is much more general than
that.  It has been used since the 1960s for almost any kind of I/O in
several mainframe lines.  And, in at least one of them, you could connect
one channel to another with a short cable and use the I/O hardware to
perform memory to memory copies, including gathering up various
address/length areas on the "write" side of the copy to a totally different
set of scatter address/length areas on the "read" side.

360 channel i/o since mid'60s strung together multiple channel
commands.  scatter/gather could be performed by either "command
chaining" (each chained operation had unique command, address, and
length) or just data chaining (first chained operation had command,
address, and length, subsequent data chained commands had just address
& length).

370 channel i/o introduced IDAL (indirect data address list) and
IDAWs. the issue was that in "command chaining" ... each channel
command was defined as synchronous ... the previous command had to be
complete before fetching the next command (this allowed for various
kinds of self-modifying i/o operations ... previous command could read
data that modified the subsequent command). This resulted in some
timing & overrun issues for higher speed devices. IDALs allowed
scatter/gather and a whole list could be prefetched minimizing some of
the timing/overrun issues.

on the i/o side it was contiguous sequential flow of data
... operation of IDALs and data chaining (except some timing issues)
for scatter/gather were transparent.

Besides application use of scatter/gather ... a big use of
scatter/gather involved large data transfers in virtual memory
environment ... where the application running in virtual memory might
think it was one contiguous transfer ... but the individual virtual
pages are randomly distributed in real memory (and the system i/o runs
with real addresses). The kernel may have to translate a contiguous
i/o requests into multi-part scatter/gather requests crossing one or
more virtual page boundaries (located at non-sequential &
non-contiguous real page locations).

random ref:
http://www.garlic.com/~lynn/2002d.html#52 Hardest Mistake in Comp Arch to Fix

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

Opinion on smartcard security requested

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Opinion  on smartcard security requested
Newsgroups: sci.crypt
Date: Tue, 19 Mar 2002 23:17:19 GMT

tabuelnaga@hotmail.com (Tarek) writes:

okayyy .. here some info that may clarify the situation ..
i'm thinking to make a pre-paid cards .. these cards will store money
as points .. u should guess that :))
now, these cards will be used to buy goods from shops with POS's ..
sure if i used smart cards the cost of cards will be very high .. so
i'm thinking to use memory cards .. but i'm not sure if this is a
secure solution or not .. i may be not that lucky guy and i find my
cards reloaded again in the shops illegaly or in other words someone
will get my card .. read the data and knows how i save my data .. then
make similar cards ..

you find (online) magstripe prepaid/stored-value cards all over the
place. they work with the same magstripe terminal used for debit &
credit.

I was at grocery store yesterday ... besides grocery store
prepaid/stored-value magstripe cards ... there was cards for possibly
half-dozen other places all lined up on j-hooks at each check out
counter.

random prepaid/stored value magstripe refs:
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002d.html#41 Why?

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

Opinion on smartcard security requested

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Opinion  on smartcard security requested
Newsgroups: sci.crypt
Date: Wed, 20 Mar 2002 00:03:24 GMT

Paul Rubin <phr-n2002a@nightsong.com> writes:

European public phones use memory cards and they suffer from massive
amounts of fraud.  Fortunately, their profits on non-fraudulent calls
are high enough that they survive the fraud.  If you use memory cards
you have to decide whether you can survive fraud too.  If you use
smart cards, you'll still have some fraud, but maybe not as much.

note that there are different failure modes with respect to offline
point-of-sale stored value and online point-of-sale stored value.

one of the reasons for the EMV card kill command (i.e. know the super
shared-secret and be able to send the card die command) is because of
possible compromise related to offline operation ... and so the
fallback plan to kill the card at the first chance).

cloning a valid offline stored-value card ... where the card might
have a valid $100 ... means that that a single valid $100 could turn
into tens of thousands of copies of $100. Cloning an online
stored-value card doesn't get more than the original $100 (no matter
how many copies are made).

It is sort of the difference between counterfeiting $100 bills or
counterfeiting an authentication token that enables access to an
account that has a total of $100.

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

Back to the H20Cooler

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Back to the H20Cooler
Newsgroups: earthlink.watercooler
Date: Wed, 20 Mar 2002 05:05:04 GMT

"rowe" writes:

What? BTW...into garlic? We have a shop here in town called Racambole and
she's got some great stuff!! You site must be some kind of code? Any hot
sauce?--jonathan

earthlink bought netcom ... and i lost my shell account.  netcom.com
use to be in bldg corner of winchester & i280 ... but moved downtown when
they got larger.

garlic.com is south valley internet .. maybe 25 miles south of where
netcom bldg. was downtown, san martin ... about halfway between morgan
hill and gilroy. If you buy garlic ... most of it will be from
someplace around gilroy (garlic capital of the world). A lot of
mushroom comes from mushroom farms around morgan hill. A lot of
strawberries, artichokes, avocados, etc come from watsonville ...
just over hecker pass to the west.

in the morning the wind blows up valley because the bay is warmer than
south valley land. you walk out of the house many mornings and the
smell of garlic immediately hits you in the face (even 20-30 miles
north of the fields).

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

Crazy idea: has it been done?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Crazy idea: has it been done?
Newsgroups: alt.folklore.computers
Date: Wed, 20 Mar 2002 14:10:28 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:

Huh?  There were two methods of VM communication twixt CMS sessions,
(massive brain fart here), but I don't recall CTC being involved.

there were "virtual" CTCs supported by VM ... in addition to real
CTCs, i.e. VM would emulate virtual CTC between two virtual machines
on the same real CEC (not needing real CTC hardware) ... not very
often virtual machines running CMS ... but more often between multiple
virtual machines running various flavors of OS ... typically with ASP
& HASP ... which morphed into JES3 & JES2.

enhancement to real CTC was trotter/3088 ... which was an 8-armed CTC
with switch in the middle. one of my wife's battles when she was in
charge of "loosely-coupled" architecture (aka cluster) ... was getting
enhanced I/O function into trotter. regular CTC required a lot of
chatter for initiation of each I/O ... point was to simplify a lot of
that with trotter ... in effect give it more of HYPERChannel flavor
than the old fashioned CTC handshaking chatter.

VM also supported virtual unit record ... with output of one virtual
machine's "punch" appearing in the "reader" of another virtual
machine. This is the original email implementation from the mid-60s
(first between virtual machines on the same processor and then VNET
extending that to networked environment).  "SMSG" & "IUCV" were
introduced as another method for virtual machine to virtual machine
communication in the mid-70s.

these days you have LPARS and the whole parallel sysplex
interprocessor coordination stuff.

misc. trotter/3088/smsg/iucv
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#37 OT?
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
http://www.garlic.com/~lynn/2001j.html#26 Help needed on conversion from VM to OS390

misc. hyperchannel
http://www.garlic.com/~lynn/subtopic.html#hsdt

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

Crazy idea: has it been done?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Crazy idea: has it been done?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 20 Mar 2002 14:52:11 GMT

jmfbahciv writes:

In TOPS-10, nothing had to be moved.  All the monitor did was
change the first user's page map page (remove the memory chunk)
and modify the receiver's user page map page (add the memory
chunck).

the issue in VM was 1) supporting the real hardware (even if a real
CTC went out of one virtual machine and back into a different virtual
machine on the same real processor) or 2) emulating the real hardware
(no real CTC, but the emulation of virtual CTC between two virtual
machines on the same real processor).

some customers had virtual tape support ... where real tape drive
might be on some other machine and the I/O commands & data forwarded
thru some network interface ... possibly flowing over a real CTC.

VM was frequently in a real quandary ... trying to preserve the look
and feel of "real" machine (at the virtual machine interface) with
lots of people believing that VM was a traditional operating system
and the kernel should be supporting higher level application services.
The real-machine-emulation forces trying to keep the cp "micro-kernel"
down to under 100k bytes ... and the traditional operating system
forces trying to balloon the kernel to megabyte or more. It was always
easier to drop some Q&D application support into a compact, simple
micro-kernel ... than it was to come up with a "hardware" emulation
architected paradigm. The problem was that after many years of the Q&D
application level support stuff ... you no longer had a compact,
simple (KISS) micro-kernel (aka simple is frequently much harder than
Q&D).

I did do a page-mapped interface semantics in the early '70s for data
transfer ... both for disk support and various other things. This was
well before extended store on the 3090 and (official) machine
instructions for moving pages around.

A variation of page-mapping tricks was also done for System/R
implementation (aka the original relational database was done on VM at
SJR ...  now ARC).

misc. page-mapped refs:
http://www.garlic.com/~lynn/2000.html#75 Mainframe operating systems
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)

misc. extended store:
http://www.garlic.com/~lynn/95.html#15 multilevel store
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than   It Can Chew?)

misc. system/r
http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?
http://www.garlic.com/~lynn/2001d.html#44 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2002.html#10 index searching

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

moving on

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From:    Anne & Lynn Wheeler <lynn@garlic.com>
Newsgroups: bit.listserv.vmesa-l
Date:    Tue, 19 Mar 2002 11:47:34 -0700
Subject: moving on

some ancient history

lyn hadley ph682prs@nepca ,,,

nepca ... was new england programming center (machine) "A" (there was also
NEPCB).

the cp67/vm370 group outgrew the space on 3rd floor, 545 technology sq. and
moved out to the old SBC building in burlington mall (ibm had spun off
service bureau corporation to control data).

POK needed the vm group in the mid-70s for developing and supporting the
VMTOOL. this was internal use only XA-mode version of VM that was targeted
solely for the support of MVS/XA development. POK closed the new england
programming center and moved it all to POK. Even with the closing of
burlington mall, the "NEPCA" node (and ph682prs userid) sruvived well into
the '80s.

By 1985, the vm group had moved to kingston ... and ph682prs@nepca had
become ph68prs@kgnvmc.

At 19:31 est, 18 mar 2002,  alan ackerman wrote:

Lyn Hadley, "Sir Lyn the Fixer", one of the Knights of VM, is retiring
at the end of this month.

I thought those of you who have been around for awhile might like to
know. I shall certainly miss him!

With his permission, I'm forwarding this note he sent to the VM team
here at Bank of America:

------------------------------------------------------------------------
From: Lyn Hadley (SMTP:sirlyn@us.ibm.com)
Subject: Time to say 'Good-bye'
Over the next few days I am cleaning up and turning over my work to others
here at IBM as I make the transition to retirement the end of this month.
I wanted to take the opportunity to say 'Good-bye' to my friends at Bank of
America who have kept me so gainfully employed for the past several
years.    I shall indeed miss my interactions with customers like you.  I
hope IBM will continue to provide you with the products and service
solutions that will meet your needs for a long time.

I have enjoyed my years of working with customers on VM.  It was 30 years
ago this year that I first saw VM and began to learn the idiosyncrasies of
the virtual machine world.

I wish you the best as you continue to use IBM products and services.

A friend,
Lyn Hadley

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

moving on (typo)

Newsgroups: bit.listserv.vmesa-l
Date:    Tue, 19 Mar 2002 11:53:53 -0700
From:    Anne & Lynn Wheeler <lynn@garlic.com>
Subject: moving on (typo)

some ancient history (typo)

lyn hadley ph68sprs@nepca ,,,
...
By 1985, the vm group had moved to kingston ... and ph68sprs@nepca had
become ph68sprs@kgnvmc.

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

Crazy idea: has it been done?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Crazy idea: has it been done?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 20 Mar 2002 15:48:18 GMT

Anne & Lynn Wheeler writes:

micro-kernel ... than it was to come up with a "hardware" emulation
architected paradigm. The problem was that after many years of the Q&D
application level support stuff ... you no longer had a compact,
simple (KISS) micro-kernel (aka simple is frequently much harder than
Q&D).

misc. past kiss refs:
http://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#16 Verisign and Microsoft - oops
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001d.html#46 anyone have digital certificates sample code
http://www.garlic.com/~lynn/2001e.html#26 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001l.html#1 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001l.html#3 SUNW at $8 good buy?
http://www.garlic.com/~lynn/2002b.html#22 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002b.html#59 Computer Naming Conventions
http://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#35 TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
http://www.garlic.com/~lynn/2002d.html#0 VAX, M68K complex instructions (was Re: Did Intel Bite Off  MoreThan  It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc

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

Progress? (was Re: Way up north in Alaska ...)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Progress? (was Re: Way up north in Alaska ...)
Newsgroups: alt.folklore.computers
Date: Wed, 20 Mar 2002 23:00:27 GMT

lawrence@c896388-c.attbi.com (Lawrence Statton N1GAK) writes:

So the claim in the suit was prima facae false, in that in any packet
of tickets there were SOME winners.  However, CSL, caved immediately,
and has recently offered some settlement to "The People of
California".  You can check out their web-site at
http://www.calottery.com/ for more details.

the other issue is that even after the prizes are awarded ... they are
declared as income ... and both the state & federal gets an
"additional take" in income taxes ... over & above what the state got
directly in the lottory process. For the big prizes ... that is
approaching 50 percent (top federal bracket plus top state bracket).

One number that doesn't show up is what percent of the prizes actually
awarded ... do the state & federal gov recoup additionally in the form
of income taxes (aka there is the direct contribution that lotteries
make to state coffers ... but also the indirect contribution that
lotteries make to both the state & federal coffers because of taxes on
the prizes).

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

Hardest Mistake in Comp Arch to Fix

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hardest Mistake in Comp Arch to Fix
Newsgroups: comp.arch,alt.folklore.computers,comp.sys.unisys
Date: Thu, 21 Mar 2002 17:06:49 GMT

adi@pirx.hexapodia.org (Andy Isaacson) writes:

As an email also pointed out, you're correct -- the FPS/CRI team
responsible for the e10k was in San Diego, not Oregon.  (Did FPS also
have offices in Oregon?)

earlier FPS systems were from oregon

random refs:
http://www.garlic.com/~lynn/2000c.html#5 TF-1
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002.html#0 index searching

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

What goes into a 3090?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What goes into a 3090?
Newsgroups: alt.folklore.computers
Date: Thu, 21 Mar 2002 20:22:55 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:

No, not a trick question!  I was thinking back to when I was
given a tour of the main computer room at a place I used to
work, and two large lumps at the side of the room were
identified to me as a pair of 3090 systems.  Both were pretty
much the same, large slabs with alternating blue metal panels
and grey ribbed plastic ones, IIRC.  I don't want to guess at

a couple other things that went into 3090 (that have been subject of
some threads here & comp.arch) were vector facility and extended
store.

extended store was a cross between memory and electronic disk. It was
getting around the 31bit (2gigabyte) addressing limit on 3090 (i.e.
couldn't address more than 2gigabytes of real storage). There was also
a case made that the bus for extended store could be made wider with
longer latency (i.e. memory positioned longer distance from the cpu)
than standard memory).

the advantage over real electronic disk was that it had a synchronous
page move instruction that was on the order of tens of processor
cycles ... orders of magnitude less than the pathlength to perform a
disk I/O operation.

The extended store bus was also where they attached HiPPI connection
(because the regular I/O iterface couldn't handle the HiPPI data
rate). The HiPPI programming model then looked somewhat more like some
of the PC operations than mainframe I/O channel programming. Basically
there were reserved extended store addresses where data was stuff that
controlled HiPPI i/o operations. The extended store synchronous page
move instructions were used to move the control information to those
reserved addresses for controlling HiPPI i/o.

another 3090 feature was vector facility.

not so much 3090 but in that era was ESCON. ESCON had been floating
around the company since the '70s but was having hard time getting
out. Engineers in the 6000 group took the escon specs and effectively
tweacked them ... getting about 10 percent higher thruput, full-duplex
operation and using much cheaper optical components (rather than much
higher priced escon driver/receivers ... basically stuff adapted from
the cdrom industry) and it was called SLA (serial link adapter). There
was then a several month period deciding whether to work on driving
SLA to gigabit or merge the work into fiber-channel standards work.

Eventually the decision was made to follow the fiber-channel standard
path and the engineer largely responsible for SLA eventually became
the editor/owner of the standards document (in the fiberchannel
standards group). There was some amount of heat generated in the
fiber-channel standards group (from some of the escon & other forces)
trying to (force?) fit the (mainframe) half-duplex device i/o paradigm
on top of the fiber-channel dual simplex (full duplex simulation with
dedicated channels for transmission in each direction) protocol.

some random extended store & vf refs:
http://www.garlic.com/~lynn/95.html#15 multilevel store
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001m.html#53 TSS/360
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than   It Can Chew?)
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?

random sla, fcs, ficon, escon refs:
http://www.garlic.com/~lynn/94.html#16 Dual-ported disks?
http://www.garlic.com/~lynn/94.html#17 Dual-ported disks?
http://www.garlic.com/~lynn/95.html#13 SSA
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/96.html#26 System/360 Model 30
http://www.garlic.com/~lynn/97.html#5 360/44 (was Re: IBM 1130 (was Re: IBM 7090--used for business or
http://www.garlic.com/~lynn/98.html#30 Drive letters
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/99.html#125 Q: S/390 on PowerPC?
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000c.html#22 Cache coherence [was Re: TF-1]
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#14 FW: RS6000 vs IBM Mainframe
http://www.garlic.com/~lynn/2000f.html#31 OT?
http://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
http://www.garlic.com/~lynn/2001.html#12 Small IBM shops
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#46 Small IBM shops
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#42 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2001e.html#22 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#22 ESCON Channel Limits
http://www.garlic.com/~lynn/2001l.html#14 mainframe question
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001m.html#56 Contiguous file system
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002.html#28 Buffer overflow
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#5 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#7 Bus & Tag, possible length/distance?
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#31 Hardest Mistake in Comp Arch to Fix

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

Mainframers: Take back the light (spotlight, that is)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Thu, 21 Mar 2002 22:47:28 GMT

Kragen Sitaker writes:

Speeding up searching your linked lists by a large constant factor by
having an index of starting points is one thing.  Speeding it up to
the point that it has the same asymptotic complexity as a binary-tree
search, but without the worst-case performance and about the same
constant factor, is something else entirely.  And that's what skip
lists do.

we did something slightly related ... but different for online phone
books in the late '70s. We had sorted (phone book) file of all records
and rather than a binary search we went thru three phased
implementation.

The first phase ... which didn't make it to deployment was a straight
radix search ... instead of binary search ... use the first letter of
the name (26 letters) to select approx. place in file to start
search. For actual deployment, the 2nd phase was to use a weighted
radix search ... having calculated the weighted distribution of
occurance of each letter as the first letter of last names. There was
also some calculation that attempted to estimate amount of error after
each probe and use that as part of calculating next record ro probe.

The 3rd phase was as the online phone books got larger and larger, the
record of the first occurance of each letter (first letter in last
name) was recorded for each phone book file. The weighted radix search
started knowing the first and last record that had last name starting
with specific letter.

The weighted (with letter frequency distribution) radix had maybe
1/3rd the probes to find a match (compared to straight binary search).
Explicitly recording the range of records for each first letter might
get another 20 percent off the 1/3rd (maybe 1/4th compared to binary
search).

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

Lisp Chips

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Chips
Newsgroups: comp.arch
Date: Fri, 22 Mar 2002 21:14:33 GMT

Peter Boyle writes:

Now do it in 512byte packets and you need 1.5GB/s of sustained
context switch traffic, while on a RISC it would be 1/4 this, and
still less on x86.

Of course you can do better by queueing/dequeueing multiple MTU's
at a time in the driver, make judicious use of polling, etc... but I think
there is clearly a potential problem ... then start hosting multiple
links.

You mean 'tcp/ip connections with a small MTU'? Like say dial-up users?

Hadn't thought of dialup, but I would guess so if sufficiently heavily
loaded.

there was gigabit router presentation at aug-88(?) ietf ... tcp/ip
traffic was heavily bimodel ... lots of max. MTU packets (1500) and
lots of minimum sized packets (setup, ACKs, misc. other stuff; http1.0
aggravated this)) ... making the avg. a couple hundred (althouhg
setup/teardown & ACKs shouldn't be perculating all the way up the
protocol stack).

work had been done on no-buffer copy, dedicated function 100
instruction packet handler in order for a 50mip processor to support
gigabit router function.

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

Replacement for RFC 1700?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Replacement for RFC 1700?
Newsgroups: comp.security.misc
Date: Sun, 24 Mar 2002 15:29:44 GMT

"Felix Tilley" writes:

RFC 1700 is out of date.  Is it going to be revised?  Is it going to be
replaced?  Is there already a replacement?  if so, where?

see rfc3232

3232 I
Assigned Numbers: RFC 1700 is Replaced by an On-line Database,
Reynolds J., 2002/01/24 (3pp) (.txt=3849) (Obsoletes 1700) (was
draft-rfc-editor-rfc1700bis-00.txt)

reference
http://www.garlic.com/~lynn/rfcietff.htm

and click on RFCs that are slso " Standards (STD)"

and click on STD-2 "1700" (Stan) - ASSIGNED NUMBERS

1700 -S
ASSIGNED NUMBERS, Postel J., Reynolds J., 1994/10/20 (230pp)
(.txt=458860) (STD-2) (Obsoleted by 3232) (Obsoletes 1340)

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

http://www.iana.org/
http://www.iana.org/numbers.html

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

Crypting with Fingerprints ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Crypting with Fingerprints ?
Newsgroups: sci.crypt
Date: Sun, 24 Mar 2002 16:17:46 GMT

"Softman" writes:

It's true that the information is "static". How do you change you password
with biometrics?:) Do not suggest cutting something off. Or do you need to
wear some rubber fingers as keys? How do you make another password? What if
you need two passwords for different applications? Two signatures? Imaging
someone stealing your biometrics data from the golf club and accessing some
secure enviroments with it? Or simpler, "just press here sir" in a super
market?!!

biometrics can be straight shared-secret .... i.e. in the same manner that
passwords are shared-secret.

also the environment that a biometric sensor is implemented can either
be some random, insecure location .... or it can be a secure sensor
that always has a armed guard present (degree that fraudulent or
counterfiet information can be injected).

the x9.84 biometric standard has a big