List of Archived Posts
2001 Newsgroup Postings (01/19 - 02/20)
- Java as a first programming language for cs students
- Review of Steve McConnell's AFTER THE GOLD RUSH
- FCC rulemakings on HDTV
- Power failure during write (was: Re: Disk drive behavior (again))
- Now early Arpanet security
- Attribbute debugging quote?
- Java as a first programming language for cs students
- Scarcasm and Humility was Re: help!
- "HAL's Legacy and the Vision of 2001: A Space Odyssey"
- "HAL's Legacy and the Vision of 2001: A Space Odyssey"
- Review of the Intel C/C++ compiler for Windows
- Review of the Intel C/C++ compiler for Windows
- Now early Arpanet security
- Now early Arpanet security
- IBM's announcement on RVAs
- Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
- Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
- Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
- Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
- FW: History Lesson
- HELP
- First OS?
- HELP
- Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
- what is interrupt mask register?
- what is interrupt mask register?
- HELP
- HELP
- So long, comp.arch
- z900 and Virtual Machine Theory
- perceived forced conversion from cp/m to ms-dos in late 80's
- occupational nightmares [was: Now early Arpanet security
- z900 and Virtual Machine Theory
- John Mashey's greatest hits
- [OT] How old are us guys? (was: First OS?)
- John Mashey's greatest hits
- [OT] Currency controls (was: First OS?)
- John Mashey's greatest hits
- Why SMP at all anymore?
- John Mashey's greatest hits
- John Mashey's greatest hits
- First OS?
- John Mashey's greatest hits
- John Mashey's greatest hits
- what is interrupt mask register?
- First OS?
- First OS?
- what is interrupt mask register?
- PC Keyboard Relics
- PC Keyboard Relics
- IBM 705 computer manual
- Stealth vs Closed
- Kildall "flying" (was Re: First OS?)
- Kildall "flying" (was Re: First OS?)
- Stealth vs Closed
- IBM 705 computer manual
- Why SMP at all anymore?
- I am fed up!
- Checkpoint better than PIX or vice versa???
- Disks size growing while disk count shrinking = bad performance
- monterey's place in computing was: Kildall "flying" (was Re: First OS?)
- Disks size growing while disk count shrinking = bad performance
- z/Architecture I-cache
- Java as a first programming language for cs students
- Java as a first programming language for cs students
- Java as a first programming language for cs students
- 10 OF THE BEST
- Original S/360 Systems - Models 60,62 70
- weather biasing where engineers live (was Re: Disk power numbers)
- Z/90, S/390, 370/ESA (slightly off topic)
- Digital signature w/o original document
- Z/90, S/390, 370/ESA (slightly off topic)
- Z/90, S/390, 370/ESA (slightly off topic)
- 7090 vs. 7094 etc.
- Z/90, S/390, 370/ESA (slightly off topic)
- Z/90, S/390, 370/ESA (slightly off topic)
- Disks size growing while disk count shrinking = bad performance
- Inserting autom. random signature
- Inserting autom. random signature
- Z/90, S/390, 370/ESA (slightly off topic)
- Disks size growing while disk count shrinking = bad performance
- 36-bit MIME types, PDP-10 FTP
- Disks size growing while disk count shrinking = bad performance
- Z/90, S/390, 370/ESA (slightly off topic)
- Disks size growing while disk count shrinking = bad performance
- what makes a cpu fast
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Java as a first programming language for cs students
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2001 19:30:58 GMT
jmfbahciv writes:
Nah, probably not odd. That's just style. In our shop,
the problem was that, if the main code was written first,
there was never any time to rewrite it to do it right.
JMF would do his hacks on weekends. In his mind, what
he did on the weekends was for his pleasure and not to
be "construed as a commitment of Digital Equipment Corp."
(in-house joke). So no one would know that the main
code had ever been written.
... something that i ran across 20 years ago.
The Psychology of Change in Development Methodology by Gerald
M. Weinberg (Ethnotech, Inc., Lincoln, Nebraska, copyright 1979,
Ethnotech, inc).
+ + +
Ford's Fundamental Feedback Formula
+ + +
. . .
Back in the 1920's, Congress was investigation river pollution
and invited Henry Ford, as a top industrialist, to testify. When Ford
took the stand, he chided the Congress for wasting good tax money on
complicated ant-pollution laws. "All you need," he said, "was one
simple law to clear up all polluted rivers."
. . .
Anyone can take any amount of water from any river for any purpose
whatsoever, as long as they return the water upstream from where they
took it out
. . .
---Simply put, Ford's Fundamental Feedback Formula says, if you
want people to change what they're doing, make sure they are fed back
the consequences of what they're doing.
. . .
Bibliography:
Weinberg, Gerald M., An Introduction to General System Thinking, John
Wiley & sons, New York, 1975
Weinberg, Gerald M. & Weinberg, Daniela, On the Design of Stable
Systems, John Wiley & Sons, New York, 1979
Weinberg, Gerald M., The Psychology of Computer Programming, Van
Nostrand-Reinhold, New York, 1971
Freedman, Danial P., and Weinberg, Gerald M., EthnoTECHnical Review
Handbook, 2nd Edition, Ethnotech, Inc., Lincoln, Nebraska, 1979
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Review of Steve McConnell's AFTER THE GOLD RUSH
Newsgroups: comp.software-eng,comp.programming,alt.folklore.computers
Date: Fri, 19 Jan 2001 19:51:06 GMT
spinoza9999 writes:
The problem is that the American inability to write software has a
broad cultural base which includes a virtualization of knowledge.
Partly a result of the deliberate destruction of the public education
system and partly a result of computerization, people increasingly seem
to regard one narrative as good as another.
... from a long ago discussion about american industry (in general,
not just software industry) ... one might consider the recent Internet
IPO boom consistent with some of these observations.
The May 4, 1981 issue of Time magazine carried an article entitled,
The Money Chase -- Business School Solutions May be Part of the U.S.
Problem.
They are, in other words, a professional managerial caste that
considers itself trained--and therefore destined-- to take command of
the nation's corporate life. This might prove a misfortune of some
magnitude. For although the M.B.A.s generally see themselves as the
best and the brightest, a growing number of corporate managers, look
on them as arrogant amateurs, trained only in figures and lacking
experience in both the manufacture of goods and the handling of
people. Worse, the flaws in the polished surface of the M.B.A. now
appear to reflect flaws in the whole system of American business
management, in its concepts, its techniques, its values and
priorities. The M.B.A., then, is both a cause and a symptom of some
fundamental problems afflicting the U.S. economy.
Yet even as the corporate recuriters scramble to sign up these young
paragons, there in increasingly widespread criticism of M.B.A.s, their
traning and their functions. The indictment reads like this:
M.B.A.s are too expensive.
They are too aggressive.
They lack loyalty.
But the most fundamental criticism is that the misjudgements and
mistakes characteristic of U.S. management as a whole can be blamed at
least in part on the managerial methods and ideas of the up-and-coming
M.B.A.s. There has been these critics say, too much emphasis on
short-term profit, not enough on long-range planning; too much on
financial maneuvering, not enough on the technology of producing
goods; too much on readily available markets, not enough on
international development. Admits Lee J. Seidler, a Wall Street
securities analyst and professor at the New York Univerisy Graduate
School of Business Administration: 'It may be that some of the basic
tools we've been teaching in business schools for 20 years are
inordinately biased toward the short term, the sure payoff.'
Why is it, for example, that so much of U.S. plant and equipment has
become considerably older than that of Japan? To newly assertive
forign experts, the misguided emphasis on short-term profit seems to
blind U.S. managers to the need for more research and development;
moreover they appear unable to develop strategies for dealing with
long-range problems of chronic inflation and soaring energy costs.
And why has quality been declining? Partly because U.S. professional
managers have cared less about what they produce than about selling it
-- and less about selling than about bookkeeping and tax-law
legerdemain and building conglomerates that sometimes fall in ruins.
'For much of the trouble of the American economy, says Akio Morita,
chairman of Sony, American management has to take the
responsibility.'
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FCC rulemakings on HDTV
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2001 23:00:20 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
On Fri, 19 Jan 2001 08:58:38 -0800, Lars Poulsen wrote:
>Technically, we should just drop the HDTV transition.
Amen. HDTV is an answer in search of a question.
there is a line somewhere about a camel is a horse designed by committee
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Power failure during write (was: Re: Disk drive behavior (again))
Newsgroups: comp.sys.ibm.pc.hardware.storage,comp.arch.storage,comp.arch
Date: Thu, 25 Jan 2001 06:19:20 GMT
"Bill Todd" writes:
Since I never received an unambiguous answer to the original question,
that's hard to say. My guess would be that if indeed it ever happens at all
the likelihood of seeing it in any given power failure is quite low. But
the answers left some ambiguity whether the disk ever actually did
something questionable. The original assertion may have been that during a
power failure host memory lost function and clamped to send nulls, rather
than its previous contents, out over the still-active bus to the
still-active disk, in which case the issue, while real, has nothing to do
with, e.g., the disk's geometry, or number of sectors written. And IIRC
another response quoted a problem with ext2fs on Linux, but left it unclear
whether that problem was simply that ext2's fast-and-loose write-back
policies left multi-sector updates interrupted in the middle of the write
effectively trashed (again, nothing the disk can reasonably guard against).
i started this with observation about disk drives with the
characteristic existed from the 60s up thru at least the 80s ... and
that some of the issues might be similar to incomplete multi-sector
writes (especially when going to a larger logical filesystem record
size that had previously had the record size the same as disk physical
sector size and relied on consistent sector writes) ... not
necessarily that any current disks suffer from this characteristic.
i have no direct data on current generation of disks, other than many
unix vendors "qualified" scsi disks as to their power-failure sector
write characteristic (either a sector is completely written correctly
or not at all). such a qualification program possibly imply that not
all disks meet such qualification (i.e. a power-failure sector write
may result in conditions other than the two states in the
qualification)
random refs:
http://www.garlic.com/~lynn/2001.html#38
http://www.garlic.com/~lynn/2000g.html#43
http://www.garlic.com/~lynn/2000g.html#44
http://www.garlic.com/~lynn/2000g.html#47
http://www.garlic.com/~lynn/2001.html#6
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Now early Arpanet security
Newsgroups: alt.folklore.computers
Date: Fri, 26 Jan 2001 02:35:19 GMT
Ken McMonigal writes:
At Case-10 in 1973, I (legally) accessed the terminal room,
on an upper floor of an unlocked Computer Engineering building,
via a hallway door with rubber-button circular
lock (so no limit on issuing of keys). (Ways to defeat this type
of lock have been posted on the Internet) And I remember walking
into the -10 machine room (which included the IMP) several times.
So, that door either had no lock on it or was propped open.
following reference ... note there was finger slip in following, it was
ucsd not ucsb.
http://www.garlic.com/~lynn/99.html#45
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Attribbute debugging quote?
Newsgroups: alt.folklore.computers
Date: Fri, 26 Jan 2001 02:29:14 GMT
Brian Inglis writes:
Big S/390s call out and tell the CE centre the history, the
symptoms and the probable FRUs to bring along. The CE centre
calls to schedule a timely downtime if required. The systems are
engineered with internal redundancy (not customer functionality)
to not require maintenance during the average time spent on one
site.
the mainframe industry also has a reporting infrastructure that will
gather and summarize all errors for all machines.
in the early '90s, one of the people watching those statistics for a
particular new model noticed that a specific kind of (recoverable)
error had occured a total of 15-20 (this was the aggregate total
across all machines over a period of a year) when they were only
expecting a aggregate total of 3-5 such errors.
random refs:
http://www.garlic.com/~lynn/94.html#24
http://www.garlic.com/~lynn/2000.html#21
http://www.garlic.com/~lynn/2001.html#22
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Java as a first programming language for cs students
Newsgroups: alt.folklore.computers
Date: Fri, 26 Jan 2001 03:10:52 GMT
Lars Poulsen writes:
Gerald Weinberg is wonderful. Never met him but I like his books.
The only psychologist I ever read who understands what it is we do.
Your bibliography omitted a booklet called something like
"Are your lights on?"
are your lights on is (C) 1990 ... my reference was literally a
reposting of a posting I had made in spring of 1981
random refs:
http://www.geraldmweinberg.com/index.html
http://www.geraldmweinberg.com/books.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scarcasm and Humility was Re: help!
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 26 Jan 2001 18:25:09 GMT
jchausler writes:
Never saw a green one and only saw one 2311 drive in yellow. This was
in a shop which apparently didn't care much about color as there was a
mix of red and blue although at least 2/3rds were blue.
CSC had 45 2314 drives connected to the 360/67 ... five 8+1 drive
strings and a short 5 drive string. CSC had the IBM/CE repaint the
2314 control panel covers so that each string was color coded and made
it much simpler to find and locate a particular pack/drive.
random refs:
http://www.garlic.com/~lynn/94.html#32
http://www.garlic.com/~lynn/99.html#121
http://www.garlic.com/~lynn/2000b.html#82
some 360/67 machine room pictures (some in color, at newcastle, not
CSC)
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/index.html
b&w picture showing 8+1 2314 string
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_67/29.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "HAL's Legacy and the Vision of 2001: A Space Odyssey"
Newsgroups: comp.sys.super,rec.arts.books,rec.arts.sf.misc,sci.space.policy,alt.folklore.computers
Date: Sun, 28 Jan 2001 16:30:24 GMT
Dag Spicer wrote on 24 Jan 2001:
The Computer Museum History Center is delighted to present:
The HAL 9000 Computer
and the Vision of 2001: A Space Odyssey
David G. Stork
Chief Scientist
bcs had hired me for the summer of 69 to come in and help setup some
of their computers ... i guess i was something like BCS employee
40-45. BCS had been formed something like 6 months previously but was
still putting together its operation (although, in theory all data
centers were in the process of being assimilated by bcs). I was still
undergraduate ... but earlier in the year they had talked me into
putting together a one week class and they brought in their technical
people during spring break.
Anyway, I saw 2001 that summer in a theater in downtown seattle.
I happened to be in seattle again during the summer of '99 and got to
go see 2010 right after the opening at the same theater. local papers
had story about paul allen restoring the theater specifically for the
opening of 2010.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "HAL's Legacy and the Vision of 2001: A Space Odyssey"
Newsgroups: comp.sys.super,rec.arts.books,rec.arts.sf.misc,sci.space.policy,alt.folklore.computers
Date: Sun, 28 Jan 2001 16:39:41 GMT
Anne & Lynn Wheeler writes:
bcs had hired me for the summer of 69 to come in and help setup some
of their computers ... i guess i was something like BCS employee
40-45. BCS had been formed something like 6 months previously but was
still putting together its operation (although, in theory all data
centers were in the process of being assimilated by bcs). I was still
undergraduate ... but earlier in the year they had talked me into
putting together a one week class and they brought in their technical
people during spring break.
that summer you could periodially see 747 (i believe) serial #3 flying
over/around seattle. it had a long "boom" out the front of its
nose. it was getting FAA flight certification.
you could also go see the 747 mock-up; jetways, internal seating, etc.
The one thing that I distinctly remember from the 747 mock-up tour was
that they claimed that the 747 would have so many passengers that
passenger loading/unloading would never be done with fewer than four
jetways (two from each side of the plane).
when was the last time you saw 747 served by four jetways?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Review of the Intel C/C++ compiler for Windows
Newsgroups: comp.arch
Date: Sun, 28 Jan 2001 18:50:58 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
1) Backbone and switch connexions, when they are multiplexing
multiple Fast Ethernet connexions. This seems to be 90% of its
use at present. Obviously a good idea.
2) When the Gigabit Ethernet card is 'intelligent' enough to
optimise memory access and do the framing itself. Reports are
that SGI's does that, but I have no data on anyone else's.
there was presentation at the '89 ietf meeting (held at stanford) on
gigabit requirements
random refs:
http://www.garlic.com/~lynn/93.html#32
http://www.garlic.com/~lynn/94.html#31
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Review of the Intel C/C++ compiler for Windows
Newsgroups: comp.arch
Date: Sun, 28 Jan 2001 19:50:06 GMT
Anne & Lynn Wheeler writes:
there was presentation at the '89 ietf meeting (held at stanford) on
gigabit requirements
random refs:
http://www.garlic.com/~lynn/93.html#32
http://www.garlic.com/~lynn/94.html#31
corrected random refs (93.html not 94.html)
http://www.garlic.com/~lynn/93.html#31
some of the people back then working on high-speed pipelined protocol
engines for efficient network activity ... had also worked on SGI's
pipelined geometry engine for graphics.
random refs:
http://www2.ics.hawaii.edu/~blanca/nets/xtp.html
http://www.netstore.com.au/cbbooks/020/0201563517.shtml
http://www.prz.tu-berlin.de/docs/html/prot/protocols/xtp.html
http://citeseer.nj.nec.com/Architecture/Clusters/
http://www.cis.ohio-state.edu/htbin/rfc/rfc1453.html
http://www.mentat.com/xtp/xtp.html
http://www.ca.sandia.gov/xtp/biblio.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Now early Arpanet security
Newsgroups: alt.folklore.computers
Date: Sun, 28 Jan 2001 22:08:26 GMT
don@news.daedalus.co.nz (Don Stokes) writes:
6310 was a nice mid-80s separate screen & keyboard thing, emulated
a Hazeltine 1500, ADM-3A and a couple of other things. (One of the
emulations looked enough like a VT52 to use with DEC stuff, with only an
occasional screen refresh.)
sometime in '79, ibm came out with the 3101 ascii display terminal
... separate screen that looked a little like the PC B&W monitor and a
fat/thick keyboard (somewhat lighter than the 3277 keyboard) & a
power/control case (possibly half as thick as the original PC
case). you could get the 3101 with an optional hardcopy printer that
could either slave to what was going on the screen or work in simple
print screen mode.
at the time i had been using a cdi miniterm (300 baud, "heat"
sensitive paper) as a home terminal (I had a dedicated "internal"
corporate phone line installed in my house).
the very first 3101 versions were just simple dumb terminal
emulation. enhancements came out sometime in '80 for full-screen
block-mode. early keyboards also had something like four pfkeys (more
like vt101) ... enhanced 3101-2 model (in early '80) was more like
3278 keyboard, 12 "alt" code pfkeys across the top and 13-24 w/o-alt
pfkeys on the right.
In feb. 1980, I did a special terminal output driver for 3101 and adm3
displays at our location ... that replaced four or more consecutive
blanks with cursor positioning (which just about doubled the effective
thruput of most output). There was only a single control character
difference between the 3101 implementation and the adm3
implementation.
Sometime in march '80, i replaced cdi miniterm w/3101 at home ... I
think the same week that I got a note from Amdahl saying that they had
Unix up and running production on one of their mainframes.
random refs:
http://www.garlic.com/~lynn/99.html#69
http://www.garlic.com/~lynn/2000g.html#17
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Now early Arpanet security
Newsgroups: alt.folklore.computers
Date: Sun, 28 Jan 2001 22:45:57 GMT
other 3101 refs:
http://www.cs.utk.edu/~shuford/terminal/ibm_ascii_terminals_news.txt
http://www.cs.utk.edu/~shuford/terminal/ibm.html
http://www.georgiasoftworks.com/term.htm
list of terminal types refs:
http://blackroses.textfiles.com/hacking/tnet3.txt
http://www.isi.edu/in-notes/rfc1091.txt
http://www.isi.edu/in-notes/rfc930.txt
http://www.isi.edu/in-notes/rfc884.txt
random ref (that include 3101); An Encyclopedia of Macintosh Faults (11/84)
http://semaphorecorp.com/ss/ss18.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's announcement on RVAs
Newsgroups: bit.listserv.ibm-main
Date: Mon, 29 Jan 2001 05:37:39 GMT
rhawkins@SINGNET.COM.SG (Ron & Jenny Hawkins) writes:
I think the problems with IBM Storage Architecture come from building
Enterprise Storage to cater for the limitations of OS/390 and z/OS, and
then having to retrofit the box for the Unix market. Far better z/OS
introduced a software layer to virtualise the IO subsystem (ala Veritas
Volume Manager). I think this has a far greater potential to realise the
Iceberg dream. Wouldn't you like to have the choices that the Unix
people have had for years?
note that IBM actually had somthing similar in LVM several years prior
to VVM.
circa 1989 ...
o OSF has decided to build its operating system (i.e. OSF/1) kernel
from a Mach 2.5 / 4.3BSD kernel base, with a BSD "Tahoe" fast file
system (FFS), and with Encore symmetric multiprocessing support
(including parallelization of the file system and of networking).
The AIXv3 logical volume manager (LVM) will be ported to the OSF/1
kernel, and the OSF/1 kernel will provide a shared library and
loader system based on ideas from AIXv3 (with extensions). Run-
time loading of modules into the kernel will be supported. (Note
that the LVM will support extensible logical disks and disk mir-
roring; however, the OSF/1 file system will not make use of
logical volume extensibility.)
and posting to comp.arch.storage in 1993 ...
From: rogerk@veritas.com (Roger B.A. Klorese)
Subject: Re: Veritas Volume Manager (was Disk striping (RAID -1 ? :-))
Date: Mon, 12 Jul 93 21:57:41 PDT
Alan Rollow - Alan's Home for Wayward Tumbleweeds. writes:
>
>I'm interested in more information about the Veritas Volume Manager. I'd
>assume that it provides the basic lvm functions of bad block revectoring,
>volume concatentation and mirroring. Does it provide any other services
>such as Striping (RAID-0) or RAID-4/5?
>
I should probably introduce myself here; I'm the Product Marketing
Manager responsible for VERITAS Volume Manager (VxVM) and VERITAS
Visual Administrator (VxVA). But I used to be the support and training
specialist for the products until very recently, so I'm not a complete
liar and my mind isn't totally mush. ;-)
VxVM is not layered on LVM -- it descends partly from some technology
developed at Tolerant Systems in the mid-1980s -- so it does not take
exactly LVM's approach. It does not do bad block revectoring, for
example, depending on underlying drivers to do so. On the other hand,
it also does not have as rigid a set of constraints on extent (we call
them subdisk) size, supports more on-line administration capabilities,
and is generally more powerful. It supports concatenation, mirroring
and striping; RAID-5 is under development, as are more functions you'd
need to sign an NDA for me to tell you about. ;-)
VxVM 1.2, the current technology version, also supports a notion of
disk identity, which facilitates moving drives between addresses and
adapters without modifying the volume configuration; it also supports
manual (and with some simple programming, semi-automatic) cutover of
disks between shared-port systems when one of the systems fails.
(Sequent's CLUSTERS product is based partly on an earlier VxVM
version.) This also assists with our simplified disk
evacuation/replacement/hot-sparing capability.
We also have capabilities for analyzing performance to the subdisk
level, as well as moving on-line data without interruption of
availability. Extensions to our VxFS file system to support VxVM
integration make bringing a file system to a stable state easy; this,
in conjunction with our transaction-based configuration management,
make it possible to use VxVM for disk backup with no interruption of
availability.
As our technology is supplied as source to our OEM customers, the
versions, capability sets, and bundles are not identical from vendor to
vendor. Some offer only VxVM, others VxVM and VxVA; some bundle it,
others offer it layered. We also offer VxVM and VxVA for SCO under
our own label, through distributors.
>If it does provide Striping, how is the performance; both through-put
>and bandwidth?
We will have a performance brief, based on UnixWare and AIM-3,
available soon. Our own simulated multi-reader loads show a throughput
improvement of about 3x from a single drive to a four-way stripe on
commodity SCSI disks; obviously, your actual mileage will vary with OS,
system, drives, etc.
>Does the user interface have a nice pretty (and hopefully functional)
>GUI and a command line interface for those times the system is stuck
>in single user mode?
...or remotely. Yes, of course. VxVA is a Motif application that
supports full VxVM function. A full command line environment is
available too, as well as a library (on most platforms), plus a
disk-functions menu. Some vendors also support character menus; we use
a mkdev script for SCO, and SVR4 supports OA&M extensions.
>I'll collect responses mailed to alan@nabeth.cxo.dec.com and
>summarize.
Feel free. Or write me at rogerk@veritas.com.
--
ROGER B.A. KLORESE VERITAS Software
4800 Great America Parkway Santa Clara, CA 95054 +1 408-727-1222 x310
rogerk@veritas.com {apple,pyramid}!veritas!rogerk
There is a kind of success that is indistinguishable from panic. -- Edgar Degas
--
Alan Rollow alan@nabeth.cxo.dec.com
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
Newsgroups: comp.arch
Date: Mon, 29 Jan 2001 14:39:27 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Watch out for that "of course"! If I remember correctly, one early
version of MVS allowed page tables to be pageable, in the grounds
that they were designing for 48-bit addressibility back in 1980.
This was implemented and backed off, at least according to reports,
on precisely the grounds that I described - yes, it mostly worked,
but it was so fiendish as to be unmaintainable economically.
i put page'able tables into VM/370 in the early '70s and it shipped
with the rest of the resource manager product that i did in '76. i
dynamically calculated when real storage was being constrained and
dissolved the pagetable, invalidated the associated segment table
pointer, and "paged" the associated backing store table. Since I never
paged a "segment" that had pages in real storage ... all the
associated page table entries (for the segment) were uniformally
invalid ... so it was easy to dissolve the page table and just use the
segment table invalid entry.
vm/370 tightly bound the page table (for a segment) and the associated
backing store table (i.e. location of pages on disk). after dissolving
the page table, it was only really necessary to page out the backing
store table (for a segment, since the strategy only bothered to page a
table for a segment that had no allocated pages in real memory and so
all the associated page table entries were uniformally invalid).
a normal time-sharing operation might have several hundred quiescent
virtual memories belonging to users that were logged on but not having
actually typed/done something in the last several minutes. The
associated tables for quiescent virtual memory could represent 10-20%
of available real storage. Bringing the backing store table and
reconstituting the page table when a virtual memory re-activated was
just a very amall percent additional "page overhead" associated with
brining the actual virtual memory pages into real storage.
strictly batch MVS operations would tend to have little or no
quiescent virtual memories ... just batch job virtual memory
appearing, running to completion and then dissolving.
Original MVS design point called for a nominal rate of 4-5 page faults
per second (not only were quiescent virtual memories hardly an issue
but quiescent virtual pages were also hardly an issue).
At least one of the large VM/370-based time-sharing services used the
page'able table strategy as part of cluster process migration ... i.e.
all tables migrated to disk and then reconstituted on a different
processor complex within the same (shared disk) cluster. Later they
enhanced the support so that the tables could flow over communication
links (allowing process migration between processor complexes that
didn't have direct shared disk connectivity in common).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
Newsgroups: comp.arch
Date: Mon, 29 Jan 2001 15:17:42 GMT
Anne & Lynn Wheeler writes:
i put page'able tables into VM/370 in the early '70s and it shipped
with the rest of the resource manager product that i did in '76. i
dynamically calculated when real storage was being constrained and
dissolved the pagetable, invalidated the associated segment table
the strategy also involved not constituting a table at all until
actually needed. when a virtual memory was initially formed ... none
of the associated page tables &/or backing store tables were actually
built until there was a page fault for the first virtual memory page
in a segment (i.e. the corresponding segment table entry was just left
flagged as invalid).
work was initially done in the early '70s on vm/370 base but didn't
actually ship to customer until '76 (although distributed extensively
internally ... there was a large number of internal installations, for
instance the internal network was larger than the internet/arpanet
until around '85 and the vast majority of the nodes in the internal
network were vm/370).
random refs:
http://www.garlic.com/~lynn/94.html#52
http://www.garlic.com/~lynn/99.html#126
http://www.garlic.com/~lynn/99.html#180
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
Newsgroups: comp.arch
Date: Mon, 29 Jan 2001 16:13:03 GMT
... and for really heavily constrained real storage ... it would
switch to mode where if virtual memory had any significant execution
pause, all of the segment table entries would be flagged invalid, the
real tables left in place ... but the page table header time-stamped.
then not only would all tables for a quiesent virtual memory be
de-constituted ... but "active" virtual memories would be scanned for
individual segments that were quiesent (based on psuedo-LRU scanning
of time-stamps in individual page table headers).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
Newsgroups: comp.arch
Date: Mon, 29 Jan 2001 17:50:29 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Ah! MVS used a very technique, as far as I recall, probably derived
from yours. It is clearly a neat solution to a serious problem. What
is more, it does NOT have the problems that I was referring to, because
there is no way that a single page can need activating at a time that
its page table entry is paged out (as you point out) :-)
I would tend to call your technique swappable page tables, but all
terminology is debatable.
The reports that I heard of wrt MVS were of an all singing, all
dancing, fully and automatically pageable, page table system. I saw
a description, but cannot be certain that the code was ever released
(or even implemented, though I think it was). It sounded horrific.
POK had difference of opinion at time. besides ludlow and company
doing the initial aos prototype using CCWTRANS from cp/67 and testing
on 360/67 ... they also had a large performance modeling group that I
interacted with from time-to-time. I tried to heavily indoctrinate
them in LRU replacement algorithms ... but one of the things the
modeling group came up with is that performance would be better if
they selected non-changed pages for replacement prior to selecting
changed pages (i.e. only having to invalidate a real memory slot w/o
first having to copy it out to disk is more efficient,
right?). Absolutely no talking them out of it.
It wasn't until about '79 that MVS realized that it was selecting
highly used, shared system services pages for replacement before
private, changed task data pages for replacement and corrected the
"optimization" that the performance modeling group had come up with.
About the same time, MVS discovered a number of other interesting
anomolies in their handling of virtual memory. One was that at certain
times tasks went to idle they would flush all associated pages
(including forced writes) and place the pages in an available
pool. What they found was that under light to intermediate load there
were alwas doing the page writes even tho under those load conditions
the pages were alwas being "reclaimed" (i.e. original task needed the
pages before there was any reason to re-allocated the real storage to
some other task). They determined that they could use some dynamic
adaptive stuff to only do pre-writes of the pages when there was a
high probability that the pages weren't be relaimed.
The MVS group then approached me ... that since it was such a
significant performance discovery for MVS ... that it should also be
able to retrofit it to VM also. I had to inform them that I had never,
not done things that way. That the initial implementation that I had
done 10 or so years previous as an undergraduate implemented pools and
processes in that manner.
I also told them the tale of TSS/360 from that period ... that TSS/360
had sense of interactive tasks and batch tasks. Interactive tasks
would have their virtual memory pages pre-staged from the 2311 disks
to the 2301 fixed head "drum" prior to task activation. On leaving the
interactive queue (either going inactive or transition to
non-interactive), associated pages would be cleaned from the 2301 back
to the 2311. This was in addition to forcing the pages into & out of
real memory. Not only was TSS/360 doing the "fixed" algorithm real
storage management used by MVS ... but also managing migration of
pages to/from 2311<->2301 in a fixed manner ... w/o regard for any
contention for the resource and/or any dynamic adaptive
characteristics.
Some time I may relate the joke I played in the VM resource manager;
because the MVS resource manager did something in a particular way
... that I had to implement something similar before I could ship to
customers.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FW: History Lesson
Newsgroups: bit.listserv.ibm-main
Date: Mon, 29 Jan 2001 16:25:00 GMT
Rick.Fochtman@BOTCC.COM (Rick Fochtman) writes:
Actually, in my experience, adding more programmers to a late project makes
it even later. Generally takes too long to get new staff 'ramped up' into
the project.
i once saw something about intellectual productivity of collections of
people
max(IQ0, IQ1, ..., IQn)
sum(IQ0, IQ1, ..., IQn)/n
min(IQ0, IQ1, ..., IQn)
min(IQ0, IQ1, ..., IQn)/n
i.e. some collections tend to productivity equivalent to the member
with the lowest IQ divided by the number of members (i.e. tends to
zero).
i'm not sure if it was written up ... but management with "disasters"
frequently were allocated additional (some cases, large numbers of)
people to finish ... which resulted in their empire growing and
increasing their executive level (there frequently is this perverse
method of rewarding poorly performing projects). management that
consistently came in on time and under budget might be viewed as not
having to deal with hard problems ... as opposed to far exceeding
requirements.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HELP
Newsgroups: alt.folklore.computers
Date: Mon, 29 Jan 2001 18:45:00 GMT
Tom Van Vleck writes:
Most 7090 card reading was done by a 1401 next to it,
which could read column binary (optional feature) or BCD.
Reading these decks onto tape for input to the 7090 was
sometimes called "pre-store." Column binary format, for
FMS anyway, was also usually 72 columns of binary data
followed by serialization, and each card said where to
load its data, so dropping the deck was not always a disaster.
I wrote programs to handle entire 960-bit "card images" for
the social scientists.
i got a summer job to implement the 1401 (709-front-end) unit record
function on a 360/30. the 2540 reader/punch and 1403 printer were
moved from the 1401 to 360/30. It was valuable learning exercise
because I got to design my own device drivers, interrupt handlers,
storage allocation, task manager, monitor, etc.
normal operation for 360/30 was to do a read/feed/select-stacker combo
i/o operation in tight loop. BCD (non-binary) 709 decks were easily
handible with the 360 ebcdic. problem was column binary ... i.e. all
12 rows/holes were arrained into pair six-bit bytes .... which were
invalid ebcdic punch combination.
For the 709-frontend application, I had to do a (ebcdic) read
(no-feed) of 80 columns into 80 bytes. If that got an error, I would
reread the card with column binary read (which on 360 read the 80
columns into 160 bytes). When I got a succesful read, i would do a
separate fed/select-stacker.
2540 i/o operations (1 byte, 8-bit op code) ... from gx20-1703-7
read, feed, select stacker S S D 0 0 0 1 0
read 1 1 D 0 0 0 1 0
read, feed (1400-compatibility) 1 1 D 1 0 0 1 0
feed, select stacker S S 1 0 0 0 1 1
PFR, punch, feed, select stack S S D 0 1 0 0 1
punch, feed select stack S S D 0 0 0 0 1
where "S S" bits selects stacker
0 0 stacker R1
0 1 stacker R2
1 1 stacker RP3 (middle shared stacker between punch & reader)
where "D" bit selects
0 EBCDIC
1 col. binary
The 2540 was about a desk sized box about 40in? high with the reader on
the right side and the punch on the left side. In the middle were five
bins that processed cards went into. The left two bins/stack were
exclusive for the punch. The right two bins/stack were exclusive for
the reader and the middle bin/stacker could be selected by both the
punch and reader.
I once did a student registration application with standard manilla
colored cards containing student registration information to be read
and red striped punched cards. student registration card would be read
(into the middle stacker) and some preliminary validation
performed. If a problem was detected, a blank (red-striped) card was
"punched" right behind it.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First OS?
Newsgroups: alt.folklore.computers
Date: Mon, 29 Jan 2001 23:20:09 GMT
QSB@QRM-QRN.net (Allodoxaphobia) writes:
Such software was/were also called "control programs" and "monitors".
Redundantly one O/S was call "Control Program Monitor".
in fact, CP/67 stands for control program/67 and CMS originally stood
for Cambridge Monitor System (but was subsequently updated to be
Conversational Monitor System).
there are probably other refs from Melinda's history
http://www.princeton.edu/~melinda/
note hovever both CP/67 and CMS postdate os/360.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HELP
Newsgroups: alt.folklore.computers
Date: Mon, 29 Jan 2001 23:23:18 GMT
Anthony M Lenton writes:
Are you sure the 2540 was moved from the 1401. AIUI 2540 was released
with S/360. The 1402 reader, similar to the 2540, was the normal reader
on a 1401 but would not function on a 2821 controller which was necessary
to attach 1403 & 2540 to a 360/30.
--
Tony Lenton
not positive ... i was just a student and they let me have the 360/30
and the gear and told me it had come from the 1401. before i started
... they had been running the 30 in 1401 emulation mode (i.e. booting
and running the 1401 "MPIO" program deck from the reader with the 30
in 1401 hardware emulation mode).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
Newsgroups: comp.arch
Date: Mon, 29 Jan 2001 23:23:56 GMT
Paul Repacholi writes:
User, P0 and P1 tables where page/swapable. Parts of the kernel
are also pageable, but only at lower CPU priorities.
the original cp/67 kernel was non-pageable. I had done a hack on cp/67
the summer i worked at BCS that divided the cp/67 into two sections
the "fixed" portion and a non-fixed portion. The CP/67 kernel ran in
real, non-relocate mode ... but the hack i put in added some code to
the cp/67 linkage supervisor that would check the "to" address and if
above the line, do "virtual->real" translate on the address. If the
operation failed then the paging supervisor was called to fetch the
(kernel) page. Because the supervisor was running in non-virtual
memory mode, the kernel code that was being paged had to be carefully
segmented into 4k chunks (somewhat like OS/360 transient SVCs that had
to fit in 2k chunks, i.e. i previously had done lot of optimization
effort on various OS releases, including transient SVCs ... and didn't
see why I couldn't add effectively a similar capability to cp/67,
didn't have to deal with all the sys1.svclib PDS gorp tho).
While this hack never shipped in the standard CP/67 product, it was
incorporated into the initial transition from cp/67 to vm/370
(shipping in the initial release of vm/370). Basically, there was a
"kernel" virtual memory tables built for locating pageable kernel
chunks even tho the tables were never used to actually execute virtual
memory mode. In the original CP/67 hack, I also had copied the kernel
symbol table into the kernel pageable space... something that didn't
survive in the transition to VM/370 release one ... but I later put
back in as part of some debugging tool activity.
2-3 years later, when I did the pageable tables for each virtual
memory ... I built a similar abbreviated, miniture virtual memory
table for each virtual address space ... and used that to map the main
tables for purposes of managing the tables on disk and moving
back&forth between real storage and disk. Virtual address tables were
copied between the miniture virtual memory (that was used to move them
into & out of real storage) and areas of fixed storage. Fixed storage
only needed to contain the actual tables in active use and so got
quite a bit of compression (compared to leaving them laid out in their
miniture address space).
somewhat unreleated was that there was abbreviated psuedo task
structure built to go along with the "kernel" virtual memory tables
for kernel "paging". As part of the resource manager effort in the
early '70s (some of which was just porting CP/67 work to VM/370 work
that hadn't shipped in the standard product), I also totally rebuilt
the kernel serialization primitives ... part of this involved
re-assigning "hung" activity to the system psuedo task in order to
totally eliminate the VM/370 equivalent of zombie tasks. Later I also
made use of it when I redid the I/O supervisor to make it bullet proof
for the disk engineering labs.
random refs:
http://www.garlic.com/~lynn/2001b.html#8
http://www.garlic.com/~lynn/2000f.html#66
http://www.garlic.com/~lynn/99.html#32
http://www.garlic.com/~lynn/99.html#130
http://www.garlic.com/~lynn/2000.html#75
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/99.html#198
http://www.garlic.com/~lynn/2000c.html#69
http://www.garlic.com/~lynn/95.html#3
http://www.garlic.com/~lynn/96.html#18
http://www.garlic.com/~lynn/97.html#15
http://www.garlic.com/~lynn/99.html#31
http://www.garlic.com/~lynn/94.html#18
with regard to the kernel symbol table ... both CP/67 and VM/370 used
a modified version of the 360 BPS loader to initialize a kernel in
memory. The loader then transferred control to some specialized code
that wrote the memory image to disk. Normal machine booting reread
this memory image back from disk. The BPS loader builds the full
symbol table as part of getting everything correctly initialized. A
little known fact was that as part of the BPS loader transferring
control to the application, a pointer to the symbol table & count of
entries was passed in registers. All that was needed was copy the full
BPS loader symbol table to end of kernel and write it to disk with the
rest of the kernel (there was little or no ordering of the entries in
the BPS symbol table so a little sorting was done as part of the
copy).
random refs:
http://www.garlic.com/~lynn/94.html#11
http://www.garlic.com/~lynn/99.html#135
http://www.garlic.com/~lynn/2000b.html#32
http://www.garlic.com/~lynn/2001.html#8
http://www.garlic.com/~lynn/2001.html#14
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: what is interrupt mask register?
Newsgroups: comp.arch
Date: Mon, 29 Jan 2001 23:35:03 GMT
handleym@ricochet.net (Maynard Handley) writes:
What sort of signals does the system (as a whole) provide to users that
these bad things are happening?
I suspect (based simply on standard CS and engineer mentality) that the
problem is considered solved if a report goes to the OS which logs it
somewhere. That's fine if someone is reading the logs, which may or may
not occur. Again, the "engineering" response to this is to claim "operator
error", but that seems to me an unwillingness to actually solve the
problem.
typically on the mainframe systems there is huge body of recovery &
retry logic for most ever anomolous condition ... in addition to the
error going into logrec/erep for recording.
then there are detailed reports that go to all sorts of people based
on the recording ... including stuff about soft errors and predictive
failure analysis for pre-emptive service.
then the mainframe world has reporting services that provide industry
wide reporting across the whole install base.
I have this story (see ref) where somebody watching the industry wide
reporting noticed that there had been something like 15-20 total
errors of a particular kind during a period of a year (this was the
aggregate total errors across all installed, operating machines over a
period of a year, not an avg. per machine per interval ... but the sum
across all machines for the whole year) ... and they had only been
expecting something like 3-5 such errors across all machines for a
period of a whole year (imagine recording every SCSI bus error that
might occur every where in the world for every machine with a SCSI bus
and then generating industry wide reports on every such machine in the
world).
random ref:
http://www.garlic.com/~lynn/2000.html#21
http://www.garlic.com/~lynn/2001.html#22
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: what is interrupt mask register?
Newsgroups: comp.arch
Date: Mon, 29 Jan 2001 23:54:29 GMT
handleym@ricochet.net (Maynard Handley) writes:
What sort of signals does the system (as a whole) provide to users that
these bad things are happening?
I suspect (based simply on standard CS and engineer mentality) that the
problem is considered solved if a report goes to the OS which logs it
somewhere. That's fine if someone is reading the logs, which may or may
not occur. Again, the "engineering" response to this is to claim "operator
error", but that seems to me an unwillingness to actually solve the
problem.
stuff nominally doesn't perculate up to the user unless it is
impossible to mask the error/condition (retries, etc).
on the other hand, for mainframes with "batch" heritage there tends to
be huge infrastruction for application programming traps; scenerios
where evovling application programs started out accepting some default
system abnormal termination (with appropriate error messages) ... but
for some class of applications this prooved inadequate and they needed
application implementation specific error masking. for this they would
specify a trap and do application specific recovery.
This methodology tended to be somewhat heuristic and evolved along
with "programmable operator" recover heuristics (i.e. installations
installing automated operater message trapping and specifying
installation specific recovery masking methodologies).
A simple example I've used within the past couple of years is disk
space exhaustion by a SORT process in a complicated series of tasks
for a complex commercial application. Various UNIX'es didn't even
propagate the error indication up to the sort application level, as a
result the resulting sort'ed file was truncated with no indication to
subsequent steps. Many commercial mainframe shops specify a standard
system recovery process in the case of disk space exhaustion ... and
as a last resort, if all available processes fail, definitive
indication is propagated.
somewhat orthogonal ... but comment about effectiveness of
programmable operator in business critical 7x24 application:
http://www.garlic.com/~lynn/99.html#71
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HELP
Newsgroups: alt.folklore.computers
Date: Wed, 31 Jan 2001 00:59:44 GMT
ehrice@his.com (Edward Rice) writes:
What was the target operating environment? Why did you have to go all the
way down to device drivers and interrupt handlers -- even BOS would do some
of that for you and all the higher-up systems would do it all.
the 360/30 had PCP (I think release3 thru 6) running and i used it to
assemble and early testing of program. however they wanted to overlap
card->tape as well as overlap tape->printer/punch. so that drove
things to "basic" mode rather than "queued" mode and doing wait/post
on ECBs. getting the I/O program with enuf overlap then drove it down
to building my own CCWs and doing EXCP/SV0. The core program was about
a box of (2000) cards, statements, comments, etc. Doing any of the
standard DD stuff required having DCB macro. Turns out the core
program assembled in about 10 minutes ... but each DCB macro took an
extra six minutes of elapsed time to assemble (and needed five DCB
macros, two tapes, one printer, one reader, one punch, you could watch
the front panel lights and recognize when it was doing a DCB macro)
which added 30 minutes to the elapsed assembly time (stretching it to
40 minutes).
Since I was already doing buffering and multi-threaded logic with
wait/post ECBs ... along with building the CCWs for EXCP/SVC0 ... if I
put in a little direct hardware support and used the BPS loader with
the resulting text deck ... elapsed assemble time was cut from 40
minutes to 10 minutes (I could reasonably get three turn-arounds per
hr instead of one). Also, with the operating system out of the way
... I could also play games with the full 64kbytes of memory for
buffers trying to keep tapes, printer, punch, and reader running at
full-speed. I also had somewhat better control over error retry
strategies, i can't say that the system of the time was all that
robust.
I would get the 360/30 from 8am saturday until 8am monday for testing.
Doing the additional direct hardware support took a week or two of
time during the week of debugging ... but it could double testing turn
around.
It got so that for the 48hrs on the weekend ... I just lived machine
language and punch cards. A number of times, recognizing simple
program patche ... I could fan the assembler output punch cards,
recognize the appropriate card, put the card into 029 and DUP a new
card and multi-punch the new "binary" patch (this could be done in a
couple minutes rather than the 10+ minutes it took to reboot PCP &
re-assemble). Since I wasn't sleeping those 48hrs, I couldn't claim to
dream in machine language ... but during the weekend i lived machine
language (not english) and punch card codes (I didn't need the printing
on the top of a card to read the card).
Oh, boy -- let's do a code review of a 35-year-old program that none of us
has a copy of!
Lynn, why did you Read EBCDIC and then, if called for, Read Binary? Why
not simply issue a Read Binary and then, if the 7-9 punch wasn't there, put
the bits together into EBCDIC? That should have been trivial, since EBCDIC
was designed with card-punches in mind.
it worked ... and most of the stuff was bcd ... very little was binary
... and it got so i could do it a full reader speed ... after i got
the elastic buffering between the reader and the tape drives down.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HELP
Newsgroups: alt.folklore.computers
Date: 30 Jan 2001 22:23:45 -0700
ehrice@his.com (Edward Rice) writes:
What was the target operating environment? Why did you have to go all the
way down to device drivers and interrupt handlers -- even BOS would do some
of that for you and all the higher-up systems would do it all.
the other (excuse?) was i used what it was they said was available. I
had just finished my first computer class, introduction to fortran
spring semester and they gave me this as a summer job. The fortran
class used 709 ibsys ... you punched cards and were told what an ibsys
control card looked like. You might have 30-40 cards in your fortran
program, rubber band around it and you turned it in at a outside
window, came back later & got your cards back with some paper wrapped
around it with another rubber band.
I had to learn 360 machine language, 360 assembler, operating system
macros, load & execute, OS JCL, hardware I/O operations, tapes,
punches, printers, how to operate the machine, PCP system services
(like bsam, qsam, wait/post), etc. in a couple days ... with just
standard OS/360 documentation and no direction (other than the fact
that the tapes i generated for the 709 had to be the same as what 1401
MPIO generated).
Along the way, I also picked up how to clean tape drives, how to take
the reader & punch apart, clean it and put it back together again,
power cycle the machine, etc. Also when things wouldn't power sequence
correctly ... go around to each of the controllers, put them into
CE-mode ... re-power the machine ... and then individually bring up
the individual controllers. Say it is midnight sunday and you've been
at it for 40 hrs straight and machine stops working ... and university
isn't paying for off-shift maint. coverage. There is another 8 hrs of
dedicated time ... so you start reading the FE manuals and trying
various combinations of things to try and get it into useable
condition.
The university normal operation finished production 8am saturday and
normally things were shutdown. For the summer, they gave me a key and
I got the machine room for 48 hrs (until 8am monday) and typically not
only was I the only person in the machine room, but frequently for
most of the time, the only person in the building. I typically brown
bagged some stuff and worked 48hrs straight thru. This even continued
into the fall semester but it was sometimes hard to make monday
classes after having already been up for 48hrs straight.
One of the reasons that i was duping cards & multi-punching binary
program patches was that I didn't get a manual on the loader and learn
about REP cards until 8 weeks or so into the job (but by that time I
could read & type (multi-punch) binary cards almost as fast as
generating REP cards).
It probably wasn't until near the end of the summer that anybody from
ibm bothered to even mention that there was something else besides
OS/PCP (and the BPS loader deck that I had accidently stumbled
across).
Starting around the end of the summer, IBM started assigning brand-new
system engineers to the university (for tutoring?) They would stay
around for 3-4 months ... and then we would get a new one or two.
wage was same as the one i had washing dishes for the previous year
(student jobs are like that) ... but was somewhat more interesting.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: So long, comp.arch
Newsgroups: comp.arch
Date: Wed, 31 Jan 2001 16:00:10 GMT
mash@mash.engr.sgi.com (John R. Mashey) writes:
I've been winding down @ SGI since August, and 1/31/01 is my last day.
I'm off to be a partner @ Sensei Partners, a brand-new early stage
Venture Captial firm ... I've enjoyed the discussions
over the last 15 years or so, but I expect to be helping build companies
rather than computers, so I bid you all adieu and good luck. I will
still be mash, but @heymash.com.
not too long ago, I almost reposted as a reference
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: R6000 vs BIT SPARC
Date: 29 Nov 89 03:14:57 GMT
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
In article rathmann@eclipse.Stanford.EDU (Peter K. Rathmann) writes:
>
> Ok, R6000 vs BIT SPARC is too early to call, but other comparisons
> might be even more interesting. The R6000 based system was billed in
> the popular press as a mainframe, so does anyone have any numbers
> comparing it to more typical mainframes like the IBM 3090 or big
> Amdahl machines?
>
Please note: it's called an "Enterprise Server" rather than a mainframe;
the 6280 brochure doesn't ever say "mainframe", on purpose.
The claim is that the CPU performance is mainframe-uniprocessor class,
and that it's got pretty reasonable I/O.
According to a posting of Mike Taylor's a while back,
a few relevant numbers would be, for the fastest scalar mainframe for
which I have numbers:
Amdahl 5990 CPU RC6280
Cycle time 10ns 15ns (@67Mhz)
LLNL 64, Harmonic 11.9 MFlops 8.8 MFLOPS
LINPACK, 64, FORT 14.5 MFLOPS 10.3 MFLOPS
LINPACK, 32, FORT 16.8 MFLOPS 13.9 MFLOPS
Dhrystones (1.1) 90Kish? 109K, -O3
.. snip ... quite long winded
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: z900 and Virtual Machine Theory
Newsgroups: bit.listserv.ibm-main
Date: Thu, 01 Feb 2001 00:08:58 GMT
d10jhm1@US.IBM.COM (Jim Mulder) writes:
Fear not. They understood, as shown below. Keep in mind that
if we consider the Virtual Machine Concept" for (S/360 and its
descendents) to have begun in 1967 (CP 67), and IEF (SIE)
to have come out with XA around 1982, then the era of the
software VM implementation was 15 years, and the IEF era has
already been 19 years.
the part with CP/67 was with the model 360/67 ... but had been done
before with cp/40 on a 360/40 dating back to 1965. the 360/40 had
custom hardware modification for virtual memory ... but the basic
method of providing virtual machine was the native 360 architecture
(although virtual memory assisted in address space isolation).
there was an early virtual machine implemented on (I believe) a 155
prior to the availability of 370 virtual memomory that used a
base/bound address relocation mechanism (required contiguous allocated
storage) that provided address space isolation (i think the feature
was part of something to do with running DOS in a region under MVT?
... been awhile). It was done by Seattle IBM SE on the Boeing account.
The issue in the 360 & 370 era was very clear & stricked delineation
between problem mode & supervisor mode (with no supervisor state
information leakage into problem state)) and a single operation that
provided for transition between
1) supervisor state & problem state
2) hypervisor address space and virtual machine address space
along with the ability of the hypervisor to address the virtual
machine address space.
For cp/67 and vm/370 the method used was to run the hypervisor in
non-translate (real) addressing mode and rely on the PSW bit to switch
from relocate mode and non-relocate mode and at the same time for a
PSW bit to switch between supervisor state and problem state ... with
clean architecture that didn't allow leakage of supervisor state
information into problem state.
ECPS (virtual machine microcode assist availabe in the mid-70s)
introduced with the 138/148 provided for virtual timer support
(i.e. timers that ran at virtual machine speed rather than wall-clock
speed).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: perceived forced conversion from cp/m to ms-dos in late 80's
Newsgroups: alt.folklore.computers
Date: Thu, 01 Feb 2001 18:05:20 GMT
B W Spoor writes:
That's why I _still_ program in Cobol, despite it not being fashionable
on small systems.
Never came across REXX, but I have used Pascal in the past although I
never really liked it.
in the past decade I had a job to port a 50,000 line pascal
application from one platform to another. my impression was that
majority of pascal implementations haven't been targeted at large
complex applications; majority of them much more targeted as teaching
tool &/or simple PC applications (i.e. I had done quite a bit of
programming in the early '80s with turbo pascal on ibm/pc and got into
some mainframe pascal in the mid-80s). For one platform I was
constantly submitting bug reports and talking to the pascal support
team ... in what I thot was going to be a simple & straight-forward
port.
REXX i first used in the very late '70s when it was still "REX" and
before the name change and release as a product.
randoms refs:
http://www.garlic.com/~lynn/94.html#11
http://www.garlic.com/~lynn/94.html#22
http://www.garlic.com/~lynn/2000b.html#29
http://www.garlic.com/~lynn/2000c.html#41
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: occupational nightmares [was: Now early Arpanet security
Newsgroups: alt.folklore.computers
Date: Thu, 01 Feb 2001 19:00:54 GMT
jata@aepiax.net (Julian Thomas) writes:
No - you have it wrong - it was 'pretty little Polly Nomial' who was
chased by curly Pi.
i happened to run across the file on a floppy some time ago
IMPURE MATHEMATICS In which it is related how Curly Pi
accousted little Polly Nomial.
... snip ...
The moral of our sad story is this:
"If you want too keep your expressions convergent,
never allow them a single degree of freedom..."
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: z900 and Virtual Machine Theory
Newsgroups: bit.listserv.ibm-main
Date: Thu, 01 Feb 2001 19:29:06 GMT
edjaffe@PHOENIXSOFTWARE.COM (Edward E. Jaffe) writes:
CP's handling of STIDP is not a consideration. That is purely a software
implementation issue. What's being discussed here is the ability of a
host control program to obscure all hints at the true machine state
during guest operation (without IEF of course). That's strictly a
hardware issue. That capability was lost in ESA/370. Prior to that, the
Virtual Machine Concept" was still in-tact, no matter what CP returned
for STIDP.
an issue is can anything in a virtual machine directly access
priviledge state machine that would leak unwanted information into the
virtual machine &/or change priviledge state info that allows it to
affect the supervisor and/or other virtual machines.
just the fact that the machine is running in a virtual machine as
opposed to a real machine has been around since (at least) CP/67
release 3 with various x'83'/diagnose support.
the logic was that the x'83' instruction implementation was defined in
the architecture as beinge model dependent and effectively, a
360/virtual machine model was defined and the operation of various
x'83' features were defined that were specific to the cp/67 (and later
vm/370) virtual machine model.
just accessing bits in the PSW isn't an issue ... 24bit address psw
with ILC/CC/PM were available as part of BAL/BALR and were set with
SPM
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/7%2e5%2e72
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John Mashey's greatest hits
Newsgroups: comp.arch
Date: Fri, 02 Feb 2001 17:02:50 GMT
jfc@mit.edu (John F Carr) writes:
Based on my experience, IBM policy is that it is OK to leak information
to and through trade magazines. About 10 years ago I asked the IBM
representative at MIT Project Athena about their hot, new, unannounced
RISC workstation. He told me he couldn't leak the information to me
directly but he could give me a copy of the magazine on his desk which
had a good article on the RS/6000.
was it charlie (CAS) ... aka of compare&swap?
there was this joke about competitive analysis and leaked information
... that the company had so many (in some cases, competitive)
projects going on ... nobody was really sure which ones might ever
actually make it to first customer ship (FCS) ... any leaked
information was more likely to severely confuse any industry watchers.
At one time, there were supposedly 450+ different individuals that
were required to sign-off on any product announcement (and any one
could veto, which then would require escalation to override).
leaking wasn't ok ... it just was being so big and so many people
watching that there were bound to be some leaks which then got written
up and published (one source is like references to various flights
i.e. the austin/sanjose nonstops; and cleaners being paid for stuff
left behind on the plane).
minor historical note ... in the '80s one of my kids was at UT and
working for AA in austin ... and submitted the "suggestion" for the
first(?) austin/sanjose nonstop.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] How old are us guys? (was: First OS?)
Newsgroups: alt.folklore.computers
Date: Fri, 02 Feb 2001 17:35:10 GMT
Jim Esler writes:
I was the dishwasher until I went to college.
--
i was a dishwasher even after i went to college (dining hall opened at
6am, so had to get up at 5am to be on duty) ...
random ref:
http://www.garlic.com/~lynn/2001b.html#27
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John Mashey's greatest hits
Newsgroups: comp.arch
Date: Fri, 02 Feb 2001 20:56:44 GMT
"Stephen Fuld" writes:
OK, I'll bite! In the late 1960s-early 1970s I worked on a "true" SMP
Univac 1108. The multiple processors (OK, we only had two and the max
supported was 3) shared acces to the memory and were run by a single copy of
the OS. Each of its processors was treated identically. Each could do I/O.
At the time, the IBM shop next door had "clusters" of processors that shared
peripherals but not memory (Attached support processors - ASP) and I believe
there was a some model of the 360 that supported "attached proccesors" which
were sort of like the predecessors of numeric co-processors (no I/O
capabilities). What am I missing?
360/65 came in two-processor SMP version, sharing common memory and
both being able to do I/O. The 360/65 caveat was that the I/O
subsystem hardware was not shared. The configuration could be cleaved
and each processor run as totally independent operation with half the
memory, its own power supply, i/o subsystem, etc. In order to "share"
I/O ... the implementation relied on the same hardware that was used
to create "clusters" of 360s ... i.e. 2-4 "tailed" devices and/or
controllers. For devices that were only connected to a single channel,
an I/O initiation might have to be queued for the appropriate
processor with unique connectivity to the device.
The 1966 enhancement to the 360/65 ... the 360/67 had a "channel
controller" for multiprocessor environment (designed for 2-4
processors, but I know of no 4 processor configurations that were
built and I only know of one three processor configuration that was
built). The channel controller provided all processors to all I/O
channels (somewhat minimizing the need to have each processor with its
own I/O channel to each controller/device). The channel controller
also was a performance boost implementing independent paths to memory
(single processor configuration had single ported memory where there
could be simultaneous processor & I/O contention for memory bus).
SMP syncronization was supported by the standard 360 instruction TS
... test and set for atomic operation.
Some drawbacks was that the OS/360 implementation of SMP support on
the 360/65 had a spin-lock to enter the kernel.
Both TSS/360 (shipped code) for 360/67 smp and cp/67 (available but
not standard shipped code) had much finer grain locking
implementation. I believe MIT Lincoln Labs had one of the first 360/67
two-processor SMPs. The only 3-processor 360/67 that I'm aware of was
for Lockheed (I believe for manned orbital lab. approx. '68).
The fine-grain locking work on CP/67 by CAS ... led to the definition
for the compare&swap instruction (mnemonic chose because it was
charlie's initials). CAS became part of the standard 370 architecture
... but a prereq was that a programming model had to be first be
devised for CAS with appicability to non-SMP configurations (i.e. the
stuff that was originally generated for the CAS programming notes
showing use of atomic CAS for threaded code, enabled for interrupts,
running in single-processor & SMP configurations).
random refs:
http://www.garlic.com/~lynn/93.html#14
http://www.garlic.com/~lynn/94.html#02
http://www.garlic.com/~lynn/94.html#28
http://www.garlic.com/~lynn/94.html#45
http://www.garlic.com/~lynn/98.html#8
http://www.garlic.com/~lynn/98.html#16
http://www.garlic.com/~lynn/99.html#88
http://www.garlic.com/~lynn/99.html#89
http://www.garlic.com/~lynn/99.html#176
http://www.garlic.com/~lynn/99.html#203
370s continue the 360 SMP design ... two processors, each with their
own independent I/O capability. In the early '80s IBM introduced the
3081 SMP ... it wasn't a traditional IBM two-processor configuration
because it was packaged in the same box and shared some common
components that precluded it being operated as two independent
processors. It was possible to combine two 3081 processors into a four
processor 3084 (where it was possible to decouple the two 3081s and
operate them independently).
for dates of some 360 models:
http://www.isham-research.freeserve.co.uk/chrono.txt
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] Currency controls (was: First OS?)
Newsgroups: alt.folklore.computers
Date: Fri, 02 Feb 2001 21:08:38 GMT
javnews@earthlink.net (John Varela) writes:
On Fri, 2 Feb 2001 15:30:37, Lars Poulsen wrote:
Last weekend I listened to a former Pan-Am captain who blamed the failure of
Pan-Am on unfair competition from national airlines [1], including currency
controls. He told the group that France limits (present tense!) the amount of
money a resident can take out of the country, and that the purchase of a
ticket on a foreign airline counts against the currency limit while a ticket
on Air France does not. I found that hard to believe of any western European
country at any time in the last 30 or 40 years, but had no facts to argue with
him.
So: are there currency controls in effect in western Europe today?
[1] I thought Pan-Am's principal problem was that they were until near the
end barred from carrying domestic traffic, while domestic airlines were given
overseas routes. Thus one could fly, say, American from Topeka to Frankfurt,
but to fly Pan-Am one had to change terminals at JFK.
in the early 80s, i used to fly monday night non-stop red-eye from SFO
to JFK at least once a month (and come back friday afternoon). PanAm,
TWA, and American had flights all about the same time. I don't know
what started it ... but PanAm ten sold the "pacific" to United
(including many of the planes ... PanAm 747 "clippers" got repainted
in United colors). The press releases at the time were that PanAm felt
that it could be more profitable if it concentrated on expanding into
the east-coast/European traffic (and get out of the pacific & the west
coast). The crash sort of ground all of that to a halt.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John Mashey's greatest hits
Newsgroups: comp.arch
Date: Fri, 02 Feb 2001 21:42:55 GMT
"Stephen Fuld" writes:
You're right, since the 1108 did not have cache, some of the problems went
away. Univac's first cached CPU was the 1100/80 in 1978 (?). It could also
be SMP'd. They solved the cache coherency problem by having the cache in a
separate cabinet, with interfaces for all the CPUs and arbitration, etc.
Since there was only one copy of the data in cache, no coherency problems
:-).
the higher end 370 machines (155, 165, 158, 168) and the 303x machines
in the 70s had cache and SMP tended to run the cache syncronization at
higher rate that the processor ... and slow down the processor by 15%
(compared to uniprocessor) to allow for cache syncronization and
cross-cache invalidation signals (i.e. raw hardware speed of a
two-processor SMP was calculated at 2*.85 of a single processor, not
taken into account any actual cache line churn and software overhead).
In the early '80s, the 3081 was supposed to (initially) come in a two
processor configuration. However, TPF (follow-on to ACP, specialized
IBM operating system used by airline industry and some financial
operations) didn't have multiprocessor support and needed flat-out
performance. A slightly stripped down 3081 was eventually offered
called the 3083 with a single processor running 15% faster than a
standard 3081 processor (the 3081 had introduced a new "IBM" SMP
concept because it wasn't a standard "IBM" two-processor
configuration, i.e. it couldn't be cleaved into two independent
operating single processors which was characteristic of all the
standard IBM 360, 370, & 303x SMPs).
One of the features for 3033 ... which had an SMP impact was the
re-appearance of the IPTE instruction (invalidate page table
entry). While IPTE, ISTE, ISTO were in the original 370 architecture
... they were dropped because one of the original models in the 370
line had difficulty with the implementation (so it was dropped from
implementation in all 370 models). 370 virtual memory management (as
shipped) had to get by with the PTLB instruction (purge look aside
buffer). The re-appearance of the IPTE instruction in the 3033 was
defined that not only did it turn on the invalid bit in the page table
entry and selectively invalidate any associated entry in the hardware
look-aside buffer ... but it would do it for all TLBs in a SMP
complex.
The issue going from standard two-processor to the 3084 four-processor
were significant to performance because rather than getting
cache-invalidate signals from one other processor, it was now possible
to get cache invalidates from three other processors.
Some operating system activity in the 3081 time-frame was system
enhancements to make sure nearly all kernel storage allocation was
done on cache-line boundaries and in cache line increments (at least
minimized independent processors operating on different data that
happened to be co-located in the same cache line).
I alwas believed that the 370 SMP issues with cross-cache invalidates
was one of the main issues behind 801 activities stead fastly not
supporting cache syncronization. It wasn't until the break for 601
with Motorola, et all that saw cache syncronization efforts. The only
RIOS implementation was OAK using RIOS 0.9 chip and four processors in
a box. Shared memory was achieved by flagging segments as either
shareable or not-shareable. Bus activities involving memory flagged as
shareable bypassed cached (there was no associated memory line
caching).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why SMP at all anymore?
Newsgroups: comp.arch
Date: Fri, 02 Feb 2001 22:01:50 GMT
jonah@dlp.CS.Berkeley.EDU (Jeff Anderson-Lee) writes:
It struck me as I was reading through posts on old SMP designs that
current processors are potentially bus/memory latency/bandwidth limited.
So what is the benefit of doing SMP anymore? Seemingly it just puts
more pressure on an already scarce resource. But people keep making
SMP designs (at least dual/quad P-III/alpha boards).
So what am I missing? How does the cache help enough to avoid
problems? Or are most workloads just not bandwidth limited yet?
Seemingly dual processors could help reduce context save/restore in
come cases where a few jobs are passing data through a pipe or shared
memory, but I'd guess that SMP would be hitting the wall soon.
[And no, this isn't a homework troll. :-)]
note that there is a difference between memory latency limited and
memory bandwidth limited. both SMP and out-of-order execution are
technques of getting more out of a memory subsystem where the overall
system is memory latency limited (but there still remains available
memory bandwidth).
early '70s saw some work on a "3081-like" 360/195 SMP ... i.e. not
everything in the complex was doubled. The problem then was pipeline
drain typically because of branch stall. The solution was to add dual
i-stream support with dual instruction counters, dual set of
registers, etc and pipeline operation with one bit tag indicating
i-stream. There was lower probability of the 195 pipeline draining
(because of branches) with two i-streams feeding it (instead of just
one).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John Mashey's greatest hits
Newsgroups: comp.arch
Date: Sat, 03 Feb 2001 01:18:11 GMT
Anne & Lynn Wheeler writes:
the higher end 370 machines (155, 165, 158, 168) and the 303x machines
in the 70s had cache and SMP tended to run the cache syncronization at
higher rate that the processor ... and slow down the processor by 15%
(compared to uniprocessor) to allow for cache syncronization and
cross-cache invalidation signals (i.e. raw hardware speed of a
two-processor SMP was calculated at 2.85 of a single processor, not
taken into account any actual cache line churn and software overhead).
i should say that they started out more like a 10% penalty for cache
syncronization (i.e. hardware of two processor was closer to 1.8 times
performance of a single uniprocessor rather than 1.7 times).
all of the 360s, 370s, etc were (very) strong memory consistency. I
was fortunate to be the rep to some SCI activities early on
... scalable coherent interface with weak(er) memory consistency and
directory-based cache management ... used (at least by) DG, Convex
(exemplar), and sequent for their scalable processor
designs. somewhere in the archives i probably have SCI drafts (in
addition to SCI definition for asynchronous operation implementing
memory consistency, there are also definitions for implementing
low-latency asynchronous i/o operations).
random refs:
http://sdcd.gsfc.nasa.gov/ESS/eazydir/inhouse/mobarry/mobarry_sc96/index.html
http://www.hcs.ufl.edu/carrier/
http://www.dg.com/about/html/sci_interconnect_chipset_and_a.html
http://sunrise.scu.edu/WhatIsCoherence.html
http://wwwbode.informatik.tu-muenchen.de/events/scieurope2000/index.html
http://sci.web.cern.ch/SCI/
http://hmuller.home.cern.ch/hmuller/sci.htm
http://ei.cs.vt.edu/~history/Parallel.html
http://www.sequent.com/hardware/numaq2000/
http://www.nersc.gov/~jed/talks/net-tutorial/sld062.htm
http://www.mpi.nd.edu/downloads/mpidc95/abstracts/html/fleischman/
http://www.scizzl.com/
and at the other end ... random ref:
http://www.garlic.com/~lynn/99.html#182
http://www.garlic.com/~lynn/2000b.html#45
http://www.garlic.com/~lynn/2000c.html#9
http://www.garlic.com/~lynn/2000c.html#21
http://www.garlic.com/~lynn/2000e.html#22
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John Mashey's greatest hits
Newsgroups: comp.arch
Date: Sat, 03 Feb 2001 16:23:46 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
I don't understand the 7.7 at all. Was it a typo?
finger check ... reference was to previous note that was 2 times .85
... i.e. and was attempting to say 1.8 instead of 1.7
A colleague of mine studied the 370/165 microcode, and found a loophole.
I wrote some code to test his hypothesis, and it was really there. We
never did report it to IBM, on the grounds that we regarded any program
that could suffer from it as being broken beyond redemption.
If you started an I/O operation into memory, waited until one byte was
changed (in a spin loop), and then updated a byte a short distance on,
you could get the cache out of step with the memory. I forget the
exact constraints, but they were pretty tight.
if i had to guess, 165 i/o microcode had fetched the cache line and
had a local copy someplace ... possibly the distance was more than a
doubleword and less than a cache line.
As that was the worst memory/cache inconsistency he found, I can agree
that its consistency can be regarded as strong ....
there were other funnies. 360 instructions did bounds checking
(starting & ending addresses) before starting instruction. 370
introduced "long" instructions that were suppose to incrementally
execute (effectively a byte at a time). "move character long" could
specify a zero length "from" argument, a zero pad character and up to
a 16mbyte length "target" argument ... which could be used to do
things like clear a region of memory (and test amount of memory
available). 370/125 & 370/115 incorrectly implemented the "long"
instruction microcode to do the bounds checking prior to starting the
instruction. do bounds checking first met then none of the instruction
was executed rather than at the point/address where there was some
sort of storage access issue.
the "long" instructions were also defined as interruptable and
restartable (i.e. i/o interrupt could interrupt a "long" instruction
... in which case progress to date would be reflected in the registers
and then the instruction could be restarted from the point it was
interrupted).
in the smp world, there are number of instructions that fetch, update,
and store the results ... but not defined to be atomic like test&set
and compare&swap. MVS kernel made extensive use of immediate
instructions to update flags (like or-immediate & and-immediate) or
even the "execute" versions of same (i.e. load the argument for the
or-immediate instructed into a register and use the "execute"
instruction to execute the or-immediate ... i.e. the argument of the
or-immediate instruction is taken form the register rather than
directly from the instruction). Because their use was so pervasive,
MVS petitioned that the or-immedate and and-immediate instructions be
implemented as atomic (even tho the architecture specifically stated
that they are non-atomic). This wasn't a problem with os/360 since it
used a spin-lock to enter the kernel ... you wouldn't encounter kernel
code on both processors with the same instruction interleaving access
to the same byte ... but MVS kernel going to finer-grain locking got
into a problem.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First OS?
Newsgroups: alt.folklore.computers
Date: Sat, 03 Feb 2001 22:26:05 GMT
Brian Inglis writes:
The fact that it had console, reader, punch, printer peripheral
assignments validates that some part of its design was based on
CP/67 or later versions of the IBM VM Control Program. Anyone
remember enough of both to say how much of a connection there
was, other than the name?
I never saw enuf of CP/M to form an opinion. I seem to remember some
people that I knew to have worked on CP/67 saying they had done
something or another in conjunction with CP/M ... as well as ????
(something MP?).
In any case, not too long ago ... I ran across somebody's statement
that one of the V-something? real-time systems appeared to be
substantially a port of the VM/370 network monitor to C ... the C code
followed the same logic as the 360 assembler code and the comments
were supposedly directly from the 360 assembler down to the same
misspellings.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John Mashey's greatest hits
Newsgroups: comp.arch
Date: Sun, 04 Feb 2001 16:00:44 GMT
Bruce Hoult writes:
At least one of the Power features listed above is shared with the
PDP-11, namely that subroutine calls store the return address in a
register rather than on the stack. The PDP-11 let you use any register
(but I seem to recall that R6 was traditional) while the Power/PowerPC
uses a single Link register. Combined with a protocol that passes
arguments in registers this is great for making small leaf functions
fast (and use no stack at all). It also helps you do threaded
interpreters, and helps unify CPS (Continuation-Passing Style) and
"normal" code.
standard 360 instructions for subroutine call were BAL/BALR (branch
and link and branch and link register). In fact, there has been
sporadic criticsm of the 360-genre of doing things that way and not
having any stack support at all.
Typical use
L R15,=A(subrout)
BALR R14,R15
&
BAL R14,subrout
... where R14 & R15 are symbolics for registers 14 & 15
Bits 32-63 of the 360 PSW (program status word) were stored in the first
argument:
bits
32-33 ILC ... instruction length code
34-35 CC ... condition code
36 ... fixed-point overflow mask
37 ... decimal overflow mask
38 ... exponent underflow mask
39 ... significant mask
40-63 ... instruction address (of following instr)
subroutine return typically returned on the address in R14 after first
setting the condition code (w/o having changed and/or needing to
restore the program interrupt masks, although some subroutines might
have found it necessary to change one or more of the program interrupt
masks and then restore them).
some of the 360 dates.
Ann. FCS
IBM DOS/360 6???? 6???? SCP FOR SMALL/INTERMEDIATE SYSTEMS
IBM OS/360 64-04 6???? PCP - SINGLE PARTITION SCP FOR S/360
IBM S/360-30 64-04 65-05 13 SMALL; 64K MEMORY LIMIT, MICROCODE CTL.
IBM S/360-40 64-04 65-04 12 SMALL-INTERMED.; 256K MEMORY LIMIT
IBM S/360-50 64-04 65-08 16 INTERMED.-LARGE
IBM S/360-60 64-04 N/A LARGE - NEVER SHIPPED
IBM S/360-62 64-04 N/A LARGE - NEVER SHIPPED
IBM S/360-70 64-04 N/A LARGE - NEVER SHIPPED
IBM S/360-92 64-08 VERY LARGE SCIENTIFIC S/360
IBM S/360-91 64-11 67-10 REPLACES 360/92
CDC 6800 64-12 LARGE SCIENTIFIC SYSTEM - LATER 7600
IBM OS/360 65-?? 68-?? MFT - FIRST MULTIPROGRAMMED VERSION OF OS
IBM 2314 65-?? 65-04 DISK: 29MB/DRIVE, 4DR/BOX REMOV. MEDIA
$890/MB
IBM S/360-65 65-04 65-11 07 MAJOR LARGE S/360 CPU
IBM S/360-75 65-04 66-01 09 LARGE CPU; NO MICROCODE; NOT SUCCESSFUL
IBM S/360-95 65-07 68-02 THIN FILM MEMORY - /91, /92 NOW RENAMED /91
IBM S/360-44 65-08 66-07 11 INTERMED. CPU,;SCIENTIFIC;NO MICROCODE
IBM S/360-67 65-08 66-06 10 MOD 65+DAT; 1ST IBM VIRTUAL MEMORY
IBM PL/I LANG. 66-?? 6???? MAJOR NEW LANGUAGE (IBM)
IBM S/360-91 66-01 67-11 22 VERY LARGE CPU; PIPELINED
IBM PRICE 67-?? 67??? PRICE INCREASE???
IBM OS/360 67-?? 67-12 MVT - ADVANCED MULTIPROGRAMMED OS
where ("Ann." is announce, & FCS is first customer ship) from:
http://www.isham-research.freeserve.co.uk/chrono.txt
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John Mashey's greatest hits
Newsgroups: comp.arch
Date: Sun, 04 Feb 2001 16:41:39 GMT
Anne & Lynn Wheeler writes:
standard 360 instructions for subroutine call were BAL/BALR (branch
and link and branch and link register). In fact, there has been
sporadic criticsm of the 360-genre of doing things that way and not
having any stack support at all.
standard OS/360 register convention was
r15 linkage "to" address
r14 linkage "from" address
r13 "save" area
r12 "basic" module addressing
os/360 module convention was the calling module supplied a "savearea"
pointer in R13 that could be utilized by the subroutine.
typical entry into a subroutine or module called for
STM R14,R12,12(R13)
save registers r14 & r15, followed by r0-r12 starting at displacement 12 bytes
off R13
then
LR R12,R15
move the linkage "to" address into the standard module base addressing
then if the called module expected to do any calling of other modules
itself, it would do
Getmain
system call for storage allocation of a new savearea (returned in R1)
ST R1,8(R13)
ST R13,4(R1)
LR R13,R1
forward/backward chain the saveareas and switch to the new save area.
A non-reentrant subroutine (i.e. not expecting to be called before
exiting might use a static data area inside the subroutine for a
savearea rather than dynamically allocating one).
at module exit. If a dynamic savearea had been allocated it would
do something like
LR R1,R13
L R13,4(R13)
FREEMAIN
otherwise, it just would backchain the saveareas.
And then typically set the return condition code and then do a
LM R14,R12,12(R13)
BR R14
The above, including the condition code setting was frequently done
by standard assembler macro:
RETURN R14,R12,RC=0
or
RETURN R14,R12,RC=(15)
i.e. set the return condition code restoring R14 thru
R12 and then return.
examples of 360 asembler
http://www.cuillin.demon.co.uk/nazz/trivia/hw/hw_assembler.html
http://members.tripod.co.uk/nvcs/Samples/nvcsget.htm
http://jm.acs.virginia.edu/~drs8h/articles/storupdt.txt
http://www.itc.virginia.edu/~drs8h/articles/idcupdt.txt
http://www.kcdata.com/~pagarner/pgprexit
http://webpunkt.com/piotr/sju/cus1122/program1/SAMPLE
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: what is interrupt mask register?
Newsgroups: comp.arch
Date: Tue, 06 Feb 2001 18:18:06 GMT
Sander Vesik writes:
That's exactly why comparing to scsi is bad.
the comparison wasn't a technology issue it was with respect to how
disk drives were attached to the system and the error recording
methodology for that attachment and trying to relate it to some more
commonly available commputing systems and their disk attachment
methodology.
obviously there may be major technology implementation differences
between how disks are attached to mainframes and how disks may be
connected to servers ... and the difficulty of relating mainframe
implementation technology to various workstation/server implementation
technology.
so the abbreviated analogy didn't work ... possibly a long winded
analogy.
Imagine all the industry of all workstations and (non-mainframe)
servers manufactured.
Imagine that eash of these computers do local error recording.
Imagine that all the operations responsible for these installed
computers forwards a copy of the error reports in machine readable
format (supporting a number of different methodologies) to an industry
reporting service.
The industry report service aggregates the information from the error
reports for the whole industry and publishes industry-wide reporting
information.
Imagine that one of the manufactures selected some fairly common
recoverable error condition (for the analogy ... you choose which ever
one it is, something that shows up relatively frequently on error log)
that is included in the error report and logging ... and decided that
they wanted to engineer their next product so that the total number of
errors of this type reported for a period of a year for all machines
across all machines bought and installed by customers was less than 5.
Imagine that the manufactur then had several people who's fulltime job
it was to follow the industry reports and compare engineering
predictions against actually reported values.
Imagine that these people employed full time by the manufactur, found
that instead of 3-5 total errors (aggregate qacross all machines for
the a period of a year) there were 15-20 such reported errors.
Imagine that the manufactur then took a signficant course of action to
find and correct whatever problem was responsible for the difference
between the expected 3-5 total aggregate errors across all machines
for a period of a years and the reported 15-20 total aggregate errors
across all machines for a period of a year.
For purposes of the analogy, the particular type of error chosen isn't
so important other than it should be a relatively common error. For
purposes of the abbreviated analogy the component the SCSI-bus
component in server/workstation implementations roughly correspond to
the component under discussion in the mainframe scenerio (regardless
of whether SCSI-bus can be re-engineered to meet such a requirement).
Using the SCSI-bus component as an analogy, then the manufactur would
redesign and re-implement that component in an attempt to achieve the
goal of 3-5 total aggregate errors per year for all machines. If
necessary eliminating all SCSI-bus support in all of their products
and replacing it with something else that does meet the requirement
(and in such case, over a period of a couple years, all manufactures
elminate support for SCSI-bus in all of their products in order to
also meet the same requirement). Of if the SCSI-bus is retained then
re-engineering the SCSI-bus so it, in fact, would meet the requirement.
The original posting & quick analogy wasn't to actually compare the
current mainframe component hardare against the current SCSI-component
... it was sufficient to show that the SCSI-component possibly hasn't
yet been re-engineered to meet the same objectives, that possibly
workstation/server manufactures don't have dedicated people tracking
industry wide reporting for all machines, and/or that the
workstation/server industry doesn't support a industry-wide service
which collects all error reports for all machines and generates
summary reports.
I would claim that for the purpose of the matter at hand that the SCSI
comparison was actually quite good ... because it does serve the same
functional purpose as the mainframe component under discussion and the
industry hasn't re-engineered it so that there is an aggregate of of
3-5 total errors across all machines over a period of a year. It would
appear that the SCSI component, in fact has a signficantly higher
error rate.
The analogy wasn't for the purposes of looking at the reasons for the
errors, the analogy was about industries tolerance for errors, and
typically with very low tolerance for something comes extensive Q&A
and auditing procedures supported by the industry to
verify/authenticate error quality.
--
Anne & Lynn Wheeler | lynn@garlic.com, http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First OS?
Newsgroups: alt.folklore.computers
Date: Wed, 07 Feb 2001 19:42:47 GMT
Eric Chomko writes:
I would believe you if the IBM 5100 system had an OS and the first
two characters in its name were 'CP'. Fact is that IBM had to go shopping
for an 8 bit OS for the IBM PC because they didn't have one.
the people i heard talk about doing something with CP/M (& MP/M),
while having worked with CP/67 and VM/370 ... I have no knowledge that
they were ever directly associated with IBM.
Around that time, the VM Waterloo Share tape had possibly more lines
of code than were in the ibm distribution for the vm kernel (i.e. &
there were possibly many more times non-IBMers writing code for vm
than there were IBMers writting code for VM).
I was once involved in a 20 person collection of people on the west
coast (growing to 40) that was going to do software for the ibm/pc; it
was sometime before the ibm/pc had been announced and we contacted
boca about allowing us to be responsible for doing the software. boca
said that it was just fine ... that they were in the hardware business
and not doing software and it was just fine if we took responsibility
for doing software. about once a month ... we re-verified that it was
ok if we took responsibility for software and boca said just fine.
after working in this manner for six months or so, boca called to say
that they "owned" all responsibility for both hardware and software
inside ibm and if their were any people interested in doing software
related stuff for the ibm/pc they had to transfer to boca.
I've seen a number of projects that were subcontracted to an outside
organization with the "responsible" organization owning the contract
rather than allow another internal organization have responsibility.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First OS?
Newsgroups: alt.folklore.computers
Date: Wed, 07 Feb 2001 20:46:38 GMT
Anne & Lynn Wheeler writes:
I've seen a number of projects that were subcontracted to an outside
organization with the "responsible" organization owning the contract
rather than allow another internal organization have responsibility.
slightly related (some of the same people on the west coast) but
different circumstances and different outcome
http://www.garlic.com/~lynn/2000g.html#40
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: what is interrupt mask register?
Newsgroups: comp.arch
Date: Wed, 07 Feb 2001 21:00:26 GMT
Sander Vesik writes:
But isn't this totally misleading and invalid comparison? Among all the
the other things, not all "scsi errors" are errors related to the scsi
channels themselves at all. IIRC it also covers:
any time somebody tried to access a cdrom drive with no media inside
which also is used for detecting if there is media inside
if a drive dies while being connected, you get loads of them
if there is a buffer overrun in writing a cd
and loads of others.
Global logging of that technology just doesn't make sensxe.
as an aside ... in an error sensitive market segment, the hardware and
the reports would be engineereed so that normal operational indicators
are filtered out from what are considered errors and the engineering
and reporting would also be able to classify the remaining errors as
to type & category.
as mentioned there was specific new engineering done so that a
particular kind of error in this class of components was done with the
expectation that total aggregate errors (of the specific type) were
reduced to 3-5 across all machines for a period of a year.
the really remarkable thing in an error sensitive market segment that
not only is the engineering important but as important (or possibly
more so) is an industry service that is able to audit and report
errors across all vendor hardware.
In that sense it is analogous to TPC and/or SPECmarks in the
performance and/or thruput sensitive market or the Common Criteria for
the security sensitive market segment (i.e. industry service providing
auditable results as to different vendors standing with regard to the
variable of interest to the market). There is also nothing that
precludes there being overlap between the performance/thruput
sensitive market segment, the error sensitive market segment and/or
the security sensivite market segment.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PC Keyboard Relics
Newsgroups: alt.folklore.computers
Date: Wed, 07 Feb 2001 21:06:46 GMT
jchausler writes:
I remember it on 029 keypunch keyboards. I don't recall what or if
I did anything with it as I was not normally using machines which
understood EBCDIC but an older code. Does anyone know what
combination of holes were punched in a card to get the "not"
character? I can then check my UNIVAC 1108 card code to
internal (f