2004 Newsgroup postings (11/20 - 12/05) Lynn Wheeler

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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:
https://www.garlic.com/~lynn/2004f.html#7 The Network Data Model, foundation for Relational Model
https://www.garlic.com/~lynn/2004l.html#52 Specifying all biz rules in relational data

aka:
https://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/cu/computinghistory/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 own 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 restaurant 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.

--
Anne & Lynn Wheeler | https://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:
https://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
https://www.garlic.com/~lynn/2004o.html#0 CKD Disks?
https://www.garlic.com/~lynn/2004o.html#22 Integer types for 128-bit addressing

--
Anne & Lynn Wheeler | https://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 advisery deadlines. this was actually policy-based with the default policy being fair share. tasks were ordered by advisery 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
https://www.garlic.com/~lynn/subtopic.html#fairshare

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

History of C

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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

--
Anne & Lynn Wheeler | https://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 | https://www.garlic.com/~lynn/

History of C

Refed: **, - **, - **, - **, - **, - **, - **

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.cgi?fn=OCOROAD&ft=MEMO
which led to
http://vm.marist.edu/~vmshare/browse.cgi?fn=OCOCARD&ft=MEMO

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

the perkin-elmer search also brought up adsm ...
http://vm.marist.edu/~vmshare/browse.cgi?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.cgi?fn=WDSFVM&ft=MEMO

other references adsm/wdsf/tsm/backup/archive/etc
https://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.cgi?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
https://www.garlic.com/~lynn/submain.html#360pcm

--
Anne & Lynn Wheeler | https://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 | https://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.
https://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 | https://www.garlic.com/~lynn/

vm/370 smp support and shared segment protection hack

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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.
https://www.garlic.com/~lynn/subtopic.html#smp
https://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).
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://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 microcode assist enabled.

the problem arose that this new hack was introduced in a release at the same time as the small subset of virtual memory management functions was introduced
https://www.garlic.com/~lynn/submain.html#mmap
https://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
https://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 reverything 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 | https://www.garlic.com/~lynn/

vm/370 smp support and shared segment protection hack

Refed: **, - **, - **, - **, - **, - **

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 | https://www.garlic.com/~lynn/

vm/370 smp support and shared segment protection hack

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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
https://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.
https://www.garlic.com/~lynn/subtopic.html#545tech
https://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 | https://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 ...
https://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 | https://www.garlic.com/~lynn/

360 longevity, was RISCs too close to hardware?

Refed: **, - **, - **

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
https://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 theoretically 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 | https://www.garlic.com/~lynn/

Mainframe Virus ????

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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
https://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
https://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
https://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):
https://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
https://www.garlic.com/~lynn/2004p.html#5

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

vm/370 smp support and shared segment protection hack

Refed: **, - **, - **, - **, - **

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 | https://www.garlic.com/~lynn/

Amusing acronym

Refed: **, - **, - **, - **

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
https://web.archive.org/web/20080123061613/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/

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

Mainframe Virus ????

Refed: **, - **, - **, - **, - **, - **, - **, - **

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
https://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):
https://www.garlic.com/~lynn/subnetwork.html#internalnet

from trusty vmshare archives ... PROB CHRISTMA thread
http://vm.marist.edu/~vmshare/browse.cgi?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 | https://www.garlic.com/~lynn/

Mainframe Virus ????

Refed: **, - **, - **, - **

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:
https://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:
https://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.

--
Anne & Lynn Wheeler | https://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)
https://en.wikipedia.org/wiki/John_Boyd_(military_strategist)

Military Strategy (John Boyd)
https://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
https://www.garlic.com/~lynn/subboyd.html#boyd

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

--
Anne & Lynn Wheeler | https://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
https://www.garlic.com/~lynn/subnetwork.html#3tier

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

Systems software versus applications software definitions

Refed: **, - **, - **, - **

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.
https://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.
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

reference to the original resource manager product announcement
https://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 kernel ... 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.
https://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 dependencies on features in the resource managere ... which was priced.

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

need a firewall

Refed: **, - **, - **, - **, - **

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):
https://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
https://www.garlic.com/~lynn/2004p.html#16 Mainframe Virus ????
https://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
https://www.garlic.com/~lynn/2004p.html#5 History of C
and
http://vm.marist.edu/~vmshare/read.cgi?fn=OCOROAD&ft=MEMO&line=1452

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

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

need a firewall

Refed: **, - **, - **

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):
https://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
https://www.garlic.com/~lynn/2004p.html#16 Mainframe Virus ????
https://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:
https://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).

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

Systems software versus applications software definitions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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

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

Systems software versus applications software definitions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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

https://www.garlic.com/~lynn/2001e.html#31 High Level Language Systems was Re: computer books/authors (Re: FA:
https://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:
https://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
https://www.garlic.com/~lynn/2001.html#0 First video terminal?
https://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
https://www.garlic.com/~lynn/2001k.html#27 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2001k.html#28 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)
https://www.garlic.com/~lynn/2001n.html#49 PC/370
https://www.garlic.com/~lynn/2002o.html#26 Relocation, was Re: Early computer games

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

IBM 3614 and 3624 ATM's

Refed: **, - **, - **, - **, - **, - **

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
https://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.
https://www.garlic.com/~lynn/subboyd.html#boyd

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

IBM 3614 and 3624 ATM's

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

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 surface had slits for ventilation. one of the fixes was a tray inside the case under the slits ... designed to hold a quart of coke.

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

IBM 3705 and UC.5

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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
https://www.garlic.com/~lynn/subtopic.html#545tech

that was in the process of doing the stuff for the internal network
https://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.
https://www.garlic.com/~lynn/submain.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 visibility 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 | https://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.cgi?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 | https://www.garlic.com/~lynn/

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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
https://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
https://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:
https://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
https://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
https://www.garlic.com/~lynn/2002j.html#78 Future interconnects
https://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
https://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc

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

--
Anne & Lynn Wheeler | https://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
https://www.garlic.com/~lynn/submain.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 | https://www.garlic.com/~lynn/

IBM 3705 and UC.5

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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:
https://www.garlic.com/~lynn/2004p.html#27 IBM 3705 and UC.5
https://www.garlic.com/~lynn/2004p.html#28 IBM 3705 and UC.5
https://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
https://www.garlic.com/~lynn/submain.html#360pcm

it is the competition from these plug compatable controllers that supposedly gave birth to both furture system
https://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-Coupled Shared Data architecture
https://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.

--
Anne & Lynn Wheeler | https://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:
https://www.garlic.com/~lynn/rfcietff.htm
as always, clicking on the ".txt=" field in the actual RFC summary, retrieves the RFC.

https://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)

https://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

https://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)

https://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)

https://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)

https://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)

https://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)

https://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)

https://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 | https://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
https://www.garlic.com/~lynn/2003c.html#70 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003c.html#76 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003d.html#13 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
https://www.garlic.com/~lynn/2003d.html#20 COMTEN- IBM networking boxes
--
Anne & Lynn Wheeler | https://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
https://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:
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
https://www.garlic.com/~lynn/2001h.html#69 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2002g.html#39 "Soul of a New Machine" Computer?
https://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
https://www.garlic.com/~lynn/2002h.html#19 PowerPC Mainframe?
https://www.garlic.com/~lynn/2002h.html#63 Sizing the application
https://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
https://www.garlic.com/~lynn/2002j.html#20 MVS on Power (was Re: McKinley Cometh...)
https://www.garlic.com/~lynn/2002l.html#14 Z/OS--anything new?
https://www.garlic.com/~lynn/2002n.html#61 Who wrote the obituary for John Cocke?
https://www.garlic.com/~lynn/2002o.html#6 Who wrote the obituary for John Cocke?
https://www.garlic.com/~lynn/2003b.html#5 Card Columns
https://www.garlic.com/~lynn/2003c.html#7 what is the difference between ALU & FPU
https://www.garlic.com/~lynn/2003d.html#43 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003e.html#55 Reviving Multics
https://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
https://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003.html#2 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#3 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2004f.html#27 [Meta] Marketplace argument
https://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
https://www.garlic.com/~lynn/2004h.html#6 The One True Language
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
https://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **
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 | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:24:06 -0700
some more topic drift ...3081 tcm paper from ibm (search engine html'ed version of pdf paper):
http://216.239.63.104/search?q=cache:NzZrbqd3ZakJ:www.research.ibm.com/journal/rd/261/ibmrd2601H.pdf+%2B3081+%2Btcm+%2Bthermal+%2Bflow&hl=en
another packaging paper from ibm (search engine html'ed version of pdf paper):
http://216.239.63.104/search?q=cache:NzZrbqd3ZakJ:www.research.ibm.com/journal/rd/261/ibmrd2601H.pdf+%2B3081+%2Btcm+%2Bthermal+%2Bflow&hl=en
somewhat unrelated ,,,, but story from vmshare archive .... 3092 service processor ... actually a pair of 4361s running a highly modified version of vm/370 release 6; ... following comment ... at least nothing as slow as 3092 could be doing any mainline computing for a 3090
http://vm.marist.edu/~vmshare/read.cgi?fn=3090&ft=MEMO&line=503
Append on 01/13/89 at 12:10 by Chris Thomas / UCLA 213-825-9308:

The 3092 has nothing to do with PR/SM, or with anything else (like IO) that is part of normal computing. The 3090 CPs will run with the 3092 down. In fact, there are msgs in VM/XA and MVS/XA to the effect taht "3092 processor controller has failed - system shutdown recommended". We got it one day and everything continued running just fine; we ran for an hour without the 3092. What you loose without the 3092 are some important things like thermal monitoring, so it's not a good idea to run without it. You can't do things that require the 3092 like writing the IOCDS either, obviously. But nothing as slow as a 3092 could be doing anything important on a 3090!

*** APPENDED 01/13/89 12:10:38 BY UR/CST ***

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
funny article
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: funny article Newsgroups: comp.databases.theory,alt.folklore.computers Date: Mon, 29 Nov 2004 14:17:31 -0700
"Dawn M. Wolthuis" writes:
Delightful! Disappointing to find out that XML is female, however, as I was taught to worship only men and male icons (being from a US red state). Ah well.

As humorous as the worship of XML might be, equally humorous is the fear of the same, as in beliefs such as:

STOP! Be afraid! Your livelihood is under attack by a new approach to formatted data. While comma-quote (comma-separated, comma-delimited, tab-delimited, csv, etc) formats did no physical harm, we are now being attacked by a data format so powerful that it will topple our profession. DO NOT TOUCH! If you get any of the XML on your hands, it will start oozing into every part of your being. <soul>It will consume you!</soul> Anything you touch will then be wrapped in XML. This will not only make your stuff dog-ugly, but will slow you down to a point where medication will not be effective in reviving you. Everything you once held dear will mean nothing to you ever again. Be afraid -- BE VERY AFRAID<punctuation>!</punctuation>

gml (initials of three people involved)
https://www.garlic.com/~lynn/submain.html#sgml
was invented at the science center in the '60s
https://www.garlic.com/~lynn/subtopic.html#545tech
nominally as an enhanced "markup language" for document formating ... aka an enhancement to the existing cms script command processing support (that had been created in the mid-60s using runoff-like "dot" commands for formating). However, hardly before gml support was incorporated into the cms script command ... tags were appearing that we describing the type of data (as opposed to the formating of the data .... with the formating being specified for data types). As a result, you start seeing gml used as integral part of long-term document existance .... not just document formating (definitly in place by the time gml was standardized as iso sgml standard in the late 70s).
html by the early 90s was much more of a return to the original document (format) markup heritage of the 60s. In the 90s, you also somewhat find ASN.1 and html competing as an encoding paradigm for network transmission of data elements.
xml is much of a return to the *ML direction of the early 70s .... used for describing the document elements as opposed to simply describing the formating of document elements.
one of the early xml issues with regard to encoding paradigm for networking transmission (as alternative to ASN.1) was deterministic encoding rules related to digitally signed documents. The document was xml encoded and digitally signed, the data elements were transmitted non-encoded with an attached digital signature. The recipient had to (XML) re-encode the data elements in order to verify the digital signature. This only worked if there were strict deterministic XML encoding rules.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
100% CPU is not always bad
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 100% CPU is not always bad Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 29 Nov 2004 15:23:47 -0700
howard@ibm-main.lst (Howard Brazee) writes:
That doesn't make sense. All systems have operating systems which take resources. Some are more efficient for various tasks than others. Maybe Unix systems aren't optimized for IBM mainframes - but that doesn't mean there aren't good business solutions that should use Unix on IBM mainframes.

But anyway, if we measure what percentage of our CPU is being used to run business solutions, we are measuring the wrong thing, especially in the age where on-line response time is valuable. We lower CPU utilization percentage rates by upgrading hardware, while processing our work more rapidly.

We need to measure $$$, average throughput, maximum throughput, reliability, availability of solutions, etc. Those are what decision makers care about. CPU utilization only is useful in determining how close we are to maxing out our hardware.

there are a large number of issues involved.
i did the resource manager product ... which existed in the same time frame as the SRM ... and the SRM did none of the things that the resource manager was capable of.
the resource manager tracked resource consumption and calculated an advisery dispatch deadline for each quota of utilization. The effective result was that the resource manager had direct policy control over each tasks resource consumption rate. The default resource consumption policy was fair share ... with both a long term and short term current resource consumption rate ... however it was possibly to specify other resource consumption policies which then translated into resource consumption rates.
truely "interactive" tasks handled by
1) given more frequent dispatching opportunities ... where the resource quanta was proportional to the dispatching interval (or rate) ... you were dispatched sooner ... but with smaller quantas. if all you wanted was a little bit ... then you got it sooner & more frequently .... but the aggregate was the same whether you were interactive or batch.
2) interactive tasks tended to frequent idle periods .... which resulted in their aggregate resource consumption over the measurement periods would be significantly less than the policy specified. the frequency of dispatching was both proportional to the size of the quanta and the task's longer term resource consumption (so having been both idle and interactive ... gave significant boost ... which degrading as task started to reach its policy specification). This applies to any sporadic tasks ... whether they are interactive or not.
the original of this was I did in the '60s as an undergraduate and then re-released in the '70s,
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
If you aren't carefully and accurately monitoring and controlling resource consumption ... then it is much more difficult to provide predictable service. The alternative is to run system under utilized ... so there is always typically available resources for newly arrived tasks.
so another issue is resource pre-emption ... not just cpu, but also paging and file i/o. frequently reduced cpu consumption would also imply low real storage usage, low page i/o utilization, low file i/o utilization. cpu resource pre-emption means saving the current task status and being able to switch to higher priority task in an economical way. this is much less of an issue when processor is not operating at saturation. the fairshare scheduler not only could do the dispatch ordering under resource consumption policy control but could do a task switch in possibly 1/100th the pathlength of a typical MVS system.
so the unix heritage is much less sophisticated resource allocation ... at least into the early 90s, I claimed most to have been similar to the original dispatch/scheduling I had encountered in cp/67 back as an undergraduate.
in theory, the heritage is back to ctss .... which then had some of the people going to 4th floor, 545 tech sq to the science center and doing cp/67
https://www.garlic.com/~lynn/subtopic.html#545tech
and others going to the 5th floor, 545 tech sq to do multics ... and then unix appeared as possibly a simplified multics(?) ... aka in the early 90s, i joked that i had rewritten/replaced (what was then a typical) unix scheduler in the '60s.
a lot of the under-utilization recommendations has to do with being able to provide relatively instantaneous execution to sporadic tasks (possibly interactive ... but also other types of operations).
in order to provide instantaneous execution in a virtual memory environment, it may mean that not only is the cpu instantaneously re-allocated ... but also portions of real storage ... as well as being able to populate those real storage slots with pages currently resident on secondary storage. While it is possibly to provide relatively instantaneous re-allocation of processor resource (with a high-efficiency, and sophisticated implementation) .... to instantaneously re-allocate real memory involves longer latencies moving pages between memory and secondary storage.
Starting in the late '70s, I was starting to make comments that the relative system thruput of disk/dasd had decline significantly (i.e. processor and real storage resources increased by a factor of 50, disk/dasd resources increased by a factor of five). This affected both being able to move pages between real storage and secondary storage as well as file accesses.
In the following comparison ... I claimed that if disk/dasd resources had kept pace with processor/memory resources, then typical 3081 configurations would be easily supporting 3000 users instead of 300 ... aka as the machines became more powerful, the number of simultaenous users supported grew proportional to disk thruput (not processor/memory growth).
an old posting
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
from the above
system 3.1L HPO change machine 360/67 3081K

mips .3 14 47* pageable pages 105 7000 66* users 80 320 4* channels 6 24 4* drums 12meg 72meg 6* page I/O 150 600 4* user I/O 100 300 3* disk arms 45 32 4*?perform. bytes/arm 29meg 630meg 23* avg. arm access 60mill 16mill 3.7* transfer rate .3meg 3meg 10* total data 1.2gig 20.1gig 18*

initially, the sanjose dasd group took offense at the statement and assigned their performance modeling group to refute the statements. after a couple months they came back with a statement that I had somewhat understated the issues ... that things like RPS-miss actually made the situation worse than the above initially indicates.
Eventually that analysis was turned into a SHARE report written as recommendations for improving disk/dasd thruput (as opposed to what is wrong with disk/dasd performance).
so one of the solutions was to go to "big pages" (sometimes referred to as swapping). basically instead of moving a single 4k page at a time, .... pages (for the same task/address space) in memory that had to go out were group into "big page" units (10 4k pages, 40kbytes, single 3380 track). when any page member of a "big page" needed to be fetched ... all members of the same "big page" was read into memory.
The trade-off was that you were possibly unnecessarily moving some pages into/out-of memory (say possibly 20-30 percent) ... but you were doing it in a single arm access. Since the arm access performance had increased by less than four times ... while the transfer rate increased by ten times (and real storage had increased by over 50 times), there was some increase in transfer utilization and real storage use ... at the savings in number of disk accesses (say seven individual accesses for seven 4k pages was transformed into a single access for 10 4k pages).
random past posts mentioning big pages:
https://www.garlic.com/~lynn/94.html#1 Multitasking question
https://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
https://www.garlic.com/~lynn/2001k.html#60 Defrag in linux? - Newbie question
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
https://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
https://www.garlic.com/~lynn/2002f.html#20 Blade architectures
https://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2002m.html#4 Handling variable page sizes?
https://www.garlic.com/~lynn/2002m.html#7 Handling variable page sizes?
https://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003d.html#21 PDP10 and RISC
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#9 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#16 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
https://www.garlic.com/~lynn/2003o.html#61 1teraflops cell processor possible?
https://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
https://www.garlic.com/~lynn/2004.html#13 Holee shit! 30 years ago!
https://www.garlic.com/~lynn/2004e.html#16 Paging query - progress
https://www.garlic.com/~lynn/2004l.html#61 Shipwrecks
https://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Computers in movies
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Computers in movies Newsgroups: alt.folklore.computers Date: Mon, 29 Nov 2004 15:31:57 -0700
Tim Chmielewski writes:
Everyone knows about HAL from 2001 and the Terminator, but does anyone know of any bad scifi movies that computers have a starring role in?

not in the movies ... but a real hal from the early 90s ... did a 64-bit sparc with investment from fujitsu ... and is now part of fujitsu. trivia ... what did this h-a-l stand for?
how 'bout war games. another trivia ... the ferry that appeared in war games ... is now a tourist boat on lake washington ... operating out of kirkland ... part of the tour goes by who's estate?.
the original ferry scene was out of a dock in south puget sound (in the movie it was supposedly off the coast of oregon). if i remember correctly ... the name of that (real) dock shows up in a science fiction novel sometime later in the 80s.
random past posts mentioning war games:
https://www.garlic.com/~lynn/2000d.html#39 Future hacks [was Re: RS/6000 ]
https://www.garlic.com/~lynn/2001m.html#52 Author seeks help - net in 1981
https://www.garlic.com/~lynn/2002b.html#38 "war-dialing" etymology?
https://www.garlic.com/~lynn/2003m.html#14 Seven of Nine
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Mon, 29 Nov 2004 23:20:29 -0700
keith writes:
I don't buy it (sorry). The junction temperatures (where the heat originated) by design were never to go above 85C or the system would crash - hard. Like current, heat flows "down hill" from high potential (temperature) to low, so even with an infinite thermal mass at 85C, the temperature will not exceed, 85C. Ok the regulators may have been at 125C, but the water was not pressurized so it wouldn't go over 100C before boiling, releasing the heat (and not conducting it to the TCMs in any case). Even 125C wouldn't have fried any electronics in the TCMs.

Now, there were embarrasing instances of "magic smoke" release in the 303x, but they had nothing to do with the coolant.

the story was told to me by somebody from cornell ... like it may have happened there.
a possible indication would be if service processor monitored flow (on open loop side) ... in addition to just temperature. if somebody has 3081 installation regarding where there were flow sensors (and/or did later installations have flow sensors on the open loop side?)
this 3081 description (possibly original announcement?)
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3081.html
talks about 3087 coolant unit and 3082 service processor monitoring both temperature and flow ... but sort of implies that the flow monitoring may just be the closed loop side. the story was that infrastructure was retrofitted with open loop side flow sensors .... which would imply that support for monitoring the open loop side flow sensors might have also been added to the service processor.
from above ...
IBM 3087 Coolant Distribution Unit

The IBM 3087 incorporates heat exchangers, controls and two water pumps to supply cooling water in a closed loop to the IBM 3081 Processor Unit.

The temperature and flow rate of the cooling water supplied to the 3081 is continuously monitored by the microcode-driven 3082 Processor Controller. Any deviation from acceptable limits is signaled to the system operator.

The 3082 also periodically switches between the two coolant water pumps to help insure high system availability.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
chip inside smart card is firmware?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: chip inside smart card is firmware? Newsgroups: sci.crypt,comp.arch,comp.arch.embedded Date: Tue, 30 Nov 2004 10:19:38 -0700
jrefactors@hotmail.com (Matt) writes:
The chip (SIM ?) inside the smart card is considered as firmware? My understanding is that firmware means software on ROM. Or can we say embedded software? I am confused with those terms.

Please advise. thanks!!

a lot of these chips have eeprom where data &/or programming can be loaded (depending on chip rom you have).
i think much of the smartcard protection profile has to do with loading programming into eeprom/flash and the operation of the loaded programming ... and frequently the partitioning provisions for multiple different loaded functions.
http://niap.nist.gov/cc-scheme/pp/PP_SCSUGSMPP_V3.0.html
http://www.cse-cst.gc.ca/en/services/ccs/SCSUG_PP_v30.html
http://www.gammassl.co.uk/topics/OP3-ICCC2.html
an issue is that the evaluation typically is of the provisions for loading programs ... as opposed to evaluation of the chip with the loaded programs.
frequently they are referred to as multi-app tokens ... which is slightly misleading ... because multi-app tends to be defined as use with external applications. the more accurate designation tends to be multi-function tokens ... although not strictly requiring program loading ... the multi-function tokens that i'm aware of tend to be programming loaded into eeprom.
note that most embedded implementations tend to refer to the programming loaded into eeprom/flash as firmware ... to distinguish it from "regular" software .... example is bios on most PCs.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
History of C
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: History of C Newsgroups: alt.folklore.computers Date: Wed, 01 Dec 2004 09:55:20 -0700
jmfbahciv writes:
Yes, that's I'm talking about. One of the side effects of the SMP implementation is we could tell the monitor to do a system sleep, system would appear to die, field service could go around reconfiguring the hardware of the system, and then the monitor could resume what it was doing. That not only requires a complete save of each job's context, but a complete save of the monitor's own context. If we could have continued the SMP hard/software evolution, there's no reason the whole system context couldn't be hotplugged.

one of the original cp67 timesharing service companies
https://www.garlic.com/~lynn/submain.html#timeshare
did something similar to vm370 in the early to mid 70s ... except it was loosely-coupled based (aka ibm for cluster, my wife was con'ed into doing stint in pok in charge of loosely-couple architecture) instead of tightly-coupled base (aka ibm for smp).
they would save process context and resume the process on another processor in the cluster ... motivated by starting to operate 7x24 with world-wide clients ... had hardware needed to be taken out of service periodicly for PM (preventive maintenance). they even claimed to be able to migrate/resume process context between datacenter in waltham to dataceter in sanfran (it was not particularly fast line ... so would primarily work with processes that weren't making use of unique files in one of the datacenters).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Wed, 01 Dec 2004 10:06:38 -0700
K Williams writes:
We were doing them a favor by installing the crypto hardware (second set in existence) on their processors. ...not to mention that we were armed with sharp objects. ;-)

internal corporate requirement was that all links leaving premises had to be encrypted ... mid-80s there was some claim that the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
had over half of all link encryptors in the world.
in conjunction with hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt
i got involved with doing a daughter card that had some interesting crypto properties and would operate at really high speeds. apparently it was too good of a job because it was eventually decided that there was possibly only one customer for such a product (but it was a different world back then).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
(fwd) News about SIGMicro
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: (fwd) News about SIGMicro Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 01 Dec 2004 14:17:45 -0700
etech@ibm-main.lst (Eric Chevalier) writes:
Found this is the comp.arch newsgroup...

Eric Chevalier

-------------------------------------------------------------------
SIGMICRO TO PROVIDE FREE ACCESS TO AN S/390 MAINFRAME
AND AN IA-64 FOR RESEARCHERS

they do this periodically ... a little search with google groups turns up the same announcement from oct, 2001 in comp.parallel
http://groups.google.com/groups?q=sigmicro+free+access+mainframe&hl=en&lr=&scoring=r&selm=907fb513.0110251457.6bef0fcd%40posting.google.com&rnum=1
and comp.os.linux
http://groups.google.com/groups?q=sigmicro+free+access+mainframe&hl=en&lr=&scoring=r&selm=556fa7e3.0110261528.747e6596%40posting.google.com&rnum=2
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
US-CERT Technical Cyber Security Alert TA04-336A -- another buffer overlow
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: US-CERT Technical Cyber Security Alert TA04-336A -- another buffer overflow Newsgroups: alt.folklore.computers Date: Wed, 01 Dec 2004 16:29:02 -0700
past buffer overflow posts:
https://www.garlic.com/~lynn/subintegrity.html#overflow
Technical Cyber Security Alert TA04-336A

Update for Microsoft Internet Explorer HTML Elements Vulnerability

Original release date: December 1, 2004 Last revised: -- Source: US-CERT

...
Overview

Microsoft Security Bulletin MS04-040 contains an update to fix a buffer overflow vulnerability in Internet Explorer.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
fc3, eamcs 21.3.1 & ls incompatibility?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: fc3, eamcs 21.3.1 & ls incompatibility? Newsgroups: linux.redhat.install Date: Wed, 01 Dec 2004 18:08:19 -0700
production fc3 ... either in the gnus emacs build (10/18) or some ls change has introduced incompatibility. i've been running ls in emacs shell with alias for ls that automatically adds "--color=auto" (for probably 10-15 years across a number of platforms).
the final fc3 now has default ls trying to add color controls ... aka stuff like:
[0m[0m
... that is caret, left bracket, left bracket, zero, m
even with standard emacs shell settings which should indicate not to (some profile and emacs file works & has been working w/o problem on fc2 and a number of other platforms).
work around is to check in profile at startup if running in an emacs shell ... and set the alias to "ls --color=never" instead of "ls --color=auto"
--
Anne & Lynn Wheeler | https://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, 02 Dec 2004 09:03:31 -0700
jmfbahciv writes:
One of the things that really irritated me was that I couldn't get anybody to think about computer conglomerates that combined loosely-coupled SMP systems. I thought that would have an elegant way to implement redundancy and computing service delivery without any pause detected by _all_ users.

when they consolidated the US hone datacenter
https://www.garlic.com/~lynn/subtopic.html#hone
did something like that. us hone datacenter supported all field, sales, marketing in the us (at one point they were pushing 40,000 userids). it was all vm370 based and the majority of the applications were apl and quite cpu intensive. i put in smp suppor integrated into their production release .... the release before general availability of smp support.
they installed SMPs and then provided loosely-coupled support within the complex. I believe it was the largest single system image complex at the time. they didn't have process migration ... but they could direct logins to any processor in the loosely-coupled configuration (so if a processor failed ... a user's re-login would be directed to surviving processor). however, it wasn't as transparent as what one of the service bureaus had done with process migration
https://www.garlic.com/~lynn/submain.html#timeshare
the consolidation was to a site in california ... and after doing single location ... they then replicated the US hone datacenter (geographic survivability, one of the issues was earthquakes in cal), first in dallas and then a 3rd in boulder. lots of stuff was kept replicated across the three locations.
smaller clones of the us hone system were created in many places around the world.
slightly lagging this activity was the proliferation of 4341 vm370 systems .... especially inside the corporation. in addition to hone, sales and marketing started seeing local systems, first at the regional hdqtrs around the us and then at the larger branches.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
History of C
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: History of C Newsgroups: alt.folklore.computers Date: Thu, 02 Dec 2004 09:11:12 -0700
jmfbahciv writes:
Did your wife encounter a thinking culture that couldn't expand itself out of the mainframe box? And I mean that literally. This was my hypothesis about why I couldn't get anybody to think twice about the possibility. I could literally see, with my eyes, their brains shut down after the first compute of the idea.

when my wife was con'ed into going to pok to be in charge of loosely-coupled archecture (aka clusters), both she and the person responsible for tightly-coupled architecture (aka smp) reported to the same manager. she did Peer-Coupled Shared Data architecture
https://www.garlic.com/~lynn/submain.html#shareddata
but found most of the attention was building bigger and better iron ... not a lot of customers ... like internal hone
https://www.garlic.com/~lynn/subtopic.html#hone
had requirements far exceeding what could be packed into a single SMP ... or had the availability requirements.
at the time, her best audience was the people doing IMS hot-standby.
also about that time, there was a new interconnect being developed, trotter/3088 for loosely-coupled configurations and she tried to influence a number of advanced enhancements ... most of which she lost (basically 3088 came out as sort of ctca switch handling up to 8 processors)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Thu, 02 Dec 2004 09:33:34 -0700
Joe Morris writes:
That's the same situation that Herb Grosch described from his time at IBM: the programmers would be working on the system during the days, and at night the greml^W design engineers would take the machine at night and change the way it worked.

not quite that ... but, in part because of the same architecture across all the machines ... the architecture manual was pretty strongly followed. the architecture manual (or red-book because of being distributed in red 3-ring binders) was a superset of the principles of operation ... in fact, it was a cms script file with conditionals that would either print the full architecture manual, or the principles of operation subset (originally with the "dot" formating commands, eventually evolving into gml).
cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech
had worked on the "h" and "i" cp67 systems with endicott. in fact transferring files between endicott and cambridge was one of the first uses of the technology that became the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
"h" systems were the modifications to the cp67 kernel to add simulation support for the 370 architecture. the cp67h kernel could run on a normal 360/67 machine and provide 360 virtual machines, 360/67 virtual machines (with relocate), 370 virtual machines (w/o relocate), and 370 virtual machine (with relocate).
"i" systems were the modifications to the cp67 kernel to change the kernel to run on a 370 machine with relocate hardware support (and provide 370 virtual machines).
the 360/67 at the science center was operated as a generalized timesharing service that had a number of non-employee accounts, including students from various universities in the area (mit, bu, harvard, etc). because all this was being done before 370 virtual memory support had been announced to customers ... they typical operation was running cp67h kernel in a 360/67 virtual machine ... so characteristics of 370 architecture wouldn't accidentally be exposred to non-employees. the cp67i kernel was then run in a 370 virtual machine provided by the cp67h kernel running in a 360/67 virtual machine ... aka
360/67 hardware cp67 kernel providing 360 and 360/67 virtual machines cp67h kernel running in 360/67 virtual machine cp67i kernel running in a 370 (relocate) virtual machine cms running in 370 virtual machine
in any case, all of this was operational a year before the first 370 engineering hardware with relocate hardware (virtual memory) support was operational.
when endicott engineers thot they had the first engineering 370 with relocate hardware operational .... alan auroux took a copy of cp67i kernel to endicott to test. this was real engineering hardware ... with the ipl button a knife switch. they ipl'ed the cp67i kernel and it aborted/failed. after a lot of diagnosing, they found out that the engineers had switched the implementation of two of the new "B2" opcodes (from memory, RRB and PTLB; from what was defined in the architecture manual) ... the kernel was quickly patched to switch the opcodes and from then on, the cp67i kernel ran fine (at some tiem the engineers had to redo the opcodes to the architecture manual definition).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Thu, 02 Dec 2004 09:51:19 -0700
K Williams writes:
I'm sure that was earlier. I worked on the 3090 and ES9000 ICRF hardware from '88-'93. The customers were primarily large banks and the Fed.

ref:
https://www.garlic.com/~lynn/2004p.html#44 IBM 3614 and 3624 ATM's
yep ... i wanted to be able to manufacture the card for under $100, keep the markup as low as possible and handle a minimum of 2-3mbytes/sec and possibly as much as 6mbytes/sec. at the time, i think i was paying something like $16k for link encryptors that would just handle up to T1.
--
Anne & Lynn Wheeler | https://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: Thu, 02 Dec 2004 10:59:38 -0700
ref:
https://www.garlic.com/~lynn/2004p.html#44
https://www.garlic.com/~lynn/2004p.html#51
the problem wasn't so much the raw rate ... it was being able to handle minimum-sized packets and potentially have to change key between every packet ... aka it wasn't just a raw bandwidth link encryptor operating at lower level, it was supposed to operate at the MAC level ... although it effectively could do the job of a link encryptor if it had to.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Integer types for 128-bit addressing
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Integer types for 128-bit addressing Newsgroups: alt.folklore.computers Date: Thu, 02 Dec 2004 13:52:40 -0700
Anne & Lynn Wheeler writes:
for even more topic drift ... i had worked construction in high school, and first summer in college ... got a job as forman on construction job. about year after i joined ibm ... they gave me this song and dance about ibm rapidly growing and THE career path was being manager, having lots of people reporting to you, etc. i asked to read the manager's manual (about 3in, 3ring binder). I then told them that how i learned (in construction) to deal with difficult workers was quite incompatable with was presented in the manager's manual. i was never asked to be a manager again.

however, they did dump me into some project roles. early in my tenure in cambridge i sort of owned the five year vm370 plan for a period of six months or so. remember this is before spreadsheets and project planners; everything was in a cms flat file, that was updated with simple text editor and displayed/printed.
there was something like two releases a year with specific line items. line items had total people months, elapsed time, co-regs, pre-reqs and specific skill & resource dependencies and typically ranged in size from 3-36 person months.
there was an early huge rampup in head count (by more than a factor of ten) and lots of training and skills needed ... which were also all dependencies. the line items had to be arraigned within releases (taking into account co-reqs, pre-reqs, dependencies, etc) and also show smooth month-to-month utilization of the available resources (people and dollars)
so there were these weekly conference calls (i think friday but maybe monday?) with staffers in corporate hdqtrs. remember, cp67 and vm370 were totally non-strategic operating systems outside the standard corporate process. In the weekly calls, i started to get the impression that at least some of the corporate staffers were trying to swamp the group with what-if planning questions (impacting actually being able to spend time writing code). After a number of weeks, I got so that i could answer most of the what-if questions in real-time from memory. this sort of put a crimp in the corporate staffers fun.
Actually, customers either directly or indirectly dictated the near term budget and line items for the next release or two ... and after that, it was purely a strawman that frequently was updated as circumstances changed ... right out of boyd and OODA-loops
https://www.garlic.com/~lynn/subboyd.html#boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
in any case, the corporate staffers couldn't go too far afield since you could counter with customer requirements.
the experience held me in good stead later on with hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt
and ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
where a lot of work was outsorced, either internally with DOUs and/or externally with real live (work-for-hire) contracts. I got to do a lot of over all architecture, continue to write code, etc; but also help write contracts and do the go/nogo checkpoints, milestone approvals, release of funds, project reviews, statements of work, budgets, audits, work-for-hire, etc.
i don't remember exactly when, but sometime in the 80s, the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
moved out of tech center down the street to 101 main. the quarters were occupied by science center, acis, and possibly some project athena related activity. when the science center and the location was shutdown ... the primary company doing ha/cmp subcontract work had grown so fast ... that they were able to move in and take over the space.
--
Anne & Lynn Wheeler | https://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: Thu, 02 Dec 2004 13:59:38 -0700
K Williams writes:
We had a proposal to do exactly that on Ethernet controllers. In fact, that's what I was hired into BTV to do, but it was too simple and cheap to get much interest.

the reason for daughter card design was so that it could be used in a number of different ways .... including as link adapters/encryptors (and not limit the market to just enet). the difficulty with this wasn't with it being too simple and/or cheap.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Thu, 02 Dec 2004 15:36:20 -0700
K Williams writes:
But Ethernet controllers are *everywhere*. It would have been simple and cheap. Alas no interest, other than from a couple of other companies we disclosed to (Enet chip maker and networking company).

not way back when ... there were telco link adapters and pcnet thingies (1mbit with head-end something like tv cable architecture).
my wife is one of the co-inventors on the ring token passing patent (before token-ring product).
token-ring then started to be pushed ... and enet was still big heavy cables. it wasn't until a little later that you started to see enet take off with first coax and then star topology on twisted-pair, unshielded, shielded, CAT4, etc.
by '88 ... the token-ring and saa contingents were out in force ... there were all sorts of published reports about 10mbit enet not sustaining even 1mbit because of collisions (and comparing to 4mbit token). As close as i can tell, they may have been using the really old 3mbit enet that simply transmitted ... before they implemented listen before transmit ... and assuming really long aggregate end-to-end lengths (and therefor transmit latencies). '88 sigcomm proceedings had paper on twisted-pair star-topology 10mbit enet with 30 stations all configured in the driver to constantly transmit minimum sized enet packets ... which dropped the effective aggregate 10mbit media thruput from 95+ percent to something like 89 percent.
the new research bldg had gone in up the hill and was completely wired for CAT4 ... and there was some contention when a lot of the CAT4 became connected with enet rather than token-ring. their measurements showed that typical 10mbit enet had both lower latency and higher effective thruput than even 16mbit token.
my wife and co-authored a response to a gov. RFI where she specified much of the basics for 3tier architecture. we then expanded that and put together marketing presentation for customers showing 3tier architecture with enet implementations. we really started taking heat from the t/r and saa crowd for that:
https://www.garlic.com/~lynn/subnetwork.html#3tier
a while ago there were some threads in some newsgroups about the origins of middleware and 3tier architecture ... and we may be the guilty parties.
remember i mentioned that at the time the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
was larger than the (whole) internet .... and all the corporate links had to be encrypted (while as far as I know, none of the public internet links were encrypted) ... and the claim at the time was that the internal network had over half of all the link encryptors in the world .... to give you and indication of the market size in that era.
as a daughter card ... it wouldn't increase the cost of a basic enet card ... and it could be used with lots of other applications, links, t/r, etc. While it was possibly clear in the academic and technical market that enet would prevail, t/r was still quite dominent in the business market and some sections of the gov. market. Also, it wasn't just crypto that wasn't playing in the academic and technical market ... there was a number of security-related things ... that seem to have market interest in the business and gov. sector ... that didn't show up in the academic and technical market segment (other than possibly research topics, but not deployed operational stuff)
--
Anne & Lynn Wheeler | https://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: Thu, 02 Dec 2004 16:08:55 -0700
K Williams writes:
But Ethernet controllers are *everywhere*. It would have been simple and cheap. Alas no interest, other than from a couple of other companies we disclosed to (Enet chip maker and networking company).

another group we spent some amount of time talking to were a couple of the settop box vendors (both cable and sat. downlinks).
--
Anne & Lynn Wheeler | https://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: Thu, 02 Dec 2004 16:24:34 -0700
Anne & Lynn Wheeler writes:
another group we spent some amount of time talking to were a couple of the settop box vendors (both cable and sat. downlinks).

one had outsourced their manufacturing to a company in the far east ... which we visited; it was the first manufacturing line that i'd seen (or knew of) doing surface mount technology ... with real surface mount chips ... later i found some place in the us doing a form of surface mount by taking regular chips and cutting the contacts off flush; goes to show you how long ago some of this was.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Fri, 03 Dec 2004 10:09:26 -0700
K Williams writes:
The programmer's system we crashed was the #2 system to get the hardware that was already flushed out on the #1 system. We only "upgraded" the hardware when we'd proven it on the hardware system, and likewise the software on the hardware system. Thre was version control on all this stuff, except the control code (embedded microprocessor) on the crypto key storage unit (we were late and they took what we had or nothing).

for 4341 the hardware engineers in endicott got #1 and #2 ... and #3 was sent out to the disk product test lab in bldg. 15
https://www.garlic.com/~lynn/subtopic.html#disk
since i had worked on redoing i/o subsystem ... so the disk engineers could now run an operating system on their machines for disk regression tests ... their machines were no longer dedicated stand-alone (and could be used for various other things concurrently). somewhat as a result, i had better early 4341 access ... than most of the non-engineer groups in endicott (performance evaluation, software, etc). in any case, i was kind and offered to run stuff for endicott people on the 4341 in san jose (aka 4341 was developed in endicott).
some random references to making 4341 runs
https://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2002b.html#0 Microcode?
https://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
and for some total random slightly related endicott drift:
http://www.theregister.com/2004/12/01/secure64_itanium_arrives/
and
https://www.garlic.com/~lynn/2003e.html#65 801 (was re: reviving multics)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Fri, 03 Dec 2004 15:10:44 -0700
K Williams writes:
But Ethernet controllers are *everywhere*. It would have been simple and cheap. Alas no interest, other than from a couple of other companies we disclosed to (Enet chip maker and networking company).

recent related posts
https://www.garlic.com/~lynn/2004p.html#54 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#56 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#57 IBM 3614 and 3624 ATM's
one of the things that started to make 3tier architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier
was when the new 16bit ("fast", rather than 8bit interface) enet cards started showing up supporting twisted pair (& CAT4); eventually list around $100 and sometimes street price around $60 (AMD lance chipset sometime in this timeframe?)
this was at a time when the 16mbit t/r cards were going for around $1k and the recommendations were having something like 300 sharing the same 16mbit.
there were a number of issues from this era
1) 300 sharing the same 16mbits help promote the saa/terminal emulation paradigm ... since it was hard to do more than that with 16mbits didvided 300 ways
2) austin had done its own 4mbit t/r card (16bit/isa ) for the pc/rt. however they were told they had to use the standard microchannel 16mbit t/r card for the 6000. there are two separate issues, one is the aggregate sustained effective sbandwidth utilization on the media ... and the other is the sustained bandwidth thru a single card. turns out evaluation of the standard microchannel 16mbit t/r card showed that the sustained thruput of a single card was actually less than the custom pc/rt 16bit/isa 4mbit t/r card. again the traide-off supporting the saa/terminal emulation paradigm (huge numbers sharing the same 16mbit, no single one able to utilize a substantial portion).
3) you could configure high-speed (enet, tcpip) router as backbone with 10 enet subnets, each with 30 stations .... for an aggregate 100mbit (10*10mbit, and normal effective aggregate media thruput was 95 percent) and 300 stations ... with a couple dedicated extra dedicated subnets, with a single server per dedicate enet .... all for lower total cost than 300 16mbit t/r cards. the enet scenario was that each client could get approx. 1/30th of 9.5 mbits ... while in the saa scenario, each client was getting something less than 1/300th of <8mbits (again promoting the saa/terminal emulation paradigm) ... and there was no additional bandwidth for server operations.
one of the practicalities is that 2tier and 3tier traffic can be quite asymmetrical .... high speed router as backbone with dedicated enets (or, if needed fddi) to/from servers supported the asymmetrical bandwidth paradigm ... while still leaving lots of individual enet subnets configured for client operations.
say all the enets are CAT4 twisted pair into hubs in some wiring closets ... with the closet hubs connected to ports on high-speed router. there is currently option of upgrading from 10mbit to 100mbit to 1gbit enet. back then with star-wired and high-speed router backbone ... and still stuck with 10mbit enet ... you did have the option for doing things like putting more hubs in the wiring closet, increasing the number of subnets and reducing the number of clients per subnet (or for custom operations providing dedicated subnet to specific places). one of the big expense items has been doing any sort of rewiring ... having a single wire going to the wiring closet and then being able to do all sorts of variations in the wiring closet for customized configurations.
the issues were that typical 10mbit enet provided more aggregate media thruput than 16mbit t/r (roughtly 9.5mbits vis-a-vis 6-8mbits), it was much easier to configure subnets and still provide single network connectivity using high-speed routers (drastically increasing total aggregate infrastructure bandwidth), individual enet cards were showing up that individual could sustain the same as media capacity at about 1/20th the cost (compared to the $1k 16mbit t/r cards that individually were possibly in the 1-2mbit range).
recent posting mentioning terminal emulation issues:
https://www.garlic.com/~lynn/2004p.html#17 Mainframe Virus ????
misc. collected postings on terminal emulation issues (many related to saa)
https://www.garlic.com/~lynn/subnetwork.html#emulation
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Single User: Password or Certificate
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Single User: Password or Certificate Newsgroups: comp.security.ssh Date: Fri, 03 Dec 2004 17:07:03 -0700
josh@uronline.net (Josh) writes:
I've read numerous threads debating the merits of client certificates vs. passwords in SSH. I'm a novice to SSH and will soon be leasing a server that uses openssh as a connection protocol. If there are only a handful (less than five) technical users who will need direct access to the box, are there any benefits to using client certificates over passwords?

i tend to strongly favor public/private key for authentication ... however there can be a big distinction between public/private key systems and certificate-based systems.
basically you can use current business processes and register public keys in lieu of passwords. when the far-end gets a digital signature ... they look up the appropriate user, pull out their public key and verify the digital signature. the validation of the digital signature implies some form of authentication. ... out of 3-factor authentication
• something you know • something you have • something you are

if you have your private key in an encrypted software file ... then the validation of the digital signature can imply something you know authentication; since you needed to supply the correct decryption key/phrase to enable the private key. if you have your private key in a hardware token, then the validation of the digital signature can imply something you have authentication (and possibly two-factor, something you know also ... if the hardware token operation requires a pin/password).
the validation of the digital signature implies some form of authentication ... but it is the business process surrounding the management of the private key that actually determines what exactly the validation of the digital signature actually implies.
all of this is pretty much totally orthogonal to the standard use of certificates. typical use of certificates is where a relying party (far-end) has some relationship with a certification authority ... but has absolutely no knowledge about the owner of the public/private key pair. instead of the far-end (relying-party) registering a public key in association with something like a userid .... the far-end has had absolutely no knowledge about the entity originating the digital signature. for this sort of authentication process ... the originator packages the digital signature with a certificate and sends it off to the far end. at the far end ... they valicate the digital certificate (as having originated from a known, trusted certification authority) and then rely on the contents of the digital certificate to provide all information about the originator (w/o even needing predefined userid or account definition). The certificatation authority that originates the digital certificate is responsible for supplying all the information about the originator.
Note however, digital certificates typically still don't deal with what the validating of a digital signature implies ... as in what form(s) of authentication can be assumed from validating a digital signature.
random past posts about certificate-less public key operation
https://www.garlic.com/~lynn/subpubkey.html#certless
possibly of some interests, some posts about issues of passwords as shared-secrets:
https://www.garlic.com/~lynn/subintegrity.html#secrets
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Sat, 04 Dec 2004 08:40:54 -0700
jmfbahciv writes:
I don't think anybody understands that this is a vital part of CPU soft/hardware development cycles and is a part of the evolution of the technology. This is why I keep claiming that separating hardware from software with a corporation barrier is not a good idea.

that was where the rubber met the road type of the thing ... but it was part of the official plan. i've told the story about 3880 disk controller before.
https://www.garlic.com/~lynn/subtopic.html#disk
the transition from 3830 to 3880 disk controller went from a fast horizontal microcode engine to a much slower vertical microcode engine (jib-prime) that just handled commands and there was special hardware assists for the data flow.
the problem was that command processing latency on 3880 increased significantly ... and there were product acceptance guidelines about newer product thruput had to be with 5-10 percent of the replaced product. this wasn't happening ... total elapsed time for each disk operation was exceeding the requirements. so they did a kludge ... they had the 3880 signal operation complete to the channel/processor before the 3880 had finished all the command cleanup/termination.
the "official" acceptance tests were done with a two-pack VS1 system that was essentially single-threaded doing one i/o operation and then doing some work and then doing the next i/o operation. by the time the VS1 system had gotten around to starting its next io operation, the controller had finished doing what ever it was doing.
so one monday morning, i get a call from the engineers in bldg. 15 product test lab ... wanted to know what i did over the weekend to the 3033 system in their machine room, that performance had totally gone to pieces. I said "nothing", and asked them what they had done; they said "nothing". so a little more checking ... they had a string of 16 3330 disk drive for their general (engineers & their friends) time-sharing use with a 3830 disk controller. it turned out, somebody had replaced the 3830 with a new test 3880 disk controller over the weekend.
the time-sharing system on the 3033 get have loads of concurrent operations going ... and if the 3880 controller got busy doing something, there could be several operations queued up until it was free.
when the 3830 signaled complete, it was really free ... and the system would immediately start the next queued disk i/o and it would be accepted. when the 3880 signaled complete, it wasn't really free .. and when the system went to immediately start any queued disk i/o operation ... the controller would signal control unit busy (aka cc=1, csw-stored, SM+BUSY). So the processor has to requeue the operation and wait for the controller to really be free. The architecture requires that for all processors/channels that a control unit has signaled "control unit busy" ... when the control unit finally does become free ... it now must signal "control unit end" to all the same processors/channels. Compared to 3830 operation, the 3880 (moderate load sequence) operation was having to go thru i/o initiation twice, take twice as many interrupts, and the redrive of the control unit with pending i/o was significantly delayed (lots more processor overhead and much longer delays).
Fortunately, this happened well before the 3880 disk controlers were to ship to customers .... so there was time to tweak the insides to get the thruput up comparable to 3830 ... even under heavy load conditions. note, however, it wasn't part of the standard process. the standard process had been the hardware engineers worked in a totally stand alone environment ... and hardware typically wasn't really exposed to real production type operations until very close to time to ship to customers. It was the finagling that went on behind the scenes and outside the process ... that saved the day.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
IBM 3614 and 3624 ATM's
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 3614 and 3624 ATM's Newsgroups: alt.folklore.computers Date: Sat, 04 Dec 2004 09:07:37 -0700
Anne & Lynn Wheeler writes:
Fortunately, this happened well before the 3880 disk controlers were to ship to customers .... so there was time to tweak the insides to get the thruput up comparable to 3830 ... even under heavy load conditions. note, however, it wasn't part of the standard process. the standard process had been the hardware engineers worked in a totally stand alone environment ... and hardware typically wasn't really exposed to real production type operations until very close to time to ship to customers. It was the finagling that went on behind the scenes and outside the process ... that saved the day.

ref: previous post
https://www.garlic.com/~lynn/2004p.html#61
putting the 4341 into early/psuedo production in the disk labs and then doing stuff for the guys back in endicott was similar finagling:
https://www.garlic.com/~lynn/2004p.html#58
there was the joke about pulling 4-shift weeks; 1st shift in research, 2nd shift in disk engineering,
https://www.garlic.com/~lynn/subtopic.html#disk
3rd shift at stl, and 4th shift at hone
https://www.garlic.com/~lynn/subtopic.html#hone
providing and supporting heavily enhanced hone system for nearly 15 years was also behind the scenes and outside the process (but it helped keep the company running).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Systems software versus applications software definitions
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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: Sat, 04 Dec 2004 09:43:21 -0700
Anne & Lynn Wheeler writes:
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.

ref:
https://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
... recent slashdot
http://developers.slashdot.org/developers/04/12/04/1551255.shtml?tid=221&tid=1
points to the acm queue interview article
http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=233
Designing for failure may be the key to success. Engineering for Failure

it was called system/r ... developed on vm370 base and initially transferred from sjr to endicott for sql/ds. later tech transfer to stl for db2. misc past system/r, sql, etc posts
https://www.garlic.com/~lynn/submain.html#systemr
and related to the subject was ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
where we had to do detailed total system vulnerability and failure mode investigation.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Systems software versus applications software definitions
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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: Sat, 04 Dec 2004 15:46:21 -0700
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Well, as I know, I agree with that. But you also know that I am convinced that the IT world is STILL heading away from there :-(

when i got to do the resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
one of the supporting processes was an automated test & benchmarking process
https://www.garlic.com/~lynn/submain.html#bench
and eventually did one sequence of 2000 benchmarks taking 3 months elapsed time before first customer ship.
with the benchmarking process ... was able to define almost any sort of workload characteristics ... including very stressful ones that turned out were guaranteed to crash the system. early on as a result of this ... one of the side-tracks was to go in and completely redesign and rewrite the kernel serialization infrastructure ... that resulted in the elimination of all stress-test induced system failures as well as all observed situations of hung/zombie processes .... some of hung/zombies as well as other fault diagnostic stuff
https://www.garlic.com/~lynn/submain.html#dumprx
the main product release after the release of the resource manager included SMP support ... which had a lot of dependencies on the resource manager code ... which then created a business problem.
https://www.garlic.com/~lynn/subtopic.html#smp
the resource manager wss the first forey into priced kernel software with guidelines that direct hardware support kernel software was still free. having smp "free" software dependent on priced (resource manager) software violated those business guidelines. As a result .. something like 80percent of code in original resource manager was removed and incorporated into the "base, free" kernel software.
so problem reporting and fix process had a procedures that assigned a number (that was incremented sequentially) and fixes for specific problems were given the same number. with the very first version of vm370, the numbering started ... and as far as i know may never have been reset (i think i've recently seen references to sequential numbers in the 60k range?).
Any way ... if you have to be dilligent to maintain kernel integrity (failures because of dangling activities after processes have gone away) and/or hung/zombie processes (waiting for some activity to complete). A couple releases after the resource manager went out, there was a fix introduced into the dispatcher to ignore various kinds of events under certain circumstances; this had a fix number of something like 15,3xx (or maybe 15,1xx?). In any case, it resulted in re-introducing hung/zombie processes.
This occurred after i had redone the i/o system to make it bullet proof so the disk enginneering lab could do their work in an operating system environment ... instead of doing everything with dedicated, stand-alone machines:
https://www.garlic.com/~lynn/subtopic.html#disk
I created an update that removed the effects of the fix that re-introduced hung/zombie processes ... and tried to find out what was the original justification for generating it in the first place.
of course, all the ha/cmp work was pretty much trying to figure out how to retrofit availability andd assurance to existing infrastructures
https://www.garlic.com/~lynn/subtopic.html#hacmp
the stuff for electronic commerce was someplace in-between ... characterize all possible failure modes anywhere in the infrastructure ... and then define recovery and/or diagnostic processes to handle every possible scenario. ... aka the previous electronic commerce ref
https://www.garlic.com/~lynn/2004p.html#23
however, in approx, the same electronic commerce time-frame ... we looked at taking a more systemic approach. we had a jad with taligent about their environment ... taking the analogy from the original os/360 system services .... what taligent characteristics would be needed for assurance and availability system services. we had a one week JAD where we walked thru all of the taligent infrastructure, specifying what needed to be added/changed for assurance and availability. at the end, we had come up with two new availability/assurance frameworks ... and, in addition, about a 30% hit to the existing taligent frameworks
you would still need the up-front failure analysis ... but could possibly reduce application code lines from a 4-10 times increase to possibly only a 1.5 to 2.0 times increase (with some higher level assurance and availability abstrations being provided by the taligent infrastructure).
misc. assurance postings:
https://www.garlic.com/~lynn/subintegrity.html#assurance
random past taligent references:
https://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2000e.html#48 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2000.html#10 Taligent
https://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow
https://www.garlic.com/~lynn/2002i.html#60 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002j.html#76 Difference between Unix and Linux?
https://www.garlic.com/~lynn/2002m.html#60 The next big things that weren't
https://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003e.html#28 A Speculative question
https://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003j.html#15 A Dark Day
https://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
https://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

previous, next, index - home