List of Archived Posts

2006 Newsgroup Postings (05/01 - 05/13)

The Pankian Metaphor

Sarbanes-Oxley

The Pankian Metaphor

Spoofing fingerprint scanners - NEWBIE()

Mainframe vs. xSeries

Transition of platforms in british education

The Pankian Metaphor

Transition of platforms in british education

Heating

Hadware Support for Protection Bits: what does it really mean?

Hadware Support for Protection Bits: what does it really mean?

Google is full

Mainframe near history (IBM 3380 and 3880 docs)

Multi-layered PKI implementation

Value of an old IBM PS/2 CL57 SX Laptop

rexx or other macro processor on z/os?

blast from the past on reliable communication

blast from the past on reliable communication

blast from the past on reliable communication

blast from the past on reliable communication

blast from the past on reliable communication

blast from the past on reliable communication

virtual memory

Virtual memory implementation in S/370

Virtual memory implementation in S/370

Benefits of PKI - 5,000 nodes organization

11may76, 30 years, (re-)release of resource manager

Really BIG disk platters?

virtual memory

Which entry of the routing table was selected?

virtual memory

virtual memory

virtual memory

virtual memory

TOD clock discussion

TOD clock discussion

virtual memory

virtual memory

virtual memory

virtual memory

virtual memory

virtual memory

virtual memory

virtual memory

The Pankian Metaphor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.folklore.computers
Date: Mon, 01 May 2006 08:49:50 -0600

jmfbahciv writes:

How was that done?  Was there a preprocessor that pretended to
execute the control file and logged all devices needed?  How did
this determine core usage?

trivial preprocessor would open some number of default files with some
amount of default allocation ... and then hope that most applications
would never exceed the default ... somewhat like a lot of desktop
applications. lots of the "system monitors" from the period
implemented that sort of paradigm for one reason or another. A fairly
representative case that is still around is CICS that provides support
for "light-weight" transaction subsystem environment. Most CICS
light-weight stuff only require a trivial amount of system resources
(much more akin to many interactive commands in other kinds of
interactive systems). CICS acquires a large block of system resources
and then manages them internally for light-weight transaction
operation (w/o having to go thru the normal system resource management
processes for every light-weight transaction).

part of all this was starting way back in the days of real storage
paradigm and much less resources. major applications could require
both tapes as well as disks to be mounted on drives ... potentially
all available drives (nearly all available resources). with PCP (no
multiprogrammer) ... there was the real storage not required by the
system, application either fit or it didn't.

later MFT & MVT supported multi-programming. regions with max amount
of allocated real storage was defined. "jobs" had max real storage
requirement which then mapped to a job "class" that would feed to
processing "region" that allowed at least that amount of real storage.

the "x37" processing aborts (abends) were when resources ran
out. default was to take default system termination. however,
applications could set up traps for nearly every kind of abort
and attempt remedial action.

this was more typical for service oriented applications that provided
online support ... and had application specific programming for
recovery from numerous kinds of anomolous operation ... as part of
providing availability. other events were things that had specific
deadlines and requirements to be run ... say like periodic payroll for
large organization ... where tens or hundreds of thousands (or even
millions) of people were expecting to be paid on specific date.

a typical payroll application might have various kinds of processing
plus a sort phase before printing checks. a mission critical
application might have a B37 abort trap provided (exhaust all
available disk space). The B37 trap might do things like invoke system
backup/archive/removal of non-critical files (i.e. the files would
still be listed in system directory but have been moved to some other
media). Then the B37 trap would restart processing in attempting to
complete.

ten years ago, i did a comparison of moving such an application to a
platform that had much less mission-critical derived infrastructure.
put in into regular use ... but one run happened to exhaust available
disk space (ran into disk full condition) during sort processing. the
system file processing reflected end-of-file to sort ... which then
continued processing using abbreviated set of entries. The final
result had a file listing only about ten percent of the total people
... but completed w/o any obvious error condition.

... a little drift about CICS subsystem monitor. it had been developed
at a customer site in the midwest (possibly utility company or some
such). IBM decided to turn it into standard product offering. A few
customers were selected to "beta-test" the product before general
availability. One was the university library that had a ONR grant to
do an online "card" catalog. As a result, one of the other things I
got to work on as an undergraduate was debugging various early CICS
problems (primarily related to the library attempting to define
CICS configruation & use that hadn't been done before). misc.
past posts mentioning CICS:
http://www.garlic.com/~lynn/94.html#33 short CICS story
http://www.garlic.com/~lynn/97.html#30 How is CICS pronounced?
http://www.garlic.com/~lynn/98.html#33 ... cics ... from posting from another list
http://www.garlic.com/~lynn/99.html#58 When did IBM go object only
http://www.garlic.com/~lynn/99.html#130 early hardware
http://www.garlic.com/~lynn/99.html#218 Mainframe acronyms: how do you pronounce them?
http://www.garlic.com/~lynn/2000b.html#41 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#35 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000c.html#45 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#52 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#54 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#62 California DMV
http://www.garlic.com/~lynn/2001d.html#56 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001g.html#24 XML: No More CICS?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
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/2001i.html#49 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#24 Parity - why even or odd (was Re: Load Locked
http://www.garlic.com/~lynn/2001j.html#25 Parity - why even or odd (was Re: Load Locked
http://www.garlic.com/~lynn/2001k.html#51 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2001l.html#43 QTAM (was: MVS History)
http://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
http://www.garlic.com/~lynn/2001n.html#0 TSS/360
http://www.garlic.com/~lynn/2001n.html#11 OCO
http://www.garlic.com/~lynn/2001n.html#36 Movies with source code (was Re: Movies with DEC minis)
http://www.garlic.com/~lynn/2001n.html#62 The demise of compaq
http://www.garlic.com/~lynn/2002.html#1 The demise of compaq
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#45 VM and/or Linux under OS/390?????
http://www.garlic.com/~lynn/2002d.html#19 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002e.html#62 Computers in Science Fiction
http://www.garlic.com/~lynn/2002g.html#78 Is it safe to use social securty number as intranet username?
http://www.garlic.com/~lynn/2002h.html#63 Sizing the application
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2002i.html#11 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#50 SHARE Planning
http://www.garlic.com/~lynn/2002j.html#53 SHARE Planning
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#68 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2003.html#13 FlexEs and IVSK instruction
http://www.garlic.com/~lynn/2003e.html#69 Gartner Office Information Systems 6/2/89
http://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
http://www.garlic.com/~lynn/2003j.html#68 Transactions for Industrial Strength Programming
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003l.html#9 how long does (or did) it take to boot a timesharing system?
http://www.garlic.com/~lynn/2003n.html#29 Architect Mainframe system - books/guidenance
http://www.garlic.com/~lynn/2003p.html#23 1960s images of IBM 360 mainframes
http://www.garlic.com/~lynn/2004.html#7 Dyadic
http://www.garlic.com/~lynn/2004.html#51 Mainframe not a good architecture for interactive workloads
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/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004g.html#54 effeciently resetting a block of memory
http://www.garlic.com/~lynn/2004m.html#40 Result of STCK instruction - GMT or local?
http://www.garlic.com/~lynn/2004m.html#61 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#0 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#5 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#9 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#16 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#4 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#5 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#15 Amusing acronym
http://www.garlic.com/~lynn/2005d.html#22 Latest news about mainframe
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005m.html#9 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#44 TLAs - was summit else entirely
http://www.garlic.com/~lynn/2005o.html#45 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005s.html#26 IEH/IEB/... names?
http://www.garlic.com/~lynn/2006c.html#0 Multiple address spaces
http://www.garlic.com/~lynn/2006f.html#22 A very basic question

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

Sarbanes-Oxley

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Sarbanes-Oxley
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 01 May 2006 09:49:27 -0600

Chris Mason wrote:

How about passing laws which allow scrutiny of an enterprise's operation
much more easily that is currently allowed? That could so increase the
deterrent effect that less law-breaking resulted. So by passing such laws
some of "them" will be stopped. Historically over the twentieth century,
isn't this what has happened?

my claim
http://www.garlic.com/~lynn/2006.html#12a sox, auditing, finding improprieties
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#58 Sarvanes-Oxley

was that much of the audit paradigm is looking for inconsistencies ...
and that if the auditor is only looking at information coming from a
single source .... say the corporate IT operation ... then a
reasonably intelligent fraud operation can leverage the IT operation
to guarantee that all the information looked at by the auditors is
consistent.

frequently, a basic security premise is multiple independent
operations.  Corporate IT operation can collapse everything into a
single operation/source ... which can be leveraged to invalidate basic
auditing assumptions.  MORE of the same stuff from the same source
... isn't going to create multiple, independent information sources
(corporate IT operation can be leveraged to generate as much
consistent stuff as needed).

there has been some claims that this inherit flaw in the current
auditing operations is somewhat implicitly recognized ... and that is
why sarbanes-oxley also has the section on informants (hoping that
other sources of information will come forward that can highlight
inconsistencies via other means).

any implicit assumption about independent information sources as part
of auditing paradigm (looking for inconsistencies) ... might also
imply that audit would have to find other methods of coming up with
independent information sources. for instance if one corporation lists
operations with another corporation ... that the information from all
corporations involved in such interactions might need to be validated
for consistency. however, that somewhat is a change to the current
auditing paradigm.

The Pankian Metaphor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.folklore.computers
Date: Mon, 01 May 2006 12:55:54 -0600

jmfbahciv writes:

This was always an incorrect assumption.  We considered operators
to be human.

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

operators were humans that did a certain set of operations with
respect to application execution .... but it was very structured
subset ... since they weren't actually the humans directly responsible
and/or necessarily really familiar with the application.  with limited
storage space ... the operators definitly were used to mount tapes and
disks on the limited number of drives (i.e. there were significantly
larger number of application tape reels and disk packs than there were
drives).

i've often commented that one of the transitions for time-sharing
services to 7x24 operations in the late 60s and early 70s was
automating numerous operator functions ... and running the machine
room "lights out" for 3rd and 4th shifts.
http://www.garlic.com/~lynn/submain.html#timeshare

also, several years ago, the person running a major financial
processing operation commented that the two major things responsible
for 100percent availability over the previous several years were

• ims hot-standby
• automated operator

as hardware and software reliability has improved ... the major
remaining source of faults were human (operator) mistakes and physical
infrastructure failures and natural disasters. the ims hot-standby
allowed them to have replicated operation at three geographically
separated sites.

when my wife had been con'ed into doing a stint in POK in charge of
loosely-coupled architecture ... she had developed peer-coupled
shared data architecture. there wasn't a lot of initial uptake until
the ims hot-standby work and then later parallel sysplex stuff.
http://www.garlic.com/~lynn/submain.html#shareddata

later when we were doing the high availability product (ha/cmp)
http://www.garlic.com/~lynn/subtopic.html#hacmp

we had coined the terms disaster survivability and geographic
survivability to differentiate from disaster/recovery.

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

Spoofing fingerprint scanners - NEWBIE()

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Spoofing fingerprint scanners  - NEWBIE()
Newsgroups: comp.security.misc
Date: Mon, 01 May 2006 13:25:48 -0600

Sebastian Gottschalk writes:

Not actually. It's neither a reliable or efficient improvement over one
factor authentication and clearly doesn't reach two factor ~. Especially
due to error rates.

But "eye" is a good keyword. Iris scanning actually fulfills the
something you are factor mantra.

some number of atm operators have been looking at both fingerprint
scanning and iris scanning, in place of PIN for two-factor
authentication.

from three-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

PIN is a shared-secret something you know in conjunction with the
card something you have.
http://www.garlic.com/~lynn/subintegrity.html#secret

the issue is that shared-secret something you know
paradigm has been grossly overworked/over-stressed ... as a result
there are some statistics that at least 1/3rd of debit cards have PINs
written on them. there is assumption with multi-factor authentication
regarding whether they are subject to independent vulnerabilities and
exploits. obviously writting PIN on the card defeats any assumptions
about multi-factor independent vulnerability related to lost/stolen
card.

the argument allowing a user to choose fingerprint (something you
are) in lieu of PIN (something you know) authentication ... is
whether it easier for a crook with a lost/stolen card to "lift" a PIN
written on the card and replay the PIN at a terminal ... vis-a-vis
"lifting" some possible fingerprint on the card and replay the
fingerprint at a terminal (even allowing a customer to choose a finger
that is least likely to have been used in handling their card).

misc. past posts mentioning fingerprint vulnerability vis-a-vis
debit cards that have PIN written on them:
http://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#167 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio2 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm19.htm#5 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/2002g.html#72 Biometrics not yet good enough?
http://www.garlic.com/~lynn/2002h.html#6 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#8 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002o.html#62 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002o.html#63 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002o.html#64 smartcard+fingerprint
http://www.garlic.com/~lynn/2002o.html#65 smartcard+fingerprint
http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
http://www.garlic.com/~lynn/2003o.html#44 Biometrics
http://www.garlic.com/~lynn/2005g.html#54 Security via hardware?
http://www.garlic.com/~lynn/2005i.html#22 technical question about fingerprint usbkey
http://www.garlic.com/~lynn/2005i.html#25 technical question about fingerprint usbkey
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005o.html#1 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005p.html#2 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#21 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

other past posts about skimming exploits of magstripe plus PIN (or any
other relatively static authentication data that can be subject to
replay attack) ... also invalidating any assumptions about
multi-factor authentication independent vulnerabilities/exploits/threats
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
http://www.garlic.com/~lynn/aadsm19.htm#5 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#20 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#29 Meccano Trojans coming to a desktop near you
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/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naïve use of TLS and/or tokens
http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004j.html#44 Methods of payment
http://www.garlic.com/~lynn/2005o.html#17 Smart Cards?
http://www.garlic.com/~lynn/2005p.html#2 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005q.html#11 Securing Private Key
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
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#30 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006g.html#38 Why are smart cards so dumb?
http://www.garlic.com/~lynn/2006h.html#13 Security
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor

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

Mainframe vs. xSeries

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe vs. xSeries
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 02 May 2006 11:42:11 -0600

Steve O'Hara-Smith writes:

Perhaps an effect similar to the one that happened at
Cambridge, the Titan was heavily secured and attempting to crack it
was encouraged to the extent that success was something to openly
boast about (and probably got you a job with a first task to close
the hole you used and the entire family of related holes). Later the
Titan was replaced by a 370 and cracking it was laughably easy -
word went out that cracking the 370 was not considered clever (look
in these places for well known techniques) and anyone caught trying
it was apt to lose all access privileges.

Result very few people attempted to crack the 370 mainly
because it was too easy and documented and therefore no challenge
(although pretty much every user had some of the useful libraries of
tools that depended on walking through the security mechanisms as
though they weren't there - but these tools were reliable and didn't
risk crashing the system).

misc. historical references of titan & cambridge univ.
http://www.cl.cam.ac.uk/Relics/chron.html
http://www.cl.cam.ac.uk/UoCCL/misc/EDSAC99/history.html
http://www.cs.man.ac.uk/CCS/res/res22.htm

it was a 370/165 installed in 1971 (pre 370 virtual memory).

following has early 70s time-line (at the end of the post)
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flused on a page fault?

retrofitting virtual memory hardware to 165 ... to turn it into 165-II,
cost a couple hundred thousand.

the cambridge references somewhat mentions difficulty in using
(card-punch) JCL and/or "TSO" ... which appears to be motivating
factor in the university developing the "phoenix command language".

something similar might be said of Stanford Univ. with Orville and
Wylbur ... minor reference:
http://www-db.stanford.edu/pub/voy/museum/pictures/IBM.html
http://www.stanford.edu/dept/its/communications/history/mainframe/timeline.html

os/360 (or its 370 descendents) weren't particularlly noted for
integrity infrastructures. in fact, hasp for much of its early
life
http://www.garlic.com/~lynn/submain.html#hasp

was started as a normal application, "took over" the interrupt vector
and intercepted all the interrupts to filter the stuff it was
emulating. part of the issue was that most batch operations were
closed operations and the "online" operations tended to be
applications that provided only limited and very controlled
feature/function.

by comparison, Univ. of Mich. had done MTS (michigan terminal system)
utilizing virtual memory on 360/67 ... and then ported to 370 when 370
virtual memory feature became available.

also, there were the commercial time-sharing services using cp67/cms
(on 360/67) later moved to virtual memory 370s
http://www.garlic.com/~lynn/submain.html#timeshare

which required a very high level of privilege isolation and
protection. similarly, the "cambridge" science center
http://www.garlic.com/~lynn/subtopic.html#545tech

provided online access to various internal corporate operations
(including corporate hdqtrs business planning that used the system to
analyze the most sensitive of corporate information) as well as
providing online access to various professors and students in the
boston area (aka the other cambridge).

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

Transition of platforms in british education

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Transition of platforms in british education
Newsgroups: alt.folklore.computers
Date: Tue, 02 May 2006 21:48:20 -0600

CBFalconer writes:

No need for an antique house for that.  Just be a child of the
depression, and be used to using blankets, cats, etc. in winter.
The first step in the morning is to hop from chair to chair to the
kitchen, and start a fire in the wood stove.  Prop up the oven door
and sit on that until things take hold.  You also learn to leave
the water running.  Windows are opaque from December through March.

wasn't depression just rural ... late 50s. house was heated by wood
stove and one of my jobs was to keep the wood bin filled and also get
up at 5.30am and restart the fire (i had an after school job ... so i
would typically chop/saw wood after dinner for an hour or two).

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

The Pankian Metaphor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.folklore.computers
Date: Wed, 03 May 2006 10:30:59 -0600

jmfbahciv writes:

Did you use any kind of programming to study this stuff?  Note:
I know I know nothing about this and have no idea what questions
to ask and probably won't understand the answers.

re:
http://www.garlic.com/~lynn/2006i.html#2 The Pankian Metaphor
http://www.garlic.com/~lynn/subtopic.html#hacmp

lots of hard work and experience. one of the things done was detailed
vulernability analysis of tcp/ip ... looking both at standards
documents (RFCs) and code examination.

for a little drift ... see my IETF RFC index
http://www.garlic.com/~lynn/rfcietff.htm

identified several operational things ... i.e. not coding bugs ...
design/implementation problems that could result in live operational
failures.

having studied both standards and code from the standpoint of detailed
vulnerability analysis help later ... story about problem that
the largest (at the time) online service provider was experiencing:
http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"

part of the experience was having developed an online failure
diagnostic tool in the early 80s
http://www.garlic.com/~lynn/submain.html#dumprx

that attempted to also build a library of failure signatures that
could be automatically scanned for (as part of the diagnostic
process).  this also evolved into looking for common failure features
and/or characteristics for grouping types of failures. this was widely
deployed thru-out the corporation ... both for internal datacenters
and people responsible for shooting customer problems.

also part of the experience as based on having redone the
I/O supervisor for the disk engineering and product test
labs in bldg. 14 & 15
http://www.garlic.com/~lynn/subtopic.html#disk

they had development hardware that operated in very strange ways and
potentially generated more errors in a few minutes that normal
production devices would generate in a year. it was a very operating
system hostile environment. attempts at using a standard MVS system in
that environment resulting in 15 minute MTBF testing just a single
development device. I had to completely rethink the whole operating
system approach with assumption that it was operating in an extremely
hostile environment ... and eventually produced a bullet-proof
operating system where they could concurrently test half-dozen or more
development devices.

also in that time-frame we were enhancing the HONE time-sharing
service (internal time-sharing services that provided world-wide
support for all corporate marketing, sales, and field people).  all
the US hone datacenters had been consolidated in northen cal.  in the
mid-70s (and there were alos a growing number of cloned datacenters
world-wide).
http://www.garlic.com/~lynn/subtopic.html#hone

there was a lot of work that went into attempting to make the HONE
service continuous. After a couple years, because of evironmental
concerns (earthquakes), the US HONE center was replicated first in
Dallas (and then a 3rd in boulder) with fall-over and load-balancing
across the distributed centers.

in the same period, there was similar work on high availability by
various other corporations providing commercial time-sharing services
using the same platform
http://www.garlic.com/~lynn/submain.html#timeshare

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

Transition of platforms in british education

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Transition of platforms in british education
Newsgroups: alt.folklore.computers
Date: Wed, 03 May 2006 14:39:47 -0600

Anne & Lynn Wheeler writes:

wasn't depression just rural ... late 50s. house was heated by wood
stove and one of my jobs was to keep the wood bin filled and also get
up at 5.30am and restart the fire (i had an after school job ... so i
would typically chop/saw wood after dinner for an hour or two).

this post somewhat jogged my memory ... i remember the wood stove
brand was siegler. slightly smaller than present day kitchen range.
external was light weight brown tin metal with interior air space
between the outer covering and the actual stove ... reduced being
burned touching the stove. it was fed/loaded from the side.

i have some vague recollection of siegler stove advertisements from
the 50s with some jingle.

i tried search engine on siegler ... came up with antigue siegler wood
stoves, as well as some number of kitchen stoves and oil burning
stoves. so far haven't found anything that looks like siegler wood
stove from the 40s or 50s.

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

Heating

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Heating
Newsgroups: alt.folklore.computers
Date: Wed, 03 May 2006 16:57:57 -0600

CBFalconer writes:

Having moved recently I now have a well insulated home.  I heated it
this winter (unusually mild) on about 2 cords [1] of wood in a small
airtight stove.  When I wished I could let the furnace and
thermostat take over.  That used about 75 gallons [2] of kerosene.

i remember as a kid that we got a lot of stuff that was effectively
tree trunks cut to stove length ... but not split (although old enuf
so that it was dry ... no longer green) it was delivered by dump trunk
in a big pile. I had to use sledge and wedges to split the trunk
pieces into (typically) thirds or quarters. then i could use an axe to
split into even smaller pieces for the stove. I also got some number
of smaller tree limbs that I cut to length and then split. mostly pine
and had a lot of chimney crud (some amount of chimney cleaning and had
to be really careful about chimney fires).

1950s stuff ... house hardly insulated and, as previous post
mentioned, siegler wood stove. went through several cords in a winter
(although at the moment I don't recollect typical number).

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

Hadware Support for Protection Bits: what does it really mean?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hadware Support for Protection Bits: what does it really mean?
Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips,alt.os.development,fa.linux.kernel
Date: Wed, 03 May 2006 19:18:00 -0600

"Maxim S. Shatskih" writes:

Setting the dirty bits on DMA is usually the OS's task.

the changed and reference bits are properties of the physical instance
of the page.

in the original 360 "key" structure ... cp67 emulated cms protected
shared pages by fiddling the storage protect keys (part of the
original 360 architecture) ... where the current executing state is
carried by the PSW (program status word) which could include a "key"
state. each storage area could have an associated key value. for a
storage to occur the PSW (application execution) key value had to
match the storage key value in order for a storage operation to
complete (aka not only did storage areas have reference and change
state ... but each storage area could also have store and optionally
fetch protection ... which also had to be checked on each instruction
operation). the supervisor could disable store (& optional fetch)
protection by setting the PSW key value to zero (for privilege
kernel/supervisor code).

so certain CMS virtual memory pages were defined as shared. the cp67
kernel ... behind the scenes fiddled both the non-shared and shared
page protection keys as well as fiddling the PSW for CMS execution ...
so that all stores to protected shared pages would fail.

along comes 370 ... and in the original 370 virtual memory
architecture, a shared segment protection feature was defined.  for
the morph of cp67/cms (from 360/67) to vm370/cms (370), the cms layout
structure was re-organized so all "shared" pages were located in a 370
segment that could be defined as shared across multiple address spaces
... and in each virtual address space table entry ... the segment
protect bit was turned on (preventing all instruction executing in
those virtual memories from being able to store in that segment range
of virtual addresses).

at that time, there was going to still be the "key" based storage
protection (inherited from 360), the page change and reference state
bits as well as the new 370 virtual memory storage protect mechanism.

some amount of past posts mentioning storage protect operations:
http://www.garlic.com/~lynn/93.html#18 location 50
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/99.html#94 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/2000c.html#18 IBM 1460
http://www.garlic.com/~lynn/2002q.html#31 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2003m.html#15 IEFBR14 Problems
http://www.garlic.com/~lynn/2004c.html#33 separate MMU chips
http://www.garlic.com/~lynn/2004h.html#0 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004q.html#82 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#84 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#0 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005h.html#17 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries

so several models are chugging along with their hardware
implementations. the 370/165 engineers then raise an issue ...  they
are something like six months behind schedule designing and building
the 165 virtual machine hardware retrofit (370/165s were initially
shipped w/o virtual memory capability). we have an escalation meeting
with architecture and various groups in POK. the 370/165 engineers
claim that they can make up the six months if they can drop several of
the 370 virtual memory features from the implementation (which also
means that all of the other 370 models that have already implemeted
the features will need to remove them from their implementations).  it
was eventually decided to go with dropping the features so 370/165
engineers can gain back six months.

one of the features that had to be dropped from the original 370
virtual memory architecture was the original virtual memory segment
protection. that created a problem for CMS ... since the whole CMS
shared page memory protect had been rebuilt around have segment
protection (i.e. lots of different applications could share exact
duplicate physical image of a page w/o fear that one application would
trounce on it and impact applications running in other virtual memory
... i.e. virtual memory was being used for partitioning and
isolation).

so, vm370/cms group was forced then to retrofit the key-based storage
protection hack that was used in cp67/cms to vm370/cms shared segment
protection.

we go forward a couple years. several of the 370 models come out with
instruction microcode performance assists for vm370/cms operation.
one of the instruction assisted is the PSW and storage key management
instructions. however, the assist rules don't have provisions for the
fiddling done to the PSW and storage keys by the original hack from
CP67 (i.e. if cms applications were to be run with the hardware
performance assists they would loose protection of their shared
pages).

somebody comes up with a bright idea. at that moment, vm370/cms
environments were only single processor machines and cms only had only
defined 16 shared pages. the idea was that cms applications would be
run with the hardware performance assist (with storage protection
actually disabled). then everytime before the underlying kernel did a
task switch from one virtual address to a different virtual address,
the dispatcher would scan the shared cms pages (that previously had
been storage protected) for the change bit. any time such a
"protected" shared page was found to be dirty/changed ... the physical
copy was flushed and the PTE was marked invalid. The switched-to
address space would never see any changes made by an application
running in a different address space. The pages were no longer
actually physically protected from stores ... however, the scope of
any such stores was very limited.

so about the time they were ready to ship this bright new idea ... cms
added support for greatly increasing the number of shared pages.  the
original idea was the overhead of scanning the dirty bits on 16 shared
pages on every task switch was less than the performance improvement
gained by using the microcode hardware assist. The problem was that by
the time the support shipped, there was always a minium of 32 shared
pages to scan (and frequently a large number more) and the trade-off
was no longer valide.

the other problem was adding support for multiprocessing. the original
bright idea was based on the fact that while the application was
running, it basically had exclusive control and use of the pages.
with multiprocessor support, that was no longer true, there was
potentially concurrent access to shared pages by equivalent of one
application for each processor. so the bright idea had to be fiddled,
as part of multiprocessor support, a unique set of shared pages were
defined for each processor. now as part of doing a task switch, the
dispatcher had to scan the shared pages from the previous task looking
for modifications (and then flushing and invalidating as needed). in
addition, the dispatcher now had to fiddle the virtual memory tables
to the new, switched-to task ... so its virtual memory tables were
point to the set of shared pages that were specific to the real
processor that the task was being dispatched on.

of course, eventually sharing protection re-appeared as part of
the architecture implementation shipped to customers.

misc. past posts on the whole gengre of the shared page fiddling (and
emulating storage protection by scanning for changed pages and
discarding the changed image ... forcing the page having to be
refreshed from disk)
http://www.garlic.com/~lynn/2000.html#59 Multithreading underlies new development paradigm
http://www.garlic.com/~lynn/2003d.html#53 Reviving Multics
http://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why?
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#9 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005o.html#10 Virtual memory and memory protection
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past

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

Hadware Support for Protection Bits: what does it really mean?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hadware Support for Protection Bits: what does it really mean?
Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips,alt.os.development,fa.linux.kernel
Date: Wed, 03 May 2006 19:37:16 -0600

"Maxim S. Shatskih" writes:

Setting the dirty bits on DMA is usually the OS's task.

so there is also a separate issue with cp67 and vm370 providing
emulated virtual machines.

there are the real storage changed and reference bits associated
with the real physical page.

the real kernel uses the real storage changed bits to determine
whether the physical instance in real memory is the same or different
than the image on disk. when the virtual copy is brought in from disk,
the real change bits are set to zero indicating that the copy hasn't
been changed since reading from disk. subsequently the application or
i/o operations may alter the virtual copy in real memory ... which
means that it is no longer the same as the copy on disk.

now there is a problem with simulating a virtual machine environment.
the pages in the virtual machine address space have changed and
referenced bits managed by the kernel running in the virtual machine.
the virtual machine kernel may read a virtual page of its disk into a
page ... which changes the real instance of the page with respect to
the real kernel. the kernel in the virtual machine will then clear its
version of the change (& reference) bit to zero (indicating that the
copy in storage is the same as the copy on its disk).

similarly, the real kernel may remove a virtual machine page from real
memory to disk. when it brings that virtual machine page back into
real memory, it will reset the changed (and reference) bits indicating
that the virtual page in storage is still the same as the copy on the
real kernel's page disk.

we have one set of real changed and reference bits ... but two
different kernels attempting to use them for tracking state about two
different things (whether there has been a change from the copy on the
virtual kernels paging disk as well as whether there has been a change
from the copy on the real kernels paging disk).

so the real kernel maintains two sets of "shadow" changed and
reference bits, one set for the virtual machine kernel and one set for
the real machine kernel. whenever the real kernel changes the real
changed and reference bits ... the values for the real page are OR'ed
with the value in the virtual machine kernel shadow bits, the real
changed and reference bits are cleared to zero ... and the desired
value is assigned to the real kernel's shadow bits.

whenever the virtual machine kernel changes a page's reference and
change bits ... the values are OR'ed with the value in the real
machine kernel shadow bits, the real change and reference bits are
cleared to zero ... and the desired value is assigned to the virtual
machine kernel's shadow bits.

whenever either kernel interrogates changed & reference bits ... it
does it first by first OR'ing the values for the real page with its
shadow bits maintained for that particular kernel.

In effect, only an virtual application instruction explicit store
alteration event is used to turn on the real dirty/changed bits
(occuring when the instruction modifies something in the range of
storage). Administrative management of the bits then never turn on the
bits ... it ONLY zeros the real bits (after first integregating and
OR'ing the bits as appropriate with the appropriate software maintained
shadow bits).

some past posts discussing management of shadow change & reference
bits as part of virtual machine emulation:
http://www.garlic.com/~lynn/95.html#2 Why is there only VM/370?
http://www.garlic.com/~lynn/2005h.html#17 Exceptions at basic block boundaries

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

Google is full

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Google is full
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 04 May 2006 08:51:21 -0600

Phil Payne wrote:

OK - here's another link -
http://www.theregister.co.uk/2006/05/04/google_bigdaddy_chaos/

It seems that everyone insists on reinventing wheels.  Apart from
anything else, this is a classic capacity planning failure.  I wonder
what would happen to any zSeries capacity planner whose work was so
bad that the CEO had to apologise in the New York Times?

Google might have gotten lots of cheap MIPS on its distributed
platforms, but it obviously didn't get the scalability it requires and
now it has a computing system that can't keep up with its business
plan.  When was the last time this happened to a zSeries user?
Scalability?  I think that's one of the boxes zSeries can tick.

i was at presentation several months ago about some of the google
activity. one claim was that they had reduced the cost of supercomputer
by at least 2/3rds. this is a supercomputer defined as a GRID-type
operation with lots and lots of MIPS and DISK packed into small space.
They had fined tuned the packaging and construction and were able to do
it for 1/3rd the cost that you would normally pay for racks & racks of
densely packed processors and disk drives (tens of thousands of each)

i've always seen a fairly high percentage of hits on our garlic web
pages from search engines  ... as well as other sources ... eserver
magazine even did article on our garlic web pages last year
http://www.ibmsystemsmag.com/mainframe/marchapril05/stoprun/10020p1.aspx

more recently somebody in comp.arch commented on the subject of "garlic"
coming up in dog&pony show at almaden
http://www.garlic.com/~lynn/2006h.html#35 64-bit architectures & 32-bit insturctions

I've even noticed that the rate of google hits seemed to have doubled
over the past several months. I've somewhat suspected that the search
engines were using our garlic pages as test cases because of the
extremely high proportion of hrefs. the ietf rfc index
http://www.garlic.com/~lynn/rfcietff.htm

and the merged taxonomies and glossaries html files
http://www.garlic.com/~lynn/index.html#glosnote

are extremely dense with hrefs (primarily because the information is
maintained in a very complex knowledge base and the html files are
generated by an application).

Mainframe near history (IBM 3380 and 3880 docs)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe near history (IBM 3380 and 3880 docs)
Newsgroups: bit.listserv.ibm-main,comp.sys.unisys,comp.lang.asm370,comp.sys.ibm.sys3x.misc,alt.folklore.computers
Date: Thu, 04 May 2006 20:07:35 -0600

Chuck Stevens wrote:

The US Veterans Administration Data Processing Center in Austin, Texas had
*at least* three -- maybe at one point five -- of these beasts (one on a
360/40, two on a 360/65, maybe two more at one point on a 360/50)..

the university i was at had 2321 attached to 360/67 (that ran as 360/65
most of the time). The univ. library had gotten an ONR grant to work on
stuff like online library card catalog. the project also got selected to
be beta-test site for cics. i remember getting to shoot some early cics
bugs ... including a bdam open bug (site where cics had been developed
appeared to have been using bdam in very specific way ... and the
library chose to use different set of bdam features).

the sounds of 2321 at boot/ipl was something like whirl, kerchunk,
kerchunk, whirl, .... as it went thru reading volsers.

remember that in the BBCCHHR DASD addressing ... the "BB" were for the
2321 bin number.

Multi-layered PKI implementation

From: lynn@garlic.com
Newsgroups: linux.debian.user
Subject: Re: Multi-layered PKI implementation
Date: Sun, 07 May 2006 11:45:04 -0700

James Westby wrote:

In a slighty simplified view of X.509 each party has a certificate
stating who they are, and they have a key that ties them to it. They
then have a Certificate Authority sign this certificate after a
process of verifying the information. They can then present this
certificate to anybody, no matter whether they have ever had any
contact with them before, and that person can verify the identity of
the first person by checking the signature of the CA on the
certificate. This then moves the trust from the person presenting
the certificate to the CA.

verifying a digital signature with a public key is a form of
something you have authentication ... aka it assumes that the entity
has access and use of the respective private key.

in the straight-forward implementations, the public key is registered
with the relying party in lieu of a password (i.e. the public key is
used to verify a digital signature for something you have
authentication, instead of matching a supplied password for something
you know authentication). this could be kerberos where public key is
registered instead of a password
http://www.garlic.com/~lynn/subpubkey.html#kerberos
or radius
http://www.garlic.com/~lynn/subpubkey.html#radius

credentials, certificates, licenses, diplomas, letters of credit,
letters of introduction, etc. has been used for centuries in the
offline world for relying parties who had no other mechanism for
determining the validiting of some information.

digital certificates (and PKI) are electronic analogy for providing
some equivalent mechanism for an electronic, offline world ... where
the relying party has no prior information and/or any means for
determining information about some new stranger they will be dealing
with.

the relying party as a local table of public keys belonging to
certification authorities in order to authenticate communication from
these entities called certification authorities. the certification
authorities provide something called digital certificates (which the
relying party authenticates by validating the digital signatures using
a public key from the relying party's table of trusted public keys).
these digital certificates typically contain information about some
other party "bound" to their public key. the relying party, when
dealing with total strangers (where the relying party has no prior
knowledge about the stranger and/or has any online capability for
obtaining information about the stranger) will use the information in
attached digital certificates to obtain information about the
stranger.

a stranger sends you some digitally signed communication with an
attached digital certificate. you authenticate the digital certificate
by verifying the certification authorities digital signature (from you
table of trusted public keys). you then take the stanger's public key
from the appended digital certificate to authenticate the
communication (by verifying the digital signature with the supplied
public key from the appended digital certificate).

the relying party then can take the remaining certified information
from the appended digital certificate for making decisions about
authorization, permissions, etc. i.e. the purpose of PKI,
certification authorities and digital certificates is so a relying
party can make decisions about how to treat first-time communication
from a total stranger, purely based on information from the appended
digital certificate.

 A simple certification authority PKI is already providing a single
level of trust indirection, the relying party has the public keys of
the certification authorities it already trusts (in the relying
party's repository of trusted public keys), and the relying party uses
those public keys to validate & authenticate digital certificates from
the certification auhority. then the relying party uses the certified
information from digital certificate to decide on how to deal with
complete stranger (decide on permissions and/or authorizations).

It is then a fairly simple step to go from one-level trust indirection
to a hierarchy of certification authorities ... where the
certification authority "trusted" by the relying party digitally
certifiies a digital certificate telling the relying party to accept
digital certificates issued by another "stranger" certification
authority (the trusted certification authority effectively instructs
the relying party to treat "stranger" certification authorities as
authorized ... i.e.  accept their digital certificates).

basically the premise is that the relying party makes their decisions
about permissions, privileges, authorizations, etc ... based on the
information in the digital certificate i.e. the primary purpose of the
digital certificate isn't to authenticate ... but to convey
information about stangers that allows a relying party to make
decisions about permissions and privileges w/o resorting to, or
requiring any other resources. A simple PKI is a one level hierarchy
of digital certificate permissions. A N-level PKI hierarchy is
basically a N+1 level of hierarchical digital certificate permissions.

so some early 90s x.509 identity certificates were based on the
premise that a certificate authority would be able to package enuf
information about a party so that a relying party (dealing with the
entity for the first time) could make decisions about permissions,
privileges, authorizations and/or other decisions with regard to how
they treated a stranger. This goes back to the digital certificate
emulation of the physical credentials, certificates, licenses,
etc. that have served the world for centuries ... allowing relying
parties to decide how to deal with entities that were otherwise comple
strangers.

Some of the 3rd party certification authorities then were looking at
increasing the perceived value of the identity certificates by grossly
overloading them with personal information ... hoping to appeal to
broader relying party market segments.

In the mid-90s, several institutions began realizing that identity
certificates, grossly overloaded with personal information,
represented significant privacy and liability issues. Also some of the
permission information specification could represent security
vulnerabilities. As a result you saw them retrenching to
relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

where the basic, unique digital certificate information was some form
of account number or database record location (along with a the public
key). after the relying party verified the digital signature, the
relying party would then look up all the necessary information about
the entity in their repository. However, this is basic violation of
the principles behind the centuries old credential/certificate/license
paradigm where information was being provided to strangers that had no
other means of obtaining the information.

in this scenario it was trivial to demonstrate if the relying party
was going to access their own information about the party (or possibly
make some online query for the same information), then the digital
certificate was redundant and superfluous. this was the
certificate-less paradigm where a person already has information about
the other entity
http://www.garlic.com/~lynn/subpubkey.html#certless

a somewhat facetious example (of much of the current PKI use) is where
spouses are required to have their marriage certificates tatooed on
their respective forwards in order to determine who their respective
spouse is. nominal certificates (including marraige) are for
presenting to strangers to establish certain priviliges and/or
permissions. it nominally wouldn't be necessary to repeatedly present
your copy of the marraige certificate to your spouse in order to
establish your position as their spouse.

the x9a10 financial standard working group had been given the
requirement to preserve the integrity of the financial infrastructure
for all retail payments
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

and it was shown that it could be done with using digital signature
for (something you have) authentication w/o appending digital
certificates (by having the public key stored in much the same way
that mother maiden names, PINs, passwords and other information used
for authentication is stored).

part of this issue was that some of the attempts at certificate-based
financial certificates had digital certificate sizes in the 4k-12k
byte range (even for the abbreviated relying-party-only certificates).
However, the typical payment transaction size is in the 60-80 byte
range. Appending 4k-12k byte redudnant and superfluous digital
certificates was creating a payload bloat of 100 times (i.e. the
transaction payload was being increased by two orders of magnitude).

Somewhat in response, there was a financial industry effort to define
a "compressed" certificate format ... hoping to get redundant and
superfluous digital certificates into the 300 byte range (payload
bloat of only five times instead of 100 times) by eliminating
non-unique fields in the certificates. I pointed out that you could go
even further, you could eliminate all fields in the digital
certificates that you knew to already be in possession of the relying
parties. Since it was trivial to show that the relying party could
have already stored ALL information that might be found in a digital
certificate ... it was possible to demonstrate compressing a digital
certificate to zero bytes. rather than talking about eliminating the
overhead of appending redundant and superfluous digital certificates,
it was possible to demonstrate the efficiency of appending zero byte
digital certificates.

Basically, as the world has gone more online and the network has
become more and more ubiquitous ,the market segment where a relying
party doesn't already have information about another entity (and/or
can't obtain it via online facelities) has rapidly shrunk. As a result
you have seen PKIs moving into more and more no-value market segments
...  where the business processes can't cost justify the relying party
having their own information (about the parties they are dealing with)
and/or can't justify the cost of doing online transactions to obtain
the information.

Value of an old IBM PS/2 CL57 SX Laptop

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sun, 07 May 2006 14:50:59 -0600

greymaus writes:

Further thought, eBay may be a trap waiting for the unwary, but Paypal
is getting more and more popular, and being banned from there (for
technical reasons) is the equivelent of an alcoholic being banned from
his local bar, embarrassing but good for ones finances.

somewhat related blog
https://www.financialcryptography.com/mt/archives/000711.html

to some extent paypal was providing online accounts where they then
turned around and do a real payment operation thru the real payment
infrastructure ... and charging a premium over and above what they had
to pay for doing the real payment transaction.

part of this was financial institutions doing real payments are fairly
heavily regulated and have lots of reporting and operational
requierments. having a separate operation for online stuff, may be
able to operate with much less overhead and restrictions. however,
they are vulnerable to real financial institutions moving into the
market space and eliminating the middle man (and the associated extra
intermediary overhead charges) ... aka offer the same function
directly for approx. the same amount they are currently charging the
middle man.

you see part of this characteristic in some manufacturing operations
that offer consumer goods and also provide financing for the
purchases. in several cases, the financial arm is making nearly all of
the profit and the actual manufacturing is operating close to a
break-even or even in the red. however, the two different
organizations are frequently kept at arms length in order to avoid
subjecting the manufacturing to the regulations and reporting overhead
that the financial organization is subject to (there have been jokes
that financial services are the only thing keeping some amount of the
rust belt afloat).

there were also some number of digital cash operations floated in the
90s (attempting to address portions of the online payments market
segment) ... however, doing detailed business process analysis turned
up that some number of them were just excuses for acquring the float.

some digital payment infrastructure was set up where the consumer had
to transfer money into the online payment infrastructure
("stored-value" and various other kinds of similar mechanisms). the
money in this infrastructure wasn't earning the consumers any interest
... it was all going to the sponsoring infrastructure (several
stored-values, gift cards, etc, work that way).

Several central banks took a look at many of these operations and
eventually made a statement that they would allow the institutions to
retain the float during the inception period (long enough until the
institutions had covered the cost of the initial deployment and other
startup costs). However, after a couple of years, these institutions
would be expected to start paying the consumer interest for the money
on deposit in these accounts.

The ruling that there would no longer be the financial bonanza (from
the float on the money in these accounts) significantly reduced the
interest in developing and deploying these types of operations.

a couple past posts mentiong the float incentive behind many
of the digital cash operations:
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
http://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

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

rexx or other macro processor on z/os?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: rexx or other macro processor on z/os?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 07 May 2006 15:19:24 -0600

Paul Gilmartin wrote:

Was this, then, even before passed data sets existed?  There was no
other way to pass data from one job step to another?  (Did jobs
even have multiple steps?)

this was standard operation for "sysgen". you would punch up 40-100
cards which specified a lot of parameters for the system configuration
(specified as assembler macros). this was "stage-1" sysgen.

based on parameters and a punch of other stuff, the assembler macros
would "PUNCH" a couple thousand cards (frequently around a box). This
became "stage-2" sysgen. This was job card, a whole series of job step
EXEC cards and all the necessary control & specification
statements for each EXEC step. it wasn't that it was a passing data
... it was a whole new job stream that had been generated
automagically by the assembly of the stage-1 sysgen deck.

this was done in dedicated scheduled time (typically at least a shift
or two), booting/ipl a special "starter" os/360 (PCP) system that
handled first the stage-1 sysgen followed by the stage-2 sysgen
deck. A single stage-2 sysgen deck (couple thousand cards) would be a
single job with several score job/EXEC steps.

as i've mentioned before, when I was an undergraduate in the late 60s
... starting with mft sysgen for os/360 release 11, I manipulated
stuff so that I could do stage-1 sysgen in standard production job
stream, get the resulting output for stage-2 sysgen and completely
re-organize it. I worked it so I could submit it to hasp/mft
production system with most EXEC steps organized as individual JOBs
... but carefully controlling their sequence of execution. The
sequence of JOBs (and things like the order of move/copy statements
and other stuff ... within job/EXEC steps) were organized to carefully
control the physical placement of datasets and PDS members for optimal
seek ordering on the newly generated system disks.

recent post commenting that they finally offered being able to
explicitly place VTOC in release 15/16 ... something that I had been
asking for since I started careful disk layout with release 11 system
generation.
http://www.garlic.com/~lynn/2006h.html#57 PDS Directory Question

for other topic drift, several collected posts about early use of rex
(long before it was renamed rexx and released to customers)
http://www.garlic.com/~lynn/submain.html#dumprx

blast from the past, reliable communication

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: blast from the past, reliable communication
Newsgroups: alt.folklore.computers
Date: Sun, 07 May 2006 16:07:10 -0600

a recent blog entry on standard tcp/ip not being adequately
reliable for financial operations:
https://www.financialcryptography.com/mt/archives/000714.htm

and some of my comments
http://www.garlic.com/~lynn/aadsm23.htm#21 Reliable Connections are not

as mentioned in the above, we were also on the xtp technical advisory
board
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

and one of the other participants was naval surface warfare center.

for a blast from the past, a short summary presented on NSWC
requirements from mar89; implicit in this is very high availability
and integrity requirements:

Several objectives from the Navy Surface Warfare Cneter (NSWC)
requirement study, considering transport service requirements for
naval platforms.

Several scenarios require low latency, high level of concurrenty,
response to operator input, and movement of very large files to
graphic displays. Transport service througput requirements are
estimated as shown:

Button & Trackball actions      50 bytes @ 2/sec           100 ms max
Menu selections                 100 bytes @ 1/sec          500 ms max
File service requests           200 bytes @ 3/min

Track file updates              1mbyte @ 1/2sec
Indicator & cursor control      50 bytes per action        100 ms max
Pixel images                    1 mbyte per action         500 ms max
File server accesses            up to 100 mbyte per action

... snip ...

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

blast from the past on reliable communication

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: blast from the past on reliable communication
Newsgroups: alt.folklore.computers
Date: Sun, 07 May 2006 23:14:35 -0600

another historical item from the period; part of old corporate XTP
position memo


To: distribution
Date: 1 September 89, 12:08:14 EDT

Communications Standards Development:
------------------------------------

Position - Oppose for OSI standardization

In reviewing the drafts of the XTP protocol it was noted that it is
very narrow in scope and does not fit into the structure of the OSI
Reference Model.

Other concerns include the possibility of a 6th Transport Class to
have to handle (Classes 0 - 4 are outlined in ISO 8073). It is also
very doubtful that we would be able to push a protocol into ISO that
spans multiple layers of the OSI Reference Model.

The high-bandwidth requirements of emerging communications
technologies will require a close examination of the Basic Reference
Model to determine what changes are required to keep it in pace with
developments.

To this end a study project has been initiated in the ANSI committee
X3S3.3 (OSI Network and Transport) to examine the requirements placed
on Network and Transport Layer protocols in support of very high-speed
networking. The existing OSI protocols will be analyzed with respect
to these requirements.  The output will be specific proposals for
modifications to existing OSI standards and/or new OSI protocols. XTP
techniques, along with those of other protocols, would be candidates
for study.

Research:
--------

Position - Oppose for standardization

The key concern is that existing OSI Network/Transport functions
should meet high-speed requirements with the proper optimizations.
Effort should be spent in this area before jumping into development of
new protocols.

XTP is really more of a OSI Layer 2 protocol rather than a Layer 3/4
protocol.

xxxxxx has been attending the ANSI X3S3.3 meetings to understand the
XTP direction and offer guidance on high-speed protocol development.

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

past posts mentioning x3s3.3 & OSI:
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?
http://www.garlic.com/~lynn/2002g.html#19 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#26 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#46 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#49 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#50 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002q.html#4 Vector display systems
http://www.garlic.com/~lynn/2003d.html#27 [urgent] which OSI layer is SSL located?
http://www.garlic.com/~lynn/2003g.html#45 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003l.html#47 OSI not quite dead yet
http://www.garlic.com/~lynn/2003n.html#36 Cray to commercialize Red Storm
http://www.garlic.com/~lynn/2004c.html#52 Detecting when FIN has arrived
http://www.garlic.com/~lynn/2004e.html#13 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004f.html#18 layered approach
http://www.garlic.com/~lynn/2004g.html#12 network history
http://www.garlic.com/~lynn/2004q.html#34 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#44 How many layers does TCP/IP architecture really have ?
http://www.garlic.com/~lynn/2005.html#9 OSI - TCP/IP Relationships
http://www.garlic.com/~lynn/2005.html#29 Network databases
http://www.garlic.com/~lynn/2005.html#45 OSI model and SSH, TCP, etc
http://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005e.html#39 xml-security vs. native security
http://www.garlic.com/~lynn/2005j.html#33 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#52 ARP routing
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005s.html#1 Type A ,Type B
http://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
http://www.garlic.com/~lynn/2005u.html#18 XBOX 360
http://www.garlic.com/~lynn/2005u.html#52 OSI model and an interview

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

blast from the past on reliable communication

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: blast from the past on reliable communication
Newsgroups: alt.folklore.computers
Date: Tue, 09 May 2006 10:22:05 -0600

... some more, this time from oct89, also mentions NSWC (naval surface
warfare center) and NOSC (naval ocean systems center):

An intense effort is centered on the evaluation of multicast
strategies. In coordination with NSWC, UVA researchers have collected
a library of multicast information, based on mechanisms, applications,
group management, metrics, and multicasting with XTP. A report,
"Strategies for Multicasting", is being written.

In parallel, another study is evaluating aspects of protocols that
allow latency control for real-time control systems operating over
LANs. A survey of priority mechanisms has led to the concept of
"importance" of dynamic message delivery. One comment is that
"importance" doesn't carry the baggage of "priority". The Sort Field
in XTP is under careful study, with a UVA report resulting, "Making
XTP Responsive to Real-time Needs".

An XTP Tutorial is being written, and will be available to the TAB
soon.

A contract from SPerry Marine calls for development of SEAnet, a
real-time LAN for commercial ships.

Sperry Marine is also sponsoring a SAFENET I test system, with XTP
running over an 802.5 token ring.

NOSC is sponsoring a SAFENET II effort, attaching VME systems with
FDDI.

NSWC is sponsoring performance measurements, LAN recommendations, and
prototyping.

NASA Johnson is sponsoring an evaluation of Space Station networking,
prototyping, and analysing tradeoffs between ISO protocols and
real-time systems.

... snip ...

ref:
http://www.garlic.com/~lynn/2006i.html#16 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication

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

blast from the past on reliable communication

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: blast from the past on reliable communication
Newsgroups: alt.folklore.computers
Date: Tue, 09 May 2006 11:32:37 -0600

Brian Inglis writes:

AFAIR they weren't very usable even in non-real-time systems, unless
you had the same vendor's hardware and software at both ends, and not
always even then!

remember this was the era of gosip and numerous gov. mandates to
convert everything to iso/osi as well as gov. mandates to eliminate
all the internetworking and tcp/ip stuff.

misc. past posts mentioning gosip (GOVERNMENT OPEN SYSTEMS
INTERCONNECTION PROFILE)
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom.
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2001e.html#17 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#6 YKYGOW...
http://www.garlic.com/~lynn/2002g.html#21 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet
http://www.garlic.com/~lynn/2002m.html#59 The next big things that weren't
http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003e.html#71 GOSIP
http://www.garlic.com/~lynn/2003e.html#72 GOSIP
http://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
http://www.garlic.com/~lynn/2004c.html#52 Detecting when FIN has arrived
http://www.garlic.com/~lynn/2004e.html#13 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004f.html#32 Usenet invented 30 years ago by a Swede?
http://www.garlic.com/~lynn/2004q.html#44 How many layers does TCP/IP architecture really have ?
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005.html#29 Network databases
http://www.garlic.com/~lynn/2005.html#45 OSI model and SSH, TCP, etc
http://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005e.html#39 xml-security vs. native security
http://www.garlic.com/~lynn/2005u.html#52 OSI model and an interview
http://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard

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

blast from the past on reliable communication

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: blast from the past on reliable communication
Newsgroups: alt.folklore.computers
Date: Tue, 09 May 2006 13:22:22 -0600

Anne & Lynn Wheeler writes:

remember this was the era of gosip and numerous gov. mandates to
convert everything to iso/osi as well as gov. mandates to eliminate
all the internetworking and tcp/ip stuff.

re:
http://www.garlic.com/~lynn/2006i.html#19 blast from the past on reliable communication

while there have been some issues with internet and tcp/ip
http://www.garlic.com/~lynn/internet.htm
http://www.garlic.com/~lynn/subnetwork.html#internet

at least ietf rfc
http://www.garlic.com/~lynn/rfcietff.htm

requires at least two interoperable implementations before
progress on standards process.

osi could pass as an iso standard w/o requiring proof that it was
feasable or could even be implemented.

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

blast from the past on reliable communication

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: blast from the past on reliable communication
Newsgroups: alt.folklore.computers
Date: Tue, 09 May 2006 13:33:03 -0600

Anne & Lynn Wheeler writes:

Communications Standards Development:
------------------------------------

Position - Oppose for OSI standardization

In reviewing the drafts of the XTP protocol it was noted that it is
very narrow in scope and does not fit into the structure of the OSI
Reference Model.

ref:
http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication

a few past telling of tale about communications group idea of
"high-speed" (during at least the mid 80 to early 90s):
http://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2003m.html#59 SR 15,15
http://www.garlic.com/~lynn/2004g.html#12 network history
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor

in that period we were already operating our high-speed backbone
http://www.garlic.com/~lynn/subnetwork.html#hsdt

had been told we couldn't bid ond nsfnet1 & nsfnet2 (precusor to
modern internet) although audit by NSF stated that what we had
running was at least five years ahead of all bid submissions
to build something new
http://www.garlic.com/~lynn/internet.htm#nsfnet
http://www.garlic.com/~lynn/internet.htm#0

had come up with 3-tier architecture and were out making presentations
to customer IT executives
http://www.garlic.com/~lynn/subnetwork.html#3tier

and had started work on our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

the communication group were out pushing SAA ... at least some of
which could be construed as attempting to put the client/server
genie back into the bottle and return to the days of PCs
accessing servers via terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation

we were taking all sorts of heat from various factions in the
communications group over at least HSDT and 3-tier architecture.

other posts in this thread
http://www.garlic.com/~lynn/aadsm23.htm#21 Reliable Connections are not
http://www.garlic.com/~lynn/aadsm23.htm#24 Reliable Connections are not
http://www.garlic.com/~lynn/2006i.html#16 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#18 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#19 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#20 blast from the past on reliable communication

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

virtual memory

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual memory
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 10 May 2006 10:14:52 -0600

"Doug MacKay" writes:

The swap storage you're thinking of is only a small piece of a virtual
memory system.  If it was removed from a virtual memory system you'd
still have a virtual memory system ;)

see melinda's paper on the development of virtual memory and
virtual machines in the 60s
http://www.princeton.edu/~melinda/25paper.pdf

part of it was mit had chosen ge for ctss follow-on multics.

the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

had added custom virtual memory to 360/40 and built cp/40 supporting
virtual machines and paging/swapping.

the 360/67 was official product with virtual memory support, built for
tss/360. however, the science center ported cp/40 from the 360/40 to
360/67 renaming it cp/67.

univ. of michigan also developed MTS (michigen terminal system) that
supported virtual memory on 360/67 (also paging/swapping).

however, there was at least one effort that modified os/360 to utilize
the 360/67 virtual memory hardware w/o providing paging/swapping
support. os/360 was nominally a "real address" operating system where
applications were allocated contiguous areas of real memory.  long
running applications frequently resulted in storage fragmentation,
there would be enough real memory to run an application but not
located contiguously. the use of virtual memory hardware allowed
discontiguous real storage to be appear to be contiguous.

for some drift ... misc posts about doing page replacement algorithms
in the 60s (i.e. deciding which pages should be moved between real
memory and disk).
http://www.garlic.com/~lynn/subtopic.html#wsclock

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

Virtual memory implementation in S/370

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual memory implementation in S/370
Newsgroups: alt.folklore.computers
Date: Wed, 10 May 2006 16:33:18 -0600

Marten Kemp writes:

The recent thread about virtual memory sparked a (kind of)
idle question: why did the implementation in the S/370
have a two-level scheme (segment and page)? My original
thought was that it facilitated definition of discontiguous
parts of an address space.

ref:
http://www.garlic.com/~lynn/2006i.html#22 virtual memory

370 virtual memory architecture segment & page tables. 360/67
provided for both 24-bit virtual addressing and 32-bit virtual
addressing (in its segment/page virtual memory structure).

the introduction of virtual memory on 370 was just 24-bit virtual
addressing with segment and page tables, originally with 1mbyte and
64kbyte segment options as well as 4kbyte and 2kbyte page options.

the original 370 virtual memory architecture also had segment
protection and some selective invalidate instructions. these
additional features were dropped to help get the virtual memory
hardware retrofit to 370/165 back on schedule.

in the morph from cp67/cms to vm370/cms, cms had been restructured to
take advantage of "shared segments" (single copy of the same virtual
memory page in physical storage for multiple different virtual address
spaces) with the segment protect feature. when segment protect was
dropped from 370 virtual memory architecture, the protection of these
shared pages had to be reworked.

more than 24-bit virtual addressing wasn't re-introduced until 370-xa
with the 3081.

I had done a page-mapped filesystem for CMS, which included compatibility
for existing CMS filesystem API
http://www.garlic.com/~lynn/submain.html#mmap

It also included a number of extended features allowing page-mapped
objects (shared & non-shared) to appear at arbitrary virtual
address locations. the same shared (segment) object could even appear
at different virtual addresses in different virtual address
space. this required a lot of fiddling with the prevalent 360/370
software use of address constants. Lots of posts mentioning the
fiddling with address constants
http://www.garlic.com/~lynn/submain.html#adcon

Only a small subset of the virtual memory object support was ever
released called DisContiguous Shared Segment (DCSS). The generalized
virtual memory object support and the page mapped filesystem support
was never released.

various posts mentioning the segment protect issue:
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#9 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment
http://www.garlic.com/~lynn/2005o.html#10 Virtual memory and memory protection
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean?

...

and misc. past posts mentioning DCSS:
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2003o.html#42 misc. dmksnt
http://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#11 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2005b.html#8 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005g.html#30 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005t.html#39 FULIST
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#35 Charging Time
http://www.garlic.com/~lynn/2006b.html#4 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006b.html#7 Mount a tape
http://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s

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

Virtual memory implementation in S/370

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual memory implementation in S/370
Newsgroups: alt.folklore.computers
Date: Wed, 10 May 2006 17:16:10 -0600

Marten Kemp writes:

The recent thread about virtual memory sparked a (kind of)
idle question: why did the implementation in the S/370
have a two-level scheme (segment and page)? My original
thought was that it facilitated definition of discontiguous
parts of an address space.

re:
http://www.garlic.com/~lynn/2006i.html#22 virtual memory
http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370

i had also done page migration as well as "table" migration ...  which
were released in my resource manager product ... the blue letter
product announcement gives product release as 11may76 ... 30 years ago
tomorrow.  partial reproduction of the resource manager blue letter:
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

page migration would look make judgements about different speed paging
devices ... and if it found "high" speed paging devices filling up, it
would start looking for idle virtual pages (resident on "high" speed
devices), that it could migrate to slower speed devices.

when real storage started getting constrained ... it would also look
for idle portions of virtual address spaces. each 64kbyte virtual
segment consumed ten bytes of real storage, 2bytes for the page table
entry and 8bytes of adminstrative stuff (shadow storage protect keys,
and location on paging device for the virtual page). for "idle"
segments, it would turn on the invalid bit in the segment table entry,
write the administrative stuff to special disk locations, and then
discard the real memory for the page table and administrative stuff
... typically picking up 160bytes of real storage per 64kbyte of idle
virtual address space or 2560bytes of real storage per 1mbyte of idle
virtual address space ... little over 4kbytes of real storage per
2mbytes of idle virtual address space.

the defined virtual address space might or might not be contiguous ...
but the segment table could have large gaps in the pointers to page
tables ... potentially because the space wasn't defined in the
particular virtual address space ... or because the virtual address
space area was deamed to be idle at the moment and the associated
tables had been removed from real storage.

the administrative table containing the disk backing store address for
virtual pages (and the shadow storage protect keys) was called a
SWAPTABLE ... so the feature allowing the SWAPTABLE to be removed from
real storage was called SWAPTABLE migration or paging SWAPTABLEs.

a few other posts mentioning SWAPTABLE migration:
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#35 Charging Time
http://www.garlic.com/~lynn/2006.html#36 Charging Time

...

and a few posts mentioning shadowing process:
http://www.garlic.com/~lynn/2005h.html#17 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2006i.html#10 Hadware Support for Protection Bits: what does it really mean?

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

Benefits of PKI - 5,000 nodes organization

From: lynn@garlic.com
Newsgroups: microsoft.public.security
Subject: Re: Benefits of PKI - 5,000 nodes organization
Date: Thu, 11 May 2006 08:48:25 -0700

S. Pidgorny <MVP> wrote:

PKI mostly gives intangible benefits by reducing risks associated
with weak authentication systems and data integrity.  Does that
count as practical?

validating digital signatures with public keys provide for checks
against data modification and impersonation with secret-based
authentication mechanisms.

originator computes hash of some message/document and encodes the hash
with their private key; the message/document then can be transmitted
along with the appended digital signature

the recipient/relying party recomputes the hash on the message, decodes
the digital signature with the originator's public key and compares the
two hashes. if they are the same, the recipient/relying party can
assume that the message/document hasn't been modified since it was
digitally signed and that the originator has access to and use of the
corresponding private key ... aka something you have authentication
... from 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

the shared-secret authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#secret

has the same value used for both origination and verification in
authentication paradigm. that means that access to the value used for
the verification also enables impersonation. fufthermore since it is a
"static value" it is subject to skimming/harvesting/evesdropping
vulnerabilities and replay attacks
http://www.garlic.com/~lynn/subintegrity.html#harvest

since public/private key uses a different value for verification and
origination, the exposure for impersonation is significantly reduced.
since the digital signature can be different on every use, it is a
countermeasure to skimming/harvesting/evesdropping and replay attacks.

the original kerberos pk-init draft
http://www.garlic.com/~lynn/subpubkey.html#kerberos

called for registering public keys in lieu of passwords and using
digital signature verification for authentication. this was a purely
non-PKI, certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#certless

it was only later that there was pressue to add PKI-mode of operation
with certificates to the kerberos pk-init draft ... creating a
duplicate and parallel administrative infrastructure. now there has to
be both the kerberos administration and registration infrastructure of
the allowed entity, in addition to the PKI/certificate adminstration
and registration infrastructure of the allowed entity.

the same can be said of RADIUS ... the other major authentication
infrastructure in use for internet and distributed environments. the
straight-forward solution is to register the entity with RADIUS
including their public key, in lieu of a password.
http://www.garlic.com/~lynn/subpubkey.html#radius

the other is to have duplicate entity registration and administration
infrastructures, one for RADIUS ... and a separate, duplicate
registration and administration infrastructure for the PKI/certificate
operation.

a few recent postings discussing some of the issues in more detail
http://www.garlic.com/~lynn/aadsm22.htm#8 Kama Sutra Spoofs Digital Certificates
http://www.garlic.com/~lynn/aadsm22.htm#17 Major Browsers and CAS announce balkanisation of Internet Security
http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm23.htm#3 News and Views - Mozo, Elliptics, eBay + fraud, naïve use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#5 History and definition of the term 'principal'?
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/2006h.html#46 blast from the past, tcp/ip, project athena and kerberos
http://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation

a few recent postings discussing some of the issues in more detail
http://www.garlic.com/~lynn/aadsm22.htm#8 Kama Sutra Spoofs Digital Certificates
http://www.garlic.com/~lynn/aadsm22.htm#17 Major Browsers and CAS announce balkanisation of Internet Security
http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm23.htm#3 News and Views - Mozo, Elliptics, eBay + fraud, naïve use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#5 History and definition of the term 'principal'?
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/2006h.html#46 blast from the past, tcp/ip, project athena and kerberos
http://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation

11may76, 30 years, (re-)release of resource manager

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: 11may76, 30 years, (re-)release of resource manager
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Thu, 11 May 2006 10:55:33 -0600

30 years since (re-)release of resource manager; some amount of the
stuff i had done as an undergraduate in the 60s for cp67 ... but was
dropped in the morph from cp67 to vm370.

collected past posts mentioning the scheduler
http://www.garlic.com/~lynn/subtopic.html#fairshare
and page replacement
http://www.garlic.com/~lynn/subtopic.html#wsclock

misc. past posts mentioning the date for resource manager:
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
http://www.garlic.com/~lynn/2001f.html#56 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2006d.html#27 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006g.html#1 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#7 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#22 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#25 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#24 Virtual memory implementation in S/370

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

Really BIG disk platters?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Really BIG disk platters?
Newsgroups: alt.folklore.computers
Date: Thu, 11 May 2006 19:22:44 -0600

"Charlie Gibbs" writes:

A friend once worked in a Burroughs 1700 shop.  They added
a head-per-track disk to the system, to speed up swapping or
whatever.  I don't remember the specs of the drive, but it
was in a cabinet about 4 feet high, 4 feet wide, and about
a foot deep.  The axis was horizontal and the platter(s)
must have been about 3 feet in diameter.

the 2301 "paging drum" was cylinder with head per track ...  actually
there was two models the 2303 and the 2301. the 2303 read/wrote single
head at a time. the 2301 read/wrote 4 heads in parallel, a "track" was
four times larger and there was 1/4th as many "tracks".

picture of 2301:
http://www.columbia.edu/acis/history/drum.html

the 2305 was also a fixed head device ... but was several spinning
disks with head per track. there were two models, one with twice as
many addressable heads and tracks. the other had the same number of
physical heads but they had paireqd heads on the same track ... offset
180degrees. which ever head the data came under first, was selected
...  as a result the one with half as many tracks and half the
"logical" heads had half the rotation delay as the standard one.

the standard 2305 required on avg half revolution to get targeted data
under the head. the other 2305 required only a quarter revolution to
get targeted data under the head.

picture of 2305
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html

... and just for the heck of it

old 650 drum
http://www-03.ibm.com/ibm/history/exhibits/650/650_ph09.html

old 355 disk
http://www-03.ibm.com/ibm/history/exhibits/650/650_ph07.html

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

virtual memory

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual memory
Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l
Date: Thu, 11 May 2006 22:00:00 -0600

"kim kubik" writes:

There are (at least) two overlapping meanings of the phrase "virtual
memory" here: a virtual (i.e., non-real) memory address and a
virtual eXtention ("X" as in VAX) of memory out to disk.  Most
people seem to use the latter meaning.

Th