2007 Newsgroup postings (01/08 - 01/18) Lynn Wheeler

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
https://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?

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

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
https://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
https://www.garlic.com/~lynn/2006j.html#27 virtual memory
https://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
https://www.garlic.com/~lynn/2007.html#44 vm/sp1
https://www.garlic.com/~lynn/2007.html#45 Just another example of mainframe costs

recent posts mentioning 3090 service processor
https://www.garlic.com/~lynn/2007.html#18 IBM sues make of Intel-based Mainframe clones
https://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:
https://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
https://www.garlic.com/~lynn/2006u.html#9 The Future of CPUs: What's After Multi-Core?
https://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?

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

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:
https://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

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

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

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

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

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.

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

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)
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network
https://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications

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

========

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

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

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
https://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 ...
https://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
https://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):
https://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)
https://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)
https://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)

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

I've claimed that one of the reasons that the internal network
https://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
https://www.garlic.com/~lynn/internet.htm

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

Special characters in passwords was Re: RACF - Password rules

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

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).
https://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
https://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
https://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
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

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

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

information utility

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

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
https://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

in the early to mid-80s, the internal network
https://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
https://www.garlic.com/~lynn/2006w.html#35 Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones
https://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
https://www.garlic.com/~lynn/2006v.html#22 vmshare

and then there was CJNTEL ... 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.

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

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.

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

Hi There,

i added you to that auth file with authorization level 9, so you can invoke any/all of the commands including adding other people to it.

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
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

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

Special characters in passwords was Re: RACF - Password rules

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

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:
https://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
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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:
https://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm21.htm#34 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2005v.html#4 ABN Tape - Found
https://www.garlic.com/~lynn/2006.html#33 The new High Assurance SSL Certificates
https://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
https://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:
https://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#12 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?
https://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 risk ... old e-commerce risk magnitude analysis
https://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)
https://www.garlic.com/~lynn/aadsm25.htm#20

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

lots of yes card past posts
https://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:
https://www.garlic.com/~lynn/aadsm26.htm#7
https://www.garlic.com/~lynn/aadsm26.htm#11

reference to old event involving internet box for the largest online service provider (at the time)
https://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
https://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)
https://www.garlic.com/~lynn/2006v.html#49
https://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
https://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007

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

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

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
https://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
https://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.
https://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
https://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.
https://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2003p.html#39 Mainframe Emulation Solutions
https://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64?
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10 years later
https://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006x.html#7 vmshare

==========

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

Special characters in passwords was Re: RACF - Password rules

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

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
https://www.garlic.com/~lynn/subintegrity.html#fraud

from 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are

shared-secrets like pin and passwords
https://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
https://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was Re: RACF - Password rules
https://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
https://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

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

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
https://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
https://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.
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://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
https://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
https://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE

... looking to enhance my merged security taxonomy and glossary
https://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
https://www.garlic.com/~lynn/subnetwork.html#internalnet

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

even before showing up on the internet ... ref ...
https://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:
https://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
https://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
https://www.garlic.com/~lynn/x959.html#aads

for something you have authentication ... from 3-factor authentication paradigm
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://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:
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?

special characters in passwords

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

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:
https://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
https://www.garlic.com/~lynn/2007.html#15 SSL info
https://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)
https://www.garlic.com/~lynn/subpubkey.html#kerberos

Just another example of mainframe costs

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

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

Date: Sat, 11 Jan 1986 15:26:02 EST
From: melinda
To: wheeler
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
https://www.garlic.com/~lynn/2007.html#45 Just another example of mainframe costs
old email about vm/xa sp1
https://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
https://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?

and email from 19jan86
https://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?

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

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:
https://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#1 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#4 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#5 How many 36-bit Unix ports in the old days?
https://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)

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

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:
https://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)
https://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

and first email in this thread from 10sep91
https://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
https://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
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

====

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

and posts mentioning original relational/sql System/R
https://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?

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

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.
https://www.garlic.com/~lynn/2004e.html#44 Infiniband - practicalities for small clusters
https://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
https://www.garlic.com/~lynn/submain.html#shareddata

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

and misc. past posts mentioning tightly-coupled, smp, &/or compare&swap instruction
https://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?

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

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:
https://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

=====

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
https://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules

history question

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

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
https://www.garlic.com/~lynn/subtopic.html#545tech

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

a couple other posts in that thread
https://www.garlic.com/~lynn/2006y.html#20 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2006y.html#34 "The Elements of Programming Style"
https://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
https://www.garlic.com/~lynn/lhwemail.html

=====

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:
https://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?

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

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:
https://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)
https://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/2007/050207-verisign-to-use-one-time-passwords.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
https://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords

What is "command reject" trying to tell me?

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

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
https://www.garlic.com/~lynn/gcard.html

greencard showed channel status word
https://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
https://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:
https://www.garlic.com/~lynn/2006y.html#34 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"

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

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

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

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)
https://www.garlic.com/~lynn/2007b.html#21 history question

re:
https://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)
https://www.garlic.com/~lynn/2007b.html#25 What is "command reject" trying to tell me?

and from long ago and far away

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

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
https://www.garlic.com/~lynn/2006l.html#6 Google Architecture
https://www.garlic.com/~lynn/2006l.html#18 virtual memory
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core?
https://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:
https://www.garlic.com/~lynn/subtopic.html#disk

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

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

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:
https://www.garlic.com/~lynn/2007b.html#21 history question

and
https://www.garlic.com/~lynn/2007.html#8 "The Elements of Programming Style"
https://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
https://www.garlic.com/~lynn/submain.html#360pcm

for other drift ... a couple recent posts about getting to play in the disk (dasd) engineering and product test labs
https://www.garlic.com/~lynn/2007b.html#25 What is "command reject" trying to tell me?
https://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".
https://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:
https://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)
https://www.garlic.com/~lynn/subtopic.html#hone

or even drop in on customers.

What is "command reject" trying to tell me?

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

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:
https://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
https://www.garlic.com/~lynn/2007b.html#26 How many 36-bit Unix ports in the old days?

as i mentioned before
https://www.garlic.com/~lynn/2002.html#10 index searching
https://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.

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

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
https://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)
https://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"

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

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

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

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

jmfbahciv writes:
If KO had IBM mentality, none of us would have worked for him. You should notice that DEC's name changed to Digital when it did start to become IBMish. (sorry, Lynn). We were not IBM; we would never be able to become IBM. DEC disintegrated when the middle management started to aspire to become IBM.

and you think i was better off inside? ... recent posts
https://www.garlic.com/~lynn/2007.html#22
https://www.garlic.com/~lynn/2007.html#26

... or the medusa tale
https://www.garlic.com/~lynn/lhwemail.html#medusa

... or the nsfnet tale
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

or this one about really taking a beating for sending email about MVS fault
https://www.garlic.com/~lynn/2007.html#2

or all the heat we took from the SAA & token-ring crowds when were were out pitching 3-tier architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier

or it taking nearly a year to get approval to send the communication mentioned here
https://www.garlic.com/~lynn/2006w.html#46

note that lots of the company had traditional organization fan-out ... avg. of seven employees per manager (although there were some organizations that had much fewer). starting around 1990, some places really flattened the organizational pyramid ... going to more like 12-14 employees per manager. that made a lot of middle-managers available (to be hired by digital?).

and of course there is this organizational story .... about some executives who managed to recreate the 14-level management infrastructure (created for a 480k employee organization) in a 2000 person organization
https://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
https://www.garlic.com/~lynn/2003j.html#76 1950s AT&T/IBM lack of collaboration?
https://www.garlic.com/~lynn/2004o.html#63 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2006m.html#17 Why I use a Mac, anno 2006

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

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

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 16:50:53 -0700

when we were doing AADS chip strawman
https://www.garlic.com/~lynn/x959.html#aads

... we worked with some of the evaluation labs that did fips-140 certification. however, we eventually went for a common criteria evaluation by a lab in Europe. I had wanted an eal5 or eal6 ... but could only get an eal4-high.
https://www.garlic.com/~lynn/2002j.html#84 formal fips186-2/x9.62 definition for eal 5/6 evaluation

there were similar chips getting eal5 and eal6 certifications ... the problem i had was i included ec/dsa as part of the chip circuits ... and there wasn't a formal (eal5/eal6) evaluation criteria for ec/dsa (fips186-2/x9.62). other chips were loading programming into chip eeprom after the evaluation ... but since I had ec/dsa in the chip circuits at manufacturing time ... i needed to evaluate everything on the chip.

I claimed that I actually had higher operational "security" than any of the eal5/eal6 evaluated chips ... since they were useless until they had their applications loaded ... which didn't have to be part of their evaluation (while aads chip strawman had everything built into the chip circuits and therefor everything was part of the evaluation).

fips-140 standard is one of the documents i use in my merged security taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote

misc. past posts mentioning fips-140
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aepay3.htm#riskaads AADS & RIsk Management, and Information Security Risk Management (ISRM)
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
https://www.garlic.com/~lynn/aadsm18.htm#19 RPOW - Reusable Proofs of Work
https://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
https://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#17 Smart Cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002h.html#6 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
https://www.garlic.com/~lynn/2002k.html#35 ... certification
https://www.garlic.com/~lynn/2003j.html#36 CC vs. NIST/TCSEC - Which do you prefer?

IBMLink 2000 Finding ESO levels

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBMLink 2000 Finding ESO levels
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Sat, 13 Jan 2007 09:26:09 -0700

Rob van der Heij wrote:
Come on Sir. You're just repeating hearsay nonsense arguments. Yours is almost as good as the one to replace the VM Toolsrun-based employee directory by LDAP because the VM solution "required updates to be applied to all copies of the data spread over multiple VM system" I believe IBM set back the clock 10 years by migrating off their VM applications internally.

for some strange reason or another, there is a ldap redbook that has reference to some webpage of ours at garlic.com

precursor to TOOLSRUN for employee directory was CJNTEL ... posting with old email from 1981 proposing a CJNTEL-based public key infrastructure
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

other posts with old email (from 70s & early 80s) mentioning CJNTEL (and maybe some TOOLSRUN)
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
https://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#7 information utility

then there was line told top executives that the internal network had to be converted to SNA ... because PROFS was an VTAM application and would otherwise stop working
https://www.garlic.com/~lynn/2006x.html#7 vmshare

concurrent with CJNTEL was the online telephone directory ... recently mentioned here
https://www.garlic.com/~lynn/2006v.html#32 Effi[ci]ency of branch table vs individual compare & branch

... now, of course, LDAP ... stands for lightweight directory access protocol ... a morphing of DAP/X.500 ... part of the ISO/OSI suite of protocols. The first time I remember hearing about X.500 was at ACM SIGMOD conference ... i think '92 at santa clara convention center ... it was described as a bunch of networking engineers trying to re-invent 1960s database technology. these day, most LDAPs are layered on some RDBMS technology. for other drift, lots of past posts on original relational/sql, System/R ... all developed on VM
https://www.garlic.com/~lynn/submain.html#systemr

IBMLink 2000 Finding ESO levels

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBMLink 2000 Finding ESO levels
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Sat, 13 Jan 2007 12:39:29 -0700

Anne & Lynn Wheeler wrote:
then there was line told top executives that the internal network had to be converted to SNA ... because PROFS was an VTAM application and would otherwise stop working
https://www.garlic.com/~lynn/2006x.html#7 vmshare

re:
https://www.garlic.com/~lynn/2007b.html#31 IBMLink 2000 Finding ESO levels

similar but different was multiple experiences that HONE had down over the years.
https://www.garlic.com/~lynn/subtopic.html#hone

HONE had started out on cp67 with some number of applications done in cms\apl.

apl\360 service was offered internally by the phili science center. it basically was a os/360 based infrastructure with apl\360 having its own (sub-)monitor, terminal support and its own workspace swapping ... i believe at the time it was 16kbyte workspaces ... although there were some places configured with 32kbyte workspaces.

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

did a port of apl\360 to cms for cms\apl. it could get rid of everything but the actual apl interpreter ... and workspaces could be almost as large as the cms virtual address space ... greatly expanded the applications that could be done in apl. there were a number of things that had to be rewritten for virtual memory environment (for instance the way apl managed workspace storage).

for a while, the science center offered internal cms\apl services on the cambridge machine. one of the users were corporate hdqtrs which loaded the most sensitive corporate information about customer installations ... for doing business modeling (in APL). a lot of APL use back then has since migrated to spreadsheet technology.

the emerging HONE operation cloned the cambridge cp67 operation to start offering online interactive services to sales, marketing and field personnel. over the years, HONE migrated to vm370 and became the online, interactive support for sales, marketing and field personnel around the world. I would continue to provide them with custom built cp67 and then vm370 systems.

a couple past posts referencing operating my own internal operating system distribution for a large number of internal installations ... a couple recent posts mentioning the subject:
https://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#42 vmshare

including old email from 1975 ... for rel2 plc15 based system
https://www.garlic.com/~lynn/2006w.html#email750430
and old email from 1980 for rel6 plc8 based system
https://www.garlic.com/~lynn/2006u.html#email800429

Somewhat after the shutdown of vm370 development group in burlington mall and the tentative announcement that there would be no new vm370 releases (i.e. the whole development group was supposedly to be moved to POK to work on an internal-only VMTOOL required for supporting MVS/XA development; VMTOOL provided XA virtual machines and was different than the internal TOOLSRUN-based VMTOOLS), the HONE organization would periodically get a new executive ... frequently "promoted" from some branch manager position. It would then came as an awful shock to them that HONE was vm370 based operation ... especially after having been in the field and thoroughly indoctrinated that MVS provided all dataprocessing features that would anybody could ever need. They would then instruct the HONE operation that they had to convert everything to MVS platform. This would side-track nearly all of the organization for upwards of a year ... until it was proven that it couldn't be successfully ported to MVS. Then it would be quietly forgotten, the executive would eventually be promoted and replaced by promotion of some other branch manager ... and the whole cycle would be repeated (every 2-3yrs). Since I was never actually in the HONE organization ... I could continue to do cp&cms enhancements for them.

security engineering versus information security

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: security engineering versus information security
Newsgroups: sci.crypt
Date: Sat, 13 Jan 2007 13:24:16 -0700

"John" <javacc1@gmail.com> writes:
Is security engineering the same as information security? I think crypto., computer security, internet security, or different types of security are subfields of information security. But how about security engineering?

taking the security acronym PAIN
P ... privacy (or sometimes CAIN, confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

a lot of crypto tends to have to do with information hiding encryption.

sometimes there is talk about information assurance (protection of the information) ... as opposed to information security ... i.e. the integrity of the information ... sometimes integrity is assumed to also included "availability" (i.e. from things like DOS attack).

for some example ... I've frequently commented about SSL being used to "hide" account numbers as part of electronic commerce ... comments having work on such an implementation
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

however, the x9a10 financial standard working group was then given the requirement to preserve the integrity of the financial infrastructure for all retail payments (not just internet, but also all other kinds of retail payments, including point-of-sale). the result was x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

the assertion is that x9.59 does a much better job of providing electronic commerce security than SSL ... and does it using "authentication" and "integrity" ... and no longer requires the information to be hidden (i.e. ssl or other forms of encryption).

no longer requiring the information to be hidden ... then also addresses a large number of the data breaches and security breaches that have been in the news for the past year or so ... where they primarily involve unauthorized access/use of information. x9.59 didn't do a better job of hiding the information ... it just made the access to the information useless to the attackers (either insiders or outsiders).

old posts about the thread between risk management and information security
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads

and semi-related old post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

security engineering then should be analysing the (end-to-end) threats and designing/building countermeasures for the threats (taking analogy from other kinds of engineering efforts ... like civil engineering ... say designing and building a bridge or a road) ... and treated as subset of risk management.

Just another example of mainframe costs

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Just another example of mainframe costs.
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 14 Jan 2007 09:01:35 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
Another old email from the east coast referring about system changes returning to global LRU
https://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?

re:
https://www.garlic.com/~lynn/2007b.html#14 Just another example of mainframe costs

This is more detailed analysis of observations mentioned in email earlier in the month (jan86). Misc. old email mentioning global LRU
https://www.garlic.com/~lynn/lhwemail.html#globallru

Date: 01/24/86 10:06:21
To: distribution
Subject: GLRU prototype status

Effective Tuesday night, KGNVMC was changed to include new code which reacted to excessive demand for pages in the <16m dpa and dynamically off-loaded what it could to the >16m area. After reviewing monitor data for Wednesday, it was clear that the improvement produced was inconsistent with the problem that was solved: i.e., we got some gains, but nothing really significant.

Yesterday, I wrote an EXEC to monitor the core scanning algorithm in real time, and observed anomolies in its behavior. I have tracked these down to two errors in the original HPO 2.5 implementation of >16m core table scan which are severe enough to mask the gains expected from equalizing the use of the two dpas. These errors are far too complex to explain in a short note, but the net of them is that, in the presense of any storage above the 16m line, we no longer have global LRU implemented below the line. This is quite independent of any consideration of whether the reset interval below the line is too short... even on systems which are not constrained below the line, the reset interval is not constant. (In fact, it will tend to be longest for pages near the middle of the area, shortening gradually as real addresses increase, and shortening strongly as real addresses become very close to the bottom of the area.)

I will try to get these problems cleaned up so that we might have a correct implementation in time for installation next Tuesday night on KGNVMC.

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

When >16mbyte real storage was added to 24bit "real addressing", there was still quite a bit of stuff that had to reside "below the line" (first 16mbyte of real storage), like lots of stuff related to I/O operations.

post
https://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370
with old email discussing implementation for >16m
https://www.garlic.com/~lynn/2006t.html#email800121

misc. other posts mentioning >16mbyte real storage with 24bit addressing
https://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
https://www.garlic.com/~lynn/2004o.html#59 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine
https://www.garlic.com/~lynn/2006w.html#23 Multiple mappings
https://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?

misc. collected posts discussiong virtual memory & page replacement
https://www.garlic.com/~lynn/subtopic.html#wsclock

security engineering versus information security

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: security engineering versus information security
Newsgroups: sci.crypt
Date: Sun, 14 Jan 2007 09:51:09 -0700

clark <clark@barbell.com> writes:
I believe that is incorrect, as "information assurance" speaks to the dependible nature or correctness of the information.

re
https://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security

... which are you referring to being "incorrect"? ... my statement that sometimes there is talk about information assurance ...? (i.e. that there are instances where somebody refers to "information assurance" in that manner) ... or that the "somebodies" that "talk" about "information assurance" (that way) are wrong?

Definitely within the context of the security PAIN acronym ... information assurance might be considered as a specific characteristic within the PAIN acronym ... however some of the "references" that talk about information assurance have defined it as effectively equivalent to "security" (i.e. all characteristics of the PAIN acronym, not just a specific one) ... see below ...

The following is from my merged security taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote

definitions are identified as to their sources (i.e. NSAINT, IATF, CIAO, CNSSI, and 800-59) ... see above URL for more detailed reference to some of the sources.
information assurance (IA)

Information Operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. (DODD S-3600.1 of 9 Dec 96) [NSAINT]

Information operations (IO) that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. [IATF]

Information operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. Information operations actions taken to affect an adversary's information and information systems while defending one's own information and information systems. [CIAO]

Measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. These measures include providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. [CNSSI]

Measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. These measures include providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. [800-59]

... snip ...

i.e. from original post
https://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security

security PAIN acronym
P ... privacy (sometimes CAIN, confidentiality) A ... authentication I ... integrity N ... non-repudiation

Special characters in passwords was Re: RACF - Password rules

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

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: Sun, 14 Jan 2007 11:13:14 -0700

Rick Fochtman wrote:
IMHO, any auditor should be ecstatic if he finds any limit under 11 set. It's not up to him to "dictate" security policy, only to examine and recommend (possible) improvements.

for a little topic drift, slightly related thread in another news group
https://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security
https://www.garlic.com/~lynn/2007b.html#35 security engineering versus information security

mentioning my merged security taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote

doesn't have a definition for auditor ... but has several audit related definitions ... including
audit
A family of security controls in the technical class dealing with ensuring activity involving access to and modification of sensitive or critical files is logged, monitored, and possible security violations investigated. [800-37] A service that keeps a detailed record of events. [IATF] An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. [IEEE610] Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures. [CNSSI] Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established security policies and procedures, and/or to recommend necessary changes in controls, policies, or procedures to meet security objectives. [CIAO] Independent review and examination of records and activities to determine compliance with established usage policies and to detect possible inadequacies in product technical security policies of their enforcement. [AJP][FCv1] The independent examination of records and activities to ensure compliance with established controls, policy, and operational procedures, and to recommend any indicated changes in controls, policy, or procedures. [NSAINT] The independent examination of records to access their veracity and completeness. To record independently and examine documents or system activity (e.g. logins and logouts, file accesses, security violations). [AFSEC] The official review, examination, and verification of system records and activities to ensure the adequacy of established IT security controls and procedures; to identify any nonfunctional controls or new vulnerabilities [NASA]

... snip ...

however, did have a definition of auditor that was part of the "6670" sayings ... random definitions (which also included all the ibm jargon entries) selected for printing on 6670 separation sheet
[Business Maxims:] Signs, real and imagined, which belong on the walls of the nation's offices:
1) Never Try to Teach a Pig to Sing; It Wastes Your Time and It Annoys the Pig.
2) Sometimes the Crowd IS Right.
3) Auditors Are the People Who Go in After the War Is Lost and Bayonet the Wounded.
4) To Err Is Human -- To Forgive Is Not Company Policy.

... snip ...

one of the same 6670s were used to print the april 1st corporate directive on passwords ... mentioned earlier in this thread (and led to putting all corporate letterhead paper under lock & key)
https://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was Re: RACF - Password rules

past postings mentioning a security audit that included search of the facility looking for unsecured classified material ... including searching the various 6670 printer areas. an auditor took it as personal afront when one of the 6670 outputs had the (auditor) definition
https://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
https://www.garlic.com/~lynn/2002o.html#24 IBM Selectric as printer
https://www.garlic.com/~lynn/2004l.html#61 Shipwrecks
https://www.garlic.com/~lynn/2005f.html#48 1403 printers
https://www.garlic.com/~lynn/2005f.html#51 1403 printers
https://www.garlic.com/~lynn/2005r.html#29 Job seperators

Special characters in passwords was Re: RACF - Password rules

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

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
CC: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU>
Date: Sun, 14 Jan 2007 11:32:02 -0700

Anne & Lynn Wheeler wrote:
3) Auditors Are the People Who Go in After the War Is Lost and Bayonet the Wounded.

re:
https://www.garlic.com/~lynn/2007b.html#36 Special characters in passwords was Re: RACF - Password rules

... several times Boyd quoted Guderian (before the blitzkrieg) as directing verbal orders only ... for much the same reason (minimizing troops worrying that afterwards getting blamed for making less than optimal decisions in the fog of war, doing something would be better than decision paralysis).

collected past postings mentioning Col. Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
and misc. URLs from around the web mentioning Col. Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

'Innovation' and other crimes

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 'Innovation' and other crimes
Newsgroups: alt.folklore.computers
Date: Sun, 14 Jan 2007 12:41:52 -0700

somewhat related, from long ago and far away ...

recent posts
https://www.garlic.com/~lynn/2007.html#22
https://www.garlic.com/~lynn/2007.html#26
https://www.garlic.com/~lynn/2007b.html#29

Date: 84/04/05 11:43:23
To: wheeler

I've been asked to talk to a freelance writer who is ghosting an article for <corporate executive> to be published in the Harvard Business Review. The subject of the article is something about "fostering creativity in large corporations"; will know more after I've talked to him. I'd appreciate any comments/thoughts on what ought to be said, not said, or emphasized, and especially any specific experiences you think may be relevant and helpful...

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

Date: 84/04/05 18:35:38
To: wheeler

I now know a bit more. The corporate communications people basically outlined the article, and it is subtitled something like "6 steps to creativity".

The 6 points are:

1. Cultivate/encourage the wild duck
2. Encourage creative restlessness --
set goals beyond reach Make people strive beyond their abilities
3. Require continuing education
4. Give serendipity a chance
Encourage unexpected interactions
5. Manage failure well
Salvage what can be; learn lessons, etc.
6. Think the unthinkable
Such as doing business in "different" ways, e.g., IBUs...

*** REDACTED *** Anyway, the contact I spoke to thought that some supporting evidence for points 2 and especially 4 would make the thing more credible, and that's the kind of thing I guess I'm looking for. Any comments on any of it are, of course, welcome. I think what he'd really like to have is an instance of people becoming aware of one another unexpectedly and profiting from the acquaintance in some immediate fashion.

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

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

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

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

from long ago and far away ... one of several iterations trying to ship unix on vm ... some of this involved people that had been involved in the unix on tss activity ... recent reference
https://www.garlic.com/~lynn/2007b.html#3

reference to similar but slightly different effort a couple years earlier
https://www.garlic.com/~lynn/96.html#4a

the original "fair share" scheduler had a default resource consumption calculated a global system resource "fair share" ... and then caculating individual process dispatching priority by taking their individual resource consumption relative to the global system "fair share" (it wasn't the only scheduling policy, but it was the default scheduling policy)
https://www.garlic.com/~lynn/subtopic.html#fairshare

a few years earlier (prior to this sequence of email), I had implemented "group" fair share scheduling ... basically establish group resource consumption resource objectives and then calculate fairshare within a group ... and then calculate process dispatching priority by taking a combination of the groups resource consumption vis-a-vis the groups allocation and the individual process resource consumption vis-a-vis the individual process resource objective. Group fair share didn't ship in the product (when it was original done or in this iteration).

Date: 03/09/84 11:04:52
From: wheeler

are there 2 or 3 types of virtual machines?

I don't know very much about how the various vmbloks are hung off the chains. I've gotten the impression that it is a two level structure. Master user vmblok that dmksch and dmkstp sees and then all the forked vmbloks that actually get dispatched. Assuming that it is really a two level structure ... then it becomes a two level scheduling problem (implementation can be anologous to the implementation I did for group fair share).

What vmblok does dmkstp see, what vmblok does dmksch see, and what vmblok does dmkdsp see???? How closely tied do you want the individual vmbloks tied to the master user vmblok?

If all time (and vmuhs) is accumulated by the master user vmblok ... then how do individual vmbloks get on the dispatch list?

First pass quick and dirty (with minimum assumptions) is that dmksch sees the master vmblok with slight flag changes, calculates some value, and then the vmblok pointers are switched. In that case ... the master vmblok needs to know the number of active vmbloks, calculate vmqprior and then multiple by the number of active vmbloks hung off this master. (quick and dirty ... assuming that cpu is approx. partitioned equally between the forked vmbloks). Non-equal partitioning requires another number ... need to know more on preferences for policies for implement non-equal partitioning.

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

Date: 04/02/84 08:28:06
To: wheeler

SUBJECT: UNIX Scheduling in VM

Hello Lynn, It's been a while since we have talked. I know that you and XXXXXX have been talking about the scheduling problem that we have uncovered with the Psuedo-machine implementation of UNIX under VM. This is obviously a critical problem, and one that we would like to solve in the very near term (at least from a design point of view). What is your availability in the next couple of weeks or so to give us some assistance in coming up with a design that will be acceptable to both IBM Kingston and Endicott? Any time you can give us would be much appreciated.

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

Date: 12 April 1984, 13:49:22 EST
To: wheeler
cc: distribution

Subject: group scheduling

gentleman .... i have interested my management in a 'DCR' change to HPO (and possibly SP) that would provide a. group scheduling b. different 'vmuprior's within the group in a general way.

the 'DCR' process is such that this would not be generally available for a year or so. However, it could be 'prototyped' thru other mechanisms much earlier (eg VMIX ? )

DSD interest is that it would satisfy 4 distinct requirements we have outstanding for variants of 'group scheduling' .... one of which is VMIX. let's discuss asap , ok ?

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

Special characters in passwords was Re: RACF - Password rules

Refed: **

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: Sun, 14 Jan 2007 13:07:53 -0700

re:
https://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#36 Special characters in passwords was Re: RACF - Password rule

and old email from 1984 about april 1st corporate directive on passwords that was printed on official corporate letterhead paper (and put up on bldg. bulleting boards). copy in old a.f.c. thread:
https://www.garlic.com/~lynn/2001d.html#53 April Fools Day

Date: 2 April 1984, 19:10:15 PST
To: wheeler

Actually, I was only able to get one copy (since I was at the Bulletin Board when it was removed). The funny part is that someone put that notice on EVERY Bulletin Board in 028 .. also heard that XXXXXX was asked to explain (since "obviously" someone in his function did it). I wonder who the phantom is?

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

Date: 04/03/84 09:57:55
From: wheeler
To: original author in POK

re: $pw script; i distributed copies to a large number of people locally on friday and to YYYYYY (who redistributed it). Somebody locally over the weekend printed it on corporate news letterhead and put it up on all the bulletin boards in the building. It lasted less than two hours monday morning before it was pulled. Local management is somewhat upset.

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

'Innovation' and other crimes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 'Innovation' and other crimes
Newsgroups: alt.folklore.computers
Date: Sun, 14 Jan 2007 13:35:34 -0700

re:
https://www.garlic.com/~lynn/2007b.html#38 'Innovation' and other crimes

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sun, 14 Jan 2007 13:51:13 -0700

Steve O'Hara-Smith <steveo@eircom.net> writes:
I've always thought the way it was done in my day was good - don't attempt to induce mastery of anything but expose the students to as many languages as possible (in my day that meant FORTRAN (II and IV), BCPL[1], Algol (W and 68C), LISP, COBOL, an Assembler, and a whole bunch of more obscure specialised languages. Then for most[2] exercises allow free choice of language and take into consideration how appropriate the choice of language was. Much more time was spent on the principals than the languages.

one more language

Sun's Fortran replacement goes open-source
http://news.com.com/Suns+Fortran+replacement+goes+open-source/2100-7344_3-6150063.html?tag=nefd.top

from above:
Fortress is designed to be a modern replacement for Fortran, a programming language born 50 years ago at IBM but still very popular for high-performance computing tasks such as forecasting the weather.

... snip ...

old thread about being asked to help track down original fortran compiler documentation and source
https://www.garlic.com/~lynn/2004d.html#24 who were the original fortran installations?
https://www.garlic.com/~lynn/2004d.html#27 who were the original fortran installations?

(for a period when I was in bldg. 28, Backus' office was just around the corner from mine)
https://www.garlic.com/~lynn/2003b.html#57 Why did they make FORTRAN so hard to parse?
https://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#25 Network databases
https://www.garlic.com/~lynn/2006b.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006m.html#28 Mainframe Limericks

security engineering versus information security

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: security engineering versus information security
Newsgroups: sci.crypt
Date: Sun, 14 Jan 2007 14:04:25 -0700

re:
https://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security
https://www.garlic.com/~lynn/2007b.html#35 security engineering versus information security

and for some other drift, a recent news URL

IT Security Doesn't Mean Information Security
http://www.cioupdate.com/trends/article.php/3653776

from above:
For many years, the term "information security" has been used to refer to solutions that protect and defend the network and IT systems. This is far too often misleading, because what is actually meant in such cases is IT security.

... snip ...

Why so little parallelism?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Sun, 14 Jan 2007 14:32:52 -0700

Joe Seigh <jseigh_01@xemaps.com> writes:
The Java gui? It's threaded. There's an event handling thread. Most programmers can't deal with that. STM (software transactional memory) is a huge area of research precisely because of that since it eliminates the deadlock issue that most programmers don't know how to avoid.

recent news URL on (hardware) transactional memory

Getting Serious About Transactional Memory
http://www.hpcwire.com/hpc/1196095.html

from above:
To that end, Intel researchers are looking to transactional memory as one of the key technologies that will enable developers to write the terascale killer apps of the next decade. The attraction of TM is that is appears to solve the most annoying problems of global locks: application robustness and scalability. These attributes are especially important for the type of large-scale concurrency required by terascale applications.

... snip ...

as i've mentioned before ... the aixv3 journaled filesystem was written using the 801 (hardware) transactional (database) memory on rios (rs/6000)

... a few past posts
https://www.garlic.com/~lynn/2002b.html#33 Does it support "Journaling"?
https://www.garlic.com/~lynn/2002b.html#34 Does it support "Journaling"?
https://www.garlic.com/~lynn/2003c.html#49 Filesystems
https://www.garlic.com/~lynn/2003d.html#54 Filesystems
https://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"?
https://www.garlic.com/~lynn/2005n.html#20 Why? (Was: US Military Dead during Iraq War
https://www.garlic.com/~lynn/2005n.html#32 Why? (Was: US Military Dead during Iraq War
https://www.garlic.com/~lynn/2005r.html#27 transactional memory question
https://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal of R&D
https://www.garlic.com/~lynn/2006y.html#36 Multiple mappings

collected past posts mentioning 801, iliad, romp, rios, fort knox, etc
https://www.garlic.com/~lynn/subtopic.html#801

Is anyone still running

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is anyone still running..........................
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 14 Jan 2007 15:05:43 -0700

Shmuel Metz , Seymour J. wrote:
MFT and MVT were contemporaneous. In fact, a lot of the code in MFT came from MVT.

as undergraduate, i gen'ed OS/360 releases 9.5 and 11 and 14 as "MFT" (along with installing HASP).

I don't remember MVT option becoming available until release 12 ... and I don't know anybody that actually gen'ed a release 12 MVT system ... I know some number had gen'ed release 13 MVT systems ... and I didn't gen a MVT system until release "15/16" (i.e. release 15 had slipped so badly that it was combined with 16).

I believe it was a release 13 MVT system that was modified by Boeing Huntsville to support virtual memory running on 360/67 "duplex" (two processor smp). It didn't support paging ... but they had a lot of long running 2250 graphic applications ... and they used virtual memory to get around os/360 storage fragmentation problems (especially with long running applications).

for some topic drift ... I did a presentation at Atlantic City share fall68 ... about a lot of enhancements i had done to MFT-14 ... as well as performance of MFT-14 in virtual machine after having done a lot of cp67 kernel rewrite.

past post with portion of fall68 share presentation
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

similar post/thread
https://www.garlic.com/~lynn/2006h.html#57 PDS Directory Question

'Innovation' and other crimes

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 'Innovation' and other crimes
Newsgroups: alt.folklore.computers
Date: Mon, 15 Jan 2007 08:30:03 -0700

Andrew Swallow <am.swallow@btopenworld.com> writes:
The initial suggestions may help with the human side but have nothing to say about the real problem with innovation - the companies controls and bureaucracy ban it.

re:
https://www.garlic.com/~lynn/2007b.html#41 'Innovation' and other crives

"IBU" (independent business unit, minor reference in above) was suppose to be setup for lightweight, agile operation. AWD (advanced workstation division, aka produced PC/RT and RS/6000) was originally set up this way. What I saw was that supposedly being lightweight, agile operation, they weren't funded for a lot of overhead and bureaucracy. However, in their dealings with other parts of the corporation ... the other bureaucracies kept insisting that they went thru the various processes, however, (at least) AWD didn't have the funding for the staff to slog thru all such processes. the result tended to be that other organization personal had to be diverted to dealing with such interactions ... significantly impacting productivity

One of the gotchas remaining lightweight and agile ... was they should depend on other corporate operations for various services ... for instance, co-location and getting facilities from an existing plant site. Dealing with the plant manager (typical of most of corporate interactions), the assertion was made that being an IBU exempted the organization from lots of corporate bureaucracy. The plant manager's comeback was that met the IBU was exempted from other corporate bureaucracy ... but not exempt in dealing with his bureaucracy. The trick then was finding any corporate bureaucracy that the IBU was actually exempt from (which it also wasn't funded to handle).

Being able to depend on other corporate organizations (to avoid duplication in the IBU) ... also extended into all sorts of technical and product areas. One of the possible disastrous decisions for RS/6000 was deciding to use microchannel. The problem wasn't that the microchannel was bad ... but that decision then subjected the RS6000 to pressure that (instead of doing their own adapters ...) they use adapters from other corporate organizations ... which had totally different design point and cost trade-offs.

This is in similar vein to stuff we encountered when we had come up with 3-tier architecture and out pitching to customer execs ... recent post
https://www.garlic.com/~lynn/2007b.html#29 was: How many 36-bit ports in the old days?
and collected posts mentioning 3-tier architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier
or this
https://www.garlic.com/~lynn/2006x.html#7 vmshare
https://www.garlic.com/~lynn/2006x.html#8 vmshare

and these collected posts
https://www.garlic.com/~lynn/subnetwork.html#emulation

specific instances were microchannel cards from other corporate organizations for display adapter, scsi adapter, and token-ring adapter. all had electronic, cost and thruput trade-offs targeted at low-end PC market ... and were totally unsuitable for high-end workstation environment.

a really severe contrast was the 16-mbit token-ring adapter. earlier, an AWD, 4-mbit/sec token-ring 16bit adapter was done for the PC/RT. However, the RS/6000 was forced to accept the corporate 16-mbit token-ring microchannel adapter. The problem was that the per-card thruput of the corporate 16-mbit/sec token-ring microchannel adapter was less than the per-card thruput of the AWD PC/RT 4-mbit token-ring 16bit adapter. The majority of the other "corporate" microchannel adapters showed similar cost/thruput trade-offs.

past posts mentioning the issue with the 16-mbit token-ring adapter compared to the pc/rt 4-mbit token-ring adapter.
https://www.garlic.com/~lynn/2004p.html#59 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
https://www.garlic.com/~lynn/2005q.html#20 Ethernet, Aloha and CSMA/CD
https://www.garlic.com/~lynn/2006l.html#35 Token-ring vs Ethernet - 10 years later
https://www.garlic.com/~lynn/2006l.html#36 Token-ring vs Ethernet - 10 years later

... aka 16-mbit token-ring microchannel adapter ... sort of had the per-card cost/thruput trade-off of putting 300 PCs on the same LAN segment doing dumb terminal emulation.

there was a joke that by the time an RS/6000 was completed fitted out with low-end PC microchannel adapters ... its thruput would comparable to a low-end PC.

disclaimer ... my wife is named on token passing protocol patent ... a couple old refs
https://www.garlic.com/~lynn/2004e.html#13 were dumb terminals actually so dumb
https://www.garlic.com/~lynn/2005i.html#43 Development as Configuration

newbie need help (ECC and wireless)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: newbie need help (ECC and wireless)
Newsgroups: sci.crypt
Date: Mon, 15 Jan 2007 11:01:13 -0700

"Joseph Ashwood" <ashwood@msn.com> writes:
For products it all comes down to business decisions. RSA is the most widely recognised name in asymmetric cryptography, and as such is the safest business decision. As for "best" I will grant that ECC is faster and smaller, but for situations that require dependable long term security I admit I often recommend RSA simply because the problem is better understood, making it more dependable long term.

there is a somewhat different issue left-over from various mid-90s protocol efforts ... that appeared to be trying to anticipate smartcard use.

the smartcards of the period had extremely poor random number capability (there was one test that involved many of the available chips from the period doing 64k power cycles followed by random number generation ... that found something like 1/3rd of the numbers were duplicates).

as a result various defined digital signature protocols (that were trying to anticipate smartcard use) had message/transaction generated externally with embedded random number field included in the message/tranaction ... followed by applying the (RSA) digital signature (possibly by a smartcard).

ecdsa would have been an attractive alternative ... except ecdsa is vulnerable w/o a decent random number capability (which the majority of the cards/chips from the period didn't provide).

one of the things that we were looking for in the mid-90s was being able to do strong authentication within "TRANSIT" time-limit (100-200 milliseconds) and "TRANSIT" contactless (as in getting power thru the air, as opposed to some wireless that have their own battery power), extremely low-power, power profile. ecdsa was the only thing that fit the bill ... modulo finding a chip that had an acceptable random number generator.

there is the folklore tale from the period about MONDEX (which wasn't even asymmetric crypto) making a proposal at a transit meeting for using MONDEX in transit applications. A "contactless" sleeve would be provided for MONDEX card and 14ft long electromagnetic "tunnels" built leading up to every transit gate/turnstyle. People would walk slowly thru the tunnels (getting power for the MONDEX card) and by they time they got to the turnstyle, the transaction would almost be complete.

The RSA solution was to put 1100bit multipliers in such chips to speed up the operation, still didn't meet the transit time-limit requirements ... however, the increased circuits significantly increased the chip size and power requirements (which also eliminated the possibility of contactless operation).

putting ecdsa in a chip with decent random number generator addressed the transit (time & contactless power) requirements ... but made it difficult to get better than EAL4 certification ... recent post discussing certification issue:
https://www.garlic.com/~lynn/2007b.html#30

misc. past posts mentioning MONDEX and/or 1100bit multipliers (for RSA):
https://www.garlic.com/~lynn/aadsm20.htm#7 EMV
https://www.garlic.com/~lynn/2004h.html#30 ECC Encryption
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure?
https://www.garlic.com/~lynn/2006s.html#11 Why not 2048 or 4096 bit RSA key issuance?

6400 impact printer

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 6400 impact printer
Newsgroups: bit.listserv.ibm-main
Date: Mon, 15 Jan 2007 22:40:12 -0700

Chris Mason wrote:
I'm not sure at all about your comparison of IP and SNA with regard to ease of routing. When I see the mess that Cisco types get up to in their "forum" to which I subscribe,[1] IP doesn't look so easy after all. If you are comparing IP and *subarea* SNA, you might have a - rickety - leg to stand on. If you are comparing IP and *APPN/HPR* SNA, you'd be left in the dust - from a theoretical standpoint - wildly mixing my linguistic metaphors. <g> Unfortunately APPN/HPR came along too late to save the commercial world from the horrors of IP.

my wife had co-authored AWP39, peer-to-peer-networking in the same time-frame as sna starting ... minor topic drift:
https://www.garlic.com/~lynn/2006x.html#8 vmshare

which resulted in her taking a lot of heat from the sna organization. this continued when she was con'ed into going to pok to be in charge of loosely-coupled architecture. while there she authored Peer-Coupled Shared Data architecture ... which except for IMS hot standby, didn't see much uptake until sysplex ... the battles with sna organization continued ... somewhat with a compromise that sna had to be used for anything crossing the boundaries of the glass-house. misc past posts mentioning peer-coupled shared data architecture
https://www.garlic.com/~lynn/submain.html#shareddata

appn was awp164 ... and the sna organization non-concurred with announcing appn. after something like six weeks escalation, the appn/awp164 announcement letter was carefully rewritten to make sure that nobody would be confused about there being any relationship between appn/awp164 and sna. recent posts mentioning awp164:
https://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
https://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
https://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

work started on tcp/ip in 1973 ... when it was recognized that arpanet was inadequate ... see reference to rfc801 in this post
https://www.garlic.com/~lynn/2007b.html#5 How many 36-bit Unix ports in the old days?

the cut-over from arpanet to tcp/ip protocol was 1jan83 ... in the arpanet newsletter from jul80 ... see copy here
https://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?

projected that there would be 100 (arpanet) nodes by 1983. This was the year that the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

passed 1000 nodes. posts that includes announcement of 1000th node
https://www.garlic.com/~lynn/99.html#112
https://www.garlic.com/~lynn/internet.htm#22 NOTE: that the internal network was NOT SNA.

and post
https://www.garlic.com/~lynn/2006k.html#43 Arpa address
with old email about getting ready for the 1000th node
https://www.garlic.com/~lynn/2006k.html#email830422

there were issues later with misinformation being pushed up to corporate executives as part of effort to convert internal network to SNA ... post
https://www.garlic.com/~lynn/2006x.html#7 vmshare

with old email about some of the misinformation being pushed up to corporate executives
https://www.garlic.com/~lynn/2006x.html#email870302

another post about misinformation
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

6400 impact printer

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 6400 impact printer
Newsgroups: bit.listserv.ibm-main
CC: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU>
Date: Mon, 15 Jan 2007 23:23:50 -0700

re:
https://www.garlic.com/~lynn/2007b.html#48 6400 impact printer

... and remember the sna organization non-concurred with announcing appn/awp164 (until after the announcement letter was carefully rewritten so that there was no relationship between appn and sna).

for more trivia ... email from day appn was announced ... and for some total trivia ... at this time ... both the author of appn/awp164 and i (directly) reported to the same executive.

Date: 06/16/86 20:18:24
To: wheeler

Lynn,

I just got back from San Francisco and I'm having a little trouble keeping up with all the network traffic .... John sends almost as many emails as you..

Your est. of 60000 terminals for Bell South is about right as I recall and the US West number is between 50 and 60K I'd guess.

I also found a Washington Systems Center Tech Bulletin on SNA Networks of Small Systems (GG66-0216) which is interesting reading on LEN and points out the design point for the prototype (and the S/36 APPN which they announced today Advanced Peer to Peer Networking...nice name) for small networks. It seems to me that the extensions required to handle a large network of arbitrary topology and high speed data are non trivial at best. The directory search algorithm and storage required to support it appear to be very large indeed. Also, once a route has been selected, it is frozen so that session recovery in the event of a node failure on the route would (I have to assume) result in the loss of the session...not the case in XXXXXX (except at the host boundary which could be changed to recover even that session without a session outage). As you know, XXXXXX can have major processor failures within the NTC, NHC or NXC and continue without session interruption.

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

Is anyone still running

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is anyone still running..........................
Newsgroups: bit.listserv.ibm-main
Date: Tue, 16 Jan 2007 00:03:47 -0700

Shmuel Metz , Seymour J. writes:
There was at least one retraction and redesign prior to that. Search for MPS and VMS.

re:
https://www.garlic.com/~lynn/2007b.html#45 Is anyone still running

you mean from this prior/similar exchange nearly a year ago
https://www.garlic.com/~lynn/2006h.html#57 PDS Directory Question

or the parenthetical note here
http://www.os390-mvs.freesurf.fr/mvshist1.htm
http://mcraeclan.com/Links/Computers/IBMMainframeHistory/mvshist1.htm

and there is also a reference to the above here
https://www.garlic.com/~lynn/2003.html#72 Disk drives as commodities. Was Re: Yamhill

for some drift, in this version
http://mcraeclan.com/Links/Computers/IBMMainframeHistory/mvshist1.htm

from above:
My understanding is that PCP metamorphosed into CMS in the VM world, almost intact.

... snip ...

CMS morphed from CTSS and had little or nothing to do with PCP ... other than CMS had some os/360 svc simulation for running various os/360 applications. CMS originally stood for the cambridge monitor system ... misc. posts mentioning the cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech

In the morph from cp67 to vm370, they changed CMS to "conversational" monitor system.

Note, somebody from Union Carbide did do a "online/os" using a PCP-gened os/360 and had written an interactive monitor that took CMS-like commands from the (virtual) operators console (sort of super TSO but worked off the virtual operator's console). Later, he was one of the people that formed IDC (a cp67 time-sharing service bureau in the late 60s). misc. past posts mentioning various time-sharing service bureaus
https://www.garlic.com/~lynn/submain.html#timeshare

Special characters in passwords was Re: RACF - Password rules

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

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

Ray Mullins wrote:
When a large community college district located in Southern California shot themselves in the foot (IMHO) and dumped their 370/158 for a Honeywell Series 6000 (without Multics, but GCOS 7 + TSS) in the early 1980's, a "B" language compiler came with the system.

past post in this thread about Multics and vulnerabilities
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules

Multics was on the 5th flr, 545 tech sq ... box originally was GE ... before GE sold their computer business to Honeywell.

Cambrdige Science Center was on 4th flr, 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech

which brought you virtual machines, the internal network, a lot of interactive tools, GML (precursor to SGML, HTML, XML, etc).

One of my hobbies was building enhanced, customized operating systems for internal distribution. I've joked before (sometimes with multics aficionados) that the number of customers vm installations was larger than the number of internal vm installations; and the total number of internal vm installations were significantly larger than the number of customer vm installations; and that i directly distributed customized vm operation system to. However, at various times, the number of internal installations that I built and directly distributed customized operating systems for ... were as large as the total number of Multics systems that ever existed.

recent post with discussion about comparing total number of multics systems
https://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?

post about csc/vm distribution
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
with old email from apr75 about the distribution
https://www.garlic.com/~lynn/2006w.html#email750430

post about sjr/vm distribution
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
with old email from apr80 about the distribution
https://www.garlic.com/~lynn/2006u.html#email800429

one long-time organization that i did this for ... dating back to the cp67 days was the HONE organization ... that used (originally cp67 and then) vm370-based systems to provide the world-wide online, interactive support for sales, marketing, and field personnel
https://www.garlic.com/~lynn/subtopic.html#hone

multics web page
https://www.multicians.org/multics.html

a multics installation was AFDS mentioned here
https://www.multicians.org/site-afdsc.html

and for other drift, here is post about AFDS looking at ordering couple hundred 4341s in the late 70s
https://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
https://www.garlic.com/~lynn/2001m.html#15 departmental servers

with old email from apr79
https://www.garlic.com/~lynn/2001m.html#email790404b

Special characters in passwords was Re: RACF - Password rules

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

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, 16 Jan 2007 11:07:40 -0700

Howard Brazee wrote:
Verbal orders - as opposed to pantomimed orders? I am picturing Patton directing traffic from the movie.

re:
https://www.garlic.com/~lynn/2007b.html#37 Special characters in passwords was Re: RACF - Password rules

who goes into enemy territory before the tanks? a couple refs
https://www.garlic.com/~lynn/2004e.html#19 Message To America's Students: The War, The Draft, Your Future
https://www.garlic.com/~lynn/2006q.html#15 The Fate of VM - was: Re: Baby MVS???
https://www.garlic.com/~lynn/2006s.html#44 Universal constants

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

Forbidding Special characters in passwords

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

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

Kim Goldenberg wrote:
however, you now have a passkey of a picture and a description the you provide and you are required to confirm they match when you log on; kind of like saying are you really ______?

Not *MY* choice, but theirs.

this is not for them to authenticate you ... this is supposedly allowing you to authenticate them (aka can they present the correct information you previously provided) i.e. this supposedly is countermeasure to website impersonation (being used for phishing and identity theft). however when this was first being discussed ... the issue of man-in-the-middle attacks was raised ... lots of past posts about man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

there has been some amount in the news recently about such website MITM exploits showing up (aka the additional website authentication processes aren't actually providing end-to-end authentication and integrity ... and a fraudulent website can still get in the middle ... transparently forwarding information in either direction as needed).

the issue somewhat "is how do you know that the website that you think you are talking to is really the website you are talking to". this was supposedly one of the vulnerabilities that SSL was suppose to address ... however, there are some number of operational and/or infrastructure vulnerabilities involving SSL that result in not actually achieving the desired goal (which has somewhat given rise to various of this additional countermeasures). recent posts discussing issues about whether the website you think you are talking to is really the website you are talking to
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006s.html#11 Why not 2048 or 4096 bit RSA key issuance?
https://www.garlic.com/~lynn/2007.html#7 SSL info

collected past posts mentioning SSL
https://www.garlic.com/~lynn/subpubkey.html#sslcert

some number of past posts discussing infrastructure and process issues with SSL-based domain name certificate infrastructure
https://www.garlic.com/~lynn/subpubkey.html#catch22

Forbidding Special characters in passwords

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Forbidding Special characters in passwords
Newsgroups: bit.listserv.ibm-main
CC: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU>
Date: Tue, 16 Jan 2007 12:25:34 -0700

Anne & Lynn Wheeler wrote:
there has been some amount in the news recently about such website MITM exploits showing up (aka the additional website authentication processes aren't actually provide end-to-end authentication and integrity ... and a fraudulent website can still get in the middle ... transparently forwarding information in either direction as needed).

re:
https://www.garlic.com/~lynn/2007b.html#53 Forbidding Special characters in passwords

and the other problem with this scheme is that it scales badly (besides not providing end-to-end authentication/integrity and vulnerable to MITM attacks) ... it has effectively the same problems as shared-secret pin/passwords
https://www.garlic.com/~lynn/subintegrity.html#secrets

if this approach were to catch on ... then if you effectively have scores of unique pin/passwords for every unique security domain ... then you potentially need (to provide and remember) scores of unique images/descriptions for every website.

IBMLink 2000 Finding ESO levels

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBMLink 2000 Finding ESO levels
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 16 Jan 2007 17:31:55 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
the emerging HONE operation cloned the cambridge cp67 operation to start offering online interactive services to sales, marketing and field personnel. over the years, HONE migrated to vm370 and became the online, interactive support for sales, marketing and field personnel around the world. I would continue to provide them with custom built cp67 and then vm370 systems.

... and some old HONE and other references from around the world

Having published some stuff internally on HYPERchannel ... as part of the HSDT activities
https://www.garlic.com/~lynn/subnetwork.html#hsdt

Date: 12 January 1983, 10:01:21 FIN
To: wheeler
From: somebody in Helsinki (HEKVM)

Greetings from Finland.

We have a customer who is planning to install VM/HPO and test MVS under it in 4341-2. His plans include to connect the MVS with HYPERchannel with a couple of Tandems and Honeywells. The question is how do we generate the HYPERchannel into VM ? My best guess is CTCA. And the second question is: any possible troubles we might have with the HYPERchannel. I asked these question from xxxxxx and he told me that you know best what to do.

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

similarly here with respect to VMSHARE

Date: 27 February 1983, 10:07:52 CET
To: wheeler
From: from HONE userid originating someplace in KUWAIT
Subject: vmshare

Lynn, I got very confused from the various informations I received from XXXXXX amd YYYYYY. My customer is a new member of both SEAS and SHARE . As they already have a link to USA , they would like to access Tymnet and the VMSHARE data base . XXXXXX and YYYYY are only taking care of VMSEAS . Can you help me .

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

Tymshare was providing "VMSHARE" computing conferencing to SHARE (and SHARE members) staring in the mid-70s I started shadowing all the files and making them available on various internal systems, including HONE complex (and HONE clones around the world).

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

When IBM/PC was made available, "PCSHARE" computer conferencing was added.

Date: 12/14/82 11:26:36
To: wheeler
From: Paris-La Defense;
December in Paris--Lights in the trees along the Champs Elysee

Dear Lynn:

I feel like I must have been off somewhere with my head in the clouds, but I hadn't heard about PCSHARE until yesterday, when a friend pointed it out as being on the Uithoorn HONE system. I knew about IBMPC 193 and 194 on YKTVMV and the PCLIB system at Endicott of XXXXXX, but even though I was at the PC Symposium at Yorktown a couple of months ago, I never heard it mentioned previously.

I maintain the PC disks on our EHQ system here, mostly with stuff from Yorktown and Endicott, with a few oddballs I get from here and there. I would like to somehow set up the PCSHARE system here, but see there are an awful lot of files, and they are obviously being appended to constantly. I don't want to add that many files to our PC disk, since it would greatly confuse things I think. I guess I'll have to set up another disk. Do you have any system set up to properly use it if I do? I suspose that it's on the HONE system disk, but too many files to really recognize what's what, and guess I need a little tutorial.

I have sent for a CMS EXEC list of the files on PCSHARE 294 on SJRLVM4 using DATASTAG, so guess that is the right way to get them. But how do I keep up to date without a lot of work once I bring the files in? Thanks for any light you can provide on PCSHARE.

Salutations distinguees et bien Cordialement le bonjour de Paris chez vous!

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

Date: 12/17/82 14:58:46
To: wheeler
From: Paris-La Defense;

Dear Lynn:

DATASTAG (wonderful invention) has kindly sent me all of the items on the SJRLVM1 PCSHARE disk, for which the last and largest items are just straggling in from a request 24 hours ago. I therefore don't think I need an initial distribution of it, but do want to get on the distribution list for changes/updates in the future, since I will maintain it here for our users.

You used to send me updated CMS EXEC's of the VMSHARE files, but not the actual files. Since that doesn't do our users here much good, I would like to do the same thing for the VMSHARE files. Can you point me to your VMSHARE files, I can order them myself, but also want to be on the distribution for them in the future as well.

Salutations distinguees et bien Cordialement le bonjour de Paris chez vous!

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

other old email mentioning VMSHARE (&/or PCSHARE):
https://www.garlic.com/~lynn/lhwemail.html#vmshare

DATASTAG was sort of a ftp/anonomous facility ... past refs
https://www.garlic.com/~lynn/2006v.html#22 vmshare
https://www.garlic.com/~lynn/2007b.html#7 information utility

====

There were also the various internal TOOLSRUN-based computer conferences (VMTOOLS, PCTOOLS, PCLIB, etc. misc. posts mentioning TOOSLRUN:
https://www.garlic.com/~lynn/2001c.html#5 what makes a cpu fast
https://www.garlic.com/~lynn/2002d.html#33 LISTSERV(r) on mainframes
https://www.garlic.com/~lynn/2003i.html#18 MVS 3.8
https://www.garlic.com/~lynn/2004o.html#48 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005q.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005r.html#22 z/VM Listserv?
https://www.garlic.com/~lynn/2006h.html#9 It's official: "nuke" infected Windows PCs instead of fixing them
https://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#16 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006w.html#35 Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?
https://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?
https://www.garlic.com/~lynn/2007b.html#7 information utility
https://www.garlic.com/~lynn/2007b.html#31 IBMLink 2000 Finding ESO levels
https://www.garlic.com/~lynn/2007b.html#32 IBMLink 2000 Finding ESO levels

====

old lisa info

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: old lisa info
Newsgroups: alt.folklore.computers
Date: Wed, 17 Jan 2007 07:19:38 -0700

Old "Lisa" information (from people around silicon valley) ... note comment in following about computer serial number ...

Date: 02/13/83 09:09:09
From: wheeler

re: lisa; there will be only 70 or so, Lisa Information Centers in the US that will be authorized to sell Lisas. They should have their demo machines by 1st or 2nd week in March. There is still a huge amount of software development going on that probably won't be seen until FCS (June or July). They will have extensive programmer & application development support (a Programmer's Tool Box) by FCS. Languages will be (at least) Pascal, Cobal, and Basic. Most of the Lisa stuff is apparently in Pascal. The Programmer's Tool Box will have extensive support/interface to the Desktop Manager to allow easy development of applications which support advanced features, like moving pieces of data from one environment to another. Each Lisa will have a machine readible serial number, and there are extensive features to guarantee that a particular piece of software only runs on the machine it was sold for. Since every piece of Lisa is easily field replaceable (interchangeble) by the customer, except for the video board ... it is likely that the serial number resides somewhere there.

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

Date: 02/13/83 11:20:08
From: wheeler

re: lisa; misc. Basic configuration for $9,995 has 68000, one megabyte of memory, 12-inch bit-mapped display (about twice the pixels of IBM monitor), dual 860k disk drives, keyboard, mouse, 5-megabyte hard disk, operating system and six integrated office applications.

Estimated price of fully configured IBM/PC1 with software to approximate Lisa package (including projected VISON) comes in around $11,000 & it is nowhere in the same ballpark.

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

& from wiki
https://en.wikipedia.org/wiki/Apple_Lisa

My brother was an apple regional marketing rep (he said the largest physical region in the contenential US). Before Mac was announced, I got to have dinner with him and some of the people working on Mac ... and I would argue that the ibm/pc would be successful because business could buy ibm/pc for about the same price as 3270 terminal and have single desk footprint ... doing both terminal emulation and some amount of local desktop computing.

past posts mentioning terminal emulation
https://www.garlic.com/~lynn/subnetwork.html#emulation

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Wed, 17 Jan 2007 07:51:19 -0700

scott@slp53.sl.home (Scott Lurndal) writes:
I disagree. Particularly with the modern push towards multicore processors, having a basic understanding of processor architecture is essential to develop good code. Understanding of things like activation records, stack frames, strong vs. weak memory models, memory barriers, synchronization primitives et. al. are key even for application programmers (and essential for kernel and hypervisor developers).

re:
https://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism?

with the above post in thread in comp.arch, I introduced the following URL
http://www.hpcwire.com/hpc/1196095.html

with quote from the article how it can simplify/enhance being able to write programs for highly parallel/scallable environment.

the ensuing posts in the thread about whether better abstractions help deal with complex problems .... and is similar to some similar discussions I remember circa 1980 about similar hardware feature in 801/risc (and was used for aixv3 journal filesystem, JFS for rs/6000).

misc. past posts about 801, romp, rios, pc/rt, rs/6000, fort knox, etc
https://www.garlic.com/~lynn/subtopic.html#801

Authentication architecture on a Unix Network

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication architecture on a Unix Network
Newsgroups: comp.security.unix
Date: Wed, 17 Jan 2007 10:44:34 -0700

Jeremy Worrells <worrells@xmission.xmission.com> writes:
My suggestion would be to look into LDAP for centralized, secure authentication.

for some topic drift, recent post with LDAP reference
https://www.garlic.com/~lynn/2007b.html#31

lots of LDAPs are implemented using RDBMS ... misc. collected posts mentioning working on original relational/sql implementation, System/R
https://www.garlic.com/~lynn/submain.html#systemr

now another widely used mechanism for authentication is Kerberos ... original developed as part of Project Athenaa. recent kerberos reference
https://www.garlic.com/~lynn/2007b.html#13

in the 80s, we periodically went in to audit various Project Athena projects ... including Kerberos ... one week we were there, they were just in the process of working out cross-domain operation .. and we sat thru a day or two participating. Kerberos has also morphed into ietf rfc standard ... and is built into a number of operating system platforms. misc. past posts mentioning Kerberos and/or PK-INIT (i.e. using digital signature for initial kerberos authentication mechanism rather than password)
https://www.garlic.com/~lynn/subpubkey.html#kerberos

for ietf RFC references ... see my rfc index
https://www.garlic.com/~lynn/rfcietff.htm

and click on Term (term->RFC#) in the RFCs listed by section.

and scroll down to kerberos ... i.e.
kerberos
see also authentication , generic security service , security
4757 4752 4559 4557 4556 4537 4430 4402 4121 4120 3962 3961 3244 3129 2942 2712 2623 1964 1510 1411

clicking on the RFC number brings up the RFC summary in the lower frame. Clicking on the ".txt=nnn" field (in the RFC summary), retrieves the actual RFC

and for "LDAP" ietf rfc references, it is also possible to click on "LDAP" (and/or "LDAPv2", "LDAPv3") in Acronym fastpath section. i.e.
lightweight directory access protocol (LDAP ) (LDAPv2) (LDAPv3 )
see also ITU directory service protocol , directory
4533 4532 4531 4530 4529 4528 4527 4526 4525 4524 4523 4522 4521 4520 4519 4518 4517 4516 4515 4514 4513 4512 4511 4510 4403 4373 4370 4104 3928 3909 3876 3866 3829 3771 3727 3712 3703 3698 3687 3674 3673 3672 3671 3663 3494 3384 3383 3377 3352 3296 3112 3088 3062 3060 3045 2927 2926 2891 2849 2830 2829 2820 2798 2739 2714 2713 2696 2657 2649 2596 2589 2587 2559 2307 2256 2255 2254 2253 2252 2251 2247 2164 1960 1959 1823 1798 1778 1777 1558 1487 1249

... note in the kerberos "see also" ... it is also possible to click on "authentication" ... and get all RFCs related to authentication.

There has also been some work on the generalized infrastructure under "Authentication, Authorization and Accounting" ... i.e.
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
4740 3588 3539 3127 2989 2977 2906 2905 2904 2903

Peter Gutmann Rips Windows Vista Content Protection

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Peter Gutmann Rips Windows Vista Content Protection
Newsgroups: alt.privacy
Date: Wed, 17 Jan 2007 19:41:33 -0700

bystander writes:
May I ask, just what is this DRM? I keep hearing of it, but it seems to be taken that everybody knows what it is/does. Can someone explain to a non-techie, please?

here is a flavor from long ago and far away
https://www.garlic.com/~lynn/2007b.html#56 old lisa info

while the above is from 1983 ... a similar concept was introduced in 1970 with announcement of 370 mainframes with a similar facility.

before it was announced, i spent a little time in a group looking at feasability of doing something similar for the original ibm/pc (however we would come up with an anti-piracy scenario and then usually also come up with frequently trivial countermeasure).

basically it tends to be countermeasure to various forms of piracy ... and used to be called anti-piracy ... before the DRM term was coined. Around the time DRM term was coined, there were comments that the US and UK have the distinction of being the only countries where piracy is only fifty percent.

in the mid-80s there were solutions with specially encoded floppy disks that could be read ... but couldn't be duplicated. at application startup, there would be request to insert the appropriate floppy disk. This partially floundered with increase in hard disk sizes and being able to load multiple applications (as well as techniques to copy/counterfeit the floppy disk).

these days, you may find higher-end applications sold with special hardware tokens ... originally serial port ... but now USB ... that serve somewhat the same purpose.

Securing financial transactions a high priority for 2007

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 10:22:13 -0700

jmfbahciv writes:
A new news item yesterday was the hacking of a retail conglomerate's data. In addition to credit card info, there was also social security numbers of their customers and, this is the important one, their checking account data. So if write a personal check, the account and bank numbers get stored permanently. They are NOT destroying the check as is stated in all the notices I've been getting on my electric, telephone, cable, and credit card bills.

re:
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007

in the mid-90s, the x9a10 financial standard working group had been given the requirement for preserving the integrity of the financial infrastructure for all retail payments .... not just credit, not just debit, not just check, not just internet, but ALL.

the result was x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

part of the standard was looking at how it would map to credit, debit and check/ACH

so part of this was doing a detailed threat analysis. lots of past posts about threats, vulnerability, fraud, exploits, etc
https://www.garlic.com/~lynn/subintegrity.html#fraud

for completely other drift ... some mention of online banking and issue of man-in-the-middle vulnerability raised a year ago
https://www.garlic.com/~lynn/2007b.html#53 Forbidding Special characters in passwords
https://www.garlic.com/~lynn/2007b.html#54 Forbidding Special characters in passwords

and possibly related news article (disclosing vulnerabilities):

The Chilling Effect
http://www.csoonline.com/read/010107/fea_vuln.html

now some of the confusion has been that the term identity theft actually applies to very wide range of fraudulent activity. somewhat as a result there has been efforts by FDIC and other agencies to refine the definition of identity theft ... primarily to differentiate account fraud (which is doing fraudulent transactions against existing accounts, frequently just needing knowledge of existing account numbers) and (real) identity theft (using personal information to establish new accounts or perform transactions not involving existing accounts).

A major problem in the account fraud scenario is that there are currently diametrically opposing requirements involving the account number. One one hand, the account number needs to be readily available for use in dozens of business processes (most of them back room, never actually seen directly by a consumer). On the other hand, just letting an attack have knowledge of the account number is sufficient for enabling fraudulent transactions ... and as a result, account numbers need to be kept confidential and never divulged. This also has somewhat motivated my comments about even if the planet were buried miles deep in (information hiding) encryption, it still would be insufficient to prevent account number leakage. some number of posts about account number havesting vulnerabilities
https://www.garlic.com/~lynn/subintegrity.html#harvest

recent post in another thread about "naked payments" and needing to bury the planet miles deep in encryption
https://www.garlic.com/~lynn/2006y.html#25 The Elements of Programming Style

Slight topic drift, recent post on encrypting everything
https://www.garlic.com/~lynn/aadsm26.htm#23 It's a Presidential Mandate, Feds use it. How come you are not using FED?

The situation is further complicated because long term statistics are that the major fraud threat is from insiders (the very people that would be involved in backroom business processes requiring access to account numbers). Somewhat related post about security proportional to risk (risk out of proportion to rest of operations, making it difficult to justify adequate countermeasures, including against insiders):
https://www.garlic.com/~lynn/2001h.html#61

So the x9.59 financial standard scenario is that it be used for ALL retail payments (even check) ... and x9.59 also changes the paradigm, eliminating knowledge of account number as a vulnerability. This eliminates the majority of account fraud (which is the majority of current, broad use of identity theft). Frequently SSN and/or license numbers are required as additional personal information added to existing transactions (as part of countermeasure to various kinds of fraud). That type of requirement for such additional personal information is also eliminated by x9.59 standard.

While x9.59 standard may address the majority of account fraud (major component of identity theft) and also eliminate needing to divulged personal information as part of x9.59 transactions ... it doesn't directly address the use of such personal information for the remaining kinds of identity theft (establishing new fraudulent accounts and/or doing other kinds of operations that depend on personal information). However, by eliminating much of the existing account fraud ... and also eliminating some amount of proliferation of places needing personal information ... the case can be made that x9.59 could free up significant resources which then can be used to concentrate on the remaining forms of identity theft.

other parts of this thread
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007

=======

Securing financial transactions a high priority for 2007

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 12:55:26 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
now some of the confusion has been that the term identity theft actually applies to very wide range of fraudulent activity. somewhat as a result there has been efforts by FDIC and other agencies to refine the definition of identity theft ... primarily to differentiate account fraud (which is doing fraudulent transactions against existing accounts, frequently just needing knowledge of existing account numbers) and (real) identity theft (using personal information to establish new accounts or perform transactions not involving existing accounts).

re:
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007

one of the things that the x9a10 financial standard working group had to take into account was that in the mid-90s the EU had made some statement that retail payments should be as anonymous as cash ... i.e. no name, no address, no telephone number, and no other personal gorp.

in that sense we attempted to make the x9.59 financial standard for all retail payments, privacy agnostic.
https://www.garlic.com/~lynn/subpubkey.html#x959

x9.59 would meet the requirement given the x9a10 financial standard working group to preserve the integrity of the financial infrastructure for all retail payments ... as well as

1) eliminate account number vulnerabilies (didn't do anything about eliminating data breaches and security breaches ... but drastically reduced the risk when such breaches happened ... especially related to account fraud) and

2) drastically reduced the places (all retail payments) where personal information might beq required (and therefor drastically reduced the responsitories containing such personal information ... hopefully helping reduce actually occurances of other types of identity theft) ... also meeting the EU statement on making retail payments as anonymous as cash ... or at least privacy agnostic

some of this led up to being the co-author of the x9.99 financial industry privacy standard. as part of that effort ... I pulled together a merged (eu-dpd, glba, hipaa, etc) privacy taxonomy and glossary ... references to merged taxonomy and glossary activities
https://www.garlic.com/~lynn/index.html#glosnote

for other drift ...
https://www.garlic.com/~lynn/2007b.html#31 IBMLink 2000 Finding ESO levels

one of the other things that happened in the mid-90s was the transition from X.509 identity digital certificates to relying-party-only digital certificates ... misc. past posts mentioning RPO-certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

the problem was that X.509 identity digital certificates tended to be grossly overloaded with personal information ... and it eventually dawned that PKI operations that sprayed X.509 identity digital certificates all over the world could represent significant privacy and liability issues.

note, however, we were frequently able to trivially show that RPO-certificates were redundant and superfluous ... and therefor you could deploy a secure digital signature authentication infrastructure w/o requiring the horrible complexity of a PKI operations ... i.e. certificate-less operation
https://www.garlic.com/~lynn/subpubkey.html#certless

and recent posting containing an old 1981 proposal for a public key operation w/o digital certificates
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

and misc. past posts mentioning privacy agnostic
https://www.garlic.com/~lynn/aadsm19.htm#49 Why Blockbuster looks at your ID
https://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
https://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
https://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005u.html#8 PGP Lame question
https://www.garlic.com/~lynn/2006v.html#39 On sci.crypt: New attacks on the financial PIN processing

Securing financial transactions a high priority for 2007

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 13:12:04 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
1) eliminate account number vulnerabilies (didn't do anything about eliminating data breaches and security breaches ... but drastically reduced the risk when such breaches happened ... especially related to "account fraud") and

https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007

late breaking data breach, security breach news ....

TJX Says Computer Systems Hacked - Breaking
http://www.smh.com.au/news/Technology/TJX-says-it-suffered-computer-systems-intrusion-customer-datastolen/2007/01/18/1168709865048.html
T.J. Maxx, Marshalls customer credit information hijacked
http://news.bostonherald.com/localRegional/view.bg?articleid=177792
T.J. Maxx parent says customer data stolen
http://news.com.com/T.J.+Maxx+parent+says+customer+data+stolen/2100-1029_3-6151017.html

Is Silicon Valley strangeled by SOX?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Is Silicon Valley strangeled by SOX?
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 13:17:37 -0700

Is Silicon Valley strangled by SOX?
http://news.com.com/Is+Silicon+Valley+strangled+by+SOX/2100-1014_3-6151059.html?tag=nefd.lede

The Sarbanes-Oxley Act might be meant to guard against massive white-collar scandals, but the resignation of a high-profile tech veteran suggests the law may also be restricting efficiency atop Silicon Valley's corporate ladder.

... snip ...

SOX was recently given as an excuse why Apple was charging for 802.11 software upgrade (rather than just making it free).

misc. past posts mentioning sarbanes-oxley
https://www.garlic.com/~lynn/aadsm19.htm#10 Security as a "Consumer Choice" model or as a sales (SANS) model?
https://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
https://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#26 Fraudwatch - how much a Brit costs, how to be a 419-er, Sarbanes-Oxley rises as fraud rises, the real Piracy
https://www.garlic.com/~lynn/aadsm25.htm#43 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
https://www.garlic.com/~lynn/aadsm26.htm#2 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
https://www.garlic.com/~lynn/aadsm5.htm#xmlvch implementations of "XML Voucher: Generic Voucher Language" ?
https://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006j.html#28 Password Complexity
https://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006u.html#22 AOS: The next big thing in data storage

Securing financial transactions a high priority for 2007

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 13:30:20 -0700

re:
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007

and for a little additional drift

The Corrosive Siege Over Signature-Card Interchange
http://www.digitaltransactions.net/newsstory.cfm?newsid=1223

from above:
The goose that has laid decades of golden eggs in credit card and signature-debit card interchange is getting long in the tooth. Usage has clearly matured, and most new demand is driven either by easy rewards for consumers who don't need to use signature-based cards or by easy credit for paycheck-to-paycheck households that increasingly use them to make ends meet.

... snip ...

one of the replacements was defined in the mid-90s, somewhat at the same time as the work on x9.59
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
and aads
https://www.garlic.com/~lynn/x959.html#aads

and had some early deployments in the late 90s ... one was by ibm for safeway in the UK ... references
https://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
https://www.garlic.com/~lynn/2002o.html#43 THIS WEEKEND: VINTAGE COMPUTER FESTIVAL 5.0
https://www.garlic.com/~lynn/2006l.html#33 Google Architecture

shortly after the early deployments ... the yes card exploit appeared
https://www.garlic.com/~lynn/subintegrity.html#yescard

and appeared to have continued up thru current day deployments (nearly ten years later).

newbie need help (ECC and wireless)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: newbie need help (ECC and wireless)
Newsgroups: sci.crypt
Date: Thu, 18 Jan 2007 14:16:26 -0700

re:
https://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless)

for a little topic drift ... crypto/ECC related RFCs published today, 4753, 4754, and 4764.

from my rfc index
https://www.garlic.com/~lynn/rfcietff.htm

RFC summaries ... in my rfc index summaries, clicking on the ".txt=nnn" field retrieves the actual rfc

https://www.garlic.com/~lynn/rfcidx15.htm#4753
4753 I
ECP Groups For IKE and IKEv2, Fu D., Solinas J., 2007/01/18 (16pp) (.txt=28760) (Refs 2409, 3526, 4306) (Ref'ed By 4754) (was draft-ietf-ipsec-ike-ecp-groups-03.txt)

...>https://www.garlic.com/~lynn/rfcidx15.htm#4754
4754 PS
IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA), Fu D., Solinas J., 2007/01/18 (15pp) (.txt=27948) (Refs 2409, 4306, 4753) (was draft-ietf-ipsec-ike-auth-ecdsa-06.txt)

...>https://www.garlic.com/~lynn/rfcidx15.htm#4764
4764 E
The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method, Bersani F., Tschofenig H., 2007/01/18 (64pp) (.txt=133990) (Refs 1661, 1796, 1994, 2243, 2289, 2716, 2898, 2989, 3748, 4086, 4186, 4187, 4279, 4282, 4302) (was draft-bersani-eap-psk-11.txt)

previous, next, index - home