List of Archived Posts

2004 Newsgroup Postings (11/20 - 12/05)

Relational vs network vs hierarchic databases

Relational vs network vs hierarchic databases

Integer types for 128-bit addressing

History of C

History of C

History of C

History of C

Integer types for 128-bit addressing

vm/370 smp support and shared segment protection hack

vm/370 smp support and shared segment protection hack

vm/370 smp support and shared segment protection hack

History of C

360 longevity, was RISCs too close to hardware?

Mainframe Virus ????

vm/370 smp support and shared segment protection hack

Amusing acronym

Mainframe Virus ????

Mainframe Virus ????

Boyd makes wikipedia

History of C

Systems software versus applications software definitions

need a firewall

need a firewall

Systems software versus applications software definitions

Systems software versus applications software definitions

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

IBM 3705 and UC.5

IBM 3705 and UC.5

FW: Is FICON good enough, or is it the only choice we get?

IBM 3705 and UC.5

IBM 3705 and UC.5

Carrying IP over ATM networks

IBM 3705 and UC.5

IBM 3705 and UC.5

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

funny article

100% CPU is not always bad

Computers in movies

IBM 3614 and 3624 ATM's

chip inside smart card is firmware?

History of C

IBM 3614 and 3624 ATM's

(fwd) News about SIGMicro

US-CERT Technical Cyber Security Alert TA04-336A -- another buffer overflow

fc3, eamcs 21.3.1 & ls incompatibility?

History of C

History of C

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

Integer types for 128-bit addressing

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

Single User: Password or Certificate

IBM 3614 and 3624 ATM's

IBM 3614 and 3624 ATM's

Systems software versus applications software definitions

Systems software versus applications software definitions

Relational vs network vs hierarchic databases

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relational vs network vs hierarchic databases
Newsgroups: alt.folklore.computers
Date: Sat, 20 Nov 2004 13:26:22 -0700

Anne & Lynn Wheeler writes:

as an undergraduate, i had worked on an onr-funded university library
project that utilized bdam (& cics) ... which turns out to have been
similar project going on at the same time at the NIH's NLM ... using
the same technology (but much larger scale). I had an opportunity to
look a NLM's implementation in much more detail a couple years ago
with some stuff associated with UMLS ... a couple recent posts
mentioning UMLS:
http://www.garlic.com/~lynn/2004f.html#7 The Network Data Model, foundation for Relational Model
http://www.garlic.com/~lynn/2004l.html#52 Specifying all biz rules in relational data

aka:
http://www.garlic.com/~lynn/2004o.html#67 Relational vs network vs hierarchic databases

random trivia ... i'm pretty sure that the onr-funded library project
also paid for the university's 2321/datacell

various 2321 pictures:
http://www.columbia.edu/acis/history/datacell.html

in the above, it mentions 2321 having been designed by shugart.  one
of the other engineers that worked on 2321 (also) left and went off to
memorex ... later he (and another person from memorex) formed a
database hardware company. even later, when their cto left for
teradata (and later formed his on rdbms company) ... they were
recruiting in and around bldg. 28 for replacement (there were some
number of after work discussions on the subject at the resturant
across the street from bldg. 28); for old times sake, i had lunch
there on tuesday.

other totally random trivia, guess who periodically shows up wearing a
t-shirt from the (above mentioned) database hadware company.

random past mentions of 2321/datacell
http://www.garlic.com/~lynn/2000.html#9 Computer of the century
http://www.garlic.com/~lynn/2000b.html#41 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?
http://www.garlic.com/~lynn/2001e.html#42 OT:  Ever hear of RFC 1149?  A geek silliness taken wing
http://www.garlic.com/~lynn/2001e.html#50 "IP Datagrams on Avian Carriers" tested successfully
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2001n.html#61 Google Archive
http://www.garlic.com/~lynn/2002.html#16 index searching
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002f.html#3 Increased Paging in 64-bit
http://www.garlic.com/~lynn/2002g.html#84 Questions on IBM Model 1630
http://www.garlic.com/~lynn/2002i.html#26 : Re: AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002i.html#31 : Re: AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002i.html#33 "Mass Storage System"
http://www.garlic.com/~lynn/2002m.html#40 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2002o.html#9 PLX
http://www.garlic.com/~lynn/2003.html#70 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003.html#72 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#9 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#18 Card Columns
http://www.garlic.com/~lynn/2003c.html#36 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003c.html#61 RFC 3092
http://www.garlic.com/~lynn/2003f.html#28 New RFC 3514 addresses malicious network traffic
http://www.garlic.com/~lynn/2003k.html#36 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003m.html#6 The real history of comp arch: the short form
http://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#39 DASD history
http://www.garlic.com/~lynn/2004.html#5 The BASIC Variations
http://www.garlic.com/~lynn/2004.html#6 The BASIC Variations
http://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004l.html#18 FW: Looking for Disk Calc program/Exec

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

Relational vs network vs hierarchic databases

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relational vs network vs hierarchic databases
Newsgroups: comp.databases.theory,alt.folklore.computers
Date: Sat, 20 Nov 2004 14:19:12 -0700

ref:
http://www.garlic.com/~lynn/2004o.html#67 Relational vs network vs hierarchic databases

an associated issue related to indexes ... I recently commented about
in context of filesystem structures ... but it also applies to
database structures.

a big driving factor in the 60s was the limited amount of real
storage.  with the increasing amount of real storage available by the
late 70s, it became more realistic to cache index structures
... off-setting some of the performance penalty vis-a-vis direct
pointers.

some number of the filesystem implementations even leveraged real
storage to switch from disk-based paradigm to real-stroage based
paradigm (with periodic checkpointing to disk) .... enabling various
kinds of lighter weight allocation implementations (which would have
been impractical when everything was strictly disk resident).

a couple filesystem trade-off posts
http://www.garlic.com/~lynn/2004o.html#0 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#22 Integer types for 128-bit addressing

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: alt.folklore.computers
Date: Sun, 21 Nov 2004 10:19:13 -0700

Charles Shannon Hendrix writes:

Ah, that's not what I mean.

Installing an OS with default limits is not the same as knowingly making
use of them.

I mean I don't think most programers and admins make use of them.

It seems to me that those most people I've met who were aware of these
limits almost always disabled them so they "wouldn't be in the way".

That make more sense?

i originally did "fair share" as undergraduate ... which eventually
morphed into resource manager. it tracked resource consumption and
calculated future advisory deadlines. this was actually policy-based
with the default policy being fair share. tasks were ordered by
advisory deadlines ... but in effect, the only way to limit
consumption was to have contention from other tasks (if you are the
only one on the machine ... you got the whole machine).

during the '70s there were various organizations that felt they
(might?) needed mandated resource consumption limits ... regardless of
whether there was contention.

I did some stuff that if you set limit to ten percent of the machine
... you would only get ten percent, even if there was nobody else
on. In the same time-frame, i had also did one that could aggregate
users resource consumption and apply resource policies based on group
aggregates (say fair share between groups, regardless of number of
users in each group ... and then fair share within group ... sort of
hierarchical resource policy). neither of these shipped in products.

turns out that when it came right down to the rubber met the road,
datacenter administrative people didn't want to take responsibility
for setting such controls. typically, user group meetings were
contentious enuf already. datacenter admin people really didn't want
to in be in the middle of arguments about why last month, one group
got 35 percent and another group got 25 percent (they just say that is
the way the system works).

also despite all the theory, there was a lot of gut feelings about
leaving expensive computer resources idle, especially when there were
pending use (i.e. user limited to ten percent, but at the moment there
are no other users).

misc. resource management
http://www.garlic.com/~lynn/subtopic.html#fairshare

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

History of C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of C
Newsgroups: alt.folklore.computers
Date: Sun, 21 Nov 2004 12:59:14 -0700

"Jack Peacock" writes:

Linux/Unix, don't like the filesystem, roll your own.  Even VMS has
multiple file systems now, ODS-2 for old timers, and ODS-5 for those
who want lower case filenames.  Then there was the infamous Spiralog
VMS filesystem, which apparently lost all context when it ran out of
space.

Multiple concurrent filesystems aren't rare.  Even later versions of
CP/M 20 years ago supported both CP/M and MSDOS filesystems.

The problem with recovering writes on removeable media is the OS has
no idea what happens to the media while it's offline.  A USB drive
can make the rounds of several other machines before returning to
the original, with a radically different directory since the last
time it was unplugged.  Holding writes in a queue would be a
disaster in waiting.

This was a major problem on floppy systems, which led to the
hardware addition of a media change/open door signal on the
interface, along with hardware status polling in multi-drive chains.
Although IBM disabled the logic, the original floppy controller on
PCs supported four drives on one controller, with hardware polling
of the door open status line to detect and immediately interrupt if
media was removed or inserted.  Pending reads/writes could
theoretically be cancelled if a media change was triggered.

cms had its original filesystem from the mid-60s and then in the
mid-70s got the EDF (extended) filesystem ... and they co-existed. the
api semantics were the same ... but the on-disk format had several
differences as well as various operational characteristic differences.

i had originally done very low level interface changes to the regular
CMS filesystem to paged mapped interface ... and then when EDF was
introduced ... also did the low level changes to EDF to interface
it to page mapped interface. the low-level page mapped interface
was pretty transparent to most higher-level functions ... except
i did add high-level function in the loading of executables to allow
specification of shared segment capability when loading executables
from a page-mapped interface.
http://www.garlic.com/~lynn/submain.html#mmap
http://www.garlic.com/~lynn/submain.html#adcon

all four (normal with and w/o paged map, edf with and w/o paged map)
co-existed

still later there was the SFS filesystem ... which (effectively)
involved cross address space calls.

that SFS is different that the SFS that I had done ... migrating
(vm370) kernel spool file function into a virtual address space.

misc. sfs (spool file) references
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003b.html#46 internal network drift (was filesystem structure)
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2004g.html#19 HERCULES
http://www.garlic.com/~lynn/2004m.html#33 Shipwrecks

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

History of C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of C
Newsgroups: alt.folklore.computers
Date: Mon, 22 Nov 2004 05:27:58 -0700

Anne & Lynn Wheeler writes:

cms had its original filesystem from the mid-60s and then in the
mid-70s got the EDF (extended) filesystem ... and they
co-existed. the api semantics were the same ... but the on-disk
format had several differences as well as various operational
characteristic differences.

there was also r/o (os/360) vtoc filesystem support ... i.e.  enabling
cms to read os/360 vtoc-based filesystems (somewhat analogous to some
linux support for ntfs filesystems).

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

History of C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of C
Newsgroups: alt.folklore.computers
Date: Mon, 22 Nov 2004 10:01:53 -0700

jmfbahciv writes:

Did IBM's OSes allow the customer to implement his own filesystems?
Or did they have to layer theirs onto an underlying IBM-supported
flavor?

there wasn't a ufs layer (like bsd) ... which would make it easier
(especially if you otherwise didn't have all the source) ... but since
all source shipped ... people did almost anything they wanted.  for
instance, perkin-elmer did cms modifications for compressed filesystem

trying to find some vmshare references
http://vm.marist.edu/~vmshare/

to the perkin-elmer changes, i did trip across the OCO (object code
only) thread ... which was the policy to stop shipping source
and just ship executable (creating difficulty for making changes):
http://vm.marist.edu/~vmshare/browse?fn=OCOROAD&ft=MEMO
which led to
http://vm.marist.edu/~vmshare/browse?fn=OCOCARD&ft=MEMO

some total drift about the intersection of virus and OCO policy
http://vm.marist.edu/~vmshare/read?fn=OCOROAD&ft=MEMO&line=1452

the perkin-elmer search also brought up adsm ...
http://vm.marist.edu/~vmshare/browse?fn=ADSM&ft=MEMO

which started out as a backup/archive system that i wrote for internal
use and then morphed into workstation data save (before becoming adsm
... and is now called tsm):
http://vm.marist.edu/~vmshare/browse?fn=WDSFVM&ft=MEMO

other references adsm/wdsf/tsm/backup/archive/etc
http://www.garlic.com/~lynn/submain.html#backup

however, i didn't turn up a reference to the perkin-elmer compressed
filesystem for cms.

there is general thread about other kinds of changes to cms file
system operation:
http://vm.marist.edu/~vmshare/browse?fn=STORECMS&ft=MEMO

common variety changes (in above ref) were done by universities for
very small filesystem allocation for students ... or a staging
mechanism (something like a virtual 3850/mss)

another topic drift, perkin-elmer was also company that had bought
interdata ... and inherited the result of a project that i
worked on as undergraduate ... 360 controller clone
http://www.garlic.com/~lynn/subtopic.html#360pcm

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

History of C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of C
Newsgroups: alt.folklore.computers
Date: Mon, 22 Nov 2004 10:11:23 -0700

Anne & Lynn Wheeler writes:

there wasn't a ufs layer (like bsd) ... which would make it easier
(especially if you otherwise didn't have all the source) ... but
since all source shipped ... people did almost anything they wanted.
for instance, perkin-elmer did cms modifications for compressed
filesystem

i think perkin-elmer may have also been the first to make
modifications for sorted directories and "fast" (binary search) file
name lookup.

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 22 Nov 2004 16:55:26 -0700

Anne & Lynn Wheeler (lynn@garlic.com) writes:

in addition, at one point, I believe i may have been building and
shipping production customized operating systems to more "internal
only" datacenters than there were total multics customers in the whole
life of the multics product (again it was purely a hobby that i did
for the fun of it).

i.e.
http://www.garlic.com/~lynn/2004o.html#45 Integer types for 128-bit addressing

aka

no. of customer ibm batch systems > no. of customer ibm vm systems
 no. of customer ibm vm systems > no. of internal ibm vm systems
  no. of internal ibm vm systems > no. of internal ibm custom vm systems I built & supported
   no. of internal ibm custom vm systems I built & supported > no. of all multics systems

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

vm/370 smp support and shared segment protection hack

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: vm/370 smp support and shared segment protection hack
Newsgroups: alt.folklore.computers
Date: Mon, 22 Nov 2004 18:04:06 -0700

the initial "smp" support actually created two hits.
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/submain.html#bounce

1) product smp design and implementation was predicated on numerous
things in the resource manager (that had already been
shipping). kernel software guidelines had been that all kernel
software was free. the resource manager was the guinea pig that
various kernel software could be charged for, but direct hardware
support in the kernel was still free (and smp support was direct
hardware support). the business issue was that you couldn't have free
kernel software that had prerequisite on charged for kernel software.
the resolution for the smp release, that all code that had been in the
resource manager that smp support was dependent on, was moved into the
free kernel. the resource manager for the smp release continued to be
priced the same (as the previous release, even tho it was now
significantly smaller).
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

2) to avoid slipping virtual memory announce by six months, some
features of the 370 virtual memory architecture were dropped (because
of implementation issues retrofitting virtual memory hardware to
370/165 hardware boxes). this created an impact on cms r/o, protected
shared segments implementation because there was no longer any feature
to "protect" shared segments. a hack was created that used the old 360
storage protection keys. cms was always set all its storage keys to
zero and its PSW key to zero. if the virtual address space contained
any cms r/o shared segment, then vm kernel played games with the real
keys .... setting all standard storage keys to "F", the real PSW key
to "F", and pages in r/o shared segments set to key "0". With the real
PSW key set to "F" and pages in r/o shared segments set to key "0",
instructions in the CMS virtual address space wouldn't be allowed to
alter r/o shared segment pages.

this game with the PSW and storage keys prevented being able to run
CMS virtual machines with the micrcode virtual machine hardware assist
(VMA; because the microcode assist changes didn't know about the
special games played with storage keys when changing PSW and/or
storage keys).

this resulted in a new & different kind of hack. the protection for
r/o shared segment pages was changed so a cms virtual machine could
alter storage at will ... however before kernel switched to a
different user ... it would examine all "protected" pages for
modifications ... and if any were found ... the virtual pages were
"discarded" (requiring a unmodified copy to be refreshed from disk).
the justification was that typically CMS virtual machine had only one
shared segment with 16 protected virtual pages to be checked on every
task switch .... and that this overhead checking for 16 pages was less
than the benefit gained from being able to dispatch CMS virtual
machines with with microcode assist enabled.

the problem arose that this new hack was introduced in a release
at the same time as the small subset of virutal memory management
functions was introduced
http://www.garlic.com/~lynn/submain.html#mmap
http://www.garlic.com/~lynn/submain.html#adcon

which was called DCSS. The changes introduced by DCSS met that at a
minium, a cms virtual machine typically had two shared segments (32
virtual pages to be checked) and frequently more shared segments. The
cost of checking 32 virtual pages for alteration on every task switch
invalidated the original justification for the change (i.e. the task
switch checking being less than the gain from being able to utilize
microcode performance assist) .... aka by the time the change first
shipped to customers for use of microcode assist by CMS ... the
assumptions justifying the change was invalid.

So along comes SMP support.

I had reverted kernels to using the storage key protection hack and
not using VMA microcode assist for cms virtual machines and built
SMP kernels using that mechanism  ... for instance HONE
http://www.garlic.com/~lynn/subtopic.html#hone

was running such production SMP kernels ... well before the official
SMP product release shipped.

I brought up the issue of reverting to the storage key hack ... rather
than the alteration checking hack (especially since by the time the
alteration checking hack actually shipped to customers, the original
trade-off assumptions were no longer valid; because with DCSS, the
number of virtual pages that needed checking had, at a minimum,
doubled).

The business problem was that several cms-intensive customers had
purchased the vma hardware assist modifications based on the previous
release announcing support for vma hardware microcode assist for cms
virtual machines (eliminating the storage key protection hack).

The judgement was that they couldn't announce dropping support for vma
hardware microcode assist (for cms virtual machines) after a single
software release cycle ... when there were cms intensive customers
that had paid hard cash for the feature.

SMP aggravated the hack allowing vma microcode assist and alteration
of "protected" virtual pages ... since the basic paradigm was that all
the "protected" virtual pages could be viewed as private to the one
and only one virtual machine/address-space executing .... and that any
alteration could be masked before the dispatcher switched to any other
virtual machine.

SMP violated this "one and only one virtual machine execution"
assumption by allowing at least two virtual machines to be executing
simultaneously. So to preserve the "private execution" assumption,
unique copies of protected shared segments were created for each
hardware processor.

therefor, before switching to a new task:

a) the switched-from cms virtual machine had all protected pages
(in its address space) checked for alteration (and if altered, the
page was invalidated, which would result in an unaltered version being
refreshed from disk).

b) the switched-to cms virtual machine then had its virtual address
space tables swizzled ... so that all the r/o, "protected" shared
segment pointers .... pointed to the shared segment copies specific to
the hardware processor it was being dispatched on.

so it could be shown that the non-smp overhead ("a") invalidated the
original performance trade-off assumptions (when "DCSS" support was
introduced and the typical number of shared segments, at a minimum,
doubled). this was further aggravated by the SMP overhead ("b") for
dispatching always with processor specific virtual address space
shared segment fixup.

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

vm/370 smp support and shared segment protection hack

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vm/370 smp support and shared segment protection hack
Newsgroups: alt.folklore.computers
Date: Mon, 22 Nov 2004 19:32:48 -0700

glen herrmannsfeldt writes:

I always thought that copy on write was a feature, not a bug.

Then again, ordinary users don't worry much about how long
context switch takes, just how much time their VM gets.

copy (as opposed to discard) on write was a later feature for unix
support under vm/370 (as opposed to preserving the appearance of r/o
protection ... when the basic, original 370 architecture hardware
feature had been dropped from the 370 virtual memory product)

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

vm/370 smp support and shared segment protection hack

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vm/370 smp support and shared segment protection hack
Newsgroups: alt.folklore.computers
Date: Mon, 22 Nov 2004 20:52:38 -0700

the conference referenced in the following
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party

included a presentation on vm/370 support for unix ... forking address
spaces, copy on write support, etc. the presentation was written in
script with mixture of "dot" commands and gml commands.

The original CMS document processor, "script" was written in the
mid-60s with support for "dot" formating commands. After GML was
invented in '69, gml tag support was added to script.
http://www.garlic.com/~lynn/subtopic.html#545tech
http://www.garlic.com/~lynn/submain.html#sgml

so there used to be a document for the presenttation at the above
mentioned conference (remember original gml tags used colon/period
for deliminators instead of greater-than/less-than). author names
munged to protect the guilty
....

.bm 3;.fm 1;.fs 1
.rt bottom /DRAFT Feb. 23 '82/VM370 support for UNIX/xxxxxxxx/
:h2.INTRODUCTION
.tr ^ c8
The efficient support of
UNIX:sym.^:esym. -
by VM/370 is a clear and often stated
requirement of the engineering and scientific, as well as the
university, market place.  TSS/370 development working with Bell Lab
has extended TSS to provide UNIX support.  This work, and the insight
into UNIX design and operation that it has given, is largely the basis
for these extensions.
.sk

....

Later there used to be another document

....

:frontm.
:titlep.
:title.VM/SP Support for Unix - Design Specification
:docnum.Release 1, Level 1 (Draft)
:date.Updated 06/16/83, Printed &SYSMONTH./&SYSDAYOFM./&SYSYEAR
:author.xxxxxxxx
:author.xxxxxxxx
:author.xxxxxxxx
:address.
:aline.Information Systems Group
:aline.Programming Architecture and Planning
:etitlep.

....
the following then goes on with a very lengthy discussion of
a copy-on-write implementation
....

IMPLEMENTATION NOTE: a brute force copy of all non-null pages would be
simple and quick to implement, and it is a case which must be handled
anyway --fork, followed by fork requires us to uncouple the
corresponding private segments-- It should be available to help stage
up the Unix kernel code.  That is, since the pseudo-machine is almost
without debug facilities, and since flaws in this private-segment copy
support will, themselves, be very hard to diagnose, a simple,
fool-proof replaceable implementation will be well worth the very
modest expense in coding effort.

......

:frontm.
:titlep.
:title.VM/SP Support for UNIX* - External Interface
:docnum.Release 1, Level 1 (draft)
:date.Prepared 08/18/82, Printed &SYSMONTH./&SYSDAYOFM./&SYSYEAR
:author.xxxxxxxx
:author.xxxxxxxx
:author.xxxxxxxx
:address.
:aline.Information Systems Group
:aline.Programming Architecture and Planning
:etitlep.

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

History of C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of C
Newsgroups: alt.folklore.computers
Date: Tue, 23 Nov 2004 07:09:29 -0700

jmfbahciv writes:

Now that produced a niggle in my brain.  IIRC, educational
systems had lots of problems with tons of small files.

The way TW arranged bits on the disk was to start the
beginning of each file at the beginning of a cluster(?I
think I'm using the incorrect DEC word for this).

Most geometries for a  disk was to assign 10 blocks/cluster.
So if all the files on a structure were 10 words long, the
disk space would be "wasted" because each 10-word file would
appear to be 10 blocks long.  word=36bits  block=128words.

I'm now trying to remember to include DEC terminology definitions.
How did I do? :-)

so original CMS filesystem had FST (file status table) for each file,
40bytes. The FST pointed (disk block number) to hyperblock. A
hyperblock contained pointers (disk block numbers) to data blocks.  A
minimum sized file took up two disk records ... a hyperblock and a
data block (and required two disk record reads to access, one for the
hyperblock and one for the first data block).

So an early hack was to recognize that there was only a single
datablock for small files and have the FST point directly at the (one
and only) data block. This also resulted in being able to access a
small file with a single disk read rather than two.

If the file grew to more than one data block, the implementation would
allocated two additional disk blocks ... one for a hyperblock and one
for additional data block (and fix up the FST to point at the
hyperblock instead of the first data block).

The original CMS filesystem had uniform disk block size of 800 bytes
(200 32bit words). Even tho these disks (originally) were (all) CKD
... CMS would format them to a uniform 800bytes/block ... and then
treat them as logical fixed-block.

when i originally did the mapping of the cms filesystem to page-mapped
infrastructure ...
http://www.garlic.com/~lynn/submain.html#mmap

i had to munge things so that the physical block size appeared to be
4kbytes (rather than 800bytes). The small file hack then was even more
critical since it reduced minimum file allocation from 8k (two 4k
blocks compared to standard 1600, two 800 byte blocks) to 4k.

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

360 longevity, was RISCs too close to hardware?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 longevity, was RISCs too close to hardware?
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 23 Nov 2004 10:42:13 -0700

fairwater@gmail.com (Derek Lyons) writes:

That's because most of the interesting problems in science currently
are better served by massively parallel solutions.  That may change,
it may not.

Those problems that are still best served by monoprocessors
(keyspace searching frex), are frequently more easily done by
splitting the data across multiple smaller (cheaper) machines
(pseudo SIMD).

there may be some question of what is cause and what is effect.  there
is very attractive price/performance (and other issues) using massive
numbers of "killer micros". are specific applications being done using
massive numbers of "killer micros" because they are currently the most
interesting problems or are massive numbers of "killer micros" being
used (in general) because they represent an attractive
price/performance solution. slightly related past post
http://www.garlic.com/~lynn/95.html#13

one scenario is that the killer micro solution just has to be able to
siphon off enuf applications (may not be theoritically optimal
computing solution ... just demonstrate price/performance advantage)
to make it uneconomic to build the massive (low volume and possibly
custom) big processor machines. If a trend is started where people can
innovatively utilize the higher volume and better price/performance
components ... then it becomes less & less attractive to invest in
massive/custom big processor machines.

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

Mainframe Virus ????

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Virus ????
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 23 Nov 2004 13:25:21 -0700

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

There have been worms, e.g., the IBM "Christmas Card" worm in PROFS.
However, from the wording of the article it's clear that the reporter
hasn't got a clue as to what a virus is.

PROFS was a menu interface that wrappered a number of lower-level
functions. One was the mail client ... which was mostly made up of the
source from an early prototype mail client called VMSG (unfortunately
the PROFS group snarfed such an early prototype and never got around
to picking up later advancements when they got around to shipping
PROFS as a product). At one point, there was even some claim that the
PROFS email client was not VMSG ... however it was demonstrated that
in the network control header of every PROFS email ... there was the
initials of the VMSG author.

it was an internal network thing
http://www.garlic.com/~lynn/subnetwork.html#internalnet

which was larger than the arpanet from just about the beginning until
sometime mid-85 .... in part because an internal net node effectively
had gateway type function ... which didn't show up until 1/1/83 with
the great switch-over to internetworking. the size of the internal
network is purely based on the internal corporate nodes
... and not any of the bitnet/earn nodes using the same technology
http://www.garlic.com/~lynn/subnetwork.html#bitnet

at the time of the switch-over to internetworking on 1/1/83 ...
arpanet had approx. 250 nodes and the internal network was nearing a
1000 nodes ... which it reached in the summer of 83
http://www.garlic.com/~lynn/internet.htm#22

after the 1/1/83 switch-over with the introduction of gateways and
internetworking, the number of "internet" nodes started to grow faster
... and approx. the sametime in 85, both the internet and the internal
network passed 2000 nodes. slightly related issue with respect to
the size of the internet (aka until there actually was internetworking,
there wasn't any requirement for multiple different domain names):
http://www.garlic.com/~lynn/2004n.html#42

in any case, at the cms level ... file transfer and email transfer
used identical facilities (aka at lower level email was just another
file form).

the issue with xmas "cards" ... was they tended to be cms "EXEC" files
... which were executable command files (aka over the years, there
were three major syntax for EXEC files, the original EXEC syntax,
EXEC2 syntax, and REX(X) syntax). the xmas virus/worm was effectively
social engineering .... an executable file was sent, the recipient
read the file and was convinced to execute the file. the xmas "exec"
file tended to format 3270 screen with some form of xmas image ...
and got more complex over the years ... there was one that used color
and graphics on a 3279 screen to create an xmas tree with
multi-colored lights that flashed on & off.

many people got used to using the PROFS menu interface to deal with
some number of feature/functions, typically networking related
features (receiving and sending files & email), online telephone book,
calender, etc (although many experienced users clung to the CLI).

in any case, once an xmas exec was read (from the network) and
execution invoke ... it could perform almost any function.

a little topic drift referencing an old vmshare/mainframe thread
mentioning the intersection of OCO and virus
http://www.garlic.com/~lynn/2004p.html#5

random past posts mentioning PROFS and/or VMSG:
http://www.garlic.com/~lynn/99.html#35 why is there an "@" key?
http://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001j.html#35 Military Interest in Supercomputer AI
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#56 E-mail 30 years old this autumn
http://www.garlic.com/~lynn/2002f.html#14 Mail system scalability (Was: Re: Itanium troubles)
http://www.garlic.com/~lynn/2002h.html#58 history of CMS
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002h.html#64 history of CMS
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
http://www.garlic.com/~lynn/2002p.html#34 VSE (Was: Re: Refusal to change was Re: LE and COBOL)
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
http://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
http://www.garlic.com/~lynn/2003e.html#69 Gartner Office Information Systems 6/2/89
http://www.garlic.com/~lynn/2003j.html#56 Goodbye PROFS
http://www.garlic.com/~lynn/2003m.html#26 Microsoft Internet Patch
http://www.garlic.com/~lynn/2004j.html#33 A quote from Crypto-Gram

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

vm/370 smp support and shared segment protection hack

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vm/370 smp support and shared segment protection hack
Newsgroups: alt.folklore.computers
Date: Tue, 23 Nov 2004 13:28:44 -0700

johnl@iecc.com (John R. Levine) writes:

That was almost certainly the support they did for Interactive
Systems' port of System III (or maybe early System V) Unix to VM.  It
was a very nice design that abstracted the Unix process model into
lightweight virtual machines.  They redid the kernel so that it was
fully distributed, used CAS rather than spin locks so that nearly all
of the system call work happened in the process VMs, calling the
master VM only to do physical I/O.  It would have scaled up very
nicely to multiprocessors.

Unfortunately it was too big a change for the VM group to accept and
it died.

yes ... these documents that used to exist ... mention several times
subcontracting unix work to a company in santa monica ...

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

Amusing acronym

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amusing acronym
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Nov 2004 10:08:52 -0700

John.Compton@ibm-main.lst (Compton, John) writes:

I remember being told once that IBM Hursley was the 'home' of CICS
development... & that the public bus service that ran past the office
building was a number 66...

"Get your CICS on route 66"   ?

cics was one of those things originally developed at/for some (US)
customer shop and then migrated into an IBM product with IBM support
(like many products from that era). After some number of years,
responsibility for the product support eventually migrated to Hursley.

The university i was at got to betatest original ibm cics product on
an onr-funded library project ... and i got to shoot a couple early
cics bugs. one i vaguely remember was some problem with bdam open ...
cics had been used in a specific customer environment with specific
bdam file options ... and the university was using some other flavor
of bdam.

misc. cics history sites:
http://www.zois.co.uk/tpm/cics.html
http://www.share.org/Volunteer_Center/programs/cics_project.cfm?CFID=3922999&CFTOKEN=90285613
http://www.yelavich.com/history/toc.htm
http://search390.techtarget.com/originalContent/0,289142,sid10_gci1004434,00.html
http://search390.techtarget.com/qna/0,289202,sid10_gci1006618,00.html?track=NL-170&ad=491834
http://www.cicscentral.com/

random past posts mentioning cics:
http://www.garlic.com/~lynn/94.html#33 short CICS story
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/96.html#9 cics
http://www.garlic.com/~lynn/97.html#6 IBM Hursley?
http://www.garlic.com/~lynn/97.html#8 Ancient DASD
http://www.garlic.com/~lynn/97.html#30 How is CICS pronounced?
http://www.garlic.com/~lynn/98.html#33 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/99.html#58 When did IBM go object only
http://www.garlic.com/~lynn/99.html#130 early hardware
http://www.garlic.com/~lynn/99.html#218 Mainframe acronyms: how do you pronounce them?
http://www.garlic.com/~lynn/2000b.html#41 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#35 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000c.html#45 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#52 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#54 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#62 California DMV
http://www.garlic.com/~lynn/2001d.html#56 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001g.html#24 XML: No More CICS?
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#49 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#24 Parity - why even or odd (was Re: Load Locked
http://www.garlic.com/~lynn/2001j.html#25 Parity - why even or odd (was Re: Load Locked
http://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#51 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#43 QTAM (was: MVS History)
http://www.garlic.com/~lynn/2001n.html#0 TSS/360
http://www.garlic.com/~lynn/2001n.html#11 OCO
http://www.garlic.com/~lynn/2002.html#1 The demise of compaq
http://www.garlic.com/~lynn/2002.html#45 VM and/or Linux under OS/390?????
http://www.garlic.com/~lynn/2002c.html#4 Did Intel Bite Off More Than It Can Chew?
http://www.garlic.com/~lynn/2002e.html#62 Computers in Science Fiction
http://www.garlic.com/~lynn/2002g.html#78 Is it safe to use social securty number as intranet username?
http://www.garlic.com/~lynn/2002h.html#63 Sizing the application
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2002i.html#11 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#50 SHARE Planning
http://www.garlic.com/~lynn/2002j.html#53 SHARE Planning
http://www.garlic.com/~lynn/2002l.html#68 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2003e.html#69 Gartner Office Information Systems 6/2/89
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
http://www.garlic.com/~lynn/2003j.html#68 Transactions for Industrial Strength Programming
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003l.html#9 how long does (or did) it take to boot a timesharing system?
http://www.garlic.com/~lynn/2003n.html#29 Architect Mainframe system - books/guidenance
http://www.garlic.com/~lynn/2003p.html#23 1960s images of IBM 360 mainframes
http://www.garlic.com/~lynn/2004.html#47 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004.html#51 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004m.html#40 Result of STCK instruction - GMT or local?
http://www.garlic.com/~lynn/2004m.html#61 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#0 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#5 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#9 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#16 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004p.html#0 Relational vs network vs hierarchic databases

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

Mainframe Virus ????

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Virus ????
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Nov 2004 14:48:16 -0700

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

I inadvertently replied to an old message. URI
http://iafrica.com/news/sa/323399.htm
have a URI relevant to the IBM Christmas card worm (*not* virus), but
as I recall it was in the late 1980s.

version on bitnet/earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

and internal network (note the slowdown in the internal
network growth ... 1000 mid-83, 2000 mid-85, 2700 ye87):
http://www.garlic.com/~lynn/subnetwork.html#internalnet

from trusty vmshare archives ... PROB CHRISTMA thread
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB

summary from the above:

Append on 12/19/87 at 20:10 by Melinda Varian <BITNET: MAINT@PUCC>:

The following statement, from a member of the EARN Board, answers the
queries about the origin of the CHRISTMA EXEC.  Clausthal-Zellerfeld
is quite a new VM installation.  When Heinz Haunhorst, of their staff,
was notified that the first appearances of the virus on the networks
originated at his node, he pursued the matter vigorously and skillfully.
Helmut Woehlbier, of the Technical University of Braunschweig, also did
an excellent job in helping to determine the originating node.

<>  <>  <>  <>  <>  <>  <>  <>  <>  <>  <>  <>  <>  <>  <>  <>  <>  <>

Date:         Wed, 16 Dec 87 18:33:58 GMT
Sender:       EARN Technical Group <EARNTECH@EB0UB011>
From:         Michael Hebgen <$02@DHDURZ1>
Comments: To: EARN Executive <EARNEXEC@IRLEARN>,
              EARN Board of Directors <EARN-BOD@IRLEARN>
Comments: cc: German EARN Executive <DEARNEX@DHDURZ1>,
              German EARN node administrators <DEARNADM@DEARN>,
              Heinz Haunhorst <HENRY@DCZTU1>,
              "Dr. Gerald Lange" <LANGE@DCZTU1>,
              Otto Bernd Kirchner <KIRCHNER@DS0IBM1>
To:           Melinda Varian <MAINT@PUCC>
Subject:      CHRISTMAS EXEC

Dear colleagues,

after some very sophisticated detective work  it is clear that the origin
of the CHRISTMAS EXEC is the EARN  node DCZTU1. A student there has writ-
ten this EXEC  to send christmas greetings to his  colleagues and another
student has  used it  without knowing what  he is doing  (as many  of our
network users) and started the explosion.

The node  DCZTU1 has already  blocked the Userid  of the author  and done
all necessary steps.  Every node in the network can  be the next starting
point  of a  similar explosion  and distribute  virus programms  or other
bad things.

As far as  I know the EDP-systems  there is no way to  prevent users from
their own  mistakes. The only  solution I can think  of for this  type of
behaviour is to observe "EDP-hygiene":

   If you receive an executable  file (EXEC, CLIST, program) from another
   might be  unknown user  do N O T execute  without control  because it
   can result in gross missdemanour and serious damage.

   Check all EXECs/CLISTs,  what they are doing, before  you execute them
   and  check all  executable programs,  where  they come  from and  what
   they do.

   As in normal life uncontrolled behaviour may result in serious
   consequences  (I am  not going  to mention  AIDS). You  as a  user are
   responsable for all what you are doing.

I propose to include such statements (in better english formulation) into
the CODE OF CONDUCT and to  start an "enlightenment" process for the end-
users

Best regards, marry christmas (without tree) and a happy new year

Michael Hebgen

EARN director of Germany and
General secretary of EARN

*** APPENDED 12/19/87 20:10:47 BY PU/MELINDA ***

================================

various other bits & pieces from the thread:

Created on 12/10/87 09:47:26 by SU/BRIDGET

Watch out for CHRISTMA EXEC!
One of our staff received this exec from the University of Missouri
(we think) over bitnet and ran it.  I haven't seen exactly what it
does, but apparently it displays a nice little Christmas tree on
your screen while examining your names file and netlog file, extracting
userids and node names.  It then proceeds to sending a copy of itself
to all the userids it finds using the acknowledge option.  We found
about 200 copies of it in our spooling system as a result of four
or five people running it.  Of course anyone installing HPO 5 and
wanting to test the limits of their spooling system may want to keep
a copy  :-)

*** CREATED 12/10/87 09:47:26 BY SU/BRIDGET ***

Append on 12/11/87 at 17:50 by Faye West (403) 450-5180:

Apparently this exec caused IBM Canada to shut down RSCS in the Western
Region (at least) today. Rumor is,  Royal Trust also went down.

>>> REVISED  12/14/87 12:13:04 BY ARC/FAYE <<<
*** APPENDED 12/11/87 17:50:34 BY ARC/FAYE ***

Append on 12/12/87 at 10:47 by Tom Klensk (607) 752-6262:

Indeed, severe problems were caused within IBM's internal network
(2700 nodes) in the last two days as CHRISTMA EXEC multiplied.
The problem also caught the attention of the press and was featured on
the front page of this morning's Press & Sun Bulletin (our local
newspaper).

Tom Klensk, IBM Endicott

*** APPENDED 12/12/87 10:47:19 BY .TK/TOM ***

Append on 12/13/87 at 10:24 by Melinda Varian <BITNET: MAINT@PUCC>:

A group of us in BITNET are trying to trace the origin of the
CHRISTMA EXEC.  So far, the earliest appearance in North America
we've been able to track down were 5 copies that passed through
CUNYVM at 09:03 EST (12:03 GMT) on Wednesday, December 9.  These
copies were being sent from DCZTU1 to recipients at USU, UCSFCCA,
and CCNYVME.

We would appreciate your examining your logs to see if you can
find any earlier occurrences.  If you do, please append the time,
sending nodeid/userid, and receiving nodeid/userid (or send mail
to MAINT@PUCC if you prefer).

Thank you.

Melinda Varian,
Princeton University

*** APPENDED 12/13/87 10:24:27 BY PU/MELINDA ***

Append on 12/17/87 at 16:32 by Kathleen E. DeGuilme:

This story hit the Wall Street Journal this morning , on page 34.  If
anyone would like a copy, send me a note.

*** APPENDED 12/17/87 16:32:02 BY SAL/KATHLEEN ***

Append on 12/18/87 at 11:58 by Michael Wagner 416 978-6602:

CHRISTMA EXEC made the papers here in Germany too.  We think we have
found the originator, by the way.  I don't know the exact status of
the chase, but I think I can find out if people are interested.
...Michael Wagner, currently in Germany

*** APPENDED 12/18/87 11:58:35 BY TY/MICHAEL ***

Append on 12/18/87 at 13:37 by Melinda Varian <BITNET: MAINT@PUCC>:

Yes, the originator of the EXEC was found a few days ago, through
the cooperative efforts of system programmers around the world.

My personal thanks to everyone who helped in this effort,
Melinda

*** APPENDED 12/18/87 13:37:29 BY PU/MELINDA ***

Append on 12/18/87 at 23:54 by Melinda Varian <BITNET: MAINT@PUCC>:

:-)     You'll never know for sure, will you, Rich?

Yes, the impact of CHRISTMA on BITNET was substantially less than was
its impact on "the other network".  I'd say that mostly we were luckier
than they were.  Some of the other factors:  Their users have larger
NAMES files than ours.  Their network has greater bandwidth than ours.
It hit us during business hours, both in Europe and in North America,
while it hit them when most of the sysprogs were not at work.  Possibly,
too, since we're constantly expecting our systems to be attacked, we
reacted just a bit faster (and more zealously).

At any rate, those responsible for writing and propagating the EXEC
were being extremely childish.  Our networks exist as a cooperative
venture and REQUIRE the goodwill of the users.  Any fool (or broken
service machine) can flood the networks; it requires no great
intellectual achievement.

I can't really say what the author's intentions were, but the fact
that he prefaced the "interesting" part of the EXEC with the following
comment makes me feel that he was not entirely filled with holiday
spirit:

     /*     browsing this file is no fun at all
            just type CHRISTMAS from cms */

However, the cooperation between the system programmers around the
world in handling this problem was very much in the holiday spirit
and is the part I will remember longest.

Melinda (aka MAINT@PUCC)

P.S.: Anybody on BITNET who wants a copy of my collection of CHRISTMA
      logmsgs from around the world can request it by mail.

*** APPENDED 12/18/87 23:54:52 BY PU/MELINDA ***

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

Mainframe Virus ????

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Virus ????
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Nov 2004 15:23:42 -0700

somewhat aside ... if you take the number internal network nodes at ye87
from the previous post:
http://www.garlic.com/~lynn/2004p.html#16 Mainframe Virus ????

as approx. number of internal systems (although some number of
internal systems weren't connected to the internal network)

and the number of employees from this earlier post:
http://www.garlic.com/~lynn/2004o.html#63 360 longevity, was RISCs too close to hardware?

then you have an approx. avg of 180 employees per system.

this doesn't take into account the number of PCs and workstations ....
which mostly had their connectivity via terminal emulation ... as
opposed to full network nodes.

some number of past posts mentioning terminal emulation subject:
http://www.garlic.com/~lynn/2000.html#6 Computer of the century
http://www.garlic.com/~lynn/2000b.html#35 VMS vs. Unix  (was: Why are Suns so slow?)
http://www.garlic.com/~lynn/2000g.html#13 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2002k.html#19 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#24 computers and stuff
http://www.garlic.com/~lynn/2002k.html#29 computers and stuff
http://www.garlic.com/~lynn/2002k.html#30 computers and stuff
http://www.garlic.com/~lynn/2002l.html#53 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#41 ibm time machine in new york times?
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
http://www.garlic.com/~lynn/2003c.html#23 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#28 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#33 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#34 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003h.html#9 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2003p.html#39 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2003p.html#44 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
http://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?

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

Boyd makes wikipedia

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Boyd makes wikipedia
Newsgroups: alt.folklore.computers
Date: Wed, 24 Nov 2004 15:55:01 -0700

somebody just sent me email pointing out that Boyd
has his own entries in wikipedia

John Boyd (military strategist)
http://en.wikipedia.org/wiki/John_Boyd_(military_strategist)

Military Strategy (John Boyd)
http://en.wikipedia.org/wiki/Military_Strategy_%28John_Boyd%29

in the above there is mention of "Discourse on Winning & Loosing"
... I first saw as "Patterns of Conflict" along with "Organic
Design For Command and Control" (in the early '80s).

some of my past postings
http://www.garlic.com/~lynn/subboyd.html#boyd

and various other pages from around the web mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

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

History of C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of C
Newsgroups: alt.folklore.computers
Date: Thu, 25 Nov 2004 08:35:43 -0700

Peter Flass writes:

It's all in how you look at it.  The system is based on volumes and
VTOCs, with all kinds of stuff added later.  My nit is picked with the
"system" part of "file system".  A typical computer system today has
some collection of SMS-managed volumes where the system enforces
naming conventions and decides file placement issues, non-SMS
cataloged files including non-VSAM where the catalog only identifies
the volume and VSAM where the catalog contains file attributes, and
uncataloged files where the VTOC contains all the file information.
There aren't too many removable volumes now, except optical.

It's your call, but I would consider it a "system" only if there was
some overall organizing princple to it.

so a system might be a collection of things that work together (as in
the various ways that an operating system might store data) ....  as
opposed to an over-arching, coherent/consistent infrastructure.

so it may be the way that a (operating) system stores data .... as
opposed to a system of files (modulo the vocabulary difference; dasd
&/or volumes instead of disks, datasets instead of files, vtoc instead
of directory of files, etc).

on the other hand ... there is the comment about SNA not being a
system, not being a network, and not being an architecture (instead a
terminal control program or monitor).

random drift, sna, saa, 3-tier architecture, etc
http://www.garlic.com/~lynn/subnetwork.html#3tier

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

Systems software versus applications software definitions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems software versus applications software definitions
Newsgroups: comp.software-eng,comp.lang.c,comp.programming,alt.os.development,comp.arch,alt.folklore.computers
Date: Thu, 25 Nov 2004 08:53:44 -0700

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:

I would disagree. For me system software is more or less equivalent
to being part of the trusted computing base, with the more or less
implied side effect that if something unexpected goes wrong with it,
you need to crash the system. Handling hardware is only part of
that, and there are scenarios where you can have software driving
hardware directly without being part of the TCB - rare, but it has
happened. Performance - sure, you would want that, but correctness
is top priority. As a counterpoint, how many OSs have you seen that
have been compiled with optimization for the particular processor
model they will run on?

when i did the resource manager ... there was something like 2000
(automated) tests that took 3 months elapsed time to run as part of
calibrating and verifying the resource manager.
http://www.garlic.com/~lynn/submain.html#bench

the standard system maint. process was monthly update (patch?)
distribution called PLC (program level change). It would ship the
cumulative source updates as well as the executable binaries.

I was asked to put out monthly PLC for the resource manager on the
same schedule as the standard system PLC. I looked at the process, and
made a counter-offer of quarterly PLC for the resource manager
... since I would have to take all the accumulated patches (for the
whole system) and rerun some significant number of the original
validation suite .... and there just weren't the resources to do that
on a monthly basis.
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

reference to the original resource manager product announcement
http://www.garlic.com/~lynn/2001e.html#45

note that much of the bits & pices that was in the resource manager
had been available in earlier kernal ... but were dropped over period
years. it was eventually decided to collect them up and package them
as a separate distribution.

this was in the period of some transition from free to charged for
software. at the time, there had been soem distinction that
application software could be charged for ... but kernel/system
software (as part of supporting the machine) was free.

the resource manager got to be the guinea pig for the first charged
for kernel software component ... with a new distinction that kernel
software that was directly related to hardware software would still be
free ... but other types of kernel software could be charged for.

a interesting paradox then showed up for the next release. the
resource manager shipped with the release prior to the release that
shipped smp support.
http://www.garlic.com/~lynn/subtopic.html#smp

however much of the SMP design and implementation was predicated on
various features that were part of the resource manager.  the problem
was that SMP support was obviously directly supporting hardware and
therefor was free ... but now had integral dependancies on features in
the resource managere ... which was priced.

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

need a firewall

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: need a firewall
Newsgroups: comp.security.firewalls,alt.folklore.computers
Date: Thu, 25 Nov 2004 09:20:13 -0700

Lars M. Hansen writes:

Firewalls doesn't do a lot to keep spyware from getting
installed. It may, if configured correctly, prevent such software
from initializing communication with "mother". There's only one cure
for spyware, and that's called "brains".

at one point ... supposedly exploits were relatively evenly divided:

• 1/3rd buffer overflows (mostly because of C programming
characteristics associated with strings),

• 1/3rd automatic scripting

• 1/3rd social engineering (duping a person into divulging information
and/or running an application that they really shouldn't run).

many of the original firewalls were application firewalls that had
examined the message and specifically check for various kinds of
failure modes (like malformed strings that could result in buffer
overflow exploits).

references to long ago worm (predates the internet worm by almost a
year):
http://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
http://www.garlic.com/~lynn/2004p.html#16 Mainframe Virus ????
http://www.garlic.com/~lynn/2004p.html#17 Mainframe Virus ????

the above was a "social engineering" worm ... since it was dependent
on the recipient manually invoking something that had arrived over the
network.

side reference to OCO (as opposed to open source) and the internet
worm
http://www.garlic.com/~lynn/2004p.html#5 History of C
and
http://vm.marist.edu/~vmshare/read?fn=OCOROAD&ft=MEMO&line=1452

specific buffer overflow posts:
http://www.garlic.com/~lynn/subintegrity.html#overflow
lots of vulnerability and exploit postings
http://www.garlic.com/~lynn/subintegrity.html#fraud
and the inverse ... assurance postings
http://www.garlic.com/~lynn/subintegrity.html#assurance

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

need a firewall

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: need a firewall
Newsgroups: alt.folklore.computers
Date: Thu, 25 Nov 2004 14:17:07 -0700

Anne & Lynn Wheeler writes:

references to long ago worm (predates the internet worm by almost a
year):
http://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
http://www.garlic.com/~lynn/2004p.html#16 Mainframe Virus ????
http://www.garlic.com/~lynn/2004p.html#17 Mainframe Virus ????

the above was a "social engineering" worm ... since it was dependent
on the recipient manually invoking something that had arrived over the
network.

note that we actually investigated the ability to do more of a virus
... rather than a worm ... nearly 15 years prior to the above
mentioned worm (30-some years ago now).

basically original cms structure had this uniform, consistant program
invokation interface that everything went thru .... svc202 with
uniform 8byte tokens.

human input command processor, program api, etc ... all put stuff into
8byte tokens and did an svc202.

the svc202 handler would first run thru the file systems search
sequence looking for an "EXEC" file with the filename set to the first
token, then it would try looking for binary executable ("MODULE")
file, and finally it would look in the kernel services name table for
a match (oh, and along the way it would play with the abbreviation and
synonym tables).

so the idea was to send an "EXEC" file over the network with the
filename of some commonly invoked command. the recipient would load
the file and next time that command (say listfile) was invoked ... it
would get the compromised exec. The compromised exec would then
replicate itself with names of specific commands (again like listfile,
which would eventually generate an expected display ... after it had
removed any display of the compromised files). These compromised
commands could be programmed to do a number of things ... analogous to
modern day viruses.

the extensive tripping thru filesystem directories for command
resolution ... was one of the speedups that the sorted directories
helped with:
http://www.garlic.com/~lynn/2004p.html#6 History of C

another kernel speed up that was eventually done was the addition of
svc203 kernel call ...  rather than the uniform svc202 mechanism.
SVC203 took a kernel services function number ... which could be used
to index a table of kernel services ... and go directly to that
function (w/o the whole command lookup scenario on every svc202).
When i said that everything had gone thru svc202, i met everything
... including things like file read/write operations (aka every file
read operation).

various past references to svc 202:
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003l.html#4 S/360 Engineering Changes
http://www.garlic.com/~lynn/2004b.html#56 Oldest running code
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004f.html#62 before execution does it require whole program 2 b loaded in
http://www.garlic.com/~lynn/2004f.html#64 before execution does it require whole program 2 b loaded in
http://www.garlic.com/~lynn/2004n.html#36 Shipwrecks (dynamic linking)

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

Systems software versus applications software definitions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems software versus applications software definitions
Newsgroups: comp.software-eng,comp.lang.c,comp.programming,alt.os.development,comp.arch,alt.folklore.computers
Date: Thu, 25 Nov 2004 14:31:20 -0700

Juhan Leemet writes:

I remember seeing a nice little table in Datamation many years ago:
relating the approximate difficulty of implementing software:

                |  single-user     multi-user
----------------+----------------------------
application     |       1               3
system          |       3               9  <== HARDEST

i've frequently claimed that to take a straight forward written
application and turn it into a "service" ... it takes 4-10 times the
code and ten times the work.

example that i frequently used was taking the straight-forward stuff
written to support server handling financial transaction and upgrading
it to business critical integrity for electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

where service and system are somewhat related since they frequently
tend to have similar business critical integrity requirements.

it used to be that system tended to be associated with things/services
that required elevated privileges .... and that other software
(typically applications) depended on those things. these days with
personal computing ... system could refer to everything involving the
computer,

misc. posts related to assurance:
http://www.garlic.com/~lynn/subintegrity.html#assurance

random past references to business critical integrity requirements and
frequently needing 4-10 times the amount of code:
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002b.html#59 Computer Naming Conventions
http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003n.html#52 Call-gate-like mechanism
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?

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

Systems software versus applications software definitions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems software versus applications software definitions
Newsgroups: comp.software-eng,comp.lang.c,comp.programming,alt.os.development,comp.arch,alt.folklore.computers
Date: Thu, 25 Nov 2004 22:27:43 -0700

"Alex McDonald" writes:

Systems programmers dislike end users. Users need software. Ergo
if the user specifies it, the systems programmer won't write it;
the application programmer does that.

Systems programmers only write programs for themselves or other
systems programmers. Rarely they will write programs to support
applications, but only under protest at the inefficency of the
applications running on their finely crafted code accessible only
from the command line. Systems programmers count in hex.

some of the old collection

http://www.garlic.com/~lynn/2001e.html#31 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2002e.html#39 Why Use *-* ?

above has:

• real programmers don't eat quiche
• real software engineers don't read dumps
• real programmers don't write specs

long ago and far away ... i have vague memories of being able to read
the holes in cards that were executable output of assembler ...
(12-2-9/x'02' "TXT" cards) and modifying the program by repunching the
binary data in the cards (actually using 026 and later 029 to do copy
of the card up until the column(s) i needed to change ... and then
using multi-punch to punch the correct holes for the hex that i
needed).

minor archeological references:
http://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
http://www.garlic.com/~lynn/2001.html#0 First video terminal?
http://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
http://www.garlic.com/~lynn/2001k.html#27 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001k.html#28 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)
http://www.garlic.com/~lynn/2001n.html#49 PC/370
http://www.garlic.com/~lynn/2002o.html#26 Relocation, was Re: Early computer games

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

IBM 3614 and 3624 ATM's

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3614 and 3624 ATM's
Newsgroups: alt.folklore.computers
Date: Fri, 26 Nov 2004 07:10:02 -0700

stegeman.h@12move.nl (Henk Stegeman) writes:

Hi all,

Does anyone know what processor/technology IBM used in their
first generation ATM machines IBM 3614 & IBM 3624 ?

Thanks for all your replies.

i remember a couple of the people talking about development at the Los
Gatos Lab (which has since been torn down).

Part of it was getting the bill feeding right ... they had vault in
the basement with ATM-worth of bills ($50k us in 20s) from a couple
dozen different countries.

another story about trying to recognize when something other than
magstripe card was fed into the card slot.

i got email from one of the people earlier in the week ... they
had sent me URL pointer to boyd in
http://www.garlic.com/~lynn/2004p.html#18 Boyd makes wikipedia

... one of the places i had sponsored boyd's talk in the early 80s was
at the los gatos lab.
http://www.garlic.com/~lynn/subboyd.html#boyd

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

IBM 3614 and 3624 ATM's

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3614 and 3624 ATM's
Newsgroups: alt.folklore.computers
Date: Fri, 26 Nov 2004 07:16:27 -0700

another (los gatos) story was the airline res terminal that you see at
check-in counters and gates. the top service had slits for
ventilation. one of the fixes was a tray inside the case under the
slits ... designed to hold a quart bottle of coke.

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

IBM 3705 and UC.5

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3705 and UC.5
Newsgroups: alt.folklore.computers
Date: Sat, 27 Nov 2004 08:46:37 -0700

Peter Flass writes:

I thought the 3705 resembled a System/7, but I have only a superficial
(or less) acquaintence with both.  What's a UC.5?

UC ... universal controller

I had some vague recollection of somebody saying that 3705 was a uc.5
microprocessor.

there were somebody in the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

that was in the process of doing the stuff for the internal
network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and had done some stuff with both an 1130 and system/7.

they got involved in some discussion about pushing peachtree (which
became the series/1) as opposed to (I thot) uc.? for the 3705. I have
some vague recollection of part of the argument that at least
peachtree had hardware interrupt levels (with save/restore) while the
processor while the 3705 processor didn't.

note this was after i was involved as undergraduate on building 360
controller replacement using an interdata.
http://www.garlic.com/~lynn/subtopic.html#360pcm
the project originally started off reverse engineering the channel
interface and building a channel interface card for an interdata/3.
later the project evolved into collection of interdata/3s as dedicated
line-scanners and interdata/4 handling the processor interface (which
provided a lot more processor sophistication than whatever was
eventually selected for the 3705).

brief mention of universal controllers
http://www.sciencedaily.com/encyclopedia/ibm_8100

slight drift with respect to above ... my wife had gotten assigned to
do a technical audit of 8100 ... and shortly after, 8100 was killed.

long ago and far away i did have a specific reference that the service
processor in the 3081 was uc.5. then there was some contention with
the group selecting 4331/vmcms for the service processor for the 3090
(instead of continuing with uc.5 stuff from the 3081). part of the
issue was field service requirement needing an on-site diagnostic
process that starts with scoping individual components. when the main
processors no longer had scopable parts ... a service processor that
had hardware diagnostic visability into all parts of the system became
a requirement .... where it was possible to do a bootstrapped
diagnostic processor starting with being able to scope the service
processor ... and then use the service processor to diagnose the main
processor. the 4331/vmcms (as service processor) for the 3090 grew
into a pair of 4361/vmcms systems i.e. replicated service processors
... so a service processor failure didn't become critical path in
diagnosing the main processor (also the main processor was becoming
more and more dependent on the service processor for normal
operation).

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

IBM 3705 and UC.5

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3705 and UC.5
Newsgroups: alt.folklore.computers
Date: Sat, 27 Nov 2004 09:02:52 -0700

for some additional topic drift  .... check 3704/3705 tales at vmshare
archive
http://vm.marist.edu/~vmshare/

Dave Tuttle's Memoirs
http://vm.marist.edu/~vmshare/browse?fn=VMHIST07&ft=NOTE

"Tales of the IBM 3704/3705" (from above)

My first run-in with the IBM 3704/3705 Programmable
Communication Control Units (PCCUs) was sometime towards the
end of 1970, I think.  The CSC work on S/360 communications
was apparently recognized within the rest of IBM, since the
controller hardware group in Raleigh, North Carolina, sent a
couple of people up to Cambridge to talk to us about their
plans for a new front-end controller product.  They
described it as  a state-of-the-art,  multi-line
communications control unit, capable of supporting many
different line types and protocols, "programmable" through
user-specified parameters.  We called it "the great step
forward into the past!"

Some of the earliest IBM data communications work had been
done next door at MIT as part of the CTSS development, using
a beast known as the IBM 7750--a programmable communications
control unit so difficult to handle that there were
reportedly fewer than a dozen people who had ever programmed
it successfully! Ed Hendricks, Craig Johnson, and I had all
talked, at one time or another, to the one person at MIT who
ever did 7750 programming.  We all considered the S/360
2701, 2702, and 2703 hard-wired controllers a real benefit;
they made it possible for highly intelligent people to write
communications programs.  The IBM 7750 and its brethren
required a genius specialist.

... snip ...

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

FW: Is FICON good enough, or is it the only choice we get?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FW: Is FICON good enough, or is it the only choice we get?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 27 Nov 2004 09:33:09 -0700

R.Skorupka@ibm-main.lst (R.S.) writes:

Agreed, Times are a changing ( (C) Bob Dylan (R) ).
But seriously, The most important is (or could be) lack of MVS support
for FBA devices, including "open-system" tape drives, optical, etc.
Connectivity is marginal problem since:
a) you don't need to connect unsupported devices.
b) you *can* connect them now, in limited way (max. 2Gb/s, no mesh).

a big problem that CKD and channel program architecture was the
half-duplex and serialization characteristics
http://www.garlic.com/~lynn/submain.html#dasd

it wasn't just maing do w/o the fancy outboard searching mechanism
channel programming to find the record of interest. i claim that the
whole search paradigm was a trade-off from the early 60s between real
storage requirements and io capacity. You could layout much of the
file structure on disk ... and rely on search commands to find the
information ... as opposed to maintaining much of that structure in
real storage of the computer.

the original SAN could be considered the NCAR filesystem (from the
80s). They had IBM mainframe that "owned" the disks and the whole
infrastructure was interconnected with HYPERChannel. They wanted to
let the other computers in the infrastructure (at least crays) use the
IBM mainframe as file system controller ... but have direct data
transfer between the disk and the (non-ibm) processors.

You could use the HYPERChannel "network" for interprocessor
communication. You could also use the HYPERChannel "device adapters"
for things like channel extenders. There was a HYPERChannel "device
adapters", A510, that emulated the IBM Channel interface ... and to
which, you could attach IBM controlers. Typical programming would have
kernel software on the IBM mainframe package up the CCW programming
and download it to the memory of the A510. This was somewhat the
analogy of creating shadow channel programs done when translating
"virtual" CCWs to "real" CCWs in cp/67, vm/370, vs2/svs, vs2/mvs, etc.
The issue with the A510 was that the disk seek/search arguments were
back in the mainframe memory .... and HYPERChannel transfer latencies
could exceed the tolerance of the standard CKD dasd controller specs.
To address this problem, an larger memory device adapter, the A515 was
created. It supported downloading both channel programs as well as
seek/search arguments to the memory of the A515 (removing the latency
problems with retrieving them in real time from mainframe memory).

This allowed the other processors in the NCAR complex to treat the IBM
mainframe as a DASD/disk controller ... while doing direct transfers
from disk to processor (w/o having to pass the actual data thru the
IBM mainframe). The processors would request some data access from the
IBM mainframe. The IBM mainframe would locate the data on disk, create
a channel program and download it to the A515. The IBM mainframe would
then return the identification for the specific channel program to the
requesting processor. The requesting processor would then send a
request to the appropriate A515 device adapter to execute the specific
channel program.

The other problem with the genre was the whole half-duplex
characteristics (moving the channel programs next to the device ... as
in the A515 ...  at least for a standardized subset of possible
channel programs ... somewhat mitigated some of the half-duplex
issues). The 9333s, mentioned here
http://www.garlic.com/~lynn/95.html#13

used serial copper, dual-simplex (i.e. pairs of lines much like serial
fiber) links. They had basically taken SCSI protocol and enapsulated
it in messages and sent it down the line (breaking any serialization
latencies inherent in standard SCSI bus). This is analogous ... but
different to what the NCAR filesystem stuff had down with A515s.

Going on about the same time ... was a big push in the fiber channel
standard (FCS) meetings by various interested parties ... to lay a
half-duplex convention on top of FCS full-duplex protocol (as opposed
to going back and addressing how to change their paradigm from
half-duplex to full-duplex .... instead try and force some half-duplex
process on top of underlying full-duplex). This tended to create a lot
of heat and churn in the FCS standards meetings.

misc. past mentions of fiber channel standard stuff:
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2002j.html#78 Future interconnects
http://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc

misc. past posts that include some HYPERchannel mention
http://www.garlic.com/~lynn/subnetwork.html#hsdt

misc. past references to NCAR, Mesa Archival, remote device adapters,
and/or A51x boxes:
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#146 Dispute about Internet's origins
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#78 Free RT monitors/keyboards
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001l.html#34 Processor Modes
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002f.html#7 Blade architectures
http://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#47 send/recv  vs. raw RDMA
http://www.garlic.com/~lynn/2003c.html#66 FBA suggestion was Re: "average" DASD Blocksize
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003g.html#49 Lisp Machines
http://www.garlic.com/~lynn/2003i.html#53 A Dark Day
http://www.garlic.com/~lynn/2004b.html#46 ARPAnet guest accounts, and longtime email addresses
http://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#33 The attack of the killer mainframes

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

IBM 3705 and UC.5

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3705 and UC.5
Newsgroups: alt.folklore.computers
Date: Sat, 27 Nov 2004 09:45:43 -0700

"Tom Linden" writes:

There were several companies that built 270x replacement units
using minicomputers, but I don't recall their names.

interdata was bought up by perkin-elmer and sold under the
perkin-elmer name. another was comten. however, the claim
was that the project that i worked on as undergraduate was the
first to create such a plug compatable box
http://www.garlic.com/~lynn/subtopic.html#360pcm

the problem started out when I added tty/ascii terminal support to
cp/67. i looked at the 2702 channel specs ... and looked at the cp/67
code that dynamically decoded whether there was a 2741 (and type of
2741) or 1052 on the line (standard os/360 programming was that it was
"fixed" and you had to specify the terminal type for each line in the
system generation process).

So I got fancy and wrote some programming that attempted to
dynamically decide whether it was a 2741, 1052 or TTY on the end of
the line. I tested it and for the cases I used, it worked, Based on
that, the university wanted to have a single dial-up line pool
... that both 2741s and TTYs could dial into the same number.

That was when the CEs got involved and said that while it was possibly
to dynamically change the line-scanner associated with each line using
the SAD ccws .... the 2702 had taken a short-cut and hardwire
oscillators to each line. The result was while it was possible to
dynamicall change the line-scanner associated with each line ... and
kernel program could tell what kind of terminal was on each line ...
it was not possible to make a common dial-up line pool. As long as
termianls were hard-wired to the correct line ... they got the correct
oscillator for that terminal line-speed.

So the university Interdata project started out with the objective of
having the Interdata/3 being able to dynamically determine the baud
rate on the line. Coupled with the dynamic terminal identification code
that I had written in CP67 ... they then could have a common dial-up
line pool.

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

IBM 3705 and UC.5

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3705 and UC.5
Newsgroups: alt.folklore.computers
Date: Sat, 27 Nov 2004 13:27:27 -0700

other refs:
http://www.garlic.com/~lynn/2004p.html#27 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2004p.html#28 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2004p.html#30 IBM 3705 and UC.5

from fading memory

2702 sad ccw commands selected

sad1  -   2741 line scanner
sad2  -   tty/ascii line scanner
sad3  -   1052 line scanner

...

the base cp/67 terminal code could play with sad1 & sad2 & transmitted
data and look at the responses and determine whether the terminal was
2741 or 1052.

when i added tty/ascii support to cp/67 .... i sort of played the same
game ... except figuring out how to dynamically determine tty/ascii
and playing with sad1, sad2, and sad3.

there wasn't a oscillator/baud-rate problem with hard-wired terminals
since you could make sure that the port that the hard-wired terminal
plugged into had the corresponding oscillator wired to it.

there also wasn't a problem with common pool for dialed 1052s & 2741s
since they operated at the same baud rate. the problem was that the
1052s&2741s had a different baud rate from the ttys ... and the sad
command only changed the line scanner on a port ... but there was no
way to change the hardwired oscillator (so the baud rate was fixed).

the university project reverse engineered the ibm channel interface
and built a channel/controller interface board that fit in (initially)
an interdata/3. the interdata/3 then had software programming added to
dynamically determine the terminal baud rate (it strobed for the line
signal rise/drop to calculate the baud rate). The initial
implementation had single interdata/3 handling both the lines and the
channel interface. later there was sort of a cluster with dedicated
interdata/3s for lines and an interdate/4 for the channel interface.

supposedly the university project was the first of this genre
http://www.garlic.com/~lynn/subtopic.html#360pcm

it is the competition from these plug compatable controllers that
supposedly gave birth to both furture system
http://www.garlic.com/~lynn/submain.html#futuresys

and the really baroque, complex pu5/pu4 interface (aka vtam/ncp
... pu5/vtam in the mainframe, pu4/ncp in the 3705).

my wife had worked on fs and after it was killed, she worked with
moldow and produced AWP39, peer-to-peer networking architecture (there
were rumors that it put some people in Raleigh on tranquilizers).

she then got con'ed into going to pok to be in charge of
loosely-coupled architecture, while there she produced peer-to-peer
shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

basically SNA, as in pu4/vtam was a terminal control infrastructure
(virtual telecommunications access method as a follow-on to tcam,
terminal control access method) ... not a networking infrastructure.
the first thing resembling networking related to SNA was with APPN in
1986. Note that SNA/Raleigh non-concurred with announcing APPN ... and
the announcement letter was eventually rewritten so that it was very
careful to not state any direct relationship between APPN and SNA.

random past posts mentioning pu5/pu4
http://www.garlic.com/~lynn/94.html#33a High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/2000c.html#51 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2002b.html#59 Computer Naming Conventions
http://www.garlic.com/~lynn/2002c.html#41 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002.html#15 index searching
http://www.garlic.com/~lynn/2002i.html#58 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#37 RCA Spectra architecture
http://www.garlic.com/~lynn/2003b.html#5 Card Columns
http://www.garlic.com/~lynn/2003b.html#8 Card Columns
http://www.garlic.com/~lynn/2003b.html#16 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003c.html#28 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#20 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#49 unix
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003d.html#73 unix
http://www.garlic.com/~lynn/2003e.html#4 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#17 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003l.html#9 how long does (or did) it take to boot a timesharing system?
http://www.garlic.com/~lynn/2004g.html#12 network history

misc. past peer-to-peer posts
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/2000b.html#89 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
http://www.garlic.com/~lynn/2002b.html#54 Computer Naming Conventions
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002h.html#12 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/2002j.html#34 ...killer PC's
http://www.garlic.com/~lynn/2003c.html#30 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003d.html#73 unix
http://www.garlic.com/~lynn/2003e.html#4 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003h.html#9 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2004d.html#36 Omniscience Protocol Requirements
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004n.html#16 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment

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

Carrying IP over ATM networks

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Carrying IP over ATM networks
Newsgroups: comp.protocols.tcp-ip
Date: Sat, 27 Nov 2004 15:27:13 -0700

"Michelot" writes:

(1) without PPP, by using routed RFC2684 (formely RFC1483),
(2) through PPPoA with bridged RFC2684,
(3) through PPPoE over bridged RFC2684,

possibly of some minor interest in the discussion ... from
my RFC index:
http://www.garlic.com/~lynn/rfcietff.htm

as always, clicking on the ".txt=" field in the actual RFC summary,
retrieves the RFC.

http://www.garlic.com/~lynn/rfcidx8.htm#2684
2684 PS
Multiprotocol Encapsulation over ATM Adaptation Layer 5, Grossman D.,
Heinanen J., 1999/09/14 (23pp) (.txt=51390) (Obsoletes 1483) (See Also
2685) (Refs 1042, 1209, 1483, 1755, 2022, 2225, 2331, 2332, 2335,
2364, 2427) (Ref'ed By 2735, 2764, 3035, 3355, 3815, 3819)

http://www.garlic.com/~lynn/rfcidx8.htm#2685
2685 PS
Virtual Private Networks Identifier, Fox B., Gleeson B., 1999/09/14
(6pp) (.txt=11171) (See Also 2684) (Ref'ed By 2735, 2764, 2843, 2917)
(VPNI)

since 2684 & 2685 mutually reference each other, the relationship is
represented as a "see also".

the RFCs that reference 2684 are (from above 2684 summary): 2735,
2764, 3035, 3355, 3815, and 3819

http://www.garlic.com/~lynn/rfcidx9.htm#2735
2735 PS
NHRP Support for Virtual Private Networks, Fox B., Petri B.,
1999/12/15 (12pp) (.txt=26455) (Refs 2332, 2684, 2685)

http://www.garlic.com/~lynn/rfcidx8.htm#2664
2764 I
A Framework for IP Based Virtual Private Networks, Armitage G.,
Gleeson B., Heinanen J., Lin A., Malis A., 2000/02/04 (62pp)
(.txt=163215) (Refs 1075, 1661, 1701, 1723, 1755, 1771, 1918, 1990,
2003, 2125, 2131, 2138, 2251, 2328, 2341, 2362, 2393, 2401, 2406,
2409, 2477, 2516, 2547, 2598, 2627, 2637, 2661, 2684, 2685, 2748)
(Ref'ed By 3212)

http://www.garlic.com/~lynn/rfcidx10.htm#3035
3035 PS
MPLS using LDP and ATM VC Switching, Davie B., Doolan P., Lawrence J.,
McCloghrie K., Rekhter Y., Rosen E., Swallow G., 2001/01/17 (20pp)
(.txt=46463) (See Also 3031, 3032, 3036) (Refs 2684, 3038) (Ref'ed By
3034, 3063, 3215, 3270, 3353, 3811, 3815)

http://www.garlic.com/~lynn/rfcidx11.htm#3355
3355 PS
Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5
(AAL5), Nanji S., Singh A., Tio R., Turner R., 2002/08/30 (13pp)
(.txt=25114) (Refs 1661, 2331, 2661, 2684)

http://www.garlic.com/~lynn/rfcidx12.htm#3815
3815 PS
Definitions of Managed Objects for the Multiprotocol Label Switching
(MPLS), Label Distribution Protocol (LDP), Cucchiara J., Luciani J.,
Sjostrand H., 2004/06/21 (106pp) (.txt=215916) (Refs 2115, 2434, 2514,
2578, 2579, 2580, 2684, 2863, 3031, 3032, 3034, 3035, 3036, 3037,
3215, 3289, 3291, 3410, 3413, 3811, 3813) (was
draft-ietf-mpls-ldp-mib-14.txt)

http://www.garlic.com/~lynn/rfcidx12.htm#3818
3818
IANA Considerations for the Point-to-Point Protocol (PPP), Schryver
V., 2004/06/21 (4pp) (.txt=6321) (BCP-88) (Refs 1661, 2434) (was
draft-schryver-pppext-iana-01.txt)

http://www.garlic.com/~lynn/rfcidx12.htm#3819
3819
Advice for Internet Subnetwork Designers, Bormann C., Fairhurst G.,
Grossman D., Karn P., Ludwig R., Mahdavi J., Montenegro G., Touch J.,
Wood L., 2004/07/13 (60pp) (.txt=152174) (BCP-89) (See Also 3828)
(Refs 768, 791, 793, 826, 1071, 1112, 1144, 1191, 1332, 1435, 1633,
1661, 1662, 1750, 1812, 1939, 1981, 1991, 2018, 2131, 2205, 2208,
2210, 2211, 2212, 2246, 2309, 2322, 2328, 2332, 2364, 2394, 2395,
2401, 2406, 2440, 2460, 2461, 2474, 2475, 2507, 2508, 2581, 2582,
2597, 2598, 2616, 2630, 2631, 2632, 2633, 2634, 2684, 2686, 2687,
2689, 2710, 2784, 2865, 2914, 2923, 2988, 2990, 3048, 3095, 3096,
3150, 3155, 3168, 3173, 3246, 3248, 3344, 3366, 3376, 3449, 3450,
3451, 3452, 3453, 3488, 3501) (was draft-ietf-pilc-link-design-15.txt)

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

IBM 3705 and UC.5

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3705 and UC.5
Newsgroups: alt.folklore.computers
Date: Sun, 28 Nov 2004 10:25:32 -0700

Anne & Lynn Wheeler writes:

interdata was bought up by perkin-elmer and sold under the
perkin-elmer name. another was comten. however, the claim

oh, and parts of comten thread from last year
http://www.garlic.com/~lynn/2003c.html#70 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#76 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#13 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
http://www.garlic.com/~lynn/2003d.html#20 COMTEN- IBM networking boxes

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

IBM 3705 and UC.5

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3705 and UC.5
Newsgroups: alt.folklore.computers
Date: Mon, 29 Nov 2004 09:18:06 -0700

stegeman.h@12move.nl (Henk Stegeman) writes:

I checked the 3705 POO with the Functional Characterisics of the
System/7.  They are completely different.

Looks like IBM re-invented the wheel every time.

that was a justification for fort knox ... to converge the wide variety
of microprocessors around the corporation to 801
http://www.garlic.com/~lynn/subtopic.html#801

under fort knox, the follow-on to the (370) 4341 would have been a
801-based microprocessor.

random mention fort knox:
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
http://www.garlic.com/~lynn/2001h.html#69 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002g.html#39 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002h.html#19 PowerPC Mainframe?
http://www.garlic.com/~lynn/2002h.html#63 Sizing the application
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002j.html#20 MVS on Power (was Re: McKinley Cometh...)
http://www.garlic.com/~lynn/2002l.html#14 Z/OS--anything new?
http://www.garlic.com/~lynn/2002n.html#61 Who wrote the obituary for John Cocke?
http://www.garlic.com/~lynn/2002o.html#6 Who wrote the obituary for John Cocke?
http://www.garlic.com/~lynn/2003b.html#5 Card Columns
http://www.garlic.com/~lynn/2003c.html#7 what is the difference between ALU & FPU
http://www.garlic.com/~lynn/2003d.html#43 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003e.html#55 Reviving Multics
http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003.html#2 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#3 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2004f.html#27 [Meta] Marketplace argument
http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004h.html#6 The One True Language
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
http://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?

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

IBM 3614 and 3624 ATM's

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3614 and 3624 ATM's
Newsgroups: alt.folklore.computers
Date: Mon, 29 Nov 2004 09:23:31 -0700

Joe Morris writes:

Don't forget the tongue-in-cheek descritption of the water-cooled
IBM 360/91 as a "solid-state sprinkler system".

And at least for the 3081 I worked with there was very definitely a
specification for coolant purity.  Building HVAC chilled water
usually could not meet those specs, so installations used a closed
system in the machine room with a heat exchanger to move the
rejected heat to the building systems.  (And at my PPOE I recall the
fights to convince the Physical Plant managers that we needed
cooling 24x7, even at night in the winter.  I always thought of
Physical Plant as a noxious weed...)

there is the story of the customer that lost flow on the building side
of the system ... and by the time the thermal tripped on the closed
side of the system ... there was still enuf heat in the infrastructure
to fry some TCMs. all systems were then retrofitted so that there were
flow sensors on both sides.

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

IBM 3614 and 3624 ATM's

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3614 and 3624 ATM's
Newsgroups: alt.folklore.computers
Date: Mon, 29 Nov 2004 13:10:51 -0700

K Williams writes:

I don't see how you'd fry the TCMs.  The CDU monitors water
temperature and reports to the service processor.  Also, each has
its own thermistor and reports temperature back to the service
processor.  If cooling is lost[*] the system shuts down before any
damage occurs.

[*] man do programmers get nervous when engineers with screwdrivers
walk onto their test floor! ;-) Yep, we pulled the cold-plate off a
TCM on the wrong side of a 3090.  It got strangely quiet for a few
seconds before the yelling started.  oops!

the story was that there was enuf (latent) heat in the system ... that
by the time the thermal sensor tripped ... it was already too late
... supposedly the processor side closed loop didn't have enuf
mass/dissipation to carry away the residual heat once the open loop
stopped flowing (and the temperature started to rise on the closed
cloop side) .... so systems were retrofitted with flow sensors on the
open loop side. the issue was what indicators were needed to shutdown
"before damage occurs".

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