From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: TSS/360 Newsgroups: alt.folklore.computers Date: Thu, 29 Nov 2001 06:00:59 GMTAlistair Gale writes:
Most of them came up on standard ibm operating system for various specific functions ... but took over most of the scheduling and interactive services.
CPS (conversational programming system) done by the IBM Boston Programming Center was one such. It supported "interactive" PL/I and there was even optional special 360/50 microcode speedup done for CPS.
Another example is the original apl/360 (or apl\360) done by the ibm phili science center (cambridge modified it into cms/apl and rewrote the garbage collection for large workspaces and virtual memory).
A much more "controlled" example would be CICS ... which is brought up ... loads a specific set of interactive environment and manages all of the resources dedicated to it (although the types of interactive services available tends to be more controlled and limited than some of the other interactive offerings). Early IMS also fell somewhat into similar category.
Stanford had Wylbur which could somewhat be considered another example.
Another was MUMPS (I think original done somewhere in the boston area, find it in the medical industry) ... which also eventually saw wide deployment under VM/370.
Of course another is PARS ... or ACP ... airline control program which was the mainstay of the airline reservation world (reservation terminals, check-in counters, etc) ... now called TPF. It has somewhat branched out from just purely airline reservation systems into other industry reservation systems and some of the financial transaction networks.
That is off the top of my head ... 60s/70s IBM mainframe, non-virtual-memory, interactive systems (or subsystems).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: More newbie stop the war here! Newsgroups: alt.os.linux,alt.folklore.computers Date: Thu, 29 Nov 2001 15:48:10 GMTmike writes:
cms was started by ibm cambridge science center '66 in 545 tech. sq, cambridge by several people that had worked on CTSS. In the '66 flavor the base disk/default was "P" (for personal) which was changed to "A" (first letter in the alphabet) around '71. This corresponds to the initial PC/DOS ... pre-hard disk. PC w/hard disk changed to "C" disk (because dual floppy had taken "A" & "B")
Better known is multics which was also going on in same bldg. 545 tech. sq (about the same time) that also included some number of former CTSS people ... and unix was somewhat a play/derivative on multics (aka lineage of both dos & unix trace back thru 545 tech. sq to CTSS)
CMS had much more dynamic mapping of drives to letters with access command. in nt you go to disk administrator to map drive/partitions to letters (but there are much more static mapping from the original dos).
there are couple recent postings on file system
https://www.garlic.com/~lynn/2001m.html#56 Contiguous file system
https://www.garlic.com/~lynn/2001m.html#57 Contiguous file system
https://www.garlic.com/~lynn/2001m.html#58 Contiguous file system
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Author seeks help - net in 1981 Newsgroups: alt.folklore.computers Date: Thu, 29 Nov 2001 17:49:21 GMTAnne & Lynn Wheeler writes:
12, 89, 145, 338, 466, 525, 546, 547, 549, 570
there was also another batch that went out earlier this month:
80, 88, 222, 264, 409, 460, 508, 524, 528, 532, 538, 543, 553
couple intros
Network Working Group B. Metcalff
Request for Comments: 89 MITDG
NIC: 5697 19 January 1971
SOME HISTORIC MOMENTS IN NETWORKING
While awaiting the completion of an interim network control program
(INCP) for the MIT MAC Dynamic Modeling/Computer Graphics PDP-6/10
System (MITDG), we were able to achieve a number of 'historic moments
in networking' worthy of some comment. First, we were able to
connect an MITDG terminal to a Multics process making it a Multics
terminal. Second, we successfully attached an MITDG terminal to the
Harvard PDP-10 System thereby enabling automatic remote use of the
Harvard System for MIT. Third, we developed primitive mechanisms
through which remotely generated programs and data could be
transmitted to our system, executed, and returned. Using these
mechanisms in close cooperation with Harvard, we received graphics
programs and 3D data from Harvard's PDP-10, processed them repeatedly
using our Evans & Sutherland Line Drawing System (the E&S), and
transmitted 2D scope data to Harvard's PDP-1 for display.
Network Working Group R.T. Braden
Request for Comments: 338 UCLA/CCN
NIC: 9931 17 May 1972
EBCDIC/ASCII MAPPING FOR NETWORK RJE
A. INTRODUCTION
Under NETRJS [1], CCN's Network rje protocol [2], a virtual remote
batch terminal may be either EBCDIC or ASCII. CCN operates an IBM
360/91 which performs all of its normal processing in EBCDIC. When a
virtual ASCII terminal signs onto NETRJS, CCN translates the "card
reader" stream to EBCDIC and translates the "printer" stream back to
ASCII [3].
In recent months, a number of ASCII hosts (RAND PDP-10, Utah PDP-10,
Illinois PDP-11) have completed user processes for NETRJS. Several
users at these sites have noted deficiencies in the ASCII/EBCDIC
mapping rules originally implemented in NETRJS. Since their
objections were well founded, we have altered the existing mapping
and added a new one.
Network Working Group J. Winett
Request for Comments: 466 LL-67
NIC: 14740 27 February 1973
Category: TELNET
TELNET LOGGER/SERVER For Host LL-67
The attached writeup documents the TELNET LOGGER/SERVER for the
CP/CMS system on the Lincoln Laboratory 360>67 (host 10). The
facility serves both half duplex and full duplex TELNET users with
data in either ASCII or EBCDIC codes.
Use of the hide-your-input and noecho TELNET controls are used for
the EBCDIC print suppress (bypass) and print restore features during
the login procedure. To support half duplex terminals, the TELNET
control break (reverse break) is sent as an input prompt when input
is desired. This code can also be used to indicate that a previous
line sent without an end of line sequence (CR-LF) should be printed.
Network Working Group W. Parrish
Request for Comments: 525 J. Pickens
NIC: 17161 Computer Systems Laboratory -- UCSB
1 June 1973
MIT-MATHLAB MEETS UCSB-OLS:
An Example of Resource Sharing
I. Introduction
A. Resource Sharing, A Comment
Non-trivial resource sharing among dissimilar system is a much
discussed concept which, to date, has seen only a few real
applications. [See NIC 13538, "1972 Summary of Research
Activities" (UTAH) for description of Tony Hearn's TENEX-CCN
Programming Link.] The first attempts have utilized the most
easily accessible communication paths, (TELNET and RJS) and the
most universal representations of numbers (byte-oriented numeric
characters in scientific notation). Future schemes will probably
be more efficient through standardized data and control protocols,
but even with the existing approaches users are gaining experience
with combinations of resources previously not available.
Network Working Group J. White
Request for Comments: 524 SRI-ARC
NIC: 17140 13 June 1973
A Proposed Mail Protocol
AUTHOR'S INTENT
This is the document I offered in (15146,) to write. It's a proposed
specification for handling mail in the Network -- a Mail Protocol.
Main handling is currently implemented as two FTP commands, MAIL and
MLFL, which permit an FTP user process to deliver a file or string of
text to an FTP server process, designating it as mail to be made
available to a user, identified by a local name, in its host. The
protocol proposed here is much richer than that, both in terms of the
functions it supports, and in terms of the flexibility it provides.
Network Working Group J. McQuillan
Request for Comments: 528 BBN-NET
NIC: 17164 20 June 1973
SOFTWARE CHECKSUMMING IN THE IMP AND NETWORK RELIABILITY
As the ARPA Network has developed over the last few years, and our
experience with operating the IMP subnetwork has grown, the issue of
reliability has assumed greater importance and greater complexity.
This note describes some modifications that have recently been made
to the IMP and TIP programs in this regard. These changes are
mechanically minor and do not affect Host operation at all, but they
are logically noteworthy, and for this reason we have explained the
workings of the new IMP and TIP programs in some detail. Host
personnel are advised to note particularly the modifications
described in sections 4 and 5, as they may wish to change their own
programs or operating procedures.
Network Working Group A. McKenzie
Request for Comments: 538 BBN-NET
NIC: 17642 5 July 1973
Updates: RFC 522
Traffic Statistics (June 1973)
ABSTRACT
Attached are the Host traffic statistics for the month of June 1973.
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: News IBM loses supercomputer crown Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 29 Nov 2001 19:59:17 GMTRugenL@MISSOURI.EDU (Rugen, Len) writes:
random refs:
https://www.garlic.com/~lynn/subtopic.html#hone
https://www.garlic.com/~lynn/subtopic.html#hacmp
https://www.garlic.com/~lynn/2001i.html#52 loosely-coupled, sysplex, cluster, supercomputer & electronic commerce
one of the largest customer single system image complexes i know of from the '90s was one of the airline reservation systems running TPF .... unfortunately they had max'ed out the disk access to CPUs all having maximum number of processors .... and were extending the functionality using Network Systems HYPERchannel gear (since bought by STK) as basis for message-passing, non-shared-disk operations.
random refs:
https://www.garlic.com/~lynn/subnetwork.html#hsdt
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Contiguous file system Newsgroups: comp.lang.asm370,alt.folklore.computers Date: Thu, 29 Nov 2001 20:08:14 GMTgah@ugcs.caltech.edu (glen herrmannsfeldt) writes:
You also found similar allocation in a number of systems (apl, some number of lisp, etc) from the same era for managing real storage .... always allocate the next available (highest) slot until end-of-storage is reached ... and then pause while garbage collection (compression) is performed ... and then restart all over again.
The allocation scheme for real storage ran into problems when mapped to virtual storage. An apl user have a "real" 32kbyte workspace tripsing thru all of stroage (even tho it never used more than a couple kbytes peak) would hardly see the effects .... but move the same apl user and the same application into a (virtual) 16mbyte workspace .... and it would eventually step thru all 16mbytes. Most of these strategies were quickly enhanced with various kinds of "dynamic" garbage collection strategies to minimize having applications eventually touch every possible virtual page (even when the peak aggregate use was less than one percent of the total).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Author seeks help - net in 1981 Newsgroups: alt.folklore.computers Date: Fri, 30 Nov 2001 01:24:56 GMTChristopher Stacy writes:
the cut-over date was 1/1/93
^^
1/1/83
from posting
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
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Author seeks help - net in 1981 Newsgroups: alt.folklore.computers Date: Fri, 30 Nov 2001 01:27:26 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: More newbie stop the war here! Newsgroups: alt.os.linux,alt.folklore.computers Date: Fri, 30 Nov 2001 02:37:12 GMTmike writes:
cms file system
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/HCSD2A20/2.6
overview of the cms file system
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/HCSD2A20/2.6.1
current CMS & CP data areas and control blocks
http://www.vm.ibm.com/pubs/ctlblk.html
most current CMS control blocks
http://www.vm.ibm.com/pubs/cms420/index.html
of interest: ADTSECT, FSTD, FSTSECT, FSCB, SFSCB, XADT.
one of the VM history pages:
http://www.vm.ibm.com/birthday.html
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Future applications of smartcard. Newsgroups: alt.technology.smartcards Date: Fri, 30 Nov 2001 17:37:38 GMT"Rob Hrehor" writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: NCP Newsgroups: bit.listserv.ibm-main Date: Sat, 01 Dec 2001 16:07:47 GMT"John S. Giltner, Jr." writes:
there were a couple shops that only needed to be connected 20-30 minutes per day and they wanted to switch to using dialed-lines for those locations.
1) the terminals required a new microcode load which only worked with a new NCP load
2) so then they had to load all the 37xxs with a new NCP load which only worked with a new VTAM
3) so then they had to generate new VTAMs which only worked with a new MVS level
4) so they had to have a new level MVS
many of the above had serious incompatibility impacts on other applications they happened to be using.
first couple of times they tried the above ... it took a couple days elapsed down time and there were problems which then required them to effectively back-off everything (which also took a couple days outage).
they eventually got it all together but it may have taken a year ... and this was all standard ibm supplied code & systems.
older 37xxs used uc.5 processor ... same used in 8100, service processor for 3081, a number of other things. is it a real 37xx or a clone?
For instance, there was a package written for S/1 that did both NCP &
SSCP (PU4/PU5) emulation (and used a channel attach card to do 37xx
emulation to mainframe):
https://www.garlic.com/~lynn/99.html#70
https://www.garlic.com/~lynn/99.html#67
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: TSS/360 Newsgroups: alt.os.multics,alt.folklore.computers Date: Sat, 01 Dec 2001 16:27:57 GMTcbbrowne writes:
keykos
http://www.cis.upenn.edu/~KeyKOS
https://web.archive.org/web/20020801235154/www.cis.upenn.edu/~KeyKOS/
misc. pieces from above:
U.S. Patent 4,584,639 - Covering the KeyKOS "Factory" The infamous
(and much lamented - at least by me) "Factory Patent", covering the
mechanism for secure sharing of programs among mutually suspicious
users.
===
The Confused Deputy (1988)
Sometimes program must run under a combination of authorities. This
leads to obscure bugs and security holes. This paper identifies the
cause of the problem, and points out some solutions. The paper is also
available in postscript form.
===
derivative work for intel platform
http://www.cis.upenn.edu/~eros/ EROS: The Extremely Reliable Operating System
random gnosis/keykos refs:
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?
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: OCO Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 01 Dec 2001 21:09:25 GMTFarleyP@BIS.ADP.COM (Farley, Peter x23353) writes:
There is even stronger statement ... a large precentage wouldn't even exist at all because they weren't written by IBM development, they were written at/by various and sundry IT shops (customer, customer w/ibm field help, ibm field at customer shop, and/or internal).
HASP ... which became JES2 ASP ... which became JES3 CICS .. was at university and had to do source debugging of original CICS beta-test ... which IBM had picked at customer site. IMS CP/67 ... ...
aka a whole slew of standard IBM pieces that wouldn't exist. It fact, there use to be a joke about IBM development not doing development ... that things were developed elsewhere and then turned over to IBM development for long-term maintenance & support.
A lot of the HASP/JES2 networking source code had the characters "TUCC" out just before col. 71.
Then there is story about one of the exectuives leaving STL for BofA ... where he eventually had more people doing (core) DBMS development than STL had doing database development.
There is the other story about some agency wanting ALL the EXACT source code for the MVS system that was running (a compile/build of the source would result in an exact binary match). IBM spent several million dollars studying whether it was even possible before giving up and telling them no.
OCO impacts the issue of customer having a choice of spending the money for quick raction teams on business critical services (dedicated in-house teams for severity one situtions). IBM has managed to subject itself to this in a couple cases ... logoing some other vendor's product with only OCO provisions. IBM takes a severity one from its customers ... and then its service people waiting weeks while the original vendor processes the severity one. The argument that IBM would use with the vendor about allowing IBM service people to have source and work on the problem ... is identical to the argument large customers with business critical services would use to IBM.
discussion about forcing implementation into (interpreted) REXX as a
way of side-stepping the OCO issue (aka forcing source to be shipped):
https://www.garlic.com/~lynn/94.html#11 REXX
misc. other OCO discussion
https://www.garlic.com/~lynn/2001e.html#6 Blame it all on Microsoft
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Author seeks help - net in 1981 Newsgroups: alt.folklore.computers,bit.listserv.ibm-main Date: Sun, 02 Dec 2001 00:18:25 GMTLars Poulsen writes:
Most of the internal network was VNET rather than JES2/HASP ... with JES2/HASP somewhat relagated to perifrial ... frequently with specially constructed VNET nodes between them and the rest of the network so any JES2/HASP network header information could be sanitized (both in-coming and out-going) ... aka effectively the base VNET code had the equivalent of gateway support in every node ... and that capability could be used to "clean" JES2/HASP network headers.
The problem was that JES2/HASP network headers tended to be version and release specific. In a large network, with lots of different JES2/HASP nodes at different verstion and release levels resulted in numerous instances of JES2/HASP receiving systems taking down the whole computer complex. After several instances of that, it became very common to always have JES2/HASP nodes hidden behind VNET nodes which would make sure all incoming and outgoing JES2/HASP header information was reformated to avoid system crashes.
The internal VNET implementation was supposedly never going to be announced and released ... but there was some internal politiking that eventually resulted in a decision for a joint VNET/JES2 networking announcement and availability (of course VNET had to have a full suite of JES2 drivers ... in addition to its own native drivers). Leading into that was long arguments with the JES2 group about needing support for greater than 170 or so nodes ... but the corporate decision was that the internal network would be the only network that would ever have more than that many nodes ... and so it wasn't needed for a product distributed to customers.
Note however, by the time of VNET/JES2 networking customer availability, the internal network was well over 255 nodes (and lack of greater than 255 nodes support had serious impacts on internal network operations, estimated that just internal incremental costs for mitigating JES2 node-limit restriction was well in excess of the development costs to have supported greater than 255 nodes). Eventually the decision was made to expand JES2 support to 999 nodes. Hhowever by the time the general availability of 999 node support, the internal network was in excess of 1000 nodes.
internet network 1000th node ref
https://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes
https://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes
random internal network refs
https://www.garlic.com/~lynn/94.html#31 High Speed Data Transport (HSDT)
https://www.garlic.com/~lynn/95.html#7 Who built the Internet? (was: Linux/AXP.. Reliable?)
https://www.garlic.com/~lynn/97.html#2 IBM 1130 (was Re: IBM 7090--used for business or science?)
https://www.garlic.com/~lynn/97.html#26 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#16 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#56 Earliest memories of "Adventure" & "Trek"
https://www.garlic.com/~lynn/99.html#7 IBM S/360
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#38c Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#83 "Adventure" (early '80s) who wrote it?
https://www.garlic.com/~lynn/99.html#109 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/99.html#113 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/99.html#126 Dispute about Internet's origins
https://www.garlic.com/~lynn/99.html#212 GEOPLEX
https://www.garlic.com/~lynn/2000.html#3 Computer of the century
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000b.html#67 oddly portable machines
https://www.garlic.com/~lynn/2000b.html#72 Microsoft boss warns breakup could worsen virus problem
https://www.garlic.com/~lynn/2000c.html#30 internal corporate network, misc.
https://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#60 Disincentives for MVS & future of MVS systems programmers
https://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems
https://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
https://www.garlic.com/~lynn/2000e.html#13 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#30 Is Tim Berners-Lee the inventor of the web?
https://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
https://www.garlic.com/~lynn/2000g.html#17 IBM's mess (was: Re: What the hell is an MSX?)
https://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
https://www.garlic.com/~lynn/2000g.html#39 Could CDR-coding be on the way back?
https://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
https://www.garlic.com/~lynn/2000g.html#53 Egghead cracked, MS IIS again
https://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
https://www.garlic.com/~lynn/2001.html#46 Small IBM shops
https://www.garlic.com/~lynn/2001b.html#16 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
https://www.garlic.com/~lynn/2001c.html#4 what makes a cpu fast
https://www.garlic.com/~lynn/2001c.html#5 what makes a cpu fast
https://www.garlic.com/~lynn/2001c.html#75 CNN reports...
https://www.garlic.com/~lynn/2001e.html#12 Blame it all on Microsoft
https://www.garlic.com/~lynn/2001e.html#16 Pre ARPAnet email?
https://www.garlic.com/~lynn/2001e.html#34 Blame it all on Microsoft
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/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#13 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#34 D
https://www.garlic.com/~lynn/2001h.html#65 UUCP email
https://www.garlic.com/~lynn/2001i.html#7 YKYGOW...
https://www.garlic.com/~lynn/2001i.html#32 IBM OS Timeline?
https://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
https://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
https://www.garlic.com/~lynn/2001j.html#26 Help needed on conversion from VM to OS390
https://www.garlic.com/~lynn/2001j.html#28 Title Inflation
https://www.garlic.com/~lynn/2001j.html#29 Title Inflation
https://www.garlic.com/~lynn/2001j.html#30 Title Inflation
https://www.garlic.com/~lynn/2001j.html#35 Military Interest in Supercomputer AI
https://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001j.html#50 Title Inflation
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#56 E-mail 30 years old this autumn
https://www.garlic.com/~lynn/2001l.html#25 mainframe question
https://www.garlic.com/~lynn/2001l.html#34 Processor Modes
https://www.garlic.com/~lynn/2001l.html#35 Processor Modes
https://www.garlic.com/~lynn/2001l.html#45 Processor Modes
https://www.garlic.com/~lynn/2001m.html#54 Author seeks help - net in 1981
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Unpacking my 15-year old office boxes generates memory refreshes Newsgroups: alt.sys.pdp10,alt.folklore.computers Date: Sun, 02 Dec 2001 16:20:22 GMTjmfbahciv writes:
1) overtime meal allowance ... something like $2.50 (early '70s) for 2hrs over standard 8hr work day and $2.50 for each 4hrs on non-standard workday or over 1st extra 2hrs on standard workday (wasn't overtime pay or anything, but it slightly covered the aggravation of filling in the cards). with home 2741 and dial-up line to work ... morning, evenings and weekends on home-terminal counted.
2) for each 4hr either over standard 8hr day or on non-standard work day ... got a 1/2 day of "comp time" (effectively compensation time off ... right in there with vacation time ... this was before such things evaporated if you didn't use them). I easily avg. 3-4 days of comp. time for each week worked.
i didn't want to fill in the time-cards ... but when they insisted, i faithfully filled in everything and applied for everything available. This went on for awhile and eventually they let it be known i could just sign the cards w/o having to fill in anything. After that, I would sign all accumulated cards about four times a year.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Security glossary available Newsgroups: comp.security.misc,alt.computer.security Date: Mon, 03 Dec 2001 15:34:36 GMTa couple at
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Replace SNA communication to host with something else Newsgroups: bit.listserv.ibm-main Date: Mon, 03 Dec 2001 20:47:35 GMTfane_bursuc@YAHOO.COM (Fane Bursuc) writes:
1) initial address resolution ... do you need DNS and multi-homed host support. Will your connection implementation support multi A-record.
2) various kinds of fall-over and/or take-over support in case of hardware outages
3) TCP session setup overhead.
note while HTTP/web runs over TCP which has reliable transmission .... it was a battle to get some of the browser vendors to implement multi-A record support for availability support
also while HTTP/web runs over TCP ... TCP is a session oriented protocol, not a transaction oriented protocol .... there is minimum 7-packet exhange for HTTP operation with TCP (session setup/tear-down/etc). this issue can represent real performance issue unless you are tunneling transactions within a long-term TCP session). The other approach is one of the reliable transaction protocols that run over IP.
for instance,
https://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#) (in the section RFCs listed by
then scroll down to "transactions" for list of transaction oriented internet standards documents.
random other refs:
https://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
https://www.garlic.com/~lynn/99.html#0 Early tcp development?
https://www.garlic.com/~lynn/99.html#16 Old Computers
https://www.garlic.com/~lynn/99.html#111 The Translate (TR) instruction
https://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#207 Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2000.html#81 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#5 "Mainframe" Usage
https://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
https://www.garlic.com/~lynn/2000b.html#45 OSA-Express Gigabit Ethernet card planning
https://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2001b.html#11 Review of the Intel C/C++ compiler for Windows
https://www.garlic.com/~lynn/2001b.html#57 I am fed up!
https://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#78 Unix hard links
https://www.garlic.com/~lynn/2001d.html#49 VTOC position
https://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?
https://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
https://www.garlic.com/~lynn/2001e.html#34 Blame it all on Microsoft
https://www.garlic.com/~lynn/2001g.html#15 Extended memory error recovery
https://www.garlic.com/~lynn/2001h.html#13 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
https://www.garlic.com/~lynn/2001k.html#56 E-mail 30 years old this autumn
https://www.garlic.com/~lynn/2001k.html#62 SMP idea for the future
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/subnetwork.html#xtphsp OSI and High Speed Protocol
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Movies with source code (was Re: Movies with DEC minis) Newsgroups: alt.folklore.computers Date: Wed, 05 Dec 2001 00:49:18 GMTgeoffm@spam.hormel.com ("Geoff McCaughan") writes:
random refs:
https://www.garlic.com/~lynn/2000.html#14 Computer of the century
https://www.garlic.com/~lynn/2000g.html#36 stupid user stories
https://www.garlic.com/~lynn/2001e.html#66 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
https://www.garlic.com/~lynn/99.html#9 IBM S/360
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: CM-5 Thinking Machines, Supercomputers Newsgroups: comp.arch Date: Wed, 05 Dec 2001 05:16:58 GMTRandy Crawford writes:
I thot PILOT OLAP came out of TMC ... they were down the street. I tried to do some work with them in the mid-90s ... but while the queries were parallelized ... loading data was sequential and I also needed fairly significant parallelized loading (which looked to be possibly a 30% hit to the code base).
Looking for them just now the domain is still active
http://www.pilotsw.com/
but it takes a bit of searching to find PILOT.
totally random refs:
https://www.garlic.com/~lynn/2000d.html#64 "all-out" vs less aggressive designs
https://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs
https://www.garlic.com/~lynn/2001c.html#67 What ever happened to WAIS?
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Call for folklore - was Re: So it's cyclical. Newsgroups: alt.folklore.computers Date: Wed, 05 Dec 2001 16:04:51 GMTjmfbahciv writes:
vm/370 (micro-)kernel ... which started out following almost a microcode hardware methodology ... eventually grew bloated and ungainly with the care from people trained in traditional operating system approach.
hardware/micro-kernel approach typically had a strategic/architecture that was tightly adhered to. both compiler and operating system approaches can have tatical/design issues ... but they rarely maintain strong consistency with overall strategic/architecture objectives leading to all kinds of bloat and inefficiencies over multi-year (tens of years) periods.
random ref:
https://www.garlic.com/~lynn/2001m.html#53 TSS/360
https://www.garlic.com/~lynn/2001l.html#25 mainframe question
& my body/strategic thinking refs:
https://www.garlic.com/~lynn/subboyd.html#boyd
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Virus: Emails sent with no message body and _ prefixed to email address Newsgroups: comp.mail.eudora.ms-windows Date: Wed, 05 Dec 2001 18:09:46 GMTann@asarian-host.net (Ann) writes:
mail clients will "see" everything ... the issue is whether or not it is enabled for special processing for the stuff it "sees" and how it is instructed to present what it "sees".
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Virus: Emails sent with no message body and _ prefixed to email address Newsgroups: comp.mail.eudora.ms-windows Date: Wed, 05 Dec 2001 20:55:34 GMTAnne & Lynn Wheeler writes:
MIME BinHex Uuencode
you can run a email client that totally turns off all encoding methods and so everything is treated as straight text stream.
most common encoding method for mail clients to recognize/separate "attachments" and/or to use special formating is
MIME
for list of internet standards & documents related to MIME standard ... goto
https://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#) and then select "MIME" from the Acronym fastpath.
various email clients in addtion to having support for the splitting a single mail into multiple different objects and possibly having various displaying rules for different kinds of objects ... may also have rules regarding execution/scripting for specific kinds of objects.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Unpacking my 15-year old office boxes generates memory refreshes Newsgroups: alt.sys.pdp10,alt.folklore.computers Date: Wed, 05 Dec 2001 22:14:57 GMTCharles Richmond writes:
also couple mugs from DLI in monterey that had some russian on one side ... and one the other was ...
which were subject to somebody's midnight requisition
the all time best coffee mug story was my brother; a regional (several state) marketing rep for a Apple reseller (eventually bought by apple, rainbow). he would fawn over coffee mugs from other vendors at customer shops ... and beg to trade them to him for his old apple mugs (and then toss them in the trash).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hercules, OCO, and IBM missing a great opportunity Newsgroups: bit.listserv.ibm-main Date: Fri, 07 Dec 2001 15:41:47 GMTpinnacle@FRONTIERNET.NET (Thomas Conley) writes:
i've also seen some institutional risk analysis that their number #1 threat is ibm mainframe critical resources that have been around for 30 years, their mortgage is paid off, their kids are thru college, and they could retire at any momemnt ... and even tho the ibm mainframe solution is more productive and cost/effective ... they have a serious business continuity issue.
previous postings on the subject
https://www.garlic.com/~lynn/2000.html#28 Homework: Negative side of MVS?
https://www.garlic.com/~lynn/2000.html#32 Homework: Negative side of MVS?
https://www.garlic.com/~lynn/2000f.html#11 Amdahl Exits Mainframe Market
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Alpha vs. Itanic: facts vs. FUD Newsgroups: comp.arch Date: Sat, 08 Dec 2001 20:43:42 GMT"Bill Todd" writes:
misc. discussion
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2001m.html#47 TSS/360
random refs:
https://www.garlic.com/~lynn/96.html#16 middle layer
https://www.garlic.com/~lynn/96.html#30 interdata and perkin/elmer
https://www.garlic.com/~lynn/96.html#37 interdata & perkin/elmer machines
https://www.garlic.com/~lynn/96.html#39 Mainframes & Unix
https://www.garlic.com/~lynn/99.html#12 Old Computers
https://www.garlic.com/~lynn/99.html#63 System/1 ?
https://www.garlic.com/~lynn/99.html#66 System/1 ?
https://www.garlic.com/~lynn/99.html#67 System/1 ?
https://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
https://www.garlic.com/~lynn/2000.html#64 distributed locking patents
https://www.garlic.com/~lynn/2000.html#71 Mainframe operating systems
https://www.garlic.com/~lynn/2000.html#76 Mainframe operating systems
https://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000b.html#49 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#66 oddly portable machines
https://www.garlic.com/~lynn/2000b.html#87 Motorola/Intel Wars
https://www.garlic.com/~lynn/2000c.html#36 Interdata, Perkin-Elmer, et al.
https://www.garlic.com/~lynn/2000c.html#37 Interdata, Perkin-Elmer, et al.
https://www.garlic.com/~lynn/2000c.html#43 Any Series/1 fans?
https://www.garlic.com/~lynn/2000c.html#53 Any Series/1 fans?
https://www.garlic.com/~lynn/2000c.html#54 WHAT IS A MAINFRAME???
https://www.garlic.com/~lynn/2000c.html#80 Unisys vs IBM mainframe comparisons
https://www.garlic.com/~lynn/2000c.html#81 Unisys vs IBM mainframe comparisons
https://www.garlic.com/~lynn/2000f.html#6 History of ASCII (was Re: Why Not! Why not???)
https://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
https://www.garlic.com/~lynn/2001.html#5 Sv: First video terminal?
https://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
https://www.garlic.com/~lynn/2001.html#62 California DMV
https://www.garlic.com/~lynn/2001.html#65 California DMV
https://www.garlic.com/~lynn/2001.html#68 California DMV
https://www.garlic.com/~lynn/2001.html#72 California DMV
https://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
https://www.garlic.com/~lynn/2001b.html#75 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#49 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001d.html#34 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001d.html#35 Imitation...
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001e.html#53 Pre ARPAnet email?
https://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
https://www.garlic.com/~lynn/2001f.html#30 IBM's "VM for the PC" c.1984??
https://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984??
https://www.garlic.com/~lynn/2001f.html#42 Golden Era of Compilers
https://www.garlic.com/~lynn/2001f.html#44 Golden Era of Compilers
https://www.garlic.com/~lynn/2001f.html#48 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001g.html#30 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#32 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001h.html#50 Flip the bits in a byte
https://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
https://www.garlic.com/~lynn/2001l.html#8 mainframe question
https://www.garlic.com/~lynn/2001l.html#43 QTAM (was: MVS History)
https://www.garlic.com/~lynn/2001l.html#44 QTAM (was: MVS History)
https://www.garlic.com/~lynn/2001n.html#9 NCP
https://www.garlic.com/~lynn/2001n.html#15 Replace SNA communication to host with something else
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Alpha vs. Itanic: facts vs. FUD Newsgroups: comp.arch Date: Sun, 09 Dec 2001 15:47:47 GMTTerje Mathisen writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Unpacking my 15-year old office boxes generates memory refreshes Newsgroups: alt.sys.pdp10,alt.folklore.computers Date: Sun, 09 Dec 2001 18:01:05 GMTTim Shoppa writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Open Architectures ? Newsgroups: comp.arch Date: Sun, 09 Dec 2001 18:15:43 GMTcecchi@signa.rchland.ibm.com (Del Cecchi) writes:
On the other hand ... CP/67 and VM/370 shipped with source maintanence (not only standard release shipped with source, but monthly tapes sent to customers with fixes and updates in source).
this was so prevalent that at one point there was some assesement that there was more kernel source code available on the Share "waterloo" tape than in the standard delivered system. On the other hand ... it was so easy to bloat the kernel with stuff ... that a lot of stuff got put into it that it could hardly be called a micro-kernel anymore (in some sense the "hardware" microcode supporting "LPARS" is closer to the original CP kernel than the current software is).
recent refs:
https://www.garlic.com/~lynn/2001n.html#18 Call for folklore - was Re: So it's cyclical.
https://www.garlic.com/~lynn/2001m.html#53 TSS/360
https://www.garlic.com/~lynn/2001l.html#25 mainframe question
random postings:
https://www.garlic.com/~lynn/94.html#11 REXX
https://www.garlic.com/~lynn/94.html#42 bloat
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#44 bloat
https://www.garlic.com/~lynn/94.html#50 Rethinking Virtual Memory
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/95.html#2 Why is there only VM/370?
https://www.garlic.com/~lynn/97.html#12 OSes commerical, history
https://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
https://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
https://www.garlic.com/~lynn/99.html#9 IBM S/360
https://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#175 amusing source code comments (was Re: Testing job applicants)
https://www.garlic.com/~lynn/99.html#199 amusing source code comments (was Re: Testing job applicants)
https://www.garlic.com/~lynn/subpubkey.html#mainframe Mainframe related postings (1993-2000)
https://www.garlic.com/~lynn/subindex.html#all Collected subjects (1993-2000)
https://www.garlic.com/~lynn/subindx2.html#mainframe Mainframe related postings (2001-)
https://www.garlic.com/~lynn/subindx2.html#all Current Collected subjects (2001-)
https://www.garlic.com/~lynn/subtopic.html#wsclock Working Set, LRU, WSClock Page Replacement Algorithm
https://www.garlic.com/~lynn/subtopic.html#fairshare Performance and/or Scheduling
https://www.garlic.com/~lynn/subnetwork.html#hsdt HSDT and/or HYPERchannel
https://www.garlic.com/~lynn/submain.html#mmap Memory Map
https://www.garlic.com/~lynn/subtopic.html#hone APL and/or HONE
https://www.garlic.com/~lynn/2000.html#8 Computer of the century
https://www.garlic.com/~lynn/2000.html#63 Mainframe operating systems
https://www.garlic.com/~lynn/2000.html#86 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#32 20th March 2000
https://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000c.html#8 IBM Linux
https://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000d.html#41 TCP/IP Suite of Protocols - dumb question ...
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
https://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2001.html#34 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
https://www.garlic.com/~lynn/2001b.html#72 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#8 Server authentication
https://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#5 SIMTICS
https://www.garlic.com/~lynn/2001e.html#57 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
https://www.garlic.com/~lynn/2001e.html#61 Estimate JCL overhead
https://www.garlic.com/~lynn/2001e.html#71 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
https://www.garlic.com/~lynn/2001f.html#5 Emulation (was Re: Object code (was: Source code - couldn't resist compiling it :-))
https://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
https://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#22 Golden Era of Compilers
https://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
https://www.garlic.com/~lynn/2001h.html#16 D
https://www.garlic.com/~lynn/2001h.html#24 "Hollerith" card code to EBCDIC conversion
https://www.garlic.com/~lynn/2001h.html#33 D
https://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001j.html#33 Big black helicopters
https://www.garlic.com/~lynn/2001k.html#24 HP Compaq merger, here we go again.
https://www.garlic.com/~lynn/2001l.html#14 mainframe question
https://www.garlic.com/~lynn/2001l.html#24 mainframe question
https://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
https://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
https://www.garlic.com/~lynn/2001m.html#52 Author seeks help - net in 1981
https://www.garlic.com/~lynn/2001n.html#11 OCO
https://www.garlic.com/~lynn/2001n.html#16 Movies with source code (was Re: Movies with DEC minis)
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Unpacking my 15-year old office boxes generates memory refreshes Newsgroups: alt.sys.pdp10,alt.folklore.computers Date: Sun, 09 Dec 2001 20:57:17 GMTTim Shoppa writes:
at the time some things that people listed as osi issues
1) '50s telco copper thot, high error rates, and effectively little or no computerized operations, no FEC, etc.
2) contrasted to ietf ... iso/osi didn't require working interoperable implementations ... people could conjecture nearly anything for a standard
3) numerous people stating that all 7 layers had to be implemented as spec'ed along with all the inter-layer interfaces.
by the mid-80s ... with wide-spread deployment of LANs appearing ... OSI was already out of date. The standard LAN model effectively collapsed levels 1, 2, and a part of 3 (networking) all into a single entity. LANs didn't implement all of the OSI network layer ... but implemented a part so the interface didn't correspond to the OSI spec layering (i.e. placing a MAC address on a packet and sending it on the wire was lower than the layer 3/4 interface ... but above the layer 2/3 interface).
ANSI x3s3 was the US standards body for network/transport (level 3/4) protocols. There was some battling with regard to high speed protocol ... because there was a large contingent that observed the "rule" that a protocol work item couldn't be proposed that didn't correspond to the OSI model.
random refs:
https://www.garlic.com/~lynn/subnetwork.html#hsdt
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Unpacking my 15-year old office boxes generates memory refreshes Newsgroups: alt.sys.pdp10,alt.folklore.computers Date: Sun, 09 Dec 2001 21:09:59 GMTTim Shoppa writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Open Architectures ? Newsgroups: comp.arch Date: Sun, 09 Dec 2001 21:05:31 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
ibm spent less than $10m researching the problem (solution?) before deciding that it wasn't practical.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FreeBSD more secure than Linux Newsgroups: comp.security.unix Date: Mon, 10 Dec 2001 17:05:34 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
misc. ha/cmp refs:
https://www.garlic.com/~lynn/subtopic.html#hacmp
random buffer overflow refs:
https://www.garlic.com/~lynn/99.html#98 Early interupts on mainframes
https://www.garlic.com/~lynn/99.html#163 IBM Assembler 101
https://www.garlic.com/~lynn/99.html#219 Study says buffer overflow is most common security bug
https://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/2000.html#25 Computer of the century
https://www.garlic.com/~lynn/2000.html#30 Computer of the century
https://www.garlic.com/~lynn/2000.html#87 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#22 ooh, a real flamewar :)
https://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
https://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
https://www.garlic.com/~lynn/2001d.html#58 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce
https://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hercules etc. IBM not just missing a great opportunity... Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 10 Dec 2001 18:31:31 GMTrhawkins@SINGNET.COM.SG (Ron & Jenny Hawkins) writes:
gml and script were done at the cambridge science center in the 60s (same place did cp/67, vm/370, cms, lots of the early performance predictor, scheduling, and early work for transition from performance tuning to capacity planning, internal network, basis for the field HONE system, editors, smp compare&swap instruction, basis for today's LPARs, lot of the early ibm virtual memory work, etc).
random 6670, script. gml refs:
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/96.html#24 old manuals
https://www.garlic.com/~lynn/97.html#9 HELP! Chronology of word-processing
https://www.garlic.com/~lynn/97.html#26 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#16 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/99.html#42 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#43 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#91 Documentation query
https://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2000.html#8 Computer of the century
https://www.garlic.com/~lynn/2000.html#34 IBM 360 Manuals on line ?
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000c.html#30 internal corporate network, misc.
https://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems
https://www.garlic.com/~lynn/2000d.html#81 Coloured IBM DASD
https://www.garlic.com/~lynn/2000e.html#0 What good and old text formatter are there ?
https://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ?
https://www.garlic.com/~lynn/2000e.html#23 Is Tim Berners-Lee the inventor of the web?
https://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
https://www.garlic.com/~lynn/2001c.html#88 Unix hard links
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?
https://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#54 DSRunoff; was Re: TECO Critique
https://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#34 D
https://www.garlic.com/~lynn/2001h.html#46 Whom Do Programmers Admire Now???
https://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#16 Disappointed
https://www.garlic.com/~lynn/2001l.html#20 mainframe question
https://www.garlic.com/~lynn/2001l.html#24 mainframe question
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
misc. cambridge refs:
https://www.garlic.com/~lynn/subtopic.html#545tech
misc. hone refs:
https://www.garlic.com/~lynn/subtopic.html#hone
misc. smp refs:
https://www.garlic.com/~lynn/subtopic.html#smp
misc. virtual memory refs:
https://www.garlic.com/~lynn/subtopic.html#wsclock
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hercules etc. IBM not just missing a great opportunity... Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 10 Dec 2001 18:37:04 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FreeBSD more secure than Linux Newsgroups: comp.security.unix Date: Mon, 10 Dec 2001 20:26:30 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hercules etc. IBM not just missing a great opportunity... Newsgroups: bit.listserv.ibm-main Date: Mon, 10 Dec 2001 22:32:11 GMTSEYMOUR.J.METZ@CUSTOMS.TREAS.GOV (Shmuel Metz , Seymour J.) writes:
random refs:
https://www.garlic.com/~lynn/96.html#16 middle layer
https://www.garlic.com/~lynn/96.html#17 middle layer
https://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
https://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#19 HP Compaq merger, here we go again.
https://www.garlic.com/~lynn/2001l.html#17 mainframe question
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic: facts vs. FUD
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: cc SMP Newsgroups: comp.arch Date: Mon, 10 Dec 2001 22:41:27 GMTKetil Z Malde writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Movies with source code (was Re: Movies with DEC minis) Newsgroups: alt.folklore.computers Date: Tue, 11 Dec 2001 05:10:48 GMTgcash writes:
"G", "M", & "L" had offices down the hall (4th floor, 545 tech sq) aka GML was selected because it is the last name initials of the three people that worked on it (30-odd years ago)
CERN was a big VM/CMS, GML, etc installation ... prior to there being a SGML & for over 15 years before there was an HTML.
random refs:
https://www.garlic.com/~lynn/94.html#11 REXX
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/96.html#24 old manuals
https://www.garlic.com/~lynn/97.html#9 HELP! Chronology of word-processing
https://www.garlic.com/~lynn/97.html#10 HELP! Chronology of word-processing
https://www.garlic.com/~lynn/97.html#26 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#16 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/99.html#42 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#43 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#91 Documentation query
https://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2000.html#8 Computer of the century
https://www.garlic.com/~lynn/2000.html#34 IBM 360 Manuals on line ?
https://www.garlic.com/~lynn/2000.html#82 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#32 20th March 2000
https://www.garlic.com/~lynn/2000c.html#30 internal corporate network, misc.
https://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems
https://www.garlic.com/~lynn/2000e.html#0 What good and old text formatter are there ?
https://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ?
https://www.garlic.com/~lynn/2000e.html#23 Is Tim Berners-Lee the inventor of the web?
https://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
https://www.garlic.com/~lynn/2001c.html#88 Unix hard links
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?
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/2001g.html#24 XML: No More CICS?
https://www.garlic.com/~lynn/2001g.html#54 DSRunoff; was Re: TECO Critique
https://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#19 checking some myths.
https://www.garlic.com/~lynn/2001h.html#34 D
https://www.garlic.com/~lynn/2001h.html#46 Whom Do Programmers Admire Now???
https://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#7 YKYGOW...
https://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#16 Disappointed
https://www.garlic.com/~lynn/2001l.html#20 mainframe question
https://www.garlic.com/~lynn/2001l.html#24 mainframe question
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
https://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hercules etc. IBM not just missing a great opportunity... Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 11 Dec 2001 16:45:14 GMTzberger@KNOLOGY.NET (Joe Zitzelberger) writes:
CERN was a long time CMS (& gml) user. There is the infamous 1974 CERN TSO/CMS comparison study that was made available at SHARE ... but copies inside IBM were labeled Confidential, Restricted (i.e. available on a need to know basis only).
There is also some lore that the original MS-DOS filesystem was a stripped down, simplified CMS filesystem (although preserving some of the same conventions).
Even within stricly OS-world there were a number of CRJE type implementations many of them better done than TSO ... I even did a hack as an undergraduate ... implementing CMS editor syntax in HASP on a MVTR18 base with 2741 & ASCII TTY support (predating TSO).
random refs:
https://www.garlic.com/~lynn/2001n.html#1
https://www.garlic.com/~lynn/2001n.html#32
https://www.garlic.com/~lynn/2001n.html#36
https://www.garlic.com/~lynn/subtopic.html#545tech
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Computer Typesetting Was: Movies with source code Newsgroups: alt.folklore.computers Date: Wed, 12 Dec 2001 16:31:34 GMTjsavard@ecn.aSBLOKb.caNADA.invalid (John Savard) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: 195 was: Computer Typesetting Was: Movies with source code Newsgroups: alt.folklore.computers,bit.listserv.ibm-main Date: Wed, 12 Dec 2001 19:43:15 GMTjsavard@ecn.aSBLOKb.caNADA.invalid (John Savard) writes:
pasc had a 145 that was around 1/30th the 195 peak thruput ... so they eventually discovered that running the application on the 145 (in background since it was pretty heavily loaded first shift with interactive workload) that they would get slightly better turn-around than on the 195. I would guess that application was one of the reasons that randy did the fortan q/hx optimization work (he was also responsible for the 145 apl microcode assist).
another application that was trying to get turn-around on the sjr 195 was the thin-film (floating) disk head "air-bearing" simulation (designing the head so would reliably float).
we had done some work on i/o supervisors for the bldg. (eingeering) 14 & (product test) 15 machine so that they could run an operating system on machines used for (multiple) disk test cell operations (MVS mean-time to failure just operating a single test cell was on the order of 15 mintues).
random ref:
https://www.garlic.com/~lynn/subtopic.html#disk
bldg. 14 & 15 machine rooms tended to get the 3rd or 4th processor of a new machine (the processor engineers would get the first couple ... and then the disk & controller engineers would get the next couple ... so disk/controller operation can be tested and certified). Bldg. 15 got a 4341 before any of the software groups:
random ref:
https://www.garlic.com/~lynn/2000d.html#0
Bldg. 15 also got one of the first 3033s. Even with multiple test cells operating, cpu utilization (with the above reference operating system work) rarely hit one or two percent. So as a public service, we would arrainge for some of our friends to run selected applications on these otherwise idle (from cpu perspective) hardware test machines. One of these to get special consideration was the air-bearing simulation program. 3033 had possible 1/2 the 195 peak thruput (so a highly optimized 195 program would take twice as long on 3033). Note however, very few programs and applications actually would hit 195 peak thruput (195 pipeline was easily stalled/drained) ... and so nominal 195 thruput was actually much closer to 3033 thutput.
random 3033 & 195 refs:
https://www.garlic.com/~lynn/93.html#14 S/360 addressing
https://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
https://www.garlic.com/~lynn/94.html#38 IBM 370/195
https://www.garlic.com/~lynn/94.html#39 IBM 370/195
https://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
https://www.garlic.com/~lynn/96.html#24 old manuals
https://www.garlic.com/~lynn/97.html#20 Why Mainframes?
https://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#7 IBM S/360
https://www.garlic.com/~lynn/99.html#73 The Chronology
https://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
https://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
https://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/99.html#187 Merced Processor Support at it again . . .
https://www.garlic.com/~lynn/99.html#188 Merced Processor Support at it again . . .
https://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again . . .
https://www.garlic.com/~lynn/99.html#195 Anti trust suits--IBMs' compared to Microsoft
https://www.garlic.com/~lynn/99.html#209 Core (word usage) was anti-equipment etc.
https://www.garlic.com/~lynn/2000.html#2 Computer of the century
https://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
https://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
https://www.garlic.com/~lynn/2000c.html#35 What level of computer is needed for a computer to Love?
https://www.garlic.com/~lynn/2000c.html#38 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#44 WHAT IS A MAINFRAME???
https://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#21 S/360 development burnout?
https://www.garlic.com/~lynn/2000d.html#40 360 CPU meters (was Re: Early IBM-PC sales proj..
https://www.garlic.com/~lynn/2000d.html#61 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#21 Competitors to SABRE? Big Iron
https://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2000e.html#58 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2000f.html#13 Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?
https://www.garlic.com/~lynn/2000f.html#21 OT?
https://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
https://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
https://www.garlic.com/~lynn/2000g.html#18 360/370 instruction cycle time
https://www.garlic.com/~lynn/2000g.html#28 Could CDR-coding be on the way back?
https://www.garlic.com/~lynn/2000g.html#29 Could CDR-coding be on the way back?
https://www.garlic.com/~lynn/2001.html#48 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
https://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
https://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
https://www.garlic.com/~lynn/2001b.html#63 Java as a first programming language for cs students
https://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#1 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#27 Massive windows waisting time (was Re: StarOffice for free)
https://www.garlic.com/~lynn/2001g.html#22 Golden Era of Compilers
https://www.garlic.com/~lynn/2001g.html#56 YKYBHTLW....
https://www.garlic.com/~lynn/2001h.html#49 Other oddball IBM System 360's ?
https://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
https://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
https://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
https://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
https://www.garlic.com/~lynn/2001j.html#33 Big black helicopters
https://www.garlic.com/~lynn/2001j.html#35 Military Interest in Supercomputer AI
https://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
https://www.garlic.com/~lynn/2001l.html#32 mainframe question
https://www.garlic.com/~lynn/2001m.html#14 adventure ... nearly 20 years
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Google increase archive reach Newsgroups: alt.folklore.computers Date: Wed, 12 Dec 2001 20:43:31 GMTDave Daniels writes:
html originated at CERN ... and can trace heritage back thru VM/CMS & GML.
SLAC had very similar system operations as CERN ... also a big VM/CMS customer ... and very close ties.
slac home page:
http://www.slac.stanford.edu/
cern home page:
http://www.cern.ch/
booth at SC2001 in denver a couple weeks ago
http://sc2001.slac.stanford.edu/
sc2001 web page:
http://www.sc2001.org/
there was a contest one evening where booths were trying to demonstrate avg. sustained bandwidth between the floor booth and various installations around the world over an extended period of time. I didn't see the result but I believe they were in the 500mbyte/sec to 1gbyte/sec ranges.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 195 was: Computer Typesetting Was: Movies with source code Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 12 Dec 2001 20:48:06 GMThancock4@bbs.cpcn.com (Lisa nor Jeff) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Cache coherence [was Re: IBM POWER4 ...] Newsgroups: comp.arch Date: Wed, 12 Dec 2001 20:53:46 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 1800 Newsgroups: alt.folklore.computers Date: Thu, 13 Dec 2001 04:33:14 GMTHoward S Shubs writes:
some general places for ibm pubs
http://booksrv2.raleigh.ibm.com/
http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US
http://www.redbooks.ibm.com/
http://www.research.ibm.com/journal/
random pop & redbook references:
https://www.garlic.com/~lynn/97.html#19 Why Mainframes?
https://www.garlic.com/~lynn/98.html#18 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#20 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
https://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001b.html#55 IBM 705 computer manual
https://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?
https://www.garlic.com/~lynn/2001f.html#41 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001g.html#8 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001g.html#9 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
https://www.garlic.com/~lynn/2001m.html#39 serialization from the 370 architecture "red-book"
https://www.garlic.com/~lynn/2001m.html#51 Author seeks help - net in 1981
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PC/370 Newsgroups: comp.lang.asm370 Date: Thu, 13 Dec 2001 15:25:27 GMTAlistair Maclean writes:
detailed description of both instructions can be found in POP:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/CONTENTS?SHELF=
basically for going from EBCDIC->ASCII translation (TR) ... you need a 256-byte translate table that has an entry for every EBCDIC byte pattern which is filled in with the corresponding ASCII byte pattern (for instance, at +x'40' position in the table ... EBCDIC blank ... there needs to be the value for ASCII blank). ASCII->EBCDIC needs a separate table that gives the corresponding EBCDIC byte code for each ASCII value.
Note that some of translate tables are not for EBCDIC->ASCII ... but for "bit-reversed" ASCII. Long ago and far away, when I was an undergraduate a couple of us built our own ibm (terminal) controller (credited with originated the IBM plug-compatible controller business, built our own channel board by reverse engineering the ibm hardware channel protocol). The motivation was because of perceived difficency in the standard IBM 2702 controller. We ran into a momentary bump before we realized that the IBM line-scanner convention was to place the leading bit in the low-order bit position in a byte (while the ASCII convention was to place the leading bit in the high-order bit position in a byte). Effectively IBM line-scanners receiving (and sending) ASCII data bit-reversed the order of the bits in each byte. As a result, the corresponding translate tables had to account for the line-scanners reversing the bit ordering.
random refs:
https://www.garlic.com/~lynn/submain.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Valid reference on lunar mission data being unreadable? Newsgroups: alt.folklore.computers Date: Thu, 13 Dec 2001 15:38:46 GMTArargh! writes:
CMS ... was the Cambridge Monitoring System (later renamed Conversational Monitoring System) ... which was the end-user portion that went with CP/67 (and VM/370).
LLMPS would also be there someplace ... lincoln labs multiprograamming supersivor ... which lore has was the original basis for MTS ... michigan terminal/time-sharing system.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Blinking lights Newsgroups: alt.folklore.computers Date: Fri, 14 Dec 2001 16:40:43 GMTjmfbahciv writes:
random FS & ZM refs:
https://www.garlic.com/~lynn/96.html#24 old manuals
https://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
https://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists.
https://www.garlic.com/~lynn/2000.html#3 Computer of the century
https://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
https://www.garlic.com/~lynn/2000f.html#17 [OT] FS - IBM Future System
https://www.garlic.com/~lynn/2000f.html#18 OT?
https://www.garlic.com/~lynn/2000f.html#21 OT?
https://www.garlic.com/~lynn/2000f.html#27 OT?
https://www.garlic.com/~lynn/2000f.html#28 OT?
https://www.garlic.com/~lynn/2000f.html#30 OT?
https://www.garlic.com/~lynn/2000f.html#37 OT?
https://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000g.html#18 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001d.html#44 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001f.html#30 IBM's "VM for the PC" c.1984??
https://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984??
https://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
https://www.garlic.com/~lynn/2001g.html#36 What was object oriented in iAPX432?
https://www.garlic.com/~lynn/2001i.html#7 YKYGOW...
https://www.garlic.com/~lynn/2001l.html#25 mainframe question
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Sysplex Info Newsgroups: bit.listserv.ibm-main Date: Fri, 14 Dec 2001 16:51:05 GMTjohana@ROCKETMAIL.COM (JohanAA) writes:
misc ref:
https://www.garlic.com/~lynn/99.html#71 High Availability on S/390
random refs:
https://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The demise of compaq Newsgroups: comp.os.vms,comp.arch,comp.sys.intel Date: Fri, 14 Dec 2001 17:10:43 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
In a multiple step batch program ... there might be specific steps that effectively only created or destroyed files (datasets) but didn't actually need to execute any code (aka "DD" statements) ... but job step semantics required an EXEC statement specifying a program. IEFBR14 as a dummy program could be specified. However, subsequent job steps could test the condition code from the previous job step (which would be the aggregate of the condition from each of the DD statements and the EXEC statement). Subsequent job steps could check for aggregate successful (each zeros) condition code (the return code from the EXEC program execution plus the condition code from each DD statement).
random past iefbr14 postings
https://www.garlic.com/~lynn/99.html#81 Perfect Code
https://www.garlic.com/~lynn/99.html#85 Perfect Code
https://www.garlic.com/~lynn/99.html#96 IEFBR14 cookie from www.ibm.com
https://www.garlic.com/~lynn/2001e.html#60 Estimate JCL overhead
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PC/370 Newsgroups: comp.lang.asm370 Date: Fri, 14 Dec 2001 17:24:57 GMTSkippyPB writes:
This is based on the assmblers knowing the program load convention starts on a double word boundary (or maybe even a page boundary). The assembler believe that the program origin is (at least) a double word boundary then rounds up the displacement from the program origin to the appropriate boundary.
The downside is that the assembler might "short" the current TXT "card" and start a new TXT "card" at the appropriate displacement (where with CNOP it would continue laying down data/instructions using the current TXT card).
However, if it really is an early pc/370 ... with the motorola chip ... then there wouldn't have been word or double-word instruction operation optimizations (that you find in the higher-end 370 and later machines).
misc. discussions of assemble/compile output TXT records:
https://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)
https://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
https://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The demise of compaq Newsgroups: comp.os.vms,comp.arch,comp.sys.intel Date: Fri, 14 Dec 2001 22:12:01 GMTgherbert@gw.retro.com (George William Herbert) writes:
one of the "redos" in the late 80s/early 90s ... was focused on having (lots of) triple redundant independent hardware (cluster) effectively checking on each other. a problem that was uncovered was assumption that all failure modes are either hardware &/or operating system which using redudancy and/or other checking, all failures could be masked totally from the application. based on that assumption ... the ATC application itself didn't have to have failure-mode logic. The problem was that there were a number of business process or domain-specific failure modes ... like missing a hand-off from one regional to another which turned out had to be handled at the application level.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Weakest Link. Newsgroups: uk.media.tv.misc,alt.folklore.computers Date: Sat, 15 Dec 2001 12:22:39 GMTSteve O'Hara-Smith writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 9-track tapes (by the armful) Newsgroups: alt.folklore.computers Date: Sat, 15 Dec 2001 12:29:00 GMTJoe Pfeiffer writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A request for historical information for a computer education project Newsgroups: comp.lang.asm370,alt.folklore.computers Date: Sat, 15 Dec 2001 12:37:51 GMT"Phil Weldon" writes:
greencard scan currently "404"
http://users.ticnet.com/davea/greencard/start.htm
random card refs:
https://www.garlic.com/~lynn/98.html#14 S/360 operating systems geneaology
https://www.garlic.com/~lynn/99.html#11 Old Computers
https://www.garlic.com/~lynn/99.html#13 Old Computers
https://www.garlic.com/~lynn/2000b.html#6 ascii to binary
https://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001.html#69 what is interrupt mask register?
https://www.garlic.com/~lynn/2001.html#71 what is interrupt mask register?
https://www.garlic.com/~lynn/2001b.html#48 PC Keyboard Relics
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001e.html#21 High Level Language Systems was Re: computer books/authors (Re: FA:
https://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001h.html#24 "Hollerith" card code to EBCDIC conversion
https://www.garlic.com/~lynn/2001h.html#72 ummmmm
https://www.garlic.com/~lynn/2001l.html#24 mainframe question
https://www.garlic.com/~lynn/2001m.html#34 9-track tapes (by the armful)
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The demise of compaq Newsgroups: comp.arch Date: Sat, 15 Dec 2001 18:48:43 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
one study found that of the businesses that had disk failure (containing critical corporate assets) that weren't backed up ... half filed for bankruptcy within the first month.
a large aircraft manufactur investigating the disaster effects of say a volcanic mud flow would have on its computing center ... found that a one week outage of the computing center resulted in a loss to the corporate significant greater than the total aggregate cost of the computing center (so they replicated the data center outside the common disaster zone).
a small trading data center in a 50+ floor building ... was found that a 24 hr outage represented loss of revenue greater than the total year lease on the building plus total annual salary of all individuals working in the building.
one aircract company had converted to email for shipping orders for critical parts for aircraft-on-ground (i.e. part was needed before plane could fly). One of the viruses two years ago took out the corporate email for two weeks; during that period only a couple part orders shipped and planes were sitting on the ground.
the systemic risks of computer interconnect hasn't reached the point of the northeast powergrid failure ... or a couple of near misses that the international financial system had with evening settlement (cascading systemic failures that snowball ... basically severe negative feed-back w/o self-correcting/annealing features). There is the also the hedge fund failure ... greenspan had to call a sat. meeting of CFOs of ten large financial institutiones and told them that they had to cough up $300m each (for $3b aggregate) to cover the hedge fund problem or see the ripple effects thruout the economy.
One of my favorites is taking a 6am flight from san jose to boston with connection in chicago ... the plane was about to leave san jose ... but was held on the ground because of a 50 minute severe thunderstorm that went thru ohare ... cutting traffic by 50% for the period. The san jose flight took off an hour late. By the time we arrived in chicago ... the delays had propagated to nearly 4 hrs. Now we are talking about 60 minute 50% reduction during ohare rush hour ... or the equivalent of 30 service minutes. In theory, after rush hour ... there should have been available capacity at ohare to absorb the 30 minute service lost ... instead the problem snowballed & steadily increased during the day. The only saving grace seems to the midnight(?) to 5am airport shutdown ... w/o that enforced idle period ... it isn't clear that air traffic could every maintain stable equilibrium (because it is otherwise a highly optimized infrastructure that has no provisions for self-healing/correcting when glitches crop up; in fact it seems to be highly unstable).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 9-track tapes (by the armful) Newsgroups: alt.folklore.computers Date: Sat, 15 Dec 2001 22:37:28 GMT"Rupert Pigott" writes:
There was some observation that if the RS/6000 was to be totally restricted to using PS/2 MCA cards (video adapters, scsi adapters, lan adatpers, etc).... for possibly the majority of applications out there, the RS/6000 would run as slowly as a PS/2.
random refs:
https://www.garlic.com/~lynn/96.html#17 middle layer
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Certificate Authentication Issues in IE and Verisign Newsgroups: sci.crypt Date: Sat, 15 Dec 2001 21:49:49 GMT"Roger Schlafly" writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Certificate Authentication Issues in IE and Verisign Newsgroups: sci.crypt Date: Sat, 15 Dec 2001 22:27:28 GMT"Ursus Horibilis" writes:
with regard to SSL domain name certificates ... things get even more interesting.
certificates basically have an offline design point ... something out of the early '80s for operation w/offline email (aka you dial-up, download email, hang-up, and then process). The issue was with regard to having some sort of authentication credential that could work in an offline environment (analogous to letters of credit from the days of the sailing ship).
applying certificates to valuable &/or timely transactions is somewhat out of their original paradigm. For such situations involving structured environments ... CRLs were invented ... where there was enuf infra-structure that there was a high probability that all relying-parties/clients could be assumed to have gotten the distributed CRLs (this is analogous to the credit card invalid account number booklets that were mailed out monthly in the 60s and 70s to all merchants).
The current (online) environment, in effect negates the original paradigm design point for certificates (i.e. offline); and the current internet relying-party/anarcy also negates the original paradigm design point for CRLs (i.e. there is a defined list of merchants ... aka relying parties that CRLs are mailed to on a regular basis).
So what did the credit-card industry do .... when they went to an online environment, they also went to online transactions (where the validity of the transaction is checked in real time). That negated the use of the need of the offline credential as well as the whole CRL structure (which quickly breaks down). The "online" magstripe turned out to be packaged in the same physical housing as the earlier offline credential (and is somewhat still used for offline scenarios).
Now, specifically with respect to the marjority use of certificate PKI is the SSL domain name certificate (possibly 99.99999 percent of all such certificate-related events that go on in the world today) ... where the client checks that the certificate is valid ... and then checks that the domain name the client typed/clicked in, matches the domain name in the certificate.
The supposed purpose of this involves questioins about the integrity of the domain name infrastructure ... and could domain names get hijacked and mapped to a fraudulent ip-address. The SSL domain name certificate is designed to address this exposure.
However, when somebody applies to a certificate authority for an SSL domain name certificate, what happens?. It turns out that the certificate authority has to check with the domain name infrastructure as to who is the valid owner of the domain name (aka ... certificates authorities ... authenticate information to be placed in a certificate by checking with the "authoritive agency" responsible for the validity of the information ... in the case of domain names ... it is the domain name infrastructure; the domain name infrastructure that has integrity issues resulting in the supposed need for certificates in the first place).
Now, one of the things on the table by the CA industry for SSL domain name certificates is to improve the integrity of the domain name infrastructure (so that CAs can have higher confidence that they aren't dealing with a situation where a fraudulent application by somebody that has "hijacked" a domain name) .... is to have a domain name owner register their public key when they register a domain name. Then subsequent transactions are digital signed with the corresponding domain name owner's corresponding private key.
Note in the above scenario ... certificates are required to be sent by the domain name owner ... since the domain name infrastructure already posseses the domain name owner's public key (which was registered when the domain name was registered) ... aka one function of certificates is to address public key distribution. However, if the relying party already posseses the public key ... it is not necessary to resort to certificates for public key distribution.
Now, it turns out the current domain name infrastructure implementations for distributing IP-addresses that correspond to domain names ... is a generalized online information distribution mechanism ... aka it can register and distribute a variety of information related to a domain name, not just an IP-address. Once the domain name infrastructure has registered public keys ... then it would be possible to do real-time distriubtion of public keys in much the same way that they do real-time distribution of ip-addresses.
In effect, a solution that the CA industry may advocate for the domain name infrastructure may sow the seeds for eliminating the need for domain name certificates.
Now, lets look at the SSL domain name certificate protocol. Currently a typical operation is a client contacts the domain name infrastructure with a domain name requesting the corresponding IP-address. After getting, the corresponding IP-address, the client initiates a TCP session with the corresponding server. For HTTPS there is then a bunch of information chatter, transmitting the certificate, verifying the certificate, etc (and, in theory, if there was ever a real PKI implementation various kinds of checking for CRLs).
Now, if the domain name infrastructure carried the public keys; the response back to the client's domain name request could be both IP-address and the corresponding public key (in a single transmission). The client then encodes all the necessary SSL setup information and sends it to the corrsponding server. If the SSL selection is satisfactory, the server then has an active SSL session. No certificates, no CRLs, no CA hierarchies, not worrying about certificate expiration dates, all the complicated infrastructure gorp at the client ... totally disappears. The domain name infrastructure only distributes valid, real-time information ... invalid public keys ... like invalid ip-addresses just don't get distributed (so there is no question about whether they are expired or not).
random refs:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Certificate Authentication Issues in IE and Verisign Newsgroups: sci.crypt Date: Sun, 16 Dec 2001 08:13:13 GMTvjs@calcite.rhyolite.com (Vernon Schryver) writes:
for situations where that is not sufficient level of comfort, it is optionally possible to bypass caching and request direct information (now we are in ticks of seconds ... which is typically much, much shorter than the nominal interval that would give rise to requirement to update the public key information).
RFCs refs (also pointed to by the rfc-editor page):
https://www.garlic.com/~lynn/rfcietff.htm
click on Term (term->RFC#)
click on DNSSEC in the Acronym fastpath
domain name system security (DNSSEC )
see also domain name system , security
3130 3110 3090 3008 3007 2931 2930 2845 2541 2540 2539 2538 2537 2536 2535 2137 2065
3130
Notes from the State-Of-The-Technology: DNSSEC, Lewis E., 2001/06/18 (10pp)
(.txt=22291) (was draft-lewis-state-of-dnssec-02.txt)
clicking on the ".txt=nnnn" retrieves the actual RFC.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SSL vs HTTPS Newsgroups: alt.computer.security Date: Sun, 16 Dec 2001 08:35:08 GMTRalph Jones <rajones@SPAM_ME_NOT_AT_tconl.com> writes:
Nominally, SSL is a transport layer protocol ... that theoretically be a TCP feature .... however as an expediate it was implemented in the application ... rather than trying to get all the kernel ip stacks to provide support (aka something along the lines of ipsec).
the "standards" version of SSL is now called TLS
http over TSL & upgrading to TSL within HTTP: rfc 2817, rfc 2818
for SMTP over SSL/TSL ... Secure SMTP (SMTPTLS), RFC 2487.
using TSL with IMAP, POP3, and ACAP: rfc 2595
TSL protocol version 1.0; rfc 2246
and first entry doing "+ftp +ssl" on altavista
WS_FTP client & server supporting 128-bit SSL
http://www.ipswitch.com/
......
rfc index (also pointed to by rfc-editor page):
https://www.garlic.com/~lynn/rfcietff.htm
then select/click term (term->RFC#)
and then select/click "TLS" in the Acronym fastpath:
Transport layer security (TLS )
see also encryption , security
2847 2830 2818 2817 2716 2712 2595 2487 2246
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Newsgroups: bit.listserv.vmesa-l Subject: Re: CMS FILEDEF DISK and CONCAT Date: Sat, 15 Dec 2001 14:34:46 -0700At 12:01 AM 12/15/2001 -0600, "Schuh, Richard" wrote:
--
Anne & Lynn Wheeler lynn@garlic.com, https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Google Archive Newsgroups: alt.folklore.computers Date: Mon, 17 Dec 2001 03:29:44 GMTCharles Richmond writes:
and click on TERM (term->RFC#)
and scroll down several screens to "April1"
April1
3092 3091 2795 2551 2550 2549 2325 2324 2323 2322 2321 2100 1927 1926
1925 1924 1776 1607 1606 1605 1437 1313 1217 1149 1097 852 748
clicking on the rfc # will bring the RFC title to the bottom frame; aka
3092
Etymology of 'Foo', Eastlake D., Manros C., Raymond E., 2001/04/1
(14pp) (.txt=29235)
clicking on the ".txt=" field will retrieve the actual RFC
or
2549
IP over Avian Carriers with Quality of Service, Waitzman D.,
1999/04/01 (6pp) (.txt=9519) (Updates 1149)
1605
SONET to Sonnet Translation, Shakespeare W., 1994/04/01 (3pp)
(.txt=4451)
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The demise of compaq Newsgroups: comp.arch Date: Mon, 17 Dec 2001 03:52:34 GMTBernd Paysan writes:
the evening shutdown, in part allows a scheduling shutdown (or nearly so) and then can reset the sheet and (try to) start with a fresh slate the next morning.
If it can be planed ... landing someplace else can be avoided by anticipating and not taking off in the first place; if it can't be avoided and the plane is close ... the inference is that munich(?) is preserving some rule by forcing the plane to land at some other (near) airport that doesn't have such a strict enforcement. The passenger traffic might be somewhat increased ... but I doubt that it actually increases the traffic significantly. again it wasn't so much a traffic overload problem but a scheduling overload problem ... which can be similar, but still different. Also, it is possible that airports operating at lower traffic & scheduling load necessarily experience the systemic negative feedback.
misc. refs:
https://www.garlic.com/~lynn/96.html#29 Mainframes & Unix
random refs:
https://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#233 Computer of the century
https://www.garlic.com/~lynn/2000.html#0 2000 = millennium?
https://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
https://www.garlic.com/~lynn/2000e.html#21 Competitors to SABRE? Big Iron
https://www.garlic.com/~lynn/2000e.html#22 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001.html#28 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#32 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#34 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#37 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#38 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#48 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?
https://www.garlic.com/~lynn/2001.html#58 Disk drive behavior
https://www.garlic.com/~lynn/2001.html#62 California DMV
https://www.garlic.com/~lynn/2001.html#73 how old are you guys
https://www.garlic.com/~lynn/2001d.html#54 VM & VSE news
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001d.html#74 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#0 April Fools Day
https://www.garlic.com/~lynn/2001g.html#24 XML: No More CICS?
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#45 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
https://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
https://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
https://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce
https://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
https://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
https://www.garlic.com/~lynn/2001k.html#17 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#51 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2001l.html#41 mainframe question
https://www.garlic.com/~lynn/2001m.html#56 Contiguous file system
https://www.garlic.com/~lynn/2001n.html#0 TSS/360
https://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
https://www.garlic.com/~lynn/2001n.html#26 Open Architectures ?
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hyper-Threading Technology - Intel information. Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 17 Dec 2001 04:53:44 GMTSEYMOUR.J.METZ@CUSTOMS.TREAS.GOV (Shmuel Metz , Seymour J.) writes:
recent 195 posts
https://www.garlic.com/~lynn/2001n.html#38 Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2001n.html#41 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2001n.html#62 The demise of compaq
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The demise of compaq Newsgroups: comp.arch Date: Mon, 17 Dec 2001 05:14:37 GMTJoe Pfeiffer writes:
i think that such things are listed in 10Ks if they are critical and not replicated.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Holy Satanism! Re: Hyper-Threading Technology - Intel information. Newsgroups: alt.folklore.computers Date: Mon, 17 Dec 2001 15:03:58 GMTab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
there were probably hundreds or thousands of smaller projects over the years that never shipped. much smaller project was vulcan electronic disk in the late '70s that never shipped. Not as massive as FS was the whole "system memory" in the '80s (for closely coupled & related stuff; sort-off distributed stuff using addressable memory paradigm; small bits & pieces are seen in parrallel sysplex).
random fs refs:
https://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists.
https://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
https://www.garlic.com/~lynn/2000f.html#17 [OT] FS - IBM Future System
https://www.garlic.com/~lynn/2000f.html#40 Famous Machines and Software that didn't
https://www.garlic.com/~lynn/2001d.html#44 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001e.html#4 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984??
https://www.garlic.com/~lynn/2001g.html#36 What was object oriented in iAPX432?
https://www.garlic.com/~lynn/2001n.html#46 Blinking lights
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Holy Satanism! Re: Hyper-Threading Technology - Intel information. Newsgroups: alt.folklore.computers Date: Fri, 21 Dec 2001 04:20:22 GMTSteve O'Hara-Smith writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hercules etc. IBM not just missing a great opportunity... Newsgroups: alt.folklore.computers Date: Fri, 21 Dec 2001 04:45:33 GMTJohn Alvord writes:
from
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist
The file system design was clearly crucial. If CMS were to be
attractive to use, it had to have ''a convenient and simple method''
for reading and writing disks. Ron Brennan left to work on TSS in
April, 1966, but before he left Cambridge he had completed
specifications for the CMS file system (which was then called the
''Disk Service Program'') and had begun the implementation. In
producing his design, Brennan drew upon his own knowledge of CTSS and
upon Adair's knowledge of the file system for STRETCH. By September
of 1965, file system commands and macros already looked much like
those we are familiar with today: ''RDBUF'', ''WRBUF'', ''FINIS'',
''STATE'', etc. Many of the decisions that were to be key to the
elegance of the CMS file system had already been made:
. CMS would use the simple filename-filetype-filemode naming
convention, rather than using OS-like file names;
. Records would be mapped to fixed-size blocks;
. Records could be read or written by relative record number;
. From the user's view, a file would be created simply by writing to it; and
. In many commands, the filemode could be defaulted, in which case the
disks would be searched in a fixed order.
Another major focus of the CMS team was to determine the nature of the
command language: It was clear, based upon the experience gained with
CTSS, that a user-friendly command language was key. Another thing we
had learned was that the system had to be very forgiving, and although
options were desirable, default-mode, non-required parameters were to
be a paramount design consideration in CMS.
While his staff worked at designing the new system, Rasmussen sought
ways to pay for it, taking advantage of every bit of luck that came
his way. When IBM gave the 7094 to the MIT Computation Center, it
retained the night shift on that machine for its own use. So, because
the Scientific Center had inherited IBM's contracts with MIT,
Rasmussen ''owned'' eight hours of 7094 time per day. He traded part
of that time to the Computation Center for CTSS time for his
programmers to use in doing their development work. He ''sold'' the
remainder to IBM hardware developers in Poughkeepsie, who badly needed
7094 time to run a design automation program that was critical for
S/360 hardware development. With the internal funds he acquired this
way, he paid for the modifications to the Model 40. Although he could
not use these funds to pay for regular ''head-count'' employees, he
could use them to pay for part-time employees, mainly MIT students,
and to pay the salaries of IBMers who came to Cambridge to work on the
system while remaining in the ''head count'' of some other part of the
company. This method of funding the project with ''unbudgeted
revenues'' had the advantage of allowing it to keep a very low
profile.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: CM-5 Thinking Machines, Supercomputers Newsgroups: comp.arch Date: Fri, 21 Dec 2001 05:22:17 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Jan92 meeting ref; less than month before cluster scale-up was
transferred and we were told we couldn't work on anything with more
than four processors):
https://www.garlic.com/~lynn/95.html#13
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) Newsgroups: alt.folklore.computers Date: Sat, 22 Dec 2001 01:56:21 GMTjohnf@panix.com (John Francis) writes:
from one of the postings by MFC:
In fact you need one fewer bit for Blue than Red. And at normal reading/viewing distance, 4 bits in green is sufficent (though 5 is just better and is the maximum I've ever measured anyone being able to distinguish). Hence 3 in R, 4 in G, and 2 in B works well (or add 1 to each of those).
For details, see my paper: "Fundamental requirements for picture presentation", in Proc. Society for Information Display, Volume 26, No. 2 (1985).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: CM-5 Thinking Machines, Supercomputers Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 22 Dec 2001 18:49:27 GMTAnne & Lynn Wheeler writes:
Ref: NY TImes 12/18/88, Business page 1
subtitled, "Japan threatens to overtake the US in supercomputers, a
a critical technology", and accompanied by a diagram:
Comparing Speeds of Supercomputers (in megaflops*)
6
U.S. | Japan
Z---? 5
| | |
| | 4 Z---?
| | | | |
| | 3 Z---? | |
Z---? | | | | | | |
| | | | 2 | | | |
| | | | | | | | |
| | | | 1 Z---? | | | |
| | | | Z---? | | | | | | |
@---Y @---Y @---Y | @---Y @---Y @---Y
Cray ETA** IBM NEC Hitachi Fujitsu**
*megaflop=1 billion floating point ops/sec **not yet delivered
Concerns expressed include the dependency of US manufacturers on
Japan for critical parts, and mixes in related issues such as
trade policies and national security. "I am afraid that we may
be headed toward more friction over the highest technologies,
like supercomputers and semiconductors": T. Yamamoto, Fujitsu.
The Japanese are worried about IBM, "a new hesitant entrant
in the field", in addition to Cray and ETA. Current installs:
in US Japan Other 1st year ship
US Companies@ 225 137 12 76
Cray 201 125 11 65 1976
ETA (CDC) 24 12 1 11 1986
in US Japan Other 1st year ship
Japanese Comp. 127 3 106 18
Fujitsu 76 2 58 16 1983
Hitachi@@ 28 0 28 0 1985
NEC 23 1 20 2 1985
@ IBM will not release this info @@ includes open orders
• $10-25 million machines now standard equipment for anyone who:
- designs motorcars or Stealth planes
- cracks molecular structures or Soviet codes
- builds power plants or nuclear weapons
- analyzes intelligence photographs taken from space
Astounding Speed
- 12/6/88 Fujistsu announced biggest jump yet
. but pre-announce rumors expected more, NECs move awaited
. not available until end of 1990 or later
. Hitachi overhauled line, brought out smaller economical models,
"for now seems to have dropped from speed race"
- Japanese cooperate w/each other on heralded 5th generation (AI) but
intensely secretive on nearterm stuff, "they really hate each other"
Different Approaches
- almost everyone joins a Japanese company for life, but Japanese
supercomputers approach is alike and all very different from US
- Americans stress difference between supercomputers & mainframes
- programs that run on an IBM were useless on a Cray
- US strength: "graceful systems designs and superior software skills"
- US focus not on fastest single processor but faster systems,
ETA and Cray using parallel processors & dividing problem among them
Japan's Ace
- if US loses software lead, the emphasis will be on fastest, cheapest
and Japanese expected to win that scenario
- Cray already buys from Fujitsu, ETA buys Japanese parts also
. "we have no intention of holding back our best technology" Fujitsu
. Cray surprised by key parts it hadnt seen in Fujistsus new machine
- Japanese worried by IBM because its more like Japanese companies:
. IBM makes its own chips, giving semiconductor divisions lead time
. IBM can afford to lose money shortterm if it sees longterm gain
. IBM believes in supercomputers that can attach to mainframes
Rooting for IBM
- IBM "signed up" Steve Chen, designer of Crays Y-MP
. Chen working on a 64-processor computer to be intro'd early 1990's
- Pentagon, Defense Science Board worried about falling behind
. Fujitsu withdrew buyout of Fairchild Semicondutor after concerns
. MIT talked out of buying a NEC supercomputer
. "some favor creating a Government agency to act as co-ordinator";
US industry is fractured and cannot synchronize chip making,
software development and computer design
SSI GETS CRACKING ON FIRST PROTOTYPE - First delivery to customers by 1994 - Have focused on research and technology selection from 1987 to 1989 - "We will be the fastest. Yes, absolutely. We will be the industry leader." - Vincent Sollito Jr. (ed. - formerly of IBM) - Building prototype this year - Test and manufacture in 1993 - Marketing, production and work on future developments 1994 - First machine to be called the SS-1 - SS-1 will have high degree of parallel processing - SSI declined to reveal how many processors will make up the system - SSI intends to be in the massively parallel market down the road - SSI formed partnership with IBM in December, 1987 - "IBM has indicated that SSI continues to be their high-end vector supercomputer system", Solitto sais. - There is a picture of a technician in "bunny suit" at a microscope in a clean room that is 100 times as particle free as a medical operating room.
GOVERNMENT AGENCIES GO CRAZY FOR RISC SYSTEM/6000 CLUSTERS
(From Ed Stadnick-Competitive Consultant)
Federal agencies have caught clustermania. Over the last six months,
an increasing number of sites have strung together workstations with
high-speed networks to form powerful replacements or augmentations
to their traditional supercomputers.
At least nine federally funded supercomputer centers recently have
installed workstation clusters, and virtually all of these clusters
are based on IBM Corp.'s RISC System/6000 workstation line.
Growing Interest - In fact, the interest in clusters at federal and
university sites has grown so much that IBM announced last month a
cluster product that it would service and support. IBM's basic
cluster configuration consists of at least two RISC System/6000
workstations, AIX, network adapters, cables and software packages.
The interest in clusters caught us by surprise, said Irving
Wladawsky-Berger, IBM's assistant general manager of supercomputing
systems. "It is one of these events where the users figured out
what to do with our systems before we did."
Jeff Mohr, the chief scientist at High-Performance Technologies Inc.,
a federal systems integrator, said:
"If you look at a Cray Y-MP 2E and a high-end RISC System/6000... the
price differential can be literally 40-to-1. But if you take a look
at the benchmarks, particularly on scalar problems, the differential
can be about 5-to-1. So on certain problems, clustering can be
very, very effective."
Agencies that have these cluster include the National Science Foundation
at Cornell University and University of Illinois, DOE's Los Alamos
National Laboratory, FERMI and Livermore National Labs, and the Naval
Research Lab in Washington D.C.
Source: Federal Computer Week Date: May 11, 1992
High-Performance Computer Systems Estimated 1988-1992 WW Installed Base Category 1988 1992 CGR Supercomputers 350 1000 22% Mainframes 6000 12000 6% minisupers 2200 11000 41% superminis 300,000 900,000 20% workstations 370,000 2,750,000 52%... snip ... top of post
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Q: Buffer overflow Newsgroups: sci.crypt Date: Sat, 22 Dec 2001 19:57:48 GMTAndreas Gunnarsson writes:
random refs:
https://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
https://www.garlic.com/~lynn/99.html#219 Study says buffer overflow is most common security bug
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure4 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/2000.html#30 Computer of the century
https://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
https://www.garlic.com/~lynn/2001c.html#38 How Commercial-Off-The-Shelf Systems make society vulnerable
https://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#58 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce
https://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Buffer overflow Newsgroups: sci.crypt Date: Sat, 22 Dec 2001 21:26:08 GMT"mark" writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A PKI question and an answer Newsgroups: sci.crypt Date: Sun, 23 Dec 2001 16:44:56 GMTnada818s@hotmail.com (8 balls) writes:
a certification authority certificate typically binds some information about the certification authority and possibly a policy statement regarding the practices of the certification authority.
a relying party may "trust" the highest level "root" certification authority based on some investigation of that "root" certification authority.
a relying party may "trust" the "root" certificate that the relying party already posseses ... say the "root" certificate that has been preloaded into their browswer; they have investigated the process that the browser manufactur uses to validate the "root" certificate, the process that the browser manufactur uses to load the "root" certificate into the browser, and the process that the browser manufactur uses to distribute the browsers (and safekeep the preloaded "root" certificate) and found all the processes to be trusted.
a relying party may "trust" the process that is used to validate a certificate "chain" ... i.e. a relying party receives a certificate and then they use one or more certification authority certificates to validate the received certificate. The relying party then can trust the information in the certificate.
So okay ... for the certificates that possibly represent 99.999999 percent of the certificate-based authentication operations that occur in the world today .... what happens? These are the SSL domain name server certificate, they represent a binding of the server domain name to a server publc key.
So why is this trust needed?
The primary issue is that when the relying party types a domain name name URL into their browser, the browser has to request the mapping of the domain name to an IP-address from the domain name infrastructure. There happen to be some integrity issues reqarding the domain name infrastructure and its ability to reliably map the typed in (or clicked on) domain name to an ip-address (say the domain name has been hijacked).
The browser
1) gets back the ip-address from the domain name infrastructure, 2) initiates a TCP session with the server at that IP-address 3) gets a SSL domain name certificate from the server at connected to IP-address 4) validates certificate's digital signature using a CA's public key from a preloaded CA certificate (hopefully correctly provided by a browser manufactur and not subsequently tampered with) 5) takes the domain name from a validated certificate and checks it against the typed in (&/or clicked on) domain name
.....
Now, what is the trust model?
The trust model is
1) CA certificate correctly provided by the browser manufactur 2) CA certificate not subsequently tampered with 3) CA correctly validated a server's domain name & public key before manufacturing & issuing the certificate 4) something bad has not happened since the CA manufactured the certificate 5) something bad has not happened before the CA manufactured the certificate
So lets look at just #5; what bad could have happened before the CA manufactured the certificate?
Now, remember the real purpose of having these SSL domain name certificates is various integrity issues related to the domain name infrastructure (and things like domain name hijacking).
What does a CA know about domain names? typically nothing. CAs typically has to validate domain name ownership with the authoritative agency(s) responsible for domain name ownership (aka in general, CAs aren't the authoritative agency for any information ... CAs are totally reliant on various authoritative agencies for the information they validate).
Who is the authoritative agency for domain name ownership that CAs must rely on for validating domain name ownership? ... the domain name infrastructure.
Could there be a problem with domain name infrastructure and information regarding domain name ownership with would invalidate the CA verification? Well .... one of the reasons that SSL domain name certificates supposedly exist in the first place is that domain name infrastructure could have integrity issues that affect the validating of the domain name information. One example is domain name hijacking which affects the validaty of domain name ownership .... giving rise to the original reason for needing SSL domain name certificates at all.
It turns out that domain name hijacking not only can affect the validity of the information a browser gets when contacting the domain name infrastructure but it also affects the validity of the information that a CA gets when contacting the domain name infrastructure ... aka
1) with regard to domain name information both browser operation and CA operation are dependent on the same agencies
2) with regard to domain name information both browser operation and CA operation are dependent on some of the SAME integrity vulnerabilities.
Now, there have been various CA-oriented proposals with regard to how to improve the integrity of the domain name infrastructure .... so that the CAs can better rely on the domain name ownership information they have to validate with the domain name infrastructure. Note, however, any improvements in the integrity of the domain name infrastructure can improve the integrity for everybody .... not just CAs .... thereby reducing the original justification for having SSL domain name certificates in the first place.
random refs:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The demise of compaq Newsgroups: comp.arch Date: Sun, 23 Dec 2001 17:07:06 GMT"Rupert Pigott" writes:
https://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (was: re: Chinese Solve Y2K)
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A PKI question and an answer Newsgroups: sci.crypt Date: Sun, 23 Dec 2001 17:49:32 GMTaka ... a PKI trust model is typically about a non-trivial number of independent business entities and business processes tied together in a complex sequence of operations (some of which can be disjoint in time by a period of a year or more). Furtermore, from a serious business stand-point the liability (typically a basic cornerstone of business operations) might be, at best, totally ambiquous.
liability is not only about who pays if something goes wrong ... but frequently also is used to indicate serious intent on the part of the participants (there tends to be a much higher level of trust that various independent business entities are really, truely taking some trust issue seriously if they have liability associated with the issue).
the mathematics of validating a certificate digital signature in real time may represent only a trivially small percentage of the total number of complex, interlocking trusted business processes required for the end-to-end operation of a PKI.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Buffer overflow Newsgroups: sci.crypt Date: Sun, 23 Dec 2001 18:01:40 GMTMok-Kong Shen <mok-kong.shen@t-online.de> writes:
If the length semantics are always implicit ... then does every operation that deal with a buffer have code that obeys some internal length specification (i.e. does every buffer carry with it maximum size and current length .... and does every operation that touches a buffer always obey the max. and current length specifications).
c language environment conventions tends to neither be consistent and/or adequate. syntax checkers can at least check for the more obvious "best practices" (only use operations where lengths are explicitly specified ... syntax checkers have much harder time validating that every buffer related operation always obeys real run-time length specifications).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) Newsgroups: alt.folklore.computers Date: Sun, 23 Dec 2001 20:43:50 GMTEric Smith <eric-no-spam-for-me@brouhaha.com> writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Swap partition no bigger than 128MB????? Newsgroups: linux.redhat,linux.redhat.install,linux.redhat.misc Date: Mon, 24 Dec 2001 05:39:48 GMTsome guy writes:
the issue is how much simultaneous active virtual memory exists ... and to some extent some aspects of the page/swap management algorithms. For instance, some implementations require that there be disk space allocated for every virtual page in existance (even duplicating virtual pages that currently exist in real storage) and other implementations only require disk space for virtual pages not currently resident in virtual memory.
A "duplication" implementation (disk space for all virtual pages regardless of whether or not they are resident in real storage) would require 1gigabyte of disk page/swap ... if there was 1 gigabyte of virtual pages belonging to applications. In effect, there is almost no correlation with amount of real storage and required swap/page space ... other than indirect correlation where installations with larger real memories may (or may not) have more simulataneously running applications.
A "no-dup" implementation could reduce the amount of required disk space by the amount of virtual memory pages resident in real storage (pages brought into real memory have their disk locations made available for writing out other virtual pages). In such a no-dup implementation the amount of total disk page/swap required is reduced by the amount of virtual pages resident in real storage. A 512kmbyte real storage with 1gigabyte of application virtual memory would only require slightly more than 512kmbyte disk space (total of 1gbyte minus something approaching 512kbyte resident in real storage; modulo kernel fixed storage and file caching requirements).
these days the performance difference between cache, real storage, and disk is so large that the relative performance penalty of having to page is much larger today than in the '70s. As a result the "pain" level is higher which can imply that anytime there is significant amount of paging ... either 1) people stop adding simulatenous applications ... reducing total virtual memory requirements or 2) add real storage. This tends to limit total number of virtual pages and has some correlation to total real storage.
I did one study that showed over a 15 year period between the late '60s and the early '80s, cpu and real storage resources increased by a factor of 50 times while disk resources increased by only a factor of 10 times; aka the net result was the relative system performance of disks declined by a factor of five times (which correlated with a five times increase in system pain associated with doing a disk operation).
Similar trends have continued up thru the current time ... where amounts of real storage has increased while its cost has come down ... and the relative trade-off of adding more real storage vis-a-vis doing disk page i/o has widened.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) Newsgroups: alt.folklore.computers Date: Mon, 24 Dec 2001 08:54:28 GMTgreenaum writes:
.... two from '90 (plus a forrester report)
quick selection from 8/26/90 sjmn
1m80 $5.99
1mx9 sipps/simms; 80 or 70 $59.95
..
1m80 $5.45
1mx9 80 $52
1mx9 70 $54
1mx9 60 $63
486/33mhz system $3295
486/25mhz system $2495
..
386/25mhz system $995
..
386/33mhz $1259
14in svga .28 1024x768 &
1024x768 vga card add $489
80mb/18ms add $475
660mb/18ms
+ esdi card add $1895
...
also for comparison, there was a 31in color tv/monitor with up to 700
line resolution for $2200. i've been arguing for several years that
such electronic TVs has majority of the components for running
computer applications. Adapter slot for a plug-in processor board,
keyboard, and disk drive should allow many of the current generation
of electronic TVs to add application processing capabiity at a very
nominal price.
quick selection from 9/2/90 sjmn
386/33mhz system that was $1259 last week is now $1229
last week this week
386/33mhz $1259 $1229
14in svga .28 1024x768 &
1024x768 vga card add $489 $469
80mb/18ms add $475 $460
660mb/18ms
+ esdi card add $1895 $1895
This system is measured at landmark speed index of 58.7mhz
.....
Some 486 systems this week:
landmark
price memory max. si mips
$2495 1mb 16mb 113mhz
$3295 1mb 16mb 135mhz
$4450 8mb 16mb 183mhz 17.7
These are all basic machines with case, power supply, keyboard, 1.2mb
teac drive, hd-fd controller.
.....
comparison of different advertisements of basic machines (case, power
supply, 1mb memory, floppy, etc) with different processors:
cpu price landmark si price/si
286-20 $559 26mhz 21.5
286-25 $659 33mhz 20
386-20 $839 28mhz 30
386-25 $885 34mhz 26
386-25c $995 43mhz 23
386-33c $1229 58mhz 21.2
486 $2495 113mhz 22
486 $3295 135mhz 24.4
486(8mb) $4450 183mhz 24.3
With the 8mbytes, the 183mhz/486 would represent about one of the best
price/performance (in terms of cpu power). For lots of tasks that
involve disk & other I/O the cached 33mhz 386 (si of 57mhz) or the
25mhz 286 (si of 33mhz) are at the knee of the price/performance
curve.
IBM Jargon:
Registered IBM Confidential - adj. The highest level of confidential
information. Printed copies are numbered, and a record is kept of
everyone who sees the document. This level of information may not
usually be held on computer systems, which makes preparation of such
documents a little tricky. It is said that RIC designates information
which is a) technically useless, but whose perceived value increases
with the level of management observing it; or b) is useful, but which
is now inaccessible because everyone is afraid to have custody of the
documents. see candy-striped
Subject: FORRESTER "MAINFRAME R.I.P." June, 1990
Forrester has published a 16 page report on customers replacing or
downsizing mainframes with client/server systems. Forrester interviewed
25 Fortune 1000 companies doing so, with the following results;
o In 7/89 Forrester projected 8 % of the Fortune firms are replacing
mainframes with PC LANs. They now feel that rate is accelerating.
o Of the 25 accounts interviewed;
17 replaced an IBM 370 (9-43xx, 6-3090, 6-308x, 3-other).7 are
keeping the 3090 but migrating applications to PC LANs.
The replacing LAN averaged 12 networks, 440 nodes, 45 servers
Excluding two very large networks (1,500 PCS each) the average
becomes 4 networks, 225 nodes, 7 servers.
o Cost savings were the key... from $240k to $4.5m per year ($1.6m avg.)
o On average, a 25% reduction in MIS staff was achieved
o Other benefits;
- Improved application development time (from 24-36 mos.to 6-12 mos)
- Doubled materials purchased on a Just-In-Time basis (mfg.)
- Improved end used control of his operation.
o Problems with downsizing;
- LAN's are not easy to install and get running.
- "There is no DEC or IBM to call when the environment breaks"
- Some concerns on security BUT....
"...is mainly fear of the unknown on the part of mainframe'
people..."
" PC networks are as secure as mainframes. Our decentralized
units passed all corporate and Price-Waterhouse audits".
o There are PEOPLE problems;
- There are a lack of people with traditional MIS skills (backup/
archive, documentation, disaster planning).
- MIS people are reluctant to believe in advantages in migrating
to micro based LANs.
- End users are not always prepared for new responsibilities.
o The demise of the mainframe is exaggerated, but the role will evolve to
that of a corporate wide utility
- Network management
- Enterprise-wide backup
- Data management
- Tool repository (applications)
- Batch processing
- Security
o Forrester schedule for the off-load
- 1989-1993 Office Automation/Decision Support
- 1990-1994 Application Development
- 1992-1995 Departmental Applications
- 1994-1999 Production Applications
o IBM's mainframe focus must shift
- To data management, not MIPS
- VPA structure
- Outsourcing (ie; IBM must manage mainframe installations for
Fortune 1000 companies
o MIS power will dilute - have to "cajole users to follow it's lead"
- Negotiate product discounts
- Administer networks
- Contract application skills
- Redesign a charge-back structure for a fee-based utility.
o WHAT USERS SHOULD DO
- Get a handle on Mainframe costs
- Think long and hard on SUMMIT or ESA
- Target an application for removal as a pilot
- Plan on MIS staff disruption/LAN training/distribution to
end user departments.
- Prepare the users for their new responsibilities
- Line up a service bureau (for remaining 370 apps)
- Outsource the mainframe
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) Newsgroups: alt.folklore.computers Date: Mon, 24 Dec 2001 09:08:18 GMTanother SJMN ...
Tom Schmitz, San Jose Mercury News, 10Apr89, pg 1D
Chip Wars:
1972 Intel 8008 3,500 transistors; 8-bit
1978 Intel 8086
1979 Intel 8088 29,000 transistors; 16-bit
Motorola 68000 68,000 transistors
1981 IBM picks Intel 8088
Apple picks Motoroloa 68000
1982 Intel 80286 130,000 transistors
1983 Motorola 68010 (adopted by Sun, H-P, Apollo)
1984 Motorola 68020 195,000 transistors 32-bit
1985 Intel 80386 32-bit; IBM adopts it for PS/2 line
1987 Motorola 68030
1988 Intel 80486 (1-million transistor mark broken)
Motorola unexpectedly releases advance details of 68040
Intel will take robe off 80486 contender today
Motorola is tying the gloves on the 68040
Time to watch some of America's most sophisticated technology companies
- slug it out over who will build brains of tomorrow's computers
- Microprocessor Wars, round 4
- contenders will find markets have undergone important changes
. 2-company contest has turned into a "bench-clearing brawl"
Drew Peck, Donaldson, Lufkin & Jenrette analyst, New York
- "Amount of confusion out there is as high as I've ever seen it."
- "Motorola and Intel are well-situated to become the
microprocessor standards of the future.
... it's a toss-up as to who's going to come out on top."
68040 and 80486 are very similar from technology point of view
- predictable extensions of familiar product lines
- promise whopping dose of industry's most sought-after commodity
. Speed (2-3 times as fast)
. approaching multi-million dollar mainframes
- First computers to use them expected in mid-1990
- extraordinary design feats
. 68040: 1.2 million transistors
. 80486: 1.1 million transistors
. 80386: 275,000 transistors (for comparison)
- High-level of integration
. Space for frequently used data and instructions
. Floating point math units
Chip customers are NOT similar
- Intel: adopted by IBM and Compaq
- Motorola: Apple, Sun, Hewlett-Packard
- 1988: Intel and Motorola neck-and-neck in sales of 32-bit processors
- Neither new chip is likely to give one company an advantage
- But computer markets are beginning to skew the race
- Intel may have trouble finding a home for the 486 in PC market
. Computer makers are only now absorbing the 386
. $1,000 price for 486 pushes computer to $15,000 range
. Computer makers may decide the extra power isn't worth it
. The applications for that power aren't there yet
("How much faster can my word processor run?")
- Some think Intel will begin poaching on Motorola territory
. technical workstations
. "... a chance to sway Motorola customers"
. "Problem is all that RISC stuff got there a year ago."
. "Not clear all that business hasn't been spoken for"
- Michael Slater, Microprocessor Report
Sequent Computer Systems, Beaverton, Oregon
- early Intel customer for 486
- plans to string the chips together into a mainframe
RISC
- Sun and Mips elbowed their way into the microprocessor market
- Some limitations:
. Not appropriate for all computing applications
- Quick speed fix of RISC has proved to be an irresistible attraction
. Put pressure on Motorola 68000 line
. "If we waited for Motorola, we'd still be waiting"
- Bill Keating, Sun director of technology marketing
- Motorola introduced it's own RISC processor
- Intel, well known RISC-detractor, rolled out its 80860
- Betting on both horses
. Forestall the RISC competitors
. Use faster conventional products to prevent further defections
Motorola is the company with the most to lose
- working overtime to smooth customer feathers
- gave reporters an inside peek at the 68040
. timed to coincide with Intel 486 announcement
- Souped up versions of the 68030 could, theoretically,
keep up with the RISC chips
Bill Keating, Sun
- 68040 and 80486 "are based on technology that's 10 years old"
- "They're serving the needs of software, more than hardware"
- How popular RISC becomes will prove the variable
. whether these chips represent a breakthru in technology
. or the end of the line
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) Newsgroups: alt.folklore.computers Date: Mon, 24 Dec 2001 09:14:30 GMT
Selection from 12/22/91 San Jose sunday paper. 486/386/286 base system
include 1:1 IDE HD/FD controller, 101 K/B, Teac 1.2mb or 1.44mb FD.
Enhanced case & P/S. 2S/1P. Motherboard w/CPU and basic memory
installed. One year labor and parts warranty.
There hasn't been much change in price since posting of a month ago
except in a couple of "system" price reductions.
system
4/14/91 6/23/91 12/22/91 12/22/91
486/33mhz(eisa) $2398 $1455 $2030
486/25mhz(eisa) $2098 $1405 $1980
486/33mhz $1698 $1448 $785 $1320
486/25mhz $1398 $1178 $735 $1330
486sx/20mhz $585 $1190
386/40mhz $1048 $898 $545 $1144
386/33mhz $898 $698 $535 $1108
286-20 $498 $388 $292 $880
"system" includes 120mb hard disk, 14in SVGA (1024x768) display, and
16-bit SVGA adapter card.
386/33 system is measured at landmark speed index of 58.7mhz, 486/25hz
system measured at 117mhz; @33mhz - 152mhz;
.....
Misc. other prices:
425mb IDE 3.5in (9ms) $1199
1.2gb SCSI (13ms) $2149
1.2gb SCSI (13ms) $1949
1.7gb SCSI (12ms) $2399
Drive warranties vary from 1yr to 5yr ... with some of the drives
advertising 150,000hr MTBF (for instance the 1.7gb SCSI).
....
One of the dealers is now advertising a 486/50mhz system for $2300
with 4mb ram (expandable to 32mb) and 105mb hard drive. Has anybody
seen Landmark "mhz" ratings for a 486/50mhz chip (i.e. 486/33mhz is
rated at "150mhz")?
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) Newsgroups: alt.folklore.computers Date: Mon, 24 Dec 2001 09:29:08 GMT
selection from 7/26/92 san jose sunday paper. 486/386/286 base system
include 1:1 ide hd/fd controller, 101 k/b, teac 1.2mb or 1.44mb fd.
enhanced case & p/s. 2s/1p/1g. motherboard w/cpu and basic
memory (512k on 286, one meg on rest) installed. one year labor and
parts warranty.
they still are pricing 486sx/20 for more than 386/33mhz ... but only
by 10 bucks (although the "super sale" shows 90). I keep predicting
that it should drop below.
6/23/91 12/22/91 2/16/92 6/7/92 7/26/92
486/50mhz(eisa) $1418 $1238
486/33mhz(eisa) $2398 $1455 $1328 $1018 $917
486/33mhz $1448 $785 $738 $630 $597
486/25mhz $1178 $735 $688 $590 $558
486sx/20mhz $585 $568 $448 $357
386/40mhz $898 $545 $508 $380 $353
386/33mhz $698 $535 $488 $376 $347
286-20 $388 $292 $292 $232 $230
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
super sale
basic system
4mb ram 70ns
1.2mb & 1.44mb floppy
130mb 15ms hard drive
1024x768 .28 dp 14in color monitor
512k svga card
deluxe medium tower chassis with power supply
486-50/64k eisa $1988
486dx2-50/64k cache $1508
486sx-20/64k cache $1138
386-40/64k cache $1058
386-33/64k cache $1048
386dx-25 $1038
options:
add $20 for 1mb svga card
add $50 for non-interlaced monitor
add $170 for 200mb hard drive
add $45 for 256k cache
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: CM-5 Thinking Machines, Supercomputers Newsgroups: comp.arch,alt.folklore.computers Date: Mon, 24 Dec 2001 18:53:42 GMTAnne & Lynn Wheeler writes:
re:
https://www.garlic.com/~lynn/2001n.html#17 CM-5 Thinking Machines, Supercomputers
https://www.garlic.com/~lynn/2001n.html#68 CM-5 Thinking Machines, Supercomputers
https://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers
the kingston lab was already in existance ... in part because of prior
supercomputer efforts .... but the following announcements were within
a couple weeks after cluster scale-up was "discovered" & transferred to
kingston and we were told we weren't to work on anything with more
than four processors.
in the above referenced meeting we had schedule for 16 processors configurations in customer shops by summer and 128 processor configurations in customer shops by ye92 (although we were also involved in commercial and business applications).
random other:
https://www.garlic.com/~lynn/2001i.html#52 loosely-coupled, sysplex, cluster supercomputer and electronic commerce
IBM ANNOUNCES SUPERCOMPUTING EFFORT:--Kingston, NY is base for new super-
computing lab:
o POWER ARCHITECTURE RISC CHIPS:--massively parallel SUPERCOMPUTERS
built using the newest technology for highly complex scientific cal-
culations, like long range weather forecasting and advanced aircraft
or automotive design.
o FUTURE VIEW:--massively parallel computing in a multiprocessing envi-
ronment is ultimate direction. IBM has looked 5 to 10 years ahead to
develop this environment according to Ladenbury, Thalmann and Co.
Source: Electronic Buyers News Date: 2-17-92 Page: 46
IBM SUPERCOMPUTERS BUILT ON RS/6000 CHIPS:--developed to run AIX perform-
ing billions of floating-point operations per second (FLOPS). Perform-
ance expected in TFLOPS range:
o DELIVERY SET:--parallel processing from multiple RS/6000 expected by
late '92. Marketed only to scientific and technical community, new
SUPERCOMPUTER products respond to customers already clustering work-
stations to perform SUPERCOMPUTING tasks.
o COMPETITION EXPECTED:--HP, SUN and other companies are expected to
follow suit with similar strategies according to THE SMABY GROUP.
IBM to compete with its own mainframes. IBM says strategic "direc-
tion came loud and clear from the customers."
o INVESTMENT and EXCHANGE NOT AFFECTED:--IBM agreements with SUPERCOM-
PUTING SYSTEMS and THINKING MACHINES are not impacted by new Lab.
.
Source: Computerworld Date: 02/17/92 Page: 8
pull-back from what was mentioned the month before in early jan92
meeting in Ellison's conference room ... aka both "scientific and
technical" *AND* commercial, reference in this old post:
Subject: "Foray into Mainstream for Parallel Computing"
Source: NY Times, 6/15/92, pg C1, John Markoff
Massively parallel processing 'has become the most turbulent and fastest-
growing corner of the computer industry. In the past, MPP systems were
used mostly by scientists and engineers willing to roll up their sleeves
and write their own software'
o IBM, DEC, Cray and Convex have jumped into the MPP market
- certain this technology will be bigger than the PC revolution
"Not long from now todays mainframe processors will disappear and
all computers will be either single microprocessor systems or
parallel systems like these" Ken Kennedy, computer scientist & dir.of
Rice Univ.'s Ctr of Research on Parallel Computation
o Edward Masi, Intels small supercomputer pres. (and former IBMer)
- he went on a recruiting mission for Cray Research last year
- and ended up working for Intel instead
"I couldn't resist the opportunity. It's mindblowing what Intel's doing"
'For the first time software is becoming available for the commercial market'
o Oracle Systems makes database software used in airline and banking
transaction systems
- they will announce today version 7 of its relational DB software
- designed to run on MPP
o Dow Jones and American Express are using MPP for special applications
requiring more power than conventional systems
o Kendall Square Research has an announcement later this week
- their 1st system designed to compete directly with IBM mainframes
- they expect the bulk of orders to be from commercial users
- MPP has tremendous cost and performance advantages over vector:
Harvey Burkhardt, Kendall Square founder
o Mark Teflian, Covia Technologies president
"Today MPP is a driving factor. Within 2 years these technologies will
begin to have a significant impact on large data processing centers"
o Larry Ellison, Oracle president
"People just haven't grasped the impact of MPP yet.
This will absolutely revolutionize high-end computing;
conventional mainframes are completely gone.
On my desk I have a $10K 76 MIPS H-P workstation that is attached to a
$7M 50 MIPS IBM mainframe. What's wrong with this picture?"
o David Audley, Prudential Securities dir. of strategic research
- they bought an Intel MPP for use by traders
"We found that we could make use of the machines right out of the box.
We knew there were technical risks but we now know that we were on the
right track"
- they plan to switch over to Intels Paragon later this summer
Cray, IBM and Amdahl are working on their own products
- Cray will soon enter the field
- IBM and Amdahl are redesigning their mainframes to utilize MPP
- DEC has formed alliances with Intel and Maspar
o 'many technology experts say IBM has the most to lose'
- IBM executives say they are well aware of the technology
"There is nothing to prevent us from taking our existing System 390
technology and implementing it in another technology"
Abraham Peled, IBM researcher
'In fact, IBM is said to be planning to demonstrate a 32-microprocessor
version of its most powerful mainframe computers later this year'
Accompanied by a chart of market share revenues: (source - Smaby Group)
1990 1991
Intel $30M $90M
Thinking Machines 65 85
Meiko 20 25
Maspar 6 19
Ncube 20 18
others 24 34
... snip ... top of post
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Buffer overflow Newsgroups: sci.crypt Date: Mon, 24 Dec 2001 19:42:18 GMTChris Humphries writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The demise of compaq Newsgroups: comp.os.vms,comp.arch,comp.sys.intel,alt.folklore.computers Date: Wed, 26 Dec 2001 00:25:15 GMTpg_nh@sabi.Clara.co.UK (Piercarlo Grandi) writes:
there is reputed to be some testimony in the gov. legal thing against ibm by somebody from one of the companies no longer in the business ... that in the late '50s all the vendors in the business realized that the single most important thing/characteristic (at that time) for the computer industry was to have a compatible line of machines across the product offering ..... and that in the '60s supposedly IBM was the only vendor that actually achieved that single most important requirement (during the late '50s, '60s, and '70s, businesses were going thru fairly rapid expansion and growth of their business data processing ... frequently needing to upgrade their hardware).
There are other tales/books/stories about the 360 line being an extrodinary gamble by the ibm company that just happened to pay off ... and consistent with the testimony about being the only vendor meeting the single most important market requirement ... achieving significant customer install base.
Lots of the stuff with required to current day state of the art business strength data processing and business continuity could be viewed as much as evolutionary trail & error by a large customer community over a 30+ year period ... as opposed to any fancy purposeful design. Some amount of it could also be attributed to various business instruments like service level agreements (stuff not often taught in university computer engineering and/or software classes).
not too long ago ... person responsible for one of the large financial
data processing infrastructures attributed 100 percent availability
for a six plus year period to
• IMS hot-standby
• automated operator
... where automated operator is something of a heuristic methodology
for automating various human interactions (minimizing various kinds of
human errors/mistakes ... which are starting to become an increasing
serious factor in service availability). Again, a lot of this
technology & methodology is as much evolutionary contributions by a
large customer base focused on business critical operations over 30+
year period.
The other comment was that possibly the number one risk to this operation was that critical staff were 30+ year veterans, mortgage was all paid off, kids all thru college and they had little incentive to not retire (there is a lot of institutional memory acquired over 30+ years about all the possible ways things could go wrong and how to plan for such contingencies ... which could possibly be lost in a relatively short period of time).
random refs:
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/94.html#44 bloat
https://www.garlic.com/~lynn/96.html#20 1401 series emulation still running?
https://www.garlic.com/~lynn/98.html#23 Fear of Multiprocessing?
https://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
https://www.garlic.com/~lynn/99.html#107 Computer History
https://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#145 Q: S/390 on PowerPC?
https://www.garlic.com/~lynn/99.html#184 Clustering systems
https://www.garlic.com/~lynn/99.html#231 Why couldn't others compete against IBM?
https://www.garlic.com/~lynn/2000.html#22 Computer of the century
https://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
https://www.garlic.com/~lynn/2000g.html#27 Could CDR-coding be on the way back?
https://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
https://www.garlic.com/~lynn/2001.html#41 Where do the filesystem and RAID system belong?
https://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
https://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
https://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001e.html#48 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
https://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
https://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2001i.html#43 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0</pre>
https://www.garlic.com/~lynn/2001j.html#33 Big black helicopters
https://www.garlic.com/~lynn/2001j.html#38 Big black helicopters
https://www.garlic.com/~lynn/2001j.html#39 Big black helicopters
https://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001l.html#47 five-nines
https://www.garlic.com/~lynn/2001n.html#22 Hercules, OCO, and IBM missing a great opportunity
https://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) Newsgroups: alt.folklore.computers Date: Thu, 27 Dec 2001 04:13:13 GMTRic Werme writes:
The "attached" processor version was just an additional processor w/o any i/o capability (and configurations couldn't be cleaved and operated independently) but fully symmetric shared memory operation.
The operating system tended to be standard multiprocessor software with the addition that when I/O was being scheduled ... it would check if the required I/O attachment was available on the current processor, and if not, queue it for the processor with the appropriate i/o capability. In a 2-processor ("attached") configuration this resulted in all I/O initiation operations and all i/o termination/interrupts where funneled thru a single processor.
It turns out that even for fairly I/O intensive operations the "attached" processor configuration could out-perform the fully symmetric multiprocessor configuration (where both processors supported full compliment of I/O). The issue was that asynchronous I/O interrupts and other types of operations tended to have severe cache hit penalty ... aka an application would be running along ... get all its data & instructions loaded into the cache ... and an I/O interrupt could occur at random ... which tended to result in the application cache lines being replaced with kernel & I/O supervisor cache lines. In the attached processor version ... the extra overhead of passing I/O requests off to another processor was more than offset by the improvement in cache hit ratios. I/O interrupts would never impact application (cache hit/miss) running on the processor w/o i/o capability (in some cases the effective mip-rate that the application experienced nearly doubled). There is also some probability that an I/O interrupt coming in on the processor with i/o capability would happen while there was still kernel & i/o supervisor logic still in the cache (which could also improve the effective mip rate of the kernel & i/o supervisor code).
The hardware was specifically configured &/or forced to run application code on one processor and kernel code on the other processor ... but the kernel was structured in such a way that if possible, dispatching would tend to promote processor (& therefor cache) affinity operation (try and keep running stuff on the same processor that it has been running on to improve cache hit ... or correspondingly reduce cache miss).
this is different than the recent postings about the work to implement a "virtual" smp on pipelined 370/195 in an attempt to better keep its pipeline operating at peak thruput.
random attached processor refs:
https://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
https://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
https://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000e.html#58 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
misc. recent 195 postings
https://www.garlic.com/~lynn/2001n.html#38 Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2001n.html#62 The demise of compaq
https://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A new forum is up! Q: what means nntp Newsgroups: comp.lang.python,alt.folklore.computers Date: Fri, 28 Dec 2001 19:21:58 GMTclaird@starbase.neosoft.com (Cameron Laird) writes:
RFC 765 FILE TRANSFER PROTOCOL June 1980 RFC 821 SIMPLE MAIL TRANSFER PROTOCOL August 1982 RFC 854 TELNET PROTOCOL SPECIFICATION May 1983 RFC 850 Standard for Interchange of USENET Messages June 1983 RFC 977 Network News Transfer Protocol February 1986765 is the latest standard .... there is a trail of previous RFCs that were replaced by the latest ... going back to
no precursor listed to 977
random ref:
https://www.garlic.com/~lynn/rfcietff.htm
jan 1, 1983 was the "cut-over" from IMPs and NCP to IP. There were about 250 nodes that were part of the 1/1/83 cutover. Note however, there were interconnects of ARPANET (IMPs and NCP) by locations with TeleNET (GTE) and "PhoneNet" (dial-in) for things like SMTP mail (aka "offline" processing ... dial-up, download, hang-up ... somewhat akin to uucp strategy using "phonenet").
random ref:
https://www.garlic.com/~lynn/internet.htm#0
misc. RFC referens:
rfc60 ... A simplified NCP Protocol rfc215 .. NCP, ICP, and TELNET: rfc381 .. TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL rfc394 .. TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL rfc550 .. NIC NCP Experiment rfc618 .. A Few Observations on NCP Statistics rfc660 .. SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACE rfc687 .. IMP/Host and Host/IMP Protocol Change rfc704 .. IMP/Host and Host/IMP Protocol Change rfc773 .. COMMENTS ON NCP/TCP MAIL SERVICE TRANSITION STRATEGY rfc801 .. NCP/TCP TRANSITION PLAN--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A new forum is up! Q: what means nntp Newsgroups: comp.lang.python,alt.folklore.computers Date: Sat, 29 Dec 2001 01:28:38 GMTssthapa@classes.cs.uchicago.edu (Suchandra Thapa) writes:
& click on RFCs that are also
"Standards (STD)"
and scroll down to STD-9
Note that most fields are "clickable" for instance FTP brings up:
FTP - (Stan) - File Transfer Protocol [port:21]
959 (STD-9) - File Transfer Protocol
1415 - FTP-FTAM Gateway Specification
clicking on the ".txt" field will retrieve the actual RFC.
Clicking on various RFC nos &/or STD references will bring up the appropriate information.
Various processes also do cross-checking of released rfc status as well as information released in new STD1s for consistency. The "Obsoleted" section use to appear as "Section 6.10" in earlier STD1s.
=============================
STD-9
959 (Stan) - File Transfer Protocol (FTP)
959 is the "standard"
959 S
File Transfer Protocol, Postel J., Reynolds J., 1985/10/01 (69pp)
(.txt=147316) (STD-9) (Updated by 2228, 2640, 2773) (Obsoletes 765)
(Ref'ed By 2389) (FTP)
959 has current updates 2228, 2640, & 2773 ... and is also ref'ed by 2389
2259 PS
File Transfer Protocol, Postel J., Reynolds J., 1985/10/01 (69pp)
(.txt=147316) (STD-9) (Updated by 2228, 2640, 2773) (Obsoletes 765)
(Ref'ed By 2389) (FTP)
2259 is currently in proposed standard state
2640 PS
Internationalization of the File Transfer Protocol, Curtin B.,
1999/07/28 (27pp) (.txt=57204) (Updates 959)
2640 is currently in proposed standard state
2773 E
Encryption using KEA and SKIPJACK, Housley R., Nace W., Yee P.,
2000/02/14 (9pp) (.txt=20008) (Updates 959)
2773 is experimental
2389 PS
Feature negotiation mechanism for the File Transfer Protocol, Elz R.,
Hethmon P., 1998/08/21 (9pp) (.txt=18536) (See Also 959)
and 2389 is proposed standard state ... but doesn't update 959 but refers to it.
=========================
... also STD-3
STD-3
1122 (Stan) - Requirements for Internet hosts - communication layers
1123 (Stan) - Requirements for Internet hosts - application and support
1123 S
Requirements for Internet hosts - application and support, Braden R.,
1989/10/01 (98pp) (.txt=239721) (STD-3) (Updated by 2181, 2821)
... 1123 is standard but doesn't directly update FTP or 959 ... but does list
requirements for Internet hosts - application and support, which is also updated
by
2181 PS
Clarifications to the DNS Specification, Bush R., Elz R., 1997/07/31
(15pp) (.txt=36989) (Updated by 2535) (Updates 1034, 1035, 1123)
(DNS-CLAR)
2181 is proposed standard status
2821 PS
Simple Mail Transfer Protocol, Klensin J., 2001/04/24 (79pp)
(.txt=192504) (Obsoletes 821, 974, 1869) (Updates 1123) (SMTP)
====================
from 1123:
4. FILE TRANSFER
4.1 FILE TRANSFER PROTOCOL -- FTP
4.1.1 INTRODUCTION
The File Transfer Protocol FTP is the primary Internet standard
for file transfer. The current specification is contained in
RFC-959 [FTP:1].
FTP uses separate simultaneous TCP connections for control and
for data transfer. The FTP protocol includes many features,
some of which are not commonly implemented. However, for every
feature in FTP, there exists at least one implementation. The
minimum implementation defined in RFC-959 was too small, so a
somewhat larger minimum implementation is defined here.
Internet users have been unnecessarily burdened for years by
deficient FTP implementations. Protocol implementors have
suffered from the erroneous opinion that implementing FTP ought
to be a small and trivial task. This is wrong, because FTP has
a user interface, because it has to deal (correctly) with the
whole variety of communication and operating system errors that
may occur, and because it has to handle the great diversity of
real file systems in the world.
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: TSS/360 Newsgroups: alt.folklore.computers Date: Sat, 29 Dec 2001 01:42:40 GMTJohn Alvord writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Buffer overflow Newsgroups: sci.crypt Date: Sun, 30 Dec 2001 18:17:32 GMT"Douglas A. Gwyn" writes:
A lot of the batch-based platforms have grown up a significant signaling infrastructure along with codified & sometimes heuristic recovery processes in response to the condition.
A trivial example I've used in the past was a unix filesystem full condition that resulted in truncating a sort work file (with no recognized error indication) ... resulting in the output of the sort having maybe only 1/3rd the records and then using the results of the sort for some business application like printing payroll checks.
A batch-oriented platform had procedures for catching/traping the "full" condition, suspending the sort, calling some form of HSM/SMS to free up necessary space and then resuming the operation when enuf space was available ... as well as logging the condition which would get reviewed in the regular formal meeting at 8am.
this is also somewhat the difference between a programmer as a simple coder production software products (where everybody says the same thing about errors as they used to say about automabile manufacturing quality in the '70s ... aka it is a fact of life) and somebody providing a service (which is expected to work correctly every time). A production, industrial-strength data processing service is supposed to do whatever is necessary to make the operation work as well as possible ... even in the face of erroneous or faulty input.
random refs:
https://www.garlic.com/~lynn/96.html#8 Why Do Mainframes Exist ???
https://www.garlic.com/~lynn/98.html#4 VSE or MVS
https://www.garlic.com/~lynn/98.html#18 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/98.html#51 Mainframes suck? (was Re: Possibly OT: Disney Computing)
https://www.garlic.com/~lynn/99.html#16 Old Computers
https://www.garlic.com/~lynn/99.html#17 Old Computers
https://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2000.html#81 Ux's good points.
https://www.garlic.com/~lynn/2000.html#83 Ux's good points.
https://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
https://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001l.html#4 mainframe question
this is only slightly related my earlier postings regarding a lot of non-C programming environments tended to have 1/10th to 1/100th the buffer overflow conditions of current C programming environments ... given similar skill level of programmers (aka the semantics of the environment just kept the programmers away from making a lot of the mistakes). Also, almost all standard, production, industrial strength data-processing has extensive input data clensing operations ... where "bad" data is flagged and set aside. An analogy in the current internet would be the email virus checkers.
misc refs:
https://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
https://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
https://www.garlic.com/~lynn/2001n.html#72 Buffer overflow
pg. 12 of dec. 2001 linuxjournal has an article on the evaluation of Linux and "commercial" unixes ... where for the first time the strongest of the Linuxes are better than the weakest of the commercial unixes. One of the points was the integration of a commerical unix and the hardware from the standpoint of error handling.
An (somewhat cultural) example from batch-platform error handling and recovery (that even the best commercial unixes haven't met). basically customer service that monitors & publichs summaries of kernel reports about the hardware errors and recovery operations for all machines in all customer shops. This particular story was about a case where one vendor was expecting a total of total 3-4 errors of a particular time across all customer machines for a period of a year (i.e. not 3-4 per machine or 3-4 per month ... but a total of 3-4 for a period of a year across all machines) and when 15 were reported (instead of 3-4) there was a serious investigation.
https://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
https://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
https://www.garlic.com/~lynn/2000.html#21 Computer of the century
https://www.garlic.com/~lynn/2000.html#22 Computer of the century
https://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
for the most part ... unix hardware vendors still view what little information they have in this area as proprietary and not to be released.
a scenario involving a financial operations that has had 100% availability
for a period of six plus years (basically you do whatever is necessary
to keep things in operation ... including discarding bad input and generating
appropriate reports to minimize such occurances in the future):
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/98.html#35a Drive letters
https://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
https://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
https://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
https://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000.html#13 Computer of the century
https://www.garlic.com/~lynn/2000.html#22 Computer of the century
https://www.garlic.com/~lynn/2000c.html#45 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#47 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
https://www.garlic.com/~lynn/2000f.html#30 OT?
https://www.garlic.com/~lynn/2000f.html#54 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
https://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
https://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
https://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001g.html#44 The Alpha/IA64 Hybrid
https://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
https://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001l.html#47 five-nines
https://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
https://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
https://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Buffer overflow Newsgroups: sci.crypt Date: Sun, 30 Dec 2001 18:31:42 GMTAnne & Lynn Wheeler writes:
random refs:
https://www.garlic.com/~lynn/94.html#44 bloat
https://www.garlic.com/~lynn/98.html#4 VSE or MVS
https://www.garlic.com/~lynn/99.html#47 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
https://www.garlic.com/~lynn/99.html#49 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
https://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001h.html#1 Alpha: an invitation to communicate
https://www.garlic.com/~lynn/2001l.html#4 mainframe question
https://www.garlic.com/~lynn/2001l.html#14 mainframe question
including some of the early assurance stuff for electronic commerce:
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "blocking factors" (Was: Tapes) Newsgroups: alt.folklore.computers Date: Sun, 30 Dec 2001 20:32:11 GMT"Foobar T. Clown" writes:
the format was data blocked 4k-byte record preceeded by 64-byte record file MFD entry (some lore that original dos was patterned after a simplified cms filesytsem ... with various kinds of changes ... including MFT/FAT instead of MFD).
for the original cmsback, I did a version called vmxplc ... which blocked up to four 4k records into a single block and collapsed the MFD entry appended to the first tape block to a file.
A very large percentage of files on the tape were 4k bytes (or less) so vmfplc was mostly a 4k record (at 6250 bpi ... .65in) plus .5in inter-record gap plus 64byte record (at 6250 bpi ... .01in) plus .5 inter-record gap ... effectively .65in of data for every inch of inter-record gap (40 precent data)
For worst case scenario on small files, vmxplc changed that to 4k+64 byte record (.65in) for every .5in inter-record gap (nearly 50% increase in amount of data on a tape).
random refs:
https://www.garlic.com/~lynn/2001n.html#66 Holy Satanism! Re: Hyper-Threading Technology - Intel information.
https://www.garlic.com/~lynn/99.html#149 OS/360 (and descendants) VM system?
vmxplc also had a trick for my page-mapped file system. The VMFPLC FST record preceeded the first data block. I wanted the data block aligned on a 4k boundary ... so the 64byte FST was appended to the end of the first data block record for a file; not preceeding it. The obvious mapping would have had the sequence of vmxplc data records in the same order as the vmfplc sequence ... but collapsing multiple tape records into a single one. The problem would be if 64byte FST was prepended to a data record ... brought in on a page boundary ... the actual start of the data would be offset by 64bytes.
The VMXPLC tape I/O operation was set to read 16k+64 with starting address on 4k boundary. The residual count from the I/O operation would indicate whether exact multiple of 4k was read or some multiple of 4k plus 64bytes (indicating the start of a new file). Since all the data records came in aligned on page boundary ... and if the disk was in pagged-mapped format ... then it was a trivial page-out operation for loading from tape to disk (modulo the appended 64byte FST for start of new file). The disk->tape was even easier with simple scatter/gather i/o.
paged mapped filesystem
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/94.html#5 Schedulers
https://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#42 bloat
https://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
https://www.garlic.com/~lynn/95.html#14 characters
https://www.garlic.com/~lynn/96.html#19 IBM 4381 (finger-check)
https://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
https://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
https://www.garlic.com/~lynn/2000.html#75 Mainframe operating systems
https://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
https://www.garlic.com/~lynn/2001c.html#89 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001d.html#77 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#19 SIMTICS
https://www.garlic.com/~lynn/2001f.html#9 Theo Alkema
https://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Buffer overflow Newsgroups: sci.crypt Date: Sun, 30 Dec 2001 22:25:17 GMTAnne & Lynn Wheeler writes:
30% hit to existing frameworks (new &/or changed code) 30% new frameworks (for industrial hardening features)
the basic concept was to try and move a lot of the 4-10 times code size increase to take a "normal" application and turn it into something that could be used in a service ... and move as much of those things being done by every "service" programmer into the underlying infrastructure ... so the increase from "normal" application to "service" application might only be a two times increase (instead of 4-10 times) ... aka only as much "service" oriented code as in the base, straightline application code.
random refs:
https://www.garlic.com/~lynn/2000.html#10 Taligent
https://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2000e.html#48 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Secret Key Infrastructure plug compatible with PKI Newsgroups: sci.crypt Date: Mon, 31 Dec 2001 01:02:51 GMTedwardhuff@netscape.net (Edward J. Huff) writes:
and what has been piloted by NACHA for the debit network.
https://www.garlic.com/~lynn/x959.html#aads
a hardware token with a single public/private key pair can have the
public key recorded in large number of different places ... and
doesn't have the downside of shared-secret key implementations
(i.e. have to use different secret key for each security domain
.... wouldn't due to have your ISP knowing the secret key that also
gets you into your bank) ... also AADS chip strawman at
https://www.garlic.com/~lynn/x959.html#aads
... i would somewhat describe this as more of digital signature infrastructure ... business process plug-compatible with existing shared-secret key infrastructures (aka retains all of the business processes of existing shared-secret key operations .... but slightly changing the technology and eliminsates a lot of the well documented short-comings of shared-secret keys).
These scenarios are that digital signatures require online support .... it is that digital signatures can flow with the transaction .... whatever way the transaction has to flow. Digital signature isn't necessary an offline or online attribute ... digital signature is a authentication attribute ... offline/online tends to be an underlying business process issue as opposed to purely authentication issue.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/