List of Archived Posts

2006 Newsgroup Postings (03/22 - 04/15)

using 3390 mod-9s

using 3390 mod-9s

using 3390 mod-9s

using 3390 mod-9s

using 3390 mod-9s

3380-3390 Conversion - DISAPPOINTMENT

64-bit architectures & 32-bit instructions

The Pankian Metaphor

Wonder why IBM code quality is suffering?

The Pankian Metaphor

The Pankian Metaphor

Anyone remember Mohawk Data Science ?

Barbaras (mini-)rant

Barbaras (mini-)rant

The Pankian Metaphor

trusted certificates and trusted repositories

trusted repositories and trusted transactions

trusted certificates and trusted repositories

how much swap size did you take?

Over my head in a JES exit

Old PCs--environmental hazard

Over my head in a JES exit

A very basic question

Old PCs--environmental hazard

Over my head in a JES exit

Over my head in a JES exit

Old PCs--environmental hazard

Old PCs--environmental hazard

Old PCs--environmental hazard

X.509 and ssh

A very basic question

X.509 and ssh

X.509 and ssh

X.509 and ssh

X.509 and ssh

X.509 and ssh

X.509 and ssh

Over my head in a JES exit

Over my head in a JES exit

X.509 and ssh

A very basic question

The Pankian Metaphor

The Pankian Metaphor

The Pankian Metaphor

The Pankian Metaphor

using 3390 mod-9s

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: using 3390 mod-9s
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 22 Mar 2006 11:44:01 -0700

ref:
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s

part of the caching/electronic store discussions that on in the 70s had
to do with global LRU and global caches vis-a-vis local LRU and
partitioning.

as an undergraduate in the 60s, i had also done the global LRU stuff for
cp67
http://www.garlic.com/~lynn/subtopic.html#wsclock

about the same time, there was some work published in the literature
about working sets and local LRU strategies.

in the early 70s, there was an effort by the grenoble science center to
implement local LRU strategy for cp67 as per the academic literature.
The cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

was running cp67 on 360/67 with 768k of real memory (104 pageable pages
after fixed storage requirements) and my global LRU implementation.
grenoble had a 360/67 with 1mbyte of real memory (155 pageable pages
after fixed storage requirements). Cambridge with global LRU and 104
pageable pages basically supported about twice as many users (75-80) at
the same performance and response as Grenoble support with local LRU and
155 pageable pages with 30-35 users.

in the late 70s about the time the disk activity project was gathering
extensive filesystem/disk record access traces, which was then being
used for various analysis ... including a cache simulator looking at
various kinds of device, controller, channel, subsystem, and system
caching strategies. except for some specific scenarios (device-level
full-track buffer as compensation for rotational synchronization and
things like RPS-miss) ... the modeling found that for any given, fixed
amount of electronic storage (and all other things being equal), a
single "system level" cache implementation always out-performed any
cache partitioning strategy (i.e. some part of the electronic storage
partitioned into device, controller, channel, etc caches).

About the same time (late 70s) there was a big fuss being made over a
stanford phd effort that was basically covering the stuff that I had
done as an undergraduate in the 60s. This stanford phd thesis was doing
global LRU ... and some of the people that had been indoctrinated by the
local LRU papers in the academic literature were objecting to the Phd
being awarded (since global LRU conflicted with their LRU beliefs).

I was somewhat able to contribute to resolving the disagreement since
Grenoble had published ACM article on their local LRU effort (in the
early 70s) ... and I had hardcopy of some of their supporting
performance data ... as well as similar data from Cambridge system doing
local LRU (for apples to apples comparison of the two strategies running
same system, same hardware, and similar workload).

in any case there is direct correspondence between the partitioning
that occurs in local LRU cache strategies and the physical partitioning
that occurs in device and/or controller level caches.

a couple posts that reference the lru/clock thesis and related controversy
http://www.garlic.com/~lynn/93.html#4 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/2001c.html#10 Memory management - Page replacement
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names

misc. other posts mentiong the lru/clock countroversy
http://www.garlic.com/~lynn/98.html#2 CP-67 (was IBM 360 DOS (was Is Win95 without DOS...))
http://www.garlic.com/~lynn/99.html#18 Old Computers
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2002c.html#16 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002k.html#63 OT (sort-of) - Does it take math skills to do data processing ?
http://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#55 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#0 Alpha performance, why?
http://www.garlic.com/~lynn/2003k.html#8 z VM 4.3
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2004.html#25 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004b.html#47 new to mainframe asm
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005n.html#23 Code density and performance?
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006b.html#35 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer

using 3390 mod-9s

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: using 3390 mod-9s
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 22 Mar 2006 18:29:35 -0700

Joe Morris writes:

By any chance were you the author (or inspiration) for the articles
about dataset and PDS member placement that were published in the
Installation Newsletter?  (And is my memory correct that the article
was in the white-paper part of the INL which wasn't supposed to be
seen by mere customers?)

ref:
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s

i was an undergraduate working for the univ. at the time that i was
doing the os/360 and cp67 work. I don't remember paying any attention
to ibm documents on the subject in that time-frame.

the later event was when the disk division got upset about my
characterizing disk relative system thruput had declined by a factor
of ten times and instructed the division performance group to refute
the statement. they eventually came out and said i had slightly
understated the situation.

specific reference in previus post
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)

the study was eventually turned into a presentation by the
disk division delivered to Guide and Share user group meetings
in the '84 time-frame (some extracts from the presentation)
http://www.garlic.com/~lynn/2001l.html#46 MVS History (all parts)

I didn't pay a whole lot of attention to where else it may have
been published.

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

using 3390 mod-9s

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: using 3390 mod-9s
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 22 Mar 2006 18:45:36 -0700

Brian Inglis writes:

The CMS approach of keeping the active disk and file tables in local
VM memory seemed to keep response times way down for file ops.
Using shared segs for fairly static disk directories: S, Y, P, and L
(local) helped by moving more I/O from the filesystem to paging.
Used to just EXECIO * DISKR files onto the program stack or later into
REXX arrays/stem variables, unless they were very large.

ref:
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s

I had done a lot of virtual memory (internal) enhancements on cp/67
and moved them over to vm/370 (again internal). some of those
enhancements were eventually picked up and shipped in the product
... like a small subset of the stuff around what they called DCSS. It
did also included a "paged mapped" filesystem infrastructure for CMS
... which would have greatly enhanced the sharing and caching of CMS
information.  misc. collected posts discussion page mapped stuff
http://www.garlic.com/~lynn/subtopic.html#mmap

the pagged map transition apparently was to great of a paradigm change
(although I had done quite a bit of work on providing compatible
semantics for existing operation) ... and never shipped. given the
full page mapped semantics, sharing and caching of all cms stuff
becomes trivially straight-forward.

CMS was otherwise a significantly file intensive infrastructure
(especially by pc standards) which was only partially mitigated by
things like placing small amounts of high-use CMS stuff in (DCSS)
shared segments.

This became extremely painfully apparent with XT/370 ... in was single
user operation in ibm/pc frame with all vm and cms stuff mapped to
standard ibm/xt 110ms (access) disks. None of the sharing stuff held
any benefit ... since you were the only one on the system (and the
available storage was also painfully limited by mainframe standards).

some past discussion of xt/370
http://www.garlic.com/~lynn/94.html#42 bloat
http://www.garlic.com/~lynn/96.html#23 Old IBM's
http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001c.html#89 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001f.html#28 IBM's "VM for the PC" c.1984??
http://www.garlic.com/~lynn/2001i.html#19 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001k.html#24 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2003f.html#8 Alpha performance, why?
http://www.garlic.com/~lynn/2003h.html#40 IBM system 370
http://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
http://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#13 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2005f.html#6 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1

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

using 3390 mod-9s

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: using 3390 mod-9s
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 23 Mar 2006 12:18:47 -0700

Anne & Lynn Wheeler wrote:

the study was eventually turned into a presentation by the
disk division delivered to Guide and Share user group meetings
in the '84 time-frame (some extracts from the presentation)
http://www.garlic.com/~lynn/2001l.html#46 MVS History (all parts)

the above is an old posting of the preface to the share presentation.
the title page for that share presentation is

SHARE 63 Presentation B874

DASD Performance Review
8:30 August 16, 1984
Dr. Peter Lazarus

IBM Tie Line 543-3811
Area Code 408-463-3811
GPD Performance Evaluation
Department D18
Santa Teresa Laboratory
555 Bailey Avenue
San Jose, CA., 95150

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

for a little more drift, STL had told me that even if i provided them
with fully tested and integrated FBA support for MVS ... that it would
still cost $26m to ship ... and I didn't have an ROI business case for
that $26m (i.e. it would just sell the same amount of FBA disk in
place of CKD disk ... so no really new revenue).

The transition to FBA would have (at least) converted the I/O
extravagant multi-track search paradigm for VTOC and PDS directories
to data structures that were loaded (and cached) in memory for
search/lookup. The multi-track search paradigm from the mid-60s that
represented a trade-off in relatively abundant I/O resources for
relatively scarce real storage resources ... was no longer valid even
ten years later.

OS/360 did get partial mitigation for the effects of multi-track
search (and loading) with RAM and BLDL lists.

past postings in this thread:
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#1 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s

misc. past posts about STL quoting $26m additional to ship MVS FBA
support (even after for already fully integrated and tested).
http://www.garlic.com/~lynn/97.html#16 Why Mainframes?
http://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe  background
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
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/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001g.html#32 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003c.html#48 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2004d.html#65 System/360 40 years old today
http://www.garlic.com/~lynn/2004g.html#15 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004l.html#20 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004l.html#23 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2005c.html#64 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2005m.html#40 capacity of largest drive
http://www.garlic.com/~lynn/2005u.html#21 3390-81

using 3390 mod-9s

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: using 3390 mod-9s
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 24 Mar 2006 08:45:08 -0700

Anne & Lynn Wheeler wrote:

for a little more drift, STL had told me that even if i provided them
with fully tested and integrated FBA support for MVS ... that it would
still cost $26m to ship ... and I didn't have an ROI business case for
that $26m (i.e. it would just sell the same amount of FBA disk in place
of CKD disk ... so no really new revenue).

The transition to FBA would have (at least) converted the I/O
extravagant multi-track search paradigm for VTOC and PDS directories to
data structures that were loaded (and cached) in memory for
search/lookup. The multi-track search paradigm from the mid-60s that
represented a trade-off in relatively abundant I/O resources for
relatively scarce real storage resources ... was no longer valid even
ten years later.

ref:
http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s

while I couldn't prove that adding FBA support to MVS would sell more
DASD ... I did try and make the case that eliminating CKD and
migrating to FBA would eliminate enormous amounts of infrastructure
costs over the years ... like all the ongoing infrastructure gorp
related to track lengths (aside from the issue of eliminating the
enormous performance degradation resulting in continuing to carry the
multi-track search paradigm down thru the ages).

3380-3390 Conversion - DISAPPOINTMENT

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT
Date: Sun, 26 Mar 2006 08:33:21 -0700
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers, bit.listserv.vmesa-l

DASDBill2 wrote:

I once wrote a deblocker program to read in 640K tape blocks and
break them up into QSAM-friendly chunks of 32,760 bytes or less.  It
was an interesting exercise, made even more so by having to run it
on MVS under VM, which caused a lot of unrepeatable chaining check
errors due to the very long channel program to read in 640K in one
I/O request.

cp/67 on 360/67 had to translate ccws from the virtual machine ... and
use data-chaining where the virtual machine CCW virtual data address
was contiguous ... but the virtual pages from the virtual machine were
scattered around (real) memory.

moving to 370, IDALs were provided in lieu of data-chaining to break
up virtual contiguous areas into non-contiguous pages. part of this is
that the standard channel architecture precluded pre-fetching CCWs
(they had to be fetched and executed synchronously). on 360, breaking a
single ccw into multiple (data-chaining) CCWs introduced additional
latencies that could result in timing errors. on 370, non-contiguous
areas could be handled with IDALs ... and channel architecture allowed
prefetching of IDALs ... supposedly eliminating the timing latencies
associated that could happen with data-chaining approach.

This issue of channels working with real addresses necessitating that
CCWs built with virtual address ... to be translated to a shadow set
of CCWs with real addresses ... affects all systems operating with
virtual memory (which support applications building CCWs with virtual
memory addresses ... where the virtual address space area may appear
linear ... but the corresponding virtual pages are actually
non-contiguous in real memory).

The original implementation of os/vs2 was built using standard MVT
with virtual address space tables and page interrupt handler hacked
into the side (for os/vs2 svs ... precursor to os/vs2 mvs ... since
shorten to just mvs). It also borrowed CCWTRANS from cp/67 to
translate the application CCWs (that had been built with virtual
addresses) into "real" CCWs that were built with real addresses for
real execution.

This version of CCWTRANS had support for IDALs for running on 370s.

Typically, once MVS had shadowed the application CCWs ... creating the
shadow CCWs with IDALs giving the non-contiguous page addresses ...
then any VM translation of the MVS translated CCWs was strictly
one-for-one replacement ... an exact copy of the MVS set of translated
CCWs ... which only differed in the real, real address spacified.

all the virtual machine stuff and cp67 had been developed by the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

there was a joint project between cambridge and endicott to simulate
virtual 370s under cp67 running on real 360/67 (for one thing the 370
virtual memory tables had somewhat different hardware definition, the
control register definitions were somewhat different, there some
different instructions, etc).

the base production system at cambridge was referred to as cp67l. the
modifications to cp67 to provide 370 virtual machines (as an
alternative option to providing 360 virtual machines) was referred to
as cp67h. Then further modifications were made to cp67 for the kernel
to run on real 370 (using 370 hardware definitions instead of 360
hardware definitions).  This cp67 kernel that ran "on" 370 hardware
was referred to as cp67i. cp67i was running regularly in production
virtual machine a year prior to the first engineering 370 model with
virtual memory hardware became available (in fact, cp67i was used as a
validation test for the machine when it first became operational).

cms multi-level source update management was developed in support of
cp67l/cp67h/cp67i set of updates.

also, the cp67h system ... which could run on a real 360/67, providing
virtual 370 machines ... was actually typically run in a virtual
360/67 virtual machine ... under cp67l on the cambridge 360/67. This
was in large part because of security concerns since the cambridge
system provided some amount of generalized time-sharing to various
univ. people & students in the cambridge area (mit, harvard, bu,
etc). If cp67h was hosted as the base timesharing service ... there
were all sorts of people that might trip over the unannounced 370
virtual memory operation.

about the time some 370s (145) processors (with virtual memory) became
available internally (still long before announcement of virtual memory
for 370), a couple engineers came out from san jose and added the
device support for 3330s and 2505s to the cp67i system (including
multi-exposure support, set sector in support of rps). also idal
support was crafted into CCWTRANs. part of the issue was that the
channels on real 360/67s were a lot faster and had lot lower latency
... so there were much fewer instances where breaking a single CCW
into multiple data-chained CCWs resulted in overruns.  However, 145
channel processing was much slower and required (prefetch'able) IDALs
to avoid a lot of the overrun situations.

a few past posts mentioning cp67l, cp67h, and cp67i activity:
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches

misc. past posts mentioning cp/67 CCWTRAN
http://www.garlic.com/~lynn/2000.html#68 Mainframe operating systems
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory
http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's
http://www.garlic.com/~lynn/2004m.html#16 computer industry scenairo before the invention of the PC?
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005b.html#50 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#18 address space
http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers
http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces

64-bit architectures & 32-bit instructions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: 64-bit architectures & 32-bit instructions
Date: Sun, Mar 26 2006 12:09 pm
Newsgroups: comp.arch

Eugene Miya wrote:

It's so wrong, I emailed Hennessy (who used to lurk here in the 80s)
to take a look, since that page credits MIPS (his firm) with the
first 64-bit architecture (no mention of Cray, CDC, IBM before 1991,
etc. etc. and whatever features they used).

So if you use Wikipedia or grade papers on architecture on this
topic be forewarned.  That page had so much wrong with it, it just
wasn't worth starting to fix (people with more 64-bit experience
than me should do that).  This came up in part as a topic also in
comp.sys.unisys which also has wikipedia problems.

Gray is on my side with this one.

last time i looked at power/pc entries on wikipedia ... it also had
incorrect stuff (although checking it just now ... it appears to have
been redone) ... reference to comp.arch post last year mentioning some
amount of power/pc description was jumbled:
http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design

the above post makes mention that the executive we reported to when we
were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

moved over to head up somerset (when it was formed). then sometime in
93, he left to be president of MIPS.

The Pankian Metaphor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.folklore.computers
Date: Sun, Mar 26 2006 6:59 pm

greymaus wrote:

My original message was inspired by the best computer (sorta) film
ever, "War Games", and the two geeks in the back office, nice enough
guys (They gave the young hero good advice), but no social graces.

i believe the car ferry in the movie was suppose to be off the coast
of oregon ... however it was the old steilicom ferry that ran between
the mainland, mcneil island and anderson island (south of tacoma
... just off ft. lewis). the ferry was later converted to tourist boat
that makes the round on lake washington ... out of kirkland

misc. past posts mentioing war games
http://www.garlic.com/~lynn/2000d.html#39 Future hacks [was Re: RS/6000 ]
http://www.garlic.com/~lynn/2001m.html#52 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2002b.html#38 "war-dialing" etymology?
http://www.garlic.com/~lynn/2003g.html#56 OT What movies have taught us about Computers
http://www.garlic.com/~lynn/2004p.html#40 Computers in movies

Wonder why IBM code quality is suffering?

From: lynn@garlic.com
Subject: Re: Wonder why IBM code quality is suffering?
Date: Mon, 27 Mar 2006 07:26:47 -0800
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers

rtsujimoto_consultant@ibm-main.lst wrote:

No, PL/C was Cornell University's student PL/1 compiler.  (I
remember it, too; Waterloo had it as one of their batch compilers,
as did ISU and many other colleges and universities around the
world.)

The PL/X genealogy included PL/S and PL/AS, but not PL/C.

posting in pl/s, et al thread in this n.g. from a couple years ago
http://www.garlic.com/~lynn/2004g.html#46 PL/? History

wikipedia entry for pl/c
http://en.wikipedia.org/wiki/PL/C

another pl/i subset was pl.8 developed as part of 801/risc project.
cp.r was written in pl.8. misc. posts mentioning 801, pl.8, cp.r,
romp, rios, power, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801

and for some drift, a recent post mentioning wikipedia and power/pc
http://www.garlic.com/~lynn/2006f.html#6 64-bit architectures & 32-bit instructions

The Pankian Metaphor

From: lynn@garlic.com
Subject: Re: The Pankian Metaphor
Date: Tues, Mar 28 2006 10:05 am
Newsgroups: alt.lang.asm, alt.folklore.computers

jmfbahciv writes:

I read those.  I'm trying to learn about miraculously piece of it.
I tried to find the Marshall Plan; it doesn't exist.  I had assumed
that a plan implies a written project plan.  It was a speech
and somehow what the guy said got translated into real actions.
I want to learn how this translation happens.  The work done
to do this is at the heart of how people run countries, including
the very mysterious thingie called foreign policy.

try a little of this ... article on ebrd, eca, erp, marshall plan
http://www.ciaonet.org/olj/iai/iai_98haj01.html

from above

The Economic Cooperation Act of 1948 authorising the ERP called for a
viable, "healthy [West European] economy independent of extraordinary
outside assistance". US bilateral agreements with 15 participating
governments set four basic tasks:

    * a strong production effort
    * expansion of foreign trade
    * restoration of internal financial stability
    * intra-European co-operation.

... snip ...

old topic drift posting regarding some of the period
http://www.garlic.com/~lynn/2004e.html#19 Message To America's Students: The War, The Draft, Your Future

more recent post in the same drfit:
http://www.garlic.com/~lynn/2006b.html#27 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006b.html#33 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#27 Mount DASD as read-only

The Pankian Metaphor

From: lynn@garlic.com
Subject: Re: The Pankian Metaphor
Date: Tues, Mar 28 2006 2:46 pm
Newsgroups: alt.lang.asm, alt.folklore.computers

lynn@garlic.com wrote:

try a little of this ... article on ebrd, eca, erp, marshall plan
http://www.ciaonet.org/olj/iai/iai_98haj01.html

ref:
http://www.garlic.com/~lynn/2006f.html#9 The Pankian Metaphor

i did search engine on EBRD (current marshall plan) and "Marshall
Plan" and one of the results was the above URL ... clicking on the
above URL from the search engine web page brings it up ... but
entering the above URL or clicking on the URL from some other page
... gets me a request to enter userid/password to access the
information.

so here is search engine query that picks up the above URL (among
several)
http://www.google.com/search?num=100&hl=en&as_qdr=all&q=ebrd+%22marshall+plan%22&spell=1
http://search.yahoo.com/search?fr=FP-pull-web-t&p=ebrd+%22marshall+plan%22

Anyone remember Mohawk Data Science ?

From: lynn@garlic.com
Subject: Re: Anyone remember Mohawk Data Science ?
Date: Wed, Mar 29 2006 10:30 am
Newsgroups: alt.folklore.computers

Charles Richmond wrote:

I worked on the Harris 800 and 1200, which were 24-bit successors to
the Harris 500. I worked mainly with their FORTRAN-77 compiler, which
was done *extremely* well. It did a great job of optomizing the code.
I also worked with their C compiler which was also good. All this was
circa 1984 to 1988.

after virtual memory was shipping for 370 ... I did some customer
marketing calls for vm/cms on 370/145 at various universities, in some
cases in competitive situation against harris and xds

370 virtual memory announce and ship:

                  ann.   ship
IBM S/370 VS      72-08 73-08 12  VIRTUAL STORAGE ARCHITECTURE FOR S/370

from old posting
http://www.garlic.com/~lynn/99.html#209 Core (word usage) was anti-equipment etc

harris, datacraft, interdata, etc. timeline
http://www.ccur.com/corp_companyhistory.asp?h=1
http://ed-thelen.org/comp-hist/GBell-minicomputer-list.html

and a sds/xds ref.
http://www.andrews.edu/~calkins/profess/SDSigma7.htm

for some drift, earlier at the univ. in the late 60s, we initially
used an interdata/3 as basis for creating mainframe telecommunication
controller clone
http://www.garlic.com/~lynn/subtopic.html#360pcm

Barbaras (mini-)rant

From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Subject: Re: Barbaras (mini-)rant
Date: Wed, 29 Mar 2006 14:02:22 -0800

Dave Cartwright wrote:

I'm with Jim on this. I was a contractor in the mid to late '90's
and came across the early TCPIP stack, written in PASCAL and ported
from VM. As I recall it performed OK, and had some quite advanced
features like VIPA which was the subject of another recent
thread. The Cisco man at the scottish bank I worked was quite
impressed.

the base vs/pascal implementation on vm used approx. 3090 processor
getting 44kbytes/sec thruput.

i added rfc 1044 support to the base ... and in some tuning at cray
research was getting sustained 1mbyte/sec between a 4341-clone and a
cray ... using only modest amount of the 4341-clone cpu (around
25 times the data rate for a small fraction of cpu).

misc. past posts mentioning adding rfc 1044 support
http://www.garlic.com/~lynn/subnetwork.html#1044

slight drift ... my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

other posts on high-speed data transport project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

we were operating a high-speed backbone ... but were not allowed to
actually bid on nsfnet1 (original internet backbone) ... however, we
did get a technical audit by NSF that said what we had running was at
least five years ahead of all nsfnet1 bid submissions.

i was asked to be the red team for nsfnet2 bid ... there were something
like 20 people from seven labs around the world that were the blue team
(although only the blue team proposal was actually allowed to be
submitted). minor past refs:
http://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET?
http://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2003c.html#46 diffence between itanium and alpha
http://www.garlic.com/~lynn/2004g.html#12 network history
http://www.garlic.com/~lynn/2004l.html#1 Xah Lee's Unixism
http://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
http://www.garlic.com/~lynn/2006e.html#38 The Pankian Metaphor

part of old reference from 1988 (although not of the added rfc 1044
support)

TITLE IBM TCP/IP FOR VM (TM) RELEASE 1 MODIFICATION LEVEL 2 WITH
ADDITIONAL FUNCTION AND NEW NETWORK FILE SYSTEM FEATURE

ABSTRACT IBM announces Transmission Control Protocol/Internet Protocol
(TCP/IP) for VM (5798-FAL) Release 1 Modification Level 2.  Release
1.2 contains functional enhancements and a new optional Network File
System (NFS) (1) feature.  VM systems with the NFS feature installed
may act as a file server for AIX (TM) 2.2, UNIX (2) and other systems
with the NFS 3.2 client function installed.  Additional functional
enhancements in Release 1.2 include: support for 9370 X.25
Communications Subsystem, X Window System (3) client function, the
ability to use an SNA network to link two TCP/IP networks, and a
remote execution daemon (server).

Barbaras (mini-)rant

From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Subject: Re: Barbaras (mini-)rant
Date: Wed, 29 Mar 2006 16:13:48 -0800

there is also the folklore of the contractor hired to do the original
tcp/ip implementation in vtam. the initial try had tcp benchmark
w/thruput much higher than lu6.2. it was explained to him that
everybody KNEW that a CORRECT tcp/ip implementation would have thruput
much lower than lu6.2 ... and they were only willing to accept a
CORRECT protocol implementation. the contract was handled by a group
that was sometimes called cpd-west located in palo alto sq (corner of
el camino and page mill).

The Pankian Metaphor

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Subject: Re: The Pankian Metaphor
Date: Sat, 01 Apr 2006 16:38:43 -0800

Larry Elmore wrote:

I'm pretty certain that before WWII, all German tanks were made in
Germany.  The Pzkw-I, their first post-WWI tank, was built by
Henschel.  The only possible exception to that would be the Czech
tanks that were seized in 1939 when the rest of Czechoslovakia was
swallowed up.  That's a result of conquest, though, not business.
The Soviet Union cooperated with Germany in military development,
allowing German training in return for technology transfer, but they
didn't build anything for the Germans.

supposedly radio communication during blitzkrieg help modernize
manuver warfare. Boyd also quotes Guderian as verbal orders
only. the scenario is that war never goes perfectly and there are
some class of people, that after a battle, want to lay blame for what
they may perceive as mistakes. Guderian wanted the officer on the spot
to make the best decision possible w/o having to constantly
having to worry about defending themselve later (this was also the
theory that the professional soldier at the lowest possible level
should be making the decisions). misc. past posts mentioning Boyd's
observations about Guderian's verbal orders only.
http://www.garlic.com/~lynn/99.html#120 atomic History
http://www.garlic.com/~lynn/2001.html#29 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001m.html#16 mainframe question
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#38 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002q.html#33 Star Trek: TNG reference
http://www.garlic.com/~lynn/2003h.html#51 employee motivation & executive compensation
http://www.garlic.com/~lynn/2003p.html#27 The BASIC Variations
http://www.garlic.com/~lynn/2004k.html#24 Timeless Classics of Software Engineering
http://www.garlic.com/~lynn/2004q.html#86 Organizations with two or more Managers

old post that had a number of WWII tank references
http://www.garlic.com/~lynn/2000c.html#85 V-Man's Patton Quote (LONG) (Pronafity)
but the URLs appear to have gone 404 or otherwise broken in one way or
another.

so a quicky search for a few tank URLs

The Best Army Tanks of World War II
http://www.chuckhawks.com/best_tanks_WWII.htm
The main American tank in World War 2 won by numbers:
http://www.2worldwar2.com/sherman.htm
The Tiger1 in action:
http://www.fprado.com/armorsite/tiger1_in_action.htm
The German Tiger Tank was introduced in August 1942 and was at that
time the most powerful tank in the world. The success of the Tiger was
so profound, that no allied tank dared to engage it in open
combat. This psychological fear soon became to be known as
"Tigerphobia".
http://www.worldwar2aces.com/tiger-tank/
The rule of thumb was that it took at least five American M4 Sherman
medium tanks to knock out a cornered Tiger.
http://www.fprado.com/armorsite/tiger1-02.htm
At times it took 10 Sherman to kill one Panther or Tiger tank.
http://experts.about.com/q/Military-History-669/World-War-2-Tanks.htm
Even the Panzer IV, the weakest of its opponents, had a more powerful
gun. Against the Panther and the Tiger, the Sherman was hopelessly
outclassed.
http://www.geocities.com/Pentagon/Quarters/1695/Text/sherman.html

Boyd contrasts the blitzkrieg with the US entry into WWII .... having
to throw in massive numbers of personal with little or no experience.
The approach was to create an extremely heavy, top-down decision
making operation that allowed for little or no local automity. He even
mentions that this is possible reason for the extremely top heavy
bueracrcies common in American corporations during the 70s and
80s. The junior officers that got their training on how to run large
operations during WWII were coming into their own as senior corporate
executives ... and the way you ran a large corporation was assume that
there was little or no expertise in the company and everything had to
be rigidly controlled from the top.

Boyd also pointed out that it was a conscious decision during WWII
about the Sherman. The Tigar was recognized as having something like a
5:1 to 10:1 kill ratio over the Sherman ... but it was possible to
turn out massive numbers of Shermans and still win via superior
numbers (logistics and attrition ... modulo possibly something of a
morale issue amoung Sherman crews being used for cannon fodder). misc.
past posts mentioning Boyd's observations about Sherman vis-a-vis
Tiger.
http://www.garlic.com/~lynn/2001.html#30 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001m.html#11 mainframe question
http://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2003n.html#27 Controversial paper - Good response article on ZDNet
http://www.garlic.com/~lynn/2004b.html#24 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2005d.html#45 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005j.html#11 The 8008
http://www.garlic.com/~lynn/2005j.html#14 The 8008

general collection of past posts mentioning Boyd:
http://www.garlic.com/~lynn/subboyd.html#boyd
misc. other URLs from around the web mentioning Boyd:
http://www.garlic.com/~lynn/subboyd.html#boyd2

trusted certificates and trusted repositories

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: trusted certificates and trusted repositories
Newsgroups: sci.crypt
Date: Tue, 04 Apr 2006 08:55:09 -0600

public key related information have certification processes defined,
which can either be done by individuals directly or possibly by some
trusted third party ("TTP") or other institution responsible for the
actual information (in the "TTP" scenario, the institution performing
the certification process has frequently not been the institution that
was actually responsible for the accuracy of the information; the
"TTP" would just certify that they had checked with the agency that
was actually responsible for the information).

the results of the certification process has been the loading of the
certified information into a trusted repository. the trusted
repository could be purely private ... somewhat like an individual's
pgp repository; or possibly some public, online trusted repository.
Another example is the trusted repository of certification authority
public keys shipped in some number of products ... especially browsers
associated with the SSL process.

there was also the scenario that for an offline, disconnected world, a
requirement for certified information (an analog to the old time
letters of credit/introduction from the sailing ship days ... and even
earlier). these were typically read-only copies of some public key
related certified information (that typically resides in some trusted
repository), which were "armored" (with digital signature technology)
for survival in the wild (freely floating around). These are called
digital certificates.

The requirement for the digital certificate (analog of the old-time,
offline letters of credit/introduction), was that the relying party
had no means of their own for directly accessing certified information
... so the other communicating party was presenting a form of
credential along with the communication (again as opposed to the
relying party having their own direct access to such certified
information).

The offline era tends to focus on the resistance of the
credential/certificate to forgery or counterfeiting (degree of
confidence that relying parties could trust the
credential/certificate). A similar example is the educational
certificates from diploma mills.

The online era tends to focus on the integrity of the certification
process and the organization providing the information, typical of
online, real-time operation. This moves past the offline era (worried
about whether the credentials/certificates could be forged or
counterfeited) and moved to what was the meaning of the actual
certified information and all aspects of the associated certification
process.

there have been a number of IETF RFCs that revolve around definitions
for respositories for digital certificates. In the trusted respository
scenario, having both trusted respository of the information and the
information also being read-only copy armored for survival in the wild
(freely floating around), would be redundant and superfluous.

In my (actual) RFC summary entries ... (follow the indicated URL),
clicking on the ".txt=nnnn" field, retrieves the actual RFC

http://www.garlic.com/~lynn/rfcidx14.htm#4398

Storing Certificates in the Domain Name System (DNS), Josefsson S.,
2006/03/31 (17pp) (.txt=35652) (Obsoletes 2538) (Refs 1034, 1035,
2246, 2247, 2440, 2693, 2822, 3280, 3281, 3548, 3851, 3986, 4025,
4033, 4034, 4301) (SC-DNS) (was draft-ietf-dnsext-rfc2538bis-09.txt)

http://www.garlic.com/~lynn/rfcidx14.htm#4387

Internet X.509 Public Key Infrastructure Operational Protocols:
Certificate Store Access via HTTP, Gutmann P., 2006/02/07 (25pp)
(.txt=63182) (Refs 2440, 2585, 2616, 2782, 2854, 3156, 3205, 3275,
3280, 3390, 3852, 3875) (was draft-ietf-pkix-certstore-http-09.txt)

http://www.garlic.com/~lynn/rfcidx14.htm#4386

Internet X.509 Public Key Infrastructure Repository Locator Service,
Boeyen S., Hallam-Baker P., 2006/02/03 (6pp) (.txt=11330) (Refs 2559,
2560, 2585, 2782) (was draft-ietf-pkix-pkixrep-04.txt)

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

trusted repositories and trusted transactions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: trusted repositories and trusted transactions
Newsgroups: sci.crypt
Date: Tue, 04 Apr 2006 09:52:41 -0600

ref:
http://www.garlic.com/~lynn/2006f.html#15 trusted certificates and trusted respositories

part of the x.509 identity certificate stuff from the early 90s was
some forces trying to increase the perceived value of the certificate
by grossly overloading it with every possible piece of personal
information. the counterforce that started to show up by the mid-90s
was the realization that x.509 identity certificate grossly overloaded
with personal information represented significant privacy (and even
liability) issues.

as a result there was some retrenchment in the mid-90s to
relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

these were certificates that contained a public key and a record
locator for a repository of information that wasn't generally publicly
available. the necessary personal information needed by the relying
party was in this trusted repository (and not publicly available).
however, it almost every transaction oriented scenario, it was trivial
to demonstrate that the 1) actual transaction also carried the record
location (like an account number) and since this was a
relying-party-only certificate, the relying-party already had a copy
of the public key (having certified and issued the original digital
certificate). As a result, it was trivial to demonatrate that the
existance of any digital certificate was redundant and superfluous.

the other issue with the trusted transaction scenario is that it tends
to be extremely focused on some actual business process. rather than a
paradigm of static information public repository, a trusted
transaction can take into account many factors, like real-time
aggregated information. for a financial example, a trusted repository
of stale, static information might not only have the account number,
but the actual account record including past transactions and possibly
the account balance at some point in time. rather than a merchant
sending off a request for copy of your digital certificate (certicate
respostiory) or a copy of your account record (trusted respository,
with all possible account related personal information, including
current account balanace); the merchant can send off a digitally
signed transaction asking if a operation for a specific amount is
approved or not. The yes/no response divulges minimum amount of
personal information.

so trusted certificate/credential model tends to be a left-over from
the offline world where relying parties didn't have their own
information regarding the matter at hand and also didn't have access
to a trusted party (as source of the information). offline
credential/certificate paradigm tended to be pre-occupied with
forgeriess of the certificate/credential.

the trusted repository model tends to move more into a more modern
online era. however, it has tended to have more generalized
collections of information ... not necessarily being able to predict
what infomration relying parties might actually be in need
of. however, especially when individuals have been involved, trusted
repositories of general information have tended to represent
unnecessary disclosier of sensitive and/or personal information.

the trusted transaction model has tended to be much more valuable
operation, in part because dynamic operations associated with real
business processes can be taken into consideration. at the same time
the transactions are frequently designed to make minimal unnecessary
disclosier of sensitive and/or personal information.

my joke left-over from the mid=90s was about various suggestions that
the financial/payment infrastructure be moved into the modern era by
attaching (relying-party-only) digital certificates to every
transaction.  my reply was that the offline paradigm digital
certificate would actually be setting back the financial/payment
infrastructure to pre-70s days before online, realtime transactions.

it was possible to have digitally signed financial transactions for
purely authentication purposes. the responsible financial institution
could validate the digital signature with the onfile public key
... and any digital certificate was purely redundant and superfluous.
the online transaction could come back approved or declined ... which
is much more valuable to merchants ... than a credential certifying
that at some point in the past you had opened a bank account.

the x9.59 financial standard scenario
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

even required that account numbers used in x9.59 transactions could
not be used in non-authenticated transactions. this had the
characteristic that skimming/harvesting/data-breach threats against
account numbers for fraudulent transactions was eliminated.  all the
data-breaches in the world against files containing account numbers
wouldn't enable a crook to take just the account number and use it in
a fraudulent transaction.

recent posts wandering into the skimming/harvesting/data-breach
topic:
http://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#30 Creativity and security
http://www.garlic.com/~lynn/aadsm22.htm#31 Creativity and security
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/2006e.html#2 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense

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

trusted certificates and trusted repositories

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: trusted certificates and trusted repositories
Newsgroups: sci.crypt
Date: Tue, 04 Apr 2006 11:50:59 -0600

Anne & Lynn Wheeler writes:

The offline era tends to focus on the resistance of the
credential/certificates to forgery or counterfeiting (degree of
confidence that relying parties could trust the
credential/certificate).  A similar example is the educational
certificates from diploma mills.

one might even be tempted to claim that pre-occupation with the value
of SSL certificates has obfuscated the certification operations that
the certificates are suppose to represent (aka is the certification
the thing of value or does the certificate, which is supposedly just
one way of representing that certification, have its own value
unrelated to the certified information). this may have contributed to
situations where consumers are perfectly comfortable with websites
that have valid SSL certificates ... even tho the websites may have
been created for purely fraudulent objectives.

misc. past posts on ssl certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

ref:
http://www.garlic.com/~lynn/2006f.html#15 trusted certificates and trusted repositories
http://www.garlic.com/~lynn/2006f.html#16 trusted repositories and trusted transactions

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

how much swap size did you take?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how much swap size did you take?
Newsgroups: alt.os.linux.redhat
Date: Wed, 05 Apr 2006 09:40:22 -0600

virtual memory is used to contain executing processes. using
paged/swapped virtual memory it is possible to have more executing
processes than can fit into real storage. the virtual memory hardware
is used to indicate what pieces are actually in real memory (and where
they are located).

SWAP/paging space is used to contain the virtual memory that isn't
being currently used and has been moved out of real storage to make
room available for other pieces of virtual memory (either for the same
process or other processes).

the amount of SWAP/page space needed on disk is dependent on how much
total virtual memory is required by your active running processes.

this is slightly affected by whether the page replacement algorithm is
following a "DUP" or "NO-DUP" strategy (duplicate or no-duplicate
strategy).

as an undergraduate in the late 60s I did a lot of paging algorithm
stuff. I created lazy allocate ... i.e. on initial use by a process, a
virtual page was allocated in real memory ... but it wasn't required
to allocate a corresponding page on disk (at that time). It was only
when a virtual page was selected for replacement the first time ...
that a page on disk was initially alloccated.

if the total requirement by all processes for virtual memory was
containable by available real storage ... then pages would never be
selected for replacement ... and there was no requirement for
swap/page space on disk.

however, at that time, i used a "duplicate" stragegy. this was when a
virtual page was on disk ... and some process required it.  a page was
allocated in real memory (potentially first removing some other
virtual page to disk), the requested virtual page read in and started
being used. however, the copy on disk was left allocated. In this
strategy, there were two allocated copies of the page ... one in real
storage and one on disk. In a scenario where there was demand for real
storage, much larger than available ... eventually all virtual pages
will have been replaced at one time or another. In this scenario,
eventually all virtual pages will have an allocated copy on disk (even
those also having a copy in real memory ... therefor the "duplicate"
reference). This "duplicate" allocation scenario requires that amount
of secondary SWAP/page allocation on disk is equal to the mazimum
amount of virtual memory that may concurrently required by all
processes that you might have running at the same time (which is
dependent on the workload that you happen to be running on the
machine).

later in the 70s, as real memory started becoming much larger ... i
started seeing some configurations where the amount of real storage
(and therefor the number of potential "duplicates") were approaching a
significant percentage of possible available SWAP/page disk
space. This was especially becoming true of those configurations with
fix-head disks and/or electronic disks being used for SWAP/page.

for these configurations i added a "no-duplicate" implementation and
some code that could dynamically switch between "duplicate" strategy
and "no-duplicate" strategy. In the "no-duplicate" strategy, whenever
a virtual page was brought in from disk, the corresponding disk space
was de-allocated (therefor there wasn't a duplicate page both in real
memory and on disk).

For a configuration with heavy SWAP/page use and using a "duplicate"
strategy ... the amount of SWAP/page space tends to be equal to the
maximum virtual memory required by all concurrently running processes.
In the "no-duplicate" strategy the amount of SWAP/page plus real
memory needs to be equal to the maximum virtual memory required by all
concurrently running processes, i.e. in a no-duplicate strategy, the
amount of SWAP/page space can be reduced by the amount of real
storage). The "no-duplicate" calculation real-storage reduciton is
modulo the amount of real-storage required for fixed kernel
requirements and file caching (which may be around 1/3rd of real
storage for some configurations).

misc. past postings mentioning dup & no-dup strategies
http://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002f.html#26 Blade architectures
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s

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

Over my head in a JES exit

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Over my head in a JES exit
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 10 Apr 2006 09:22:17 -0600

Efinnell15@ibm-main.lst wrote:

The story I heard was they liked ASP, but it was too piggy so a
furious rewrite was undertaken and it became Half ASP. Most of the
design objectives were met. When they went to present, it was  deemed
unsophisticated and changed to Houston  ASP.

Local Houston branch office group put out HASP type-III for some time
before their was an official support formed in gburg and many of the
people moved there ... and the name change to JES2

ASP was two-processor loosly-coupled system ... although there was a
flavor called LASP (single processor) ... local-ASP somewhat to compete
with HASP.

both HASP and ASP come out of the field since the original "spooling"
built into the base product had significant issues.

My wife served a stint in the gburg group ... and was one of the
technology catchers for ASP ... when it was also moved to the gburg
group and renamed JES3. She also did a detailed technology and market
analysis of JES2 and JES3 for a proposal for a merged product
(maintaining the major important customer requirements from each in the
merged product). However, there was some amount of discord for that to
ever succeed. She did get quite a bit of experience regarding
loosely-coupled operation and was eventually con'ed into serving a stint
in POK in charge of loosely-couple architecture. She developed
peer-coupled shared data architecture ... that also saw quite a bit of
resistance. Except for work by the IMS hot-standby effort, it didn't see
much uptake until parallel sysplex
http://www.garlic.com/~lynn/subtopic.html#shareddata

lots of past postings mentioning HASP
http://www.garlic.com/~lynn/subtopic.html#hasp

I can almost see the cover of my old HASP documentation ... but I can't
remember the HASP type III program product number. However, search
engines are your friend; an old JES2 posting from 1992 giving some of
the original history and the type-III program product number:
http://listserv.biu.ac.il/cgi-bin/wa?A2=ind9204&L=jes2-l&T=0&P=476

following take from above:

"It was originally written in Houston in 1967 in support of the Appolo
manned spacecraft program.  Subsequently it was distributed as a Type
III program, picked up a small number of users but through the years the
number of users have increased fairly substantially.  Further more there
is a continuing demand today for HASP.  The growth that we have
accomplished has not been without problems.  In 1968 IBM decided that in
release 15/16 since we had readers and writers we no longer had a
requirement for HASP. IBM came down very hard on the users and said we
were'nt going to have a HASP.  The users resisted and HASP exists today."

Any typos in the above are mine.  My Contributed Program Library
document for HOUSTON AUTOMATIC SPOOLING PRIORITY SYSTEM 360D 05.1.007 is
dated August 15, 1967.  The authors listed are: Tom H. Simpson, Robert
P. Crabtree, Wayne F. Borgers, Clinton H. Long, and Watson M. Correr.

... snip ...

One of the internal problems with the JES2 NJE network was it
traditional networking paradigm and severe limitations. Quite a bit of
the original code still carried the "TUCC" label out in cols. 68-71 of
the source. It had intermixed networking related fields in with all the
job control header fields. It had also scavange the HASP 256 psuedo
device table for network node identifiers; as a result a typical
installation might have 60-80 psuedo devices leaving only 180-200
entries for network node definitions. By the time JES2 NJE was
announced, the internal network was already well over 256 nodes.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

The lack of strongly defined layers and intermixing networking and job
information severely compromised a lot of the internal network. Minor
changes to header format from release to release would result in network
file incompatibilities. Some machines somewhere in the world, upgrading
to a newer release before all the other machines in the world
simultaneously upgrading to the same release. There is the well-known
legend of the JES2 systems in San Jose being upgraded which resulted in
MVS systems in Hursley crashing trying to process network files
originating from the San Jose system.

the original internal network technology had been developed at the
science center (same place that gave you virtual machines, gml, and a
lot of interactive computing)
http://www.garlic.com/~lynn/subtopic.html#545tech

and had well defined network layering as well as effectively a form of
gateway technology in each of its nodes. I've frequently asserted that
heavily contributed to the internal network being larger than the
arpanet/internet from just about the beginning until possibly mid-85.
Because of the many limitations in NJE ... JES2 nodes tended to be
restricted to end-nodes in the internal networks. all the intermediary
nodes were the responsible of the networking technology from the science
center. When talking to a JES2 system ... a special NJE driver would be
started. The ease of having lots of different drivers all simultaneously
running in the same node ... also gave rise to the not only having a
large library of different NJE drivers ... that corresponded to all the
currently deployed JES2 releases. The other technology eventually
developed in these drivers was a canonical JES2 header representation.
The specific NJE driver directly talking to a real end-node JES2 system
would do an on-the-fly translation from the canonical format to the
format specifically required by the JES2 system it was talking to (as a
countermeasure to JES2 mis-understanding NJE header fields resulting in
MVS system crashes).

... for slightly other drift

one of the principle HASP people went to Harrison in westchester country
and started a project codenamed RASP. This was sort of a cross between
tss/360 and MTS ... reborn and redone from scratch as brand new
operating system. tailored for virtual memory environment and not
carrying with it all the baggage of real memory heritage ... heavy
dependency on pointer passing, application API still real address i/o
oriented with heavy dependency on ccw translation. a couple recent posts
on ccw translation
http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT

for various reasons that person eventually left and became an Amdahl
"fellow" in Dallas and started a project similar to RASP that was code
named Aspen. Along the way there was some legal wrangling regarding
whether Aspen was contaminated with RASP code. misc. past posts
mentioning RASP and/or Aspen.
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#2 Article in Information week: Mainframe Programmers Wanted
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006b.html#24 Seeking Info on XDS Sigma 7 APL

Old PCs--environmental hazard

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old PCs--environmental hazard
Newsgroups: alt.folklore.computers
Date: Mon, 10 Apr 2006 10:14:06 -0600

Brian Boutel writes:

Some organisations require clean desks every night for all employees,
sharing or not. This is for security. You can't trust the cleaners.

you may not be able to trust the cleaners ... but i thot clean desks
were for the security officers that came around late at night checking
to see if you had complied with all classified information being under
lock. since they had to leaf thru all the paper that had been left out
... their job was much faster if there was nothing left out.

for classified trash there were 50gal barrels, top lid was secured
with padlock and had specially constructed slot. I don't think they
were directly emptied, instead they were periodically collected with
empty barrel replacing the collected barrel.

we had "internal use only" ... which was ok to leave out, the printed
corporate telephone book was "internal use only". then was simple
corporate confidential, which had to be kept under locked up at
night. I once accidentially carried a document labeled corporate
confidential into a gov. facility. the marine guards caught it on the
search leaving and maintained that they had no way of knowing whether
it was a gov. confidential document or a corporate confidential
document (the corporate name possibly being just a gov.  confidential
classification term). It took quite a while to get the document
liberated.

then there was "confidential - restricted" ... basically need to know
only. in the 70s, internal copies of the cern report to share
comparing cms and tso got stamped "confidential - restricted"
... there was an objective of restricting employee knowledge about how
bad tso was compared to cms.

the highest level were the candy striped "registered confidential"
documents ... each page was embossed with large faint document serial
number in the background (numbers were couple inches in size), aka
there was a document publication number ... but in addition each copy
of the document had a unique document serial number embossed on each
page. these had to be kept in special double-locked cabinets. you had
to sign for each serial numbered document and there were sporadic
security audits where you had to show that each document signed out to
you was still in your possession (and kept under lock and key). at one
point I had a cabinet full of 811 documents, which was code name
(taken from nov. 1978 inception) for 370-xa, 31bit virtual addressing,
some of the stuff that showed in in 3081 processors.

misc. past posts mentioning "confidential - restricted" and/or
"registered confidential"
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just missing a great opportunity...
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/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002g.html#67 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002h.html#14 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002n.html#37 VR vs. Portable Computing
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003k.html#13 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#21 TSO alternative
http://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
http://www.garlic.com/~lynn/2004n.html#17 RISCs too close to hardware?
http://www.garlic.com/~lynn/2005f.html#42 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#49 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005s.html#26 IEH/IEB/... names?

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

Over my head in a JES exit

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Over my head in a JES exit
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
CC: ibmmain <ibm-main@bama.ua.edu>
Date: Mon, 10 Apr 2006 11:43:30 -0600

Anne & Lynn Wheeler wrote:

One of the internal problems with the JES2 NJE network was it
traditional networking paradigm and severe limitations. Quite a bit of
the original code still carried the "TUCC" label out in cols. 68-71 of
the source. It had intermixed networking related fields in with all the

ref:
http://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit

another problem JES2 had internally was its use of source maintenance.

both cp67 (and later vm370) and hasp shipped with full source. A lot of
customers commoningly rebuilt their systems from scratch ...
re-assembling everything from source.

internally, the jes2 group had adopted the source maintenance
infrastructure from cp/cms ... and were doing almost all their
development on cp/cms platform. actually a large number of product
groups did majority of their development on cp/cms platform ... even a
large number of the mvs-based products. however, jes2 was one of the few
mvs-based products that exclusively used the cp/cms source maintenance
infrastructure (possibly in part because they had shared a common
heritage of shipping all source and customers being used to rebuilding
systems from scratch using the source).

however, this created some amount of hassle for jes2 development group
... because they then had to convert all their cp/cms based stuff to mvs
infrastructure for product ship.

misc. past posts describing evolution of cp/cms source maintenance
infrastructure
http://www.garlic.com/~lynn/2001h.html#57 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2002n.html#39 CMS update
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003j.html#14 A Dark Day
http://www.garlic.com/~lynn/2003j.html#45 Hand cranking telephones
http://www.garlic.com/~lynn/2003k.html#46 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
http://www.garlic.com/~lynn/2005b.html#58 History of performance counters
http://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#6 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006b.html#10 IBM 3090/VM Humor

A very basic question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A very basic question
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 10 Apr 2006 12:32:57 -0600

Ted MacNEIL wrote:

Also, for the poster that asked about CPU usage.  Who cares? This
entire CICS sub-system is using less than 5% of the processor.  The
only one being impacted is this sub-system.  CICS cannot sustain that
rate very long without response implications.

We need to know the cost per I/O to size the work effort to repair or
remove.

the science center had done a whole lot of work on performance ...
http://www.garlic.com/~lynn/subtopic.html#545tech

lots of work on instrumenting much of the kernel activity and collecting
the statistics on regular intervals (every ten minutes, 7x24 ...
eventually with historical data that spanned decades).

people at the science center also did a lot of even modeling for
characterizing system operation

and did the apl analytical system model that eventually turned into
the performance predictor on HONE.

HONE was an online (cp/cms based) time-sharing system that supported
all the field, sales and marketing people in the world (major replicas
of HONE were positioned all around the world).
http://www.garlic.com/~lynn/subtopic.html#hone

eventually all system orders had to be processed by some HONE
application or another. the HONE performance predictor was a
"what-if" type application for sales ... you entered some amount of
information about customer workload and configuration (typically in
machine readable form) and asked "what-if" questions about changes in
workload or configuration (type of stuff that is normally done by
spreadsheet applications these days).

i used variation off the performance predictor was also used for
selecting next configuration/workload in the automated benchmark
process that I used for calibrating/validating the resource manager
before product ship (one sequence involved 2000 benchmarks that took 3
months elapsed to run)
http://www.garlic.com/~lynn/subtopic.html#bench

the performance monitoring, tuning, profiling and management work
eventually evolved also into capacity planning.

there also were some number of instruction address sampling tools
... to approx. where processes were spending much of the time. One
such tool was done in support of deciding what kernel functions to
drop into microcode for endicott's microcode assists. the guy in palo
alto that had done the apl microcode assist originally for the 370/145
... did a psw instruction address sampling application in 145
microcode and we used it to help select what part of kernel
pathlengths to drop into microcode for kernel performance
assist. minor reference
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

However, another technology we used was to take interval activity data
and run it thru multiple regression analysis ... assuming we accounted
for the major activity variables, we were able to come up with pretty
accurate cpu time correlation with different activities. Doesn't take
a whole lot of effort ... just a far amount of recorded activity over
range of activity and feed it into a good MRA routine. At the time, we
primarily used MRA from the scientific subroutine library. There are
some free packages you can find on the web ... but to get one that can
handle both a large number of variables and large number of data
points ... you may have to consider a commercial package.

In subsequent years, I've used MRA to find anomalous correlations in
extremely large applications ... unusual activity correlations that
conventional wisdom maintained couldn't possible be correct ... but
actually accounted for major resource consumption. This is analogous
to one of the other postings in this thread about finding things
happening in a large application; that the responsible application
people couldn't possibly believe was happening.

trivial things MRA may turn up is cpu use and i/o activity by major
functions, cpu use per i/o, etc.

Old PCs--environmental hazard

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old PCs--environmental hazard
Newsgroups: alt.folklore.computers
Date: Mon, 10 Apr 2006 13:37:27 -0600

"Rostyslaw J. Lewyckyj" writes:

As I remember it on the 360 ... OS MVS ..., there were/are two
types, levels, of IPL.  There is the cold start IPL and a warm start
IPL For either system you set in the address of the device from
which the system is to be loaded. The hardware then reads in the IPL
bootstrap record from the device and starts executing it.  In a cold
start IPL you lose all previous information about the former state
of the system, such as the spool pack, job queues, etc. In a warm
start you don't.

there were generally two different kinds of things referred to as IPL
"warm start". one tried to scavanage old data laying around in memory
at the time of the reboot and save it as part of restarting. the other
was slightly analogous to fsck in unix ... although significantly
faster and involving significantly less information.

when recoverable information needed by either process was too messed
up, you fell back to a cold start.

search engine is your friend ... here is more detailed description of
ipl, nip, and hasp with os/360 (predating hasp being renamed jes2
which managed the spool and the job queue; and os/360 being renamed
mvs).
http://hansen-family.com/mvs/IPL_Process.htm

cold/warm was when you had gotten to the hasp initialization phase of
system startup and had to reply warm/cold.

a little more overview:
http://hansen-family.com/mvs/MVS.htm

various past postings mentioning hasp
http://www.garlic.com/~lynn/subtopic.html#hasp

it took quite awhile before os/360 got alternate console support.  I
remember having the whole system to my self on weekens and the system
coming to a griding halt and ringing the bell. nothing would work.
even rebooting/reipl just resulted in the bell ringing. i would
eventually bang on the 1052-7 operator's console in frustration and
the fan-fold paper would fall out the back of the 1052-7 ... and it
was obvious the the system was waiting for new paper to be feed into
the console.

the 1052-7 had a little finger sensor for when it ran out of paper ...
and it would present "unit check", "intervention required" i/o error
in response attempting to write to the console. the system then would
ring the bell and wait until the operator had feed a new stack of
paper into the operator's console.

it turns out that it was possible for the end of the paper feed to
move past the finger sensor ... but it was sometimes positioned just
so that the paper didn't actually finish falling out. from the front
of the operator's console it still looked like it had good supply of
paper. it wasn't until you banged in frustration on the keyboard that
it jiggled the mechanism and the paper fell out (and then it was
obvious what the problem was).

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

Over my head in a JES exit

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Over my head in a JES exit
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 10 Apr 2006 14:04:05 -0600

Brian Inglis writes:

... more importantly, can you see the cover of your HASP songbook?
... on Friday morning?

I've got an old HASP songbook someplace (and even several
reproductions of the 1931 edition of the ibm song book).

scids typically closed at midnight ... so that wasn't hard. however,
back in the days of the free bar at scids ... share will have
pre-purchased/order some number of cases of alcoholic beverages.
thursday night after scids, the un-consumed beverages would be taken
to the (share) president's suite.  some number of people had an
obligation to help with minimizing the amount of non-empty alcoholic
beverage containers that the president had to deal with on friday.

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

Over my head in a JES exit

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Over my head in a JES exit
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 10 Apr 2006 16:56:49 -0600

Brian Inglis writes:

Nobody created a PDS (module library) creator (or transporter) similar
to (Unix) tar, so they could just NJE the files over to MVS?
IIRC tar format is basically a dump of inode metadata and file data.

it wasn't filesystem metadata issue (files easily moved back and
forth) ... it was that the structure of the multi-level cms source
maintenence metadata was different than the mvs product/component
management metadata. the mvs fixes, enhancement, change maintenance
metadata was totally different (and there wasn't necessarily a
straight-foward automated conversion from one to the other).

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

Old PCs--environmental hazard

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old PCs--environmental hazard
Newsgroups: alt.folklore.computers
Date: Mon, 10 Apr 2006 17:20:15 -0600

"Rostyslaw J. Lewyckyj" writes:

It was also the place where the version of Unix that was later taken
over by Amdahl was first developed.

there was a concerted effort to try and get approval to make a job
offer to the person (that did most of the work) after he had graduated
... but wasn't succesful, and so he went w/amdahl.

as mentioned in some of the past postings referencing aspen ... there
was some amount of rivalry between aspen and gold (aka A.U.) projects.
I suggested to some of them that they might somewhat reconcile by
looking at doing something akin to the tss/370 ssup work for AT&T
... with a stripped down page mapped supervisor underneath higher
level unix code.

If nothing else, there were several in the valley that would show up
to the monthly meetings at SLAC and then adjorn to the blue goose or
one of the other watering holes afterwards ... where we would
kibitz/gosip about such things.

couple recent posts mentioning the tss/370 unix stuff for AT&T:
http://www.garlic.com/~lynn/2006e.html#31 MCTS
http://www.garlic.com/~lynn/2006e.html#33 MCTS

the most recent post with references to Aspen (it didn't
mention the gold activity ... but it has a list of URLs,
some of which mention both aspen and gold):
http://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit

misc. past posts with reference to the TUCC label in HASP networking
source:
http://www.garlic.com/~lynn/2001g.html#48 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001n.html#11 OCO
http://www.garlic.com/~lynn/2001n.html#12 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#23 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#48 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002q.html#31 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2002q.html#32 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2002q.html#35 HASP:
http://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004g.html#8 network history
http://www.garlic.com/~lynn/2004q.html#58 CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)
http://www.garlic.com/~lynn/2005f.html#12 Mozilla v Firefox
http://www.garlic.com/~lynn/2005f.html#53 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005i.html#37 Secure FTP on the Mainframe
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3

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

Old PCs--environmental hazard

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old PCs--environmental hazard
Newsgroups: alt.folklore.computers
Date: Mon, 10 Apr 2006 17:47:49 -0600

"Rostyslaw J. Lewyckyj" writes:

For some reason I thought/remembered that the person involved was
'S.B' and he went to Bell Telephone Labs, got interested in security
and is still there and also involved in SANS. Also the system name
was UTS?

I remember effort to try and hire at least one person that was
involved in the effort. at amdahl, the development project was code
named gold (after initials for "amdahl unix"). the product was
announced as UTS.

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

Old PCs--environmental hazard

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old PCs--environmental hazard
Newsgroups: alt.folklore.computers
Date: Mon, 10 Apr 2006 18:02:30 -0600

an old email only partially related (note gold wasn't single user as
speculated in the attached)


To: wheeler
Date: 04/04/80 10:48:34
From: somewhere on the east coast

Lynn,

     XXX and I were involved to some extent with the TSS thing, and to
wishful thinking about modifying CP in the way that they wanted to
modify TSS.  We ahve heard of the Amdahl UNIX stuff. The former
Princeton student did a conversion of UNIX while at Princeton to run
under VM, but it really ran as if it were in a bare machine. The TSS
thing was very different, and so was the proposed CP changes...to
provide all sort of functions for the lower levels of UNIX supervisor
to do task forking, etc. The Princeton thing never got to a practical
working state, but was obviously feasible.

     It could be that the version done at Amdahl by the former
Princeton student also runs in a virtual machine, and supports
multiple users in a virtual machine. Perhaps the Amdahl hypervisor is
all that it runs under?  Maybe that UNIX takes advantage of the
various diagnoses of CP?  Another possiblity is that further work was
done to make the UNIX single user in nature. This is not too hard to
do, since the Bell Sys. Tel. J. had an article about a single user
LSX11 version of UNIX.

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

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

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Tue, 11 Apr 2006 11:03:19 -0600

Ken Johanson writes:

Moreover, x509 certs (and constructed CAs) instantly lend themselves
to a whole host of other secure AND trust applications, https,
ldaps, smtps, ftps, imaps (to name a few), mail signing /
encryption, software signing. When you extend their reach out to all
these other forms of communication, and used by computer laymen,
old-fashioned random public key strings is simply not at all
feasibile.

Anyone who claims that that x509 is disadvantaged compared to plain
PKI, is simply demonstrating that they have no practical or level
experience with BOTH technologies. That really shows like sore thumb
to those of us who do have both exeriences.

one of the issues from x.509 identity certificates from the early 90s
was the eventual realization that certificates potentially grossly
overloaded with personal information represented significant privacy
and liability issues.

as a result, in the mid-90s you saw the introduction of
relying-party-only certificates ...
http://www.garlic.com/~lynn/subpubkey.html#rpo

where the only unique information in the certificate was some sort of
account number (that could be used to index a respository where the
actual entity information resided, including the original issued
public key information, along with that public key) and a public key.

an entity created some sort of message or transaction, digitally
signed the transaction and appended the RPO-certificate. It was
trivial to show for these scenarios that the appended certificate was
redundant and superfluous.

I got a lot of flack in the mid-90s for demonstrating that appending
such certificate was redundant and superfluous. The conventional
wisdom at the time was that appendidng certificates was required for
everything and if you voiced any sort of opposing view, you were a
heretic doing the work of the devil. One of the lines was about
appending certificates to retail payment transactions would bring the
business process into the modern era. My counter-argument was that the
purpose of appending certificates to payment transactions was to
provide sufficient information for offline authorization ... and, as
such was actually a return to the 50s era, predating online
transactions.

This is the business process analysis of appended certificates
following the offline credential model or the letters of
introduction/credit from the sailing ship days (dating back at least
several centuries). The credential/certificate paradigm is useful in
offline scenarios where the relying party.

1) doesn't have their own information about the other party

2) doesn't have any online access to trusted authorities for
information about the other party

3) must rely on prepackaged, stale, static credential/certificate
about the other party rather than having online access to realtime
information

when we were called in to work with small client/server startup
that wanted to do payments on their server and had this technology
called SSL ...
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we had to work out the business process details of using SSL
technology for payments ... as well as doing walkthru audits of these
emerging operations calling themselves certification authorities.

for the original payment gateway, for using SSL between the server and
the payment gateway (for payment transactions), one of the first
things we had to do was specify something called mutual authentication
(which hadn't yet been created for SSL). However, as we flushed out
the business process of servers interacting with the payment gateway,
we were keeping tables of authorized merchants and the gateway and
gateway specificate information loaded at each merchant. By the time
we were done with the process, it was evident that any certificate use
was also totally redundent and superfluous (purely a side-effect of
using the crypto function that were part of the SSL library).

The payment gateway had registered information (including public keys)
of all authorized merchants and all authorized merchants had
configuration information regarding the payment gateway (including its
public key). There was absolutely no incremental business process
advantage of appending digital certificates to any of the
transmissions.

The other part of stale, static, redundant and
superfluous certificates, at least related to payment transactions
was that a typical retail payment transaction is on the order of 60-80
bytes.  The RPO-certificate overhead from the mid-90s was on the order
of 4k-12k bytes (i.e. appending stale, static, redundant and
superfluous digital certificates to payment transaction was
causing a two orders of magnitude payload bloat).  Somewhat as
a result, there was an effort started in the financial standards
organization for "compressed" digital certificates ... with a goal of
reducing the 4k-12k byte overhead down into the 300 byte range. Part
of their effort was looking at eliminating all non-unique information
from a RPO-certificate issued by a financial institution (CPS, misc.
other stuff). I raised the issue that a perfectly valid compression
technique was to eliminate all information already in possesion of the
relying party. Since I could show that the relying party already had
all possible information in the digital certificate, it was possible
to reduce the digital certificates to zero bytes. Rather than claiming
it was redundant and superfluous to attack stale, static
digital certificates to a transaction, it was possible to show that it
was possible to attach zero-byte digital certificates to every
transaction (for a significant reduction in the enormous payload
bloat caused by digital certificates).

Another model for certificates ... with respect to thhe emulation of
credential/certificates in the offline world (where the relying party
had no other mechanism for establishing information in first time
communcation with total stranger), was the offline email model from
the early 80s. The relying party would dialup their local (electronic)
post office, exchange email, and hangup. They potentially then had to
deal with frist time email from a total stranger and no way of
establishing any information about the sender.

During the early establishment of electronic commerce, I had frequent
opportunity in exchanges to refer to the merchant digital certificates
as comfort certificates.

Stale, static digital certificates are a tangible
representation of a certification business process. In the offline
world, certificates and credentials were used as a representation of
such certification business processes for the relying parties who had
no direct access or knowledge regarding the original certification
process. These stale, static certificates and credentials
provided a sense of comfort to the relying parties that some
certification process had actually occured.

One of the things that appears to have happened with regard to
physical certificates and credentials ... is that they seemed to have
taken on some mystical properties totally independent of the
certification process that they were created to represent. The
existance of a certificate or credential may convey mystical comfort
... even though they simply are a stale, static representation of the
certification process ... for relying parties that have no other means
of acquiring information about the party they are dealing with.

Another example of such credentials/certificates taking on mystical
comfort properties are the diploma mills ... where the pieces of
parchment produced by diploma mills seem to take on attributes totally
independent of any educational attainment that the parchment is
suppose to represent.

An issue, is that in transition to online paradigm, it is possible for
relying parties to have direct online real-time access to the
certified information ... making having to rely on the stale,
static representations using credentials and certificates,
redundant and superfluous.

However, there is an enormous paradigm change from an offline-based
orientation (where a large percentage of people may still draw great
comfort from artificial constructs that emulate the offline
credential/certificate paradigm) to an online-based paradigm dealing
with realtime information and realtime business processes.

One of the big PKI marketing issues has been "trust". However, the
actual trust has to be in the certification process ... where any
certificate is purely a stale, static representation of that
certification process for use by relying parties that have no other
means of directly accessing the information.

As the world has migrated to more and more online ... that is somewhat
pushing the X.509 and PKI operations into market segments that have no
online mechanisms and/or can't justify the costs associated with
online operation. However, as online becomes more and more ubiquitous
and online costs continue to decline, that market segment for x.509
and PKI operations is rapidly shrinking (needing stale static
certificates as representation of some certification process for
relying parties that otherwise don't have direct access to the
information). Also part of the problem of moving into the no-value
market segment, is that it becomes difficult to justify any revenue
flow as part of doing no-value operations.

a slightly related commented on some of the PKI operations attempting
to misuse constructs with very specific meaning
https://www.financialcryptography.com/mt/archives/000694.html

slightly related set of posts on having worked on word smithing both
the cal. state and federal electronic signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

a collection of earlier posts in this thread:
http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#12 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#13 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#14 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#27 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#29 X.509 and ssh

misc. past posts mentioning the enormous benefits of zero byte
certificates
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 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#kiss6 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/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing

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

A very basic question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A very basic question
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 11 Apr 2006 13:42:09 -0600

Anne & Lynn Wheeler wrote:

eventually all system orders had to be processed by some HONE
application or another. the performance predictor was a "what-if"
type application for sales ... you entered some amount of information
about customer workload and configuration (typically in machine
readable form) and asked "what-if" questions about changes in workload
or configuration (type of stuff that is normally done by spreadsheet
applications these days).

i used variation off the performance predictor was also used for
selecting next configuration/workload in the automated benchmark
process that I used for calibrating/validating the resource manager
before product ship (one sequence involved 2000 benchmarks that took 3
months elapsed to run)
http://www.garlic.com/~lynn/subtopic.html#bench

the performance monitoring, tuning, and management (along with
workload profiling) work evolved into capacity planning.

ref:
http://www.garlic.com/~lynn/2006f.html#22 A very basic question

for a little more drift ... when the US hone datacenters were
consolidated into a single center in the bayarea in the late 70s ...
possibly the largest single-system cluster anywhere (at the time) was
created. a variation of the performance predictor was used to monitor
real time activity of all the members of the cluster and when a new
branch office (or other sales, marketing or field) person initiated a
login, the overall view of the cluster was used to decide which machine
the user actually logged into (aka providing both availability and
load-balancing at log-in)
http://www.garlic.com/~lynn/subtopic.html#hone

In the 70s, the base system didn't have process migration between
different processors in a cluster (once logged on).

Note, however, one of the time-sharing service bureaus using the same
(cp/cms) platform, had done such a enhancement in the mid-70s ...
http://www.garlic.com/~lynn/subtopic.html#timeshare

this particular service bureau had moved to 7x24 operation with
customers world-wide ... and so there was no period where the system was
totally idle and could be taken down for service. When a member of their
(mainframe) cluster configuration needed to be taken offline for service
or preventive maintenance ... it was possible to migrate all active
processes off the piece of hardware (to other members in the cluster,
transparently to the end user), and take the hardware offline.

they had datacenter near boston and another in san francisco and claimed
to be able to do transparent process migration between datacenters (as
well as between members of the cluster within a datacenter) ... modulo
having replicated data at the two centers.

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Tue, 11 Apr 2006 14:12:46 -0600

Ken Johanson writes:

"potentially" seem really vague to me the way you use it. The fact is,
very few fields are actually required by CAs -- and the ones that are
required are the ones needed to establish the identity being claimed
(given name, location, email) (to distinguish one John Doe from
another), and also the endorser cert / chain.

ref:
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh

the issue in the early 90s with x.509 identity certificate standard
... appeared to be that personal information in a certificate seemed
to be a valuable business niche for certificates ... and some of the
emerging things called certification authorities ...  which were out
to sell these x.509 identity certificates started down the road that
the more personal information included, the greater the value of the
certificate (and the implication that they could charge more).

that trend somewhat created the realization in a number of
institutions, that certificates, grossly overeloaded with personal
information, gave rise to significant privacy and liability issues
... and contributed to the appearance of the relying-party-only
certificates in the mid-90s.
http://www.garlic.com/~lynn/subpubkey.html#rpo

the original x.509 identity certificate paradigm seem to assume a
total anarchy where the x.509 identity certificate would be used for
initial introduction (like the letters of credit/introduction example)
between totally random strangers. as such, the respective entities as
individual