List of Archived Posts
2004 Newsgroup Postings (2/28 - 3/20)
- A POX on you, Dennis Ritchie!!!
- Oldest running code
- Oldest running code
- Oldest running code
- OS Partitioning and security
- PSW Sampling
- If the x86 ISA could be redone
- IBM operating systems
- IBM operating systems and APL
- TSS/370 binary distribution now available
- XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
- 40yrs, science center, feb. 1964
- The BASIC Variations
- Yakaota
- A POX on you, Dennis Ritchie!!!
- If there had been no MS-DOS
- Anyone Still Using Cards?
- If there had been no MS-DOS
- IT jobs move to India
- IT jobs move to India
- Parallel programming again (Re: Intel announces "CT" aka
- PSW Sampling
- More complex operations now a better choice?
- Jargon Files Wanted
- More complex operations now a better choice?
- More complex operations now a better choice?
- Moribund TSO/E
- Moribund TSO/E
- Moribund TSO/E
- separate MMU chips
- Moribund TSO/E
- Moribund TSO/E
- Moribund TSO/E
- separate MMU chips
- Playing games in mainframe
- Computer-oriented license plates
- If there had been no MS-DOS
- Memory Affinity
- ATA drives and vibration problems in multi-drive racks
- Memory Affinity
- Microprocessor History Site
- If there had been no MS-DOS
- Moribund TSO/E
- why and how VeriSign, thawte became a trusted CA?
- If there had been no MS-DOS
- Detecting when FIN has arrived
- IBM 360 memory
- IBM 360 memory
- IBM 360 Memory
- [OT] Lockheed puts F-16 manuals online
- [OT] Lockheed puts F-16 manuals online
- [OT] Lockheed puts F-16 manuals online
- Detecting when FIN has arrived
- defination of terms: "Application Server" vs. "Transaction Server"
- [OT] Lockheed puts F-16 manuals online
- Idea for concurrent transactions
- Bushwah and shrubbery
- [OT] Lockheed puts F-16 manuals online
- real multi-tasking, multi-programming
- real multi-tasking, multi-programming
- IBM 360 memory
- IBM 360 memory
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A POX on you, Dennis Ritchie!!!
Newsgroups: alt.folklore.computers
Date: Sat, 28 Feb 2004 16:31:18 GMT
Roland Hutchinson writes:
It is very easy to answer why.
The MLA handbook does not seek to provide guidance for formatting
texts in a way that will help the reader to read efficiently.
It provides guidance for formating manuscripts in a way that will
help the editor, the copyeditor, and the publisher do their jobs
efficiently. The text that leaves the author's hands therefore, for
a variety of reasons, is NOT formatted the way it will be when the
reader ultimately sees it.
after we decided on doing the internal online telephone book as a
killer app to get executives interested in using keyboards ... during
deployment we got into big discussion about whether it should be
name/number or number/name in the display.
the scenario was that if there was a single exact match .. then
leading number would be the faster thing for the person to find
.. however, if there wasn't a single exact match and there was a list
of names, then it would be easier for the human to scan leading names
(especially when there was some variability in number lengths).
couple minor previous posts:
http://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oldest running code
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 28 Feb 2004 16:52:43 GMT
Brian Inglis writes:
GML is a markup language, not a programming language. But the APFs
(Application Processing Functions associated to GML tags) were
written in SCRIPT (/DCF?) control language, which provides a macro
programming language with conditionals and either jumps or loops, I
can't remember, and can't find the ref card right now. Changed GML
to handle IBM 6670 and various models of Xerox laser printers almost
identically to IBM 3800 printers, and support every font provided
(max 4 per page IIRC), once upon a time.
i knew some number of people who were considered GML programmers
... especially in various parts of the business that specialized in
writing responses to RFPs and other stuff. script had macro,
conditionals, testing, branching, logic, etc (aka programming)
the original application was SCRIPT ... from mid-60s on CMS .. done
at the cambridge science center. it supported runoff like "dot"
commands. Later (still at cambridge science center) "G", "M", and "L"
invented gml and GML syntax support was also added to SCRIPT.
the analogy might be the difference between between a machine
program and an assembler programmer where machine & assembler are
sometimes used interchangeably.
an early, widely available publication that utilized the conditional
support was the 360 (later 370) principle of operations and the
architecture "red book". The architecture "red book" was an internal
only document distributed in a ox-blood colored 3ring binder. It was a
superset of the 360 principle of operations (describing the machine
operation, instructions, etc) which included all the unannounced
instructions, a lot of engineering/hardware consideration notes on
instructions & machine features, and various justifications for
incorporating/adding the instruction to the original architecture.
When the 360 principle of operations was printed ... it was done w/o
all the architecture, engineering, and business notes.
misc. past science center posts
http://www.garlic.com/~lynn/subtopic.html#545tech
recent posting referencing redbook:
http://www.garlic.com/~lynn/2004b.html#57 PLO instruction
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oldest running code
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 28 Feb 2004 16:56:38 GMT
Brian Inglis writes:
Nice hack, wish it had been documented in the EXEC/EXEC2 manuals!
Now if only the diagnose calls were as easy to substitute.
Although life required a lot less assembler when REXX was released
with the DIAG?NOSE?() function, ISTR REXX did not support all the
possible VM DIAG instruction operands, and some assembly was still
required.
yes, very early on, i decided to do a demo of the power of REX (before
it changed it name to REXX) and that it wasn't just another pretty
command batching language. I selected the CP/CMS dump processing
facility ... which was a large assembler written application supported
by a modest sized organization in endicott.
the objective was to spend 3 months half-time re-implementing the
application in REX which would have ten times the function and ran ten
times faster. I did have to do about 120 instructions of assembler to
achieve the goal. misc. past refs to the effort:
http://www.garlic.com/~lynn/subtopic.html#dumprx
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oldest running code
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 28 Feb 2004 19:11:58 GMT
Brian Inglis writes:
WAIT RDR1RDR1 <8bytes hex zeros>
^^^^^^^^
fence word with x'FF' I presume?
nope ... standard fencing was eight bytes of x'00'
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS Partitioning and security
Newsgroups: comp.security.misc
Date: Sat, 28 Feb 2004 19:10:04 GMT
"Tsvi Gad" writes:
I am looking for information about the following issue: A client I
work for is going to use a single hardware for the Development and
Production servers by using the machine ability of OS
Partitioning. It means that every OS has its own hardware exept the
bus that is common. The problem is that for security reasons there
is a need to separate the two servers and it also has different sets
of data. I am sure every vendor will confirm that kind of
architecture as safe but my guts says otherwise.
Does anyone have some article or expirience that will support my opinion?
note one of the original partitionings used extensively for various
security operations was virtual machines .... dating back to cp/67
http://www.garlic.com/~lynn/2003d.html#72 CP/67 35th anniversary
which morphed into VM/370. various microcode performance assists
for virtual machine support
http://www.garlic.com/~lynn/subtopic.html#mcode
became quite sophisticated ... leading to PR/SM and then to LPARS
... or logical partitions ... where a significant subset of the VM/370
support is implemented directly in the hardware of the machine ... and
it is possible to partition the real hardware into multiple "logical
partitions" each running their own operating system.
much more recently there have been the intel architecture virtual
machine software implementations used for providing partitioning (as
well as security) ... and a number of vendors are now talking about
offering hardware-supported partitioning ... similar to the mainframe
LPAR concept.
the other higher level concept for partitioning for security are the
capability-based operating system implementations ... like gnosis,
keykos, and eros (see refs following the pr/sm and lpar refs).
lots of past PR/SM and/or LPAR refs:
http://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000.html#8 Computer of the century
http://www.garlic.com/~lynn/2000.html#63 Mainframe operating systems
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2001b.html#72 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001e.html#61 Estimate JCL overhead
http://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
http://www.garlic.com/~lynn/2001n.html#17 CM-5 Thinking Machines, Supercomputers
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002e.html#25 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002n.html#6 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#0 Home mainframes
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#4 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2002p.html#46 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2002p.html#55 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2003c.html#41 How much overhead is "running another MVS LPAR" ?
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003l.html#12 Why are there few viruses for UNIX/Linux systems?
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#37 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#13 CPUs with microcode ?
http://www.garlic.com/~lynn/2003n.html#29 Architect Mainframe system - books/guidenance
http://www.garlic.com/~lynn/2003o.html#52 Virtual Machine Concept
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
misc: gnosis, keykos, and/or eros discussions:
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PSW Sampling
Newsgroups: bit.listserv.ibm-main
Date: Sat, 28 Feb 2004 23:45:13 GMT
jfregus@ibm-main.ix.netcom.com (John F. Regus) writes:
There is only one PSA per processor. You cannot look at the PSA for one
machine while inside of another.
on 360/67 SMP ... each processor had a different PSA 4k that came out of
real storage someplace; all 4k PSAs could be addressed by all
processors by their "real" address (just a matter of knowing what 4k
real address each processor had their PSA set to); however, real page
zero was "lost".
for 370 SMP ... this was modified so that each processor could address
real page zero ... by the real address of that processor's PSA ...
aka each processor loaded a 4k real page address into their PSA
register ... all references to page zero were converted to the page
address in the PSA register and all addresses for the real page
address in the PSA address was converted to real page zero. That way
all processors could address the real page zero ... by using the value
loaded into their PSA register. operating systems then could use their
PSA for processor specific information ... and still be able to use
real page zero for complex-wide information. discussion of z/390
prefixing (now 8k bytes):
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/3.7?SHELF=DZ9ZBK01&DT=20020416112421
long ago and far away ... boeing wichita used a video camera focused
on the 370/168 display lights to do PSW sampling.
reference to 370/145 microcode change to do psw sampling:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
sort of part of the evoluation in vm microcode assists that led up to PR/SM
and eventually LPARs.
misc. other mcode refs:
http://www.garlic.com/~lynn/subtopic.html#mcode
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If the x86 ISA could be redone...
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 29 Feb 2004 03:30:42 GMT
"Stephen Fuld" writes:
I can't comment more on the PDP 11 due to lack of knowledge, but you
are conflating several things with regard to S370. First, the
vitrual address stuff. The early S370s, specifically the 155 and
165 did not have virtual memory, as they were essentially just
faster S360s. Even when the virtual address systems came out (the
models ending in 8), they still didn't support any more than 16 MB
of memory. The ability to use more than 24 bits for a memory
address came only with Extended Addressing mode (called XA), which
came later. I expect the Wheelers can provide specific dates for
all of these.
360/67 was basically a 360/65 with DAT (dynamic address translation)
box providing virtual memory. the 360/67 supported both 24bit and
32bit virtual addressing (circa late 1966). there was official product
for the 360/67 called TSS/360 which never was very succesful. however,
a virtual machine operating system utilizing virtual memory was developed
by the cambridge science center, initially on a custom modified 360/40
and later ported to standard 360/67. note on cp/67 35th anniv:
http://www.garlic.com/~lynn/2003d.html#72
which later morphed into vm/370 for 370. misc. other posts about
cambridge science center:
http://www.garlic.com/~lynn/subtopic.html#545tech
which also was where GML (precursor to SGML, HTML, XML, etc) originated
as well as the internal network
http://www.garlic.com/~lynn/internet.htm
the early 370s were shipped w/o dyanamic address translation enabled
... in the 155 and 165 case ... the hardware wasn't even
there. however, there was something of strong speculation since the
rollers on the front of the 370/145 had a lamp in the psw bit
definitions with the designation "XLATE" ... that lots of customers
speculated as meaning translation. later with the announcement of
virtual memory, a new floppy disk was distributed which contained the
microcode to enable virtual memory on the 145. the 155 & 165 required
field upgrades. however there were issues with the 165 field
upgrade. the original 370 virtual memory architecture ("redbook")
included selective invaliation instructions (invalidate page table
entry, invalidate segment table entry, invalidate address space) in
addition to the purge lookaside buffer (PTLB). however, the 165
engineers claimed that implementing the selective invalidation
instructions would delay the virtual memory hardware availability for
the 165 by six months ... so the instructions were dropped from 370
virtual memory product (although selective invalidate page table entry
was latter introduced with the 3033).
the 3033 also had a hack for addressing more than 16mbytes of real
memory. The 370 16bit pagetable entry had two unused bits ... 12 bits
for (4k byte) page number, page table invalid bit and page reference
bit. The 3033 hack was to use the two unused bits and add them to the
page number field ... extended the number of 4k pages that could be
specified to 14bits or possibly up to 64mbytes of real storage. While
instructions couldn't address more than 24bits, they could be
translated to a real page address that could resolve to 26bit address.
This, in part worked since 370 architecture had originally extended
i/o addressing with IDAL (indirect data list) that allowed 31-bit
address specification.
another issue was that the mainstream mainframe commercial batch
system had the kernel and all services occupying the same address
space as applications with API that evolved using pointer passing
(which then was predicated on associated parameters in the same
address space). The initial transition to 370 virtual memory for this
batch system was single virtual (paged) 16mbyte address space as if it
was running on 16mbyte real machine ... with 8mbytes reserved for
kernel functions and 8mbytes for all applications. This then evolved
into MVS with multiple virtual address spaces ... with each
application having its own 16mbyte address space ... although with
shared kernel occupying 8mbytes of each application address
space. After the mid 70s, there got to be a problem with expanding
system services taking more than 8mbytes (of the 16mbyte) virtual
address apace ... in some cases leaving only 4mbytes in each address
space for actual application use.
to address this issue a dual address space feature was introduced with
the 3033 (in addition to greater than 16mbyte real addressing). this
allowed semi-priviledged system service applications to reside in
their own address space and be called by normal user applications
using pointer-passing API paradigm ... where the sermi-priviledged
system services had expanded instructions that could access
alternative (typically user domain) virtual address spaces. This
somewhat alleviated the problem of fitting all system services in the
same 16mbyte virtual address space with a running application.
xa with 31bit addressing (not 32bit as in the earlier 360/67) was
referred to originally as 811 (date of architecture specification,
nov, 1978) ... and was introduced with 3081 processors.
xa introduced the concept of access registers that sort of expanded
the concept of cross-memory services. in addition to the fact that
there was a pointer passing paradigm ... some number of system
services were packaged as system libraries and invoked by standard
subroutine program call. For various integrity reasons there was a
desire to move most of these library system functions into
semi-priviledged and different address space from the running
application ... but still be able to do subroutine linkages w/o the
overhead of kernel calls, priviledge checking and address space
changes. so there are now a number of access tables for services that
are predefined ... some number of alternatively defined address spaces
and a lightweight PC/program-call instruction that can call
subroutines in alternative address spaces under controlled rules.
These still use the pointer passing API paradigm ... and these
subroutines use cross-memory instructions to access parameters and
data in the application address space. while the original cross memory
services were originally targeted at moderating some of the difficulty
of all system services occupying the same 16mbyte address space as the
application ... the access register architecture continues the cross
memory paradigm into the 31-bit (and now 64bit) architecture ... more
as an integrity feature ... rather than as memory size relief.
some past posts on access registers (in some cases include URL pointers
to official architecture/hardware descriptions);
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002n.html#74 Everything you wanted to know about z900 from IBM
totally random recent posting on paging (from mainframe n.g.)
http://www.garlic.com/~lynn/2004b.html#60 paging
more dates than you possibly ever wanted to know:
Product
or Event Ann. FCS Description
CDC6600 63-08 64-09 LARGE SCIENTIFIC PROCESSOR
IBMS/360-67 65-08 66-06 10 MOD 65+DAT; 1ST IBM VIRTUAL MEMORY
IBMPL/I.LANG. 66-?? 6???? MAJOR NEW LANGUAGE (IBM)
IBMS/360-91 66-01 67-11 22 VERY LARGE CPU; PIPELINED
IBMPRICE 67-?? 67??? PRICE INCREASE???
IBMOS/360 67-?? 67-12 MVT - ADVANCED MULTIPROGRAMMED OS
IBMTSS 67??? ??-?? 32-BIT VS SCP-MOD 67; COMMERCIAL FAILURE
1Kbit/chip.RAM 68 First commercial semicon memory chip
IBMCP/67 68+?? 68+?? MULTIPLE VIRTUAL MACHINES SCP-MOD 67
IBMSW.UNBUNDLE 69-06 70-01 07 IBM SOFTWARE, SE SERVICES SEP. PRICED
IBMS/360-195 69-08 71-03 20 VERY LARGE CPU; FEW SOLD; SCIENTIFIC
IBMS/370ARCH. 70-06 71-02 08 EXTENDED (REL. MINOR) VERSION OF S/360
IBM3330-1 70-06 71-08 14 DISK: 200MB/BOX, $392/MB
IBMS/370-155 70-06 71-01 08 LARGE S/370
IBMS/370-165 70-06 71-04 10 VERY LARGE S/370
IBMS/370-145 70-09 71-08 11 MEDIUM S/370 - BIPOLAR MEMORY - VS READY
AMHAMDAHL 70-10 AMDAHL CORP. STARTS BUSINESS
Intel,Hoff 71 Invention of microprocessor
IBMS/370-135 71-03 72-05 14 INTERMED. S/370 CPU
IBMS/360-22 71-04 71-07 03 SMALL S/360 CPU
IBMLEASE 71-05 71 06 01 FixTERM PLAN;AVE. -16% FOR 1,2 YR LEASE
IBMPRICE 71-07 71+?? +8% ON SOME CPUS;1.5% WTD AVE. ALL CPU
IBMS/370-195 71-07 73-05 22 V. LARGE S/370 VERS. OF 360-195, FEW SOLD
IBMVM.ASSIST 72+?? 7?-?? MICROCODE ASSIST FOR VM/370
IBMMVS-JES3 72+?? 75-10 LOOSE-COUPLED MP (ASP-LIKE)
IBMMVS-JES2 72-?? 72-08 JOB-ENTRY SUBSYSTEM 2 (HASP-LIKE)
IBMVSAM 72+?? 7?-?? NEW RANDOM ACCESS METHOD
IBM3705 72-03 72-06 COMMS CNTLR: 352 LINES; 56KB/SEC
IBMS/370.VS 72-08 73-08 12 VIRTUAL STORAGE ARCHITECTURE FOR S/370
IBM135-3 72-08 73-08 12 INTERMED. S/370 CPU
IBM145-3 72-08 73-08 12 INTERMED. S/370 CPU
IBM158 72-08 73-04 08 LARGE S/370, VIRTUAL MEMORY
IBM168 72-08 73-08 12 VERY LARGE S/370 CPU, VIRTUAL MEMORY
IBMOS/VS1 72-08 73-?? VIRTUAL STORAGE VERSION OF OS/MFT
IBMOS/VS2(SVS) 72-08 72+?? VIRTUAL STORAGE VERSION OF OS/MVT
IBMOS/VS2(MVS) 72-08 74-08 MULTIPLE VIRTUAL ADDRESS SPACES
IBMVM/370 72-08 72+?? MULTIPLE VIRTUAL MACHINES (LIKE CP/67)
IBM125 72-10 73-04 06 SMALL S/370 CPU
AMHV/6 75-04?75-06 02 FIRST AMDAHL MACHINE, FIRST PCM CPU
AMHV6-2 76-10 77-09 11 (1.05-1.15)V6 WITH 32K BUFFER
AMHV7 77-03 78-09 18 AMDAHL RESP. TO 3033 (1.5-1.7) V6
IBM3033 77-03 78-03 12 VERY LARGE S/370+EF INSTRUCTIONS
IBM3031 77-10 78-03 05 LARGE S/370+EF INSTRUCTIONS
IBM3032 77-10 78-03 05 LARGE S/370+EF INSTRUCTIONS
IBM3033MP 78-03 79-09 18 MULTIPROCESSOR OF 3033
IBM3033MP 78-03 79-09 18 MULTIPROCESSOR OF 3033
AMHPLANT 78-05 AMDAHL OPENS DUBLIN, IRELAND PLANT
AMHV8 78-10 79-09 11 (1.80-2.00)V6, FLD UPGR. FROM V7
IBM3033AP 79-01 80-02 13 ATTACHED PROCESSOR OF 3033 (3042)
IBM3033 79-11 79-11 00 -15% PURCHASE PRICE CUT
IBM3033N 79-11 80-01 04 DEGRADED 3033, 3.9MIPS
IBM3033AP 80-06 80-08 02 3033 ATTACHED PROCESSOR
IBM3033 80-06 81-10 16 Ext. Addr.=32MB REAL ADDR.;MP ONLY
IBMD.Addr.Sp. 80-06 81-06 12 Dual Address Space for 3033
IBM3033XF 80-06 81-06 12 OPTIONAL HW/FW PERF. ENHANCE FOR MVS/SP
AMHUTS 80-09 81-05 UTS=Amdahl Unix Op. System (under VM)
IBM3033.24MB 80-11 81-11 12 24MB REAL MEM. FOR 3033UP, AP
IBM3081D 80-11 81-4Q 12 FIRST H MODEL, 10MIPS IN DP, WATER COOLED
AMH580/5860 80-11 82-09 22 (2V8, 12+ MIPS) UP, NEW,AIR COOLED TECH.
AMH580/5880 80-11 85-05 54 MP OF 5860 AT 21+ MIPS
IBM3033S 80-11 81-01 02 2.2MIPS, DEGRADED 3033 (ENTRY 3033 MODEL)
IBM3033N.UPGR. 80-11 80-11 00 9%-14% PERF. IMPROVE, NO CHARGE
IBM3081K 81-10 82-2Q 08 NEW DP FUM: 1.353081D, 64K BUFFER/OVLAP
IBM370-XA 81-10 83-03 17 NEW ARCH 3081: 31 BIT REAL/VIRT, NEW I/O
IBM3033.PRICE 81-10 10% IN US, 12-20% EUROPE PURCH. ONLY
IBM3033S.PERF. 81-10 82-06 08 NO-CHARGE PERF. BOOST BY 8%-10%
IBM3033 82-03 16% PUR.PRICE CUT, -14%Mem.Price($31K/MB)
IBM3033 82-03 3033 Placed on LIMITED-NEW PRODUCTION
IBM3084 82-09 83-4Q 15 1.93081K Perf., 4 way MP, 3081K upgrade
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM operating systems
Newsgroups: alt.folklore.computers
Date: Sun, 29 Feb 2004 16:56:49 GMT
cstacy@news.dtpq.com (Christopher C. Stacy) writes:
I used APL*PLUS in the 70s on the Amdahl/470. I believe that there
was another layer of standard or hacked-up operating system
underneath that. Does anyone know what that was? And what was the
relationship of the IBM operating systems to the APL that IBM had
(APL/360)?
many of the early amdahls ran mts (michigan terminal system) and
vm/370 at universities. the first business/commercial account to
install amdahl was aetna in hartford around mid 1976; from
recent post
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
AMHV/6 75-04?75-06 02 FIRST AMDAHL MACHINE, FIRST PCM CPU
AMHV6-2 76-10 77-09 11 (1.05-1.15)V6 WITH 32K BUFFER
AMHV7 77-03 78-09 18 AMDAHL RESP. TO 3033 (1.5-1.7) V6
random unrelated ... activity I was involved in as undergraduate
that we get blamed for producing the first PCM controller and spawning
the PCM controller business:
http://www.garlic.com/~lynn/subtopic.html#360pcm
later in the 70s there were more amdahl machines running mvs.
apl\360 was apl language and subtasking monitor/swapper that ran as
subsystem under os/360. it typically managed two 16kbyte (or 32kbyte)
swapping regions for apl workspaces and all the terminal interactions,
besides also providing the apl interpreter.
cambridge science center circa 1970
http://www.garlic.com/~lynn/subtopic.html#545tech
took a copy of apl\360 and adopted just the interpreter to cms\apl
... and doing things like rewritting the garbage collecttion for
virtual memory environment (and opening up apl so workspace could just
about be full 16mbyte). it also "corrupted" the apl syntax by adding
support for doing system calls ... so apl programs could do things like
read/write files. this was used to provide services to corporate
hdqtrs planning and business people for doing what-if things that are
typically done with spreadsheets today ... using business models
written in apl. this was something of security challenge since there
were lots of MIT & BU students using cambridge system ... and
corporate people were loading the most highly valued corporate data on
the machine. some misc. comments about cp/67, vm/370 and security in
time-sharing offerings:
http://www.garlic.com/~lynn/subtopic.html#timeshare
cms\apl also became the delivery vehicle for HONE supporting
all the field, marketing, sales people world-wide (hone as well as lots
of general APL comments):
http://www.garlic.com/~lynn/subtopic.html#hone
about 1977 all the US HONE datacenters were consolidated in California
... and possibly the largest (at the time) single system operations
was created for supporting US marketing, sales and field forces. HONE
clones were created at various places around the world ... for some
number of clones I hand carried and personally did the install ... the
original was when EMEA hdqtrs moved from NY to la defense (near paris)
... random recent ref:
http://www.garlic.com/~lynn/2004b.html#58 oldest running code
the palo alto science center later did apl\cms with a microcode
accelerator for the 370/145 (apl programs on the 145 w/apl-mcode would
run as fast as on 370/168). apl\cms was then transferred to santa
teresa labs (STL) where support was added for running under MVS
(somewhat back to the original apl\360) in addition to running on CMS
... and renamed apl\sv ... for apl shared variable. This was important
to many people because it eliminated the system call API interface
(corruption) introduced with cms\apl and replaced it with the
shared-variable paradigm ... where things like system call APIs were
abstracted behind the shared variable interface.
there was a special 2741 typeball and little stickers for the front
face of 2741 keys ... that supported the APL character set (as well as
cp/67 and vm/370 translate tables). later there was special 3277
display model that supported apl character set.
quicky use of search engine for a apl*plus (& stsc) history:
http://www.lescasse.com/APLHistory.asp
http://www.rexswain.com/aplinfo.html
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM operating systems and APL
Newsgroups: alt.folklore.computers
Date: Sun, 29 Feb 2004 17:14:10 GMT
johnl@iecc.com (John R. Levine) writes:
The IBM 5100, an early single user portable computer, also ran
APL\360. They wrote an emulator for as much of the 360 instruction
set as APL needed, and replaced the OS interface with code to talk to
the keyboard, screen, and cartridge tape that the 5100 had. It wasn't
fast, but it was real APL and was quite usable.
random past 5100 & palm (Put All Logic in Microcode) refs:
http://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
http://www.garlic.com/~lynn/2000.html#70 APL on PalmOS ???
http://www.garlic.com/~lynn/2000d.html#15 APL version in IBM 5100 (Was: Resurrecting the IBM 1130)
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2000g.html#46 A new "Remember when?" period happening right now
http://www.garlic.com/~lynn/2001b.html#45 First OS?
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2002b.html#39 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#47 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2003i.html#79 IBM 5100
http://www.garlic.com/~lynn/2003i.html#82 IBM 5100
http://www.garlic.com/~lynn/2003i.html#84 IBM 5100
http://www.garlic.com/~lynn/2003j.html#0 IBM 5100
http://www.garlic.com/~lynn/2003n.html#6 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS/370 binary distribution now available
Newsgroups: bit.listserv.ibm-main
Date: Sun, 29 Feb 2004 19:17:15 GMT
edgould@ibm-main.ameritech.net (Edward A. Gould) writes:
Hmmm.. I was around 30 years ago and don't honestly remember too
much about TSS. Is there an INTRO or some such doc that will at
least give me a basic understanding of TSS?
there is some of the politics between the science center and mohansic
over virtual memory operating system in melinda's refs:
http://www.princeton.edu/~melinda/
tss/360 was time-sharing system that supported virtual memory and both
24-bit and 32-bit virtual address modes on 360/67 (i.e. 67 had 32-bit
virtual address supported compared to the later 31-bit virtual address
support introduced much later with 3081).
one big user of TSS/370 was at&t which had a special version of TSS
kernel as the underpinnings of 370 unix-based internal offering.
use search engines on tss/360 & tss/370 for lot more references
lots of old random mentions of tss/360 and/or tss/370:
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#1 pathlengths
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#48 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#6 mainframe question
http://www.garlic.com/~lynn/2001l.html#7 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#9 mainframe question
http://www.garlic.com/~lynn/2001l.html#11 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#18 mainframe question
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2001m.html#53 TSS/360
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#0 TSS/360
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2001n.html#89 TSS/360
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002d.html#23 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#36 Blade architectures
http://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
http://www.garlic.com/~lynn/2002f.html#42 Blade architectures
http://www.garlic.com/~lynn/2002f.html#53 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002j.html#27 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
http://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#57 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003d.html#58 POWER hashes vs tree
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#41 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#16 OSI not quite dead yet
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
http://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
http://www.garlic.com/~lynn/2004.html#4 TSS/370 source archive now available
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
Newsgroups: alt.folklore.computers
Date: Tue, 02 Mar 2004 04:48:04 GMT
Peter Flass writes:
On a software basis alone it would win hands-down. BPM/BTM were
somewhat primitive, but still beat TSO. UTS (and presumably CP-V)
were very capable systems, and the Fortran compiler would run rings
around anything IBM had.
i wasn't doing TSO ... as undergraduate ... I had put terminal I/O
support into HASP and support for the syntax from the CMS editor ..
for early CRJE. put I was doing lots of cms stuff ... and by the
time of 370/145 was VM/370 and cms. recent threads that touch
on some of the issues:
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004b.html#53 origin of UNIX dd command
http://www.garlic.com/~lynn/2004b.html#47 new to mainframe asm
This was about the time of the CERN TSO-CMS bake-off ... the report
was made available at SHARE about the TSO-CMS comparison (benchmarks,
features, useability, etc).
an interesting side point was that while the CERN report was general
made available at SHARE ... the copies that were taken "in house" got
stamped "confidential, restricted"; available on need to know basis
only ... aka it wouldn't do to distribute thruout the corporation how
TSO actually fared against CMS.
lots of random old references to CERN benhmark & share paper:
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/2000e.html#23 Is Tim Berners-Lee the inventor of the web?
http://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001g.html#24 XML: No More CICS?
http://www.garlic.com/~lynn/2001g.html#54 DSRunoff; was Re: TECO Critique
http://www.garlic.com/~lynn/2001h.html#11 checking some myths.
http://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
http://www.garlic.com/~lynn/2001n.html#40 Google increase archive reach
http://www.garlic.com/~lynn/2002g.html#67 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002h.html#14 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002n.html#35 VR vs. Portable Computing
http://www.garlic.com/~lynn/2002n.html#37 VR vs. Portable Computing
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2003.html#54 Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003k.html#13 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: 40yrs, science center, feb. 1964
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 02 Mar 2004 18:39:47 GMT
Feb. 1964, 40years, cambridge science center
other 545 tech sq references:
http://www.garlic.com/~lynn/subtopic.html#545tech
cp/67 was announced at spring '68 share in houston (cp/40 had been
previously been done on modified 360/40 pending availability of
360/67):
http://www.garlic.com/~lynn/2003d.html#72
long post that includes several 360/370 announce/fcs dates:
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
other timesharing refs:
http://www.garlic.com/~lynn/subtopic.html#timeshare
from Melinda's history paper
http://www.princeton.edu/~melinda/
short extract from the history paper at above
... 360 announced 4/7/1964 ...
... Feb 64, IBM had sent Norm to establish the Science Center ...
... Also in 1969, the system that was to become UNIX would be begun at
Bell Labs as an offshoot and elegant simplification of both CTSS and
Multics ...
longer extract (see the original paper for much more) ...
However, inside IBM at that time there was a strong belief that
time-sharing would never amount to anything and that what the world
needed was faster batch processing. MIT and other leading-edge
customers were dismayed, and even angered, on April 7, 1964, when IBM
announced System/360 without address relocation capability. The
previous Fall, MIT had founded Project MAC to design and build an even
more useful time-sharing system based on the CTSS prototype. Within
Project MAC, Corbato and others were to draw on the lessons they had
learned from CTSS to build the Multics system. The basic goal of the
Multics project "was to develop a working prototype for a computer
utility embracing the whole complex of hardware, software, and users
that would provide a desirable, as well as feasible, model for other
system designers to study." At the outset, Project MAC purchased a
second modified 7094 on which to run CTSS while developing Multics. It
then requested bids for the processor on which Multics would run.
In February of 1964, IBM had sent Norm Rasmussen to Cambridge to
establish what became the Cambridge Scientific Center (CSC). Cambridge
in the 1960s was an exciting place, full of ferment. It was a
congenial place for Rasmussen, who was very much a man of that era,
and it was a congenial assignment, as well, because Rasmussen was
eager to demonstrate that science has a role to play in the building
of good software. Rasmussen arranged for space for the Scientific
Center in the same building as Project MAC, 545 Technology Square.
(For many years after that, the Scientific Center programmers and the
Project MAC programmers would remain on friendly terms and would
occasionally get together in the bar on the ground floor of that
building after work.)
All of IBM's contractual relationships with MIT were turned over to
the new Scientific Center to administer. The Scientific Center was
also expected to take the lead in making IBM "respectable" to the
academics. So, only weeks after his arrival in Cambridge, Rasmussen
had to deal with MIT's very negative reaction to System/360. Within
days of the System/360 announcement, the chief S/360 architect, Gene
Amdahl, came to Cambridge to meet with Professor Corbato and his
colleagues, but that meeting seems only to have made matters worse.
As a loyal IBMer, Rasmussen was deeply embarrassed by IBM's failure to
heed the advice of such an important customer, and he became
determined to make things right, to do whatever was necessary to make
System/360 right for MIT and other customers. To do that, he knew that
he would need very talented people, so he set about attracting the
best people he could find. He was fortunate to be able to start by
taking over the staff of IBM's MIT Liaison Office. From the Liaison
Office came two very skilled Systems Engineers, Les Comeau and John
Harmon, as well as a quiet, unassuming Customer Engineer named Fritz
Giesin, who would come to be treasured by generations of programmers
at the Center. Next came another excellent IBM programmer, Ron
Brennan, from the Federal Systems Division. Shortly after that, one of
the seven CTSS authors, Lyndalee Korn, left MIT to join the Center.
One of the first jobs for the staff of the new Center was to put
together IBM's proposal to Project MAC. In the process, they brought
in many of IBM's finest engineers to work with them to specify a
machine that would meet Project MAC's requirements, including address
translation. They were delighted to discover that one of the lead
S/360 designers, Gerry Blaauw, had already done a preliminary design
for address translation on System/360. Address translation had not
been incorporated into the basic System/360 design, however, because
it was considered to add too much risk to what was already a very
risky undertaking. The machine that IBM proposed to Project MAC was a
S/360 that had been modified to include the "Blaauw Box". This
machine was also bid to Bell Labs at about the same time. It was never
built, however, because both MIT and Bell Labs chose another
vendor.
MIT's stated reason for rejecting IBM's bid was that it wanted a
processor that was a main-line product, so that others could readily
acquire a machine on which to run Multics. It was generally believed,
however, that displeasure with IBM's attitude toward time-sharing was
a factor in Project MAC's decision. Losing Project MAC and Bell Labs
had important consequences for IBM. Seldom after that would IBM
processors be the machines of choice for leading-edge academic
computer science research. Project MAC would go on to implement
Multics on a GE 645 and would have it in general use at MIT by
October, 1969. Also in 1969, the system that was to become UNIX would
be begun at Bell Labs as an offshoot and elegant simplification of
both CTSS and Multics, and that project, too, would not make use of
IBM processors.
But getting back to the summer of 1964: Norm Rasmussen had just begun
his fight to make System/360 acceptable to the academics and was not
having an easy time of it. During that summer, Professor Corbato (a
man widely known for his gentlemanliness) published a Project MAC
Report containing a devastating analysis of the weaknesses of the
S/360 as a machine on which to implement a time-sharing system. Other
customers were also expressing concern about the lack of time-sharing
capability in System/360. In August, SHARE's Advanced Planning
Division presented a survey of the currently operating on-line
programming systems. One of the speakers was Fernando Corbato, who
emphasized the potential for growth of the computing industry due to
time-sharing.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: comp.lang.basic.misc,alt.lang.basic,alt.folklore.computers
Date: Tue, 02 Mar 2004 21:12:34 GMT
hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins) writes:
The oil companies don't seem to have anything to do with it--it sounds
like garden variety tax-dodging.
I don't know about Wales, but in the U.S., fuel taxes pay for things
such as roads . . . we sell dyed untaxed diesel for agricultural use.
slightly related thread on fuel taxes for roads
http://www.garlic.com/~lynn/2002j.html#41 Transportation
http://www.garlic.com/~lynn/2003i.html#21 Spam Bomb
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Yakaota
Newsgroups: alt.folklore.computers
Date: Thu, 04 Mar 2004 22:50:36 GMT
Charles Richmond writes:
In the US in the 1970's, the common thing to say was
"computer code" and *not* "codes". Instruction codes
were refered to as operation codes or "op-codes".
the high performance computing culture commonly used codes ....
like the environment that spawned the SLAC-enhancements to the (370)
ASM-H. big deal was made of things like getting codes to fit within
the 64 instruction pipeline of the 195.
extraneous references to SLAC modifications
http://www.xephon.com/arcinframe.php/m090a06
search engine for *high-performance* and *codes* turns up various
extraneous references
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A POX on you, Dennis Ritchie!!!
Newsgroups: alt.folklore.computers
Date: Sat, 06 Mar 2004 18:03:25 GMT
bhk@dsl.co.uk (Brian {Hamilton Kelly}) writes:
[I'm just reposting this; I now have suggestions from others that my post
wasn't carried by some servers, because although it bore a Date of 21st
Feb, it wasn't successfully injected until 29th. AIUI, some servers may
have discarded it as "too old" rather than making it available for
download to clients.]
an old rex(x) b'day thread:
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000b.html#30 20th March 2000
http://www.garlic.com/~lynn/2000b.html#31 20th March 2000
http://www.garlic.com/~lynn/2000b.html#32 20th March 2000
http://www.garlic.com/~lynn/2000b.html#33 20th March 2000
http://www.garlic.com/~lynn/2000b.html#44 20th March 2000
--
Anne & Lynn Wheeler - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If there had been no MS-DOS
Newsgroups: alt.folklore.computers
Date: Sat, 06 Mar 2004 17:51:50 GMT
Brian Inglis writes:
Widespread availability was a cost issue, not a functionality issue.
Terminals went on everyone's desk when they became cheap enough.
PCs went on everyone's desk when they became cheaper than terminals.
I've rarely worked in the computer industry, but my impression from
those inside was that hardware went out the door for demos or sales,
and those in the industry had a harder time getting equipment than
those outside, in businesses buying from the vendors.
It *MAY* have been better in industry software development groups, but
I wouldn't have bet on it.
it wasn't only cost of the terminal ... but cost of the online
infrastructure that the terminal was connected to. then all the
datacenter infrastructure to deal with people sitting at their
terminals and calling up and complaining about service and response
time (i.e. number and frequency of interactions with the datacenter
increased by several orders of magnitude ... aka ... potentially every
keystroke).
for really large organization that both produced terminals and
software, terminals going to customers would show up on quarterly
bottom line as revenue ... while terminals going to employees would
show up as expense. if there was large customer demand for terminals
requiring some allocation decision ... which is better revenue or
expense?
there are also somewhat related issues .... i once had a converstation
with guy running datacenter for large development lab about installing
an enhancement to the resource manager that provided deterministic
resource scheduling by group. the offer was decline ... because then
it was just another thing that the datacenter manager had to deal with
... the political fights with the heads of different groups about the
settings that the deterministic group resource allocation should
have. if it was accepted to be (relatively) total anarchy ... then the
datacenter manager couldn't be blamed or held accountable (as to
which group was getting more or less resources than some other group).
in the wake of Jim Gray's MIPENVY ...
http://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002o.html#75 They Got Mail: Not-So-Fond Farewells
a study was commissioned that went around to various research
institutions and universities documenting computing facilities
available. partial short summary from that survey:
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
some past postings related to corporate terminal justifications
http://www.garlic.com/~lynn/2000.html#6 Computer of the century
http://www.garlic.com/~lynn/2002j.html#33 VT50, VT51, VT52, VT55, VT61, VT62 terminals (was Re: Weird...)
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
--
Anne & Lynn Wheeler - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Anyone Still Using Cards?
Newsgroups: alt.folklore.computers
Date: Sun, 07 Mar 2004 17:09:07 GMT
arargh403NOSPAM writes:
Chicago - Yes.
Originally designed to deliver goods and fuel (coal and to remove the
clinker) to buildings in the downtown area, later used (by accident)
to deliver a flood to a large part of the downtown area, and now,
AFAIK, mostly used for fibre optic (and probably other) cables.
at about that time we were out hawking ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
we had coined the terms disaster survivability and geographic
survivability.
a number of operatins had done all sorts of industrial provisioning
including service diverse routing. one operation had identified a
building (for a datacenter) in a downtown metropoilitan area that had
different water mains on opposite sides of the building, different
electrical power grid service on opposite sides of the building and
service from four different telco offices arriving at the building
from four different directions. during this period that datacenter was
taken out by explosion of electrical transformer in the basement
(which included the contaimination of the bldg environmental by PCB).
It was also in this period that the chicago flood took out a number of
"hardened" datacenters.
misc. past refs to disaster &/or geographic survivability
http://www.garlic.com/~lynn/98.html#23 Fear of Multiprocessing?
http://www.garlic.com/~lynn/99.html#145 Q: S/390 on PowerPC?
http://www.garlic.com/~lynn/99.html#184 Clustering systems
http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
http://www.garlic.com/~lynn/2000g.html#27 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#41 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#43 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002e.html#67 Blade architectures
http://www.garlic.com/~lynn/2002e.html#68 Blade architectures
http://www.garlic.com/~lynn/2002f.html#4 Blade architectures
http://www.garlic.com/~lynn/2002i.html#24 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002m.html#5 Dumb Question - Hardend Site ?
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2003.html#38 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003f.html#36 Super Anti War Computers
http://www.garlic.com/~lynn/2003h.html#31 OT What movies have taught us about Computers
http://www.garlic.com/~lynn/2003h.html#60 The figures of merit that make mainframes worth the price
http://www.garlic.com/~lynn/2003o.html#6 perfomance vs. key size
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If there had been no MS-DOS
Newsgroups: alt.folklore.computers
Date: Sun, 07 Mar 2004 17:48:16 GMT
jmfbahciv writes:
Of course it opened new doors. What the PC did was give
computer access to the hairy masses. Computer centers
at universities were beginning to become Nazis about who
had access to their timesharing machines, were severely
limiting bit storage capacities, and were beginning to
become very proprietary about who got to read sources.
Most kiddies wanted to play games. Most installations
removed those games.
of course one of the issues was that these datacenters were funded to
accomplish some set of goals and objectives for a large and diverse
population. many of the timesharing infrastructures of the period were
prone to all kinds of resource diversion and other hacks by a relative
small (and usually unidentified) subset of the general (student)
population (situations not all that different from current internet
issues).
however at this period ... such hacking 1) compromised the funded
datacenter objectives, 2) in many cases could put the jobs of the
datacenter staff at risk, and 3) the risk originated from a population
that weren't necessarily a major part of the directly funded
datacenter objectives (and therefor was fairly straighforward to put
restrictions on the population from where the risk originated).
the current differentiation with the internet ... is that it is
currently difficult to differentiated the source of servere risk
(relatively small population) from the general target service
population.
i have a similar posting about road thruput ... that adverse driving
habits of less than one percent of the population can severely degrade
heavy traffic thruput on major roads (for all drivers). It only takes
one or two cars out of a hundred that
1) frequently changing lanes in heavy traffic ... taping breaks,
darting into small adjacent openings, both of which result in cars
behind them suddently applying breaks (and break lights) which then
propagates to possibly several hundred following cars and frequently
is the cause of severe accordion effects of traffic flow
2) drving in the far, high-speed lane and waiting until they are 100
feet or so before an exit before they realize they have to exit,
hitting the breaks and negotiating 2-4 lanes in order to crowd into
the front of the exit lane (effectively bringing to stop several
hundred cars behind them).
for the 2nd scenario ... several places have implemented barricades
that extend for quite a distance on the exit lane ... as well as
express lanes where exits are relatively infrequent. these address the
bad driver exit behavior ... but doesn't address the lane changing
jitter/brownian-motion behavior (with the following brake light
cascading effect)
the assertion is that activities by relatively small percentage of
drivers will severaly degrade the driving environment for all drivers
under heavy traffic conditions (and in fact can actually precipitate
the transition from moderate traffic to extremely heavy traffic
because of the drastic reduction in the traffic thruput). this is
parallel between the highway system and the internet ... that
activities by a very small percentage of what appears to be the
general propulation result in severe degradation of the overall
environment ... and it not possible to address the problem by simply
denying the use of the facilities to easily identifiable small subset
of the population from which the risk originates.
lots of topic drift ... back to some specific posts about timesharing
http://www.garlic.com/~lynn/subtopic.html#timeshare
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IT jobs move to India
Newsgroups: alt.folklore.computers
Date: Sun, 07 Mar 2004 18:27:58 GMT
"Jack Peacock" writes:
Every country has the sovereign right to decide what their tax
structure should be. Demands like that can backfire...what would
happen if the EU demanded the US double it's income tax rates and
mandate 6 week vacations so Europe would be more competitive?
long ago, i was teaching an extended class during first shift
someplace in europe ... and also coming in early and staying late
doing various online stuff.
i asked if i could come in all day sat ... and was told that they
could arrainge it if i really needed to ... but he already had a lot
of paperwork to fill out for the gov. (in response to reports
submitted to the the gov. about my coming in early and leaving late)
.... and there would be a lot more gov. paperwork that he would have
to do if I did come in on the weekend.
apparently the convention had just switched from 5week vacation to
6week vacation .... and these particular employees had already been
used to having 6weeks. the volumes of submitted gov. reports was
supposedly based on some of the employees being used to having a week
more vacation than everybody else ... and they thought that when
everybody else (in the country) was increased from 5weeks to 6weeks,
their vacation should be increased from 6weeks to 7weeks.
it was apparently disgraceful to work 14-16 hrs a day, seven days a
week.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IT jobs move to India
Newsgroups: alt.folklore.computers
Date: Mon, 08 Mar 2004 04:48:44 GMT
"Stimpy" writes:
It's effectively illegal since the introduction of the European
Working Time Directive. This attempts to limit how much time over
and above the contracted hours can be worked.
There is currently a facility to allow workers to voluntarily opt out but
this is to be tightened up in a couple of years. It's all to do with
helping break the 'long hours are good' culture and encourage a better
work-life balance as well, of course, as helping those workers being
forced/pressurised to work overtime
i suppose they wouldn't like it at all that when i was in school they
would let me have the datacenter on the weekends starting at 8am sat
... i could then pull a 48hr shift w/o sleep until 8am monday ...
and then go to classes ... misc. past posts mentioning pulling
48hr shift and then going to class
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/98.html#55 Multics
http://www.garlic.com/~lynn/2000d.html#46 Charging for time-share CPU time
http://www.garlic.com/~lynn/2002o.html#1 Home mainframes
http://www.garlic.com/~lynn/2002o.html#2 Home mainframes
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parallel programming again (Re: Intel announces "CT" aka
"IA-32e")
Newsgroups: comp.arch
Date: Mon, 08 Mar 2004 18:46:08 GMT
"Stephen Fuld" writes:
While I am not necesarily opposed to a higher gas tax, you have to
be carefull about trying to make wholesale changes quickly. For
example, in the US, many people work at jobs that are far enough
from where they live (both by their won choices) that they must use
a car to get from one to the other. They have built their life
around those choices. If you suddenly dramatically increased the
gax tax, it would cause major dislocations as people couldn't afford
to get to their jobs, or would have to decrease their life style
(i.e purchase less good) because they would be spending more on gas.
If that happens, our economy suffers. You can't change "just one
thing".
another way it is expressed is that cheap gas has subsidized numerous
life-style choices ... or .... it allows individuals to occupy
economic (environment) niches that wouldn't be possible w/o the
availabiilty of cheap gas. one could assert that the difference in the
price versus the value (of gas) is the subsidy that supports such
life-style choices. in general, the difference between the price and
the value subsidizes lots of standard of living issues ... not just
distance from work. cheap food is also predicated on cheap
transportation (as well as various farm machinery).
there is also the issue that the highway costs are essentially
proportional to the use by heavy trucking. much of the gas tax is used
for transportation infrastructure maintenance ... with significant
amount of that tax coming from recreational & life-style driving
... even tho recreational & life-style driving has little or no impact
on highway infrastructure costs. So in addition to the heavy trucking
transportation industry effectively being subsidized by cheap gas
... the highway infrastructure in support of heavy trucking
transportion is further subsidized by spreading the gas tax across all
driving ... not just heavy trucking that is primarily responsible for
the costs.
some specific references to road design/maintenance being driven by
heavy trucking and that road use by cars, pickups, two-axle vehicles,
etc having effectively no impact on highway wear & tear:
http://www.garlic.com/~lynn/2002j.html#41 Transportation
http://www.garlic.com/~lynn/2002j.html#42 Transportation
in any case, there has been significant exploitation of
economic/environmental niches through-out the infrastructure
predicated on availability of cheap gas. you might not even be able to
determine all such dependancies w/o actually drastically increasing
the price of gas.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PSW Sampling
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 08 Mar 2004 19:10:17 GMT
shmuel+ibm-main@ibm-main.Patriot.net (Shmuel Metz , Seymour J.) writes:
That term covers a multitude of sins; it doesn't really say what you
are trying to do. What do you mean by "address space monitor"? Are you
trying to produce a histogram of problem program instruction
executions? All instruction executions? Something else entirely?
long ago and far away (mid-70s) the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
shipped a product called vs/repack.
at its core it had an instruction simulator that ran traces on
application execution ... recording at 32byte boundaries, execution
fetches, data fetches and data storage. It was typically setup to dump
out the storage use maps every 2000 or so instructions. This
information was used by vs/repack application using cluster analysis
to do program & module reordering for optimal page set size and paging
characteristics.
just the map was also used for various internal development projects
identifying hotspots and areas for redesign/rewrite (in some cases,
long before it was released as a product). it was used (early '70s on
cp/67) in the port of apl\360 to cms\apl redoing storage allocation &
storage garbage collection. apl\360 typically ran 16-32kbyte
workspaces where the whole workspace was swapped in/out in single
operation. move to cms\apl (on cp/67 with 360/67) was a virtual paged
environment where workspace might be up to 16mbytes. The storage
allocation for the 16kbyte swapped environment was horribly
inefficient in a large virtual memory environment.
it was also used by places like the IMS development group ... looking
at where IMS was spending all of its execution time.
There was a co-project which involved modifying the CP/67 kernel. A
new feature was added to the CP/67 that allowed a fixed number of
valid pages being made available to a virtual process. The process was
allowed to fault on that many pages until it had reached the valid
virtual page limit. At that point, the list of valid virtual pages
were recorded, and then had the invalid page bit set (they were
allowed to sit around in storage). This kernel modification ran
significantly faster than the instruction emulation implementation and
there were several studies done comparing the quality of the data
gathered by the kernel modification for limited virtual page numbers
versis the data gathered by the instruction simulation implementation.
For most of the areas that vs/repack was used in ... there was little
difference seen in the quality of the results between the two methods
of gathering information for studying program/application behavior.
early post on psw sampling with respect to microcode support:
http://www.garlic.com/~lynn/2004c.html#5 PSW sampling
random past posts mentioning vs/repack
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002f.html#50 Blade architectures
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits
http://www.garlic.com/~lynn/2004.html#14 Holee shit! 30 years ago!
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More complex operations now a better choice?
Newsgroups: comp.arch
Date: Tue, 09 Mar 2004 15:07:24 GMT
glen herrmannsfeldt writes:
I have sometimes wondered if S/360 (and a little less, its successors)
should be considered RISC. Pretty much only two addressing modes.
Three instruction lengths, coded by the first two bits of the opcode.
Instructions on 16 bit boundaries. Though there are some pretty
complicated instructions in there, too.
one could make the case that 801 was re-action to the failure
of FS ... misc. FS references:
http://www.garlic.com/~lynn/subtopic.html#futuresys
which was supposedly to have been the follow-on to s/360.
the 801 presentation ... misc 801 references
http://www.garlic.com/~lynn/subtopic.html#801
that i remember from '76 or so .... was no SMP support, no cache
consistency, no protection domain, and various hardware/software
trade-offs that effectively moved stuff from hardware into
software. thruput optimization came purely from combination of
extremely simple instructions and compiler technology (i.e. it was
possible for the compiler to accurately model the simplified hardware
instruction processing ... and generate instruction sequences for
optimal hardware thruput).
protection would be provided by a combination of compiler technology
and checking at bind/load time (i.e. compiler wouldn't generate
insecure code and the binder/loader would make sure that executable
came from valid compiler).
virtual memory was combination of inverse tables, software loading of
hardware lookaside table, and small number of segment registers. the
small number of segment registers was compensated for by a lack of
protection domain and that in-line application code could change
segment register values as easily as it could change general register
values.
FS had gone to extreme of complex (object?) instructions, something
like generic ADD instruction would figure out whether the operands
were interger, floating-point, string, etc ... and magically do the
appropriate thing. 801 had gone to the opposite extreme ... making the
hardware implementation as simple as possible (not just instruction
specification) and attempting to move all complexity into software
technology. a side-effect of the extreme 801 hardware simplification
was possibly being able to (almost) implement a processor in a single
chip of the day.
one could also make the case that in FS ... somplexity had been chosen
for the sake of complexity ... with little or no other supporting
business reason. however, there has been some claims that the overall
FS system complexity (not just instructions) would result in an
extremely complex overall system ... effectively creating barrier to
entry for PCM (plug compatible manufacture) controllers ... something
that I've been blamed for helping create from project that I worked
on as undergraduate ... misc. 360 pcm refs:
http://www.garlic.com/~lynn/subtopic.html#360pcm
some specific references/quotes about the FS complexity issue:
http://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Jargon Files Wanted
Newsgroups: alt.folklore.computers
Date: Wed, 10 Mar 2004 05:30:23 GMT
Steven Ehrbar writes:
2.9.8
i've got
jargon271.ascii
jargon296.ascii
jargon298.ascii
www.212.net has some version of ibm jargon
http://www.212.net/business/jargon.htm
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More complex operations now a better choice?
Newsgroups: comp.arch
Date: Wed, 10 Mar 2004 17:17:53 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
This is why a lot of people are proposing a CISC ISA, which gets
translated into a RISC code for execution. As in the Crusoe,
Pentium 4 etc. Actually, as in the Perq, if I recall.
and all the low-end 360s & 370s ... with vertical microcode ... it was
the high end 370s that instructions were handled by complex horizontal
microcode. the low-end 360s/370s were frequently rated in the
avg. number of microcode instructions per "machine" instruction. The
high-end horizontal microcode machines were more commonly rated in avg
machine cycles per "machine" instruction (in part because a horizontal
microcode instruction could be doing several things simultaneously &
somewhat asynchronously).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More complex operations now a better choice?
Newsgroups: comp.arch
Date: Wed, 10 Mar 2004 19:50:10 GMT
"Mike Cowlishaw" writes:
When Java came out I used to enjoy making the comparison with
S/360. All the initial machines were interpreters of the S/360 'byte
codes'. Only later were there real hardware S/360 machines...
and at a 1996 java conference ... i joked with the Sun general manager
that "owned" java about virtual machines circa mid-60s on 360
.... cp/40 on modified 360/40 and then later ported to 360/67 as cp/67
(of course he had previously been at Los Gatos lab and one of the two
people responsible for vs/pascal ... and had come to sun after
previously being vp of software development at the "old" mips.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 10 Mar 2004 20:40:25 GMT
ccampbe2@ibm-main.csc.com (Colin Campbell) writes:
I had never thought much about the state of TSO/E until this thread
started. I first used TSO about the time it was introduced, around
1975. As a young programmer who had been working with Time-Sharing
on the GE-635 for awhile, I wondered what took IBM so long.
I have used it ever since, and in my shop, all the programmers are
logged on for the greatest part of their workday. Of course, we use
ISPF under TSO/E. I'm struggling to imagine an alternative method
of getting our day ot day work done.
it wasn't that it took ibm so long for time-sharing ... there
was the whole project mac scenario ... some of it repeated:
http://www.garlic.com/~lynn/2004c.html#11 40yrs, science center, feb. 1964
as well as the whole tss/360 (and tss/370) follow-on stuff that
floundered.
TSO was mostly glorified conversational job entry ... that happened to
talk to terminals. I had done something similar in the late 60s
... putting in terminal support in HASP and implementing the CMS
editor syntax for program submission.
circa 1974, CERN presented a report at SHARE on its TSO/CMS bake-off
... which was one of the reasons that CERN (as well as SLAC) heavily
went vm/370 & CMS. that in part contributed to evolution of HTML
... since CERN then was GML/SGML user (and GML had originated on CMS
at the science center).
recent posting with some reference to the CERN TSO/CMS bake-off
http://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370.
note also various of the time-sharing service bureaus in the early 70s
were CMS based (either originally from CP/67 and then later VM/370):
http://www.garlic.com/~lynn/subtopic.html#timeshare
probably the largest such time-sharing service operation in the 70s
were the internal HONE systems (initially cp/67 but then converted all
to vm/370) which supported all of the world-wide sales, marketing,
branch, and field people (aka in the late '70s, just the US HONE
complex had something approaching 40k defined users):
http://www.garlic.com/~lynn/subtopic.html#hone
for strange connection ... as undergraduate putting TTY support into
cp/67 and then TTY and 2741 support into HASP ... led me to trying to
make the 2702 do something that it couldn't do (although the whole
thing with SAD command being able to specify the line-scanner for each
port sort of implied it should have been able to dynamically assign
any line-scanner to any line). That in turn led to undergraduate
project where some of us reversed engineered the IBM channel interface
and built our own control unit (that would support both dynamic
terminal identification and dynamic line-speed identification). Which
in turn gets us blamed for originating the IBM PCM controller
business
http://www.garlic.com/~lynn/subtopic.html#360pcm
And the IBM PCM controller business was supposedly one of the
primary justfications for FS. recent posting with some FS
references
http://www.garlic.com/~lynn/2004c.html#22 complex operations now a better choice?
and a lot more FS references:
http://www.garlic.com/~lynn/subtopic.html#futuresys
and the 801 activities can be considered a reaction to the glorious
falure of FS (going to nearly the opposite extreme with KISS):
http://www.garlic.com/~lynn/subtopic.html#801
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 10 Mar 2004 23:04:41 GMT
thomen@ibm-main.us.ibm.com (Mark Thomen) writes:
Ummmm, I think I'd have to disagree. CRBE (Conversational Remote
Batch Entry) and CRJE (Conversational Remove Job Entry) both
preceded the introduction of TSO. I worked at OSU, which was a Beta
test site for TSO and had run both CRBE and CRJE well before that.
While those systems were "conversational job entry" in format, TSO
was a major step forward, had significant additional function, and
was quite different than the design and implementation of CRBE/CRJE.
TSO never looked back, and continued to add much more function. SPF
was a god-send and the usage of TSO exploded after that, but I would
never have considered TSO simply a job entry system.
it may be true that TSO was/is better than some specific CRJE
implementation. however TSO would never be confused for a any kind of
competitive time-sharing environment (including per the CERN TSO/CMS
bake-off report presented at SHARE circa 1974); i.e. tso is online
support for a batch environment, aka the glorified conversational
job entry phrase as per original comment:
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
also as per above, as an undergraduate in the late '60s, I had put in
(2741 & TTY) terminal support into HASP ... implementing an online
environment that included support for the CMS editor syntax (although
the code was written from scratch to fit into HASP). I considered it
relatively tolerable implementation for an online environment
supporting a fundamental batch infrastructure .... with syntax and
response much better than later TSO implementation that I saw.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 10 Mar 2004 23:11:43 GMT
ccampbe2@ibm-main.csc.com (Colin Campbell) writes:
I agree with Mark. My first use of TSO was to develop what I
believe was the first JCL syntax checker and standards enforcement
tool. I used the EDIT, ASM, and TEST commands all day long for
weeks, hardly ever submitting a job. I could not believe how much
simpler TSO made the job.
are you saying that TSO was a competitive time-sharing offering ... or
it was better than various specific CRJE implementations that you had
previously delt with?
in the HASP scenario that I mentioned ... I could also edit, assemble,
and test all day long sitting at a tty or 2741. however, i would still
consider it online support embedded in a batch paradigm system. also,
the editor syntax (that i had borrowed from cms) and the response time
was better than I saw from subsequent TSO implementation.
original post:
http://www.garlic.com/~lynn/2002c.html#26 Moribund TSO/E
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: separate MMU chips
Newsgroups: comp.arch
Date: Wed, 10 Mar 2004 22:50:10 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
The System/360 and System/370 did not do that, because they did not
architect the relevant data separately from the interrupt PSW, so
all imprecise interrupts were necessarily non-recoverable. But that
was a design decision, and could have been done differently.
I was told (long ago and far away) that a major difference between
360/195 and 370/195 ... was that a lot of ibm standard mainframe RAS
instruction retry was added for the 370/195 ... which might have gone
a long way to cleaning various imprecise interrupt issues (there was
something about the 195 being fast enough and there was so many
components that a soft failure could be expected on the order of
daily). quick use of search engine about instruction retry for 195
just turns up some of my old postings.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 11 Mar 2004 00:10:55 GMT
... and for something completely different ... the person referenced
in the following regarding java virtual machines
http://www.garlic.com/~lynn/2004c.html#25 More complex operations now a better choice?
in the early to mid 80s, between his stint at Los Gatos lab and MIPS ...
helped form a startup to do a 3270 controller clone. the sole
justification for the company and the controller was that TSO editing
would be offloaded into the controller ... because TSO was
so very,
... very,
... extremely,
... bad
This was also in the period when the (really bad) performance of 3274
was not considered an issue (since nobody would ever need less than
one second resposne) ... aka 3270s were designed for online use, not
time-sharing use ... posting with some extract from studies of the
period:
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
(and I was demonstrating .11sec trivial system response on heavily
loaded systems)
misc other 3270 postings
http://www.garlic.com/~lynn/2000c.html#63 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#66 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#67 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#23 IBM's mess
http://www.garlic.com/~lynn/2001k.html#30 3270 protocol
http://www.garlic.com/~lynn/2001k.html#33 3270 protocol
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#48 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2002j.html#77 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#2 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2002q.html#51 windows office xp
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003c.html#72 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003d.html#24 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003e.html#43 IBM 3174
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003i.html#30 A Dark Day
http://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
http://www.garlic.com/~lynn/2003k.html#20 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003o.html#14 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#36 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#44 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/99.html#28 IBM S/360
http://www.garlic.com/~lynn/99.html#193 Back to the original mainframe model?
http://www.garlic.com/~lynn/99.html#239 IBM UC info
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 11 Mar 2004 03:55:43 GMT
some futher topic drift with respect to 3270, cms, & tso response:
http://www.garlic.com/~lynn/2004c.html#30 Moribund TSO/E
and
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
this was during the heyday of reports about productivity of subsecond
response (aka quarter second or less) and people optimizing lightly
loaded TSO systems being able to demonstrate one second system trivial
response (see more detailed discussion in above "3270 protocol"
posting).
in this period ('80, '81), STL was bursting at the seams and the
decision was made to move approx 300 IMS (development) programmers to
an off-site location something like five miles away (old bldg 96, part
way between main san jose plant site and STL). The IMS programmers had
been used to something like quarter second response on local 327x
boxes with VM/CMS ... and were decidedly opposed to the idea of having
to suffer with the standard SNA remote 327x solution (especially with
VM/CMS ... TSO users seemed to be significantly less sensitive to the
extreme incremental response penalty inflicted by remote SNA terminal
operation or even for that matter, local SNA terminal operation.
after a lot of investigation, it was decided to deploy a (non-IBM)
channel extender that ran over T1 lines between STL (bldg-90) and
remote location (bldg-96). Local 3270 controllers were then used in
the remote location .... with emulated local channel connectivity back
to the mainframes in the STL machine room.
the actual lash-up was subchannels on the T3 collins digital radio
(aka microwave) that ran between STL and the main plant site (you can
see the repeater tower on top of the hill above Santa Teresa that
divides south san jose from coyote valley (drivers with radar
detectors also take a hit on 85 when they they cross the line between
the repeater tower and the dish on top of bldg-12). Then there was
dish from roof of bldg-12 to the roof of bldg-96 (aka bldg-12 on
the main plant site was relay between bldg-90 and bldg-96).
in any case, after it was all up and running, users claimed to see no
percevied response time difference between the vm/cms reponse on local
3270s in STL ... and the vm/cms response on "local" 3270x in bldg-96.
some misc. references to the bldg 90/96 channel extender (for the IMS
group) are included in postings about the high speed data transport
(HSDT) project:
http://www.garlic.com/~lynn/subtopic.html#hsdt
there was one anomoly that cropped up with the move of the ims
development people to bldg-96 ... after the local 3270x were moved
... the thruput of the affected mainframes increased by 10-15
percent. It turned out that prior to the move, the 3270 controllers
were pretty evenly distributed across all available channels
... shared with disk controllers. What was discovered was that the
channel extenders (that replaced the 3270 controllers as directly
attaching to the real mainframe channels) had significantly lower
channel busy overhead for doing the identical operations.
as an aside ... a similar deployment was then implemented in boulder
for the IMS FE support team ... but in boulder, there was use of
infrared optical modem between the datacenter bldg and the bldg.
with the ISM FE support team ... some past threads:
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/99.html#137 Mainframe emulation
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001e.html#72 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
the boulder installation presented some additional challenge. The
transmitters/receivers were mounted on poles on top of the bldgs. the
normal movement of the sun across the sky would cause uneven heating
and uneven expansion/contraction of the bldgs during the course of the
day ... sufficient to throw the beams out of alignment.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 11 Mar 2004 15:00:29 GMT
IBM-MAIN@ibm-main.isham-research.com (Phil Payne) writes:
Ummmm, I think I'd have to disagree. CRBE (Conversational Remote
Batch Entry) and CRJE (Conversational Remove Job Entry) both
preceded the introduction of TSO.
are you referring to a specific CRBE/CRJE implementation?
when an undergraduate I had put (TTY & 2741) terminal support into
HASP ... and facility that supported the CMS editor syntax (not the
actual code since i had to write it from scratch to fit it into HASP).
this i considered to have much better response and useability than the
later TSO implementation (of course i could be a little
biased). although I could "edit, asm, and test" all day long ... it
was still basically a conversational front-end to a batch system
... with a little slight of hand monitor. This was running on a MVT18
system on 360/65. I don't think that anybody would confuse my
conversational HASP hack or TSO with any kind of competitive
time-sharing offering.
i had purposefully used "glorified conversational job entry" in lower
case to differentiate it from specific CRBE/CRJE implementations that
other people might be familiar with.
misc. previous posts in this thread:
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#27 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#28 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#30 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: separate MMU chips
Newsgroups: comp.arch
Date: Thu, 11 Mar 2004 15:21:04 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
[*] If I recall, MVC with overlapping source and target that took a
page miss half way through was one such. I vaguely remember some
reference to a change to the microcode to touch both the first and
last bytes before starting the copy to reduce this effect. But I
could be imagining the situation.
possibly a m'code bug that was the reverse situation?
One of the reasons that the 360/67 had to have a minimum of 8 TLB
entries was that an "execute" of an MVC instruction:
• "execute" instruction could cross a page boundary
• MVC instruction could cross a page boundary
• source could cross a page boundary
• destination could cross a page boundary
which would require resolving a maximum of eight virtual page
addresses before starting the operation.
even in non-virtual-memory mode .... a MVC instruction is required to
validate starting/ending locations of both source and destination
before beginning the operation (i.e. 360 storage protection with
destination crossing 2k boundary).
all 360 instructions were required to do this. it wasn't until the
introduction of the long instructions with 370 that the requirement
was somewhat relaxed ... i.e. the long instructions were defined as if
they performed a byte at a time.
This gave rise to a microcode bug in the 370/125 implementation of
long instructions which used the old 360 rules ... checking start &
ending locations of source & destination before starting the operation
(instead of checking at each byte). VM/370 at boot had used the move
long instruction (MVCL) to both clear memory and test for size of real
storage ... when the MVCL instruction interrupted it would have
cleared all of available real storage and the registers would indicate
the last available real storage location. The 370/125 microcode bug
resulted in the instruction not even starting operation
... effectively appearing to vm/370 boot as if there was no real
storage.
misc. past refs:
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2003j.html#27 A Dark Day
http://www.garlic.com/~lynn/2004b.html#26 determining memory size
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Playing games in mainframe
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 12 Mar 2004 17:10:52 -0700
steve_mark_waugh@ibm-main.hotmail.com (Stephen Waugh) writes:
Are there any games written in REXX that could be downloaded from
the internet? If anyof you has one, please pass me the code.
long ago and far away, the person that wrote REX(X), wrote a multiuser
spacewar game using IUCV