List of Archived Posts

2007 Newsgroup Postings (01/08 - 01/18)

sealand up for sale

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

Special characters in passwords was Re: RACF - Password rules

information utility

Special characters in passwords was Re: RACF - Password rules

Mainframe vs. "Server" (Was Just another example of mainframe

Special characters in passwords was Re: RACF - Password rules

How many 36-bit Unix ports in the old days?

Special characters in passwords was Re: RACF - Password rules

special characters in passwords

Just another example of mainframe costs

How many 36-bit Unix ports in the old days?

V2X2 vs. Shark (SnapShot v. FlashCopy)

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

history question

sealand up for sale

How many 36-bit Unix ports in the old days?

Forbidding Special characters in passwords

What is "command reject" trying to tell me?

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

What is "command reject" trying to tell me?

was: How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

IBMLink 2000 Finding ESO levels

IBMLink 2000 Finding ESO levels

security engineering versus information security

Just another example of mainframe costs

security engineering versus information security

Special characters in passwords was Re: RACF - Password rules

Special characters in passwords was Re: RACF - Password rules

'Innovation' and other crimes

How many 36-bit Unix ports in the old days?

Special characters in passwords was Re: RACF - Password rules

'Innovation' and other crimes

"The Elements of Programming Style"

security engineering versus information security

Why so little parallelism?

Is anyone still running

'Innovation' and other crimes

newbie need help (ECC and wireless)

6400 impact printer

6400 impact printer

Is anyone still running

Special characters in passwords was Re: RACF - Password rules

Special characters in passwords was Re: RACF - Password rules

Forbidding Special characters in passwords

Forbidding Special characters in passwords

IBMLink 2000 Finding ESO levels

old lisa info

"The Elements of Programming Style"

Authentication architecture on a Unix Network

Peter Gutmann Rips Windows Vista Content Protection

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Is Silicon Valley strangeled by SOX?

Securing financial transactions a high priority for 2007

newbie need help (ECC and wireless)

sealand up for sale

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: sealand up for sale
Newsgroups: alt.folklore.computers
Date: Mon, 08 Jan 2007 07:38:57 -0700

Sealand Put Up For Sale
http://slashdot.org/articles/07/01/08/1158240.shtml
Tiny North Sea tax haven for sale
http://www.abc.net.au/news/newsitems/200701/s1823039.htm

update on this post
http://www.garlic.com/~lynn/2006w.html#32 'Innovation' and other crimes

above has reference showing it burning, and then there is this older reference

Answers From Sealand: CTO Ryan Lackey Responds
http://interviews.slashdot.org/interviews/00/07/02/160253.shtml?tid=99

comment in above:

Why do you need physical security at all?

... snip ...

of course, fire control measures might be considered a security
issue.

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Mon, 08 Jan 2007 12:20:50 -0700

krw <krw@att.bizzzz> writes:

Yeah, but it doesn't work that way under VM or PR/SM (IIRC, VM
swiped PR/SM code).  It assigns that task to virtual processor 1.
VM then dispatches that to any physical processor.

previous post
http://www.garlic.com/~lynn/2007.html#46 How many 36-bit Unix ports in the old days?

Amdahl's hypervisor was done in macrocode ... pr/sm ... which has
since evolved into LPARs ... started out as low-level 3090 microcode
... evolving from SIE. some drift with posts and old email about 3090
SIE operation, (amdahl) macrocode, hypervisor, pr/sm, etc
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email

in some sense, SIE was fairly sophisticated starting point ... but
required software kernel to specify all the parameters. pr/sm (and
then LPARs) ... used the service processor to reserve some set of
dedicated resources and establish various parameters ... setting
everything in motion w/o requiring a (separate) software kernel. The
LPAR sophistication was much less than what was in the vm software
kernel ...  (although there was quite a bit of variation between
vm370, vm/sp, vm/sp hpo, and vm migration-aid/system facility). some
recent posts
http://www.garlic.com/~lynn/2007.html#44 vm/sp1
http://www.garlic.com/~lynn/2007.html#45 Just another example of mainframe costs

recent posts mentioning 3090 service processor
http://www.garlic.com/~lynn/2007.html#18 IBM sues make of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Mon, 08 Jan 2007 15:56:09 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

for some drift, old email discussing VMS announcement of support for
symmetric multiprocessing support. i think ultrix symmetric
multiprocessing support was two years later(?)

re:
http://www.garlic.com/~lynn/2007.html#46 How many 36-bit Unix ports in the old days?

above includes digital press release from VAX 8800 symmetric
multiprocessing spring of 88. above also mentions that ULTRIX and VAX
ELN support (non-symmetric) at that time.

previous post mentioning vaxstation 8000 announce also spring 88
http://www.garlic.com/~lynn/2006u.html#9 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#10 The Future of CPUs: What's After Multi-Core?

previously ULTRIX had two-processor, asymmetric multiprocessor support

from 3apr90 announce

• Digital's three-processor DECsystem 5830 and four-processor
  DECsystem 5840 join the exciting DECsystem 5810 and 5820
  computers as the most expandable, large-system members of
  Digital's DECsystem family.  ULTRIX V4 with SMP makes
  efficient use of each processor to deliver new levels of
  performance to commercial and technical users.  Typical
  applications for timesharing and server environments
  include academic computing, CASE, molecular modeling,
  econmetric modeling, high-energy physics and computational
  chemistry.  The DECsystem 5800 series offers the best
  overall expansion capacity in the industry, with support
  for up to 256 Mbytes of memory, up to 50 MB/s I/O, and up
  to 115 Gbytes of storage.  Upgrades within the series --
  for example, from a DECsystem 5820 to a DECsystem 5830
  computer -- can be done quickly and easily in the field.
  With the reduced pricing announced today, entry prices for
  the DECsystem 5810 start at $75,000; entry prices for the
  new DECsystem 5830 and DECsystem 5840 begin at $140,000 and
  $160,000, respectively.  The new systems are available in
  June.

... snip ...

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Mon, 08 Jan 2007 19:59:31 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

the exception that proves the point was the tss/370 ssup that saw
extensive deployment inside at&t. higher level parts of Unix were
mated to the low-level tss/370 kernel interfaces ... unix was sort of
running on a "370 bare machine" ... but it was actually layered on top
of the lower level tss/370 kernel (which provided all the 370 RAS and
EREP support).

ref:
http://www.garlic.com/~lynn/2007.html#38 How many 36-bit Unix ports in the old days?

some additional drift with old at&t tss/370 ssup (small supervisor) aka sss/370 status


From: wheeler
Date: 04/08/80  19:20:54

XXXXXX didn't reply. didn't have much to say. Talked to YYYYYY at YKT
since & he has more information since he is acquainted at least some
of the characters (and knows the names for the rest of the cast). Bell
is projecting to have UNIX code working for TSS PRPQ by end of the
year (instead of June). Also I'm looking for existing C compiler but
there is none as of yet.

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

misc. past posts referencing unix on tss activity:
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000.html#92 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001d.html#77 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
http://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004p.html#10 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/2005b.html#13 Relocating application architecture and compiler support
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/2005m.html#4 [newbie] Ancient version of Unix under vm/370
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006f.html#28 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
http://www.garlic.com/~lynn/2006p.html#22 Admired designs / designs to study
http://www.garlic.com/~lynn/2006p.html#26 Admired designs / designs to study
http://www.garlic.com/~lynn/2006t.html#17 old Gold/UTS reference
http://www.garlic.com/~lynn/2006w.html#24 IBM sues maker of Intel-based Mainframe clones

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Mon, 08 Jan 2007 20:18:14 -0700

krw <krw@att.bizzzz> writes:

In the early '90s I worked on the Crypto feature (ICRF) for the
ES9000 processors (and the 3090s before that).  One of the
improvements for the 3090s was to be able to put a crypto feature
on each processor (before that only one per side was allowed).  To
guarantee that each processor had the master keys a test was
dispatched to each processor.  Nope, the affinity was virtualized
so there was no way to verify keys.  One might issue four tests to
the four processors, only to have the tests run on one physical
processor.  WHen this was discovered, the multiple crypto program
was canceled (and I was allowed to transfer out of P'ok).

for other crypto activity ...  response to an initial design i had
done long ago and far away for one-to-many encrypted transmission

since this email was internal corporate communication ... some number
of people tended to interpret in terms of SNA, VTAM, LU6.2, etc ...
even when it has nothing to do with sna.


To: wheeler
Date: 26 December 1984, 11:19:26 MST

Lynn,
re: bind and key passing

Just went back over one of your recent notes and want to make sure I
understand something.  You said the bind would be with the local
transport layer.  I assume (correct me if I assume too much) that you
mean that a bind request would be sent to the transport layer with a
list of candidate destination applications/locations for a
multi-or-single participant session.  Given that the session has a
interactive characteristic, and not just a file to be delivered to
multiple locations, I would not expect the bind to come back with any
status until the transport layer had tried to contact all candidate
transport layer nodes in the list.  I would expect the bind to come
back with each candidate marked as 'yes' or 'no' and perhaps a global
'all' or 'partial' flag.  The bind requester could choose to either
continue or not (or even at bind request time, could indicate 'if not
'all', forget the whole thing').

The second point is that you indicated the application would pass the
key to the transport layer.  My druthers (which, to SNA product
developers always seem to be either inept, uninformed, or irrelevant)
would be to have the application simply request that the session(s) be
encrypted.  Actual key coordination or establishment should be a
function of the transport layer.  Specifically, I think key management
should be a function of LU6.2, for instance.

p.s. If memory serves, the DIA/DCA developers ***REDACTED***

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

the issue of where to do key coordination is still around in the
mid-90s when ipsec was going to have it in the transport layer ... and
you find SSL, PGP, and some number of other implementations doing it
in applications.

a couple other old crypto email references (email with public key references
from 1981 and 1985)
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network
http://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications

and old non-publickey, DES reference
http://www.garlic.com/~lynn/2006n.html#36 The very first text editor

========

and various recent posts with some mention of SNA and/or VTAM
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#12 Barbaras (mini-)rant
http://www.garlic.com/~lynn/2006f.html#13 Barbaras (mini-)rant
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
http://www.garlic.com/~lynn/2006h.html#56 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers
http://www.garlic.com/~lynn/2006l.html#25 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006l.html#46 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006l.html#50 Mainframe Linux Mythbusting (Was: Using Java in batch on
http://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006m.html#0 Mainframe Linux Mythbusting
http://www.garlic.com/~lynn/2006m.html#16 Why I use a Mac, anno 2006
http://www.garlic.com/~lynn/2006m.html#17 Why I use a Mac, anno 2006
http://www.garlic.com/~lynn/2006m.html#20 Why I use a Mac, anno 2006
http://www.garlic.com/~lynn/2006n.html#8 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006o.html#10 Article on Painted Post, NY
http://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#5 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#10 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core)
http://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgements
http://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#35 What's a mainframe?
http://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
http://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#29 Descriptive term for reentrant program that nonetheless is
http://www.garlic.com/~lynn/2006w.html#52 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006x.html#7 vmshare
http://www.garlic.com/~lynn/2006x.html#8 vmshare
http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)
http://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#14 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#29 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Tue, 09 Jan 2007 07:42:13 -0700

krw <krw@att.bizzzz> writes:

Back in the '70s one of the Senior Engineers (known for developing
the IBM channels)across from me had to ditch is Cessna 182 on
Interstate 84 right after an annual.  When they replaced the engine
they crushed the carb heat manifold.

somewhat similar discussion here
http://www.garlic.com/~lynn/2006x.html#8 vmshare

i.e. quote from old document referenced in above

• First, any given change can and often does impact service
(availability) levels of seemingly unrelated components in a data
processing system.  The impact is generally unpredictable and usually
undesirable.

... snip ...

and post citing RFC801 some similar issues in arpanet ...
http://www.garlic.com/~lynn/2007.html#43 SSH protocol analyzer

mentioning similarity between homogeneous OSI and homogeneous
arpanet and not being suitable for large heterogeneous network
interoperability

comment from rfc801:

It was clear from the start of this research on other networks that
the base host-to-host protocol used in the ARPANET was inadequate for
use in these networks.  In 1973 work was initiated on a host-to-host
protocol for use across all these networks.  The result of this long
effort is the Internet Protocol (IP) and the Transmission Control
Protocol (TCP).

... snip ...

post with old (jul80) arpanet newsletter article projecting that there
might be as many as 100 arpanet nodes in 1983
http://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?

and some discussion of issues when growing homogeneous network
operations can you any longer take everything down at one time for
global service and maintenance (quoting arpanet network-wide service
schedule from RFC638):
http://www.garlic.com/~lynn/2006y.html#19 The History of Computer Role-Playing Games

the change-over from arpanet to internetworking protocol was 1jan83
... which would be considered the technology basis for modern
internet. however, i contend the operational basis for the modern
(internetworking) internet came from the NSFNET backbone (lots of
references to both the 1jan83 switch-over to internetworking as well
as NSFNET)
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)
http://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)

as in the above referenced post
http://www.garlic.com/~lynn/2006x.html#8 vmshare

I've claimed that one of the reasons that the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

was larger than the arpanet for just about the whole period, was that
the primary internal network software was able to provide separation
(effectively a gateway type function) from just about the beginning
... something that didn't happen in the arpanet ... i.e. old arpanet
newsletter article projecting that there might be 100 nodes in 1983
... a year when the internal network passed 1000 nodes.

misc. background posts discussing internet
http://www.garlic.com/~lynn/internet.htm

misc. arpanet, internet, nsfnet posts
http://www.garlic.com/~lynn/subnetwork.html#internet

Special characters in passwords was Re: RACF - Password rules

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Special characters in passwords was Re: RACF - Password rules.
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 09 Jan 2007 08:24:15 -0700

ibmmain@ibm-main.lst (Arthur T.) writes:

You pick ease over security.  At my old shop, we had several
RACF-protected systems plus one VM system that held the password
unencrypted.  Most people used the same password on all, making them
none of them secure.  Many people also used the same password on a
client's system which also kept the passwords unencrypted; that let
the password totally out of the company.  I also found that NDM let
remote sites find your password; if that was a multi-use password,
you've compromised yourself everywhere.

the issue isn't so much that none of them were secure ...

there is the issue that passwords are shared-secrets ... and the same
value that is used to authenticate/verify ... is also used to
originate.  the recommendation for unique shared-secret (password,
pin, etc) for each unique security domain is countermeasure to
cross-domain security attacks (i.e. local garage isp attacking you
place of business or online banking).
http://www.garlic.com/~lynn/subintegrity.html#secrets

there is somewhat separate issue of making the passwords hard to guess
(and therefor hard to remember) and changing them frequently (making
them even harder to remember), in addition to having unique ones for
every security domain (having scores of things that are impossible to
remember).

old April first corporate directive on passwords from 1984
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#53 April Fools Day

some even tried to blame me ... but it had originated in POK and I
only distributed it local ... I didn't print it on corporate
letterhead, placing them around plant site corporate bulletin boards
over the weekend.

one of the justification for public key is that the value used for
verification (of digital signature) is not the same that is used to
originate (the digital signature). that eliminates needing to have
unique public key for every security domain (as countermeasure to
cross-domain attacks).

reference to old public key proposal from 1981
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

some recent related (security) topic drift
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/aadsm26.htm#18 SSL (https, really) acceleators for Linux/Apache?
http://www.garlic.com/~lynn/aadsm26.htm#20 Tamperproof, yet playing Tetris

lots of past posts on threats, vulnerabilities, exploits, fraud, etc
http://www.garlic.com/~lynn/subintegrity.html#fraud

information utility

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: information utility
Newsgroups: alt.folklore.computers
Date: Tue, 09 Jan 2007 09:47:19 -0700

i believe the person that coined the term "information utility" was
the person that also came up with the term datastore ...  and was one
of the people that i met with in meeting mentioned here
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

in the early to mid-80s, the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

had something called TOOLSRUN which sort of combined features of
computer conferencing (ala usenet), mailing lists (ala listserv), as
well as program/document retrieval and distribution (ala
ftp/anonymous) ... a couple recent posts mentioning TOOLSRUN
http://www.garlic.com/~lynn/2006w.html#35 Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?

predating TOOLSRUN was DATASTAG/RGET ... which was just remote
program/document retrieval (ala ftp/anonymous) ... recent post
http://www.garlic.com/~lynn/2006v.html#22 vmshare

and then there was CJNTEL ... was was more online network information
repository ... from long ago and far away ...

in the following, "sjrlvm1" is san jose research (in san
jose). "tdcsys4" is technology data center in pok (ny). "winh6" is
system in England.


To: distribution
Date: 03/29/80 16:34:21

  CJNTEL is up an running on both sjrlvm1 and tdcsys4. the phone
update/add/ and delete functions will automatically keep both versions
of the netphone directory in synch with each other. any
updates/deletes/adds made will be forwarded to the other system. the
user will be notified that his activity has been forwarded. and he is
notified when his change is complete.

  the design is table driven, and can support slave systems (example
the current plans to bring up a copy on winh6).

  although it is not impossible to get the data base out of synch, it
would require a person sending update commands to both systems for the
same record at the same time, then it is possible to have one update
overlayed with another (but only the active record).  i don't feel the
exposure is that great.

  because of the security built into it, where a person can only
modifiy his own record, the only record he can cause to be out of
synch is his own.

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

and a week or so later, tdcsys4 was having some number of performance
issues and started shutting various things off.


To: wheeler
Date: 04/08/80  09:29:55

Hi There,

  XXXXXX informed me that management decided to take CJNTEL off of
tdcsys4, so i updated your tables for sjrlvm1, with no slave
systems.. i'm going to sit tight and see what happens as far as other
system.. franklin lakes is installing a 3033 this weekend, and has
offered to bring up a CJNTEL system there..

  i made a change to the directory routines to allow the 18 byte phone
number you suggested, but i havent had a chance to test it out
yet.. (i've been buried with other things around here).. but will do
that sometime within the next week or so (will have to reformat the
directory you have there first).

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

post with old email from 1981 suggesting use of CJNTEL for supporting
a public key infrastructure
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

other posts mentioning CJNTEL
http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network
http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007

Special characters in passwords was Re: RACF - Password rules

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Special characters in passwords was Re: RACF - Password rules.
Date: Tue, 09 Jan 2007 11:36:03 -0700
Newsgroups: bit.listserv.ibm-main

Rick Fochtman wrote:

The nature of our business was such that we handled large amounts of
other people's money on a daily, and even hourly, basis. When I started
there, in 1981, I was told that we processed enough money in a week to
pay the National Debt. Needless to say, security and employee integrity
were incredibly important aspects in running the business. Nobody who
couldn't be bonded was even considered for employment. Any kind of
criminal record, other than traffic violations, was also a "career
limiting factor". Even downloading a file to a diskette was forbidden
except with management approval; and the actual download was done by the
Security staff!

previous post:
http://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords

when we were working on the stuff that has since come to be called e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

one of the things we tried to specify was FBI background checks on all
employees of merchant e-commerce business ... it never happened. a few
old references:
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm21.htm#34 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2005v.html#4 ABN Tape - Found
http://www.garlic.com/~lynn/2006.html#33 The new High Assurance SSL Certificates
http://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#30 Caller ID "spoofing"

now, one of the things that should be done is an end-to-end threat
analysis ... and then you define your security countermeasures to the
analyzed threats ... slightly related blog discussion:
http://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#12 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#14 Who has a Core Competency in Security?

part of the threat analysis is understanding the magnitude of the
threat ... so that it is possible to design security proportional to
the risk ... old e-commerce risk magnitude analysis
http://www.garlic.com/~lynn/2001h.html#61

now, you can have all sort of vulnerabilities and exploits ... when
there has been inadequate analysis of the end-to-end threats ... and
possibly only concentrate on a single (or at most a few) *point*
countermeasures (w/o actually having done the end-to-end threat
analysis)
http://www.garlic.com/~lynn/aadsm25.htm#20

recent post about this scenario involving the yes card exploits:
http://www.garlic.com/~lynn/aadsm26.htm#21

lots of yes card past posts
http://www.garlic.com/~lynn/subintegrity.html#yescard

and, of course, one of the major issues has always been "insider
threats" ... which typically have always been considered larger risk
than outsider attacks .... recent posts including some statistics on
insider threats:
http://www.garlic.com/~lynn/aadsm26.htm#7
http://www.garlic.com/~lynn/aadsm26.htm#11

reference to old event involving internet box for the largest online
service provider (at the time)
http://www.garlic.com/~lynn/aadsm26.htm#17 Changing the Mantra -- RFC 4732 on rethinking DOS

part of the issue was that this specific problem went on for two
months while they had a large number of "experts" come in to look at
the problem. When they came to us (after two months), it was readily
apparent ... in part because we had earlier done detailed
vulnerability and threat analysis as part of turning out ha/cmp
product
http://www.garlic.com/~lynn/subtopic.html#hacmp

a more recent issue in the press is a lot of the data breaches and
security breaches ... especially involving account numbers ... recent
post outline diametrically opposing requirements for account numbers
(post that looks at this threat as well as several others)
http://www.garlic.com/~lynn/2006v.html#49
http://www.garlic.com/~lynn/aadsm26.htm#8

and that even if the planet was buried under miles of information
hiding encryption, it still wouldn't stop account number leakage
http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007

Mainframe vs. "Server" (Was Just another example of mainframe

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe vs. "Server" (Was Just another example of mainframe
 costs.)
Newsgroups: bit.listserv.ibm-main
Date: Tue, 09 Jan 2007 17:20:54 -0700

Charles Mills wrote:

Pet peeve. Saying mainframes versus servers is like saying Fords versus
cars. A mainframe typically IS a server (often among other roles). The first
definition Google comes up with for server is "A computer that delivers
information and software to other computers linked by a network." I would
quibble with that definition (server is also used to describe software) but
it certainly fits most mainframes. IBM lists "System Z" under Servers on
their home page so I think IBM agrees with this theory.

If we mean "**ix and Windows boxes" or "non-mainframe boxes" then let's say
that.

I'm not just quibbling over semantics. When I read "vendors are promoting
server solutions" I get a totally different image in my mind versus that
which I get when I read "vendors are promoting **ix and Windows solutions."

While I'm here, I don't think non-mainframe platforms are inherently more
profitable for software vendors. Indeed, the traditional mainframe software
vendors have struggled trying to achieve the same profitability with their
"other box" offerings. Non-mainframe platforms are attractive and profitable
for software vendors because that is where BOD and CIO focus is.

this was long struggle/battle with the communication group. my wife
constantly ran into it, first when she co-authored AWP39, peer-to-peer
networking in the same timeframe as SNA was getting started. recent
posting referring to that period
http://www.garlic.com/~lynn/2006x.html#8 vmshare

... then later when she was con'ed into going to POK to be in charge of
loosely-coupled architecture and authored peer-coupled shared data
architecture
http://www.garlic.com/~lynn/submain.html#shareddata

which didn't see a lot of uptake, except for IMS hot-standby, until
sysplex. however, there was also constant battles with the communication
group ... pushing master/slave, dumb terminal paradigm. there was
eventually some truce where peer-to-peer could be used within glass
house walls ... but dumb terminal paradigm had exclusive control over
crossing glasshouse boundary.

along came PCs ... and dumb terminal emulation helped see PCs have quite
a bit of uptake early on. however, later when the PCs started to move
into client/server ... it started to really impact the dumb terminal
emulation install base.
http://www.garlic.com/~lynn/subnetwork.html#emulation

About the time we had come up with 3-tier architecture and was out
pushing it in customer executive presentations, the communication
group had come up with SAA. SAA could somewhat be construed as
attempts to put the client/server genie back into the bottle ... and
we were taking lots of hits from SAA and the communication group about
pushing 3-tier
http://www.garlic.com/~lynn/subnetwork.html#3tier

in that same time-frame ... the disk division had come up with a
number of products that would have allowed extremely high-bandwidth
between the distributed environment and potential glasshouse
servers. The communication organization consistently managed to have
such products shot down (based on communication group "owning"
everything crossing the boundary with the glasshouse). Finally, one of
the high-level senior disk engineers managed to get a talk scheduled
for the annual, world-wide communication group's internal
conference. However, it didn't quite start out as advertised, since he
opened the talk by stating that the communication group was going to
be responsible for the demise of the disk division (because the
stranglehold that the communication group had on the glasshouse was
resulting it huge leakage/replication of glasshouse data out into the
distributed environment, there were hard numbers about the annual
migration/leakage percentage over a number of years). past posts
mentioning the talk claiming demise of the disk division.
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2003p.html#39 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64?
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006x.html#7 vmshare

==========

some somewhat related activity with regard to NSFNET
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)
http://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)

Special characters in passwords was Re: RACF - Password rules

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Special characters in passwords was Re: RACF - Password rules
Newsgroups: bit.listserv.ibm-main
Date: Wed, 10 Jan 2007 09:21:53 -0700

R.S. writes:

Additional security also raises the price. Almost always.
Additional complexity doesn't always mean additional security,
sometimes the opposite.

any add-on features increase complexity ... complexity increases costs
... complexity also tends to make infrastructures more vulnerable and
fragile ... with failures tending to happen in unexpected ways. I've even
used the analogy between various after-market/add-on security features and
after-market automobile seat belts back in the 60s.

security (actually almost any characteristic) guideline has been that
it has to be built in as part of the base infrastructure and KISS.

as before, misc. past posts mentioning fraud, vulnerabilities, threats,
exploits, risk
http://www.garlic.com/~lynn/subintegrity.html#fraud

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

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

shared-secrets like pin and passwords
http://www.garlic.com/~lynn/subintegrity.html#secrets

work sort-of ok, as something you know authentication when the
person had one (or at most a very few) shared-secret to remember. a
problem is the paradigm scales up very poorly. however, a lot of
institutions continue to make believe that they are the one and only
security domain that a user has to deal with (and therefor theirs is
the only password the person needs to remember).

in reality, many people are dealing with scores of unique security
domains and therefor dealing with large number of places requiring
authentication. when the authentication is a (static) shared-secret,
the requirement is that there be a unique value per security domain
(as countermeasure to cross-domain attacks).

previous posts in this thread
http://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Wed, 10 Jan 2007 09:43:31 -0700

krw <krw@att.bizzzz> writes:

VF never cared what real CP it was running on.  One had to
guarantee the master keys were loaded correctly on a physical CF
before allowing work to proceed on that CP.

vector has (lots of) registers ... like general purpose registers
... they were saved and reloaded as part of context switches
... virtualization needs to save & restore context for specific
process ... just like any other kind of context switch ... unless
hardware had support for tagging different context/process ... like
virtual memory TLB (table look-aside buffer) keeping track of multiple
different address spaces ... so context switch only has to switch some
sort of context/process indicator.

i.e. recent posts mentioning VF
http://www.garlic.com/~lynn/2007.html#45 Just another example of mainframe costs

there were some games that if there were a very few processes using
vector ... they would disable vector capability for processes not
requiring it. then if the same process that was previously using
vector was resumed (on the same processor) ... they could avoid the
save/resume. there was possibility that vector capability might not be
installed on all processors in a processor complex ... so you might
have to deal with dispatching on processor with vector capability
... as well as attempting to redispatch on same processor previously
run (attempting to avoid save/restore overhead).

loaded crypto keys are effectively a special type of register ... so
you could require a good context-switch save/restore process defined
for them

Special characters in passwords was Re: RACF - Password rules

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Special characters in passwords was Re: RACF - Password rules
Newsgroups: bit.listserv.ibm-main
Date: Wed, 10 Jan 2007 11:36:08 -0700

Howard Brazee writes:

One of the tough choices programmers come up with is when a 30 year
old program that has been modified every year - should be replaced.

This type of decision becomes more difficult with people who design
operating systems and systems that interface with other systems.

in much of the 90s, the biggest (internet) related threats were from
buffer overflow exploits ... mostly related to c language
programming conventions. lots of posts on this topic
http://www.garlic.com/~lynn/subintegrity.html#overflow

implementations done in other languages suffered much fewer (or none)
overflow exploits. I know of none in the original mainframe tcp/ip
done in vs/pascal ... i had done the enhancement to support rfc 1044
... base thruput (on 3090) was something like 44kbytes/sec aggregate
thruput ... some tuning at cray research between 4341-clone and cray,
the rfc 1044 support was getting 1mbyte/sec ... misc. past posts
http://www.garlic.com/~lynn/subnetwork.html#1044

similarly, it has been claimed that there were no known buffer overflow exploits in Multics (implemented in PLI) ... some past posts.
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

for some drift, multics was on the 5th floor ... and the science
center was on the 4th floor
http://www.garlic.com/~lynn/subtopic.html#545tech

which brought you virtual machines, the internal network (from which
came bitnet/earn), gml precursor to sgml, html, xml, etc), and loads
of other online and interactive tools.

around the turn of the century ... because of the introduction of
automatic scripting ... the exploits started to shift to half
overflows and half automatic scripting (i.e. files or email arriving
from the network would include script code that would be automatically
executed).

I had tried to categorize information from various exploit databases
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE

... looking to enhance my merged security taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glosnote

however, the descriptions were quite free form and I complained that
they could be quite difficult to categorize. since then there have
been some announcements that they would be adding more structure to
exploit database entries to aid categorization

later a more extensive exploit study ... including various human
factor characteristics came up with 1/3rd overloads, 1/3rd automatic
scripting and 1/3 social engineering. social engineering includes
phishing, convincing people to divulge information, convincing people
to execute programs arriving over the network, etc.

some of the suggestions for transition to dumb devices ... isn't so
much whether they are dumb or not ... it is whether they support
loading and execution of foreign (and potentially extremely hostile)
code. turns out that vast majority of devices that have been
classified as "dumb" are providing features for loading and execution
of foreign code (of one sort or another).

this is a problem we had to deal with on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

a couple decades ago ... and a flavor of it showed up on bitnet/earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

even before showing up on the internet ... ref ...
http://www.garlic.com/~lynn/2005b.html#20 Buffer overruns

one of the other issues with "smart" vis-a-vis "dumb" devices
connected to the internet ... is one of the most prevalent platforms
dates back to something that was designed to operate in totally
unconnected environment ... and as such had no defenses and
countermeasures. some number of applications even grew up
taking advantage of being able to assume complete control of the
machine (like games). later ... adding internet connectivity to the
same platform created quite a bit of a problem a) platform that was
designed to have no defenses and countermeasures, b) large set
of applications that took advantage of the platform not having
defenses and countermeasures and c) connected to an extremely
hostile network environment which requires significant defenses and
countermeasures.

recently there has been some work on using virtualization in attempt
to address the diametrically opposing requirements ... no defenses and
countermeasures at the same time requiring very extensive
defenses and countermeasures.

other posts in this thread:
http://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules

for (lots of) other drift ... i designed the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

for something you have authentication ... from 3-factor
authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

its secret is never divulged and its authentication information always
changes ... so there is nothing to skim/eavesdrop for replay
attacks. it isn't prone to the standard phishing attacks ...
since the secret is never divulged ... even the owner doesn't know the
secret (and therefor can't divulge it). It also has absolutely no
provision for external loading/executing any sort of foreign code. It
uses public key ... so the same public key can be registered in lots
of different security domains w/o exposure to cross-domain
attacks (like you have with shared-secret something you
know paradigms).

it was done somewhat in conjunction with work by the x9a10 financial
standard working group, which in the mid-90s had been given the
requirement to preserve the integrity of the financial
infrastructure for all retail payments ... resulting in the x9.59
standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

one of the issues that was becoming prevalent in the mid-90s was
skimming of static authentication information and transactions where
just knowing the account number was sufficient. combination of x9.59
and aads eliminated static authentication information and also
eliminated transactions where account number by itself was no longer
sufficient. when account number by itself is no longer sufficient for
(fraudulent) transactions ... much of the risk is eliminated from the
majority of the recent data breaches and security
breaches (being able to obtain records/logs of old transactions
and replay the account number in new fraudulent transactions).

misc. recent posts
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007

aads chip strawman also had work on how to make the same token
acceptable to lots of different institutions (i.e. not the same kind
of token ... but the same token belonging to a person) as an
authentication mechanism. Current infrastructure tends to have
institutions providing each person, individual tokens. I've claimed
that if this was consistently followed ... a person would have nearly
as much difficulty dealing with large scores of tokens as they
currently have trying to deal with large scores of passwords. some
past posts about trying to move from a institution-centric paradigm to
a person-centric paradigm ... misc. past posts discussion
institution-centric paradigm vis-a-vis person-centric paradigm:
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
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/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
http://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?

special characters in passwords

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: special characters in passwords
Newsgroups: bit.listserv.ibm-main
Date: Wed, 10 Jan 2007 13:00:03 -0700

Arthur T. wrote:

also didn't list some minor ones (like the code to the push-button locks
on the doors).  I also didn't list all of the passwords and PINs needed
in my personal life.  Note that in about a quarter of the above, I could
not be sure that the password was end-to-end encrypted, and thus had to
be different from all other passwords.

     I believe that when Schneier said to write down passwords, he did
mean work-related ones, too.  And I agree.  The alternative is that
you'll have people with the same password on a weak system (maybe
internal website) as a strong system (mainframe RACF).

it doesn't have to be two different "strong" systems ... the major
source of exploits, compromises, fraud ... etc are insiders ... all it
takes is an insider in one domain, using common password to attack
some other domain.

slight analogy is that compromised merchant point-of-sale terminals
are typically used to skim/harvest information and then (effectively
replay) attack at some completely different merchant ... as opposed to
using a compromised point-of-sale terminal to directly do fraudulent
transactions.

there is also a analogy with SSL used for encrypting financial
transactions ... there are an enormous number of areas where the
financial transaction as accessed and stored ... while SSL is only
used to hide the information for a fleeting moment while it transits
the internet.

in any case, that was one of the reasons i took a look at what would
be necessary to morph from an institutional-centric authentication
paradigm to a person-centric authentication paradigm ... previous post
in thread:
http://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was: Re: RACF - Password rules

a prevalent and widely deployed single-sign-on infrastructure is based
on kerberos ... a couple recent posts mentioning kerberos
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://www.garlic.com/~lynn/2007.html#32 V2X2 vs. Shark (SnapShot v. FlashCopy)

and lots of past posts mentioning kerberos and/or pk-init (i.e. where a
public key is registered in lieu of kerberos password and using the
public key to authenticate digital signature)
http://www.garlic.com/~lynn/subpubkey.html#kerberos

Just another example of mainframe costs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Just another example of mainframe costs.
Newsgroups: bit.listserv.ibm-main
Date: Wed, 10 Jan 2007 19:47:34 -0700

some more topic drift, three old emails from jan86, a couple about
dispatching/scheduling (including vm/xa sp1) and one more on global
LRU.

vmshare archive:
http://vm.marist.edu/~vmshare/

Following vmshare memo was forwarded to me from bitnet ... the vmshare
posting was at loss to figure out what had happened in HPO3.4


To: wheeler
Date: Sat, 11 Jan 1986 15:26:02 EST
Subject:  From VMSHARE....

<<< PROB HPOGRIND - 48 lines, 0 append(s) >>>

HPO 3.4 allows a user to run away with the CPU

One of the reasons we were always happy to pay to get a Wheeler
scheduler, beginning way back in the PRPQ days, was that it did such a
good job of protecting other users from a CPU hog.

Indeed, several times a year we would have a user panic because he had
just discovered that his computer account was overdrawn by several
thousand dollars.  The scenario was always the same.  He had invoked a
program or EXEC he was working on; his terminal had gone dead, so he
had gone home for the night.  A couple of days later, he tried to
logon again, found himself still logged on, and asked the operators to
force him.  That's when he found he had no money left.  Then he would
come to us.  We'd tell him about loops, ask him not to do that again,
and give him his money back.

The interesting part of all this is that the Wheeler Scheduler had
been doing such a good job of protecting the system from the looping
user, that nobody had noticed him.  The scheduler just kept him in the
background absorbing the spare cycles, but didn't let him use the
cycles somebody else wanted.

This is not at all the way the HPO 3.4 scheduler works, however.  In
the year we've been running it, we have seen numerous cases in which
one or two heavy CPU users severely degraded the performance of the
entire system.

These people are not paging heavily and are not doing a lot of I/O.
(VM has never done a real good job of containing users who put
excessive loads on memory/paging or I/O.)  They are using CPU only and
generally have very small working sets.  Typically, their TVRATIO's
are 1.0.

And the HPO 3.4 scheduler lets a single such user have as much as 90%
of one processor in the middle of the afternoon, when there are plenty
of other users who need (and deserve) some of those cycles.

I'm rather at a loss to figure out how to approach IBM on this
problem.  I don't want to be told that the scheduler is working as
designed.  Does anybody have any suggestions?  Also, do other people
see this problem?

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

somewhat related
http://www.garlic.com/~lynn/2007.html#45 Just another example of mainframe costs
old email about vm/xa sp1
http://www.garlic.com/~lynn/2007.html#email850304

and following reply in response to my forwarding the above to the
each coast


Date: 01/13/86 17:45:45
To: wheeler

Re:   PROB HPOGRIND

Have you talked to XXXXXX about this?  Awhile back (3 months or
more) he was aware of this problem and had installed a fix here on
the KGNVMC system that put the CPU hogs back in their proper place.
His comment to me at the time was that people had been tampering with
the scheduler over a period of years and some of the logic from your
scheduler for ordering the dispatch list had been messed up.

XXXXXX fix must have done something right for I remember YYYYYY
complaining to me about it at the time.  YYYYYY was one of the CPU
hogs at that time, doing half hour data-reduction runs to generate
reports from LSPM and/or Monitor tapes from large performance runs
that he was doing on a regular basis.  When he complained, I told him
he was just being put in his proper place.  He said, well his work was
more valuable than most of the other work being done on KGNVMC, that
the rest was mostly just managers and secretaries using PROFs.  So I
said, well it takes only 5ms to do a trivial transaction, and then the
user doesn't come back for several seconds... but your stuff wants to
use 1000ms every second.  Is your stuff really 200 times (or more) as
valuable as those secretaries' time?

YYYYYY was just kidding anyway about his stuff being more valuable...
just taking the opportunity to moane and groan a little over the fact
that he was no longer running as fast as he once had.  He agreed that
the change XXXXXX had made was really a change for the better, though
it did make things worse for him.

The VM/XA SF dispatch ordering should do a good job of keeping the
CPU hogs from taking more than their share of CPU.  There the consumption
of CPU cycles causes a user to move downward in the list.  The speed of
a user's downward movement is exactly proportional to the amount of CPU
he uses (assuming he has the same SHARE as other users).  There are still
some minor opportunities for that mechanism to go astray, but these will
be fixed in VM/XA SP1.  (The main problem I'm thinking of that will be
fixed is that, in SF, if a user stops or slows down using CPU, he rises
very high in the list.  Then if he later becomes CPU bound, he can be so
far above everyone else that, even though he moves down rapidly, he
blocks the other users out for long enough to have a noticeable impact.
We knew this was a theoretical problem when we designed SF1, but didn't
have time to fix it.  So far it doesn't seem to be a noticeable problem
here on the SF1 system where we run SF1 on a 3081, though on a single-CPU
system it might be more noticeable.  Anyway, VM/XA SP1 will fix it.)

Regards,

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

Another old email from the east coast referring about system changes returning
to global LRU
http://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?
and email from 19jan86
http://www.garlic.com/~lynn/2006y.html#email860119

This is email from somebody commenting on early testing of HPO changes
to return to global LRU, indicating that as load increases,
global LRU is having to do less paging (than base comparison).


Date: 14 January 1986, 01:41:58 EST
To: distribution

An interesting perspective, especially when one considers that
global LRU seems to transfer substantially fewer pages per second
(combined page and swap) as the main storage demand increases.

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

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Wed, 10 Jan 2007 22:28:59 -0700

krw <krw@att.bizzzz> writes:

No, they're not like a normal register and save/restore context
will not work.  First of all, there is only one master key per
system image (one per LPAR).  Second of all, the master keys were
*never* stored in memory so couldn't be swapped anywhere. In fact
they were stored in SRLs that had the scan chains broken so even
the service processor could' tlook at them.  Master keys were
loaded from a secure (FIPS 140 level 4) "Key Management Unit" at
power on/reset.  To change a master key required at least two
trusted people (usually corporate VPs) interfaced directly (as in
pushed the buttons and watched the blinkin' lights) with the KSU
(and of course the system software (ICSF).

re:
http://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#1 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#4 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#5 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#11 How many 36-bit Unix ports in the old days?

if you were really designing something where context could be
saved/restored for process switch ... then it would need to have some
equivalent mechanism. so what would be equivalent method to
save/restore such information? either it supports save/restore
associated with process/context change ... or it doesn't. if it
doesn't ... then it pretty much assumes dedicated environment.

if it is a dedicated environment paradigm ... and attempting to attach
it to a paradigm that has context switches and requires save/restore
... is a mismatch of the two different paradigms. Doesn't make either
wrong ... just makes them inconsistent.

V2X2 vs. Shark (SnapShot v. FlashCopy)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Thu, 11 Jan 2007 08:23:08 -0700

re:
http://www.garlic.com/~lynn/2007.html#32 V2X2 vs. Shark (SnapShot v. FlashCopy)

and another MEDUSA (cluster-in-a-rack) ... somewhat leading up to
here (and then a few days later being told the project was being
transferred and we weren't suppose to work on anything with more
than four processors)
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

and first email in this thread from 10sep91
http://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones


Date: Sat, 28 Sep 91 17:53:58 EST
From: wheeler
To: distribution
Subject: MEDUSA

The opportunity in MEDUSA is to take the 1in high rack-mount RISC/6000
card and turn it into problem solution. The characteristics of the
card is essentially a smaller RISC/6000 planner with no microchannel,
and/or other types of I/O interface.  The board has room for the
RISC/6000 processor chip set, the SIO bus, 64mbytes to 256mbytes of
memory. This is effective all off the shelf components requiring
essentially no invention to achieve the 1in rack packaging. Given a 4in
high rack 64x64 ANCOR FCS ...  switch, it is possible to package the
ANCOR 4in high switch and 32 MEDUSA boxes in the same rack.

** foil for the MEDUSA rack

** MEDUSA biggest bang for the buck

  a) database/OLTP engine in addition to 32-way high-speed parallel
     compute server
  b) MEDUSA can ship with OSF/DCE providing the earliest RISC/6000
     version of OSF. Lack of the 15k different device drivers for
     OSF on RISC/6000 platform isn't a problem in the MEDUSA
     configuration.
  c) Oracle is already porting OSF/DCE to a 6000/320 in an attempt
     to be the first player on the block with Transarc/OLTP support
  d) Oracle N-cube support should be a straightforward
     and efficient translation to a MEDUSA configuration

** MEDUSA becomes one of the first & major OLTP player

  a) ship early OSF/DCE/Transarc/CICS 3q/92
  b) Oracle ships MEDUSA/cics support 3q/92 with
     easily much >tcp-a than their n-cube runs
     (and hopefully better price/transaction)
  c) as mentioned in various HA/6000 documentation
     this OLTP market is a $30B business opportunity

** MEDUSA still plays in the parallel compute server
   market all over the place. support requirements are:
  a) nqs
  b) isis
  c) etc.

** cooperative work

  OLTP
   a) osf & transarc
   b) cics
   c) oracle & others

  Compute servers
   a) find/use existing technology
   b) numerous existing mach/osf based projects in
      distributed and parallel computing

**

   * no invention
   * low risk
   * little development
   * primarily product packaging activity
   * early tactical entry directly on strategic path
   * enormous business opportunity

 ................................................

considerations:

tpc-a requires supporting ACID. disk acid requires disk mirroring &/or
raid (for OLTP, raid-5).

For processor acid ... either use ha/6000 with a pairs of MEDUSA's
(i.e. two racks, two independent power supplies, 64 processors total)
or create an "highly-available" MEDUSA rack with at least two power
supplies.

In a highly-available MEDUSA rack, the simplest would be to attach 16
processors to one power supply and 16 processors to the other power
supply. Slightly more complex would be to make the 1in processor
components hot pluggable into a pair of power buses. The two power
supplies would provide two power buses that all 32 processors could
connect to with some sort of capability for a processor component to
switch from being active on one bus to the other bus.

unitree scale-up into MEDUSA configurations for managing large disk
farms along with appropriate library devices. scale-up into aggregate
2500+ mip range.

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

other old MEDUSA email from the period
http://www.garlic.com/~lynn/lhwemail.html#medusa

I had done some work on high-density compute rack configurations in
84/85 time-frame ... but the technology for "high-density" was
somewhat different at that time (although it included 32-bit 801 iliad
chip) ... past post
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

and past postings mentioning MEDUSA (cluster-in-a-rack)
http://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
http://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#38 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#39 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#41 Why so little parallelism?
http://www.garlic.com/~lynn/2006x.html#11 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)
http://www.garlic.com/~lynn/2007.html#32 V2X2 vs. Shark (SnapShot v. FlashCopy)

====

... for other drift ... ACID is DBMS transaction related term
http://www.garlic.com/~lynn/2001.html#6 Disk drive behavior
http://www.garlic.com/~lynn/2002d.html#5 IBM Mainframe at home
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004q.html#27 1GB  Tables as Classes, or Tables as Types, and all that
http://www.garlic.com/~lynn/2004q.html#75 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#32 the relational model of data objects *and* program objects
http://www.garlic.com/~lynn/2005k.html#1 More on garbage
http://www.garlic.com/~lynn/2005r.html#23 OS's with loadable filesystem support?
http://www.garlic.com/~lynn/2006l.html#24 Google Architecture
http://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?

and posts mentioning original relational/sql System/R
http://www.garlic.com/~lynn/submain.html#systemr

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Thu, 11 Jan 2007 12:12:48 -0700

jmfbahciv writes:

They always have been.  It's not a problem when it's a fact of life.
It is the computer biz' job to provide systems that customers can
use efficiently and be able to change as their businesses evolve.

from email recently sent to me off-list:

The Standish Group's original study concluded that software projects
costing less than $1 Mil had a probability of success of 54%, projects
costing 1-5 Mil or thereabouts had a probability of success of 17% and
projects over $5 Mil had a probability of success of only 7%.  These
numbers are probably over five years old but the results may still be
the same.

... snip ...

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Thu, 11 Jan 2007 12:39:09 -0700

Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:

IBM systems have had the notion of VARYing OFF/ON components (including
CPUs) since OS/360, although at various times the wiring and packaging
have resulted in less independent components e.g. opening an interlocked
door powers off various bits: oops!
We started halting the processor for a few seconds, to disconnect the
cables for maintenance, then pressed continue ro resume work.

one of the issues were in I/O interconnected systems
(i.e. multi-channel control units) ... that didn't have fully
coordinated loosely-coupled operation. in those configurations, it was
quite common to "VARY OFF" a device (frequently a tape drive) on one
system and then "VARY ON" the same device for another system.

old thread that discussed loosely-coupled (mainframe for cluster) and
tightly-coupled (mainframe for shared-memory smp) 360 systems.
http://www.garlic.com/~lynn/2004e.html#44 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004e.html#51 Infiniband - practicalities for small clusters

loosely-coupled relied on control units that had multiple channel
connections (where different channels were for different systems).

tightly-coupled relied on same facility to provide for simulating
symmetric I/O in a SMP shared-memory operation ... i.e. standard 360
SMP didn't have shared channel I/O ... it relied on processor specific
dedicated channels to be configured for common control units (to
achieve simulated symmetric i/o operation). Exception was 360/67 smp
which had a "channel director" that supported all processors accessing
all channels.

as I've mentioned before, my wife was con'ed into doing a stint
in POK in charge of (mainframe) loosely-coupled architecture ...
where she authored peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

misc. past posts mentioning loosely-coupled, clusters, ha/cmp, etc
http://www.garlic.com/~lynn/subtopic.html#hacmp

and misc. past posts mentioning tightly-coupled, smp, &/or
compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Thu, 11 Jan 2007 12:43:58 -0700

Rich Alderson <news@alderson.users.panix.com> writes:

IBM didn't have "dis{k,c}s", they had "DASD".  No smiley.

IBM had drums, data cells, disks, etc ... early on they coined the
term DASD (direct access storage device) to collectively apply to all
(since in that period, it possibly wasn't clear that any were clearly
dominant).

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Thu, 11 Jan 2007 21:50:31 -0700

krw <krw@att.bizzzz> writes:

The master keys, by design, can *never* be in memory (or any place
viewable by the system), nor can any other key be in memory "in the
clear".  Security is easily breached otherwise.

re:
http://www.garlic.com/~lynn/2007b.html#15 How many 36-bit Unix ports in the old days?

sorry, my statement wasn't with regard to why it couldn't be done, it
was with regard to was there anyway could it be done. this is along
the lines of some past threads about why some architectures were
virtualizable and other architectures weren't virtualizable

... for instance ...
http://www.garlic.com/~lynn/93.html#3 Self-virtualization and CPUs
http://www.garlic.com/~lynn/97.html#26 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/97.html#27 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2000g.html#4 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2000g.html#6 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2003p.html#40 virtual-machine theory

=====

in the original 360 and 370 ... architecture was software
virtualizable "recursively" to arbitrary level ... i've related before
how cambridge ran cms under three levels of virtual machine kernels
(cp67l on real hardware, cp67h in a 360/67 virtual machine providing
370 virtual machines, cp67i in a 370 virtual machine providing 370
virtual machines ... which ran cms).

there have been some architectures that weren't arbitrarily
virtualizable .... some had special hardware assist that enabled
special case virtualizing ... initially only a single level.

one of the architecture features in 360 & 370 that was instrumental in
enabling virtualizing was there was a single instruction that 1)
changed address space, 2) changed problem/supervisor state, and 3)
changed instruction address. this allowed switching from the virtual
hypervisor 1) address space, 2) supervisor state, and 3) instruction
address to the virtual machine's 1) address space, 2) problem state,
and 3) instruction address. this wasn't the only requirement ... but
it was important enabler.

for other kind of drift ... typically master keys that never appear in
memory will satisfy a specific security (classification level)
requirement ... say as a countermeasure to specific threat(s) ... like
insiders that might have access to privilege system storage.

we had an example of this with regard to applying security
classification levels to different kinds of personal information
... for the purpose of establishing the level of protection the
information required. we recommended that instead of just doing
straight-forward security classification level attributes, that the
information attributes should also include the threats. the
classification attribute scenario basically resulted in levels/degrees
of information hiding (encryption) as a security solution.  turns out
that also understanding the actual threats can result in coming up
with other security measures (than simple information hiding).

some of this is from security PAIN acronym

P ... privacy (sometimes CAIN & confidential)
A ... authentication
I ... integrity
N ... non-repudiation

recent reference mentioning that (some specific scenarios) ...
even if the planet was buried under miles of (information hiding)
encryption ... that it still couldn't prevent (certain kinds
of) information leakage
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules

history question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: history question
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Fri, 12 Jan 2007 08:43:30 -0700

John McKown wrote:

Just for my curiousity. Was CP-67 the first virtualization engine ever
produced? Or did some other company have this type of ability before IBM
did it?

cp40 predated cp67.

the science center really wanted a 360/50 to modify for virtual memory
... but all of the spare 50s were going to the FAA ... so they had to
settle for 360/40. when 360/67 finally became available they ported
cp40 to cp67. lots of posts mentioning the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

recent post mentioning some wiki entries about cp/cms
http://www.garlic.com/~lynn/2007.html#8 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#12 "The Elements of Programming Style"

a couple other posts in that thread
http://www.garlic.com/~lynn/2006y.html#20 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006y.html#34 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"

not the 60s ... but index of old email (mostly from the 70s and 80s), much
of it vm related
http://www.garlic.com/~lynn/lhwemail.html

=====

and large number of past posts mentioning cp40
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#37 SIE instruction (S/390)
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/98.html#33 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/99.html#126 Dispute about Internet's origins
http://www.garlic.com/~lynn/99.html#139 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/99.html#142 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/99.html#174 S/360 history
http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
http://www.garlic.com/~lynn/2000.html#52 Correct usage of "Image" ???
http://www.garlic.com/~lynn/2000.html#81 Ux's good points.
http://www.garlic.com/~lynn/2000.html#82 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#42 Domainatrix - the final word
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000e.html#16 First OS with 'User' concept?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#59 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
http://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#46 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2002b.html#6 Microcode?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#8 TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#36 Blade architectures
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002h.html#62 history of CMS
http://www.garlic.com/~lynn/2002h.html#70 history of CMS
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002l.html#22 Computer Architectures
http://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003f.html#2 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2003g.html#33 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003k.html#5 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#24 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003m.html#4 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#16 OSI not quite dead yet
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#34 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#36 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003o.html#32 who invented the "popup" ?
http://www.garlic.com/~lynn/2003o.html#47 Funny Micro$oft patent
http://www.garlic.com/~lynn/2004.html#45 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004b.html#0 Is DOS unix?
http://www.garlic.com/~lynn/2004c.html#11 40yrs, science center, feb. 1964
http://www.garlic.com/~lynn/2004c.html#25 More complex operations now a better choice?
http://www.garlic.com/~lynn/2004f.html#17 IBM 7094 Emulator - An historic moment?
http://www.garlic.com/~lynn/2004f.html#63 before execution does it require whole program 2 b loaded in
http://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#48 Hercules
http://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
http://www.garlic.com/~lynn/2004h.html#34 Which Monitor Would You Pick??????
http://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004n.html#3 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#25 Shipwrecks
http://www.garlic.com/~lynn/2005c.html#56 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005o.html#4 Robert Creasy, RIP
http://www.garlic.com/~lynn/2005s.html#21 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#23 winscape?
http://www.garlic.com/~lynn/2005u.html#47 The rise of the virtual machines
http://www.garlic.com/~lynn/2006.html#34 UMA vs SMP? Clarification of terminology
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006i.html#22 virtual memory
http://www.garlic.com/~lynn/2006i.html#30 virtual memory
http://www.garlic.com/~lynn/2006i.html#31 virtual memory
http://www.garlic.com/~lynn/2006i.html#32 virtual memory
http://www.garlic.com/~lynn/2006j.html#29 How to implement Lpars within Linux
http://www.garlic.com/~lynn/2006k.html#30 PDP-1
http://www.garlic.com/~lynn/2006k.html#41 PDP-1
http://www.garlic.com/~lynn/2006l.html#16 virtual memory
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?
http://www.garlic.com/~lynn/2006o.html#27 oops
http://www.garlic.com/~lynn/2006o.html#29 oops, cics
http://www.garlic.com/~lynn/2006s.html#21 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006s.html#65 Paranoia..Paranoia..Am I on the right track?.. any help please?
http://www.garlic.com/~lynn/2006t.html#23 threads versus task
http://www.garlic.com/~lynn/2006w.html#22 Are hypervisors the new foundation for system software?
http://www.garlic.com/~lynn/2006x.html#23 Multiple mappings

sealand up for sale

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sealand up for sale
Newsgroups: alt.folklore.computers
Date: Fri, 12 Jan 2007 08:58:42 -0700

re:
http://www.garlic.com/~lynn/2007b.html#0 sealand up for sale

Pirate Bay to Purchase Sealand?
http://yro.slashdot.org/yro/07/01/12/1345244.shtml

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Fri, 12 Jan 2007 09:54:37 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

sorry, my statement wasn't with regard to why it couldn't be done, it
was with regard to was there anyway could it be done. this is along
the lines of some past threads about why some architectures were
virtualizable and other architectures weren't virtualizable

re:
http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?

so for some other virtualizable topic drift (ref mid-60s, 40+ yrs ago)
http://www.garlic.com/~lynn/2007b.html#21 history question

and some more virtualizable topic drift ... a fewURLs mentioning the
subject from the past week or so
Virtually Speaking: Virtualizing in the Real World
http://www.serverwatch.com/news/article.php/3653636
Automation and Virtualization Software Provider for the Web Hosting
Industry Updates PEM Data Center Automation Solution
http://www.hostsearch.com/news/swsoft_news_5474.asp
Virtualization and ILM 2006: Looking Back
http://www.it-director.com/business/content.php?cid=9148
Linux KVM Virtualization Performance
http://www.osnews.com/story.php?news_id=16886
Virtualization may redefine the software industry
http://blogs2.cio.com/node/475
Virtualization Gets A Grip In 2006
http://newsvac.newsforge.com/newsvac/07/01/06/0818236.shtml
Enterprise Virtualization,' System Consolidation and IP SANs Are
Powering the Wave
http://www.earthtimes.org/articles/show/news_press_release,40746.shtml
Grid, Virtualization Get Closer
http://www.enterpriseitplanet.com/networking/news/article.php/3651981
New year, new Linux virtualization options
http://searchservervirtualization.techtarget.com/originalContent/0,289142,sid94_gci1237121,00.html
Virtualization: Keeping the Processor Occupied
http://www.edn.com/blog/400000040/post/1780006178.html
Virtualize Now!
http://www.enterprisenetworksandservers.com/monthly/art.php?2899
New virtualisation system beats Xen to Linux kernel
http://www.techworld.com/opsys/news/index.cfm?newsID=7586&pagtype=all
New open source virtualisation from SWsoft
http://www.computerweekly.com/Articles/2006/12/14/220677/new-open-source-virtualisation-from-swsoft.htm
Getting Started with Virtualization
http://itmanagement.earthweb.com/article.php/3648836
Sun Solaris getting security, virtualization boosts
http://www.networkworld.com/news/2006/121206-sun-solaris-getting-security-virtualization.html

Forbidding Special characters in passwords

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Forbidding Special characters in passwords
Newsgroups: bit.listserv.ibm-main
Date: Fri, 12 Jan 2007 10:57:34 -0700

Tom Marchant wrote:

Ok, I stand corrected.  I've seen it posted here that RACF uses
the password as a key to encrypt the userid.  It seemed like a
good technique to me.  I was surprised at Mr. Schneier's comment
quoted above.

unix password file is publicly readable ... and used a similar
technique to obfuscate the passwords.

however an attack was to get a copy of the password file ... and run
thru all the password guesses, doing the transformation on each
password guess ... and compare it with what was in the file.  That was
why it was called password guessing ... since you just couldn't take
the password directly from the file.

the countermeasure is the shadow password file ... the publicly
readable password file was retained ... but with the password field
dummied out ... and the password file with the actual (obfuscated)
passwords were hidden away someplace.

the real countermeasure is to make it as hard as possible to obtain
the password file (making it more difficult to efficiently run the
guessing process). The password obfuscation technique is decades old
countermeasure predating efficient, automated guessing strategies.

other posts in this & related threads
http://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords

What is "command reject" trying to tell me?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is "command reject" trying to tell me?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 12 Jan 2007 12:29:43 -0700

Leland C. Sheppard wrote:

The CSW status (0E00) is showing a unit check.  Does the unit check
cause a CMD reject or does the CMD reject cause the unit check bit to be
set?

q&d conversion of gcard ios3270 to html
http://www.garlic.com/~lynn/gcard.html

greencard showed channel status word
http://www.garlic.com/~lynn/gcard.html#6

and unit check was an indication that a sense i/o operation was
required to obtain more detailed error information ... in fact, when
there was a unit check ... control units would go into contingent
connection and reflect SM+BUSY (control unit busy) to SIO for all
operations to any other (control unit) device ... it then would
present CUE (control unit end) interrupt ... with the interrupt giving
the address for the device with pending sense information.

green card didn't have sense information ... the 360/67 "blue" card
did have sense information for some number of devices. i updated some
of the device information (long ago and far away) and contributed it
to gcard ios3270

sense bytes for a few devices
http://www.garlic.com/~lynn/gcard.html#17

one of the "features" that I had to handle when rewrote the i/o supervisor for
the disk engineering and product test labs (bldg. 14 & 15) was contingent
connection scenario when the unit check interrupt hadn't been presented in
the correct order (i.e. control unit in contingent connection, appeared to
be solid SM+BUSY because the system hadn't seen the unit check interrupt
come in) ... recent posts with old early 80s email mentioning the work:
http://www.garlic.com/~lynn/2006y.html#34 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"

other past posts mentioning work for bldgs. 14&15:
http://www.garlic.com/~lynn/subtopic.html#disk

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Fri, 12 Jan 2007 14:27:38 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

so for some other virtualizable topic drift (ref mid-60s, 40+ yrs ago)
http://www.garlic.com/~lynn/2007b.html#21 history question

re:
http://www.garlic.com/~lynn/2007b.html#23 How many 36-bit Unix ports in the old days?

so other topic drift about virtualization and hobby i had playing around in
disk engineering and product test labs (bldg 14&15)
http://www.garlic.com/~lynn/2007b.html#25 What is "command reject" trying to tell me?

and from long ago and far away


From: wheeler
Date: 03/23/80  12:54:58

re: dedicated channel/FYI; -- We are working on modifying the
dedicated channel support so that nothing is queued in CP iobloks and
everything passes straight thru as it occurs, even cc=2 on sio &
channel available interrupts. Also for class F virtual machines, no
sense will be performed and it is up to the virtual machine (and CFPRD
to clear any possible contingent connection).

we have also given some thot to attached control units which would
work something like attached channels except cc=2 & channel available
interrupts would not be reflected.

Part of the problem is that the engineers would like to do extensive
dedicated channel type testing on all possible real channels. The 3033
has 16 channels and to have a dedicated channels requires that all 256
rdevbloks for a channel be defined. 256x16 rdevbloks is more than CP
can handle. Interim solution is to have two different cp nucleuses
with different combinations of rdevbloks for real channels and
schedule the cp system and the channels for particular tests.

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

the cp "rdevblok" problem was along the lines of the y2k problem ...
rdevblock was identified as 16bit displacement added to base address
where the machine i/o configuration was located. this failed when the
number of rdevbloks times the size of the rdevblok exceeded 64kbytes
(i.e. 16*256 is 4096 which only works if rdevblocks were no larger
than 16bytes). The "base" dedicated channel support was sort of a
special case of "dedicated device" ... but involved all possible
devices for the channel. This was a modification to attempt to just
transparently pass all operations for a dedicated channel
... eliminating as much as possible any virtualization intermediate
gorp.

some recent posts mentioning the 3033 in bldg. 15
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#18 virtual memory
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?

past posts mentioning getting to play around in bldg. 14&15:
http://www.garlic.com/~lynn/subtopic.html#disk

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Fri, 12 Jan 2007 14:48:37 -0700

Rich Alderson <news@alderson.users.panix.com> writes:

Yes, Lynn, and I started in the IBM world, for 8 years before I met my first
DEC-20.  I'm just a bit younger than you.  I still think in EBCDIC and have
an ASCII translation table, 30 years later.

I knew any number of folks in the IBM world who talked about, for example,
3380 DASDs.  Not disks, not discs, but DASDs.  Because that's what the IBM
documentation said.

i.e. it started out DASD ... and it seem that nobody ever got around
to changing it.

for other topic drift, original cp67 ... somewhat recent ref:
http://www.garlic.com/~lynn/2007b.html#21 history question

and
http://www.garlic.com/~lynn/2007.html#8 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#12 "The Elements of Programming Style"

only had 2741 and 1052 terminal support. one of the things i got to do
to cp67, as an undergraduate, was adding tty/ascii terminal support.
while it I was at it ... i tried to do it in such a way that it did
automatic terminal type identification ... which would have allowed
being able to have a common phone number (and common modem rotary
pool) for all terminals.

turns out that there was a short coming in the 2702 terminal control
unit ... which wouldn't quite allow me to do what i wanted.

that sort of prompted a university project to build our own (clone)
control unit ... initially out of an Interdata/3; reverse engineer the
channel interface and build our own channel interface board for the
Interdata/3. the project was wrote up blaming four of us for the clone
(PCM/plug compatible) controller business. ... misc. past post
http://www.garlic.com/~lynn/subtopic.html#360pcm

for other drift ... a couple recent posts about getting to play in the
disk (dasd) engineering and product test labs
http://www.garlic.com/~lynn/2007b.html#25 What is "command reject" trying to tell me?
http://www.garlic.com/~lynn/2007b.html#26 How many 36-bit Unix prots in the old days?

and other posts mentioning playing in bldg. 14&15 ... a lot of it
during the hey day of the development of the 3880 control unit and the
3380 "DASD".
http://www.garlic.com/~lynn/subtopic.html#disk

i nominally was working full-time in sjr (bldg. 28), but i would
frequently wander around ... across the street to bldg. 14&15
... sometimes down to STL (bldg. 90) .... recent post mentioning STL:
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"

 ... and other times out to the los gatos vlsi lab (bldg. 29) ...

and then other times up to the HONE complex (to supply them with
custom built operating systems, HONE provided world-wide support for
sales, marketing, and field people)
http://www.garlic.com/~lynn/subtopic.html#hone

or even drop in on customers.

What is "command reject" trying to tell me?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is "command reject" trying to tell me?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 12 Jan 2007 15:43:52 -0700

re:
http://www.garlic.com/~lynn/2007b.html#25 What is "command reject" trying to tell me?

and just for the fun of it ... another post mentioning contingent connection
http://www.garlic.com/~lynn/2007b.html#26 How many 36-bit Unix ports in the old days?

as i mentioned before
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?

... i was getting pulled into disk engineering meetings to help
resolve/work design issues. i was told it was because there had been
defection of so many of senior engineers (who were familiar with the
controller/channel interface, something i had to know in detail
... among other things in order to make virtualization code work
correctly). most recent set of defections (in the time-frame of the
following old email) were going to STK ... there was even a special
committee set-up to monitor the (defection to STK) situation.


From: wheeler
Date: 04/02/80  11:29:08

IOS meeting went alright. Most of the engineers didn't know anything
other than the DASD to controller interface. They will attempt to
contact POK channel engineers to get any written info that might
exist. They were a little surprised about what looks like a bug with
getting into contingent connection without a unit check.  I think they
have identified a 3880 problem which could lead to that situation. It
still looks like we need something to get out of a contingent
connection loop after we've gotten into it. One of the engineers may
have also found a problem with 3350 support in the 3880 having to do
with issuing HIO (HDV) to 3350 while control unit is busy (the bug may
also exist in the 3830 which would explain the problem in DMKIOSHA
about loosing interrupts on 3350s if you issue HDV while control unit
is busy.  This problem showed up at STL after a PTF was applied. The
official PTF now will only issue a HDV to a busy control unit if the
device is a CTCA, beginning to look like a software work around to a
hardware bug).

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

i fixed the referenced problem about 3880 forgetting to present unit
check ... by putting in limit count for consecutive controller SM+BUSY
operations ...  and then generating a sense against the interrupting
device address.

of course hardware isn't normally expected to do such stuff ... but
this was the engineering lab ... and i eventually had to handle all
sorts of anomalies that couldn't (weren't suppose to) ever happen.

other recent mention of stuff for bldg. 14&15
http://www.garlic.com/~lynn/2006y.html#34 "The Elements of Programming Style"

and another post that has old email mentioning the results of 3880
regression test with MVS that got me into a lot of hot water with the
manager of MVS RAS (even tho it was purely internal corporate email)
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"

other posts mentioning getting to play in bldg. 14&15
http://www.garlic.com/~lynn/subtopic.html#disk

was: How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: was: How many 36-bit Unix ports in the old days?
New