List of Archived Posts

2006 Newsgroup Postings (05/18 - 05/30)

Passwords for bank sites - change or not?
Hey! Keep Your Hands Out Of My Abstraction Layer!
Hey! Keep Your Hands Out Of My Abstraction Layer!
Arpa address
Passwords for bank sites - change or not?
Value of an old IBM PS/2 CL57 SX Laptop
Hey! Keep Your Hands Out Of My Abstraction Layer!
Impossible Database Design?
Arpa address
Arpa address
Arpa address
Hey! Keep Your Hands Out Of My Abstraction Layer!
Arpa address
The Pankian Metaphor
The Pankian Metaphor
Passwords for bank sites - change or not?
Value of an old IBM PS/2 CL57 SX Laptop
Hey! Keep Your Hands Out Of My Abstraction Layer!
Value of an old IBM PS/2 CL57 SX Laptop
Hey! Keep Your Hands Out Of My Abstraction Layer!
Hey! Keep Your Hands Out Of My Abstraction Layer!
Sending CONSOLE/SYSLOG To Off-Mainframe Server
Encryption for Powerpoint?
Value of an old IBM PS/2 CL57 SX Laptop
Value of an old IBM PS/2 CL57 SX Laptop
Can anythink kill x86-64?
Value of an old IBM PS/2 CL57 SX Laptop
PDP-1
Hashes and Passwords
PDP-1
PDP-1
PDP-1
PDP-1
Password Complexity
PDP-1
PDP-1
PDP-1
PDP-1
PDP-1
PDP-1
Arpa address
PDP-1
Arpa address
Arpa address
virtual memory
Hey! Keep Your Hands Out Of My Abstraction Layer!
Keylogger resistance
Hey! Keep Your Hands Out Of My Abstraction Layer!
Hey! Keep Your Hands Out Of My Abstraction Layer!
Value of an old IBM PS/2 CL57 SX Laptop
TSO and more was: PDP-1
other cp/cms history
Keylogger resistance
Hey! Keep Your Hands Out Of My Abstraction Layer!
Hey! Keep Your Hands Out Of My Abstraction Layer!
5963 (computer grade dual triode) production dates?
Hey! Keep Your Hands Out Of My Abstraction Layer!
virtual memory

Passwords for bank sites - change or not?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Passwords for bank sites - change or not?
Newsgroups: alt.computer.security
Date: Thu, 18 May 2006 19:41:06 -0600
TwistyCreek writes:
They're no more or less secure than anything else if mishandled, or if the protocols are breakable. That's the big bitch about PIN numbers these days, not writing them on the card. The hardware that's supposedly secure is crackable, and whether or not you use a 4 digit PIN, your fingerprint, or a retinal scan combined with a 100 character random password is meaningless.

re:
http://www.garlic.com/~lynn/2006j.html#42 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006j.html#52 Passwords for bank sites - change or not?

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

something you have
something you know
something you are

the card is a something you have and the PIN is something you know. the nominal assumption in multi-factor authentication is that the different factors are subject to different vulnerabilities.

however the well established skimming activity has been able to harvest magstripe information (static data that supposedly represents the card, something you have) and the PIN (static data something you know) at the same time (at compromised and/or counterfeit terminals or devices) ... invalidating assumption about multi-factor authentication having independent vulnerabilities.
http://www.garlic.com/~lynn/subintegrity.html#harvest

some recent posts about yes card and recent chip&pin skimming:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#41 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#26 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Thu, 18 May 2006 20:23:42 -0600
"Wrolf" writes:
Why did TCP/IP win over OSI?

1) As I understand it, RFCs needed two interoperating implementations before becoming standards. ISO standards were set first by well meaning individuals, then implementations were attempted.

2) Many participants in OSI meetings were there to learn, not contribute.

3) OSI standards were therefore pie in the sky - you only learned after the standards were set that performance or reliability or other killer problems had been baked in, or that there was an overwhelmingly simpler way that any successful implementation would have uncovered.

4) The 7 layer model proved too complex, leading to many inefficiencies and complexities (including multiple buffer to buffer copies).


there were also organization issues ... ISO had a "rule" that you couldn't have standards work on protocols that didn't confirm to the osi model.

we had taken high-speed protocol proposal to x3s3.3 (ansi iso chartered body repsonible for networking and transport layer). it would go directly from transport to mac ... including support for internetworking. it was rejected because

1) lan mac interface sits in the middle of layer 3, going directly from transport to mac interface violated osi model by bypassing layer 3/4 interface.

2) osi has no provisions at all for supporting internetworking ... so anything that supported internetworking violates osi model

3) lan mac interface in the middle of layer 3 violates osi model, so anything that interfaces to lan mac violates osi model.

http://www.garlic.com/~lynn/subnetwork.html#xtphsp

in some sense, osi was similar/analogous to the arpanet, pre-internetworking ... having relatively homogeneous operation w/o gateway and internetworking support.

i've frequently asserted that the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

was larger than the arpanet/internet (from just about the beginning until possibly mid-85) because the internal network had a kind of gateway support in every node ... which arpanet didn't get until the great switch-over to internetworking on 1/1/83.

misc. recent postings on the subject:
http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
http://www.garlic.com/~lynn/2006j.html#50 Arpa address
http://www.garlic.com/~lynn/2006j.html#53 Arpa address

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Thu, 18 May 2006 22:12:30 -0600
"Wrolf" writes:
It is robust enough that HTTP/HTTPS just uses it without provoking any need for further optimization. As does SMB/CIFS. NFS turned out to be a big performance loser in WAN applications because the designers decided to bypass TCP and use UDP - but only tuned it for LAN applications, losing out on all the then current and future optimizations.

tcp has minimum 7 packet exchange, vmtp (rfc1045) has minimum 5 packet exchange, xtp has 3 packet exchange for reliable communication
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

most tcp implementations assumed relatively few long running sessions. http totally changed all that. as some of the webservers saw increased load, some of them started finding 95+ plus processor cpu being spent running FINWAIT list ... checking for dangling packets on termination. it was crisis period for some webservers and required a bit of rework to handle the situation.

we were called in to consult with this small client/server startup that wanted to do payments on the server. we worked with them creating and deploying a payment gateway and webservers communicating with the payment gateway to do financial transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

this small client/server startup had this technology called https. the way that https was suppose to work for e-commerce was that the client typed in a host name url. the browser contacted a the server. the server returned a ssl domain name digital certificate. the browser verified the digital certificate and then cross checked that the domain name (in the url typed in by the user) is the same as the domain name in the returned digital certificate. if they matched, then there was some assurance that the webserver that the person thot they were talking to ... was in fact the webserver they were talking to. this was a countermeasure to webserver impersonation/spoofing.

so what happened? relatively quickly, webservers found that https reduced their processing capacity by 80-90percent ... that webservers could support to 5-6 times more load if they just used http instead of https.

so webservers changed to use plain http for the shopping experience and saved https for the checkout/pay experience. the webserver provides a button to click for checkout/pay that invokes https. the issue here is that the button now provides the url for invoking the https process. now it means that the url domain name provided in the button from the webserver is matched against the domain name in the digital certificate provided by the webserver. misc past posts on ssl certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

the process was suppose to check that the domain name provided by the user matches the domain name provided by the webserver digital certificate. now the processes checks that the domain name provided by the webserver matches the domain name in the digital certificate provided by the webserver. if it were really a fraudulent webserver ... it would be an incompetent crook that wouldn't specify a domain name in their checkout button that didn't correspond to the domain name in the certificate they supply.

misc. postings discussing the change in SSL process negating the original assumptions about what integrity was provided by SSL.
http://www.garlic.com/~lynn/aadsm19.htm#26 Trojan horse attack involving many major Israeli companies, executives
http://www.garlic.com/~lynn/aadsm20.htm#6 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model
http://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/2003n.html#10 Cracking SSL
http://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005u.html#20 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor

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

Arpa address

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Thu, 18 May 2006 23:08:50 -0600
ref:
http://www.garlic.com/~lynn/2006j.html#49 Arpa address

from
http://www.garlic.com/~lynn/internet.htm#0
CSNET (Computer Science NETwork) is funded by NSF, and is an attempt to connect all computer science research institutions in the U.S. It does not have a physical network of its own, but rather is a set of common protocols used on top of the ARPANET (Department of Defense), TeleNet (GTE), and PhoneNet (the regular phone system). The lowest-cost entry is through PhoneNet, which only requires the addition of a modem to an existing computer system. PhoneNet offers only message transfer (off-line, queued, files). TeleNet and ARPANET in allow higher-speed connections and on-line network capabilities such as remote file lookup and transfer on-line, and remote login.

... snip ...

from
http://www.garlic.com/~lynn/internet.htm#22

from the 83 file .... 1000 mainframes on the internal worldwide network 6/10/83.


•                     Date Sent     6-14-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ CPHVMCE           * CPHVM1/9   4341/VM   EMEA Copenhagen, Denmark
- CPHVMEC           * CPHVM1/9   4341/VM   EMEA Copenhagen, Denmark
•    I have just received word that CPHVMEC, the 1000th node that
• appeared 6/10/83 was the incorrect node name due to some misunder-
• standing in Copenhagen.   CPHVMCE is the correct name.

couple more samples from the 83 file

•                     Date Sent     7-29-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ BPLVM             * PKMFGVM/9  4341/VM   DSD  Brooklyn, N.Y.     8-868-2166
+ FRKVMPF1          * STFFE1/9   4341/VM   CSD  Franklin Lakes, NJ 8-731-3500
+ FUJVM1            * FDLVM1/4   3033/VM   AFE  Fujisawa, Japan
+ GBGMVSFE          * GBGVMFE3/C GUEST/MVS FED  Gaithersburg, Md.  8-372-5808
+ LAGVM5            * LAGM3/9    168/VM    CPD  La Gaude, France
+ LAGVM7            * LAGM1/9    3032/VM   CPD  La Gaude, France
+ MVDVM1            * BUEVM1/2   4341/VM   AFE  Montevideo,Uruguay 98-90-17
+ RALVMK            * RALVMA/C   4341/VM   CPD  Raleigh, N.C.      8-441-7281
+ RALVMM            * RALVS6/C   4341/VM   CPD  Raleigh, N.C.      8-227-4570
+ RALVMP            * RALVM2/C   3081/VM   CPD  Raleigh, N.C.      8-442-3763
+ RCHVM1PD          * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ RCHVM2            * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ RCHVM3            * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ SJMMVS16          * SNJMAS2/9  4341/MVS  GPD  San Jose, Ca.      8-294-5103
+ SJMMVS17          * SNJMAS1/9  4341/MVS  GPD  San Jose, Ca.      8-276-6657
+ TUCVMJ            * TUCVMI/5   148/VM    GPD  Tucson, Arizona    8-562-7100
+ TUCVMN1           * TUCVM2/C   4341/VM   GPD  Tucson, Arizona    8-562-6074
+ UITECVM1          * UITHON2/9  4341/VM   EMEA Uithoorn, Netherlands

•                    Date Sent    12-15-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ ADMVM2            * ADMVM1/9   4341/VM   EMEA Amsterdam, Neth.   20-5133034
+ BOEVMN            * BOEVM1/9   4361/VM   SPD  Boeblingen, Ger. 49-7031-16-3578
+ BRMVM1            * MTLVM1/9   4341/VM   AFE  Bromont, Canada    514-874-7871
+ DUBVM2            * RESPOND/4  3158/VM   EMEA Dublin, Ireland    785344 x4324
+ ENDVMAS3          * ENDCMPVM/C 3081/VM   GTD  Endicott, N.Y.     8-252-2676
+ KGNVME            * KGNVMN/C   3081/VM   DSD  Kingston, N.Y.
+ KISTAINS          * KISTAVM/9  4341/VM   EMEA Stockholm, Sweden
+ MDRVM2            * MDRVM1/9   3031/VM   EMEA Madrid, Spain      34-1-4314000
+ MSPVMIC3          * MSPVMIC1/9 4341/VM   FED  Minneapolis, Minn. 8-653-2247
+ POKCAD1           * PKDPDVM/9  4341/VM   NAD  Poughkeepsie, N.Y. 8-253-6398
+ POKCAD2           * POKCAD1/C  4341/VM   NAD  Poughkeepsie, N.Y. 8-253-6398
+ SJEMAS5           * SNJMAS3/S  4341/MVS  GPD  San Jose, Ca.      8-276-6595
+ TOKVMSI2          * FDLVM1/9   3031/VM   AFE  Tokyo, Japan

... snip ...

and from
http://www.garlic.com/~lynn/2000e.html#18



Date: 30 Dec 1982 14:45:34 EST (Thursday)
From: Nancy Mimno <mimno@Bbn-Unix>
Subject: Notice of TCP/IP Transition on ARPANET
To: csnet-liaisons at Udel-Relay
Cc: mimno at Bbn-Unix
Via:  Bbn-Unix; 30 Dec 82 16:07-EST
Via:  Udel-Relay; 30 Dec 82 13:15-PDT
Via:  Rand-Relay; 30 Dec 82 16:30-EST

 ARPANET Transition 1 January 1983
 Possible Service Disruption
 ---------------------------------

 Dear Liaison,

As many of you may be aware, the ARPANET has been going through the
major transition of shifting the host-host level protocol from NCP
(Network Control Protocol/Program) to TCP-IP (Transmission Control
Protocol - Internet Protocol).  These two host-host level protocols
are completely different and are incompatible.  This transition has
been planned and carried out over the past several years, proceeding
from initial test implementations through parallel operation over the
last year, and culminating in a cutover to TCP-IP only 1 January
1983. DCA and DARPA have provided substantial support for TCP-IP
development throughout this period and are committed to the cutover
date.

The CSNET team has been doing all it can to facilitate its part in
this transition. The change to TCP-IP is complete for all the CSNET
host facilities that use the ARPANET: the CSNET relays at Delaware and
Rand, the CSNET Service Host and Name Server at Wisconsin, the CSNET
CIC at BBN, and the X.25 development system at Purdue.  Some of these
systems have been using TCP-IP for quite a while, and therefore we
expect few problems.  (Please note that we say "few", not "NO
problems"!) Mail between Phonenet sites should not be affected by the
ARPANET transition.  However, mail between Phonenet sites and ARPANET
sites (other than the CSNET facilities noted above) may be disrupted.

The transition requires a major change in each of the more than 250
hosts on the ARPANET; as might be expected, not all hosts will be
ready on 1 January 1983.  For CSNET, this means that disruption of
mail communication will likely result between Phonenet users and some
ARPANET users.  Mail to/from some ARPANET hosts may be delayed; some
host mail service may be unreliable; some hosts may be completely
unreachable. Furthermore, for some ARPANET hosts this disruption may
last a long time, until their TCP-IP implementations are up and
working smoothly.  While we cannot control the actions of ARPANET
hosts, please let us know if we can assist with problems, particularly
by clearing up any confusion.  As always, we are <cic@csnet-sh>
or (617)497-2777.

Please pass this information on to your users.

Respectfully yours,
Nancy Mimno
CSNET CIC Liaison

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

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

Passwords for bank sites - change or not?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Passwords for bank sites - change or not?
Newsgroups: alt.computer.security
Date: Fri, 19 May 2006 07:24:35 -0600
Jim Watt <jimwatt@aol.no_way> writes:
Its certainly about time a standard PC came with a smartcard reader to add another layer of authentication. However simple passwords are not enough for anything sensitive.

ref:
http://www.garlic.com/~lynn/2006j.html#42 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006j.html#52 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?

part of the issue is that static data authentication are vulnerable to skimming/evesdropping/harvesting and replay attacks.

there is issue with just straight-forward hardware token interface. this is one of the reasons for the EU FINREAD terminal specs.
http://www.garlic.com/~lynn/subintegrity.html#finread

it has been well recognized for a long time that PCs have a large number of vulnerabilities. FINREAD terminal was to isolate with relatively high integrity ... 1) the hardware token interface, 2) the PIN-entry interface, and 3) the display interface (for transaction authentication, was the value displayed for the transaction being authenticated, really the value in the transaction being authenticated).

this was attempt to minimize that a compromised PC (with virus/trojans) being able to a) skim the PIN, b) perform interactions with the token w/o the owners knowledge, c) display one set of values for a transaction but perform a totally different transaction.

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

one of the things done in resulting x9.59 financial standard was that it provided for the "authenticating" environment for also authenticating transactions ... i.e. the EU FINREAD standard call for a special high-integrity terminal ... but w/o the terminal also authenticating the transaction, there is no proof to the relying party that a EU FINREAD terminal is being used for the transaction ... aka the transaction might be done purely from the PC w/o a special terminal or might be done with a counterfeit terminal. the transaction is authenticated ... but the environment that the transaction is performed in is also authenticated.

one of the other things that x9.59 did was recognize that current infrastructure has overloaded the account number ... it is required to be exposed for use in a large number of different processes ... but can be sufficient information for a crook to perform a fraudulent transaction. x9.59 defined that account numbers used for x9.59 transactions can't also be used in unauthenticated transactions. this was a recognition that with the large number of business processes requiring the account number to be exposed ... that even burying the planet under miles of information hiding crypto ... it would be still be impossible to prevent account number data breaches and account number skimming.

there is also the issue that numerous studies have continued to find that something like 70percent of breaches resulting in various kinds of identity and account fraud have involved insiders. this somewhat relates to my old post of security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

there are also a large variety of man-in-the-middle attacks against session oriented protocols ... that to eliminate the possibility, require that transactions are explicitly authenticated, in addition to any session oriented authentication (aka authentication performed separately and independent of explicitly authenticated actual operations).

lots of past posts about exploits, vulnerabilities, attacks, and fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

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

Value of an old IBM PS/2 CL57 SX Laptop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 07:40:19 -0600
KR Williams writes:
Yes, this is called "check-21" and is coming to a supermarket near you. Several retailers already scan checks then hand them back to you. You will get an image of the check back, if your bank still does such things. It doesn't add anything to the (in)security of the pull system. It's always been the case that someone with your bank routing information (the numbers you freely give to everyone on the bottom of every check) can just reach in and help themselves. This (check-21) is no worse.

e-check is variation which requires the transaction to be authenticated, typically with digital signature.

the x9a10 financial standards working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. this included all ... as in point-of-sale, internet, face-to-face, non-face-to-face, as well as ach, check, debit, credit, stored-value ... all.

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

was to require that account numbers (including from micr off checks) used in x9.59 transactions could not be used in non-authenticated transactions. early in work on x9.59 standard it was recognized that account numbers have been overloaded ... that they are required to be exposed in a large number of different business processes and the knowledge of the number is frequently sufficient for attackers to perform fraudulent transactions. that you could bury the planet under miles of information hiding cryptography and it still wouldn't be possible to prevent account number leakage.
http://www.garlic.com/~lynn/subintegrity.html#harvest

a somewhat related, recent post
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?

misc. collected posts on vulnerabilities, threats, exploits, fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Fri, 19 May 2006 08:23:51 -0600
"Le Chaud Lapin" writes:
OSI, was more like a mood. I have never seen one line of OSI "code". And trust me, I searched long and hard for it. When I read about OSI, I get the feeling it was "designed" by people who actually knew what they were talking about, but lost the ability to program computers (read implement their vague vision) several decades earlier.

late 80s ... OSI was all the range ... possibly half the booths at interop 88 had various osi implementations on dipslay. misc. past posts mentioning interop 88
http://www.garlic.com/~lynn/subnetwork.html#interop88

the fed. gov. (as well as some number of organizations) was mandating elimination of the internet and tcp/ip and moving everything to osi. some of this can be seen in GOSIP .. misc. recent postings mentioning gosip
http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006i.html#19 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#20 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006j.html#34 Arpa address

minor ref:
GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)

The Federal Information Processing Standard (FIPS) describing the Federal government's policy, including the DoD transition from TCP/IP to ISO international protocols.


... snip ...

there have been some claims that OSI was primarily worked on by telco oriented individuals reflecting the copper wire, point-to-point, homogeneous service, enterprise/institutional oriented networks of the 60s and 70s.

there was no concept of cross organizational and/or internetworking involving different and/or heterogeneous operations (aka instead some sort of telco or other operation was provide a homogeneous service to all its participants and/or subscribers). this is somewhat the 70s, pre-internetworking (1/1/83) ARPANET design. the whole concept of LANs and WANs also didn't exist.

ISO compounded the problem with rules about not considering standardization of protocols that violated OSI. recent post in this thread
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!

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

Impossible Database Design?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Impossible Database Design?
Newsgroups: comp.databases.theory
Date: Fri, 19 May 2006 09:11:05 -0600
"David Cressey" writes:
Back in the 1980s, I used to teach database programming and design in an industrial setting. The course was product specific, (DEC Rdb/VMS), but many of the concepts were not. I used to use the ariline reservation system as a classic example of why atomicity in a transaction was important. In my example, if your transactions can't be atomic, you can't prevent overbooking.

Then one time, I got someone as a student who had been on the SAABRE project. He told me that they never did solve that poblem, but management decided that it was a feature and not a bug! I don't know whether I believe it, but it's an interesting fable anyway.

More to the point, back in that time frame, the number of fare changes was about 10,000 per day. I expect it's much greater now.


recent post referencing rewriting major portion of one the airline res. systems (about a decade ago)
http://www.garlic.com/~lynn/2006j.html#6 The Pankian Metaphor

part of the issue was the paradigm had been established in the 60s and while things like scale-up had been done ... there hadn't really been any re-examination of the various design decision trade-offs established in the 60s ... and whether advances in technology might result in making other kinds of design decision trade-offs.

lets say there are around half-million take-off/landings a day (flight segments) and for round numbers there are 50 passengers per flight segment ... so you could have on the order of 25million updates per day (independent of changes in fares and schedules). that is besides possibly similar number of inserts of new PNR records for reservations and then similar number of deletes for old PNR records.

part of the issue is that there has been some amount of bookings where the person is no-show. somewhat as a result there tends to be some fine tuning of capacity planning attempting to get every seat filled, despite some percentage of no-shows.

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

Arpa address

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 10:09:02 -0600
eugene@cse.ucsc.edu (Eugene Miya) writes:
Lynn's problem in this is that he had access to fairly good resources in his part of IBM. Other friends in IBM had to weigh net access for what they did and didn't see the value of access.

IBM placed more value in cute demos and Lotus notes than what the outside world which passed some of it away. Microsoft has learned from some of this; some other firms have benefitted from IBM's bureaucracy.


I thot we were talking about events leading up to 1983 and the size of the networks in 1983.

lotus was an 1995 purchase ... more than a decade later:
http://web.archive.org/web/19991009195729/http://www.dbmsmag.com/fred9508.html

at one point there were supposedly well over 400k employees around the world ... it would not be unusual that some employees in some places of the world might have access to more resources than other employees in the world. it probably also held true for various people from around the world in universities, academia and other institutions.

re:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/internet.htm#22
http://www.garlic.com/~lynn/99.html#112

however from even the little indication in the above frequently referenced network nodes in 1983 ... it would appear that the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

(frequently reposted from the above ...) show at least small indication that one may conclude that the internal network had a fairly extensive world-wide presence (not limited to a few score or few hundred):


•                     Date Sent     6-14-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ CPHVMCE           * CPHVM1/9   4341/VM   EMEA Copenhagen, Denmark
- CPHVMEC           * CPHVM1/9   4341/VM   EMEA Copenhagen, Denmark
•    I have just received word that CPHVMEC, the 1000th node that
• appeared 6/10/83 was the incorrect node name due to some misunder-
• standing in Copenhagen.   CPHVMCE is the correct name.

couple more samples from the 83 file

•                     Date Sent     7-29-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ BPLVM             * PKMFGVM/9  4341/VM   DSD  Brooklyn, N.Y.     8-868-2166
+ FRKVMPF1          * STFFE1/9   4341/VM   CSD  Franklin Lakes, NJ 8-731-3500
+ FUJVM1            * FDLVM1/4   3033/VM   AFE  Fujisawa, Japan
+ GBGMVSFE          * GBGVMFE3/C GUEST/MVS FED  Gaithersburg, Md.  8-372-5808
+ LAGVM5            * LAGM3/9    168/VM    CPD  La Gaude, France
+ LAGVM7            * LAGM1/9    3032/VM   CPD  La Gaude, France
+ MVDVM1            * BUEVM1/2   4341/VM   AFE  Montevideo,Uruguay 98-90-17
+ RALVMK            * RALVMA/C   4341/VM   CPD  Raleigh, N.C.      8-441-7281
+ RALVMM            * RALVS6/C   4341/VM   CPD  Raleigh, N.C.      8-227-4570
+ RALVMP            * RALVM2/C   3081/VM   CPD  Raleigh, N.C.      8-442-3763
+ RCHVM1PD          * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ RCHVM2            * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ RCHVM3            * RCHVM1/C   4341/VM   SPD  Rochester, Mn.
+ SJMMVS16          * SNJMAS2/9  4341/MVS  GPD  San Jose, Ca.      8-294-5103
+ SJMMVS17          * SNJMAS1/9  4341/MVS  GPD  San Jose, Ca.      8-276-6657
+ TUCVMJ            * TUCVMI/5   148/VM    GPD  Tucson, Arizona    8-562-7100
+ TUCVMN1           * TUCVM2/C   4341/VM   GPD  Tucson, Arizona    8-562-6074
+ UITECVM1          * UITHON2/9  4341/VM   EMEA Uithoorn, Netherlands

•                    Date Sent    12-15-83
•  Node              Connected   Machine   DIV    WHERE            OPERATOR
•                     To/How      Type                              NUMBER
+ ADMVM2            * ADMVM1/9   4341/VM   EMEA Amsterdam, Neth.   20-5133034
+ BOEVMN            * BOEVM1/9   4361/VM   SPD  Boeblingen, Ger. 49-7031-16-3578
+ BRMVM1            * MTLVM1/9   4341/VM   AFE  Bromont, Canada    514-874-7871
+ DUBVM2            * RESPOND/4  3158/VM   EMEA Dublin, Ireland    785344 x4324
+ ENDVMAS3          * ENDCMPVM/C 3081/VM   GTD  Endicott, N.Y.     8-252-2676
+ KGNVME            * KGNVMN/C   3081/VM   DSD  Kingston, N.Y.
+ KISTAINS          * KISTAVM/9  4341/VM   EMEA Stockholm, Sweden
+ MDRVM2            * MDRVM1/9   3031/VM   EMEA Madrid, Spain      34-1-4314000
+ MSPVMIC3          * MSPVMIC1/9 4341/VM   FED  Minneapolis, Minn. 8-653-2247
+ POKCAD1           * PKDPDVM/9  4341/VM   NAD  Poughkeepsie, N.Y. 8-253-6398
+ POKCAD2           * POKCAD1/C  4341/VM   NAD  Poughkeepsie, N.Y. 8-253-6398
+ SJEMAS5           * SNJMAS3/S  4341/MVS  GPD  San Jose, Ca.      8-276-6595
+ TOKVMSI2          * FDLVM1/9   3031/VM   AFE  Tokyo, Japan

... snip ...

the following is a list of corporate locations that had one or more new (mainframe) network nodes added during 1983:


Amsterdam, Neth.               Marne LaValle, France
Atlanta, Georgia               Mechanicsburg, Pa.
Austin, Texas                  Melbourne, Australia
Bangkok, Thailand              Menlo Park, Ca.
Barcelona, Spain               Milan, Italy
Bethesda, Md.                  Minneapolis, Minn.
Boca Raton, Florida            Montevideo, Uruguay
Boeblingen, Ger.               New York, N.Y.
Boigny, France                 Newton, Ma.
Bologna, Italy                 Nieder-Roden, Ger.
Bordeaux, France               Novedrate, Italy
Boston, Mass.                  Owego, N.Y.
Boulder, Colorado              Paris, France
Bromont, Canada                Parvis de la Defense, France
Brooklyn, N.Y.                 Pisa, Italy
Burlington, Vermont            Pittsburgh, Pa.
Cambridge, Ma.                 Portsmouth, U.K.
Charlotte, N.C.                Poughkeepsie, NY
Chicago, Illinois              Purchase, N.Y.
Cincinnati, Ohio               Raleigh, N.C.
Cleveland, Ohio                Reykjavik, Iceland
Copenhagen, Denmark            Rio de Janeiro, Brazil
Cosham, U.K.                   Rochester, Minn.
Cranbury, N.J.                 Rochester, N.Y.
Dallas, Texas                  Rome, Italy
Dayton, N.J.                   Sainte-Marie, France
Detroit, Michigan              San Francisco, Ca.
Diegem, Belgium                San Jose, Ca.
Dublin, Ireland                Santa Teresa, Ca.
Eastliegh, U.K.                Seattle, Washington
Ecully, France                 Seoul, Korea
Endicott, N.Y.                 Sindelfingen, Ger.
Essen, Germany                 Singapore
Essonnes, France               St. Louis, Mo.
Fishkill, N.Y.                 Stamford, Conn.
Frankfurt, Ger.                Sterling Forest, NY
Franklin Lakes, NJ             Stockholm, Sweden
Fujisawa, Japan                Stuttgart, Ger.
Gaithersburg, Md.              Sumare, Brazil
Greencastle, Indiana           Sydney, Australia
Greenock, U.K.                 Tampa, Florida
Hannover, Germany              Tokyo, Japan
Havant, U.K.                   Toronto, Canada
Herrenberg, Ger.               Tucson, Arizona
Hursley, U.K.                  Uithoorn, Netherlands
Irving, Texas                  Valencia, Spain
Jakarta, Indonesia             Vancouver, Canada
Johannesburg, South Africa     Vienna, Austria
Kingston, N.Y.                 Vimercate, Italy
Kuala Lumpur, Malaysia         Warwick, U.K.
La Gaude, France               Wayne, Pa.
Lexington, Kentucky            Wellington, New Zealand
Lisboa, Portugal               West Berlin, Ger
Los Angeles, Ca.               Westlake, Ca.
Madrid, Spain                  White Plains, N.Y.
Mahwah, N.J.                   Winchester, U.K.
Mainz, Ger.                    Yasu, Japan
Manassas, Va.                  Yorktown, N.Y.
Manilla                        Zurich, Switzerland

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

Arpa address

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 12:30:36 -0600
eugene@cse.ucsc.edu (Eugene Miya) writes:
Your talking about your perceptions as your then employer was attempting to play catch up in a field of telecommunications. No one doubts of late that IBM had more machines internally. Numbers and tallys of are fine to a point. But it would be interesting to know the numbers of DEC-10s and DEC-20s inside IBM on the VNET. The number of ILLIAC IVs (that would be interesting if it were non-zero), or other Burroughs machines, the number of Sigmas, etc. etc. Just exactly how much how much market analysis was done on these machines. That's heterogeneity.

Induction starts with a null hypothesis. The world knows ARPAnet's was 1969. Somewhere between 1969 and 1983, someone in IBM got a clue. This's a pinching argument.

But it all water under the bridge except for historians unless you are going to claim IBM started networking. I think I can see a factor of why Taylor is the way he is. It's sad that's an aspect of this industry.


re:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address

cpremote was approximately 1970 between machines at the science center. approx. 1971 vnet was used between science center and endicott for distributed development project enhancing cp67 to provide virtual "370" virtual machines (there were some number of new instructions added to 370 architecture that had to be simulated and the hardware virtual memory tables had different definitions).

in mid-70s there was new joint product announcement for vnet and jes2/nje (vnet in addition to its own line drivers had a large collection of line drivers to talk nje).

jes2/nje had a severe problem because jes2 managed network node definitions using a one-byte index of 255 entries (that was already being used to define jes2 psuedo devices, which typically might occupy 60 entires) ... and by the time of the joint vnet/jes2 announcement, the internal network was well passed the limit of total nodes that could be defined in a jes2 system. jes2 nodes on the internal network had to be carefully managed ... also a jes2 feature was that it would discard network traffic where either the origin node or the destination node wasn't in its table definition. a new activity was invented for managing jes2 network definitions ... managing the subset of internal network node definitions that were critical for the users of that system.

sometime after the internal network passed 1000 nodes, jes2 enhanced their networking support to allow for defining up to 999 nodes ... later, after the internal network had passed 2000 nodes, jes2 was enhanced to support definition of 1999 nodes.

as i've frequently posted in the past, the corporate communication group had started sna in the early 70s ... aka system network architecture ... which was basically a large sophisticated terminal controller infrastructure. it scaled up for large corporations and institutions that had tens of thousands of dumb terminals (or things controlled like dumb terminals ... atm cash machines, cable tv settop boxes, etc, later institutions like airline res. system that might have several hundred thousand terminals).

this wasn't "networking" ... it was communication control for large numbers of dumb terminals (despite its label sna). the extensive use of the term "networking" by the communication group ... forced other organizations to start calling their stuff "peer-to-peer networking" to differentiate it from the communication stuff that was called sna.

as in this recent posting, my wife somewhat ran afoul of the communication group in that time-frame ... when she co-authored "peer-to-peer networking" architecture (AWP39) with bert moldow (as a real networking architecture).
http://www.garlic.com/~lynn/2006j.html#31 virtual memory

in the 80s, the communication group assisted in the rapid uptake of PCs in corporate environments with terminal emulation ... dumb corporate terminals, and their millions, could be upgraded to a PC (the price of the dumb corporate terminals and PCs were approx. the same) ... and for a single desktop footprint ... the person got a display/keyboard that provided both access to corporate dataprocessing and some local computing facilities.

in the late 80s, as client/server networking started to emerge ... the communication group attempted to counter with "SAA" ... which attempted to preserve as much as possible of the terminal emulation paradigm as possible.
http://www.garlic.com/~lynn/subnetwork.html#emulation

in that time frame, my wife and I had come up with 3-tier networking architecture and were out pitching it to corporate IT executives and taking some amount of heat from the communication group (which wanted to continue the terminal emulation paradigm and stave off any progression to networking).
http://www.garlic.com/~lynn/subnetwork.html#3tier

I've asserted that one the reasons that the number of nodes on the internet passed the number of nodes on the internal network sometime mid-85 ... was that while the communication group couldn't prevent the internal network ... they were able to do a lot to head-off being able to treat workstations and PCs connected to the internal mainframes as networking nodes (maintain their status as terminal emulation) ... at a time when internet was seeing a big explosion in workstations and PCs as networking nodes.

the following article lists cpremote as completed mid-69.
http://www.research.ibm.com/journal/sj/181/ibmsj1801H.pdf

it was then replaced with scnode ... followed by RSCS which was subsequently announced and released as a product. The article mentions that the internal network grew at a relatively constant rate of one node a week through 1977 and then in 1978 the growth doubled to two nodes a week.

another reference that discusses some of this ... cpremote, rscs, vnet, rscs, etc.
http://www.leeandmelindavarian.com/Melinda/25paper.ps

I don't know the number of DEC machines internally. I've been able to post the information that I have access to. In the past, I've posted the number of vax machines sold
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

and noted that in the late 70s and early 80s ... there were as many or more 43xx machines sold as there were vax machines sold. there was some sort of transition/threshold that happened in this period and you saw corporate orders for several hundred 43xx machines at a time.

I've repeatedly and frequently posted both data that I have as well as other references. To some extent the world knows about arpanet because a lot of people made it their business to publish information about it for one reason or another. During that period, there was little or no public documents about the internal network ... in part because of the communication group's effort to focus customers totally on their SNA activity and terminal communication paradigm. in fact, the communication group strongly objected to vnet being part of the joint jes2/vnet networking announcement in the mid-70s (and had prevented it from being announced earlier).

however, despite all the efforts by the communication group to put a totally different face on "communication", "networking" and products announced by the corporation for customer use ... that doesn't mean that the internal network didn't exist. I conjecture that there are a lot of things that go on within various institutions and govs. ... that may not be public knowledge ... but just because it isn't public knowledge ... doesn't mean that it didn't happen.

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

Arpa address

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 14:35:09 -0600
Anne & Lynn Wheeler writes:
in mid-70s there was new joint product announcement for vnet and jes2/nje (vnet in addition to its own line drivers had a large collection of line drivers to talk nje).

re:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address

some number of homogeneous operations also tend to have lots of stories about scheduled shutdown of the service while all components in the infrastructure are synchronously upgraded ... like the big 1/1/83 conversion for arpanet.
http://www.garlic.com/~lynn/2000e.html#18
http://www.garlic.com/~lynn/2006k.html#3 Arpa address

sna and jes2 folklore has huge number of such stories.

jes2 was particularly senstive to homogeneous operation ... minor jes2 release changes would result in incompatible network communication between otherwise identical jes2 systems. the jes2 homogeneous operation even went so far that relatively minor jes2 release incompatibilities could precipitate the failure of a jes2 operation, including bringing down the related mvs operating system.

this problem became so bad on the internal network that the heterogeneous rscs/vnet support was enlisted to compensate for the homogeneous jes2 operation requirement. not only was a large library of jes2 nje drivers developed for vnet ... vnet was even enhanced to recognize when two different incompatible jes2 systems were attempting to communicate and do the necessary format conversion. this eventually evolved in vnet essentially having a canonical representation of jes2 format and converting to the specific format needed by a directly connected jes2 operation (there is an early infamous story about a jes2 software upgrade on a system in san jose, ca. resulting in MVS system crashes in hursley, UK)

there are a large raft of similar customer stories about large SNA installations ... where large number of different components would have to be upgraded simultaneously ... i.e. shutting down the service until all components have been upgraded ... as infrastructures got larger and larger ... it was becoming less and less possible to contain such a synchronous migration over even an extended weekend.

part of the vnet infrastructure was a kind of gateway mechanism that allowed heterogeneous operation as well as the deployment of incremental upgrades w/o having to syncronize such upgrades across the whole infrastructure.

some misc. RFCs ... from my rfc index.
http://www.garlic.com/~lynn/rfcietff.htm

normally in frame's mode, the rfc summaries appear in the bottom frame. it is possible to "click" on various fields, clicking on ".txt=nnnn" retrieves the actual RFC

http://www.garlic.com/~lynn/rfcidx0.htm#101
101
Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971, Watson R., 1971/02/23 (14pp) (.txt=30343) (Updated by 108)


... lists there being 15 IMPs as of 2/23/71 (although many in purely test operation).

http://www.garlic.com/~lynn/rfcidx2.htm#638
638
IMP/TIP preventive maintenance schedule, McKenzie A., 1974/04/25 (4pp) (.txt=4088) (Obsoletes 633)


... this appears to imply that Tuesday mornings from 7am to 9am are reserved for doing network software maintenance on all IMPs across the whole infrastructure. In addition there is somewhat rolling hardware maintenance schedule for different IMPs. This lists 45 IMPs as of 4/25/74. This RFC and several other RFCs imply that there was synchronized software upgrades of all IMPs across the whole infrastructure (implying a form of network infrastructure homogeneous operation)

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Fri, 19 May 2006 11:13:57 -0600
re:
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!

... by the time ISO had passed OSI as a standard ... you had things like LANs and internetworking ... making OSI obsolete (or at least out-of-date). ISO then compounded the problem by dictating that only OSI conforming protocols, could be standardized.

then in the late 80s, further compounding the problem, you have various govs. and institutions mandating elimination of tcp/ip and the internet ... replacing them with OSI.

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

Arpa address

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 14:58:19 -0600
Anne & Lynn Wheeler writes:
some number of homogeneous operations also tend to have lots of stories about scheduled shutdown of the service while all components in the infrastructure are synchronously upgraded ... like the big 1/1/83 conversion for arpanet.
http://www.garlic.com/~lynn/2006k.html#3 Arpa address


and ...
http://www.garlic.com/~lynn/2000e.html#18

also part of extended post from above (email from month after the 1/1/83 cutover date) ... note the final comment


MSG 0001  02/02/83  23:49:45

To: CSNET mailing list
Subject: CSNET headers, CSNET status

You may have noticed that since ARPANET switched to TCP/IP and the
new version of software on top of it, message headers have become
ridiculously long.  Some of it is because of tracing information
that has been added to facilitate error isolation and "authentication",
and some of it I think is a bug (the relay adds a 'From' and a 'Date'
header although there already are headers with that information in
the message).  This usually doesn't bother people on the ARPANET
because they have smart mail reading programs that understand the
headers and only display the relevant ones.  I have proposed a
mail reader/sender program that understands about ARPANET headers
(RFC822) as a summer project, so maybe we will sometime enjoy the
same priviledge.


The file CSNET STATUS1 on the CSNET disk (see instructions below for how to access it) contains some clarification of the problems that have been experienced with the TCP/IP conversion. Here is a summary: - Nodes that don't yet talk TCP (but the old NCP) can be accessed through the UDel-Relay. So if you think you have problems reaching a node because of this, append @Udel-Relay to the ARPANET address. - You can find out about the status of hosts (e.g., if they run TCP or not) by sending ANY MESSAGE to Status@UDel-Relay (capitalization is NOT significant). - If your messages are undeliverable, you get a notice after two days, and your messages get returned after 4 days. - Avoid using any of the fancy address forms allowed by the new header format (RFC822). - The TCP transition was a lot more trouble than the ARPANET people had anticipated.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The Pankian Metaphor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 15:40:32 -0600
Eric Smith writes:
Why was there only 16MB of virtual address space? I thought the 360/67 hardware supported 32-bit addressing?

360/67 hardware had both 24-bit and 32-bit virtual address. cp67 for virtual machines only provided 24-bit (virtual) address space i.e. there wasn't a 360 hardware definition for 32-bit "real" address ... aka cp67 was using virtual memory hardware to simulate the real hardware definition. in addition, cms was quite constrained by the extensive borrowing of application code, compilers, etc from os/360 (which was built purely for 24-bit addressing).

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

The Pankian Metaphor

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 16:57:30 -0600
Eric Smith writes:
That makes sense.

Did TSS/360 use or allow use of 32-bit addressing?


tss/360 enable 32-bit virtual addressing.

part of the issue in virtual machine operation ... was doing i/o. all the 360 i/o operations were 24bit ... i.e. you couldn't do an i/o operation into an address other than 24bit.

tss/360 provided 32-bit virtual addressing within a "real" 24-bit machine (i.e. all i/o transfers, to/from disk, etc ... all involved 24-bit addressing api). you could operate within a 32-bit virtual address space ... but when you went to actually do something it was restricted to 24bit.

cp67 could provide a virtual machine for tss/360 to run in with 24-bit ... since the "real" machine that tss/360 ran in was 24-bit.

besides cms being constrained by heavy borrowing of software from os/360 world ... its api for moving to/from filesystem was 24bit inherited from the 360 "real" i/o infrastructure.

when i built page-mapped filesystem for cms, i went to a 32bit api (actually slightly more than 32bit address since i used 32bit field to specify 4k page numbers ... so theoritically it was 32bit+12bit ... 44bit api).
http://www.garlic.com/~lynn/submain.html#mmap

however, the rest of cms was heavily 24bit.

in the os/360 world, even after 370-xa and 31bit was introduced ... there was heavy use of dual-mode operation because of the enormous amount of inherited 24-bit software.

general motors research was a big tss/360 32bit user on 360/67 ... they claimed that they got enormous programmer productivity using the tss/360 single level store model (large memory mapped files) in 32bit mode ... with the programmers not having to bother themselves with a lot of file semantics found in many applications.

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

Passwords for bank sites - change or not?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Passwords for bank sites - change or not?
Newsgroups: alt.computer.security
Date: Fri, 19 May 2006 19:24:24 -0600
Jim Watt <jimwatt@aol.no_way> writes:
However, its realistic guess a the number of unique passwords one needs these days to get by. As previously stated the banking systems do not rely on just a password. One of them even pops up an onscreen keyboard to ensure keyloggers are by-passed.

re:
http://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?

very shortly after some vendor announced the onscreen keyboard/pinpad, there was an announcement that a keylogger had been discovered that also logged screen mouse motions

again ... the whole area of pc vulnerabilities has been major motivation behind the EU finread standard
http://www.garlic.com/~lynn/subintegrity.html#finread

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

Value of an old IBM PS/2 CL57 SX Laptop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sat, 20 May 2006 08:41:15 -0600
jmfbahciv writes:
Sigh! If I were a crook, I'd get a job at AmEx or Walmart in their bookkeeping dept. Bide my time. And then run their check number/account data base through for $10/datum. I can imagine emptying the virtual vaults of a single bank. More importantly, I don't even have to be present when my batch job fires up; I could use an /AFTER:1YEAR switch.

with all the stories about data breaches and security breaches ... various studies have continued to indicate that the majority of account/identity fraud involve insiders.

in the early 80s you already having insider fraud countermeasures that required multi-parties for doing sensitive operations. the response then was collusion. you then were starting to have some amount of collusion countermeasures.

the internet brought a lot of focus on outsiders. however, with insiders still being responsible for the majority of fraud, the focus on outsider threats, helps the insider attackers distract from the source of the problem.

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

an old favorite on security proportional to risk (also mentioning insider threat)
http://www.garlic.com/~lynn/2001h.html#61

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Sat, 20 May 2006 09:18:55 -0600
"Wrolf" writes:
Agree with all your points.

TCP is not optimized for transaction type requests, with all the wasted handshaking at the beginning and the end. The alternatives have not been much good, and the current workaround is to keep the TCP connection alive for multiple transactions, thus amortizing the initial and final handshaking over many transactions (HTTP GETs).

However, this inefficiency has not led to an enhanced TCP with data in the initial SYN packet, nor for the reply packet to be the final packet for idempotent operations (GETs of static pages, if you don't get an answer just ask again).

So keeping the connection alive was all that was needed, and TCP was not modified.

As far as the SSL issues, they are independent of TCP.


re:
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!

they aren't totally independent of transaction oriented philosophy.

if you had transaction oriented transport for both HTTP & HTTPS, then you might have a transaction oriented HTTPS, if you had a purely transaction oriented HTTPS, then you would have much less overhead.

in effect, the prevailing change to using HTTPS to encoupass the whole session ... to just the checkout/pay portion ... is sort of treating the checkout portion as a "large" transaction. However, that change violated fundamental corner-stone of the whole HTTPS protection and security scenario.

The point of the HTTPS hand-shaking was to prove that the webserver the user thot it was talking to was the webserver that the user was actually talking to. The security paradigm required that the user/client supply who they thot they were talking to ... and the webserver supply the proof that was who they were. posts about being called in to work with this small client/server startup (who had this technology called SSL) that wanted to do payment transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

The change to the checkout/pay button resulted in the webserver supplying who they were claiming to be ... as well as supply the proof that they were who they were claiming to be. The fundamental step-by-step dependent security process was violated.

so, there was VMTP (rfc 1045) that was transaction oriented and did reliable message in 5 packet exchange. and there was XTP that did reliable message in 3 packet exchange
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
recent post in this thread
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!

the fundamental cornerstone use of HTTPS in e-commerce is

1) to make sure you actually are sending the account number to the entity that you think you are sending it to

2) to prevent evesdropping the account number while the transaction is in-flight.

So the way that HTTPS is commingly used for e-commerce invalidates #1. At it doesn't do anything to protect the account number before it is sent or after it arrives (data-at-rest as opposed to data-in-flight). in the past, there has been a lot of discussion that data breaches of transaction logs harvesting millions of account numbers has always been a much more attractive target than evesdropping the net
http://www.garlic.com/~lynn/subintegrity.html#harvest

the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. part of the early work on the x9.59 financial standard was recognition that the account number was overloaded.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

on one hand, the account number is required to be generally available for a large number of different business processes. on the other hand, it was required to be kept totally confidential and never divulged in any way. these diametrically opposing goals met that you could bury the planet under miles of information hiding cryptography ... and still wouldn't be able to prevent account number leakage.

so x9.59 financial standard defined a light weight payment transaction that required end-to-end authentication (digital signature) and furthermore a business rule that account numbers used in x9.59 transactions were not valid in non-authenticated transactions.

with those two things, account numbers (by themselves) became useless to crooks. you could have enormous data breaches and evesdropping activity and the crooks still wouldn't have harvested sufficient information to perform a fraudulent transaction (the other way of viewing the account number vulnerability is that it is subject to simple replay attacks, the x9.59 standard definition eliminated the replay attack vulnerability). misc. past posts vulnerability, threat, exploits, and/or fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

so from that standpoint ... you could have an x9.59 financial transaction riding XTP transaction transport ... w/o requiring the account number to be hidden.

collected posts mentioning various ssl issues
http://www.garlic.com/~lynn/subpubkey.html#sslcert

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

Value of an old IBM PS/2 CL57 SX Laptop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sat, 20 May 2006 09:40:46 -0600
re:
http://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop

slightly related post mentioning overloaded diametrically opposing account number use requirements ... needing to be readily available for a larger number of different business processes and at the same time needing to be kept confidential and never divulged:
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!

misc. past posts repeating line about burying the planet miles deep in information hiding cryptography
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Sat, 20 May 2006 10:23:59 -0600
Anne & Lynn Wheeler writes:
the fundamental cornerstone use of HTTPS in e-commerce is

1) to make sure you actually are sending the account number to the entity that you think you are sending it to

2) to prevent evesdropping the account number while the transaction is in-flight.


re:
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!

so x9.59, beside meeting the requirement to preserve the integrity of the financial infrastructure for all retail payments, we tried to eliminate the attack scenarios against account numbers and also have an extremely light-weight transaction that could be performed in a single round-trip.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

possibly the prevailing use of HTTPS in the world today is still hiding account numbers in e-commerce transactions. x9.59 eliminates having to hide account numbers as a countermeasure to various kinds of existing fraudulent transactions (minimizes even needing HTTPS or other information hiding technologies for e-commerce operations)

this is a couple of earlier postings that look at various SSL and integrity issues
http://www.garlic.com/~lynn/2006h.html#27 confidence in CA
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA

and suggests a process where the HTTPS objectives for e-commerce (hiding and authentication) could be done in much the same manner that mapping x9.59 to XTP process could be done i.e. transaction oriented encrypting the contents of a XTP payload (or other extremely light-weight oriented operation).
http://www.garlic.com/~lynn/subpubkey.html#certless

it also mentions some of the enormous payload bloating approaches from the mid-90s.

earlier postings in this thread:
http://www.garlic.com/~lynn/2006j.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#11 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Sat, 20 May 2006 12:17:28 -0600
Anne & Lynn Wheeler writes:
it also mentions some of the enormous payload bloating approaches from the mid-90s.

re:
http://www.garlic.com/~lynn/2006k.html#19 Hey! Keep Your Hands Out Of My Abstraction Layer!

starting possibly mid-90s, going forward for a time, appeared to be a period leaning towards extreme extravagance; enormously complex protocols (that few people understood) and humongous payload bloat (in some cases by one hundred times or more), were frequently viewed as being *better*.

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

Sending CONSOLE/SYSLOG To Off-Mainframe Server

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Sending CONSOLE/SYSLOG To Off-Mainframe Server
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 20 May 2006 15:25:44 -0600
Tom Schmidt wrote:
Either way I wouldn't mess with 3270 emulation at this point in SNA's life. Let SNA face its ultimate end with some dignity.

we were periodically constantly fighting with the communications group. the communications group had set up sna as communication control of large number of terminals ... but they included "network" in their label ... which had little or nothing to do with what it was doing.

this somewhat forced other organizations to adapt nomenclature like "peer-to-peer networking" to describe real networking and differentiate it from sna. early in sna lifetime, my wife co-authored peer-to-peer networking AWP39 architecture with Bert Moldow ... which put them at odds with the communication organization.

she then got con'ed into going to POK to be in charge of loosely coupled architecture (clusters by any other name) ... where she created peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

the communication group was constantly trying to carve off as their turf any bits that left the processor complex ... even purely processor-to-processor communication, creating lots of difficulties for my wife. recent comment on one such involving 3088/trotter
http://www.garlic.com/~lynn/2006j.html#31 virtual memory

the communication group did contribute to early uptake of PCs with terminal emulation ... for about the same price as a mainframe terminal, a person could get a single desktop footprint (keyboard and display) that did both mainframe connectivity and local computing.

however, in the late 80s, "peer-to-peer" networking and client/server was emeging for PCs ... and the communication group was attempting to counter it with SAA ... attempting to maintain as much as possible the earlier terminal emulation paradigm
http://www.garlic.com/~lynn/subnetwork.html#emulation

it was in this period that we had created 3-tier architecture and were out pitching it to customer executives
http://www.garlic.com/~lynn/subnetwork.html#3tier

and were taking a lot of heat from the communication group and SAA forces.

during the 80s, the communication/sna group had also done things like non-concurred with the announcement of APPN ... i.e. AWP164 ... recent post mentioning APPN/AWP164 (as well as AWP39):
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe

for a little drift, thread talking about the internal network (going on in the same period as arpanet):
http://www.garlic.com/~lynn/2006j.html#53 Arpa address
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address

Encryption for Powerpoint?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Encryption for Powerpoint?
Newsgroups: sci.crypt
Date: Sat, 20 May 2006 17:20:44 -0600
Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
We are talking about a Powerpoint presentation. No amount of DRM will defeat a camcorder set up in the room.

somewhat after vendor announced a "screen" pin-pad (using mouse clicks) as a countermeasure to keyloggers (somewhat targeted at online banking or financial operations) ... there was some announcement of a keylogger being found that also took screen shots and mouse motions.

there have been stories about people smuggling camcorders into special screenings of new movies and within a very short period ... counterfeit DVDs showing up at various places around the world.

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

Value of an old IBM PS/2 CL57 SX Laptop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sun, 21 May 2006 08:54:28 -0600
jmfbahciv writes:
This is an impossibility. This is why I believe that this has to remain a human work point, and not automated.

re:
http://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop

so we annalysed this when we started work on x9.59 in the mid-90s ... and in the x9.59 financial standard, changed the paradigm.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

a crook with just the knowledge of an account number (used in x9.59 transactions) can no longer perform a fraudulent transaction.

the role of account number as some sort of authentication shared-secret is eliminated,
http://www.garlic.com/~lynn/subintegrity.html#secret

overloading of the account number is eliminated and account number is then used purely for business process operations. the millions of places that account numbers are needed and readily available, no longer represent sensitive operations that are also responsible for never divulging the account number.
http://www.garlic.com/~lynn/subintegrity.html#harvest

this is also the point of my old security proportional to risk posting
http://www.garlic.com/~lynn/2001h.html#61

... the business value of an account number (in all these processes) may reprensent only a few dollars to a merchant ... but to the crook (either insider or outsider) represents potential value equivalent to the account credit limit. no only is their the impossibility of simultaneously making the account number generally available for the myriad of business process and at the same time keeping the account number confidential and never divulging it ... but there is a significant mismatch between the value of the account number to the "defenders" and the value of the account number to the "attackers" (and, in fact, studies find something like 70 percent of identity and account theft incidents involve insiders).

for a little drift, the transaction card cost for some merchants, can even be larger than the profit from the transaction, i.e. the value that the transaction represents to the merchant:

http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems

posted in the above:
http://www.csnews.com/csn/search/article_display.jsp?vnu_content_id=1002425619

from above
Fed up with out-of-control interchange fees, retailers are fighting back with concerted legal and educational tactics -- and, in some cases, proactive offensives of their own.


... snip ...


http://www.epaynews.com/newsletter/epaynews322.html
from above:
Convenience store operators can make more money on a 12-ounce cup of coffee than they can on a 12-gallon tank of gas. Credit card fees now account for almost half of a typical store's expenses - more than labor.

... snip ...

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

Value of an old IBM PS/2 CL57 SX Laptop

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sun, 21 May 2006 09:00:59 -0600
jmfbahciv writes:
Our Congress critters at work again. They've forgotten the mess made with S&Ls.

this posting goes into some detail regarding the savings and load situation
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Managment and Information security

basically, the reserve requirement had been something like 8percent, the gov S&L gov. board cut this in half to something like 4percent ... and all of a sudden, approx. 4percent of total S&L deposits were available for investment. there was no immediate vehicle to place such a large influx of capital ... and so some innovative people on wall street packaged up some products that could absorb the sudden, large influx of capital.

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

Can anythink kill x86-64?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can anythink kill x86-64?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 21 May 2006 12:35:00 -0600
Bernd Paysan writes:
There are also the smartphones. These become more and more general purpose computers, because they need to play TV, browse the web, and allow you to read and write e-mail.

Remember: What "killed" the IBM mainframe was the typewriter department of IBM that sold IBM PCs rather than typewriters. So the death of x86-64 is smaller boxes doing the work that's actually needed, with less effort.


they sold IBM PCs in lieu of mainframe terminals (at about the same price) ... as part of this, the communication group acquired a big install base of terminal emulation products
http://www.garlic.com/~lynn/subnetwork.html#emulation

the millions of installed mainframe terminals could be upgraded with a pc that cost about the same as the terminal ... and with a single desktop footprint for display and keyboard ... provide both online mainframe connectivity as well as some local computing capability.

with the spread of (peer-to-peer) networking and client/server, the comminication group responded with all sorts of tactics ... including SAA (late 80s) in an attempt to contain the migration away from terminal emulation.

there was even an infamous internal world-wide networking (actually communication) conference ... where a senior person from the disk division gave a talk about how the communication group was going to be responsible for the demise of the mainframe disk division. the disk division had been coming up with all sorts of innovative client/server solutions that provided high-speed/high-thruput access to data on mainframe disk farms ... and they were constantly being blocked by the communication group defending their install base of terminal emulation products.

we had come up with 3-tier archtecture in the late 80s and were out pitching it to customer executives ...
http://www.garlic.com/~lynn/subnetwork.html#3tier

and taking a lot of heat from the communication and SAA forces.

a couple recent posts on the subject:
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server

at the other end ... starting in the early to mid-90s ... we started running into problems with the smartcard forces. in the early 90s, we had done some consulting with gov. labs attempting to move some gov. smartcard technology out into the commercial market. what we saw was technology that had evolved in the 70s & 80s to address a low-end portable computing market niche. However, there wasn't portable input/output technology in this market niche ... so you had a lot of standardization work done for stationary input/output stations that could interoperate with the smartcard products. however, what we saw going into the mid-90s was the emergance of the portable input/output technology in the form of PDAs and cellphones ... i.e. all other things being equal would you prefer to have to find a stationary input/output station to make use of your portable computing device ... or would you prefer a portable computing device that had portable input/output capability?

there had been billions of dollars poured into the smartcard technology ... and various parties were out looking at some means of recoverying at least some of the investment ... even if it was only five cents on the dollar. however, some of the attempts at specific market niches ... like financial transactions ... are also falling to smartphone based payment operations.

in any case, when we started looking at various chip technologies for "secure" operations in the mid-90s ... we assumed from the start that it would need to be form factor agnostic.

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

Value of an old IBM PS/2 CL57 SX Laptop

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sun, 21 May 2006 14:30:26 -0600
jmfbahciv writes:
I've thought about this. It will only work well when all people start to do 'credit card' transactions. I estimate it's now about 60%, perhaps more. I will never, ever have a debit card account as the rules stand now.

a couple related articles
ATM/Debit Cards: What consumers need to know about greater fraud risk, card blocking, and debit card fees.
http://www.pirg.org/consumer/banks/debit/debitcards1.htm


from above:
Worse, unlike a credit card, under the law, your debit card liability could be as much as $500, if you notify the bank more than 48 hours after you learn of the problem or even up to all the money in your checking account plus your maximum overdraft line of credit if you fail to notify the bank within 60 days

... snip ...
ATTEMPTED CHECK FRAUD INCREASES TO $5.5 BILLION ACCORDING TO ABA SURVEY
http://www.aba.com/Press+Room/112204CHECKFRAUD.htm


a couple items from above:
• Reveal checking account information only to businesses you know to be reputable.
• Shred or tear-up canceled checks and deposit slips before discarding them.


... snip ...
Use a Pen, Not Your Pin?
http://biz.yahoo.com/kiplinger/060519/pf_v056_n009_u124_01001_id.html?.v=1

A Corporate Guide to Card Payments and the Role of Interchange
http://www.afponline.org/pub/store/pubs/ecgpay.html

Merchants' lawsuit could end credit-card rewards
http://www.mysanantonio.com/business/consumernews/stories/MYSA051906.01P.gas_card_end.1f6ef7b3.html


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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Sun, 21 May 2006 18:22:08 -0600
David Scheidt writes:
I think it was inevitable that computing would progress from batch to interactive use. The limits of what you can do with batch processing were obvious. Once the underlying tech existed, it was just a matter of time before someone figured out how to bend it the way they wanted it. It might have been a year later, or five, but I doubt much more than that.

a lot of the batch stuff was dataprocessing w/o having a human to control it ..... besides running payroll and various other operations, many of these platforms for used for various other kinds of controlled operations ... like running hundreds of thousand of ATM machines ... or webservers.

one might even claim that it somewhat went the other way. a lot of early computers had the programmer right there controlling the machine (interactive).

"batch" was sort of extending the use of such machines via punch cards ... i.e. allowing people to use the machines with punch card technology w/o actually having to be present when the punch cards were processed.

when i was an undergraduate, i would to get the machine room from 8am sat. to 8am monday. I had a 360/30 as an interactive personal computer on the weekends ... it was mostly what people call a "batch" operating system ... but it did have a 1052-7 keyboard that i had exclusive use of.

During this period, time-sharing was somewhat synonomous with interactive ... because the machines were normally too expensive to dedicate for one person's exclusive interactive use (batch could also be considered motivated by the same economics, attempting to improve the utilization of an expensive resource)

small extract from Melinda's Virtual Machine history
http://www.leeandmelindavarian.com/Melinda/25paper.pdf
Papers discussing the idea of a time-sharing system began being published about 1959. There followed a period of experimentation at MIT and other institutions. An early version of CTSS was demonstrated on an IBM 709 at MIT in November, 1961. From that beginning, CTSS evolved rapidly over the next several years and taught the world how to do time-sharing.[5]. CTSS was developed on a series of IBM processors. In the 1950s, IBM's president, T.J. Watson, Jr., had very shrewdly given MIT an IBM 704 for use by MIT and other New England schools.[6] Then, each time IBM built a newer, bigger processor, it upgraded the system at MIT.[7] The 704 was followed by a 709, then by a 7090, and finally by a 7094. IBM also gave MIT the services of some highly skilled Systems Engineers and Customer Engineers, who formed its MIT Liaison Office, which was housed at the MIT Computation Center.

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

[5] From the preface to the ''candy-striped manual'' (F.J. Corbato, M.M. Daggett, R.C. Daley, R.J. Creasy, J.D. Hellwig, R.H. Orenstein, and L.K. Korn, The Compatible Time-Sharing System: A Programmer's Guide, The MIT Press, Cambridge, Mass., 1963):

The only other general purpose time-sharing system known to be operating presently, that of the Bolt, Beranek and Newman Corporation for the PDP-1 computer, was recently described by Professor John McCarthy at the 1963 Spring Joint Computer Conference. Other time-sharing developments are being made at the Carnegie Institute of Technology with a G20 computer, at the University of California at Berkeley with a 7090, at the Rand Corporation with Johnniac, and at MIT (by Professor Dennis) with a PDP-1. Several systems resemble our own in their logical organization; they include the independently developed BBN system for the PDP-1, the recently initiated work at IBM (by A. Kinslow) on the 7090 computer, and the plans of the System Development Corporation with the Q32 computer.


... snip ...

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

Hashes and Passwords

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hashes and Passwords
Newsgroups: alt.computer.security,comp.security,comp.security.misc
Date: Mon, 22 May 2006 06:37:47 -0600
"Dr Socrates" writes:
Instead of the password being sent in the clear, it would be better to send a hash of the password. If the hash is obtained by a malicious node, it is not going to be very useful since it is not the actual password.

the issue is evesdropping static data transmitted and using it for replay attack.

regardless of what it is called, if it is the same data (static) sent each time ... and is compared against something; then it can be evesdropped and replayed. whatever it is called being transmitted, if it is always the same, then it can be evesdropped and replayed.

for a little drift, here is discussion of one-time-password hash scheme ... based on hash being a one-way function, and the use of hash iterations that decrements on each use. the server has to remember the previous hash and the current hash iteration count . the server sends the client one less than the current hash iteration count. the client then does hash iterations for the indicated count and transmits that value. the server hashes the received value and compares it with the saved value. if correct, the server decrements the count by one and saves the most recently transmitted value.

the issue here is that the same value/hash is not transmitted each time ... so it supposedly is not subject to replay attack (and since hash is one-way function, simple evesdropping can't predict the next value.

however, the original claims were that the transmissions did not have to hidden/encrypted (countermeasure to evesdropping) and/or require the client to carry with them anything; supposedly usable in public environment. it supposedly then is also immune to man-in-the-middle attacks.

an attack is a man-in-the-middle substituting a much smaller iteration count
http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?

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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 08:08:37 -0600
Morten Reistad writes:
The PDPs were leaders, but they were not alone. They were perhaps three years ahead of the curve from all the others in 1968.

CTSS/ITS/Multics were starting a bandwagon around 1971, and microprocessors were starting to be available around 1976. If it wasn't unix, then some other heir would have sprung up. The period 1969-1974 was also catch-up time for all the others.

Without the minis the mainframes may have lasted another 2-3 years, and the transition to microprocessors would have been a lot more brutal. Altos had multiprocessor solutions for MP/M in 1982, and they were able to take at least as much load as the minis.

CP/M and MP/M show a pretty direct heritage from Tops10; msdos has more of a generic feel.

In retrospect we probably would have had better systems today without the extended mini period, called the "superminis" at the time.


in late 68, university started a project to clone an ibm mainframe controller ... reverse engineering the mainframe channel interface and building a channel interface board for interdata/3 ... and programming the interdata/3 to emulate the mainframe controller.
http://www.garlic.com/~lynn/subtopic.html#360pcm

Interdata was eventually bought by Perkin/Elmer. In the late 90s, I ran into somebody at RSA conference in San Franciso, who mentioned that he made a really good living in the early 80s selling the boxes to NASA (and claimed that the mainframe channel interface board looked like it had been designed in the 60s and never updated). In the same time-frame I visited a major credit-card "acquiring" datacenter (i.e. million or so of those merchant point-of-sale credit card terminals connect into) ... where the incoming lines were being handled by Perkin/Elmer ("interdata") boxes.

in june 68, a commercial company was formed to offer commerical timesharing based on cp67 platform
http://www.garlic.com/~lynn/submain.html#timeshare

... technology based on virtual machine work at the science center on the 4th flr of 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

... multics was going on 5th flr of 545 tech sq.

fall of 68, a second commercial company was formed to offer commercial timesharing based on cp67 platform.

start of 1969, boeing formed BCS (boeing computer services) with the objective of moving all boeing data processing into BCS. During spring break 69, I was con'ed into teaching a one week computer class to the BCS technical staff. Then that summer they con'ed me into taking a job as BCS management (i got badge that got me into the management parking late at Boeing hdqtrs across from Boeing field). core of BCS datacenter at corporate hdqtrs was cp67/cms system.

later in the early 70s, other companies like tymshare was using it (or its follow-on vm370) to offer commercial time-sharing services.

here is reference to Gary Kildell using cp67/cms at NPG in '72
http://www.garlic.com/~lynn/2004e.html#38

various other time-sharing and cp67 history
http://www.leeandmelindavarian.com/Melinda/25paper.ps

old post given super & superminis ... including numbers of superminis as of 88
http://www.garlic.com/~lynn/2001b.html#56

old past given some overview of supercomputers, superminis, etc in the late 80s and early 90s
http://www.garlic.com/~lynn/2001n.html#70

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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 08:21:17 -0600
Morten Reistad writes:
Both CTSS and Multics were decidedly ahead of their times. They had per-user costs that were astronomical. ITS and unix were "responses from the real world". It took until the eighties before conversational systems were deployable in large organisations.

re:
http://www.garlic.com/~lynn/2006k.html#27 PDP-1
http://www.garlic.com/~lynn/2006k.html#29 PDP-1

early history of CTSS and some split with project going to Multics on 5th floor 545tech sq ... and others going to science center on 4th floor 545tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

Melinda history covers a lot of detail of that period.
http://www.leeandmelindavarian.com/Melinda/25paper.ps

cp40 was spawned and then morphed into cp67 when it was ported to 360/67 in 1967. cp67 was cost effective enuf that two commercial companies were created in 1968 to offer commercial cp67 time-sharing services. boeing offered internally as part of the formation of bcs ... and then cp67 (and change over to vm370) was used as basis of lot of BCS outside consulting business in the 70s and 80s.

there were fairly large number of cp67 installations and even larger number of installations of the cp67 followon, vm370.

one of the people at the science center that was involved using cms\apl (and happened to be son of one of the people credited with discoverying DNA) left the science center in the mid-70s and joined BCS consulting service. He once commented that one of his consulting projects at BCS was using apl\cms (followon to cms\apl) to do the financial modeling for a contract with USPS justifying postage stamp price increase.

a lot of the "personal computing" during the 70s were cp67/cms (and then vm370/cms) based.

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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 08:52:08 -0600
Morten Reistad writes:
Both CTSS and Multics were decidedly ahead of their times. They had per-user costs that were astronomical. ITS and unix were "responses from the real world". It took until the eighties before conversational systems were deployable in large organisations.

re:
http://www.garlic.com/~lynn/2006k.html#27 PDP-1
http://www.garlic.com/~lynn/2006k.html#29 PDP-1
http://www.garlic.com/~lynn/2006k.html#30 PDP-1

oh and a large part of internal corporate computing was cp67/cms and then vm370/cms based ... even development for some of the more familiar batch, non-conversational systems; and of course it was also the platform that provided the basis for the internal network in the 70s.

some recent posts:
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006k.html#12 Arpa address

for some slight drift mentioned in the above ... number of vax shipments and 43xx shipping as many or more.
http://www.garlic.com/~lynn/2002f.html#0

from above:
NO. OF VAX YEAR US NON-US TOTAL MODELS SHIPPED --------- --------- --------- --------- -------------- 1978 312 78 390 1 1979 627 313 940 1 1980 1,512 1,038 2,550 2 1981 1,979 1,726 3,705 2 1982 4,129 2,794 6,923 4 1983 6,178 4,384 10,562 5 1984 11,703 8,227 19,930 7 1985 17,600 7,300 24,900 8 1986 19,190 12,840 32,030 12 1987 21,780 15,485 37,265 12 -------- -------- -------- TOTAL 85,010 54,185 139,195

... snip ...

see the complete posting (including by model) at the referenced URL ... in the later years, much of the growth in vax shipments were due to micro-vax.

i mentioned that in this time-frame there had been some transition/threshold and you started see 43xx orders of multi-hundred machines at a time (in the late 70s and early 80s). one example in 1981 was a chip manufacture that ordered nearly 1000 4341s in a single order (although orders for 200-500 4341s at a time were more common).

here is old post about air force data center that had a multics installation and in 1979 were looking at upgrading.
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

and between spring of 1979 and fall of 1979 changed a twenty 4341 order to 210 4341s.

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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 09:35:12 -0600
Morten Reistad writes:
Both CTSS and Multics were decidedly ahead of their times. They had per-user costs that were astronomical. ITS and unix were "responses from the real world". It took until the eighties before conversational systems were deployable in large organisations.

oh, and here is multics history site
http://www.multicians.org/history.html

mentions commercial announcement 1/1973

multics air force data center, first install 11/73 ... grew to six systems
http://www.multicians.org/site-afdsc.html

reference to afdc ordering 210 4341s in 1979
http://www.garlic.com/~lynn/2006k.html#31 PDP-1
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

as an aside, this was nearly as many machines as there were total arpanet nodes on 1/1/83 ... slight drift:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address

Melinda's history of work at the science center on 4th flr 545 tech sq. ... also mentions some of the CTSS activity and Multics (on 5th flr, 545 tech sq)
http://www.leeandmelindavarian.com/Melinda/25paper.ps

reference to cp67/cms
http://www.multicians.org/thvv/360-67.html

the above also mentions the two companies formed in 1968 to offer cp67/cms commercial time-sharing services
http://www.garlic.com/~lynn/2006k.html#30 PDP-1
http://www.garlic.com/~lynn/submain.html#timeshare

multics site home page
http://www.multicians.org/multics.html

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

Password Complexity

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Password Complexity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 22 May 2006 09:59:02 -0600
Tom Marchant wrote:
Ok, Ted, I'll bite again. As a matter of fact, some people DO embezzle.

the long held lore is that the majority of fraud involves insiders. there have been some surveys published in the last couple years that indicates that things haven't changed a lot in the internet era ... that something like 70percent of identity/account theft has involved insiders.

in fact, there is some conjecture that much of the preoccupation on the internet and outsider attacks is benefit to the insiders responsible for the majority of fraud.

at least by the early 80s, you were starting to see sensitive processes requiring multi-person participation. the crooks responded with collusion. you then started to see countermeasures for dealing with multi-party collusion.

currently there still seems to be significant focus on outsider threats and attacks, even tho all the indicators still maintain that the major threats still are from insiders. for example, some number of the auditing organizations have been participating in establishing "PEN-test" standards (i.e. penetration testing as countermeasure to outsider attacks).

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 10:59:49 -0600
eugene@cse.ucsc.edu (Eugene Miya) writes:
I am amused that Lynn has not popped in to push TSO.

not TSO ... but cp67/cms :-)
http://www.garlic.com/~lynn/2006k.html#30
http://www.garlic.com/~lynn/2006k.html#31
http://www.garlic.com/~lynn/2006k.html#33

approx. 1974, cern presented a report at SHARE comparing CMS and TSO. internally, the report got classified IBM CONFIDENTIAL RESTRICTED (available on a need to know only basis) .... in part, they were trying to minimize contamination of the carefully indoctrinated sales and marketing people. this was somewhat difficult since even the major online, interactive service supporting sales, marketing, and field people was cp67/cms (subsequently upgraded to vm370/cms) based ... called HONE
http://www.garlic.com/~lynn/subtopic.html#hone

however, most of the applications were (CMS) APL based and the service was fairly carefully wrapped so not many sales/marketing/field people realized that it was cms.

I got my first trip out of the country in the early 70s, when EMEA hdqtrs moved from the US to la Defense outside of Paris ... and I was called in to handle part of the new datacenter install. One of the issues that I had at the time ... was figuring out the telecommunication connection so I could read my email back in the states (people take for granted being able to get to their email almost anywhere in the world ... but it was a little more difficult nearly 35 years ago)

a few past postings mentioning the cern cms/tso bakeoff
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2005s.html#26 IEH/IEB/... names?
http://www.garlic.com/~lynn/2006d.html#35 Fw: Tax chooses dead language - Austalia
http://www.garlic.com/~lynn/2006d.html#38 Fw: Tax chooses dead language - Austalia

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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 12:07:06 -0600
Anne & Lynn Wheeler writes:
in june 68, a commercial company was formed to offer commerical timesharing based on cp67 platform
http://www.garlic.com/~lynn/submain.html#timeshare


re:
http://www.garlic.com/~lynn/2006k.html#29 PDP-1

the first week in june '68, ibm hosted a one week class in hollywood ... classes were at the ibm site on wilshire ... and everybody stayed at the beverely hills hotel. I was undergraduate and the univ. sent me so i thot it was a lot of fun.

monday morning, ibm asked me if i would teach some of the cp internals. it turned out that the lead cp kernel developer and the person that was to teach cp internals had given notice the friday before that he was leaving to help form this new cp67 time-sharing service bureau company.

over the years they heavily extended their version of cp67 and called it vp/css.

for even more drift ...

ramis from Mathematica Products Group in Princeton, New Jersey offered exclusive on vp/css in 1969
http://www.decosta.com/Nomad/tales/history.html

ncss then did their own called "nomad" and the Mathematica Products Group released "focus"

an unofficial nomad home page:
http://www.decosta.com/Nomad/

later there was a 370 clone vendor, two-pi. ncss branded and sold 120 or so two-pi machines with their branded version of cp67/cms (and two-pi sold another 100 or so)
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone

i.e. ncss sold more of its own re-branded two-pi machines with its own branded version of cp67/cms than the total number multics systems.

two-pi was acquired in 1981 by four-phase.

for other drift ... in the 70s, the original relational/sql was all done on vm370 base on sjr .... called system/r
http://www.garlic.com/~lynn/submain.html#systemr

some past postings mentioning nomad, ramis, focus
http://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2003d.html#15 CA-RAMIS
http://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
http://www.garlic.com/~lynn/2003m.html#33 MAD Programming Language
http://www.garlic.com/~lynn/2003n.html#12 Dreaming About Redesigning SQL
http://www.garlic.com/~lynn/2003n.html#15 Dreaming About Redesigning SQL
http://www.garlic.com/~lynn/2004e.html#15 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
http://www.garlic.com/~lynn/2004j.html#52 Losing colonies
http://www.garlic.com/~lynn/2004l.html#44 Shipwrecks

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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 13:55:09 -0600
Anne & Lynn Wheeler writes:
the first week in june '68, ibm hosted a one week class in hollywood ... classes were at the ibm site on wilshire ... and everybody stayed at the beverely hills hotel. I was undergraduate and the univ. sent me so i thot it was a lot of fun.

monday morning, ibm asked me if i would teach some of the cp internals. it turned out that the lead cp kernel developer and the person that was to teach cp internals had given notice the friday before that he was leaving to help form this new cp67 time-sharing service bureau company.


re:
http://www.garlic.com/~lynn/2006k.html#35 PDP-1

some more history of ncss and time-sharing
http://corphist.computerhistory.org/corphist/?s=select&cid=4
http://corphist.computerhistory.org/corphist/?s=themes&id=32
http://www.computerhistory.org/corphist/view.php?s=stories&id=162

... from above
Dick wrote the file system for the disk, and I coded the terminal handling for the 930 (TTY and IBM1050,) together with the drivers for the communications pipe between the 930 and the 9300. Bob wrote the 9300's dispatcher. By '67, I had a small group of programers working for me on what, by then, was a running system, with 16 simultaneous users plus a batch stream. PE loved it. (Around the same time, some folks at Berkeley were playing with an SDS940. My team was by then about 5 people, including May Guimond and Nick Pisarro, Jr - though Nick was still finishing up at RPI. I was the hiring manager for Bob and his team, by then.

Our IBM salesman was Dick Glazer. He'd been following both our work and that of the Cambridge CP67/CMS team at IBM, and when we started looking at the follow-on machine to the 9300 (SDS had come out with its Sigma line,) he had us (me, Bob, and Dick Orenstein) run up to Cambridge to see CP/CMS. We fell in love. We met Dick Bayles and Mike Field (they showed us what they had) and we pulled them aside to tell them that we were going to make their toy into something spectacular. They hardly believed us.


... snip ...

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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 14:27:57 -0600
Anne & Lynn Wheeler writes:
later in the early 70s, other companies like tymshare was using it (or its follow-on vm370) to offer commercial time-sharing services.

re:
http://www.garlic.com/~lynn/2006k.html#29 PDP-1

from keykos history, here is account of Tymshare offering vm370 based timesharing starting in the early 70s
http://www.cap-lore.com/CapTheory/KK/History.html

from above:
About that time Tymshare had become profitable and we could look beyond the current crisis. Three of us, Dale Jordan, Bill Weiher, and myself began a series of Thursday afternoon discussions on how to provide such a platform. Capabilities were known to each of us but none of us assumed that only they held the solution. After a number of these Thursday meetings the design proposals began to take on a pure capability flavor — no other architectures seemed suitable.

Dale Jordan wrote a paper outlining the problem and hinted at the solutions. Some time had passed when IBM announced a version of the 370 with demand paging. We studied that architecture and deemed it suitable for out plans. The micro processor was still very micro and still years from having the oomph to sport a powerful OS of any variety, let alone oomph to solve our customers problems. Also IBM offered VM/370 somewhat like their previous CP-67 which provided a virtual machine that provided multiple images of a real machine in a decent timesharing environment. At the time Tymshare was providing timesharing services on the SDS 940 and also on DEC's PDP-10. It seemed clear that a number of customers wanted to use 370 computing remotely. Relatively few companies provided internal interactive access to their main frames. The computing centers of some companies did but were trusted less than a commercial third party such as Tymshare. Tymshare adapted VM/370 to Tymnet and developed a good business selling 370 cycles.


... snip ...

tymshare went on to develop capability-based system under vm370 for 370 called gnosis. when tymshare was acquired by m/d in the mid-80s, some number of things were spun off ... tymnet eventually going to B/T and gnosis was spun off as Keykos. minor trivia, as part of spinning of gnosis (as Keykos), i was brought in to audit gnosis (I still have paper manuals).

also note the ncss, ramis, nomad, focus, connection:
http://www.garlic.com/~lynn/2006k.html#35 PDP-1
and
http://www.decosta.com/Nomad/tales/history.html

from above:
In 1973, NCSS decided to fund the development of an alternative product, which in October of 1975 was released under the name NOMAD. That same month, Gerry Cohen left Mathematica and released a product called FOCUS, which he made available on Tymshare Inc's competing time-sharing system, with the promise to RAMIS users that their applications could run un-modified, and at a significant discount over NCSS' charges for RAMIS applications.

... snip ...

Norm's website
http://www.cap-lore.com/

Eros was subsequently spawned based on the keykos work
http://www.eros-os.org/

which has since morphed into
http://www.capros.org/
and
http://www.coyotos.org/

misc. past posts mentioning gnosis
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
http://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#43 Secure design
http://www.garlic.com/~lynn/2005d.html#50 Secure design
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities
http://www.garlic.com/~lynn/2005s.html#12 Flat Query

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

PDP-1

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 16:28:13 -0600
Peter Flass writes:
Seriously I think we're worse off with the decline of mainframes, not better. As usual in the industry history is repeating itself, with net-based apps taking the place of timesharing. I think the current pecee model where everyone has to be his or her own security expert, network admin, CE, sysadmin, etc. is pretty much a failure. If we'd had broadband internet sooner, we'd probably be running host-based X applications and our pecees would be glorified X-servers.

or if the communications group and SAA forces had their way, still stuck on terminal emulation.
http://www.garlic.com/~lynn/subnetwork.html#emulation

for a little drift from financial crypt blog (and issues where everybody has to be their own sysadmin and do their own maint. ... there is some analogy from the days when owning a automobile required you to be an expert mechanic or employ a driver that was one):

IT IS NO LONGER ACCEPTABLE TO BE COMPLEX
https://www.financialcryptography.com/mt/archives/000730.html

and a recent comment/observation about enormously complex protocols and humongous payload bloat from the mid-90s
http://www.garlic.com/~lynn/2006k.html#20 Hey! Keep Your Hands Out Of My Abstraction Layer!

in that time frame i took some heat for advocating KISS
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss3 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
http://www.garlic.com/~lynn/aadsm3.htm#kiss10 KISS for PKIX. (authentication/authorization seperation)
http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE

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

PDP-1

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 18:01:27 -0600
Anne & Lynn Wheeler writes:
some more history of ncss and time-sharing
http://www.computerhistory.org/corphist/view.php?s=stories&id=162


re:
http://www.garlic.com/~lynn/2006k.html#36 PDP-1

the computer history site has a lot more pages devoted to NCSS (and Tymshare, as well as number of other companies)

list of companies with histories
http://corphist.computerhistory.org/corphist/?cid=

History summary page for NCSS:
http://www.computerhistory.org/corphist/view.php?s=select&cid=4

there are tabs on each corporate history summary page for more detailed information about the corporation

History summary page for Tymshare
http://www.computerhistory.org/corphist/view.php?s=select&cid=1

History summary page for GEIS (general electric information services)
http://www.computerhistory.org/corphist/view.php?s=select&cid=5

under (GEIS) documents, there is PDF file that is a scan of NYT 2/27/69 article titled "Computer Time Sharing Grows Up".
http://www.computerhistory.org/corphist/documents/doc-43de674ca84cf.pdf

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

Arpa address

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 19:18:14 -0600
Anne & Lynn Wheeler writes:
The transition requires a major change in each of the more than 250 hosts on the ARPANET; as might be expected, not all hosts will be ready on 1 January 1983. For CSNET, this means that disruption of mail communication will likely result between Phonenet users and some ARPANET users. Mail to/from some ARPANET hosts may be delayed; some host mail service may be unreliable; some hosts may be completely unreachable. Furthermore, for some ARPANET hosts this disruption may last a long time, until their TCP-IP implementations are up and working smoothly. While we cannot control the actions of ARPANET hosts, please let us know if we can assist with problems, particularly by clearing up any confusion. As always, we are or (617)497-2777.

re:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address

above was an extract from a CSNET memo dated 31Dec82 discussing the impedding change-over to internetworking protocols on 1jan83.

note that this refers to ARPANET having 250 hosts at the time. There must have been extremely explosive growth between Jul80 and Jan83 ... since the following ARPANET newsletter article was only projecting to have 100 nodes by 1983 ... OR ... there was possibly 2-3 HOSTS for every IMPs/NODE (i.e. multiple hosts connecting to each ARPANET IMP node?).

ARPANET newsletter
ftp://ftp.rfc-editor.org/in-notes/museum/ARPANET_News.mail

from above:


NEWS-1                                                   DCA Code 531
1 July 1980                                           (DCACODE535@ISI)
                                                        (202) 692-6175

                          ARPANET NEWSLETTER

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

Over the past eleven years, the ARPANET has grown considerably and has
become the major U. S. Government research and development
communications network.  The ARPANET liaisons have made significant
contributions to the network's success.  Your efforts are voluntary,
but are critical to successful operation of each Host, IMP, and TIP.
Your continued support of the ARPANET is greatly appreciated and will
facilitate continued smooth ARPANET operation.

To aid you in performance of your duties, DCA will attempt to provide
you with the latest information in network improvements.  This
information is grouped into two major areas: management and technical
improvements.  However, a brief discussion of where we are going with
the ARPANET is in order.

The ARPANET is still a rapidly growing network.  It provides a service
which is both cost and operationally effective.  We predict the
ARPANET will grow to approximately 100 nodes by 1983, when we
will begin transferring some of the subscribers to DOD's AUTODIN II
network.

... snip ...

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

PDP-1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 20:35:41 -0600
tss/360 was the original "designated" operating system for the 360/67. it was never very succesful. in anticipation of virtual memory, the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

built cp-40 for a custom modified 360/40. In 1967, it was moved to a 360/67 and renamed cp/67. more reference to cp-40 project in Melinda's history paper
http://www.leeandmelindavarian.com/Melinda/25paper.ps

a number of univ. had ordered 360/67s in anticipation of tss/360. with the dismal showing of tss/360 some number of 360/67 customers took to installing cp67/cms. others just used their machine in 360/65 mode (w/o virtual memory) using (batch) os/360.

UofMich ... built their own virtual memory system, interactive system for the 360/67 named MTS. Some history (and lots of pictures) here
http://www.eecis.udel.edu/~mills/gallery/gallery8.html

one could quibble with the claim above ... about being the first operational virtual memory operating system in the world ... along with Multics at MIT ... several references to Multics history site:
http://www.garlic.com/~lynn/2006k.html#32 PDP-1

this describes a project at UofMich to build their own communication controller using a PDP8 ....
http://www.eecis.udel.edu/~mills/gallery/gallery7.html

similar to the project I was involved at as an undergraduate that used an Interdata/3
http://www.garlic.com/~lynn/2006k.html#29 PDP-1
http://www.garlic.com/~lynn/subtopic.html#360pcm

another MTS reference site:
http://www.clock.org/~jss/work/mts/overview.html

for other folklore, the science center had installed a copy of cp67 out at lincoln labs in 1967 (and then the came out to the univ. I was at, and installed cp67 the last week in jan68).

lincoln labs had written a very simple multitasking system for the 360 called LLMPS (lincoln labs multiprogramming system). The folklore was that the people at UofMich scaffolding building MTS using LLMPS.

misc. past posts mentioning LLMPS
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000.html#89 Ux's good points.
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#45 Valid reference on lunar mission data being unreadable?
http://www.garlic.com/~lynn/2001n.html#89 TSS/360
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
http://www.garlic.com/~lynn/2004d.html#31 someone looking to donate IBM magazines and stuff
http://www.garlic.com/~lynn/2004l.html#16 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
http://www.garlic.com/~lynn/2005g.html#56 Software for IBM 360/30

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

Arpa address

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Tue, 23 May 2006 09:36:00 -0600
"Lars Poulsen (impulse news)" writes:
Most IMPs had at least two hosts: A mainframe (PDP-10 class time- sharing system, or IBM-360 class mainframe, typically) and a TAC - Terminal Access Controller (later we would call this a terminal server) which was the same kind of mini as the IMP but with TTY port cards, typically with modems hanging off them.

re:
http://www.garlic.com/~lynn/2006k.html#40 Arpa address

so a location might have an IMP node for the network, a mainframe ... considered a HOST, another IMP working as a terminal server ... also considered a HOST? The 250 host arpanet on 1/1/83 then possible was in the range of 100 or so IMP network nodes, 100 or so mainframes (considered hosts), possible 100 terminal servers (also considered hosts?), and misc fifty other somethings also considered hosts?

the internal network nomenclature was somewhat more mainframe oriented/centric than network nomenclature centric.

you would have a network node that was synonomous with host and mainframe. the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
having nearly 1000 nodes/hosts at the start of 1/1/83 and passing 1000 nodes/hosts in jun83 ... were 1000 mainframe machines
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address

the mainframe would likely have a half dozen or so "controllers" (in some nomenclature these have been called FEPs, or front-end processors). The controllers could be a mixture of telecommunication controllers and/or terminal controllers. The telcommunication controllers handled a mixture of slow-speed terminal lines and/or telco lines (up to 56kbits/sec). The (3270 dumb) terminal controllers handled coax 3270 terminals that got hundreds of kbits/sec.

Not all of them were the os/360 360 machines ... here is a list of RFCs done by Joel Winett at Lincoln Labs with regard to their arpanet connection with 360/67 running cp67 time-sharing
http://www.garlic.com/~lynn/99.html#51 Internet and/or ARPANET?

This post on MTS and UofMich
http://www.garlic.com/~lynn/2006k.html#41 PDP-1

mentions the "60s" 2703 telecommunication controller (used both for terminal controller lines and other telco lines) and Mich building their own terminal controller from PDP-8
http://www.eecis.udel.edu/~mills/gallery/gallery7.html
I had been involved in something similar as an undergraduate but using an Interdata/3 instead of a PDP-8
http://www.garlic.com/~lynn/subtopic.html#360pcm

A typical mainframe/host configuration (customers, internal network, etc) would have several tens of coax lines to several hundred coax lines. Through the 80s, a lot of the 3270 dumb terminals on the end of these coax connections changed over to PCs supported with terminal emulation ... some recent comment on terminal emulation paradigm
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
http://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64

One of the selling points of T/R starting in the late 80s was reducing the building loading weight by changing the terminal emulation from direct (3270) coax to T/R. The 3270 coax had long coax runs from the machine room to the terminal. As the number of coax cables in these long bundle runs increased ... there were numerous installations where it started to bump up against some structural loading weights. A large datacenter might have tens of mainframes and thousands or tens of thousands of coax cables coming out of the datacenter. A big selling point for T/R was the significant problem that some customers faced with pure structural loading weight of the coax cables ... transitioning from direct point-to-point coax for the terminal emulation to running terminal emulation of T/R. Typical customer strategy was to hang 300 or 400 "terminals" (PCs with terminal emulation) off the same T/R LAN ... all sharing the same bandwidth.

for some drift, when we were out pitching 3-tier architecture in the late 80s ...
http://www.garlic.com/~lynn/subnetwork.html#3tier

we showed a configuration of 100 PCs and workstation. the terminal emulation scenario had typical 100 machines sharing a 16mbit T/R (1/3rd typical configuraiton of 300 machines sharing 16mbit t/r) The 3-tier architecture had multiple enet sections running over the same T/R wiring with high-speed router/backbone for approx. the same cost. This table somewhat gave 16mbit T/R the benefit of the doubt ... even that it is effective thruput was no where near its media bit rate
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?

The 16mbit T/R LAN had possibly 8mbit aggregate max effective thruput and each individual T/R LAN adapter peaked at less than 1mbit/sec (there was this chicken&egg reasoning ... if you were only doing terminal emulation you didn't have to design for higher thruput ... and if you didn't have higher thruput you didn't need to do anything other than terminal emulation).

There were 16 separate 10mbit enet segments (6-7 machines/segement) going into the high-speed router (that was rated at overall sustained thruput of 200mbit/sec) ... each enet segment getting over 9mbit/sec aggregate and the individual enet adapter boards capable of over 9mbit/sec sustained.

The PC/RT group had earlier done a custom 4m T/R card ... but in the switch-over to 16m T/R card, the group was told that they had to use the same card that was produced for the PC terminal emulation market. This 16m T/R card had lower per card thruput than the earlier PC/RT 4m T/R card.

misc. past posts mentioning the difference of opinion between the workstation group and the terminal emulation forces:
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002g.html#9 IBM MIcrochannel??
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2004p.html#59 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
http://www.garlic.com/~lynn/2005q.html#20 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2005q.html#21 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005u.html#50 Channel Distances

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

Arpa address

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Tue, 23 May 2006 12:42:42 -0600
Anne & Lynn Wheeler writes:
so a location might have an IMP node for the network, a mainframe ... considered a HOST, another IMP working as a terminal server ... also considered a HOST? The 250 host arpanet on 1/1/83 then possible was in the range of 100 so IMP network nodes, 100 or so mainframes (considered hosts), possible 100 terminal servers (considered hosts?), and misc fifty other somethings also considered hosts?

re:
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
http://www.garlic.com/~lynn/2006k.html#42 Arpa address

if there were as few as 100 mainframe hosts(?) connected to the arpanet on then 1jan83 cut-over to internetworking ... then the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

would have had nearly ten times as many mainframe host/nodes (on that date as the arpanet had connected mainframes). those nearly 1000 mainframes connected to the internal network ... on 1jan83, the internal network didn't actually pass 1000 mainframe nodes until jun83
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address

would have had on the order of 50,000 connected "terminals" (mostly 3270s) and there would have possibly been somewhere between 100,000 employees and 200,000 employees with email capability.

just the us hone datacenter alone (providing online, interactive vm370 based service for sales, marketing and field people in the us) was pushing upwards of 40,000 defined "users" in the early 80s (of course the branch offices had a much higher ratio of "users" to "terminals" than many of the plant or development sites; in the early 80s, a branch office might only have a few remote 3270 terminals that would be shared between 20-250 people).
http://www.garlic.com/~lynn/subtopic.html#hone

there was some celebration with passing 1000th nodes ... they had these desk things made up with a small clear plastic tripod holding a clear plastic sphere with a stylized map of the world inside ... having a few dots representing nodes and lines connecting them ... with the logo 1000 nodes (I have one in my desk drawer).

from long ago and far away ... preparing for 1000th node

Date: 04/22/83 09:08:00
To: distribution

Just got the VNET 1000 node materials back from the vendor.. Wish that you could see them .... I think that they look GREAT!!!!!

We have a small 8 1/2 x 11 poster for insert into a notepad binder.. a 11 x17 wall poster, a 3 x 5 paperweight w/a reduced version of poster in lucite..and the desk ornament... the poster has a picture of the desk ornament with the globe and a 'network' (actually a constellation)...in blue light with a dark background...

I would like to get a list of candidates from you for the desk ornament which will be given to major contributors of VNET over the years...


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

desk ornament was clear lucite globe that sat in clear lucite "tripod"
http://www.garlic.com/~lynn/vnet1000.jpg

1000th node globe

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

virtual memory

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual memory
Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l
Date: Tue, 23 May 2006 13:17:43 -0600
blmblm writes:
Was there an acronym/initialism for this COMMON area? My memory of doing junior-level systems work on MVS systems is telling me that there was one, but not what. ?

re:
http://www.garlic.com/~lynn/2006i.html#33 virtual memory

"common segment" ... having started out as a 1mbyte "shared" segment in every virtual address space (common segment area, csa)

the hardware table look-aside buffers (TLBs) were STO (virtual address space) associative. the result was that there were unique entries for the same common segment entries from different virtual address spaces.

in the early 80s, some of the high-end hardware started adding special TLB treatment for the MVS "common segment" ... so that there would only be one set of TLB entries for MVS common segment areas across all MVS address spaces. However, this references a "bug" when MVS was running as a virtual guest ... and a temporary fix ... pending availability of MVS APAR.



Date: 18 February 1983, 12:30:13 EST
To: wheeler

Hi - the 'official' fix to the STBVR 0Cx abend problem is MVS APAR/
PTF OZ67587.  I don't know if it's available yet.  In the meantime,
the zap works just fine.

I'll send the zap following this note.

//xxxxx JOB (6007,X003),xxxxxxxx,MSGLEVEL=1,MSGCLASS=O,CLASS=B,
// REGION=1024K,NOTIFY=xxxxxx
//ZAP EXEC PGM=AMASPZAP
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DSN=SYS1.NUCLEUS,DISP=SHR,UNIT=3330,VOL=SER=D00126
**
** FOR VM MVS GUEST, STBVR, TURN OFF USE OF COMMON SEGMENTS
**
 NAME IEAVNPX1 IEAVNPX1
 VER 0DA2 96026003        OI  SGTCB=1
 REP 0DA2 47000000        NOP
 VER 0DCE 96026003        OI  SGTCB=1
 REP 0DCE 47000000        NOP
//

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

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Tue, 23 May 2006 15:12:43 -0600
Anne & Lynn Wheeler writes:
minor ref:

GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)

The Federal Information Processing Standard (FIPS) describing the Federal government's policy, including the DoD transition from TCP/IP to ISO international protocols.


re:
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!

.. a little more excerpt mandating moving off internet to gosip
U. S. Government Open Systems Interconnection Profile (GOSIP)
VERSION 2.0
October 1990

1.1 BACKGROUND

Both the government and the private sector recognize the need to develop a set of common data communication protocols based on the International Organization for Standardization's seven-layer Open Systems Interconnection (OSI) Basic Reference Model [ISO 1]. In the past, vendor-specific implementations of data communication protocols led to isolated domains of information, very difficult and expensive to bridge. Recent advances in communication technology based on the OSI model offer alternatives to vendor-specific network solutions. Most significantly, advances in open systems allow the interoperation of end systems of different manufacture, when required.

This Government Open Systems Interconnection Profile (GOSIP) is based on agreements reached at the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open Systems Interconnection. Each new version of GOSIP will reference the latest appropriate version of the Stable Implementation Agreements for Open Systems Interconnection Protocols [NIST 1], hereafter referred to as the Workshop Agreements. The Workshop Agreements record stable implementation agreements of OSI protocols among the organizations participating in the NIST Workshop for Implementors of OSI.

A new version of the Workshop Agreements is created each year at the December OSI Implementors' Workshop meeting. It is the intent of the NIST Workshop that new versions of the Workshop Agreements will be backwardly compatible with previous versions. New editions of the same version of the Workshop Agreements are published at regular intervals during the year. These new editions contain errata and clarifications to the original agreements that are approved by the Workshop plenary. The latest editions are being distributed to all workshop attendees and are available through the National Technical Information Service (NTIS). See NIST Reference 1 for ordering information.

GOSIP is also consistent with and complementary to industry's Manufacturing Automation Protocol (MAP) [MISC 1] and Technical and Office Protocols (TOP) [MISC 2] specifications. GOSIP addresses the need of the Federal Government to move immediately to multi-vendor interconnectivity without sacrificing essential functionality already implemented in critical networking systems. All capabilities described herein exist as standard products or are close enough to market that they can be proposed by vendors.


... snip ...

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

Keylogger resistance

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Keylogger resistance
Newsgroups: sci.crypt
Date: Tue, 23 May 2006 16:51:11 -0600
"Luc The Perverse" writes:
I would like a small external device using public key cryptography which would require physical replacement/tampering.

I'm not familiar with any such device though.


combination EU finread terminal and chip-card
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#15 Passwords for bank sites - change or not?

above also mentions keylogger's countermeasure to on-screen pin-pad (screen and mouse logging).

misc. past posts mentioning eu finread terminal
http://www.garlic.com/~lynn/subintegrity.html#finread

finread terminal has its own display and keypad ... as countermeasure to large number pc vulnerabilities, viruses, trojans, etc.

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Tue, 23 May 2006 17:05:43 -0600
"Albert Manfredi" writes:
Indeed, that did happen. However, the date was 1990. By 1994, IP was added into GOSIP.

re:
http://www.garlic.com/~lynn/2006k.html#45 Hey! Keep Your Hands Out Of My Abstraction Layer!

so the reference post:
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!

was:
GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)

The Federal Information Processing Standard (FIPS) describing the Federal government's policy, including the DoD transition from TCP/IP to ISO international protocols.


...

aka GOSIP was a specification for moving off TCP/IP to OSI conforming protocols (as early postings in this thread, IP is not an OSI conforming protocol). So then by 1994, they added IP into GOSIP. Does that mean that GOSIP then become a specificaiton for moving off TCP/IP to TCP/IP?

past posts in this thread:
http://www.garlic.com/~lynn/2006j.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#11 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#18 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#19 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#20 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#45 Hey! Keep Your Hands Out Of My Abstraction Layer!

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Tue, 23 May 2006 22:45:57 -0600
krw writes:
First of all, the basic PC didn't come with a floppy at all. The basic 5150 was 16K and no floppy and did sell in the $2K region. I bought a "first day" PC (as an employee) for about $2500 with a floppy, 48K memory, monochrome display and card and a color card.

I had ordered PC on the employee purchase plan the fall of 1982. It took six months to show up. The week after I picked it up, they cut the (street) price to what I had payed.

Scan of the 5150 announcement 23aug81
http://www.cod.edu/people/faculty/zlotow/IBM.htm

from old email:



Date: 02/10/82  08:54:19
To: wheeler

 -------------------------------------------------------------------------------
 From IBM (Employee discount):
 Qty U/M PNumber Description         Cost    (Sub)    Price     (Sub) Discount
 --- --- ------- --------------- -------- --------  ------- --------- --------
  1   1  5150013 System Unit      1517.00  1517.00  2235.00   2235.00      32%
  1   1  1501001 16k Storage        45.00    45.00    90.00     90.00      50%
  1   1  1504910 TV Adapter        223.00   223.00   300.00    300.00      26%
  1   1  1503800 Diskette Drive    366.00   366.00   570.00    570.00      36%
 --- --- ------- --------------- -------- --------  ------- --------- --------
                 Totals           2151.00           3195.00                33%
 With California tax (6.5%):      2290.82 (At least 6 mo. wait...)

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

misc. past posts mentioning acorn:
http://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2003c.html#31 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#19 PC history, was PDP10 and RISC
http://www.garlic.com/~lynn/2003e.html#16 unix
http://www.garlic.com/~lynn/2005q.html#24 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design

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

Value of an old IBM PS/2 CL57 SX Laptop

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Wed, 24 May 2006 08:52:25 -0600
KR Williams writes:
But Sol comes to you in the form of coal, gas, wood, whatever. You choose which one suits your purpose. There is more than one bank too. If everyone stayed away from the thiefs and they would reform.

supposedly the purpose of the bank modernization act was that if you were already a bank, you could stay a bank and if you weren't already a bank, you didn't get to be a bank. one of the senator's even said that it was going to specifically prevent m'soft and walmart from becoming banks and competing with existing banks.

a little more thread drift w/regards S&L crisis
https://www.financialcryptography.com/mt/archives/000727.html
http://www.garlic.com/~lynn/aadsm23.htm#44

this post includes some discussion of the S&L crisis
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

a couple past posts in this thread:
http://www.garlic.com/~lynn/2006i.html#14 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006j.html#9 Value of an old IBM PS/2 CL57 SX Laptop

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

TSO and more was: PDP-1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSO and more was: PDP-1
Newsgroups: alt.folklore.computers
Date: Wed, 24 May 2006 10:25:31 -0600
Brian Inglis writes:
PFM (Personal File Manager) on DOS PCs (pre-Y2K) was pretty similar and I've people said the same about NC (Norton Commander) on DOS PCs and MC (Midnight Commander) on Unix.

Filelist is even better than its predecessor FLIST and pretty elegant when you want to blast through a CMS directory performing some operation(s) on selected files; the command LISTFILE pattern ( EXEC ARGS makes it easy to perform the same operation on all or some files matching a pattern. ISTM SPF is a clunky imitation of FLIST; and ISPF is a crufty development platform for imitating a programmed keypunch with datasets on a terminal to create data and jobs, submit jobs, browse datasets, spool queues, and output.


the original was FULIST, BROWSE, and IOS3270 package done for CMS by Theo Alkema. A REXX version for XEDIT environment was then done. Jim Wyllie at SJR did the PC version that was released in software productivity package (this was before SJR moved up the hill and changed its name).

somebody once told a folklore tale at a SHARE meeting about tie-in between ISPF and CP performance monitor/management products involving charging for software and cost center accounting. Supposedly the ISPF group was a couple hundred people ... and the market price that could be charged for ISPF was significantly less than what was needed to cover the organization run rate. the innovative solution was to capture the CP performance monitor/management products and merge it into the same organization for cost center accounting purpose. The cp performance monitor/management products group consisted of 3 people ... but the revenue was higher than what ISPF earned. Combining the two groups and stopping nearly all new work in CP performance monitor/management ... allowed the group to show postive revenue flow. (supposedly ISPF was strategic for MVS ... and the organization repeatedly had declared cp, vm, cms, et al non-strategic).

collection of threads discussing other aspects of early cp performance benchmarking, monitoring, management ... and early work leading into what has became capacity planning
http://www.garlic.com/~lynn/submain.html#bench

a recent post in another thread about IBM/PC announcement
http://www.garlic.com/~lynn/2006k.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!

misc. old posts about fulist and various descendants
http://www.garlic.com/~lynn/2001f.html#8 Theo Alkema
http://www.garlic.com/~lynn/2001f.html#9 Theo Alkema
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004q.html#63 creat
http://www.garlic.com/~lynn/2005f.html#14 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005t.html#39 FULIST
http://www.garlic.com/~lynn/2005t.html#40 FULIST
http://www.garlic.com/~lynn/2005t.html#41 FULIST
http://www.garlic.com/~lynn/2005t.html#42 FULIST
http://www.garlic.com/~lynn/2005t.html#43 FULIST
http://www.garlic.com/~lynn/2005t.html#44 FULIST
http://www.garlic.com/~lynn/2005t.html#45 FULIST
http://www.garlic.com/~lynn/2005t.html#47 What is written on the keys of an ICL Hand Card Punch?
http://www.garlic.com/~lynn/2005t.html#48 FULIST
http://www.garlic.com/~lynn/2005t.html#49 FULIST
http://www.garlic.com/~lynn/2006.html#0 EREP , sense ... manual
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006b.html#9 Is there a workaround for Thunderbird in a corporate environment?
http://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370

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

other cp/cms history

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: other cp/cms history
Newsgroups: alt.folklore.computers
Date: Wed, 24 May 2006 11:13:28 -0600
Anne & Lynn Wheeler writes:
the original was FULIST, BROWSE, and IOS3270 package done for CMS by Theo Alkema. A REXX version for XEDIT environment was then done. Jim Wyllie at SJR did the PC version that was released in software productivity package (this was before SJR moved up the hill and changed its name).

re:
http://www.garlic.com/~lynn/2006k.html#50 TSO and more was: PDP-1

Names xxx'ed to protect the guilty

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

Date: 17 October 1985, 17:35:59 PDT
To: wheeler

Yeah, you should!!!!!

Some facts about SPM.

Original version was written by xxxxx of IBM Pisa Scientific center for CP-67. I installed his code in Poughkeepsie and, when TDC converted to VM/370 Release 2, I re-wrote the entire function, using the CP-67 code as a guide. Some stuff I kept the same, others I redesigned.

I then gave this code to you, as xxxx was the one who had given me some good feedback in the design. (In fact, it was through SPM that I got to meet you originally.) It was at this time that xxxxx and xxxxx added SPM support to the internal version of RSCS (which eventually was released as the VNET PRPQ). In fact, the VNET PRPQ had, as shipped to customers, all the SPM support. They just didn't get the documentation and the CP updates to support it.

While VM development was still in Burlington, Mass., I shipped a copy of the documentation for SPM (and possibly the code, but I don't remember) to xxxxx, who tried to interest the product group in it. At that time, the product group saw no value to the function in CP. Virtual machines could communicate through virtual CTCAs and/or the spool file system!

Also, although the product group has at least once that I'm aware of disclaimed any knowledge of such a function, I did publish a Poughkeepsie Lab Technical Report (TR 00.2701) in 1975 documenting this facility.

My first release of SPM was on 8/12/75 to the following people:


       1. Lynn Wheeler, Cambridge Scientific Center, Cambridge, Mass.
       2. xxxx, RTP, Raleigh, North Carolina
       3. xxxx, Palo Alto, California
       4. xxxx, Washington Ed Center, Washington, DC.
       5. xxxxx, GPD, Westlake, California

Subsequent releases were as follows:

08/21/75 6. xxxxx, RTP, Raleigh, North Carolina
09/18/75 7. xxxxx, Kingston, New York
09/26/75 8. xxxxx, Boulder, Colorado
10/27/75 9. xxxxx, Lyngby, Denmark
10/xx/75 10. xxxxx, Sindelfingen, Germany
11/xx/75 11. xxxxx, WTSC, Poughkeepsie, New York
11/xx/75 12. xxxxx, Boeblingen, Germany
03/15/76 13. xxxxx, Tel Aviv, Israel
03/17/76 14. xxxxx, Kingston, New York (Common System)
03/17/76 15. xxxxx, Vancouver, British Columbia, Canada
03/17/76 16. xxxxx, Paris, France
04/21/76 17. xxxxx, Uithoorn, Netherlands
05/10/76 18. xxxxx, Zurich, Switzerland
04/30/76 19. xxxxx, Los Angeles Scientific Center, Los Angeles, Ca.
03/xx/77 20. xxxxx, WTSC, Poughkeepsie, New York
03/xx/77 21. xxxxx, TOROLAB.
07/xx/77 22. xxxxx, Syndey, NSW, Australia
07/xx/77 23. xxxxx, Chicago, Illinois
02/22/78 24. xxxxx, San Francisco, California
02/23/78 25. xxxxx, Los Angeles, California
04/05/78 26. xxxxx, Sudbury, United Kingdom
05/24/79 27. xxxxx, Toronto, Ontario, Canada

The last distribution I did was for VM/370 Release 6 and there were about 25 people on the distribution list. This was sometime in 1980.

SPM was mentioned in the second VM Newsletter published by xxxxx.

The combination of VMCF, SMSG, and extended diagnose code 8 provide all functions of SPM EXCEPT the implicit message capability (this was the ability to trap a CP message as a special message). Although the initial version of IUCV did NOT supply this facility, IUCV was enhanced (VM/SP R2 I think) to add this capability, giving the product, after about 8 years, the functional equivalent of the SPM facility to which they saw no value in the CP product.

Ever since the introduction of VM/SP, xxxxx of the Cambridge Scientific Center, Cambridge, Massachusetts has supported these modifications for a vanilla system. Kingston Common has also continued to supply SPM with their system.

Since the product now finally offers the equivalent function, I have recommended that SPM be removed. xxxxxx has no plans to convert this function to SP/R4, Kingston Common plans to remove it when they go to SP/R4, and I am in the process of removing it from the HONE systems.

I still think that the SPM concept is far superior to the approach used by VMCF and IUCV in that the hypervisor has no business being involved with the protocol of inter-virtual machine communication. All the hypervisor should do is deliver the requested data to a receiver who has informed the hypervisor that he is willing to receive this type of communication. I am glad that so many people have been able to profitably use code which I helped to create, but I really doubt if I will ever make such an effort again. The bitterness left after dealing with *************** REDACTED ********************** *************************** REDACTED ******************************* *************** REDACTED ******************* absolutely stomach turning. If people hadn't had the courage to take a chance on something new in the past, we wouldn't have 1/10 the stuff we have today in VM.

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

Lynn - feel free to use anything you wish from this note. I didn't think I cared any more, but I find as I write this that all the bitterness I've felt over the years has come back. I'd appreciate it if you would clean up a little on anything you decide to excerpt from this note, as I doubt that all of it is appropriate for a general forum. You probably more than anyone else in IBM can understand why I feel the way I do.

If you think more elaboration is needed in any area, let me know and I'll dig out what I can for you.

xxxxx


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

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

Keylogger resistance

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Keylogger resistance
Newsgroups: sci.crypt
Date: Wed, 24 May 2006 12:55:47 -0600
Ari Silverstein writes:
Uncool, it was stolen from Cartes Bancshares.

do you mean finread? ... maybe Cartes Bancshares contributed to the finread standard?

FINREAD standard history page:
http://www.finread.com/pages/about/introduction/02_about_history.html

from above:
1998: Start of the FINREAD project (an acronym for FINancial Transactional IC Card READer), a European Commission funded initiative carried out within the framework of the ISIS Programme (Information Society Initiative for Standardisation). Creation of the FINREAD Consortium, an initiative made up of seven partners belonging to the payment and card reader manufacturing industries.

... snip ...

some about the members:
http://www.finread.com/pages/about/introduction/04_about_members.html

from above:
FINREAD has been designed and carried out by seven European partners, together six key European payment systems and the leading card reader manufacturer. They are the founding members and constitute the FINREAD Consortium.

The partners are Banksys (Belgian banking card scheme), MasterCard Europe (former Europay international), Groupement des Cartes Bancaires "CB" (French bank card scheme), Ingenico, Interpay Nederland (Dutch bank card scheme), SIZ (the computer processing centre of the German Saving Banks) and Visa EU (Visa Europe). The design and promotion of FINREAD are co-ordinated by Groupement des Cartes Bancaires "CB".


... snip ...

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Wed, 24 May 2006 13:11:16 -0600
"Albert Manfredi" writes:
Agreed. And the OSI reference model is perfectly usable in today's network protocols, even if other aspects of ISO/OSI might not be. I think most people have agreed that at least up through Layer 4 the fit is perfectly valid, but I think beyond Layer 4 it is also valid.

The only problem is, people who actually WRITE the code for stuff happening at layers 5 and above are not typically "network people." They are those who write applications. So maybe IT folk think those layers are useless or unnecessary, but in fact someone is worried about them too.


a problem is that ISO/OSI doesn't included "internetworking" layer that sits between layer 3 and layer 4 in the OSI model. ISO/OSI also doesn't include local area networking ... which is an interface layer that corresponds to something above layer2/layer3 interface and below the layer3/layer4 interface. both these came into deployment approximately the time that ISO past OSI as a standard ... while possibly not quite making OSI model obsolete ... it did make it out-of-date. previous reference:
http://www.garlic.com/~lynn/2006k.html#11 Hey! Keep Your Hands Out Of My Abstraction Layer!

ISO then further compounded the deficiency by mandating that protocols that violated the OSI model couldn't be approved as ISO standards.

OSI was born of the point-to-point, copper wire, telco paradigm that predated the early 80s (when at least LANs and internetworking protocols were coming into fairly wide-spread deployment). It still works well for people that live in the point-to-point, telco, private networking paradigm world (and not having to deal with LANs and/or internetworking, aka TCP/IP).

for some drift ... long-winded recent thread about arpanet (which was much closer to the OSI model) change-over to internetworking protocols on 1jan83.
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
http://www.garlic.com/~lynn/2006j.html#50 Arpa address
http://www.garlic.com/~lynn/2006j.html#53 Arpa address
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006k.html#12 Arpa address
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006k.html#43 Arpa address

and past posts in this thread:
http://www.garlic.com/~lynn/2006j.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#11 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#19 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#20 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#45 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#47 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#48 Hey! Keep Your Hands Out Of My Abstraction Layer!

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

Hey! Keep Your Hands Out Of My Abstraction Layer!

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Wed, 24 May 2006 13:47:45 -0600
"Le Chaud Lapin" writes:
Was he ever a part of Big Internet? There was a group of people whose opinion about computer networking were completely opposite of mine. I do not remember if he was in the group, but the name looks familiar.

He was at interop '88 ... as was a bunch of osi and isode stuff. misc. past posts about interop '88
http://www.garlic.com/~lynn/subnetwork.html#interop

go to to my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

select "Author" (in the RFCs listed by section)

and scroll down to:
Rose M. (mrose@dbc.mtview.ca.us)
4227 3683 3470 3349 3343 3342 3341 3340 3288 3195 3117 3081 3080 2629 1939 1908 1907 1906 1905 1904 1903 1902 1901 1869 1864 1725 1703 1652 1651 1569 1544 1530 1529 1528 1503 1495 1486 1460 1452 1451 1450 1449 1448 1444 1443 1442 1441 1426 1425 1418 1414 1303 1283 1227 1225 1215 1213 1212 1202 1187 1161 1158 1156 1155 1086 1085 1082 1081 1070 1066 1065 1006 983 934 886


in frames mode, RFC summaries will appear in the bottom frame. clicking on any RFC number in the Author section will bring up the summary for that RFC ... for instance
4227 PS
Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP), O'Tuathail E., Rose M., 2006/01/05 (21pp) (.txt=39112) (Obsoletes 3288) (Refs 2045, 2387, 2392, 2557, 2616, 2782, 3023, 3080, 3156, 3288, 3851, 3902, 3986)


clicking on the ".txt=nnn" filed in the RFC summary will retrieve the actual RFC.

or ...
983 -
ISO transport arrives on top of the TCP, Cass D., Rose M., 1986/04/01 (27pp) (.txt=58280) (Obsoleted by 1006) (Refs 791, 793, 960) (Ref'ed By 1006, 1086)


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

5963 (computer grade dual triode) production dates?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: rec.audio.tubes,alt.folklore.computers,sci.electronics.components
Subject: Re: 5963 (computer grade dual triode) production dates?
Date: Fri, 26 May 2006 12:55:26 -0700
Michael A. Terrell wrote:
The Collins C-band equipment they sold to CATV and TV stations was pure crap as well. Fixed tuned with a single channel filter at the antenna, and a mechanically tuned 4 GHz oscillator. A poor noise figure, and they ran so hot that the green fiberglass PC boards turned dark brown in a couple years of use.

old posts about T3 collins digital radio from san jose main plant site to STL and LSG
http://www.garlic.com/~lynn/2000b.html#57 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2002q.html#45 ibm time machine in new york times?
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E
http://www.garlic.com/~lynn/2005n.html#17 Communications Computers - Data communications over telegraph
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances
http://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications

.....

after they built elevated 85 ... went thru part of the plant site ... people would comment that their radar detector would trip passing the path between the roof of bldg.12 and the relay tower to STL.

there was complete set of c-band stuff for satellite that was but in by SBS on most plant sites (sbs had been formed by comsat, ibm, and aetna). couple posts about the T3 encryptor on the TDMA channel ... the data aggregator (aggravator):
http://www.garlic.com/~lynn/2000b.html#27 Tysons Corner, Virginia
http://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications

one of the projects i got to do as part of HSDT (in additional to various subchannels on the collins dgital radio)
http://www.garlic.com/~lynn/subnetwork.html#hsdt

(... and some clear-channel T1 on telco ... although we had to convert when the local telco's came back and said that they would no longer support clear-channel T1s ... and play games with 193rd bit .... )

was TDMA earth stations that had KU-band transponder on SBS4 (or SBS-D) ... couple posts:
http://www.garlic.com/~lynn/2000b.html#27 Tysons Corner, Virginia
http://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
http://www.garlic.com/~lynn/2003j.html#29 IBM 3725 Comms. controller - Worth saving?
http://www.garlic.com/~lynn/2003j.html#76 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2004.html#32 BASIC Language History?
http://www.garlic.com/~lynn/2005h.html#21 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006d.html#24 IBM 610 workstation computer

sbs4 flew on 41d
http://www.nasa.gov/mission_pages/shuttle/shuttlemissions/archives/sts-41D.html

Hey! Keep Your Hands Out Of My Abstraction Layer!

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Fri, May 26 2006 4:29 pm
Albert Manfredi wrote:
Once again, there is no mention of ISO or OSI in RFC 791, and yet the layered protocol model is clearly used. RFC 791 is the current standard for *IP*, not ISO/OSI protocols. It may only show 4 layers vs 7, but anyone with the slightest clue can see it accomplishes exactly the same function, and is totally consistent with the OSI 7-layer model.

while layering is consistent with other architectures that are layered ... it contains a "internetworking" layer that is totally absent from the OSI 7-layer model.

this is one of the things that we ran afoul of in ansi/iso in the late 80s and early 90s with high-speed protocol. ISO (and iso-chartered national standards body) would not standardized protocols that were not in comformance with the OSI 7-layer model. Since the OSI 7-layer model doesn't have an "internetworking" layer (an abstractions that sits somewhere between the bottom of transport and the top of networking ... where the OSI 7-layer model shows transport going directly to networking and having absolutely no provisions for internetworking).
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

i've had similar discussions about the internal network. the internal networking nodes had a form of gateway layer built into the majority of the nodes.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

while arpanet had much more traditional appearing network (i.e. much more coformance with osi) implementation in the 70s. it didn't really see the gateway layer until the change-over to internetworking on 1/1/83.
http://www.garlic.com/~lynn/subnetwork.html#internet

my assertion is that one of the reasons that the internal network was so much larger than the arpanet from just about the beginning until sometime mid-85 .... was that the internal network had something like a gateway layer from the beginning which the arpanet didn't get until the change-over to internetworking on 1/1/83.

arpanet had possible 250 hosts on 1/1/83 ... but it may have actually been as little as 100 hosts. there were on the order of 100 arpanet "IMP" nodes on 1/1/83 .... and all sub-addresses appeared to have been referred to as "hosts". there may have been as many as 100 of the 250 "hosts" (on 1/1/83) might have possible been terminal controllers rather than more generalized dataprocessing machines (i.e. computers). refs:
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
http://www.garlic.com/~lynn/2006k.html#42 Arpa address

by comparison, the internal networking had nearly 1000 host/nodes on 1/1/83 (it officially passed 1000 nodes in jun83)
http://www.garlic.com/~lynn/2006k.html#43 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address

there was a secondary issue with the internet over-taking the internal network in number of nodes. there was a strong corporate push to restrict PCs and workstations to terminal emulation on the internal network .... where they were becoming full-fledge networking nodes on the internet. recent posts on the subject:
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
http://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64?

misc. collected posts terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation

virtual memory

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re: virtual memory
Date: Tue, 30 May 2006 18:13:16 -0700
robertwessel2@yahoo.com wrote:
That's pretty optimistic for random I/Os on any real hard disks. You're unlikely to get much more than about half that in real life.

But flash as the backing store for VM doesn't make all that much sense in general. First, page stores have pretty much equal read and write traffic, so while read times are pretty good, write times are not, especially for NAND-type devices. Second, flash is not particularly (if at all) cheaper than DRAM, so what's the point? Adding the equivalent amount of DRAM to your system will be a much, much bigger win. In the worst case make the extra DRAM a RAM disk and page to that, and you'd still win. And DRAM avoids the flash wear problems as well.

Obviously situations where main memory cannot be economically expanded and space in a flash device is available may make paging to flash practical.


3090 in the mid-80s had "expanded" store ... it was normal dram at the end of a special high-speed bus, the physical packaging for dram limited the amount that could be configured for the cache/processer specs. ... so they created a special bus that allowed kernel software to do very fast 4k page transfers between normal memory and expanded store memory. it was logically an electronic paging device ... but used synchronous tranfer instruction.

later technology overcame the physical packaging limitations that led to 3090 expanded store solution.

misc. past postings mentioning expanded store
http://www.garlic.com/~lynn/2002.html#17 index searching
http://www.garlic.com/~lynn/2004e.html#2 Expanded Storage
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces

circa 1980, several hundred "1655" were procured for internal datacenter use (dram paging i/o device that emulated a 2305 fixed-head disk). the claim was that that the vendor had used dram chips that had failed various normal memory acceptance tests. the failures were such that a device controller had sufficient latency in the i/o paradigm to compensate for various kinds of dram failures ... allowing the chips to still be put to some use (as opposed to going to the trash bin).

misc. past posts mentioning 1655s
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s

past posts in this thread:
http://www.garlic.com/~lynn/2006i.html#22 virtual memory
http://www.garlic.com/~lynn/2006i.html#23 Virtual memory
http://www.garlic.com/~lynn/2006i.html#24 Virtual memory
http://www.garlic.com/~lynn/2006i.html#28 virtual memory
http://www.garlic.com/~lynn/2006i.html#30 virtual memory
http://www.garlic.com/~lynn/2006i.html#31 virtual memory
http://www.garlic.com/~lynn/2006i.html#32 virtual memory
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006i.html#36 virtual memory
http://www.garlic.com/~lynn/2006i.html#37 virtual memory
http://www.garlic.com/~lynn/2006i.html#38 virtual memory
http://www.garlic.com/~lynn/2006i.html#39 virtual memory
http://www.garlic.com/~lynn/2006i.html#40 virtual memory
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#0 virtual memory
http://www.garlic.com/~lynn/2006j.html#1 virtual memory
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#4 virtual memory
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#7 virtual memory
http://www.garlic.com/~lynn/2006j.html#13 virtual memory
http://www.garlic.com/~lynn/2006j.html#14 virtual memory
http://www.garlic.com/~lynn/2006j.html#17 virtual memory
http://www.garlic.com/~lynn/2006j.html#18 virtual memory
http://www.garlic.com/~lynn/2006j.html#19 virtual memory
http://www.garlic.com/~lynn/2006j.html#20 virtual memory
http://www.garlic.com/~lynn/2006j.html#21 virtual memory
http://www.garlic.com/~lynn/2006j.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#23 virtual memory
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006j.html#25 virtual memory
http://www.garlic.com/~lynn/2006j.html#26 virtual memory
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006j.html#30 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006j.html#37 virtual memory
http://www.garlic.com/~lynn/2006j.html#39 virtual memory
http://www.garlic.com/~lynn/2006j.html#40 virtual memory
http://www.garlic.com/~lynn/2006j.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#43 virtual memory
http://www.garlic.com/~lynn/2006j.html#44 virtual memory


previous, next, index - home