--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600TwistyCreek writes:
from the three factor authentication model
https://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.
https://www.garlic.com/~lynn/subintegrity.html#harvest
some recent posts about yes card and recent chip&pin skimming:
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#41 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#26 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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.
https://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
https://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:
https://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
https://www.garlic.com/~lynn/2006j.html#34 Arpa address
https://www.garlic.com/~lynn/2006j.html#45 Arpa address
https://www.garlic.com/~lynn/2006j.html#46 Arpa address
https://www.garlic.com/~lynn/2006j.html#49 Arpa address
https://www.garlic.com/~lynn/2006j.html#50 Arpa address
https://www.garlic.com/~lynn/2006j.html#53 Arpa address
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://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.
https://www.garlic.com/~lynn/aadsm19.htm#26 Trojan horse attack involving many major Israeli companies, executives
https://www.garlic.com/~lynn/aadsm20.htm#6 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
https://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model
https://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
https://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/2003n.html#10 Cracking SSL
https://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
https://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
https://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2005u.html#20 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Arpa address Newsgroups: alt.folklore.computers Date: Thu, 18 May 2006 23:08:50 -0600ref:
from
https://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
https://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 IBM 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
https://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 | https://www.garlic.com/~lynn/
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 -0600Jim Watt <jimwatt@aol.no_way> writes:
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.
https://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.
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://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
https://www.garlic.com/~lynn/subintegrity.html#fraud
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600KR Williams writes:
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
https://www.garlic.com/~lynn/x959.html#x959
https://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.
https://www.garlic.com/~lynn/subintegrity.html#harvest
a somewhat related, recent post
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
misc. collected posts on vulnerabilities, threats, exploits, fraud
https://www.garlic.com/~lynn/subintegrity.html#fraud
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
https://www.garlic.com/~lynn/2006i.html#19 blast from the past on reliable communication
https://www.garlic.com/~lynn/2006i.html#20 blast from the past on reliable communication
https://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
https://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Arpa address Newsgroups: alt.folklore.computers Date: Fri, 19 May 2006 10:09:02 -0600eugene@cse.ucsc.edu (Eugene Miya) writes:
lotus was an 1995 purchase ... more than a decade later:
https://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:
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/internet.htm#22
https://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
https://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 IBM 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--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Arpa address Newsgroups: alt.folklore.computers Date: Fri, 19 May 2006 12:30:36 -0600eugene@cse.ucsc.edu (Eugene Miya) writes:
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).
https://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.
https://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).
https://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.
https://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
https://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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Arpa address Newsgroups: alt.folklore.computers Date: Fri, 19 May 2006 14:35:09 -0600Anne & 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.
https://www.garlic.com/~lynn/2000e.html#18
https://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 synchronize such upgrades across the whole infrastructure.
some misc. RFCs ... from my rfc index.
https://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
https://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).
https://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 | https://www.garlic.com/~lynn/
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 -0600re:
... 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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Arpa address Newsgroups: alt.folklore.computers Date: Fri, 19 May 2006 14:58:19 -0600Anne & Lynn Wheeler writes:
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.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Pankian Metaphor Newsgroups: alt.folklore.computers Date: Fri, 19 May 2006 15:40:32 -0600Eric Smith writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Pankian Metaphor Newsgroups: alt.folklore.computers Date: Fri, 19 May 2006 16:57:30 -0600Eric Smith writes:
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 theoretically it was 32bit+12bit
... 44bit api).
https://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 | https://www.garlic.com/~lynn/
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 -0600Jim Watt <jimwatt@aol.no_way> writes:
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
https://www.garlic.com/~lynn/subintegrity.html#finread
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600jmfbahciv writes:
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
https://www.garlic.com/~lynn/subintegrity.html#fraud
an old favorite on security proportional to risk (also mentioning
insider threat)
https://www.garlic.com/~lynn/2001h.html#61
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
recent post in this thread
https://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
https://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.
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://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
https://www.garlic.com/~lynn/subpubkey.html#sslcert
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600re:
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:
https://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
https://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
https://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/2005k.html#26 More on garbage
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Anne & Lynn Wheeler writes:
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.
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://www.garlic.com/~lynn/2006h.html#27 confidence in CA
https://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).
https://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:
https://www.garlic.com/~lynn/2006j.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#11 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Anne & Lynn Wheeler writes:
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 | https://www.garlic.com/~lynn/
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 -0600Tom Schmidt wrote:
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
https://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
https://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
https://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
https://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):
https://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):
https://www.garlic.com/~lynn/2006j.html#53 Arpa address
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/2006k.html#8 Arpa address
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#10 Arpa address
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Encryption for Powerpoint? Newsgroups: sci.crypt Date: Sat, 20 May 2006 17:20:44 -0600Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
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 | https://www.garlic.com/~lynn/
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 -0600jmfbahciv writes:
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.
https://www.garlic.com/~lynn/x959.html#x959
https://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,
https://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.
https://www.garlic.com/~lynn/subintegrity.html#harvest
this is also the point of my old security proportional to risk
posting
https://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:
https://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 | https://www.garlic.com/~lynn/
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 -0600jmfbahciv writes:
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 | https://www.garlic.com/~lynn/
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 -0600Bernd Paysan writes:
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 ...
https://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:
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://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 recovering 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 | https://www.garlic.com/~lynn/
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 -0600jmfbahciv writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Sun, 21 May 2006 18:22:08 -0600David Scheidt writes:
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
https://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 | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 08:08:37 -0600Morten Reistad writes:
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
https://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
https://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 Kildall using cp67/cms at NPG in '72
https://www.garlic.com/~lynn/2004e.html#38
various other time-sharing and cp67 history
https://www.leeandmelindavarian.com/Melinda/25paper.ps
old post given super & superminis ... including numbers of superminis
as of 88
https://www.garlic.com/~lynn/2001b.html#56
old past given some overview of supercomputers, superminis, etc
in the late 80s and early 90s
https://www.garlic.com/~lynn/2001n.html#70
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 08:21:17 -0600Morten Reistad writes:
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
https://www.garlic.com/~lynn/subtopic.html#545tech
Melinda history covers a lot of detail of that period.
https://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 follow-on, 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 (follow-on 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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 08:52:08 -0600Morten Reistad writes:
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:
https://www.garlic.com/~lynn/2006k.html#8 Arpa address
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#10 Arpa address
https://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.
https://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.
https://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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 09:35:12 -0600Morten Reistad writes:
mentions commercial announcement 1/1973
multics air force data center, first install
11/73 ... grew to six systems
https://www.multicians.org/site-afdsc.html
reference to afdc ordering 210 4341s in 1979
https://www.garlic.com/~lynn/2006k.html#31 PDP-1
https://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:
https://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)
https://www.leeandmelindavarian.com/Melinda/25paper.ps
reference to cp67/cms
https://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
https://www.garlic.com/~lynn/2006k.html#30 PDP-1
https://www.garlic.com/~lynn/submain.html#timeshare
multics site home page
https://www.multicians.org/multics.html
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Tom Marchant wrote:
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).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 10:59:49 -0600eugene@cse.ucsc.edu (Eugene Miya) writes:
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
https://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
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
https://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
https://www.garlic.com/~lynn/2005s.html#26 IEH/IEB/... names?
https://www.garlic.com/~lynn/2006d.html#35 Fw: Tax chooses dead language - Austalia
https://www.garlic.com/~lynn/2006d.html#38 Fw: Tax chooses dead language - Austalia
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 12:07:06 -0600Anne & 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.
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)
https://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
https://www.garlic.com/~lynn/submain.html#systemr
some past postings mentioning nomad, ramis, focus
https://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
https://www.garlic.com/~lynn/2003d.html#15 CA-RAMIS
https://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
https://www.garlic.com/~lynn/2003m.html#33 MAD Programming Language
https://www.garlic.com/~lynn/2003n.html#12 Dreaming About Redesigning SQL
https://www.garlic.com/~lynn/2003n.html#15 Dreaming About Redesigning SQL
https://www.garlic.com/~lynn/2004e.html#15 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
https://www.garlic.com/~lynn/2004j.html#52 Losing colonies
https://www.garlic.com/~lynn/2004l.html#44 Shipwrecks
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 13:55:09 -0600Anne & Lynn Wheeler writes:
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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 14:27:57 -0600Anne & Lynn Wheeler writes:
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:
https://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
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
https://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001n.html#10 TSS/360
https://www.garlic.com/~lynn/2002f.html#59 Blade architectures
https://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
https://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002j.html#75 30th b'day
https://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
https://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
https://www.garlic.com/~lynn/2003j.html#20 A Dark Day
https://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
https://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
https://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
https://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
https://www.garlic.com/~lynn/2004m.html#49 EAL5
https://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
https://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
https://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005d.html#43 Secure design
https://www.garlic.com/~lynn/2005d.html#50 Secure design
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities
https://www.garlic.com/~lynn/2005s.html#12 Flat Query
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 16:28:13 -0600Peter Flass writes:
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
https://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
https://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))
https://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))
https://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))
https://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))
https://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))
https://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))
https://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))
https://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
https://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
https://www.garlic.com/~lynn/aadsm3.htm#kiss10 KISS for PKIX. (authentication/authorization seperation)
https://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 18:01:27 -0600Anne & Lynn Wheeler writes:
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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Arpa address Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 19:18:14 -0600Anne & Lynn Wheeler writes:
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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Mon, 22 May 2006 20:35:41 -0600tss/360 was the original "designated" operating system for the 360/67. it was never very successful. in anticipation of virtual memory, the cambridge science center
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
https://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:
https://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
https://www.garlic.com/~lynn/2006k.html#29 PDP-1
https://www.garlic.com/~lynn/submain.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 supervisor). The folklore was that the people at UofMich scaffolding building MTS using LLMPS.
misc. past posts mentioning LLMPS
https://www.garlic.com/~lynn/93.html#15 unit record & other controllers
https://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
https://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
https://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
https://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
https://www.garlic.com/~lynn/2000.html#89 Ux's good points.
https://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001m.html#55 TSS/360
https://www.garlic.com/~lynn/2001n.html#45 Valid reference on lunar mission data being unreadable?
https://www.garlic.com/~lynn/2001n.html#89 TSS/360
https://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2002n.html#64 PLX
https://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
https://www.garlic.com/~lynn/2004d.html#31 someone looking to donate IBM magazines and stuff
https://www.garlic.com/~lynn/2004l.html#16 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
https://www.garlic.com/~lynn/2005g.html#56 Software for IBM 360/30
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://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
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://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
https://www.garlic.com/~lynn/99.html#51 Internet and/or ARPANET?
This post on MTS and UofMich
https://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
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
https://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 ...
https://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
https://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:
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
https://www.garlic.com/~lynn/2002g.html#9 IBM MIcrochannel??
https://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
https://www.garlic.com/~lynn/2004p.html#59 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
https://www.garlic.com/~lynn/2005q.html#20 Ethernet, Aloha and CSMA/CD -
https://www.garlic.com/~lynn/2005q.html#21 Ethernet, Aloha and CSMA/CD -
https://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005u.html#50 Channel Distances
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Arpa address Newsgroups: alt.folklore.computers Date: Tue, 23 May 2006 12:42:42 -0600Anne & Lynn Wheeler writes:
if there were as few as 100 mainframe hosts(?) connected to the
arpanet on then 1jan83 cut-over to internetworking ... then the
internal network
https://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
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://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).
https://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, HSDT email
desk ornament was clear lucite globe that sat in clear lucite "tripod"
https://www.garlic.com/~lynn/vnet1000.jpg
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600blmblm writes:
"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 | https://www.garlic.com/~lynn/
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 -0600Anne & Lynn Wheeler writes:
.. 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 | https://www.garlic.com/~lynn/
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:
above also mentions keylogger's countermeasure to on-screen pin-pad (screen and mouse logging).
misc. past posts mentioning eu finread terminal
https://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 | https://www.garlic.com/~lynn/
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:
so the reference post:
https://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:
https://www.garlic.com/~lynn/2006j.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#11 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#18 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#19 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#20 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#45 Hey! Keep Your Hands Out Of My Abstraction Layer!
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600krw writes:
Scan of the 5150 announcement 23aug81
http://www.csnews.com/csn/search/article_display.jsp?vnu_content_id=1002425619
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:
https://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2003c.html#31 difference between itanium and alpha
https://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#19 PC history, was PDP10 and RISC
https://www.garlic.com/~lynn/2003e.html#16 unix
https://www.garlic.com/~lynn/2005q.html#24 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600KR Williams writes:
a little more thread drift w/regards S&L crisis
https://www.financialcryptography.com/mt/archives/000727.html
https://www.garlic.com/~lynn/aadsm23.htm#44
this post includes some discussion of the S&L crisis
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
a couple past posts in this thread:
https://www.garlic.com/~lynn/2006i.html#14 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006j.html#9 Value of an old IBM PS/2 CL57 SX Laptop
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Brian Inglis writes:
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
https://www.garlic.com/~lynn/submain.html#bench
a recent post in another thread about IBM/PC announcement
https://www.garlic.com/~lynn/2006k.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!
misc. old posts about fulist and various descendants
https://www.garlic.com/~lynn/2001f.html#8 Theo Alkema
https://www.garlic.com/~lynn/2001f.html#9 Theo Alkema
https://www.garlic.com/~lynn/2002o.html#25 Early computer games
https://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
https://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
https://www.garlic.com/~lynn/2004q.html#63 creat
https://www.garlic.com/~lynn/2005f.html#14 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005t.html#39 FULIST
https://www.garlic.com/~lynn/2005t.html#40 FULIST
https://www.garlic.com/~lynn/2005t.html#41 FULIST
https://www.garlic.com/~lynn/2005t.html#42 FULIST
https://www.garlic.com/~lynn/2005t.html#43 FULIST
https://www.garlic.com/~lynn/2005t.html#44 FULIST
https://www.garlic.com/~lynn/2005t.html#45 FULIST
https://www.garlic.com/~lynn/2005t.html#47 What is written on the keys of an ICL Hand Card Punch?
https://www.garlic.com/~lynn/2005t.html#48 FULIST
https://www.garlic.com/~lynn/2005t.html#49 FULIST
https://www.garlic.com/~lynn/2006.html#0 EREP , sense ... manual
https://www.garlic.com/~lynn/2006.html#13 VM maclib reference
https://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
https://www.garlic.com/~lynn/2006b.html#9 Is there a workaround for Thunderbird in a corporate environment?
https://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
https://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: other cp/cms history Newsgroups: alt.folklore.computers Date: Wed, 24 May 2006 11:13:28 -0600Anne & Lynn Wheeler writes:
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, CaliforniaSubsequent releases were as follows:
08/21/75 6. xxxxx, RTP, Raleigh, North Carolina 09/18/75 7. xxxxx, IBM 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, IBM 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, CanadaThe 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.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Keylogger resistance Newsgroups: sci.crypt Date: Wed, 24 May 2006 12:55:47 -0600Ari Silverstein writes:
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 | https://www.garlic.com/~lynn/
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:
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.
https://www.garlic.com/~lynn/2006j.html#34 Arpa address
https://www.garlic.com/~lynn/2006j.html#45 Arpa address
https://www.garlic.com/~lynn/2006j.html#46 Arpa address
https://www.garlic.com/~lynn/2006j.html#49 Arpa address
https://www.garlic.com/~lynn/2006j.html#50 Arpa address
https://www.garlic.com/~lynn/2006j.html#53 Arpa address
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/2006k.html#8 Arpa address
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#10 Arpa address
https://www.garlic.com/~lynn/2006k.html#12 Arpa address
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
https://www.garlic.com/~lynn/2006k.html#42 Arpa address
https://www.garlic.com/~lynn/2006k.html#43 Arpa address
and past posts in this thread:
https://www.garlic.com/~lynn/2006j.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#11 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#19 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#20 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#45 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#47 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#48 Hey! Keep Your Hands Out Of My Abstraction Layer!
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
go to to my rfc index
https://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 | https://www.garlic.com/~lynn/
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 -0700Michael A. Terrell wrote:
.....
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):
https://www.garlic.com/~lynn/2000b.html#27 Tysons Corner, Virginia
https://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications
https://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)
https://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:
https://www.garlic.com/~lynn/2000b.html#27 Tysons Corner, Virginia
https://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
https://www.garlic.com/~lynn/2003j.html#29 IBM 3725 Comms. controller - Worth saving?
https://www.garlic.com/~lynn/2003j.html#76 1950s AT&T/IBM lack of collaboration?
https://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2004.html#32 BASIC Language History?
https://www.garlic.com/~lynn/2005h.html#21 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD -
https://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications
https://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
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 pmAlbert Manfredi wrote:
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 conformance 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).
https://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.
https://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.
https://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:
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
https://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)
https://www.garlic.com/~lynn/2006k.html#43 Arpa address
https://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:
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
https://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64?
misc. collected posts terminal emulation
https://www.garlic.com/~lynn/subnetwork.html#emulation
From: lynn@garlic.com Newsgroups: comp.arch,alt.folklore.computers Subject: Re: virtual memory Date: Tue, 30 May 2006 18:13:16 -0700robertwessel2@yahoo.com wrote:
later technology overcame the physical packaging limitations that led to 3090 expanded store solution.
misc. past postings mentioning expanded store
https://www.garlic.com/~lynn/2002.html#17 index searching
https://www.garlic.com/~lynn/2004e.html#2 Expanded Storage
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
https://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
https://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 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
https://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001l.html#53 mainframe question
https://www.garlic.com/~lynn/2002.html#31 index searching
https://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
https://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
https://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
https://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
https://www.garlic.com/~lynn/2005r.html#51 winscape?
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
https://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
past posts in this thread:
https://www.garlic.com/~lynn/2006i.html#22 virtual memory
https://www.garlic.com/~lynn/2006i.html#23 Virtual memory
https://www.garlic.com/~lynn/2006i.html#24 Virtual memory
https://www.garlic.com/~lynn/2006i.html#28 virtual memory
https://www.garlic.com/~lynn/2006i.html#30 virtual memory
https://www.garlic.com/~lynn/2006i.html#31 virtual memory
https://www.garlic.com/~lynn/2006i.html#32 virtual memory
https://www.garlic.com/~lynn/2006i.html#33 virtual memory
https://www.garlic.com/~lynn/2006i.html#36 virtual memory
https://www.garlic.com/~lynn/2006i.html#37 virtual memory
https://www.garlic.com/~lynn/2006i.html#38 virtual memory
https://www.garlic.com/~lynn/2006i.html#39 virtual memory
https://www.garlic.com/~lynn/2006i.html#40 virtual memory
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006j.html#0 virtual memory
https://www.garlic.com/~lynn/2006j.html#1 virtual memory
https://www.garlic.com/~lynn/2006j.html#2 virtual memory
https://www.garlic.com/~lynn/2006j.html#3 virtual memory
https://www.garlic.com/~lynn/2006j.html#4 virtual memory
https://www.garlic.com/~lynn/2006j.html#5 virtual memory
https://www.garlic.com/~lynn/2006j.html#7 virtual memory
https://www.garlic.com/~lynn/2006j.html#13 virtual memory
https://www.garlic.com/~lynn/2006j.html#14 virtual memory
https://www.garlic.com/~lynn/2006j.html#17 virtual memory
https://www.garlic.com/~lynn/2006j.html#18 virtual memory
https://www.garlic.com/~lynn/2006j.html#19 virtual memory
https://www.garlic.com/~lynn/2006j.html#20 virtual memory
https://www.garlic.com/~lynn/2006j.html#21 virtual memory
https://www.garlic.com/~lynn/2006j.html#22 virtual memory
https://www.garlic.com/~lynn/2006j.html#23 virtual memory
https://www.garlic.com/~lynn/2006j.html#24 virtual memory
https://www.garlic.com/~lynn/2006j.html#25 virtual memory
https://www.garlic.com/~lynn/2006j.html#26 virtual memory
https://www.garlic.com/~lynn/2006j.html#27 virtual memory
https://www.garlic.com/~lynn/2006j.html#30 virtual memory
https://www.garlic.com/~lynn/2006j.html#31 virtual memory
https://www.garlic.com/~lynn/2006j.html#37 virtual memory
https://www.garlic.com/~lynn/2006j.html#39 virtual memory
https://www.garlic.com/~lynn/2006j.html#40 virtual memory
https://www.garlic.com/~lynn/2006j.html#41 virtual memory
https://www.garlic.com/~lynn/2006j.html#43 virtual memory
https://www.garlic.com/~lynn/2006j.html#44 virtual memory
previous, next, index - home