List of Archived Posts
2002 Newsgroup Postings (6/28 - 7/11)
- Where did text file line ending characters begin?
- User 2-factor authentication on laptops
- Where did text file line ending characters begin?
- DCAS [Was: Re: 'atomic' memops?]
- DCAS [Was: Re: 'atomic' memops?]
- DCAS [Was: Re: 'atomic' memops?]
- how to set up a computer system
- CDC6600 - just how powerful a machine was it?
- how to set up a computer system
- More about SUN and CICS
- Signing email using a smartcard
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- AS/400 and MVS - clarification please
- Al Gore and the Internet
- AS/400 and MVS - clarification please
- AS/400 and MVS - clarification please
- AS/400 and MVS - clarification please
- CDC6600 - just how powerful a machine was it?
- 6600 Console was Re: CDC6600 - just how powerful a machine was
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- AS/400 and MVS - clarification please
- CDC6600 - just how powerful a machine was it?
- trains was: Al Gore and the Internet
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- : Re: AS/400 and MVS - clarification please
- IBM was: CDC6600 - just how powerful a machine was it?
- "Mass Storage System"
- IBM was: CDC6600 - just how powerful a machine was it?
- pop density was: trains was: Al Gore and the Internet
- pop density was: trains was: Al Gore and the Internet
- IBM was: CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- IBM was: CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- Unisys A11 worth keeping?
- CDC6600 - just how powerful a machine was it?
- AS/400 and MVS - clarification please
- AS/400 and MVS - clarification please
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- AFP really was 2000: CDC6600 - just how powerful a machine was
- wrt code first, document later
- Unisys A11 worth keeping?
- wrt code first, document later
- wrt code first, document later
- CDC6600 - just how powerful a machine was it?
- CDC6600 - just how powerful a machine was it?
- wrt code first, document later
- Unisys A11 worth keeping?
- BIOMETRICS
- subjective Q. - what's the most secure OS?
- Hercules and System/390 - do we need it?
- Hercules and System/390 - do we need it?
- privileged IDs and non-privileged IDs
- Unisys A11 worth keeping?
- Does Diffie-Hellman schema belong to Public Key schema family?
- CDC6600 - just how powerful a machine was it?
- Hercules and System/390 - do we need it?
- Does Diffie-Hellman schema belong to Public Key schema family?
- TCPA
- A Lesson In Security
- Unisys A11 worth keeping?
- A Lesson In Security
- Does Diffie-Hellman schema belong to Public Key schema family?
- HONE was .. Hercules and System/390 - do we need it?
- Does Diffie-Hellman schema belong to Public Key schema family?
- Does Diffie-Hellman schema belong to Public Key schema family?
- Fw: HONE was .. Hercules and System/390 - do we need it?
- HONE
- McKinley Cometh
- HONE
- HONE
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where did text file line ending characters begin?
Newsgroups: alt.folklore.computers
Date: Fri, 28 Jun 2002 12:35:01 GMT
"Rostyslaw J. Lewyckyj" writes:
A couple of consequences of this, I believe, are:
You begin building a hierarchy of escapes similar to the idea
of set of sets, etc. in math.
You introduce history into the processing of the data stream.
i.e. you have to remember whether you are processing data
of part of an escape, etc.
another consequence of making length implicit .... is that programmers
start to ignore some of its more practical issues resulting in a huge
exploision in the number of length-related vulnerabilities & exploits
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: User 2-factor authentication on laptops
Newsgroups: comp.security.misc
Date: Fri, 28 Jun 2002 12:40:01 GMT
Ali-Reza Anghaie writes:
Or you can rig up something by which a person would have to present their
private key via removeable media. Say business-card sized CD-R.
i've seen this done with secure filesystem (i.e. the whole harddisk is
encrypted) ... and the system needs to boot off the (business-card
sized) CD-R ... which then asks for password to unlock the key file
... in order to have any access to the hard disk.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where did text file line ending characters begin?
Newsgroups: alt.folklore.computers
Date: Fri, 28 Jun 2002 15:45:48 GMT
jcmorris@mitre.org (Joe Morris) writes:
A slightly different problem in this class occurred in the IPL (IBMese
for "boot") program used by OS/360. The S/360 architecture has no
mechanism to directly obtain the memory size, so the IPLTXT program
(loaded into memory by the hardware) wrote zeros through memory
until it gets a program interruption for an invalid memory address.
The joker was that the S/360 architecture provided for exactly 24 bits
of addressing for memory. When the first machines with 16 MB of
memory (oh ye gods, the cost of that memory) arrived, the IPLTXT
program cheerfully ran through memory looking for the address where
an interruption occurred -- and never found it, since the addressing
logic quietly looped the effective address from 2^24-1 to 0.
some similar but different happend on 370/125. somebody had changed
the CP "loader" to use the MVCL instruction to clear and test for
memory size (the "loader" booted, read the information for a new
kernel and wrote it to disk in load format .... so it could be booted
from disk).
The CP "loader" programmer was original the BPS (very early 360) card
deck loader with some number of subsequent modifications.
In any case, instead of looping thru memory setting it to zeros ...
it was replaced with MVCL. All the original 360 instructions were
defined to pretest all the memory access and protection information
before starting the instruction. 370 introduced a couple instructions
(mvcl, clcl) that were defined to incrementally execute ... a byte at
a time. They could be interrupted and restarted ... but they also
could incrementally work up to a page boundary (w/o requiring all
virtual pages to be resident at one time) or other forms of conditions
that would terminate the instruction.
In any case, the 370/125 initially shipped with a bug in the microcode
where the instruction arguments were pretested and the instruction
never executed if the pretest failed. As a result the loader instead
of getting storage cleared and idea of the machine size ... got an
indication that there was no storage.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCAS [Was: Re: 'atomic' memops?]
Newsgroups: comp.arch
Date: Fri, 28 Jun 2002 19:33:29 GMT
Terje Mathisen writes:
The limited spin loop is to avoid the risk of pegging a cpu when
something bad has happened, and the OS probably have to go in and clean
something up, or just let some other process finish whatever it wants to
do before it can release the contested lock.
no serious system or application delivery code would ever have
uncontrolled loops. simple desktop throwaway applications under the
assumption that there is a human attending ... might default to system
or human kill for one reason or another (with human expected to
perform remediation actions). system and application delivery code
(including dim/dark room web farm apps) should always bracket all
loops/conditions and have a couple levels (or more) of automated
back-off/remediation strategy (this is applicable to both system level
services ... as well as higher level, more sophisticated application
services); aka somewhat difference between programs and business
critical services.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCAS [Was: Re: 'atomic' memops?]
Newsgroups: comp.arch
Date: Fri, 28 Jun 2002 23:09:33 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Similarly, I consciously and positively do NOT put loop limits in
cases where there is no obvious upper bound, the user kill action
is equivalent to the one I would take if I detected an excessive
loop, and the real criterion for killing the program is likely to
be that the user has specified too large a task for his resource
limits (or patience).
the original post tried to make specific distinction between a program
being run by a user and a service possibly being operated in dim/dark
room with nobody around .... the former can have human factors
considerations .... the later might be something like supporting ATM
cash machines (or various flavors of webservers in large webhosting
farm). they have totally different design point assumptions
.... although one could make a case that a lot of the web farm stuff
being deployed may have evolved from desktop environment and possibly
has numerous design point assumptions about desktop operation (as
opposed to totally different design point used for service operation).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCAS [Was: Re: 'atomic' memops?]
Newsgroups: comp.arch
Date: Sat, 29 Jun 2002 09:11:46 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Yes, but my point stands even there. If the only reasonable action
on a loop limit exceeded is to abort and let the controlling system
(whether operating system, human or other) sort out the mess, and
there is no natural limit to put on loop counts, then there is no
point in having them. While this is a fairly specific circumstance,
it is a very common one.
This argument was used by some people who ought to have known better
talking about embedded programming and numerical errors. They claimed
that not allowing the OPTION of aborting on an error was correct, as
failure during embedded running is unacceptable. I pointed out that
(a) this made debugging MUCH harder and hence increases the chance of
failure and (b) aborting is generally better than giving wildly wrong
answers (e.g. reversed signs).
original code can be bad .... and the remediation can be bad.
very early in CP/67 system supported full dump and auto-reboot/restart
so that it was possible to diagnose various kernel failures and also
keep running (although there was service interruption).
tale from the multics crowd and justification for fast file system
(because of comparison between cp/67 restart times and multics restart
times .... both projects were done in the same bldg. at 545 tech sq).
http://www.multicians.org/thvv/360-67.html
the other case that I'm fairly familiar with is when i redid the i/o
supervisor to make it absolutely bullet proof (initially for the disk
engineering lab). a common failure mode was whole series of tight
kernel loops related to i/o operations ... which were all done based
on retrying an operation ... because that was what the i/o
specification said to do (frequently some sort of busy condition, it
wasn't a counter loop ... it was a retry operation that would never
stop). unfortunately, various kinds of hardware glitches could result
in things not quite conforming to the i/o
specification/architecture. i had to do almost total rewrite,
bracketing all sorts of retry operations (with things like retry limit
counts). no explicit i/o error actually occured ... but the bracketing
code would treat the situation as if an i/o error had occured, logged
it, aborted the operation and then kept going.
http://www.garlic.com/~lynn/subtopic.html#disk
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how to set up a computer system
Newsgroups: alt.folklore.computers
Date: Sun, 30 Jun 2002 20:05:25 GMT
Joe Yuska writes:
You forgot the 35-ton Liebert for the peripherals, and the 400 Hz
motor-generators and water chiller system for the mainframe.
in addition to the PDUs and the water chillers ... these days many
places, you have to have the water tank on the roof of the building
for water recycling instead of just having a 4inch or larger water
pipe just dumping water into the sewer.
some cases you might run into room loading limits and have to figure
out some other solution to high volume water flow straight into the
sewer.
some past related discussions on pdus, water chillers and tanks:
http://www.garlic.com/~lynn/2000b.html#82 write rings
http://www.garlic.com/~lynn/2000b.html#85 Mainframe power failure (somehow morphed from Re: write rings)
http://www.garlic.com/~lynn/2000b.html#86 write rings
http://www.garlic.com/~lynn/2001.html#61 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001m.html#40 info
http://www.garlic.com/~lynn/2002g.html#62 ibm icecube -- return of watercooling?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Mon, 01 Jul 2002 01:41:55 GMT
mschaef@eris.io.com (MSCHAEF.COM) writes:
It's not the CDC 6600, but this site has information on one of its
almost contemporaries:
original long ago ... reposting from
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe:
rain/rain4
158 3031 4341
Rain 45.64 secs 37.03 secs 36.21 secs
Rain4 43.90 secs 36.61 secs 36.13 secs
also times approx;
145 168-3 91
145 secs. 9.1 secs 6.77 secs
rain/rain4 was from Lawrence Radiation lab ... and ran on cdc6600 in
35.77 secs.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how to set up a computer system
Newsgroups: alt.folklore.computers
Date: Mon, 01 Jul 2002 13:59:07 GMT
Howard S Shubs writes:
So -that's- what that was for! You're talking about the big rectangular
building -right- next to I93, yes? Just south of the on-ramp?
remember when they had momentary abberration and considered not
completing i93.
the issue was there is this existing elevated section coming down from
the north that was four lanes .... with traffic having strong y-split
at north station/garden. i93 elevated with four lanes would feed into
the same elevating section about 100yards(?) before the traffic
y-split pattern ... creating a strong x-traffic pattern ... in
addition to merging from 8 lanes for 4.
When somebody realized that the architect messed up in the design and
"in theory" you would have two streams of cars traveling at 55 MPH
effectively crossing each other in a very short physical space
... they realized they would have to dump all the i93 traffic off into
the streets before the elevated merge and the last couple mile section
of i93 would never be used. The issue that was investigated that since
the last couple mile section was never going to be opened .... whether
is was worthwhile actually building that section. The analysis in the
press was that it would cost the state something like $50m in
construction penalties if it canceled the building of the remaining
section ... and $200m to finish building the section. However since it
was supposedly an interstate (even tho it would never meet any
interstate standards .... that even if they ever did open the section
for traffic ... the speed limit ... because of the upcoming merge ...
and strong "X" traffic pattern would fail interstate standards), the
federal gov. paid 90 percent (would only actually cost the state $20m
to complete).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More about SUN and CICS
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 01 Jul 2002 14:22:33 GMT
g.goersch@WORLDNET.ATT.NET (Bo Goersch) writes:
Meanwhile, the package was re-evaluated and it was decided to proceed
with the new release on either VSE or MVS. No word from the powers that
be on where it will sit yet although a good case for MVS is being made
based upon the pre-req of a smaller CPU and no extras (FILESERV, OPC,
etc..) which leaves me with mixed emotions. The company is not
considering SUN equipment due to a large AIX investment. It seems SUN
loses out and we do too, running MVS on a small box brings back fears of
trying to run MVS on a 370-115/2, it ran, but nothing else did, and of
course the alternative is VSE.
ran VM on 125 ... but in doing so uncovered 125 m'code bug with MVCL
instruction. I had done some tuning for CP/67 kernel size on 256k
360/67 ... which included adding enhancement to be able to make part
of the kernel "pageable". The pageable stuff was picked up for VM/370
kernel .... but the fixed kernel still got quite a bit bloated. It
took a bit of re-arranging code from the fixed kernel to make
operating on 256k machine reasonable.
recent thread with respect to storage size issues and IPL:
http://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
the 115 & 125 were effectively the same machine, both had the same
engines .... basically up to nine microprocessors with appropriate
microcode loaded to perform the various control/io functions ... about
a 800kip microprocessor. The difference was that the 115 used the
standard 800kip engine for the 370 microcode load (at 10:1 emulation
giving effectively about 80kip 370 instruction rate). The 125 used all
the same engines .... except the engine that the 370 emulation code
ran on was about a 1mip processor (with 10:1 emulation yielded about
100kip 370 thruput).
I once worked on a project that would populate up to five of the
microprocessor bus positions with 125 microprocessor engines with 370
microcode load .... creating a 5-way multiprocessing
configuration. The microcode was also tweaked to put majority of
tasking & SMP management into the microcode. The disk controller
microcode was also tweaked to offload some amount of the paging
supervisor.
random refs:
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000e.html#7 Ridiculous
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#19 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Signing email using a smartcard
Newsgroups: alt.technology.smartcards
Date: Mon, 01 Jul 2002 14:39:00 GMT
"Bernt Skjemstad" writes:
Has anyone out there sucseeded in signing email using a certificate (digital
ID) on a smartcard?
I have a smartcard reader which is tested and working (Omnikey Cardman 2020
USB), and a smartcard containing a certificate for signing email. The
problem is how do I get an email client to use the certificate on the
smartcard? Up to now I only get up the software certificates (which I have
downloaded from Thawte and VeriSign).
Anyone who have done this before me? Or someone with any ideas?
Bernt
note that the certificate and the private key are two completely different
things.
nominally a public/private key is generated. A signing consists of
calculating the SHA-1 of the data (20 bytes) and then "encrypting" the
SHA-1 with the private key yielding a 20 byte signature (or in the
case of FIPS186 federal digital signature standard yields 40 byte
signature).
Given the original message and the public key, the recipient can
verify the signature.
A certificate is one of the methods for transporting the public key to
the recipient .... in order for the recipient to be able to perform
the signature verification. Basically a certificate contains something
like your name and your public key ... and is digitally signed by
thawte or verisign private key.
In effect, a certificate is also a signed message. Before the
recipient can use a public key in a certificate to verify your message
... they must "verify" the signature on the certificate .... say
thawtes or verisigns ... by already having thawtes/verisigns public
key sitting around somewhere (i.e. they've used some other method of
obtaining the public key used to sign certificates ... and have that
public key stored locally).
Note in the case of something like PGP .... basically the use of
certificates isn't necessary ...all public keys are acquired and
stored locally by recipients (basically the method in the certificate
model of acquiring public keys for "certification authorities" and
storing them locally is used for all public keys .... doing away with
the requirement for having separate "certification authority" public
keys and certificates).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Mon, 01 Jul 2002 20:38:50 GMT
kent@nettally.com (Kent Olsen) writes:
They were so much easier to use than VM, MVS, CICS, etc... Depending
on the application, the 6000s outran the IBMs, sometimes the IBMs
outran the 6000s. They were definitely the two biggest horses in the
race.
note that CMS on VM ... had copyfile command ... effectively inherited
from CTSS (aka some of the CMS people had worked on CTSS) ...
although huge number of parameters were added to the copyfile over
time .... eventually endowing it with all sorts of extra capability
(as opposed to just simply doing a file copy).
In the same bldg (545 tech sq) some other people that had worked on
CTSS were working on Multics. Both CMS and unix trace some common
heritage back to CTSS.
here is page giving command correspondance between cms, vax, pc-dos,
and unix:
http://www.cc.vt.edu/cc/us/docs/unix/cmd-comp.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Mon, 01 Jul 2002 21:05:00 GMT
"Douglas H. Quebbeman" writes:
Although the Wheelers refer to RAIN/RAIN4, LINPACK was also
used for relative speed comparisons, and has been ported to
modern platforms and other languages. You should be able to
find any number of different versions all over the net...
linpack numbers (including 6600):
http://ap01.physik.uni-greifswald.de/~ftp/bench/linpack.html
bunch of stuff from above
Computer N=100(Mflops)
------------------------------------ --- -------------
Cray T916 (1 proc. 2.2 ns) 522
Hitachi S-3800/180(1 proc 2 ns) 408
Cray-2/4-256 (1 proc. 4.1 ns) 38
IBM RISC Sys/6000-580 (62.5MHz) 38
IBM ES/9000-520 (1 proc. 9 ns) 38
SGI CHALLENGE/Onyx (6.6ns, 2 proc) 38
DEC 4000-610 Alpha AXP(160 MHz) 36
NEC SX-1 36
FPS 510S MCP707 (7 proc. 25 ns) 33
CDC Cyber 2000V 32
Convex C-3430 (3 proc.) 32
NEC SX-1E 32
SGI Indigo2 (R4400/200MHz) 32
Alliant FX/2800-200 (14 proc) 31
IBM RISC Sys/6000-970 (50 MHz) 31
IBM ES/9000-511 VF(1 proc 11ns) 30
DEC 3000-500 Alpha AXP(150 MHz) 30
Alliant FX/2800-200 (12 proc) 29
HP 9000/715 (75 MHz) 29
Sun Sparc 20 90 MHz, (1 proc) 29
Alliant FX/2800 210 (1 proc) 25
ETA 10-P (1 proc. 24 ns) 27
Convex C-3420 (2 proc.) 27
Cray-1S (12.5 ns) 27
DEC 2000-300 Alpha AXP 6.7 ns 26
IBM RISC Sys/6000-950 (42 MHz) 26
SGI CHALLENGE/Onyx (6.6ns, 1 proc) 26
Alliant FX/2800-200 (8 proc) 25
NAS AS/EX 60 VPF 25
HP 9000/750 (66 MHz) 24
IBM ES/9000-340 VF (14.5 ns) 23
Meiko CS2 (1 proc) 24
Fujitsu M1800/20 23
DEC VAX 9000 410VP(1 proc 16 ns) 22
IBM ES/9000-320 VF (1 proc 15 ns) 22
IBM RISC Sys/6000-570 (50 MHz) 22
Multiflow TRACE 28/300 22
Convex C-3220 (2 proc.) 22
Alliant FX/2800-200 (6 proc) 21
Siemens VP400-EX (7 ns) 21
IBM ES/9221-211 (16 ns) 21
FPS Model 522 20
Fujitsu VP-400 20
IBM RISC Sys/6000-530H(33 MHz) 20
Siemens VP200-EX (7 ns) 20
Amdahl 1400 19
Convex C-3410 (1 proc.) 19
IBM ES/9000 Model 260 VF (15 ns) 19
IBM RISC Sys/6000-550L(42 MHz) 19
Cray S-MP/11 (1 proc. 30 ns) 18
Fujitsu VP-200 18
HP 9000/720 (50 MHz) 18
IBM ES/9221-201 (16 ns) 18
NAS AS/EX 50 VPF 18
SGI 4D/480(8 proc) 40MHz 18
Siemens VP100-EX (7 ns) 18
Sun 670MP Ross Hypersparc(55Mhz) 18
Alliant FX/2800-200 (4 proc) 17
Amdahl 1100 17
CDC CYBER 205 (4-pipe) 17
CDC CYBER 205 (2-pipe) 17
Convex C-3210 (1 proc.) 17
Convex C-210 (1 proc.) 17
Cray XMS (55 ns) 17
Hitachi S-810/20 17
IBM ES/9000 Model 210 VF (15 ns) 17
Siemens VP50-EX (7 ns) 17
Multiflow TRACE 14/300 17
Hitachi S-810/10 16
IBM 3090/180J VF (1 proc, 14.5 ns) 16
Fujitsu VP-100 16
Amdahl 500 16
Hitachi M680H/vector 16
SGI Crimson(1 proc 50 MHz R4000) 16
FPS Model 511 15
Hitachi M680H 15
IBM RISC Sys/6000-930 (25 MHz) 15
Kendall Square (1 proc) 15
NAS AS/EX 60 15
SGI 4D/440(4 proc) 40MHz 15
Siemens H120F 15
Cydrome CYDRA 5 14
Fujitsu VP-50 14
IBM ES/9000 Model 190 VF(15 ns) 14
IBM POWERPC 250 (66 MHz) 13
IBM 3090/180E VF 13
SGI 4D/340(4 proc) 33MHz 13
CDC CYBER 990E 12
Cray-1S (12.5 ns, 1983 run) 12
Gateway 2000 P5-100XL 12
IBM RISC Sys/6000-520H(25 MHz) 12
SGI Indigo 4000 50MHz 12
Stardent 3040 12
CDC 4680InfoServer (60 MHz) 11
Cray S-MP/MCP101 (1 proc. 25 ns) 11
FPS 510S MCP101 (1 proc. 25 ns) 11
IBM ES/9000 Model 340 11
Meiko Comp. Surface (1 proc) 11
Gateway 2000 P5-90(90 MHz Pentium) 11
SGI Power Series 50MHz R4000 11
Stardent 3020 11
Sperry 1100/90 ext w/ISP 11
Multiflow TRACE 7/300 11
DEC VAX 6000/410 (1 proc) 1.2
ELXSI 6420 1.2
Gateway 2000/Micronics 486DX/33 1.2
Gateway Pentium (66HHz) 1.2
IBM ES/9000 Model 120 1.2
IBM 370/168 Fast Mult 1.2
IBM 4381 90E 1.2
IBM 4381-13 1.2
MIPS M/800 (12.5MHz) 1.2
Prime P6350 1.2
Siemans 7580-E 1.2
Amdahl 470 V/6 1.1
Compaq Deskpro 486/33l-120 w/487 1.1
SUN 4/260 1.1
ES1066 (1 proc. 80 ns Russian) 1.0
CDC CYBER 180-840 .99
Solbourne .98
IBM 4381-22 .97
IBM 4381 MG2 .96
ICL 3980 w/FPU .93
IBM-486 33MHz .94
Siemens 7860E .92
Concurrent 3280XP .87
MIPS M800 w/R2010 FP .87
Gould PN 9005 .87
VAXstation 3100-76 .85
IBM 370/165 Fast Mult .77
Prime P9955II .72
DEC VAX 8530 .73
HP 9000 Series 850 .71
HP/Apollo DN4500 (68030 + FPA) .60
Mentor Graphics Computer .60
MIPS M/500 ( 8.3HHz) .60
Data General MV/20000 .59
IBM 9377-80 .58
Sperry 1100/80 w/SAM .58
CDC CYBER 930-31 .58
Russian PS-2100 .57
Gateway 486DX-2 (66HHz) .56
Harris H1200 .56
HP/Apollo DN4500 (68030) .55
Harris HCX-9 .50
Pyramid 9810 .50
HP 9000 Series 840 .49
DEC VAX 8600 .48
Harris HCX-7 w/fpp .48
CDC 6600 .48
IBM 4381-21 .47
SUN-3/260 + FPA .46
CDC CYBER 170-835 .44
HP 9000 Series 840 .43
IBM RT 135 .42
Harris H1000 .41
microVAX 3200/3500/3600 .41
Apple Macintosh IIfx .41
Apollo DN5xxT FPX .40
microVAX 3200/3500/3600 .40
IBM 9370-60 .40
Sun-3/160 + FPA .40
Prime P9755 .40
Ridge 3200 Model 90 .39
IBM 4381-11 .39
Gould 32/9705 mult acc .39
NORSK DATA ND-570/2 .38
Sperry 1100/80 .38
Apple Mac IIfx .37
CDC CYBER 930-11 .37
Sequent Symmetry (386 w/fpa) .37
CONCEPT 32/8750 .36
Celerity C1230 .36
IBM RT PC 6150/115 fpa2 .36
IBM 9373-30 .36
CDC 6600 .36
IBM 370/158 .22
IBM PS/2-70 (16 MHz) .12
IBM AT w/80287 .012
IBM PC w/8087 .012
IBM PC w/8087 .0069
Apple Mac II .0064
Atari ST .0051
Apple Macintosh .0038
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Mon, 01 Jul 2002 21:12:50 GMT
Larry__Weiss writes:
Does anyone know when UT Austin retired their CDC-6600 ?
don't know about campus ... but balcones research had a cray and my
wife and I manage to donate a bunch of HYPERchannel equipment to them
for interconnecting various stuff.
thorton after working on 6600 left cdc and founded NSC and built
HYPERChannels.
random past stuff
http://www.garlic.com/~lynn/99.html#119 Computer, supercomputers & related
http://www.garlic.com/~lynn/2001.html#19 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#20 Disk caching and file systems. Disk history...people forget
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AS/400 and MVS - clarification please
Newsgroups: bit.listserv.ibm-main
Date: Mon, 01 Jul 2002 23:19:40 GMT
it_hjw@JUNO.COM (Harold W.) writes:
In a couple weeks, I will be venturing into new territory (i.e., I will
do a security assessment at a new client organization for the first
time). I'm a bit confused, because on their initial background
submission, they are stating that they run MVS on their AS/400. I called
the primary contact (who is not in the IS division), and he insist that
it is how things are. Based on my knowledge, this is not supported, and
I have never even heard of it happening. Maybe I'm overlooking
something, I've only been doing this 4 years.
Has anyone ever heard of MVS running on an AS/400, if it is even
possible?
note while the as/400 some years ago ... moved from a cisc hardware
architecture to a power/pc chipset .... it is a power/pc
chipset. Running MVS on as/400 is like saying running MVS on any other
kind of hardware with a power/pc chipset (apple, rs/6000, as/400,
etc).
you could possibly get a p/390 card running mvs in a rs/6000 .... i
have no idea whether you could get a p/390 card running in an as/400
or not. This isn't a case of running MVS on a power/pc chipset ... it
is a case of running MVS on a p/390 card .... which can fit in such a
box (apple, rs/6000, or as/400).
here is discussion of P/390 card in an rs/6000
http://www.tech-beamers.com/r390new.htm
a possible question is does any of the as/400 boxes support PCI bus
which would take a P/390 card and can you get software in the as/400
that talks to the p/390 card. Even tho aix, apple, and as/400 all run
on power/pc chips .... the software/programming environments are
different.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jul 2002 02:06:47 GMT
Floyd Davidson writes:
Gingrich was very prominent on the national political scene yet
his activity in support of DARPA (which admittedly is
significantly second to Al Gore's) is unknown by the public.
Newt Gingrich at the time didn't think it was politically worth
much. That does suggest a very basic difference in his view of
the Internet compared to Al Gore's view. Gore actually
understood how significant the Internet was going to be, long
before it was. He may well be the only member of Congress who
had a clue until it was all but a done deal.
total aside .... from possibly '88 to possibly '92 .... while there
was some NSF funding for NSFNET backbone (but substantial amount of
the resources were in excess of the NSF funding and "donated" by
commercial/industry sources) ... the "official?" government and darpa
strategy was OSI/GOSIP.
There could be a case made that if comercial/industry interests hadn't
been so heavily involved in the NSFNET and regionals .... that left to
"purely" government influence ... everything would have been migrated
to the morass of OSI and we wouldn't have any internet at all today.
misc. past discussions about OSI & GOSIP (and other things)
http://www.garlic.com/~lynn/subtopic.html#xtphsp
some gosip, nren, etc discussions:
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
other gosip specific mentions:
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom.
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2001e.html#17 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#6 YKYGOW...
http://www.garlic.com/~lynn/2002g.html#21 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
I have copies of gosip-v2.txt and gosip-v2.ps. Misc. from
"gosip-order-info.txt" (9/91):
GOSIP Version 1.
----------------
GOSIP Version 1 (Federal Information Processing Standard 146) was
published in August 1988. It became mandatory in applicable federal
procurements in August 1990.
Addenda to Version 1 of GOSIP have been published in the Federal
Register and are included in Version 2 of GOSIP. Users should obtain
Version 2.
GOSIP Version 2.
----------------
Version 2 became a Federal Information Processing Standard (FIPS) on
April 3, 1991 and will be mandatory in federal procurements initiated
eighteen months after that date, for the new functionality contained
in Version 2. The Version 1 mandate continues to be in effect.
Version 2 of GOSIP supersedes Version 1 of GOSIP. Version 2 of GOSIP
makes clear what protocols apply to the GOSIP Version 1 mandate and
what protocols are new for Version 2.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AS/400 and MVS - clarification please
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 02 Jul 2002 02:16:39 GMT
SEYMOUR.J.METZ@CUSTOMS.TREAS.GOV (Shmuel Metz , Seymour J.) writes:
1. The 2305 was a fixed-head disk
2. The drums were 2301 and 2303.
basically 2303 and 2301 were the same physical device. 2303 was used
with standard disk controller. 2301 was essentially a 2303 that
read/wrote four heads in parallel (and had four times the data
transfer rate of the 2303) and had a high-speed controller.
2301 held about 4mbytes of data. TSS & CP/67 formated 2301 with 9 4k
pages on a pair of 2301 "tracks" (eight physical "2303" tracks).
old comparison of 360/67 with 3 2301s compared to 3081k with six 2305
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AS/400 and MVS - clarification please
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 02 Jul 2002 02:19:52 GMT
efinnell@SEEBECK.UA.EDU (Edward J. Finnell, III , Ed) writes:
Don't think we ever ran the 2305, MMC was humongous, but did have some of the
STK SSDs that emulated them. I was scared to death of the things and would only keep
the MIX primary and SWAP datasets on them. Blow off a few TSO users, just have to
log back on..... then we got suckered into some of the Amdahl 6880's and entered
the world of continual EC change.
anybody out there run any 1655s from intel that emulated 2305. I think
there was something like 500 built ... and all went to internal
corporate installations.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AS/400 and MVS - clarification please
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 02 Jul 2002 09:31:48 GMT
IBM-MAIN@ISHAM-RESEARCH.COM (Phil Payne) writes:
I also remember an IBMer trying deperately to convince me that a fully
populated 3380 string didn't have exactly the same string switch path
busy problem as four full strings of 3350. He came back several times
- even tried to get me browbeaten by management. Then when they got
(a form of) dual port, the foils made exactly that point.
i got all sorts of grief making the statement that the relative disk
system thruput had declined by a factor of 10 over a 15 year period.
GPD (disk division) assigned the performance modeling group to
prooving the statements wrong. previous ref:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the door
what the group came back with was that i had slightly understated the
problem, if you took into account RPS-miss .... the relative disk
system thruput had declined by more than a factor of 10 (aka
cpu/memory goes up by a factor of 50+, disk thruput goes up by a
factor of 5-, relative disk system thruput declines by a factor of
more than 10). There was also an big issue with significant increase
in 3880 processing overhead as well as anytime the 3880 had to switch
channel interfaces.
I got nailed on this because I had built a bullet proof I/O supervisor
.... so the disk engineering labs could run the testcells in an
operating system environment. The first time they switched a string of
16 3350s from 3830 controller to first 3880 (over a weekend), they
first suggested that I had made software changes over the weekend that
resulted in the big performance hit. Fortunately this was six months
prior to FCS of 3880s .... and there was time to do some tweaking of
the m'code. misc. refs:
http://www.garlic.com/~lynn/subtopic.html#disk
the result was reformulated into recommended system configuration
presentation and initially given at Share 63, presentation B874
(8/18/84). Summary from the paper:
DASD subsystems have been crucial to the success of time-sharing
systems for over twenty years. Hardware has evolved and components
get bigger and faster at differing rates. Faster CPUs are now
available with parallel processing capabilities that exceed the
traditional notions of IO requirements. Bigger external storage as
well as larger and faster memories are coming on line that will
require even more effective storage and performance management. If
the full system potentials are to be realized, the effectiveness of
the user IO is going to have to be improved.
Configuration of DASD subsystems for availability and performance is
accomplished by using many dedicated channel paths and keeping strings
short. The requirement for high path availability to an arm to
support good response leads to the less than 25% busy channel
guidelines, etc. Where this is too expensive or impractical for
space, cost, or configuration reasons, compromises must be made. DASD
capabilities, quantified by reliability, throughput, response time and
cost, can make an application successful or unsuccessful. Equally
important are the effects of the application environment. An
understanding of this environment as well as the DASD parameters
usually is required for successful application management. An
extensive data base cataloging the systems past performance, coupled
with a calibrated model provides what is effectively an expert or
knowledge based system for exploring these compromises.
Storage management, the system centered management of capacity and
performance, is required to deal with the complexities of active and
inactive data. Because of the large number of DASD and connections
involved, the effects also are difficult to simulate and measure
precisely. More attention to the IO subsystem, in particular, the
user data base IO, is required to realize the potential of current and
future technologies.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Tue, 02 Jul 2002 20:03:21 GMT
eugene@cse.ucsc.edu (Eugene Miya) writes:
Be warned with Lynn and the other IBM folk, (I like Lynn), but they have a
tendency to quote 32-bit benchmarks against 60 and 64-bit CDC and Cray
benchmarks, and this is why Bailey's first rule in benchmark is the way it is.
I don't have proof anymore but i believe the RAIN4 numbers were for 32
bit and the "RAIN" numbers wree for "double precision" 64bit.
"fast double precision" was introduced for 168-3 (not on initial 168-1
machines) ... and so the 9.1 secs should be for RAIN ... as was the
6.77 secos for the 91.
the interesting numbers are the 3031 and 158 numbers. The processor
engine in the 3031 and 158 were the same; however in the case of the
158 .... there were "integrated channels" ... aka there was two sets
of microcode running on the same 158 processor engine .... the
microcode that implemented the 370 instruction set ... and the
microcode that implemented the I/O support ... and the processor
engine basically had to time-slice between the two sets of microcode.
For the 3031, there were two "158" processor engines ... one processor
engine dedicated to the 370 function (i.e. the 3031) and a second
"158" processor engine (i.e. the "channel director") that implemented
all the I/O function outboard.
The dates for some of the machines (note 4341 and 3031 were about the same time):
CDC 6600 63-08 64-09 LARGE SCIENTIFIC PROCESSOR
IBM S/360-67 65-08 66-06 10 MOD 65+DAT; 1ST IBM VIRTUAL MEMORY
IBM S/360-91 66-01 67-11 22 VERY LARGE CPU; PIPELINED
AMH=AMDAHL 70-10 AMDAHL CORP. STARTS BUSINESS
IBM S/370 ARCH. 70-06 71-02 08 EXTENDED (REL. MINOR) VERSION OF S/360
IBM S/370-145 70-09 71-08 11 MEDIUM S/370 - BIPOLAR MEMORY - VS READY
IBM S/370-195 71-07 73-05 22 V. LARGE S/370 VERS. OF 360-195, FEW SOLD
Intel, Hoff 71 Invention of microprocessor
Intel DRAM 73 4Kbit DRAM Chip
IBM 168-3 75-03 76-06 15 IMPROVED MOD 168
IBM 3031 77-10 78-03 05 LARGE S/370+EF INSTRUCTIONS
and to repeat the numbers for rain/rain4:
158 3031 4341
Rain 45.64 secs 37.03 secs 36.21 secs
Rain4 43.90 secs 36.61 secs 36.13 secs
also times approx;
145 168-3 91
145 secs. 9.1 secs 6.77 secs
rain/rain4 was from Lawrence Radiation lab ... and ran on cdc6600 in
35.77 secs.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 6600 Console was Re: CDC6600 - just how powerful a machine was
it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Tue, 02 Jul 2002 20:13:38 GMT
"Russell P. Holsclaw" writes:
The earlier support for the 2250 as a console, in OS/360, was actually
cooler than the "device independent" console software later built into
the system to support other display-type devices. One of the neat
features was a "Help" facility that could be selected via light-pen.
It displayed syntax diagrams graphically for the various console
operator commands.
there were a number of 2250 "models" ... a 2250m1 direct channel
attach with its own controller, a 2250m4 .... which came with its own
1130 and some others.
in the late '60s, somebody at the science center ported spacewars from
pdp to the 1130/2250m4 (my kids played it in the mid '70s).
lincoln labs had one or more 2250m1 attached to 360/67 and somebody
there wrote fortran graphics package for CMS to drive the screen.
the university i was at also had 2250m1 .... and I hacked the CMS
editor with the 2250m1 support code from lincoln labs to generate a
full screen editor ... circa fall '68.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jul 2002 20:51:29 GMT
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
Betcha the 158 was microprogrammed by the 360/50 crowd.
("Looks like a duck, walks like a duck...")
So what was the story behind the 3033? A 168 on steroids?
I recall a service bureau using one of those as a primary workhorse.
the story is that a 3031 was 158 with channel director and 3032 was
168 with channel director. The 3033 started out to be the 168 wiring
diagram mapped to chips that were about 20 percent faster than 168
chips ... and with about ten times the circuits/chip. The initial
remapping resulted in the 3033 being about 20 percent than
168/303s. Before any machines shipped, there was then an effort to
redo the logic and utilize higher onchip density that got the 3033 up
to about 50 percent faster than 168/3032.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Wed, 03 Jul 2002 16:13:46 GMT
Charles Shannon Hendrix writes:
Why do I see so many notes about the 4341, but not the 4381. I programmed
a 4381 in 1986-1989 in college.
Was the '81 much faster than the '41? I ask because the '81 I used
felt a lot faster than what I've been told about the CDC 6600, but
then again, maybe it was just I/O speed.
these particular notes (that i happened to have laying around) came
from some work that i was doing for some endicott 4341 performance
engineers. they wanted a benchmark run between 3031 and 4341 (this is
pre-4381 ... aka after the endicott engineers produced the 4341
... they later went on to produce the 4381). The endicott performance
engineers were having trouble getting machine time to do the benchmark
(also at the time, rain/rain4 were one of the few widely run
benchmarks).
Basically the processor hardware engineers got the first machine built
and the disk engineering/product-test labs got the second machine
built, aka in addition to developing new disk drives they validated
existing disks against new processors as they became available. The
processors in the disk engineering lab had been running "stand-alone"
applications (FRIEND, couple others) for the testing .... problem was
that the testcell disks under development tended to sometimes deviate
from normal operational characteristics (MTBF for a standard MVS when
operating a single testcel was on the order of 15 minutes).
As something of a hobby, i rewrote the I/O supervisor to make it
absolute bullet proof, aka no kind of i/o glitches could make the
system crash. As a result it was installed in all the "test"
processors in the disk engineering and product test labs .... and they
were able to do concurrent, simulataneous testing of 6-12 testcells
(instead of scheduling stand-alone time for one testcell at a time) on
each processor (as needed).
I then got the responsibility of doing system support on all those
machines and periodically would get blamed when things didn't work
correctly and so had to get involved in debugging their hardware (as
part of prooving that the software wasn't at fault). One such
situation was the weekend they replaced the 3830 control unit for a
16-drive string of 3350s (production timesharing) with a "new" 3880
control unit and performance went into the can on that machine.
Fortunately this was six months before first customer ship of the 3880
controller so there were times to make some hardware adjustments (I
make this joke at one point of working 1st shift at research, 2nd
shift in the disk labs, and 3rd shift down at STL, and also couple
times a month supporting the operating system for the HONE complex in
palo alto).
In any case, at that particular point that there were two 4341s in
existance, one in edicott and one in san jose disk machines. Since I
supported the operating system for san jose disk ... and since while
the machines might be i/o intensive ... the workload rarely exceeded 5
percent cpu utilization. They had 145, 158, 3031, 3033, 4341,
ect. machines that I could worry about and had some freedom in doing
other types of things with.
So i ran the rain/rain4 benchmarks for the endicott performance
engineers and got 4341 times (aka they couldn't get time on the
machine in endicott because it was booked solidly for other things),
3031 times, and 158 times. They previously had collected numbers for
the 168-3 and 91 times for rain/rain4 ... and of course rain had been
run on 6600 (numbers they sent to me along with the benchmarks to
run).
There may have been other benchmark runs made by other people ... but
I didn't do the runs and didn't have the data sitting around
conveniently. I posted some numbers that I had conveniently available.
misc. disk engineer related posts:
http://www.garlic.com/~lynn/subtopic.html#disk
misc. hone related posts:
http://www.garlic.com/~lynn/subtopic.html#hone
random post about working 4-shift work weeks (24hrs, 7days):
http://www.garlic.com/~lynn/2001h.html#29 checking some myths
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Wed, 03 Jul 2002 16:27:15 GMT
Charles Shannon Hendrix writes:
How did the two stay in sync? I mean, I have vague and fuzzy
recollections of doing assembler on a 4381 and since the programs are
a mix of I/O and calculation, I assume this is very important.
basically instruction processors and I/O processors were architected
to be asynchronous .... effectively in much the same way that machines
with multiple instruction processors (SMP) are typically architected
so that the multiple instruction processors operate asynchronously.
The instructions for th3 360/370 i/o processors were, in fact called
"channel programs". You could write a channel program ... and signal
one of the asycnronous "channel processors" to begin asynchronous
execution of that channel program. The channel program could cause asynchronous
interrupts back to the instruction processor signling various kinds of
progress/events.
On some of the machines, the i/o processors were real, honest to
goodness independent asynchronous processors. On other machines, a
common microcode engine was used to emulate both the instruction
processor and multiple i/o (channel) processors. Machines where a
common processor engine was used to emulate multiple processors (cpus,
channels, etc) where typically described as having "integrated"
channels.
158s, 135, 145, 148, 4341, etc ... were "integrated" channel machines
(aka the native microcode engine had microcode for both emulating 370
processing and microcode for performing the channel process function
and executing "channel programs"). 168 machines had outboard channels
(independent hardware boxes that implement the processing of channel
programs). Channels processors and instruction processors had common
access to the same real storage (in much the same way that multiple
instruction processors have common access to the same real storage).
For the 303x line of machines .... they took a 158 integrated channel
machine .... and eliminated the 370 instruction emulation microcode
... creating a dedicated channel program processing machine called a
"channel director". The "channel director" was then a common component
used for 3031, 3032, and 3033 machines ... aka they were all "outboard
channel" machines (having dedicated hardware processing units for
executing channel programs) ... as opposed to "integrated channel"
machines.
A 3031 was then a 158 with just the 370 instruction emulation
microcode and reconfigured for "outboard channel" operation rather
than "integrated channel" operation. A 3032 was then a 168 that was
reconfigured to use "channel director" for outbarod channels (rather
than the 168 outboard channel hardware boxes).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Wed, 03 Jul 2002 16:56:15 GMT
Anne & Lynn Wheeler writes:
shift in the disk labs, and 3rd shift down at STL, and also couple
times a month supporting the operating system for the HONE complex in
palo alto).
HONE was the system infrastructure that supported the people in the
field, salesmen, marketing people, branch office people, etc.
At one time the US HONE system in Palo Alto had grown into the largest
single-system-image complex in the world. At one time, I knew it had
something over 40,000 defined "userids".
The US HONE system was also cloned for a number of country and/or
regional centers around the world.
Also, in the early '80s, the Palo Alto complex was extended with
redundant centers in Dallas and Boulder for disaster survivability
(my wife and I later coined the terms disaster survivability and
geographic survivability when we were doing HA/CMP) ... online
workload was spread across the three datacenters, but if one failed
the remaining two could pick up.
Nearly all of the application delivery to branch & field people were
written in APL ... running under CMS. One of the most important were
the "configurator" applications. Starting with the 370/125 (& 115), it
was no longer possible for a salesman to manual fill-out a mainframe
machine order .... they all had to be done interacting with HONE
configurator.
random ha/cmp refs:
http://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Wed, 03 Jul 2002 16:57:13 GMT
Anne & Lynn Wheeler writes:
basically instruction processors and I/O processors were architected
to be asynchronous .... effectively in much the same way that machines
with multiple instruction processors (SMP) are typically architected
so that the multiple instruction processors operate asynchronously.
also some smp related postings:
http://www.garlic.com/~lynn/subtopic.html#smp
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: : Re: AS/400 and MVS - clarification please
Newsgroups: bit.listserv.ibm-main
Date: Wed, 03 Jul 2002 16:47:18 GMT
Rick.Fochtman@BOTCC.COM (Rick Fochtman) writes:
OK...am I the only one who "knew" the 2321 data cell famous early "mass storage" we used in developing a large (really) application .... Finest day was when an executive was touring, looking to see if the application (ALIS if anyone was there..
Advanced Life Insurance System) was on target... AND HE TURNED THE DATA CELL OVER... OOPS - there is your master file spread in little strips all over the floor... Now that was an interesting "failure" to recover from!
Janice Winchell
some random old 2321 postings ...
http://www.garlic.com/~lynn/2000.html#9 Computer of the century
http://www.garlic.com/~lynn/2000b.html#41 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?
http://www.garlic.com/~lynn/2001e.html#42 OT: Ever hear of RFC 1149? A geek silliness taken wing
http://www.garlic.com/~lynn/2001e.html#50 "IP Datagrams on Avian Carriers" tested successfully
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2001n.html#61 Google Archive
http://www.garlic.com/~lynn/2002.html#16 index searching
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002f.html#3 Increased Paging in 64-bit
http://www.garlic.com/~lynn/2002g.html#84 Questions on IBM Model 1630
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Wed, 03 Jul 2002 17:10:31 GMT
Charles Shannon Hendrix writes:
Why do I see so many notes about the 4341, but not the 4381. I programmed
a 4381 in 1986-1989 in college.
Was the '81 much faster than the '41? I ask because the '81 I used
felt a lot faster than what I've been told about the CDC 6600, but
then again, maybe it was just I/O speed.
oh yes, i did do a post referencing URL somebody's linpack table ... and
extracted several of the entries for the posting (including a number of
4381 entries ... besides 6600). Note the original table at the referenced
URL includes information about compiler and options used .... i scrubbed
that info ... trying to reduce the size of the posting ... people wanting
to see the full information should go to the reference URL
the 4381 linpack entries from that posting
IBM 4381 90E 1.2
IBM 4381-13 1.2
IBM 4381-22 .97
IBM 4381 MG2 .96
IBM 4381-21 .47
IBM 4381-11 .39
ref linpack posting
http://www.garlic.com/~lynn/2002i.html#12
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: trains was: Al Gore and the Internet
Newsgroups: alt.folklore.computers
Date: Wed, 03 Jul 2002 19:27:03 GMT
eugene@cse.ucsc.edu (Eugene Miya) writes:
Talking with Europeans (I just got back from London yesterday after also
being in Scotland and Iceland on this trip): they have practically no
place to park, their roads are much smaller, they have different land
uses than the US. Take a European to Nevada outside the cities and they
practically never seen open land like that.
when I was in high school, i lived in a county that was the same size
as the state of massachusetts but only had a total population of
50,000.
slightly related:
http://www.garlic.com/~lynn/2002d.html#32 Farm kids
it was quite an adjustment moving to boston. I drove cross country in
the winter .... crossing into mass. i observed that there were county
two-lane mountain roads in the west better built than the mass pike.
there were two claims by various long time mass. residents/natives
.... 1) the frost heaves caused all the problems on the pike (frost
heaves is a problem out west also ... but they build the road bed
appropriately) & 2) road repair was a thriving lobby in the state and
become dependent on doing major road repairs every year (somebody
joked about water soluble asphalt being used for mass. roads).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Wed, 03 Jul 2002 19:32:22 GMT
Charles Shannon Hendrix writes:
Mostly I just notice that I see a lot more references to the 4341 instead
of the 4381, and I mean in general, not just in your posts.
Was the '81 a less popular machine?
I remember the one I used in Richmond, VA, and there was one in city
hall in Newport News, VA. But most of what I saw was 3xxx or old 370
machines, not counting things like the baby-mainframes and the AS/400s.
4341 was possibly one of the best price/performance machines for its
time. slightly related
http://www.garlic.com/~lynn/2001m.html#15 departmentl servers
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers,comp.sys.cdc
Date: Wed, 03 Jul 2002 20:45:38 GMT
Anne & Lynn Wheeler writes:
4341 was possibly one of the best price/performance machines for its
time. slightly related
http://www.garlic.com/~lynn/2001m.html#15 departmentl servers
the talk referenced in the above posting about 11,000+ vax machines
... was given in 1983 (spring?)
note as per:
http://www.garlic.com/~lynn/2002f.html#0
the total world-wide vax ships as of the end of 1982 was 14,508 and the
total as of the end of 1983 was 25,070.
from
http://www.isham-research.com/chrono.html
4341 announced 1/79 and fcs 11/79
4381 announced 9/83 and fcs 1q/84
workstation and PCs were starting to come on strong in the
departmental server market by the time 4381s started shipping in
quantity.
also per:
http://www.garlic.com/~lynn/2002f.html#0
while the total number of vax shipments kept climbing thru '87
... they were micro-vax. combined 11/750 & 11/780 world wide shipments
thru 1984 was 35,540 ... and then dropped to a combined total of 7,600
for 1985 and 1660 for 1986.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: : Re: AS/400 and MVS - clarification please
Newsgroups: bit.listserv.ibm-main
Date: Wed, 03 Jul 2002 20:56:15 GMT
vbandke@BSP-GMBH.COM (Volker Bandke) writes:
Spaghetti : type of noodles
Schleuder: Tumbler, Twister
Noodle snatcher sounds nice to me
Thanks
Now - How do I support that under Hercules <b.s.g>
the "BB" in "BBCCHHR" ccw convention is for addressing the 2321
"bins". i always thot of the 2321 action more like a washing machine
as the bins rotated. The sound of 2321 at boot/ipl was distinctive
... a ker-chunk, whirl, ker-chunk, whirl, ker-chunk, whirl, ... as the
volser for each bin was read (aka read the strip, put it back,
rotate).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM was: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 14:23:01 GMT
eugene@cse.ucsc.edu (Eugene Miya) writes:
I thought IBM had a strict no benchmark release policy.
just a.f.c. now.
i get to invoke the 5 year expiration rule ... or maybe the machine no
longer exists rule. Machine "Function Specification" documents used to
include instruction timings and details like difference between
whether base &/or index register was used, etc.
Maybe what I did was run sample program not benchmarks. Sometimes when
I didn't have direct access to the hardware I would ask people at other
locations to run some sample program .... I got some good/different numbers
from places like BNR.
There was a situation that created some ambivalence. I wanted dynamic
adaptive to not take into account workload and different machine
models but the future. So for the Resource Manager .... I put in some
timing code at boot/ipl and dynamically adjusted various factors that
had been previously pulled out of a static table based on cpuid.
http://www.garlic.com/~lynn/subtopic.html#fairshare
Part of this was that you couldn't assume what possible model numbers
might be invented in the future. Probably the wierdest story was AT&T
longlines getting an early pre-release version and it disappearing
into their corporate structure (actually they got source for a heavily
modifed kernel including some other stuff also). Ten years later
somebody handling the AT&T longlines account came tracking me down.
Turns out that AT&T longlines was still running the same source and it
had propagated out into the corporate infrastructure ... and they just
kept moving the kernel to the latest machine models. Over a period of
10 years some of the things had changed by factors of fifty to
hundred, but that little ol Resource Manager just kept chugging along.
In any case, not only did the change eliminate needing to have model
numbers (and corresponding values) in predefined static table ... and
therefor didn't need to have preknowledge about the future ... there
were also these things called clones that had there own convention for
cpuids (which the little ol resource manager chugged along on also).
clones ... plug compatible manufactur cpus (or PCMs cpus).
Another PCM story ... that they couldn't really hold against me for
because it was done while still an undergraduate ... was building the
first PCM controller ... and getting blamed for helping starting the
PCM controller business.
http://www.garlic.com/~lynn/subtopic.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Mass Storage System"
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 14:28:59 GMT
mikekingston@cix.co.uk (Michael J Kingston) writes:
Film chip 35 by 70 millimetres - capacity approx five times ten to the
sixth data bits
Plastic cells each hold 32 chips
A cell file can rapidly select any of its 2250 cells for delivery to a
chip reader
there recently has been a new running thread on 2321s in bit.listserv.ibm-main
I think this had some discussion in this n.g. within the past year
... as one being at LLNL (which i only heard about ... didn't actually
see).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM was: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 14:32:37 GMT
Anne & Lynn Wheeler writes:
There was a situation that created some ambivalence. I wanted dynamic
adaptive to not take into account workload and different machine
models but the future. So for the Resource Manager .... I put in some
timing code at boot/ipl and dynamically adjusted various factors that
had been previously pulled out of a static table based on cpuid.
http://www.garlic.com/~lynn/subtopic.html#fairshare
oh, and there was a general user command that would yield up at least
one of the values; the operating system just ran the "benchmark" for
you automagically.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: pop density was: trains was: Al Gore and the Internet
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 14:46:35 GMT
eugene@cse.ucsc.edu (Eugene Miya) writes:
Some what.
Still most mtn. roads aren't paved. I know people in the Silicon Valley
who still have 2 miles of dirt road to get to their house.
... i thot was slight connection since I started the trip over (paved)
country mountain roads that were subject to frost heaves (and in much
better condition) ... and ended on the masspike which is part of the
interstate highway system .... and which failed much of the time to
meet interstate highway system standards.
the other slight connection was that mass. residents claimed that the
name of the major paving/road company and the name of a certain
federal sec-DOT was the same (there is also a federal bldg. in
cambridge by that name).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: pop density was: trains was: Al Gore and the Internet
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 14:55:05 GMT
Anne & Lynn Wheeler writes:
... i thot was slight connection since I started the trip over (paved)
country mountain roads that were subject to frost heaves (and in much
better condition) ... and ended on the masspike which is part of the
interstate highway system .... and which failed much of the time to
meet interstate highway system standards.
... driving from out west to mass in the winter ... the road on that
trip that was in the absolutely worst condition (including some
mountain county roads subject to severe frost heaves) was the
(interstate) masspike (and the mass residents claimed that it was a
regular and well expected problem that needed major fixing every year
... and implied that it could have possibly been adverted with better
construction ... i don't remember for sure ... but something about the
depth of the road bed and the materials used; something about the
depth of masspike roadbed thru frost heave area was something like
half that used on some county roads out west in similar situations).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM was: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 15:14:39 GMT
Anne & Lynn Wheeler writes:
i get to invoke the 5 year expiration rule ... or maybe the machine no
longer exists rule. Machine "Function Specification" documents used to
include instruction timings and details like difference between
whether base &/or index register was used, etc.
ok, maybe some 4341s ... or 158s, or 3031s, might possibly still exist
... but I could invoke the no longer be sold by ibm rule.
also when I did this particular benchmark it was still in the '70s
(2nd 4341 built ... before any shipped to customers) ... and the
issues about benchmarking results weren't as strict at that time
(including possibly some functional specifications still having
meaningful data).
the worst "benchmarking" scenario that i'm aware of is the MVS/CMS
backoff done by CERN (on the same hardware). Even tho it was a SHARE
report .... some internal organization had it stamped "Confidential,
Restricted" (only available on need-to-know basis ... as least so far
as employees were concerned).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 18:30:15 GMT
"Rupert Pigott" <dark.try-eating-this.b00ng@btinternet.com> writes:
How about adding 25,000 remote terminals, and maybe 1000 disk
drives out there pumping 250MB/s through the system, doing
something useful with most bytes and all in 64MB?
redoing "routes" for a bit more than 25k terminal/users:
http://www.garlic.com/~lynn/96.html#31 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#153 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#61 64 bit X86 ugliness (Re: Williamette trace cache (Re: First view of Willamette))
http://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
http://www.garlic.com/~lynn/2001k.html#26 microsoft going poof [was: HP Compaq merger, here we go again.]
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 18:40:11 GMT
Steve O'Hara-Smith writes:
The PC that used to take up to 5000 ftp sessions at once and
one day kicked out two and a quarter terabytes of data (30MB/s average)
was rather slow by todays standards.
remember when the netscape browser download had machines 1-19? that
was somewhat alliviated when they got netscape20 machine ... a large
sequent that was configured to handle 20,000 sessions at once and I
believe was the first kernel that had a serious fix for the finwait
problem for webservers.
http wasn't so much of an issue of the number of concurrern sessions,
it was the number of sessions endings per second and the length of the
dangling finwait queue (high activity web servers spending 98 percent
of total cpu running the finwait list). tcp finwait hadn't seen it
before, even with relatively high number of concurrent sessions
because tcp was somewhat presumed to be a connection protocol that
lasted for some time. http1.0 is effectively a connectionless
protocol being driven over a connection protocol (as a result http
would drive the number of tcp session terminations per second thru the
roof, as well as causing a large amount of session setup/tear-down
packet chatter).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jul 2002 18:51:39 GMT
"Douglas H. Quebbeman" writes:
Actually, a CDC 6600 with 60 terminals hanging off it was
terribly bogged down, giving crappy response time to all
60 users. I can't imagine trying to hang more _character mode_
terminals off such a system.
But the comparisons often made to IBM mainframes with 1000s
of terminals isn't fair; unless I'm mistaken, those 1000s
of terminals were usually block-mode terminals, or ones
which were at least operating in block mode. Not having
to process an interrupt for every daggone character allows
you to hang a lot more of them onto the muxes, and more
muxes on the channels.
CDC also provided for block-mode terminals and transaction-
oriented subsystems, but I personally never saw those in use.
in the early '90s the configuration referenced in the previous post
about routes was actually a cluster of SMP mainframes .... but still
having avg. peak loading of 3500 transactions per second .... 1500 or
so weren't real transactions ... they were device interrupts from the
ticket & boarding pass printers around the world; human operated
terminals was only seeing about 2000 "transactions" a second ... about
1/4th of the 2000 or around 500/second were requests to find a route
between two airports (i.e. flight segments).
now, back with cp/67 on a 360/67 single processor (say maybe
compareable to a large AT w/80287 co-processor) we supported 75-80
"active" 2741 terminal "mixed-mode" users with subsecond trivial
response (of course this had line interrupts not character
interrupts) ... mixed-mode ... apl, program development, document
preperation, source editing, compilation, program debug & test, etc.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM was: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Fri, 05 Jul 2002 09:37:25 GMT
Anne & Lynn Wheeler writes:
(including possibly some functional specifications still having
meaningful data).
oops ... finger/brain check
that was funcational characteristics manuals ... for instance for 360/67
A27-2719 IBM System/360 Model 67: Functional Characteristics
gave detailed instruction timings
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Fri, 05 Jul 2002 10:00:30 GMT
Anne & Lynn Wheeler writes:
now, back with cp/67 on a 360/67 single processor (say maybe
compareable to a large AT w/80287 co-processor) we supported 75-80
"active" 2741 terminal "mixed-mode" users with subsecond trivial
response (of course this had line interrupts not character
interrupts) ... mixed-mode ... apl, program development, document
preperation, source editing, compilation, program debug & test, etc.
there was a lot of work to get cp/67 up to that level of performance.
when I first got a copy of cp/67 at the university in jan. '68 ... it
was doing good supporting 30 mixed-mode users and/or concurrent
mixed-mode and a guest operating system like MFT.
over the next six months I significantly reduced general pathlengths
and introduced "fastpaths" (fastpath is methodology for optimized
pathlength for the most common case(s) .... in contrast to just
straight-forward optimized pathlength for all cases). ref to
report I gave at august '68 SHARE meeting as to the result of some
of the pathlength work for guest operating systems:
http://www.garlic.com/~lynn/94.html#18 CP/67 and OS MFT14
Of the next 18 months at the university I also rewrote
dispatch/schedule and implemted fair share scheduling, rewrote paging
subsystem and implemented clock replacement algorithm, rewrote "DASD"
support .... implementing ordered-seek queueing for 2311 and 2314
disks and chained scheduling for 2301 drums.
The orders seek queueing reduced latency and increase thruput of both
2311 and 2314 disk drives for both paging and user i/o. The 2301 was a
fixed head device that doing one i/o operations at a time was subject
to average rotational latency delay for every i/o operation. In this
mode, the 2301 had peak sustained paging rate of about 80 page i/os
per second. With chained-scheduling, multiple requests were ordered in
a single i/o ... so rotational latency typically applied to just the
first operation .... given a dedicated channel the 2301 would then see
peek sustained thruput of 300 page i/os per second.
The other feature affecting performance that I did as an undergraduate
was to implement support for being able to page selected portions of
the kernel ... reducing the total fixed storage requirements
... freeing up more space user execution. Machine at the university
was 768k memory ... 192 4k pages ... but that would be reduced to as
little as 104 "available" 4k pages under heavy load. Some simple
kernel paging could easily pick up 10 percent real storage for
application execution.
Eventually all of the above changes (except for kernel paging) was
picked up and distributed as part of the standard release (they also
distributed various other stuff that I had done like the TTY/ascii
terminal support).
Much of the above was carried over in the CP/67 to VM/370 port
... except for the paging and dispatch/scheduling algorithm changes.
I was able to re-introduce those in the resource manager product:
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
which went out initially as PRPQ (special offering) but was shortly
changed into standard product status.
misc. general refs:
http://www.garlic.com/~lynn/subtopic.html#technology
including
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Fri, 05 Jul 2002 10:32:39 GMT
Charles Shannon Hendrix writes:
The WWW is what basically amounts to a graphical, markup-based virtual
3270.
one could claim that html .... was cambridge's GML by way of all the ibm
systems at CERN (aka GML was done by "G", "M", & "L" at cambridge, before
becoming SGML ... and then morphing into stuff like HTML, XML, etc).
3270s did have some number of drawbacks. The 3274 controller (for
3278, 3279, etc terminals ) was slower than the original 3272
controller for 3277 terminals, in part because a lot of "head"
electronics was moved out of the terminal and back into the 3274
controller (making the cost of each 3278/3279 terminal cheaper).
With some local electronic tinkering it was possible to adjust the key
repeat delay and key repeat speed to just about any value you wanted
(on the 3277) ... improving the ability to navigate the cursor around
the screen. You could also get a keystroke FIFO box for the 3277. The
3270 had a characteristic if you used to fast typing ... that if you
happen to hit a key at just the same instant that something was being
transferred to the screen ... the keyboard would lock and you would
have to het the reset buttom. For fast typists ... that just about
threw you into half-duplex mode of operation to avoid having to deal
with the interruption of the keyboard lockup and having to hit reset.
All of that was lost in upgrade to 3274/3278/3279 (since all the
required electronics were now back in the controller and not in the
terminal). It never really came back until you got ibm/pc with
3278/3279 terminal emulation.
The other impact was that while local 3274s (direct channel attach)
exhibited significantly better human factor response than remote 3274s
controller (i.e. connected over some sort of 9.6kbit telco line
... with multiple attached terminals all sharing the controller rate)
... the 3274 command processing time on the channel was excessive.
A fully configured system tended to have a lot of disk controllers and
a lot of 3274 controllers all spread out on the available channels
(with some disk controllers and some 3274 controllers attached to each
channel). It turned out that 3274 slowness was causing high channel
busy time and typically interferring with disk thruput. This wasn't
immediately recognized .... however I was doing a project implementing
kernel aupport for HYPERChannel Remote Device Adapter (basically
channel extender over T1 telco line) for large numbers of local 3274
controllers. You would remove the 3274 controllers from all the
channels and put them in a remote building. You would then attach a
HYPERChannel A22x to the channel and setup a HYPERChannel network to
some number of A51x boxes at the remote site. The A51x boxes emulated
mainframe channels and you could attach "local" controllers (like
3274) to the A51x boxes and they would think they were talking to real
channel.
The result was you could put a couple hundred people and their
terminals at a remote site and they typically couldn't tell the
difference between being local or remote. This is in contrast to
"remote" 3274s where the response and human factor degradation was
significant.
A side effect of this project was that it appeared that total disk
thruput (and therefor total system thruput) went up by about 10-15
percent. Further analysis showed that the HYPERChannel A22x boxes that
were directly attached to mainframe channel had significantly lower
channel "overhead" for doing the same exact operation compared to
configuration with all the local 3274s controllers attached to the
real channels. This discovery resulted in some number of presentations
and configuration advisories as to not mixing 3274 controllers and the
same channels with anything else of significant thruput importance
(like disk controllers).
slightly related discussion with respect to some disk thruput & controller
issues
http://www.garlic.com/~lynn/2002i.html#18 AS/400 and MVS - clarification please
some past HYPERChannel postings
http://www.garlic.com/~lynn/subtopic.html#hsdt
Slightly related HYPERChannel issue ... mentioned in some of the above
postings. I had also did the standard mainframe product support for
RFC1044 (aka hyperchannel) and did some tuning at Cray Research ...
where we got sustained thruput between a cray machine and 4341-clone
that was nearly equal to 1.5mbyte/sec hardware channel speed ... with
only relatively modust cpu utilization. By comparision the "standard"
base support (non-rfc1044) had trouble getting 44kbyte/sec while
nearly saturating a 3090 cpu.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Unisys A11 worth keeping?
Newsgroups: alt.folklore.computers,comp.sys.unisys
Date: Fri, 05 Jul 2002 11:27:24 GMT
jmfbahciv writes:
I think that's why a lot of people liked TOPS-10. No matter
who or what you were, you were guaranteed to have some knowledge
that others didn't have about the system. Even the most lowly
drudge could be important and help somebody floundering on
the terminal next door.
one of the things with vm ... besides being a time-sharing service
... was that tymshare started hosting vm releated newsgroup for the
share community in the mid-70s (hosted on their vm-based time-sharing
service). the archive:
http://vm.marist.edu/~vmshare/
started in the '80s a lot of the activity started move to various
mailing lists .... first on bitnet/earn and then on the internet
(bitnet was the vm-based corporate funded educational network in the
US and earn was similar corporate funded educational network in
europe).
random bitnet/earn refs:
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
http://www.garlic.com/~lynn/99.html#38c Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#39 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#126 Dispute about Internet's origins
http://www.garlic.com/~lynn/2000b.html#67 oddly portable machines
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#72 When the Internet went private
http://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000f.html#22 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#51 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2000g.html#39 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#19 What is "IBM-MAIN"
http://www.garlic.com/~lynn/2001e.html#12 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001e.html#25 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001h.html#65 UUCP email
http://www.garlic.com/~lynn/2002b.html#54 Computer Naming Conventions
http://www.garlic.com/~lynn/2002b.html#56 Computer Naming Conventions
http://www.garlic.com/~lynn/2002b.html#57 Computer Naming Conventions
http://www.garlic.com/~lynn/2002d.html#33 LISTSERV(r) on mainframes
http://www.garlic.com/~lynn/2002e.html#6 LISTSERV(r) on mainframes
http://www.garlic.com/~lynn/2002h.html#11 Why did OSI fail compared with TCP-IP?
from above vmshare ref:
Welcome to the VMSHARE Archives
About VMSHARE
VMSHARE has been the conferencing system of the VM Cluster of SHARE
since August 1976. After VMSHARE was closed down in August 1998 it was
decided that the database should be kept available for reference. Read
here the announcement of that by Ross Patterson. The best way to get
a feeling for what VMSHARE meant to its users is probably by browsing
through the VMSHARE Archives where you will find appends like this.
It may also be helpful to read Melinda Varian's History of VM to get a
better understanding of the community that has developed around VM and
VMSHARE.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Fri, 05 Jul 2002 11:49:51 GMT
Brian Inglis writes:
What kind of config was that? AT a PPOE we managed to get 30KB/s
sustained TCP/IP throughput over twin 128kbps SNA links
(Canada-UK) using TCP over SNA tunnelling with no significant
loading, although IIRC both the TCP and SNA setups were patched
up to date and tweaked according to SE instructions.
see RFC1044 ... if nothing else find pointer to the RFC from my rfc index at:
http://www.garlic.com/~lynn/rfcietff.htm
Basically a channel attached hyperchannel A22x box on ibm mainframe
connected to a hyperchannel network. i wrote all the code ... device
driver and various optimized paths for the box in the base product.
The original mainframe TCP/IP product ... in the'80s initially only
supported the 8232 ... basically a pc/at with channel attach card and
some number of LAN cards. The 8232 wasn't really a tcp/ip box .... but
a channel to LAN gateway ... so all the TCP/IP to LAN/MAC level stuff
had to be done in the mainframe (which accounted for a lot of the cpu
overhead processing). The channel attached HYPERChannel box was a real
TCP/IP router ... which allowed a lot of the processing for the 8232
to be bypassed.
This was also the basis for what we used for the mainframe part of our
internal corporate highspeed backbone. This internal corporate
highspeed backbone is what the NSF audit claimed was five years ahead
of all bid submissions for the NSFNET1 backbone. For the internal
backbone I had done some additional stuff that didn't appear in the
product (like rate-based pacing ... which the audit cliamed was
included in the five years ahead .... and 15 years later it still
looks to be five years ahead ... internet2 is looking at it tho).
random refs:
http://www.garlic.com/~lynn/internet.htm
misc. 8232 refs:
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
misc. stuff about hsdt ... high speed data transport:
http://www.garlic.com/~lynn/subtopic.html#hsdt
in the following ref:
http://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
somebody in the SNA group had posted an announcement for a new
newsgroup. The contrast was significant.
tale slightly out of school:
http://www.garlic.com/~lynn/2000c.html#58
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AS/400 and MVS - clarification please
Newsgroups: bit.listserv.ibm-main
Date: Fri, 05 Jul 2002 10:54:09 GMT
Anne & Lynn Wheeler writes:
the result was reformulated into recommended system configuration
presentation and initially given at Share 63, presentation B874
(8/18/84). Summary from the paper:
slightly related to recommendations configuring disk controllers on
channels (with respect to 327x controllers):
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AS/400 and MVS - clarification please
Newsgroups: bit.listserv.ibm-main
Date: Fri, 05 Jul 2002 10:57:24 GMT
Anne & Lynn Wheeler writes:
basically 2303 and 2301 were the same physical device. 2303 was used
with standard disk controller. 2301 was essentially a 2303 that
read/wrote four heads in parallel (and had four times the data
transfer rate of the 2303) and had a high-speed controller.
2301 held about 4mbytes of data. TSS & CP/67 formated 2301 with 9 4k
pages on a pair of 2301 "tracks" (eight physical "2303" tracks).
slightly related to programming i/o support for 2301:
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Fri, 05 Jul 2002 12:14:36 GMT
cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Oh yes. I remember using a 3274 (well, that and a herd of UNIX minis
which emulated them and connected via an X.25 card hacked to talk SNA-
style SDLC) which was connected to the remote mainframe via a piece
of wet string which wobbled at 9600bps. This was over a 3-year
period and it was painful, especially after a visit to the site where
the mainframes lived and I got to see what the response should really
be like (much < 1 second as opposed to several seconds)
there were a couple level of "arguments". there were a lot of the TSO
crowd claiming that sub-second response wasn't required. Some number
of detailed human factor detailed studies then were done that showed
that sub-second response was significant. Those studies significantly
aided the case for having local 327x controllers at remote location
using hyperchannel as a channel extender (as opposed to using
sna-based remote 327x controllers).
Then there was a east research center that was really proud of the
fact that the had .22 second response under heavy load and provided
one of the best time-sharing services in the world. We then pointed
out that we had a .11 second response with effectively the same load
and the same hardware. There was then some discussion whether less
than .20 second response really had any meaning (i.e. could humans
tell the difference between .11 second response and .20 second
response).
the sna group were less than thrilled about various of these
activities (also see the recent posting mentioning tcp/ip and
vtam/sna). they were really not thrilled that i was part of the four
person group that created the first non-ibm controller and started the
pcm controller business. another slightly related sna/hyperchannel
comparison:
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/2000.html#53 APPC vs TCP/IP
http://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
http://www.garlic.com/~lynn/2001i.html#21 3745 and SNI
http://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
http://www.garlic.com/~lynn/2001k.html#21 OT: almost lost LBJ tapes; Dictabelt
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Fri, 05 Jul 2002 16:05:30 GMT
cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
I'm sure I heard somewhere (may have even been from yourself?) that
it's difficult to notice the difference in response times below 100ms,
but any increments above that are quite obvious.
shortly after getting hired .... i got to go to an internal technical
conference held in DC at old marriott. mills gave a talk on
superprogrammer. somebody from ykt gave a talk on event time
perception threshold, across a wide range of people it seemd to vary
between 100ms and 200ms.
prior ref:
http://www.garlic.com/~lynn/2001h.html#48 Whom Do Programmers Admire Now???
a later study in the early '80s found that predictability was also
important .... if people could perceive the delay, they could get into
a pattern anticipating it ... if the delay was longer than
anticipated, it interrupted the (human) pattern and it then took the
person twice as long to "recover". If the delay was about two seconds,
and it went to four seconds .... a human took an additional two
seconds (six seconds total) to recover. The theory was that the
person's attention started to wonder when their expectation failed and
the attention "recovery" time was equal to the amount of time spent
"wondering". A supporting example was if the delay extended into the
minutes, you might even leave your desk to do something else.
other random refs:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
http://www.garlic.com/~lynn/2000b.html#24 How many Megaflops and when?
http://www.garlic.com/~lynn/2000b.html#25 How many Megaflops and when?
http://www.garlic.com/~lynn/2000c.html#64 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#40 360 CPU meters (was Re: Early IBM-PC sales proj..
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC6600 - just how powerful a machine was it?
Newsgroups: alt.folklore.computers
Date: Fri, 05 Jul 2002 16:22:15 GMT
cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Interesting that even on our somewhat rickety setup, TSO (and TSO alone)
still managed sub-second responses where a significant screen update
wasn't involved. A