List of Archived Posts

2004 Newsgroup Postings (05/27 - 06/26)

Usenet invented 30 years ago by a Swede?

before execution does it require whole program 2 b loaded in

Text Adventures (which computer was first?)

Need to understand difference between EBCDIC and EDCDIC

Infiniband - practicalities for small clusters

Adding Certificates

Adding Certificates

Text Adventures (which computer was first?)

network history

Need to understand difference between EBCDIC and EDCDIC

IBM's Electronic Data Interchange Support

Infiniband - practicalities for small clusters

network history

Infiniband - practicalities for small clusters

Infiniband - practicalities for small clusters

Infiniband - practicalities for small clusters

Infiniband - practicalities for small clusters

Infiniband - practicalities for small clusters

Infiniband - practicalities for small clusters

HERCULES

Infiniband - practicalities for small clusters

Infiniband - practicalities for small clusters

Infiniband - practicalities for small clusters

|d|i|g|i|t|a|l| questions

|d|i|g|i|t|a|l| questions

Infiniband - practicalities for small clusters

network history

Infiniband - practicalities for small clusters

Most dangerous product the mainframe has ever seen

[IBM-MAIN] HERCULES

network history

network history

network history

network history

network history

network history (repeat, google may have gotten confused?)

network history

network history

Infiniband - practicalities for small clusters

spool

IBM 7094 Emulator - An historic moment?

[URL] (about) passwords

command line switches [Re: [REALLY OT!] Overuse of symbolic constants]

Sequence Numbbers in Location 73-80

Sequence Numbbers in Location 73-80

command line switches [Re: [REALLY OT!] Overuse of symbolic constants]

PL/? History

PL/? History

Hercules

Adventure game (was:PL/? History (was Hercules))

Chained I/O's

Channel busy without less I/O

Chained I/O's

Chained I/O's

effeciently resetting a block of memory

The WIZ Processor

War

Adventure game (was:PL/? History (was Hercules))

Usenet invented 30 years ago by a Swede?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Usenet invented 30 years ago by a Swede?
Newsgroups: sci.archaeology,soc.culture.nordic,soc.history.medieval,soc.history.science,comp.protocols.tcp-ip
Date: Thu, 27 May 2004 17:38:15 -0600

Philip Deitiker writes:

The first personal computer I personally saw as a 8Kb Z80 based
kodak in which you had to supply a cassette tape recorder to
feed in the programs and store them. A TV set with the lousiest
resolution you ever saw, the device had a keypad on it, but it
was not a keyboard. Way back in the early days people actually
used cassette records instead of disk drives. In 1982 when I
learned how to program it was done using punch cards encoded
with Fortran V written on terminals run by something called
Music, and the cards were then processed, usually overnight.
Next day you find out how many misspelling errors you made.
It took about a week to debug a program you would not even
created errors in with Visual Basic (option explicit turned on)
today.

the first personal computer i saw was a 64kb 360/30 that the
university would let me have from 8am sat until 8am monday (actually
they nominally shutdown the computing center over the weekend and i
could check in 8am sat morning and pull a 48hr shift and then have to
possibly worry about staying awake another 8-10 hrs for monday
classes).

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

before execution does it require whole program 2 b loaded in

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: before execution does it require whole program 2 b loaded in
Newsgroups: bit.listserv.ibm-main
Date: Thu, 27 May 2004 17:53:10 -0600

gilmap writes:

At one time, AL3() was used pervasively, perhaps by both coloro che sanno
and mandolinisti.  I suspect its vestiges are yet prevalent.

... note as an aside ... a lot of the os system services macros forced
alignment of mixed data & instructions with appropriately generated
cnops (program origins were assumed to be at a minium double word
aligned ... so system services macros could calculate alignment at
double word level by the displacement from the program origin and
taking on faith the program would be at a minimum double word
aligned).

cms system call macros skipped the cnops and just allowed fullword
constants (even relocatable adcons) to be half-word aligned following
the svc instruction.

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

Text Adventures (which computer was first?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Text Adventures (which computer was first?)
Newsgroups: alt.folklore.computers
Date: Thu, 27 May 2004 18:20:25 -0600

Peter Flass writes:

No, you're not.  Take a look at Hercules, an open-source IBM mainframe
emulator for Windoze/Linux, etc.  Legal versions of MVS 3.8J and
VM/370 (rel 8?) are available with the software you'll need bundled.
These aren't the most recent OS's, but, particularly from a
programmer's POV are pretty close to everything but the newest 64-bit
stuff.

the last "release" of vm/370 was 6. this was the transition period
when ibm was charging for application software (as of the unbundling
announcement 6/23/69) but not operating system software ... and
starting to charge for all software.

after unbundling ... the theory was that operating system software
could be shipped for free because it was necessary to make the machine
run (and therefor there was an excuse for "bundling" the kernel with
the machine).

with mainframe clones appearing and customers getting operating systems
for "free" ... there was a transition to figuring that kernel software
could be charged for ... totally independent of any past "bundling"
questions.

I got to be the guinea pig with the resource manager for the first
charged for kernel software (the privilege I got to spend more time
than I thot I would ever need to learning about business and pricing
models). The initial logic was that the feature wasn't actually necessary
to make the hardware operate ... it just made it operate
better. random resource manager refs:
http://www.garlic.com/~lynn/subtopic.html#fairshare

this was for vm/370 release three.

then vm/370 release four was going to ship ... base system again for
free. the problem was a lot of release four was support for
multiprocessors ... which had been architected/designed based on a lot
of features in the resource manager (which was charged for). random
multiprocessor refs:
http://www.garlic.com/~lynn/subtopic.html#smp

the resolution was to repackage about 80 percent of the resource
manager code as part of the base (free) release 4 ... and continue to
charge the same price for the abbreviated, slimmed down "release 4"
resource manager.

release five and six had more and more kernel features being packaged
as part of charged for add-ons.

Finally come release seven time-frame and the decision was made to
have a single kernel package with a flat-rate price for the whole
thing. No more somewhat artificial distinction of what was free and
what was charged for ... everything was charged for. This appeared to
be somewhat motivated by the proliferation of 370 clones ... in effect
getting free operating system at IBM's expense.

In any case, the name was changed to VM/SP (release 1; instead of
vm/370 release 7 with a slew of optional extra priced features).

So what is likely to be out there is the base release 6 ... the last
"free", non-changed for release (w/o any of the priced add-ons).

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

Need to understand difference between EBCDIC and EDCDIC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Need to understand difference between EBCDIC and EDCDIC
 charterset.
Newsgroups: bit.listserv.ibm-main
Date: Thu, 27 May 2004 22:00:02 -0600

"John S. Giltner, Jr." writes:

I would say that the "EDCDIC" is a typo, especially since the file
name on one of the links i EBCDIC and the table names on the other
links are also EBCDIC.  Only in the column header of the second table
does it change to EDCDIC.  Some other references I found for "EDCDIC"
stated that it is the code used on IBM mainframes, which do not use
EDCDIC but do use EBCDIC, in fact in one paper it used the terms
EBCDIC, EDCDIC, and EDCIC to describe the the coding used on an IBM
mainframe.

if you have your trusty green card ... quite a bit of it
is seven(/eight) columns with:

decimal
hexadecimal
mnemonic (aka if there is instruction opcode with that value)
graphic & control symbols BCDIC (aka pre-360)
graphic & control symbols EBCDIC
7-track tape BCDIC
punched card code
system/360 8-bit code

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Fri, 28 May 2004 06:42:09 -0600

glen herrmannsfeldt writes:

What about CALL/OS, or possibly slightly different names
for similar systems?

I did use it some years ago, and it seemed to work pretty
well, though it was somewhat more limited than I
thought it needed to be.

was subsystem monitor that was at least loaded by standard os/360 and
ran on any of the real memory 360s. the 360/67 was the only official
product with hardware translation & virtual memory (although cambridge
had done custom relocation hardware on a 360/40 for the original
virtual machine system, cp/40).

apl\360 was similar ... cps (conversational programming system), etc;
there were some number of terminal oriented multitasking monitors that
were developed for real-memory 360s. most of them operated with
limited sized workspaces that were swapped (say 8k to maybe 32kbytes)
... some analogy to ctss ... except there was double layered operating
system; the base real-memory 360 operating system ... with an
interactive monitor layered over it, handled the terminals and
swapping.

slightly more primitive/powerful were the conversational job entry
...  basically a terminal editor with job submission and
retrieval. TSO was sort of in that genre. I had done something similar
at the university, taking the CMS editor syntax and re-implementing it
from scratch. Putting 2741 & TTY support and re-implemented CMS editor
into HASP. also original wylbur done at stanford:
http://datacenter.cit.nih.gov/interface/interface206/if206-01.htm
http://portal.acm.org/citation.cfm?id=362234&dl=ACM&coll=portal
http://portal.acm.org/citation.cfm?id=801770&dl=ACM&coll=portal

tss/360 was the official virtual memory operating system for the 360/67.
cp/67 virtual machine (and virtual memory) operating system was developed
by the science center (although it was somewhat a port from cp/40 from
the custom modified 360/40):
http://www.garlic.com/~lynn/subtopic.html#545tech

another virtual memory operating system develeped for 360/67 was MTS
(michigan terminal system) developed at UofMich.

tss/360 sort of continued to limp along after it was decommissioned as
official product. a tss/370 port was done. late '70s, a custom unix
port was done interfacing to low-level tss/370 kernel APIs which was
used inside AT&T.

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

Adding Certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Adding Certificates
Newsgroups: comp.security.firewalls
Date: Fri, 28 May 2004 08:24:58 -0600

"Beoweolf" writes:

The question is...what is a certificate's main function?

The answer is...to uniquely identify the bearer of the certificate

The problem is...I would like to add certificates to
a firewall, but I don't want to configure the firewall

The answer is...No, Your identity (online) is tied to your IP address, if
you change your IP address, you will need to renew your certificates. If you
do not provide an IP address, you have not satisfied the requirement, having
an IP address, which is needed to certify the source,  your identity.

basically a certificate is to bind some information to a public key,
typically for use in an offline environment.

typically somebody generates a digital signature, appends a certificate
and transmits it.

the receiver eventually gets the transmission, uses (public key in)
the certificate to verify the digital signature and then has some
comfort that the transmission is somehow related to the information
bound in the certificate. the type of information bound in the
certificate might be identity or even permission related.

the typical business process has the receiver looking up some
available account record for the information instead of with a
certificate.

certificates had a design point from the early '80s for offline email
... the environment where somebody dialed up their "post office",
exchange email, hung up and processed the email offline. the
certificate was designed to serve an introductory function when the
recipient had never previously had any communication with the sender.

the function of the certificate was to serve as a substitute, in an
offline electronic environment of the early 80s, for access to the
real information. In a firewall scenario ... the lack of RADIUS-like
function being able to access the real information.

the x.509 identity certificate standards (somewaht from the early 90s)
started to run into problems by the mid-90s because of the serious
privacy issues related to having potentially enourmous amounts of
privacy related information flying around in such certificates.

Somewhat in an attempt to preserve the certificate paradigm and
demonstrate some marginal utility for certificates ... there was some
effort to retrench the x.509 identity certificate to something called
a relying-party-only certificate ... which basically contained only an
account number and a public key. Some financial operations
demonstrated such an implementation in conjunction with various
payment related operations.

There was some serious issues with this mode of operation.

1) it was trivial to show that in such a relying-party-only
scenario; the certificate was redundant and superfluous. by definition
if you have to access the account record with all the real
information, then the certificate doesn't actually contain any useful
information, making the existance of the certificate redundant and
superfluous. it also violates the basic assumptions of the certificate
design point, a substitute in an offline environment for access to the
real information.

2) even relying-party-only certificates could get to fairly
large, even to the 4kbyte to 12kbyte range. in the payment attachment
scenario; the typical payment message is 60-80 bytes, containing the
account number and the amount of the transaction. In the
relying-party-only scenario a 128byte digital signature would
be attached to the payment message followed by the digital
certificate.  This is sent to the relying-party financial institution
that has all the information in an account record (including a copy of
a public key). The destination financial institution pulls the account
number from the payment transaction, reads the account record,
retrieves the public key and verifies the digital signature. At no
time did it need to resort to referencing the certificate. So in an
attempt to demonstrate some marginally utility for a relying-party-only
certificate, append a certificate that need never be used but does
result in payload bloat of a typical payment message
approximately one hundred times.

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

Adding Certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Adding Certificates
Newsgroups: comp.security.firewalls
Date: Fri, 28 May 2004 09:48:36 -0600

Mailman writes:

I don't know where you got that idea, but it just doesn't work that
way.

A certificate is a third party confirmation of your NAME, not your
address.  Thus a server certificate (which is probably what the OP
was asking about) simply confirms that the server www.serv.com
really is www.serv.com. What the IP address is has nothing to do
with this: that is the job of the DNS.

Look up the definition of the certificate fields for X509.

As to "adding certificates to the firewall" - the question is
meaningless. A firewall has no certificates, nor does it use them. A
certificate is almost always connected to an application (Web
server, EMail server, proxy, browser, EMail client, VPN, etc), so
you need to look for the documentation for those.  -- Mailman

domain name server certificates exist because of trust issues with the
domain name system and am I really talking to the server I think that
I'm talking to.

basically 3rd party certificatation authority is asked to certify that
i'm really the owner of the domain name and issue a certificate to
that effect.

the client types or clicks on a URL ... the browser goes off and
contacts the server, the server sends back a certificate ... the
browser checks to see if it is a valid certificate (using a table of
certification authority public keys that have somehow been loaded into
the browser at some time) and then checks to see if the domain name in
the certificate matches the typed or clicked on value. so one of the
exploits is to get the user to click on a field that actually points
to a domain name that matches a certificate that a bad guy might
happen to have.

now, the 3rd party certification authorities ... in order to certify
somebody is really the domain name owner ... have to contact the
authoritative agency for domain name ownership; which turns out to be
the domain name infrastructure ... this is the same entity that people
supposedly have trust issues with and therefor believe they need
certificates.

now, 3rd party certificate authorities have some trust issues and
process issues with domain name infrastructure also ... there happen
to be a number of proposals to improve the integrity of the domain
name infrastructure ... some of them being backed by the 3rd party CAs
(if people can't trust the source of the information for the certified
infomration, how can they trust the certificate).

one of these proposals somewhat from the 3rd party CA industry,
involve a domain name owner registering a public key with the domain
name infrastructure at the same time they register their domain name.
Future interaction between the domain name owner and the domain name
infrastructure can involve digital signatures that can be validated
with the registered public key ... minimizing things like domain name
hijacking and various other exploits. So this improves the reliance
and trust that the 3rd party CA industry places in the domain name
infrastructure.

the other issue is that the 3rd party certification process is fairly
expensive identification process. the current paradigm has the domain
name owner registering a bunch of identity information with the domain
name infrastructure. when the domain name owner applies for their
server certificate, they also provide a lot of identification
information. The 3rd party CA than has an expensive and error prone
process matching the presented identification information with the
identification information on file with the domain name
infrastructure. With a public key on file with the domain name
infrastructure, the domain name owner can just digitally sign a
certificate request. the 3rd party CA then just has to retrieve the
public key on file and verify the digital signature. This changes an
expensive and error prone identification process into a much simpler,
less error prone, and less expensive authentication process.

So there is something of a catch-22 for the 3rd party certification
industry.

1) If the integrity of the domain name infrastructure is improved,
then the lack of trust supposedly will be lowered, which likely also
results in lower demand for certificates.

2) if there is a public key on file with the domain name
infrastructure (for the domain name owner) that the 3rd party
certification process can retrieve for authentication ... then
presumably other entities, like end-users and clients might also be
able to retrieve the public key for performing authentication
... eliminating the requirement for needing digital certificates
issued by a 3rd party certification authorities.

misc. past posts on ssl server certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

note that general case of using the domain name infrastructure for a
public key server (w/o needing certificates) shows up in some of the
anti-spam proposals for authenticating email senders.

part of the issue is that that the domain name infrastructure is
actually a distributed, near-real-time, information distribution
mechanism. it is currently primarily used to distribute the ip-address
related to a specific domain or host name. however, the domain name
infrastructure has also been used for serving up other kinds of
real-time data. There is nothing that prevents the domain name
infrastructure from also serving up real-time public keys that are
bound to a domain or host name.

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

Text Adventures (which computer was first?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Text Adventures (which computer was first?)
Newsgroups: alt.folklore.computers
Date: Fri, 28 May 2004 10:12:26 -0600

"Jim Nugent" <njim2k-nntp@yahoo.com> writes:

A side note: This machine was hooked up to to a BBN "IMP" (Interface
Message Processor) which was a essentailly a NIC as big as a
refrigerator and a gateway to the ARPANet (not sure it was called
that at time) aka the baby Internet. I know Stanford had one (we
could log in to their '10 and they into ours), don't know who
else... WPI?.

arpanet project defined a packet-switched network implemented with
IMPs ... which were effectively network front-end processers (FEPs)
connected to backend hosts. there were a variety of backend hosts that
IMPs connected to ... including some number of IBM mainframes.

it predated the internet and didn't support IP, internetworking
protocol. the great switch-over to internetworking and IP was 1/1/83.

one of the reasons that the internal network was larger than the
arpanet/internet up until about mid-85 was that effectively there was
gateway function in the internal network nodes allowing support for
heterogeneous networking. the internet didn't get heterogeneous
networking and ip/internetworking until the 1/1/83 switch-over.  At
the time of the switch-over, arpanet had approximately 250 nodes and
the internal network was nearing a thousand nodes (which it hit that
summer). Besides the introduction of internetworking, heterogeneous
networking, and gateways ... the other factor was that with IP, there
started to be a number of workstation and PC nodes ... while the
internal network pretty much remained a host/mainframe based
infrastructure. The internal network technology was also used for the
bitnet & earn university/research networks, some large part was also
directly or indirectly funded by the corporation.

misc. past internet post:
http://www.garlic.com/~lynn/internet.htm

some bitnet/earn posts:
http://www.garlic.com/~lynn/subnetwork.html#bitnet

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

network history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: network history
Newsgroups: alt.folklore.computers
Date: Fri, 28 May 2004 15:49:14 -0600

cstacy@news.dtpq.com (Christopher C. Stacy) writes:

I'm confused by a couple of these statements.  First, I thought that
the IBM network was composed of IBM systems, not a heterogeneous
environment.  Second, the ARPANET was all about heterogeneous
networking: connecting all different kinds of hardware and software
systems together.  What is it that you mean by "heterogeneous
networking"?

double check ... all of the network was homogeneous IMPs ... there may
have been heterogeneous systems ... but the heterogeneous nature of
the systems were hidden behind the homogeneous IMs and homogeneous
networking infrastructure.

the big innovation with the 1/1/83 switchover was the introduction of
internetworking and gateways .... so that different networks ... even
different heterogeneous networks ... that was somewhat why the term
"internetworking" was chosen ... to be able to interconnect different
networks.

a possible semantic queue/clue to the difference before and after the
great 1/1/83 switch-over ... was that the after networking was the
"internetworking protocol" ... giving rise to the the abbreviated term
"internet"

the internal network may have been homogeneous machines ... as opposed
to heterogeneous hosts ... but there was, in fact a number of
different operating systems for those machines along with different
network.

the mainstay for the internal network was the networking support
developed at the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech
the same place that developed virtual machine operation systems,
cp/67, the origins of vm/370, cms, gml (which begate sgml, html,
xml, etc) and a number of interactive offerings.

a lot of people are more familiar with the mainframe batch system
networking of NJI in JES2 (somewhat derived from the TUCC networking
modifications to HASP). HASP had a one byte table for psuedo unit
record devices ... and the TUCC/NJI networking support mapped
networking nodes into the remaining entries in the 255 psuedo device
table.

this network support was more akin to the arpanet in that it had an
extremely strong homogeneous implementation ... in addition not be
able to define more than 255 networking nodes (at most, a typical JES2
installation might have 60 defined psuedo unit record devices, so the
maximum number of defined networking nodes was more like 200 or less).
JES2 also had the downside that if it encountered traffic where either
the origin node or the destination node wasn't in its network table
... it was trashed.

The homegeneuous nature of the JES2 implementation was possibly even
stronger than the arpanet/imp implementation ... with the added
downside that the JES2 networking implementation was in the batch
operating system kernel ... and if JES2 crashed it was likely to crash
the whole system. There was the famous scenario where a system in San
Jose upgraded its JES2 networking and started injecting files into the
network ... and some that eventually arrived in Hursley caused the
hursley systems to crash.

The VM networking implementation was used for the internal network
backbone ... since it didn't have network node limitations AND didn't
trash traffic where it didn't recognize the origin (it somewhat had to
know the destination in order to route the traffic). The VM network
implementation allowed much more freedom and ease in network growth
than the JES2 implementation.

Also the gateway function was used to interface arbitrary protocols to
vm network node .... and because implementations like JES2 was so
fragile ... there eventually evolved all sorts of special VM network
gateway functions. Special drivers were built for VM gateways that
would be used when connecting to specific JES2 systems. It became the
responsibility of the VM systems to see that the JES2 system didn't
crash. The VM drivers would have special code that recognized JES2
transport headers that were at different version and/or release level
than the immediate system it was communicating with ... and would
convert the headers to acceptable format to avoid crashing locally
connected JES2 systems. Besides not having the homogeneous nature of
the JES2 systems, basically embedded gateway capability to deal with
many different interfaces, pretty much free from network node
limitations, and wouldn't trash traffic from origins that it didn't
recognize (possibly recently connected machines somewhere in the
network).

These capabilities the arpanet didn't really get until the great
switchover on 1/1/83 to the internetworking protocol ... which then
basically begate the attribute "internet".

some misc. internet archeological references:
http://www.garlic.com/~lynn/rfcietf.htm#history

note if you instead seelect
http://www.garlic.com/~lynn/rfcietf.htm
and then select "misc historical references" when the referenced
historical RFC numbers are selected, the corresponding RFC summary
will be brought up in the lower frame. And as always ... clicking on
the ".txt=nnnn" field in the RFC summary retrieves the actual RFC.

random past post mentioning heterogeneous/homogeneous network issues
http://www.garlic.com/~lynn/2004g.html#7 Text Adventures (which computer was first?)
http://www.garlic.com/~lynn/99.html#206 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy   Berners-Lee
http://www.garlic.com/~lynn/2000.html#74 Difference between NCP and TCP/IP protocols
http://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#13 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#30 Is Tim Berners-Lee the inventor of the web?
http://www.garlic.com/~lynn/2001e.html#16 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001l.html#35 Processor Modes
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#35 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#48 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#79 Al Gore and the Internet
http://www.garlic.com/~lynn/2002q.html#35 HASP:
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003h.html#7 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003h.html#9 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003h.html#16 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003l.html#0 One big box vs. many little boxes
http://www.garlic.com/~lynn/2003m.html#25 Microsoft Internet Patch
http://www.garlic.com/~lynn/2003n.html#44 IEN 45 and TCP checksum offload
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004e.html#12 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
http://www.garlic.com/~lynn/2004f.html#30 vm
http://www.garlic.com/~lynn/2004f.html#35 Questions of IP

random past post mentioning the great 1/1/83 switchover
http://www.garlic.com/~lynn/2001c.html#4 what makes a cpu fast
http://www.garlic.com/~lynn/2001e.html#16 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001l.html#35 Processor Modes
http://www.garlic.com/~lynn/2001m.html#48 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001m.html#54 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#5 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#6 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#87 A new forum is up! Q: what means nntp
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002b.html#53 Computer Naming Conventions
http://www.garlic.com/~lynn/2002b.html#58 ibm vnet : Computer Naming Conventions
http://www.garlic.com/~lynn/2002g.html#19 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#35 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#40 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#71 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002h.html#5 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002h.html#11 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#48 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#79 Al Gore and the Internet
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002k.html#19 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002l.html#48 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002o.html#17 PLX
http://www.garlic.com/~lynn/2002q.html#4 Vector display systems
http://www.garlic.com/~lynn/2002q.html#35 HASP:
http://www.garlic.com/~lynn/2003c.html#47 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#59 unix
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003f.html#0 early vnet & exploit
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#51 vnet 1000th node anniversary 6/10
http://www.garlic.com/~lynn/2003h.html#7 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003h.html#16 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003h.html#17 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003i.html#32 A Dark Day
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003l.html#0 One big box vs. many little boxes
http://www.garlic.com/~lynn/2003m.html#25 Microsoft Internet Patch
http://www.garlic.com/~lynn/2003n.html#44 IEN 45 and TCP checksum offload
http://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004d.html#13 JSX 328x printing (portrait)
http://www.garlic.com/~lynn/2004e.html#12 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
http://www.garlic.com/~lynn/2004e.html#30 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004f.html#30 vm
http://www.garlic.com/~lynn/2004f.html#32 Usenet invented 30 years ago by a Swede?
http://www.garlic.com/~lynn/2004f.html#35 Questions of IP
http://www.garlic.com/~lynn/2004g.html#7 Text Adventures (which computer was first?)

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

Need to understand difference between EBCDIC and EDCDIC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Need to understand difference between EBCDIC and EDCDIC
 charterset.
Newsgroups: bit.listserv.ibm-main
Date: Fri, 28 May 2004 16:08:02 -0600

shmuel+ibm-main@ibm-main.lst (Shmuel  Metz , Seymour J.) writes:

I don't say any such thing. ASCII is American Standard Code for
Information Interchange; it is a standard, and anything not matching
the standard is by definition not ASCII. Any binary computer can use
ASCII, and any binary computer can use other character sets; "ASCII
computer" is as meaningless as "multiple linear regression computer"
or "payroll computer".

for those that don't remember, the 360 PSW bit definition 12 was
"USASCII mode" ... which was dropped in 370 (again from my trusty
green card).

there actually used to be another subtle difference ... i had
put TTY support into CP/67 at the university ... and wrote a punch
of code to drive the 2702 to extend the existing cp/67 2741/1052
automatic terminal detect to also do automagic 2741/1052/TTY terminal
detect. I pretty well tested it out when the IBM CE informed me
that it wouldn't work reliably ... that while the 2702 allowed
you to reassign line-scanners to any line with the SAD command ...
they had taken a shortcut in the implementation and hardwired
the oscillator to lines (determining the baud rate).

somewhat as a result there was a project start to build a clone
controller ... where we've gotten blamed for originating the
pcm controller business
http://www.garlic.com/~lynn/subtopic.html#360pcm

so i had built the ascii->ebcdic and ebcdic->ascii translate tables
(somewhat borrowed from btam) and was using them with cp/67 tty
support on the 2702.

the 2702 clone was originally built out of an interdata/3 minicomputer
and a channel interface board from reverse engineering the ibm channel
interface. the first bytes we got into storage ... we thot was cause
for celebration ... but it turned out that it looked like garbage.  we
had overlooked the fact that ibm linescanner convention places the
leading bit in the low-order bit position. communication ascii data
arriving in 360 memory had every byte bit-reversed. The translation
tables took care of the fact that they were dealing with bit-reversed
ascii bytes. in order to fully emulate the 2702 ... our clone also had
to do bit-reversal on every ascii byte.

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

IBM's Electronic Data Interchange Support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's Electronic Data Interchange Support
Newsgroups: bit.listserv.ibm-main
Date: Fri, 28 May 2004 18:15:05 -0600

poitras writes:

EDI is much more that that. From wikipedia:

"EDI is still the engine behind 95% of all electronic commerce transactions
in the world"

http://en.wikipedia.org/wiki/Electronic_Data_Interchange

It wouldn't surprise me if dozens of IBM products incorporated some EDI
elements. It's been around for over 30 years. Websphere is the current
spot where IBM seems to be concentrating their EDI efforts.

Although I suppose IBM might have some product called "EDI", if I had
gotten this call, it would have sounded to me something like, "How long
will my release of LU 6.2 be supported?"

LU6.2 may be way to modern ... i was doing search for some stuff about
protocol between controller and 327x terminal ... and happen to stumble
across history reference to EDI being closely tied to bisynch.

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Fri, 28 May 2004 21:41:11 -0600

"Stephen Fuld" writes:

The driving requirement in the early 70s (pre virtual memory) was the TSO
environment.  You don't want to have to have every user, when his program
was swapped out due to quantum expiring, waiting for user input, etc. to
have too be reloaded back at the same memory location from which it was
swapped out.

tso had well acknowledged, extremely poor human factors .... in the
mid to late 70s (after virtual memory w/mvs) there was a big
performance and human factors issues with 3274/3278 making it
difficult to deliver subsecond response. something of a stock answer
was that the majority of people using 3278s aren't expecting (or can't
expect) subsecond response anyway. the 3272/3277 added a pretty
consistent tenth of a second hardware latency (regardless of factors)
.... the 3274/3278 generation increased the hardware latency to over a
half second minimum ... but it could vary to quite a bit more based on
how much data was being transfered or other concurrent factors. I was
providing an infrastructure that under heavy load had .11 second
system response for 90th percentile of trivial interactive
commands. Coupled with 3272/3277 hardware latency ... that made it a
little less than quarter of a second. Most TSO sysadmins talked
glowingly about being able to provide any sort of avg. system response
that came even within spitting distance of a second.

i've repeatedly commented that tso was little more than a crje
implementation .. and one of the poorer ones at that. it was never
suppose to be a human factors interactive system ... the batch
applications didn't need base/bound ... and it wouldn't have actually
been able to cost justify base/bound based on TSO ... because that
wouldn't have been sufficient to fix TSO thruput.

we had an interesting situation with one datacenter having a heavily
loaded 168 MVS system in the late 70s sharing disk farm with a heavily
loaded 168 VM/CMS system. There was an edict that controller strings
of disk were nominal dedicated exclusively to one system or another
(primarily to eliminate the performance polution that would happen if
a MVS disk was being access thru a controller that was nominally
reserved exclusively for VM).

One day, the MVS system administrator inadvertantly mounted a MVS disk
on a drive nominal designed as VM exclusive. Within a couple of
minutes the VM/CMS users started irate phone calls to the datacenter.

It turns out that OS/360 genre of operating systems have a nasty habit
of using multi-trark searches on nearly all of their disks ... which
results in horrible busy conditions on channels, controllers, and
drives ... which, in turn leads to horrible response latency
characteristics. TSO users aren't aware of it because their response
is always horrible. However, a single MVS disk on a nominal string of
16 VM drives sharing the same controller was enough to send all the
affected vm/cms users into severe apopolexy within a few minutes.  If
a single MVS disk sharing a controller that is nominally 15 VM/CMS
disks ... sends vm/cms users into severe apopoplexy ... can you
imagine what 16 MVS disks on an MVS dedicated controller string does
to the latency on an MVS system? ... it is several times worse
... however the TSO users are so beaten down that they don't even
realize it.

in any case, back to the story ... the vm staff asked the mvs staff to
move the disk back to one of their "own" controller strings. The MVS
staff declined because it might interrupt some application in process
using the disk. SO .... we had this highly souped up VS1 system
tailored for running under VM/370 ... which also uses the os genra of
multi-track search conventions. We got one of the VS1 packs mounted on
an MVS string with the MVS system disks ... and cranked up an
application under VS1 (under VM on a otherwise heavily loaded 370/158)
... and brought the 370/168 MVS system nearly to its knees.  At that
point the MVS staff decided that they would swap drives ... and mvs
disks would be kept on the mvs side and vm disks would be kept on the
vm side.

the point of the story is that there are a huge number of factors in
os/360 contributing to horrible tso response ... even after move to
mvs virtual memory infrastructure ... which in theory is a far
superior solution than the base/bound swapping ... and it still
couldn't improve TSO.

it is some of the reasons that most of the internal software
development programming was done on internal vm/cms systems
... regardless of what software was being development and/or for what
platform.

I also provided support and infrastructure for the internal HONE system
that was the online infrastructre for the worldwide field, branch,
marketing and sales people. The US HONE complex had close to 40,000
users defined. This was all VM/CMS based also ... and was one of the
largest online time-sharing services at the time (although purely
internal again). random hone refs:
http://www.garlic.com/~lynn/subtopic.html#hone

as to one of your other comments ... there was at least one paper
published in the 70s claiming corporate credit for virtual memory.
The author of one of the letters to the editor going into gory detail
about why it wasn't true ... showed me the letter before he sent it
off.

so another mvs CKD story ... in the late '70s there was a large
national retailer that had their datacenter in the area. they had
multiple systems sharing very large disk farm ... somewhat with
specific complexes dedicated to specific regions of the nation.
Sporadically during the day their retail applications suffered
extremely bad performance degradation ... and nobody could explain
why. I was eventually called in and brought into this class room with
dozen or so student tables ... each about six feet long... about half
were completely covered with one foot high stacks of fan-fold printer
output. The output was detailed performance numbers of processer
utilization and device activity at 10-15 minute snapshots ... for each
processor in the complex covering days & days of activity.

so i get to examining thousands and thousands of pages of this output.
after an hour or so of looking at reams and reams of performance
numbers and asking what periods had the bad performance and what
periods didn't ... i was starting to see a slight pattern on the
activity count for a specific disk amoung the very large number.  Part
of the problem was that the outputs were processor specific ...  so to
integrate the activity for a specific disk ... I had to run totals in
my head across the different system specific counts for each disk
drive (each system would report the number of I/Os it did to each
specific disk ... but to understand the aggregate number of I/Os for a
device, you had to sum the counts across all the individual system
reports and keeping the running taily from snapshot to snapshot).

So nominal load for these disks runs 40-50 i/os per second ... heavy
load might peak at 60-70 i/os per second (with a lot of heavily
optimized seek order ... or short seek distances) ... this is
aggregate for a device across the whole complex. I was starting to see
an anomaly for one disk that it was consistantly running at 6-7 i/os
per second aggregate during the periods described as bad performance.
It wasn't high or heavy load ... it just started to be the only
relatively consistent observations across the whole complex.

It turns out because it was such a low number ... nobody else had
given it much thought. So I started probing what was on the disk.
Turns out it was the application program library for all retail
applications ... large PDS dataset which, it turned out had a large
number of members and the PDS directory had been extended to three
cylinders.  Now these were 3330 disk drives that had 19 tracks and
rotated at 3600rpm or 60rps. Program loading consistented of finding
the member in the PDS directory using multi-track search. The search
operation would start on the first track on the directory and search
until it found the member name or the end of cylinder. During the
search operation, the device, the (shared) controller (which met all
other disk on that controller) and the channel were busy. It turned
out that avg. search was a cylinder an half (i.e. all searches of
three cylinder directory would on the avg. find the member after
searching half the entires). So a multi-track search for a
full-cylinder takes 19/60 seconds ... or a little less than 1/3rd
second elapsed time (during which time, a significant amount of the
disk i/o across the whole machine room was at a stand still). A search
of a half cylinder is a little less than 1/6th of a second (and a
second I/O). The loading of the member takes about 1/30th of a second
(and a third I/O). So each program member load involves half second
elapsed time ... and three I/Os. That means the disk is doing about
two program loads a second and six i/os a second ... which is very
close to what I was seeing (the avg. across the whole complex tended
to run somewhere between six iand 7 i/os per second ... some of the
program members required two disk i/os to load). It was operating at
fully saturated at 6-7 I/Os per second as well as contributing to
severe complex-wide system degradation.  Of course requests to load
application program members out of that specific library were
experiencing severe queueing delays ... since all machines and all
business regions shared the same application program library. But
constant program loading from that library was also resulting in
severe performance impact thru-out the infrastructure.

random past postings about the horrible effects of multi-track
search on latency, response, thruput, performance:
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/97.html#16 Why Mainframes?
http://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe  background
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#19 OT?
http://www.garlic.com/~lynn/2000f.html#42 IBM 3340 help
http://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#60 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#6 index searching
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002d.html#22 DASD response times
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002n.html#50 EXCP
http://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003b.html#22 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#48 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003f.html#51 inter-block gaps on DASD tracks
http://www.garlic.com/~lynn/2003k.html#28 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#37 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2003o.html#64 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004d.html#63 System/360 40 years old today
http://www.garlic.com/~lynn/2004e.html#42 Infiniband - practicalities for small clusters

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

network history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: network history
Newsgroups: alt.folklore.computers
Date: Sat, 29 May 2004 09:11:28 -0600

cstacy@news.dtpq.com (Christopher C. Stacy) writes:

I started to write a long reply to this, but I decided that
explaining it all would be a waste of time and would just
piss you off.  We're just going to have to disagree on
the semantics.  Readers of the literature will note that
the IBM interpretation of "heterogeneous networking"
is exactly opposite of what everyone else believes.

IBM has some technology called SNA ... system network architecture;
I've repeatedly commented that it is not a system, not a network, and
not an architecture. For the most part, SNA is primarily a
communication (not networking) infrastructure and a terminal control
system for very large numbers of terminals. A modest size customer
configuration might involve 65,000 connected/supported terminals.

Note that the VM-based networking technology for the internal network
was not in any way related to SNA.

SNA doesn't even actually have a network layer (in the osi model)
... there is my separate rant that ISO actually prohibited work on
protocol standards that violated the OSI model ... and
internetworking/ip doesn't exist in the OSI model and therefor is in
violation ... and can't be worked on as an ISO protocol standard.  I
was involved in some stuff that tried to get HSP (high speed protocol)
considered in (ISO chartered) ANSI X3S3.3. It would go directly from
transport to MAC. It violated OSI model in two ways: a) it bypassed
the layer 3/4 interface and b) it went directly to LAN MAC interface,
which sits in the middle of layer 3, which also violates OSI model:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

In any case, SNA doesn't even have a network layer. The closest thing
that genre has with something that has a network layer is APPN. When
APPN was about to be announced ... the SNA/raleigh crowd nonconcurred
with the announcement. It was escalated and after 8-10 weeks APPN
managed to get out an announcement letter ... but it was very
carefully crafted so as to not state any connection between APPN and
SNA.

Some of the SNA heritage is claimed to have gone back to the PCM
controller clones ... which I've gotten blamed for helping originate.
As an undergraduate, I worked on a project that reversed engineered
the ibm channel interface, built a ibm channel board interface for an
Interdata/3 and programmed it to simulate an ibm controller:
http://www.garlic.com/~lynn/subtopic.html#360pcm

The appearance of PCM controllers is supposedly a prime factor in
kicking off future system effort ... some specific quotes on this
http://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
random general posts about failed/canceled FS project:
http://www.garlic.com/~lynn/submain.html#futuresys

The death of FS ... supposedly kicked off some number of projects that
tried other methods of tightly integrating host and controllers ...
the SNA pu4/pu5 (ncp/vtam) interface might be considered one of the
most baroque.

note that the acronym "ncp" for network control program that ran in
the 3705 FEPs should not be confused with the "network control
protocol" supported by arpanet IMP FEPs.

Several years later, I tried to ship a product that would encapsulate
and carry SNA RUs over a real networking infrastructure ... simulating
a PU4/PU5 at boundary layer to host PU5/VTAM. About the time the
battle over getting APPN announced was going on ... I gave a
presentation on the effort in raleigh to the SNA TRB. Afterwards the
guy that ran the TRB wanted to know who had invited me (to make sure I
was never invited back). some related postings:
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)

It was part of some general activity that my wife and I had called
high-speed data transport (HSDT)
http://www.garlic.com/~lynn/subnetwork.html#hsdt

part of HSDT was operating a high-speed backbone for the internal
network. One of the things that flowed over the backbone was chip
designs. Chip design work went on in several places around the company
... however there was a unique, one-of-a-kind hardware logic simulator
out on the west coast ... that performed 50,000 times faster than
other methods at the time.

We also got to be effectively red team for the NSFNET1 and NSFNET2
bids (there was one meeting for NSFNET2 bid that involved my wife and
I as the red team and the blue team was something like 30 people from
seven different labs around the world) ... we weren't actually allowed
to bid. My wife did talk the director of NSF into asking for an audit
of what we were doing. The conclusion was a letter that said what we
had operating was at least five years ahead of all NSFNET bid
submissions to build something new (actually we were doing some stuff
that internet2 might get around to deploying).

the other thing we had come up with in HSDT that got us in lots of
trouble was 3-tier architecture and middle layer (the genesis of
middleware) ... this was at a time when the corporation was running
SAA and trying to at least put the client/server genie into a
straight-jacket (if not back into the bottle):
http://www.garlic.com/~lynn/subnetwork.html#3tier

There is this story (in the middle of some HSDT activity and before
NSFNET1 bid), on the friday before I was to leave on a HSDT business
trip to japan, somebody from the sna/raleigh communication group sent
out an announcement for a new online discussion group on "high-speed
networking" with the following definitions:

      low-speed               <9.6kbits
      medium-speed            19.2kbits
      high-speed              56kbits
      very high-speed         1.5mbits

the following monday, on a wall in a conference room in tokyo

      low-speed               <20mbits
      medium-speed            100mbits
      high-speed              200-300mbits
      very high-speed         >600mbits

in any case ... my assertion has been that the ease of doing gateways
was one of the critical reasons that the internal network was almost a
thousand nodes at the time when arpanet was 250 nodes .. and the
1/1/83 switchover ... effectively creating the internet (and deploying
internetworking protocol) with gateways was a prime factor in allowing
the internet to explode in size and pass the internal network in
number of nodes by the middle of 1985.

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Sat, 29 May 2004 09:51:17 -0600

"Stephen Fuld" writes:

Interesting.  I didn't know that.  On a similar vein, I recently read an
article by an IBMer on the history of disk drives (for the 50th
anneversary).  It comes very close to claiming (and certainly intimates)
that IBM invented the caching disk controller, which is equally false.  That
one hurts me personally.  :-(

the first caching disk (DASD) controller that I was aware of was the
3880-11/ironwood and 3880-13/sheriff. Ironwood was an 8mbyte, 4kbyte
record cache architecture and sheriff was a 8mbyte fulltrack cache
architecture. The earliest reference I have to ironwood is 1981.

random past ironwood/sheriff posts:
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#54 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2002d.html#55 Storage Virtualization
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2002o.html#52 ``Detrimental'' Disk Allocation
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?

When caching controlers might have been invented, I have no idea. I
know that it surprised me ... and some other people that IBM had a
patent on RAID controllers something like ten years before the term
RAID was coined.

I know about 1980 I was involved in a large amount of disk access
tracing which was used to feed a cache model. One of the things that
came out of the work was a methodology for doing real-time efficient
tracing on production systems that could be used for re-organizing
physical locality. The other was that (except for head/drive
full-track buffer for compensating for rotational delay) ... the ROI
for cache benefit/byte is at the largest common point; a single
20mbyte system file cache has more benefit than two partitioned ten
mbyte controller caches.

Of course this is consistent with my work as an undergraduate on page
replacement algorithms ... that global LRU outperformed local LRU
replacement strategies (except in some pathelogical cases) ... misc
posts on global LRU work as undergraduate in the '60s:
http://www.garlic.com/~lynn/subtopic.html#wsclock

Over ten years after my undergraduate work on global LRU in the late
60s ... there was some argument regarding a stanford phd (clock)
thesis on global LRU replacement strategies. To help resolve it ... I
was able to site an early '70s ACM paper by the grenoble science
center implementing working set dispatcher (which included a faithful
implementation of local LRU) modifications for CP/67 running on
360/67. Gernoble had a one mbyte 360/67 with 155 pageable pages after
fixed kernel requirements.

With similar workload and 35 users, grenoble got about the same
performance as the cambridge system did with 75 users on a 768k 360/67
(104 pageable pages after fixed kernel requirements) ... which was
running nearly the same version of cp/67 but with global LRU
replacement strategy. minor past ref:
http://www.garlic.com/~lynn/2001c.html#10 Memory management - Page replacement
in the above ... scroll down to the bottom of the post ... past all my
"random refs" urls .. to specific literature citings.

I used to have original copies of onion skin plotting paper with
performance curves ... and other pieces from early drafts of the
grenoble paper ... but they seem to have disappeared with the passing
of years.

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Sat, 29 May 2004 11:23:05 -0600

"Stephen Fuld" writes:

I never heard that it wasn't supposed to be a "true" interactive
time sharing system.  There were certainly other such systems
available at the time and TSO seemed to be marketed as IBM's
equivalent capability.  Certainly the sysprogs at the site I was at
thought it was that.  :-(

fundamentailly it was a glorified conversational job entry ...  there
was nothing in the infrastructure to really support time-sharing. The
"official" time-sharing system was TSS/360 ... aka Time Sharing System
.... that designed for the 360/67 with virtual memory.

there was possibly a lot of confusion with online systems and real
time-sharing systems. os/360 was pretty good at online systems ...
basically single execution contexts with huge amounts of terminals
... where the majority of each terminal specific context was some
amount of data ... not actually unique programs. Things like the
airline res systems, systems that run atm machines, etc.

in some ways TSO was term inflation ... somewhat analogous to SNA
... which was not a system, not a network, and not an architecture
... but basically a communication and terminal control system.
somewhat about that in post this monring in a.f.c:
http://www.garlic.com/~lynn/2004g.html#12 network history

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Sat, 29 May 2004 11:50:09 -0600

"Stephen Fuld" writes:

Interesting.  That seems to imply that it was actually considered by
the hardware guys and rejected as not worth the cost.  Is that true?
BTW, one advantage it would have had with the batch workload would
be to eliminate the need for the extra work that you had to do to
make pieces of program executable at any physical memory location.

i think it means that it may have been considered by the business guys
and possibly rejected because there wasn't sufficient ROI ... i.e.
how many more machines would be sold against the cost of doing it (at
least in the beginning of the 370 time-frame). the hardware issues
probably were the least of the consideration ... considering that at
least some number of the machines had it anyway (just wasn't part of
the 360/370 architecture). the next step was nominally going to the
extremely radical departure called future system (where absolutely
everything changed):
http://www.garlic.com/~lynn/submain.html#futuresys
and then the fallback was somewhat the virtual memory announcement for
370.

i got into a little of something similar with STL over supporting FBA
in MVS ... and being able to get out from under the horrible
performance impact of multi-track search conventions. They told me
that if I gave them fully developed, integrated and tested code
...  it would still cost $26m to ship it in a product and I couldn't
show any increase in disk drive sales i.e. at the time they were
already selling as many disk drives as they could make. also there
were 3375/florance drives which was basically a FBA drive with CKD
emulation overlayed on top (any sales of 3370 FBA drives could be
handled by 3375/florance flavor w/o system software impacts).

note ... i don't know what the reasoning was at the beginning of
360. there were the real memory systems with base+displacement for
batch and online systems .... you didn't have to move things in and
out a lot (except with the exception of loader overlays ... which i
don't believe was used much). online systems tended to have single
execution context and may have moved the individual terminal context
in&out ... but that was all data and wouldn't need to have any
absolute address pointers.

there was virtual memory add on for 360 in the 360/67 with the
official time sharing system (tss/360). tss/360 had defined and
implemented a position independent paradigm. people that were never
exposed to real interactive systems might equate TSO with time-sharing
just because TSO was called time-sharing option. that doesn't mean
that TSO was in any more related to time-sharing than SNA is related
to networking (and in fact, SNA is totally devoid of a network layer).

some number of machines had base&bound in the hardware ... but not
part of the 360 architecture (from what i understand it was used by
various emulators).

the change from 360 to 370 (w/o virtual memory) was primarily some new
hardware technology ... but very little architecture change. part of
this was to avoid changes to operating systems, application code,
software and/or programming paradigm. i believe some number of the
machines may have still implemented base&bound in the hardware ... but
it wasn't part of the 360/370 architecture and apparently primarily
used by various emulators.

I have 2nd hand story of ibm systems engineer (on the boeing account)
doing a highly modified version of cp/67 on real-memory 360/370 using
the base&bound hardware.

of course ... all of the mainframe machines have base&bound in the
hardware now since it is the basis for implementating the
microcode-level erzatz virtual machines called LPARs or logical
partitions.

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Sat, 29 May 2004 23:48:05 -0600

"Stephen Fuld" writes:

I was a user/victim of TSS/360 when I was a student at CMU from 68-72.  When
I got my first programming job 1972 they were running lots of (13 IIRC)
360/65s.  At that time, I believe they were all batch, but soon after than
they started experimenting with TSO/360 on a 4 plex running MVT and ASP.  I
thought TSS was dead before TSO became a reality, but I may be wrong.

tss/360 was decommited before tso became a reality ... one could
conjecture that marketing may have then felt compelled to do the name
inflation and call it time-sharing option.

even tho tss/360 was decommited ... it continued to limp along (with
some loyal customer base) and there was a port done for tss/370. it
then saw something of a revival inside AT&T with a unix port down to
low-level tss/370 APIs.

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Sun, 30 May 2004 00:46:40 -0600

the cache model i worked in 1980 was with dick mattson. there was a
lot of system stuff that could do i/o tracing all thru the 70s, this
was a technique that could effectively do i/o activity capture with
nearly no overhead and therefore could (in theory) be left on all the
time. one of the things we looked at was something like hsm/sms doing
physical reorg based on load-balancing and arm distance .. as part of
normal production operation.

the model had arm, drive, controller, channel, channel director, main
memory. since 370/303x were already max'ing out memory comfigurations
...  looked at aggregating cache memory in something like the 303x
channel director (which as i've posted before really was a 370/158 w/o
the 370 microcode ... just the integrated channel microcode).

ironwood and sheriff 3880 cache stuff were done in tucson. both were
8mbytes ... so neither were really sufficient to make a lot of cache
difference.

using 3880-11/ironwood as a paging cache ... I was able to show that
with standard strategy, the majority of pages were duplicated in both
processor memory and the 3880-ii cache. to make 3880-11 cache
effective ... i claimed that the system needed to be changed to always
do "destructive" reads to the 3880-11 controller ... so to avoid the
problem with total duplication of pages in the controller cache and
main memory. this is just another variation on the dup/no-dup (aka
duplicate/no-duplicate) paging strategy i've periodically posted
on. with the no-dup strategy ... you could start treating the 3800-ii
memory as overflow adjunct to main memory pages as opposed to normally
containing duplicates of main memory pages most of the time. pages
would get written out to the 3880-11 and they would either get
"reclaimed" later with a destructive read (eliminating duplicates in
the 3880-11 and main memory) or would age out to real disk. On a real
cache miss with a real read to disk ... you always wanted it to bypass
cache since; if it didn't, the result would be a duplicate in cache
and real memory ... which was a waste of cache. The only way you
wanted the 3880-11 cache populated was on flushing a page out of real
memory to the 3880-11.

the 3880-13/sheriff was also only an 8mbyte cache. they generated
marketing material that evironments normally got 90 percent hit
rate. I brought up the issue that a normal use of 3880-13 was with
sequential reading; a frequent configuration might be a 3380 drive
with 10 4kbyte records per track ... read sequentially. With the
3880-13, the first record read on the 3380 track is a miss, bringing
in the whole track ... which then makes the next nine sequential reads
"hits" ... or a 90 percent hit rate (as per the marketing material). I
suggested if the customer were to tweak their JCL to do 10record
buffering ... encouraging full-track reads, then the 90 precent hit
rate would drop to zero. The 3880-13 would have resulted in nearly the
same effect if it had been simple track buffering as opposed to track
caching i.e. with only 8mbytes, there was little re-use probability
over and above the sequential read scenario ... and you could have
gotten nearly the same effect with a simpler track buffer as opposed
to the more complex track caching stuff.

I also pointed out that doing a track buffer in the drive ... instead
of cache in the controller ... would pick up the marginal improvement
of out-of-order transfer ... begin read as soon as the head had
settled ... regardless of where the I/O operation says to start.

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Sun, 30 May 2004 08:09:52 -0600

Anne & Lynn Wheeler writes:

using 3880-11/ironwood as a paging cache ... I was able to show that
with standard strategy, the majority of pages were duplicated in
both processor memory and the 3880-ii cache. to make 3880-11 cache
effective ... i claimed that the system needed to be changed to
always do "destructive" reads to the 3880-11 controller ... so to
avoid the problem with total duplication of pages in the controller
cache and main memory. this is just another variation on the
dup/no-dup (aka duplicate/no-duplicate) paging strategy i've
periodically posted on. with the no-dup strategy ... you could start
treating the 3800-ii

i had somewhat come up with some of this for the resource manager.  if
you have a variety of devices for paging, 2305 fixed head disks
(12mbytes) and big moveable arm 3330s (200 mbytes) ... you would try
and keep the highest used overflow from real memory on 2305 fixed
heads. however, it could be that some stuff that pushed out to 2305
just weren't getting asked for again ... so you would periodically run
LRU for pages on 2305 and move inactive pages from the 2305 to lower
used areas on 3330s. I called this "page migration" which I put into
the resource manager (along with all the stuff of real storage page
replacement, global LRU, dispatching & scheduled ... some amount I
had actually done earlier as undergraduate in the 60s for cp/67 and it
had been dropped in the cp/67 to vm/370 transition):
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

so, instead of using the 3880-11 as a real disk controller 4k (page)
record cache ... attempt to manipulate the infrastructure so that it
effectively operated as an 8mbyte managed electronic paging device;
always using cache bypass/destructive reads on incoming (avoid having
duplicates in controller cache and real memory). the advantage it had
over a real managed 8mbyte electronic paging device was that when you
pushed things into ... and they possibly aged out ...  you didn't have
to worry about needing to run page migration on it; the internal
controller LRU algorithm would handle the aging of low referenced
data.

At this point the system needed to periodically query the controller
on cache hit statistics.  Even with all the managing ... you could
still be pushing pages into the 3880-11 at such a rate ... that they
were aged out before they were ever pulled back again. If the cache
hit rate was dropping too low ... then the system needed to start
managing the pages that were being pushed into the cache ... and start
using mechanisms that did writes to disk that avoided the cache also.

random past posts on dup/no-dup strategies for managing device/controllers
associated with paging and replacement algorithms:
http://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002f.html#26 Blade architectures
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?

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

HERCULES

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HERCULES
Newsgroups: bit.listserv.ibm-main
Date: Sun, 30 May 2004 08:17:13 -0600

IBM-MAIN@ibm-main.lst (Phil Payne) writes:

I believe IBM has a MAJOR lead in storage virtualisation with what
has so far been delivered of Storage Tank - the IBM SAN File System.
On the 25th they announced V2.1 and created the previously unseen
"SFS" acronym.  It's on IBM's site - check it out. I believe this
system embodies architectures that could eventually deliver what I
call the "data dictionary dream" across multiple platforms - yet
there is no mainframe client.

slight topic drift ... i used SFS extensively in the early to mid-80s
for a filesystem rewrite that I had done using vs/pascal ... and
moving a bunch of stuff out of the kernel previously implemented in
assembler. there are even some number of usenet posts mostly from the
90s on the work. random trivia, at the time, I also had office in
almaden.

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Sun, 30 May 2004 10:51:33 -0600

"Stephen Fuld" writes:

I have snipped a lot of stuff about the problems with the early IBM 3880
caching controllers.  Yes, when we saw what IBM had done, we were "puzzled"
in that we couldn't figure out how they had gotten things so bollixed up.
There were many problems in the design, many of which you have identified.
But let me just say that we were commonly getting 80% hit rates on typical
user workloads.  Note that we didn't need as high a hit rate as the -13 did
to achieve good performance since we were also caching writes.  In any
event, customers were almost always very pleased with the performance.  Of
course, we "benefited" from the rather limited memory size of systems in
that era.

they may have been bolixed up ... but that was dwarfed by the caches
being too small for the market they were sold into (any secondary
issues regarding the quality of the cache implementation was totally
dwarfed by the lack of quantity).  at the time of the 3880-11 & 13
controller caches ... typical configurations were 4341 16mbyte real
storage and 3033 & 3081 32mbyte real stores.

a 4341 w/16mbyte typically had single 3880 controller with 16 to
32 640mbyte drives ... which you could add an 8mbyte cache option. the
4341 was "caching" more data in real memory than was available in the
cache of the controller. in the page/4k record case it was relatively
trivial that the 4341 real storage tended to have a superset of what
was in the 3880-11 8mbyte cache ... if you operated it as a straight
cache.  i had used the dup/no-dup paradigm in the 70s ... and it also
became applicable to the 3880-11 ... and figuring out how to
manipulate the interface to bypass its caching function and attempt to
use it directly as just simply 8mbyte adjunct to real memory.

The analogy in CPU caches ... would be having a L1 cache larger than
any L2 cache ... which you could reasonably show would result in the
L2 cache being superfluous. For an extreme example, lets say that
instead of having a 32kbyte L1 cache and a 4mbyte L2 cache .. you had
a 4mbyte L1 cache and a 32kbyte L2 cache ... would the L2 cache
provide much benefit?

The is the scenario I also presented for 3880-13 full track cache.
Given that the next higher cache was larger ... then having a lower
level cache that contained less information made it redundant and
superfluous as a cache. It could somewhat be used as an elastic buffer
for attempting to compensate for some end-to-end syncronicity effect
... but it tended to not be very useful as a cache.

a 3033 or 3081 with 32mbyte might have four 3880 controllers each with
16-32 drives (for a maximum of 64-128 drives). You could add a 8mbyte
cache option to each 3880 controller ... either as a 3880-11 or as a
3880-13. Again in the 3880-11 case, it could be shown that the
majority of the pages brought thru the 3880-11 caches would exists as
duplicates of the same page in real memory (operating it as a cache,
and therefor had very low probability of being needed).

 In the case of the 3880-13 full track cache ... other than its use as
a buffer for sequential reading (in effect a read-ahead buffer as
opposed to a caching re-use buffer), the probability in general
circumstances was extremely low.  If it wasn't sequential reading
... of data it hadn't seen before ...  the other common application
was random access to databases that were tens of gigabytes in
size. The probability of a 3880-13 8mbyte cache having something from
a ten gigabyte random access database ... that wasn't already in the real
storage "cache" was extremely low ... and by the time anything might
have aged out of what's in real memory ... it surely would have aged
out of the smaller 3880 controller cache.

Given the real-live configurations ... hit rates for actual cache
re-use was near zero ... given that the real storage memories were as
large or larger than the available controller cache sizes. Majority of
the hit rates in real life would effectively be coming from the buffer
read-ahead effects (not from caching re-use effects). The processor
should only be resorting to asking for data that wasn't already in
real stroage ... and given the relative size of real storage and
the caches ... if it wasn't in real storage it also wasn't likely
to be in the caches.

it would be possible to fabricate a configuraiton ... where there
wasn't any special software changes required. Say your normal
configuration was 32mbyte 3081 with four 3880 controllers and 128
drives ... you could buy four additional 3880 controllers with
controller cache option, and use them with a single dedicated 3380
apiece. On each of the dedicated 3380s you restrict allocation to at
most say 16mbytes of data. The problem here is that there would still
be a fairly high duplicates between what was in the cache and what was
in real memory. The other problem is that both 3880 controllers and
3380 drives were relatively expensive ... so it wouldn't be likely
that one would dedicate them for a function supporting such a small
amount of data.

One way of thinking about this is that the effective size of the cache
is reduced by the data that is in both real storage and the cache
(since the processor isn't likely to be asking for data it already
has). A 8mbyte cache with high duplicates because of large real
storage ... might effectively only have 512kbytes of data that wasn't
also in real memory. That 512kbytes is the only portion of the cache
that there is possibility for the processor to ask for ... since it
isn't a very smart processor that is asking for stuff it already
has. So when you are talking about probability of cache hit rates ...
it would be the probability that the processor would ask for something
in that 512k bytes (since it wouldn't be asking for the stuff that was
duplicated and it already had).

Lets turn this around ... lets say a 8mbyte cache of no duplicates had
an 80percent hit rate (purely cache re-use ... no read-ahead buffer
effects). Then, with only 512kbyte of non-duplicates, the cache hit
would drop to 1/16th or five percent (for probability of hit rate
re-use) ... assuming purely linear effects. However there are some
non-linear theshhold effects so it could actually drop to less than
five percent.

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Sun, 30 May 2004 14:38:16 -0600

"Stephen Fuld" writes:

OK, at the risk of seeming self serving here, I will relate the
story.  First, I discount the Memorex box, which had a write through
cache in the A units (head of string) and got to a few beta sites
before being withdrawn and never heard from again.  The first cache
disk controller was developed by a company named Amperif and
installed on a cusotmer Sperry mainframe in the second half of 1980.
This was a "full cache" design, incorporating what IBM would later
call DASD Fast Write, (something IBM didn't have until the 3880-23
some time later) including a UPS and a small disk for backing up the
cache in the event of power failures (The 3880-13 was not write
through but was only usable for paging data, and the 3880-13 wasn't
even write-through, but IIRC "write-by" - it did writes directly to
the disk and invalidated the cache entry.

i never wrote any of the microcode for the 3880 ... but while the
original controller development was still up in san jose (and before
the original 3880 controller was even announced) i got suckered into
helping get it working.

i use to wander around looking for interesting things and periodically
roped into working on them. there was a joke that at one point that i
was working first shift in bldg. 28/research, 2nd shift in
bldg. 14/15, 3rd shift in stl, and 4th shift/weekends at HONE.

bldg. 14 had this machine room with some number of mainframes where
the original 3880 development was going on. these machines were in
individual "test cells" ... i.e. heavy steel mesh cages with 4-5
number combination locks, inside a secure machine room, inside a
secure bldg.  on a plant site with fences & gates.

running mvs on one of the mainframes with a single test cell being
testing had something like a MTBF of 15minutes for MVS. As a result
... process eventually settled on special stand alone test time rotating
between the various test cells ...  running special purpose monitors
on the mainframe for exercising the controllers.

I thot it would be fun to rewrite the operating system i/o supervisor
so that it never failed ... and be able to concurrently do testing
with a half dozen to dozen test cells at a time. it was something of a
challenge, but got pretty much there so eventually the machines in
bldg. 14 were running the modified system ... as well as the machines
over at the product test lab in bldg. 15 ... and then when some amount
of the controller activity was moved to tucson ... the custom
operating system was propagated to tucson also. however, i didn't have
a lot of interaction with what went on in tucson.

part of the downside was then when there appeared to be a problem
... the engineers wanted to blame me ... and I could get dragged into
helping scope whatever problem they happened to have. I also got
suckered into sitting in on conference calls between the controller
engineers in san jose and the channel engineers on processors in
POK. something of the current tv ad ... i'm not really a disk engineer
... i just play one on tv.

lots of random past posts on the fun in bldg 14 & 15; (engineering and
product test labs):
http://www.garlic.com/~lynn/subtopic.html#disk

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

Infiniband - practicalities for small clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Mon, 31 May 2004 07:21:19 -0600

"Stephen Fuld" writes:

Yes, the small size was a problem, but the lack of caching writes was a
major contributer, as writes tend to have a higher hit rate than reads (in a
controller that caches writes).  So even with a modest sized cache, you get
hits on the writes of the typical database operation of read some record,
update it and rewrite it.  In addition, you get hits on things like the
logs, that are sequential but tend to want to be written quickly, not
waiting for lots of records to accumulate, in order to reduce transaction
latency.  The 3880-13 would have looked much better performance wise, even
with its small cache if it could have taken advantage of these kinds of
operations.  I know that because our system did exactly that.  Now of
course, as with any cache, bigger is better and IBM eventually learned, with
the -23, to make the caches larger.

there is no cache hit of writing a record that has just been read. the
write completely replaces anything that has been read.

you can have (using some processor cache related terms):

1) write thru ... in which case it has to be immediately written before
signaling complete

2) write into ... with "write behind" or "lazy writes" to actual disk
later. especially for database operations write-behind/lazy-write
strategies need various kinds of countermeasures for volitile cache
memories loosing power (before the write has been performed)

you can keep the written record around in cache on the off-chance
there is a subsequent read ... which would be a cache hit.

the full-track strategy related to caching for database writes then
becomes somewhat similar to RAID-5. you are only replacing part of the
actual data ... in which case you have to possibly read the whole
stripe, update the parity record and write back the individual record
and the partity record. if you are doing full-track caching ... here
is where there is something like a cache-hit. if you have recently
read the record ... and brought in the whole track ... when you go to
write the (updated) record back, having the full-track already in a
buffer means that you can update the portion of the track represented
by the latest record write w/o having to (re)read the track ... before
writing it back out.

the issue in cache isn't by itself that bigger is better ... in part
it is that the lower-level cache needs to be (potentially
significantly) larger than the next higher level in any memory
hierarchy ... otherwise the lower-level cache tends to become totally
polluted by duplicates (and the lower-level cache never sees any hits
because they are all being satisfied by data resident in some higher
level memory hierarchy).

another of the places that such caching tends to crash & burn is with
shadowing implementations (like illustra was ... and some other
database systems, or log structured filesystems) ... where you
effectively never write back ... you always write to newly allocated
locations. for these buffered for things like helping with lazy-writes
... but the possibility of cache re-use gets to be very low.

when i asked the question of the engineers why the -11/-13 caches were
only 8mbytes ... they said something about business reasons ... which
i fail to remember what they were at the moment. I do remember that
for other products about that era ... that processors had priority
access to memory inventory and some products never got announced. say
they forcasted that half all 3880s might order or retrofit cache
... then they had to get commitment from internal memory inventory for
that number of boxes times the mbytes/box. if instead, they forcasted
a few tens of thousands, they might have gotten allocation for more
mbytes/box.

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

|d|i|g|i|t|a|l| questions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: |d|i|g|i|t|a|l| questions
Newsgroups: alt.folklore.computers
Date: Mon, 31 May 2004 06:26:55 -0600

Brian Inglis writes:

Ran same workload on similarly configured low end air cooled IBM MF:
application performance and thruput was much higher at same price
point as the VAX, with an order of magnitude expansion capability
available, and another order of magnitude available if we went water
cooled.

that was somewhat this post
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

some related about rapid explosion in mid-range market segment
during the late 70s & early 80s ... which was subsequently
subsummed by workstations and large PCs:
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

and some topic drift:
http://www.garlic.com/~lynn/2002f.html#1 Blade architecture
http://www.garlic.com/~lynn/2002f.html#5 Blade architecture
http://www.garlic.com/~lynn/2002f.html#5 Blade architecture

and even more drfit related to thread running over on comp.arch
http://www.garlic.com/~lynn/2002f.html#26 Blade architecture

http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters

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

|d|i|g|i|t|a|l| questions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: |d|i|g|i|t|a|l| questions
Newsgroups: alt.folklore.computers
Date: Mon, 31 May 2004 06:50:58 -0600

Rupert Pigott writes:

If you take the long view that doesn't coincide with what we've seen
with IBM's product lines... IBM thinking appears to be capable of
accomodating multiple lines of radically different hardware and OSes
(lots of fiefdoms). What I'm wondering is if DEC got saddled with a
bunch of guys who fell out of the IBM tree when the FS project got
shit-canned. What I read of FS is that it was intended to replace
all the various lines and do everything better somehow. Does that
sound like VAX/VMS or what ? :)

there may be two different issues here ... in the early 70s, FS was
sort of to have been another 360; a new radical generation that was
even more different than 360 than 360 had been from earlier ... lots
of posts on FS
http://www.garlic.com/~lynn/submain.html#futuresys
recent discussion of the sequence in network history thread here
http://www.garlic.com/~lynn/2004g.html#12 network history

one intepretation is that the extreme re-action to the cancelation of
the horribly complex FS resulted in some inventing the opposite
extreme, KISS risc. lots of misc. posts on risc/801/romp/rios/etc
http://www.garlic.com/~lynn/subtopic.html#801

in the early '80s there was a project, fort knox, to use 801 to
replace the large proliferation of microprocessor that had spawned all
over the cooperation. low & mid-range 370s were microcode machines (as
had been 360 before them) ... typically each having their own unique
microprocessor engine. there were loads of other microprocessors in
controllers, office products, instrument division, etc (s/32, s/34,
s/38, displaywriter, series/1, 8100, 1800, 3274, 3880, 3705, 4341,
4331, etc). Nominally, the follow-on to the 4341, the 4381 would have
been an 801 microprocessor engine. I contributed to a report that said
that technology had moved on & that it was cost effective to implement
370 in hardware for the midrange ... which was instrumental in killing
fort knox for 4381.

801/romp with cp.r was to have been the follow-on to the office
products division displaywriter. when that project got killed, the
people involved decided to retarget the platform to unix workstation
market ... resulting in the pc/rt. they hired the company that had
done the at&t unix port for pc/ix to do one of the pc/rt, resulting in
aix "2.0".

One influx of IBM'ers into DEC was from the vm370/cms development
group out in burlington mall during 76 & early 77. the decision had
been made to kill the vm370 product and move all the people from the
burlington mall group to POK to work on the vm/tool ... this was an
internal virtual machine development project (only) supporting the
development of mvs/xa for "811" ... or what became 3081 and 31-bit
addressing. some number of the people left ibm, stayed in the boston
area and got jobs at dec & prime.

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

Infiniband - practicalities for small clusters

From: lynn@garlic.com
Subject: Re: Infiniband - practicalities for small clusters
Newsgroups: comp.arch
Date: Tue, 1 Jun 2004 20:22:18 -0700

"Stephen Fuld" wrote in message news:<beKuc.103011$hH.1815333@bgtnsc04-news.ops.worldnet.att.net>...

Typical sort of "large company" problem.  :-(

large company might be a symptom rather than a cause.  two issues
that somewhat affect the situation:

1) problem with a large customer base ... which are the customers for
the product. a large customer base can be the cause ... given a large
customer base, you might have a large company as a symptom.

2) the other aspect of having a memory hierarchy. using the cpu cache
analogy ... given a situation where you effectively have the same
technology for both L1 and L2 ... and ask a customer whether they
wanted to use 8mbytes for L1 or L2 ... where the benefit/byte to the
customer was five to fifty times greater when used as L1 (compared to
using same amount for L2) ... aka given the customer had choice
between adding the same 8mbytes as main memory or controller cache.
... This also somewhat goes back to one of my original comments
implying the higher up in the hierarchy you have more memory .. the
better off you are ... and by implication, any cache memory that you
have lower down in the memory hierarchy has to be much larger than
amount higher up in the hierarchy ... if nothing else to compensate
for duplicate pollution.

some amount of controller buffered memory is useful ... as mentioned
before ... not as re-use cache ... but to handle outboard various
functions asynchronously (avoiding needing to have end-to-end
syncronicity). the amount of buffered memory needed to improve
performance by avoiding end-to-end syncronicity ... is different than
needing possibly 5-10 times larger cache lower in the memory hierarchy
as a means of compensating for duplicate pollution (as well as various
other uses that fail to conform to least-recently-used paradigm
... like large sequential reads).

network history

From: lynn@garlic.com
Date: Thu, 3 Jun 2004 10:48:33 -0700
Newsgroups: alt.folklore.computers
Subject: Re: network history

eugene@cse.ucsc.edu (Eugene Miya) wrote in message news:<40beb413$1@darkstar>...

This is completely misleading.
IMPs weren't seen at the application level.
IMP were just that INTERFACE PROCESSORS (MESSAGE).
You never saw a mesage.  They were just interfaces like connectors.
No different than differing backplanes.
>
I have to agree with a subsequent posting by Chris.
>
What's lacking is any reference to the protocols which preceded TCP.
>
It's was pretty stupid to FTP Fortran files and get inconsistent
character sets, and their interpretation of a dumb one (EBCDIC).
That is heterogeneous.
>
And this was all before email.

ok, the original assertion was that the internal network was larger
than the arpanet because the internal network had effectively
heterogeneous and gateway support from just about the start ... which
the arpanet/internet didn't get until the 1/1/83 switch-over

there was nothing about whether there was other technologies at the
transport and application layer ... and/or even that there weren't
other technologies out there. the assertion was that a big limitation
on the size of the arpanet vis-a-vis the internal network was the
difference between gateways and lack of gateways at the network
(and/or internetworking) layer. furthermore, that a big explosion in
the number of nodes on the internet after the 1/1/83 switch-over was
because it got gateway and heterogeneous support as part of the 1/1/83
switch-over ... greatly contributing to it passing the number of nodes
in the internal network by mid-85.

so as to why the arpanet had fewer nodes than the internal network
prior to 1/1/83 ... is because it had FTP at the application &
transport layer? That because the IMPs weren't seen at the application
layer is a reason that there were fewer nodes on the arpanet than on
the internal network? That the IMPs were a network layer
implementation ... and therefor not seen at the application layer is a
reason that the arpanet had fewer nodes than the internal network?

Or is it that the IMPs were networking layer implementation, were a
homogeneous networking layer implementation, and didn't have
internetworking and/or gateway ... contributed to the apranet having
fewer nodes than the internal network ... and that the introduction of
internetworking and gateways as part of the 1/1/83 switch-over allowed
a big explosion in the number of heterogeneous networking nodes
... aided by gateways part of internetworking architecture.

misc. past archeological posts on this subject:
http://www.garlic.com/~lynn/internet.htm

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

Infiniband - practicalities for small clusters

From: lynn@garlic.com
Date: Thu, 3 Jun 2004 10:48:33 -0700
Newsgroups: comp.arch
Subject: Re: Infiniband - practicalities for small clusters

nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message news:<c9mmsg$2ur$1@pegasus.csx.cam.ac.uk>...

Actually, that is how GUTS worked (Gothenburg).  Phoenix did less
modification, and used the MVT batch mechanism for jobs and TSO
for interactive work.  It was essentially a front-end and service
provider.

It did, however, have to do really quite a lot to make TSO usable.
I was probably the only person who ever wrote CLISTs under Phoenix,
and it took me a hell of a lot of politicking to get permission.

Regards,
Nick Maclaren.

one of the people that did vs/pascal left about '80 and got funding to
do a 3274 controller clone that outboarded a lot of the TSO
interactive interface in the controller ... because the TSO
performance was really so bad compared to other infrastructures. one
of the explanations why the company didn't do well was that the
majority of the people that used TSO didn't understand how really bad
it was and/or appreciate that things could be significantly better.

how truely bad tso was was also why much of the internal development
work went on under vm/cms worldwide around the company ... regardless
of the targeted platform.

Most dangerous product the mainframe has ever seen

From: lynn@garlic.com
Date: Thu, 3 Jun 2004 17:58:30 -0700
Newsgroups: bit.listserv.ibm-main
Subject: Re: Most dangerous product the mainframe has ever seen

scomstock@aol.com (S Comstock) wrote in message news:<20040603112905.16349.00000371@mb-m29.aol.com>...

In yesterday's Wall Street Journal (back page of the Marketplace
section) there was a story about Sun and Fujitsu teaming up to
jointly develop future computer systems, called the APL (Advanced
Product Line).  The last paragraph quotes Scott McNealy (Sun's CEO):
"I think the APL will be ultimately the most dangerous product the
IBM mainframe has ever seen".  Well, competition is good. But what I
found interesting is the implicit recognition of the IBM mainframe
as a major player even today. Most competitors, at least publicly,
denigrate the mainframe as not being a factor in the industry any
more. Now an open admission that mainframes are still a significant
part of the market. Somehow I find that encouraging.

remember in the past that it was fujitsu that funded and did the
manufacturing for amdahl. also fujitsu funded HaL (some number of
former beemers) before taking it over completely ... which did
the first 64bit sparc chip ... random references:
http://sunsite.uakom.sk/sunworldonline/swol-10-1995/swol-10-hal.html
http://www.hoise.com/primeur/99/articles/monthly/AE-PR-10-99-53.html
http://www.hoise.com/articles/SW-PR-12-98-28.html

[IBM-MAIN] HERCULES

From: lynn@garlic.com
Date: Thu, 3 Jun 2004 18:13:21 -0700
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Subject: Re: [IBM-MAIN] HERCULES

jmaynard@ibm-main.lst (Jay Maynard) wrote in message news:<20040601162325.GA2980@thebrain.conmicro.cx>...

Do they? I'm not so sure. It seems to me that the powers that be at
IBM want to tap the Linux geek base for the future, as their answer
to the graying of the z/OS (and, to a lesser extent, z/VM - although
there they seem to want to train the people to use VM, instead of
supplant it) workforce.

x-posting to alt.folklore.computers

original cp/67 in the '60s and then vm/370 in the '70s shipped with
all the source ... both to internal accounts within the corporation as
well as customers outside the corporation. both internal and external
customers frequently rebuilt the system completely from the source as
a common practice.

there was a study done of the vm share tape in the late 70s and
effectively of something very equivalent, the internal corporate
common tape. the vm share tape and the internal common tape had about
the equivalent number of lines of source changes, updates and/or
add-ons to the system ... which in aggregate (for both) was about four
times larger than the base product source (note however that in both
the share and common tape cases, there was some large amount of
duplicate feature/functions implemented from different installations).

i posted somewhat of a time-line of the transition of the
vm/370 kernel to charged for licensed product (note that
the time-line was similar for MVS ... although slightly
later, using vm/370 as guinea pig):
http://www.garlic.com/~lynn/2004g.html#2 Text Adventures (which computer was first?)

network history

From: lynn@garlic.com
Date: Thu, 3 Jun 2004 18:47:40 -0700
Newsgroups: alt.folklore.computers
Subject: Re: network history

jmfbahciv@aol.com wrote in message news:<40bf1bfd$0$2940$61fed72c@news.rcn.com>...

The difference is Lynn's view from inside out and our view
from outside in.

note that the original assertion wasn't about inside out or outside in
... the original assertion pertained to why was the internal network
larger (had more nodes) than the arpanet for just about the complete
life of the arpanet .... up until after the switchover to 1/1/83
... sometime mid-85.

my assertion was that the mainstay of the internal network effectively
had gateway-like function in every node ...  allowing the connection
of heterogeneous environments ...  something that the arpanet didn't
get until internetworking and the switch-over 1/1/83.

there were comments about SNA ... which was extremely homogeneous AND
didn't even have a network layer. it was designed primarily for large
terminal communication infrastructures.

then given the original assertion ... then all the comments about how
much better arpanet was all during the '70s than the internal network
... are important contributing factors for why the arpanet was so much
smaller than the internal network ... because it actually had all
these really much better features.

so is this intending to imply that all such really great technical
features were actually a disaster from a deployment standpoint (as
contributing to the fact that the arpanet was so much smaller than the
internal network)? Or is it an observation that the arpanet was so
much smaller than the internal netwokr (until it started to explode in
size after the 1/1/83 switchover) in spite of having these really,
really great features ... sort of implying that there must be some
other really enormous technical(?)  inhibitor offsetting such really
great features.

network history

From: lynn@garlic.com
Date: Fri, 4 Jun 2004 11:30:23 -0700
Newsgroups: alt.folklore.computers
Subject: Re: network history

eugene@cse.ucsc.edu (Eugene Miya) wrote in message news:<40bf69e5$1@darkstar>...

> You and Chris and I will just have to agree to disagree.
>
> I recall gateways for email before 1983.

they were application gateways, not network gateways

> NCP existed from the era before layered models.
> In that period for demo or die had lots of discussion on transparency.
> TCP was that transition.

wrong ... in fact is an example of layered model/implementation

> I think you are making some revisionist interpretations of the situation
> at the time.  Most of the other gatewayed networks didn't have the full
> functionality of the ARPAnet and other up and coming work done by
> others.  And I think that some of that can be seen reflected in the
> earliest versions of laying (descriptions not prescriptions) in Tanenbaum.

i never made any comments about whether apranet had more or less
function.  I was specifically citing that the lack of internetworking
layer and network gateways (which are part of the internetworking
layer) didn't exist in the arpanet and probably contributed to
inhibiting its growth ... and that the switch-over on 1/1/83 removed
that.

> >misc. past archeological posts on this subject:
> >http://www.garlic.com/~lynn/internet.htm
>
> Read it before Lynn.  It's your view.

actually the above reference contains some detailed information about
CSNET & its email gateway into the arpanet. note that this was a
application gateway ... not a network gateway. they are different.

the point of the original assertion was that the internal network
co-existed in the same period as the arpanet (supposedly before
layered architectures) .... and even so, the internal network
effectively had (network) gateway function in every node.

The assertion is that one of the reasons that the arpanet was
smaller than the internal network all thru the 70s ... was because the
arpanet lacked internetworking/networking-gateways until 1/1/83
switch-over ... while the internal network effectively had the
equivalent of networking gateway function in every node.

it wasn't that arpanet NCP and host protocols weren't layered. In fact
they were exceptionally layered. The issue was that they were layered
in much more of the traditional OSI model that lacked internetworking
and network-layer gateways. that the arpanet didn't deviate from the
traditional OSI layering until the 1/1/83 switch-over where it gained
internetworking and gateway layer function. Furthermore, ISO has had
rules that ISO & ISO chartered organizations can't work on
protocols that violate the OSI layered model. Since the internet's
internetworking layer and networking gateways (i.e. the networking
gateways are part of the internetworking layer which doesn't exist in
the OSI movel), that couldn't be considered in ISO.

it wasn't that there wasn't layered models during the period that
arpanet existing ... there were layered models ...  they just didn't
include (and some cases specifically mandated the exclusion of)
internetworking and networking gateways (i.e. gateways between
networks).

the switch-over to internetworking and gateways for the arpanet on
1/1/83 gave it somewhat the functionality of what the internal network
had from the start ... and therefor the assertion specifically about a
reason why the internal network was larger than the arpanet thru-out
most of its early lifetime ... until sometime mid-85.

network history

From: lynn@garlic.com
Date: Fri, 4 Jun 2004 12:07:34 -0700
Newsgroups: alt.folklore.computers
Subject: Re: network history

eugene@cse.ucsc.edu (Eugene Miya) wrote in message news:<40bf69e5$1@darkstar>...

I think you are making some revisionist interpretations of the
situation at the time.  Most of the other gatewayed networks didn't
have the full functionality of the ARPAnet and other up and coming
work done by others.  And I think that some of that can be seen
reflected in the earliest versions of laying (descriptions not
prescriptions) in Tanenbaum.

lets see what is revisionist interpretation

1) arpanet didn't have internetworking (and networking gateways that
are part of the internetworking layer) until the 1/1/83 switchover

2) the internal network was larger (had more nodes) than the arpanet
for nearly the whole period until about mid-85

3) the mainstay of the internal network had effectively (network)
gateway function in every node from the start

so which of the three claims are revisionist?

an assertion that a possible/contributing reason that the internal
network was larger than the arpanet for that period was because of the
(networking) gateway functionality. furthermore a possible reason for
the explosive growth in the internet after the 1/1/83 switchover was
the availability of internetworking and network gateways that come
with internetworking layer.

note that th