List of Archived Posts

2006 Newsgroup Postings (02/01 - 02/12)

IBM 610 workstation computer

IBM 610 workstation computer

Mount a tape

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

Mount a tape

Free to good home: IBM RT UNIX

Is there a workaround for Thunderbird in a corporate environment?

IBM 3090/VM Humor

IBM 610 workstation computer

IBM 610 workstation computer

Change in computers as a hobbiest

Expanded Storage

{SPAM?} Re: Expanded Storage

{SPAM?} Re: Expanded Storage

{SPAM?} Re: Expanded Storage

{SPAM?} Re: Expanded Storage

IBM 3090/VM Humor

Seeking Info on XDS Sigma 7 APL

IBM 3090/VM Humor

Would multi-core replace SMPs?

Seeking Info on XDS Sigma 7 APL

Seeking Info on XDS Sigma 7 APL

Multiple address spaces

Multiple address spaces

IBM 610 workstation computer

Multiple address spaces

IBM 610 workstation computer

Empires and Imperialism

Seeking Info on XDS Sigma 7 APL

Multiple address spaces

IBM 610 workstation computer

Multiple address spaces

Seeking Info on XDS Sigma 7 APL

Multiple address spaces

X.509 and ssh

blast from the past ... macrocode

another blast from the past

another blast from the past ... VAMPS

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Wed, 01 Feb 2006 12:33:01 -0700

greymaus writes:

The vision is of holding a tiger by the tail. There was a thing on TV
about the Taiwanese electronics industry, a guy was interviewed that
worked at making moulds (forms) for plastic parts. He had been working
at one project for over two days nonstop to get it finished on time.
What can you say?... Also your message explains how so much stuff is
sold as remainders of lines.

when i was undergraduate, i would regularly get the machine room to
myself from 8am sat. until 8am monday ... and would work 48hrs
non-stop and then go off to class (sometimes nearly 60hr day).

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Thu, 02 Feb 2006 09:34:43 -0700

greymaus writes:

And then you grew up! What machine?

misc. past posts:
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/93.html#17 unit record & other controllers
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
http://www.garlic.com/~lynn/97.html#21 IBM 1401's claim to fame
http://www.garlic.com/~lynn/98.html#9 ** Old Vintage Operating Systems **
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#59 Living legends
http://www.garlic.com/~lynn/99.html#130 early hardware
http://www.garlic.com/~lynn/2000.html#79 Mainframe operating systems
http://www.garlic.com/~lynn/2000c.html#11 IBM 1460
http://www.garlic.com/~lynn/2000d.html#34 Assembly language formatting on IBM systems
http://www.garlic.com/~lynn/2001.html#11 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001b.html#22 HELP
http://www.garlic.com/~lynn/2001b.html#27 HELP
http://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2002b.html#13 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#15 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002f.html#48 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002o.html#19 The Hitchhiker's Guide to the Mainframe
http://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2003h.html#30 Hardware support of "new" instructions
http://www.garlic.com/~lynn/2003i.html#8 A Dark Day
http://www.garlic.com/~lynn/2003i.html#12 Which monitor for  Fujitsu Micro 16s?
http://www.garlic.com/~lynn/2003i.html#51 Oldest running software
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
http://www.garlic.com/~lynn/2004f.html#49 can a program be run withour main memory?
http://www.garlic.com/~lynn/2004g.html#39 spool
http://www.garlic.com/~lynn/2004k.html#40 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004q.html#66 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2005c.html#54 12-2-9 REP & 47F0
http://www.garlic.com/~lynn/2005g.html#52 Software for IBM 360/30
http://www.garlic.com/~lynn/2005l.html#34 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005n.html#3 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3

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

Mount a tape

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mount a tape
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 02 Feb 2006 15:06:19 -0700

swiegand@ibm-main.lst (Stephen M. Wiegand) writes:

I was trying to stay out of this thread because I thought it was a
homework or some other such question but having seen some of the
responses, I have an urgent need to add my thoughts.  When I first
saw the question, I was thinking the person wanted to know how to
physically mount a tape.  After all he didn't ask about JCL or a
program or a console command.  That got me to thinking about how I
learned back in the barely light years.  (They didn't have computers
in the dark ages).  In my very first programming job we had an IBM
370-?? CPU with DOS and Power operating systems.  We didn't use tape
much in our shop but we had to get a drive because IBM in those days
sent everything out on tape.  So we had some unit (don't remember
the numerals) that had two spindles and a sliding glass door.  It
definitely had a vacuum load because you could hear it sucking when
you readied a tape.  Having never been exposed to this hardware in
college and having to come in on weekends to load operating system
and other IBM software without the presence of an operator, I had to
learn how to "mount a tape".  I remember you had to press a button
to open the doors, mount the tape reel on a spindle or hub (whatever
you call that thingy in the middle), thread the tape across the
heads and through another path.  Press another button and the doors
closed, the vacuum sucked the tape up the rest of the way and onto
the take-up reel and readied the tape at the first readable block,
which might be the label if it was a labeled tape.

my first programming job was to implement a 360/30 version of 1401
mpio (rather than running 360/30 in 1401 emulation mode). the 1401 was
used for unit record<->tape frontend for 709; loaded cards on tape,
physically moved tape from 1401 drive to 709 drive, 709 ran outputing
to new tape, took that tape from 709 drive back to 1401 tape drive and
produced whatever print & punch output.

tapes came in canisters which had to be opened, reel of tape removed.
tape drives had full sized swing open doors that you manually opened;
you had to mount the reel and then manually feed the tape to the tape-up
reel (somewhat similar to the old audio tape open reel).

later they had those straps that just wrapped around the reel of tape,
instead of canisters that completely enclosed the reel.

later still you got those straps that didn't have to be removed, there
was new drives that would open the strap a smidgen and feed the tape
from the reel.

for the 360/30 mpio version i got to design and implement my own
monitor, interrupt handlers, device drivers, error recovery, storage
allocation, multitasking, etc. i could concurrently handle card to one
tape ... while concurrently processing another tape to printer.

recent posting with lots of references to MPIO activity:
http://www.garlic.com/~lynn/2006b.html#0
http://www.garlic.com/~lynn/2006b.html#1

much later i had implemented a backup/archive system that i deployed on
a number of internal systems (originally, mostly used 6250bpi tape).
eventually it made it out the door as workstation datasave, which
subsequently morphed into adsm and is now called tsm.
http://www.garlic.com/~lynn/submain.html#backup

the 360 green card had tape ccws. several years ago, an ios3270 of the
green card was done (ios3270 was a full-screen menu app on cms from the
70s, lots of people saw it as the service processor menus on the 3090;
the 3090 service processor was a pair of 4361s running a hihgly
customized version of vm370 release 6 with all the menu screens in
ios3270). the 360/67 "blue" card also had sense bit definitions for a
number of devices. I had added some of that sense information (including
tape) to the ios3270 gcard.
recently i did a rough cut at translating the ios3270 gcard to html
http://www.garlic.com/~lynn/gcard.html
mag tape ccws:
http://www.garlic.com/~lynn/gcard.html#25
sense data
http://www.garlic.com/~lynn/gcard.html#17

recent gcard ref:
http://www.garlic.com/~lynn/2006.html#0 EREP, sense ... manual

picture of 2311 7mbyte disk drvies in the forground and a couple 2400
tape drives in the left middle (picture also drum in upper middle
behind tape drives):
http://ftp.columbia.edu/acis/history/2311.html

the whole front of the tape drive was a door that opened. tape reel was
mounted on the hub and feed thru the heads and onto the take-up reel.
the reels had small finger indented finger depression ... you
would wind the tape around the take up reel once (until it had
overlapped and friction would keep it from slipping) and then you
would spin the take-up reel several times (index finger in the finger
depression) ... getting the tape position past the small strip of
reflective foil that marked the start of tape. you closed the door and
hit rewind/ready. that would spin tape from the take-up reel until the
heads sensed the reflective foil (if you didn't get the tape spun
manually past the reflective foil, all the tape would come off the
take-up reel and you would have to feed it again from the start).

the hub in the middle of the tape reel had a handle that pull out that
released and/or locked the tape reel on the hub.

earlier 701 tape drive
http://ftp.columbia.edu/acis/history/701-tape.html

later 3420 tape drive
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3420.html

the mounted tape is on the right with the (white) auto-strap still
around the reel. this had a small clasp that the tape drive opened and
pulled the tape thru the opening and fed the tape under the heads and
onto the take-up reel.

another picture of 3420 tape drive (on ebay, picture isn't likely to be
around for long)
http://cgi.ebay.com/Vintage-LIKE-NEW-IBM-3420-8-MAGNETIC-TAPE-DRIVE-Rare_W0QQitemZ5217468698QQcategoryZ74946QQcmdZViewItem

here is a closeup of the white strap around a tape reel with the clasp
on the left that the drive could automatically be opened and feed the
tape.
http://ftp.columbia.edu/acis/history/media.html

picture of 360/30 with tape drives on the left and 2314 disks on the right.
http://ed-thelen.org/comp-hist/vs-ibm-360-30.jpg

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Thu, 02 Feb 2006 15:37:55 -0700

hancock4 writes:

I think he said when he was an undergraduate, so it was in college, not
in high school, a bit older than a teenager.

when i started my first undergraduate student programing job, (got to
design and implement my own monitor, interrupt handlers, device
drivers, pull 48hr weekend shift, have the whole machine room to
myself, and then go to class, etc) a little more detail recently
x-posted from ibm-main n.g.
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape

i was still a teenager.

i had worked construction in high-school and the previous summer had
been foreman on construction crew ... recent posting making
reference (among a number of things).
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs

the particular construction project with passing mention in the above
posting got behind schedule because of weather problems and the last
6-8 weeks we pulled 85hr weeks (time and half for 41-60hr and double
time for over 60). the programming job was somewhat more interesting
(designing and implementing my own system, etc, and a single 48hr
shift was different than 85hr work week but student programmer didn't
pay anywhere near as well).

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Thu, 02 Feb 2006 16:07:07 -0700

hancock4 writes:

Some computers had Fort Knox level security, but definitely not all,
some were rather lax.  I merely walked into my summer employer's
computer room (I wasn't in computers then) and asked to use the
phone, I was directed to the one right at the CPU console.  I
could've came in off the street, I think I was only 17 at the time.

re:
http://www.garlic.com/~lynn/2006b.html#3 IBM 610 workstation computer

i started out taking intro to fortran 2hr credit class, half-way thru
the semester i was trying to write my own fortran program to calculate
orbital positions. also about that time they got a 360/30 to replace
the 1401 ... which then ran mostly in 1401 emulation mode ... ref
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape

they got used to seeing me around ... and were trying to figure out
what this new 360 stuff was ... so eventually they turned a lot of it
over to me to figure out. I got my own key to the machine room (which
was kept locked at all times). the univ. normally turned everything
off by 8am sat. and nothing officially was scheduled until 8am monday.
I could come in a little before 8am sat. before the friday night 3rd
shift left .. and then have the whole machine room to myself for the
weekend. since i was doing an application that did a lot of tape and
unit record stuff ... i also had to learn how to be my own operater
... not only mounting tapes ... but doing the regular 8hr shift
cleaning of tape drives, card punch/readers, printers, etc.

the 360/30 was supposedly interim getting ready for 360/67 (which was
going to replace the 709/1401 setup) running tss/360. tss/360 was
never succesfully deployed (at the univ). although some of the ibm'ers
would interrupt parts of my weekends (after the 360/67 came in for
weekend tss/360 testing). however, ibmers never worked more than a
single 8hr shift (or rarely two shifts) on the weekends ... so i would
still have most of the 48hr period to myself.

lots of postings about getting to play w/computers as undergraduate:
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/97.html#7 Did 1401 have time?
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#33 ... cics ... from posting from another list
http://www.garlic.com/~lynn/99.html#44 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/99.html#95 Early interupts on mainframes
http://www.garlic.com/~lynn/2000.html#30 Computer of the century
http://www.garlic.com/~lynn/2000c.html#42 Domainatrix - the final word
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001c.html#36 How Commercial-Off-The-Shelf Systems make society vulnerable
http://www.garlic.com/~lynn/2001d.html#23 why the machine word size is in radix 8??
http://www.garlic.com/~lynn/2001d.html#48 VTOC position
http://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984??
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/2001f.html#78 HMC . . . does anyone out there like it ?
http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's  supercomputers?
http://www.garlic.com/~lynn/2001g.html#52 Compaq kills Alpha
http://www.garlic.com/~lynn/2001h.html#12 checking some myths.
http://www.garlic.com/~lynn/2001h.html#60 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
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#34 Processor Modes
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002b.html#13 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#15 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#45 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/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
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/2002l.html#29 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
http://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002p.html#62 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#5 Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003k.html#8 z VM 4.3
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#55 S/360 IPL from 7 track tape
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2003n.html#50 Call-gate-like mechanism
http://www.garlic.com/~lynn/2003p.html#9 virtual-machine theory
http://www.garlic.com/~lynn/2003p.html#23 1960s images of IBM 360 mainframes
http://www.garlic.com/~lynn/2004.html#48 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004b.html#47 new to mainframe asm
http://www.garlic.com/~lynn/2004b.html#53 origin of the UNIX dd command
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
http://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#43 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004m.html#26 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#36 Multi-processor timing issue
http://www.garlic.com/~lynn/2004n.html#3 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#23 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#2 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#56 1401-S, 1470 "last gasp" computers?
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
http://www.garlic.com/~lynn/2005j.html#28 NASA Discovers Space Spies From the 60's
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005k.html#8 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005k.html#14 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005k.html#38 Determining processor status without IPIs
http://www.garlic.com/~lynn/2005k.html#42 wheeler scheduler and hpo
http://www.garlic.com/~lynn/2005k.html#50 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#23 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#24 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005o.html#12 30 Years and still counting
http://www.garlic.com/~lynn/2005o.html#25 auto reIPL
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2006.html#2 Average Seek times are pretty confusing
http://www.garlic.com/~lynn/2006.html#7 EREP , sense ... manual
http://www.garlic.com/~lynn/2006.html#15 S/360
http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#40 All Good Things

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Thu, 02 Feb 2006 17:43:51 -0700

hancock4 writes:

I don't know the percentage of programming done on the early machines
(ie 709x series) in assembler vs. Fortran, but I suspect assembler was
the main language for the reasons above.  After S/360, with its more
sophisticated operating system, disk drivers, and more memory, Fortran
was more widely.  Also, there were more college courses in Fortran by
that time.

on the university's 709, the vast majority of programming was fortran
and cobol. classes were all fortran, and most of the departments did
fortran ... math, business statistics, biometric statistics, soc &
psyc stats, etc. admin had cobol jobs (there may have been some univ.
assembler 709 programs, but i wasn't aware of any). the 709 ran
ibsys and almost everything was tape-to-tape ... using 1401 as
unit record front end i.e. tapes were manually moved between 709
drives and 1401 drives as mentioned in this tape related x-posting
from ibm-main n.g.
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape

later on the 360/67 (mostly running 360/65, os/360), most of the
student stuff had moved to watfor fortran ... while departments were
mostly fortg, (fortran) scientific subroutine lib., etc. admin had
converted their 709 cobol to 360 cobol.

one day i was wandering thru the machine room and everything had come
to a halt and people were standing around waiting. apparently an
important admin daily cobol job had been run and produced some
different ending results. i had never paid any attention before, but i
was told that it was a 407 plug-board job that had been converted to
709 cobol (emulating 407 operation) and produced emulation of 407
sense switch settings (at the end of the run) on the printer. this had
then been ported from 709 cobol to 360 cobol.  the responsible admin
person didn't know what to make of the unanticipated and different
results. after about an hour, it was decided to repeat the run and if
the (printed) 407 switch settings came out the same ... then they
would assume everything was ok.

past postings mentioning ibsys and/or 407s:
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#9 ** Old Vintage Operating Systems **
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/99.html#137 Mainframe emulation
http://www.garlic.com/~lynn/2000.html#19 Computer of the century
http://www.garlic.com/~lynn/2000.html#20 Computer of the century
http://www.garlic.com/~lynn/2000.html#55 OS/360 JCL: The DD statement and DCBs
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#67 Building so big it generates own weather?
http://www.garlic.com/~lynn/2001b.html#27 HELP
http://www.garlic.com/~lynn/2001f.html#5 Emulation (was Re: Object code (was: Source code - couldn't resist compiling it :-))
http://www.garlic.com/~lynn/2001g.html#22 Golden Era of Compilers
http://www.garlic.com/~lynn/2001i.html#33 Waterloo Interpreters (was Re: RAX (was RE: IBM OS Timeline?))
http://www.garlic.com/~lynn/2001m.html#52 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002.html#49 OT Friday reminiscences
http://www.garlic.com/~lynn/2002d.html#21 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#53 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#53 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002q.html#39 HASP:
http://www.garlic.com/~lynn/2003j.html#23 A Dark Day
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2003n.html#42 When nerds were nerds
http://www.garlic.com/~lynn/2004.html#48 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004b.html#53 origin of the UNIX dd command
http://www.garlic.com/~lynn/2004d.html#44 who were the original fortran installations?
http://www.garlic.com/~lynn/2004d.html#59 Happy Birthday Mainframe
http://www.garlic.com/~lynn/2004f.html#49 can a program be run withour main memory?
http://www.garlic.com/~lynn/2005e.html#29 Using the Cache to Change the Width of Memory
http://www.garlic.com/~lynn/2005g.html#56 Software for IBM 360/30
http://www.garlic.com/~lynn/2005n.html#3 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Thu, 02 Feb 2006 18:03:58 -0700

Anne & Lynn Wheeler writes:

on the university's 709, the vast majority of programming was fortran
and cobol. classes were all fortran, and most of the departments did
fortran ... math, business statistics, biometric statistics, soc &
psyc stats, etc. admin had cobol jobs (there may have been some univ.
assembler 709 programs, but i wasn't aware of any). the 709 ran
ibsys and almost everything was tape-to-tape ... using 1401 as
unit record front end i.e. tapes were manually moved between 709
drives and 1401 drives as mentioned in this tape related x-posting
from ibm-main n.g.
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape

some years later, i was at the san jose research center ...  backus'
office was several doors away ... although he rarely came in.  he
worked from home a lot.

a few old posts that started out trying to track down original fortran
distribution:
http://www.garlic.com/~lynn/2004d.html#24 who were the original fortran installations?
http://www.garlic.com/~lynn/2004d.html#27 who were the original fortran installations?
http://www.garlic.com/~lynn/2004d.html#44 who were the original fortran installations?
http://www.garlic.com/~lynn/2004d.html#45 who were the original fortran installations?

since boeing was one of the original installations, i had tried to track
down some of the people that i had known at boeing; minor recent ref.
to bcs:
http://www.garlic.com/~lynn/2006.html#40 All Good Things

One of the people that I had worked with at that time, I actually was
able to track down, he had retired and still lived in Seattle and had
some amount of old/early Fortran stuff in boxes.

for some drift, codd's office was floor above and not too far away.
this was during the days of the original relational/sql work and
system/r ... minor refs:
http://www.garlic.com/~lynn/submain.html#systemr

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

Mount a tape

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mount a tape
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Feb 2006 08:46:20 -0700

Louis Krupp wrote:

Don't forget the write ring.  Leave it off when you intended to write to
the tape, and you had to unload and reload the tape all over again.
Leave it on when you didn't mean to, and the tape might get purged by
mistake.

i had some stuff from the late 60s and early 70s replicated on three
different tapes (over the years copying from 800bpi to 1600bpi to
6250bpi tape) ... but all in the same datacenter library in the mid-80s.
it included some stuff on periodically monitoring system activity and
using the information for dynamic adaptive feedback control. i had
created dynamic adaptive feedback scheduler in the 60s as an
undergraduate that included fairshare as a default policy ... that was
shipped in cp67. much of the code was dropped in the morph from cp67 to
vm370. however, i was given a chance to re-introduce it with the
resource manager (shipped spring 1976).

for a little more drift, the resource manager was selected to be the
guinea pig for priced kernel software. with the unbundling announcement
on 6/23/69, application software started being charged for ... but
kernel software was still shipped free (under the justification that it
was needed to run the hardware ... aka bundled). by the mid-70s, various
factors (like 370 clones) were contributing to pressure to pricing
kernel software. i got to spend six months or so on and off with
business and pricing people on policies for pricing kernel software.
misc. past bundling/unbundling posts
http://www.garlic.com/~lynn/submain.html#unbundle

anyway, in mid-80s, some people from corporate came looking for
early examples of periodic monitoring of system performance activity ...
having to do with some litigation or patent issue. i went to retrieve
the code and found that all three tapes had been written over.
apparently there was some problem in the datacenter with operators
randomly selecting tapes to be mounted as scratch (i.e. the ring was
inserted for a request to mount a scratch tape for writing).

recent post reproducing part of the resource manager "blue" announcement
letter (actually beige at this time, but still commonly referred to as
"blue" ... i don't actually still have a paper copy but was presented an
engraved plaque of the announcement letter that has survived).
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux

Free to good home: IBM RT UNIX

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Free to good home: IBM RT UNIX
Newsgroups: comp.sys.ibm.pc.rt,comp.unix.aix,alt.folklore.computers
Date: Sat, 04 Feb 2006 08:40:07 -0700

Tux Wonder-Dog writes:

I have a _dream_!  (Okay, to bring it down to earth, a wish that IBM
would consider old operating systems and tools, etc, including their
source code, as both fodder for future students and as an
inexpensive means to bring people up to speed on IBM equipment,
which are no longer the first-in-line for people to use or
experience in training.  And AOS features in this as an example of
how IBM took from the Unix community an OS with apparently few of
the IBM-specific features that might conceivably prevent IBM from
releasing it plus source under the original BSD license.)

???

note that old operating systems and source use to be freely available.
both cp67 and vm370 were free and shipped with source and source
maint. some of this may be picked up with respect to hercules
activity.

the big issue was the gov. (and other) litigation that resulted in the
6/23/69 unbundling announced when application software started be
priced/charged. kernel software was still bundled (and free) under the
policy that it was required to operate the hardware.

i had made extensive cp67 source modifications as undergraduate and a
lot of it was picked up and shipped in the product (dynamic adaptive
scheduling policies, fairshare policy, working set like operationg,
page replacement stuff, lots of pathlength optimization, etc). some
amount of that was dropped in the morph to vm370. some amount of
customer advocacy (in share user group organization and other places)
resulted in being able to package and (re-)release some of it as the
resource manager (in 1976). however, resource manager was tagged as
the guinea pig for pricing kernel software (somewhat motivated by
clone 370 processors being able to pickup free kernel). misc. past
unbundling related posts
http://www.garlic.com/~lynn/submain.html#unbundle

the advent of clone processors continued pressure on software and in
the early 80s you started to see the "OCO" wars (object code only)
where there was push to not only to charge for (unbundled) software
but also to stop shipping source.

also in the early 80s, ibm formed (academic) ACIS organization ... and
initially provided with $300m to give away to educational institutions
for computer related stuff. CMU activity got $50m (mach, camelot,
andrew, etc). MIT (project athena) got $25m (project athena also got
matching $25m from dec; project athena saw things like X-windows,
kerberos, etc). CSNET and later NSFNET backbone got some amount.
Independent of CSNET (& NSFNET) there was a lot poured into BITNET
(and EARN in europe). misc. bitnet & earn posts
http://www.garlic.com/~lynn/subnetwork.html#bitnet

minor specific csnet, nsfnet refs:
http://www.garlic.com/~lynn/rfcietf.htm#history
http://www.garlic.com/~lynn/internet.htm#nsfnet
http://www.garlic.com/~lynn/internet.htm#0

ACIS group was also responsible for doing BSD-based AOS for PC/RT.
The ACIS also took LOCUS (another unix-alike from UCLA, i don't know
how much of the initial $300m, acis may have provided to ucla or
Berkeley) and it was turned into AIX/370 (later aix/esa) and AIX/PS2
products.

A lot of the various IBM funded activities ... later fed into OSF
(open software foundation) for stuff like DCE (distributed computing
environment) which drew on mach, andrew and locus, etc work. couple
random osf (open software foundation) refs:
http://www.auditmypc.com/acronym/OSF.asp
http://en.wikipedia.org/wiki/Open_Software_Foundation
http://www.opengroup.org/dce/

note that cmu's mach also shows up in other places like the basis for
the (current) apple operating system. in the middle of our doing
ha/cmp
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/subtopic.html#hacmp
the executive we reported to, moved over to head up somerset ... the
apple, motorola, ibm, etc ... effort to do a single-chip version
of rios/801/power ... somerset turned out the power/pc chips ...
used by apple and for some number of other things.

i've joked in the past about ibm paying three times for transarc work
...  the initial $50m grant to cmu, the initial investment when
transarc was spun off from cmu, and then when they bought transarc
outright.

in the late 70s there had been a big push to consolidated a wide
variety of internal microprocessors to 801 risc. by the early 80s, the
primary surviving was the office products effort with ROMP for
displaywriter replacement using pl.8 and cpr. when the displaywriter
follow-on was killed, somebody observed that a lot of hardware vendors
were turning out unix workstation systems with much reduced effort
(doing a unix port). it was decided to retarget romp to the unix
workstation market and the company that had taken at&t unix and turned
out pc/ix (for the ibm/pc) was contracted to do a similar port for
romp. this became the pc/rt (and the aix unix for the pc/rt ... as
opposed to various other AIXs like aix/370 and aix/ps2 that came from
other origins). misc. romp, rios, 801, power, posts
http://www.garlic.com/~lynn/subtopic.html#801

the pc/rt was also the target for the bsd-based AOS effort. it had
initially started out as doing a port to 370. that got side-tracked to
the pc/rt. however, essentially the same group also did the ucla locus
stuff for aix/370 and aix/ps2. I had been doing some stuff for getting
a C-language front end to the 370 pascal compiler. in the middle of
this, the person left and joined metaware in santa cruz. when the aos
for 370 group started up, i talked them into working with metaware for
a c compiler for the port. when aos got retargeted to the pc/rt they
retained the use of the metaware compiler for the effort.

random past posts mentioing metaware:
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002q.html#19 Beyond 8+3
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2004d.html#71 What terminology reflects the "first" computer language ?
http://www.garlic.com/~lynn/2004f.html#42 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#61 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005b.html#14 something like a CTC on a PC
http://www.garlic.com/~lynn/2005e.html#0 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#1 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal of R&D

misc. past posts mentioning somerset
http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2001g.html#23 IA64 Rocks My World
http://www.garlic.com/~lynn/2001i.html#28 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001j.html#37 Proper ISA lifespan?
http://www.garlic.com/~lynn/2002g.html#12 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#14 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002l.html#37 Computer Architectures
http://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
http://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
http://www.garlic.com/~lynn/2004.html#28 Two subjects: 64-bit OS2/eCs, Innotek Products
http://www.garlic.com/~lynn/2004d.html#1 IBM 360 memory
http://www.garlic.com/~lynn/2004k.html#39 August 23, 1957
http://www.garlic.com/~lynn/2004q.html#36 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#40 Tru64 and the DECSYSTEM 20
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005e.html#7 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#13 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005o.html#37 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#34 logical block addressing

random past posts mentioning acis, locus, etc
http://www.garlic.com/~lynn/98.html#35a Drive letters
http://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs
http://www.garlic.com/~lynn/2000d.html#69 "all-out" vs less aggressive designs
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
http://www.garlic.com/~lynn/2001.html#44 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001f.html#1 Anybody remember the wonderful PC/IX operating system?
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/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2002b.html#36 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002h.html#65 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#54 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002j.html#36 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002n.html#67 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002o.html#40 I found the Olsen Quote
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003h.html#35 UNIX on LINUX on VM/ESA or z/VM
http://www.garlic.com/~lynn/2003h.html#45 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003h.html#53 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"?
http://www.garlic.com/~lynn/2004d.html#57 If you're going to bullshit, eschew moderation
http://www.garlic.com/~lynn/2004d.html#72 ibm mainframe or unix
http://www.garlic.com/~lynn/2004h.html#41 Interesting read about upcoming K9 processors
http://www.garlic.com/~lynn/2004h.html#42 Interesting read about upcoming K9 processors
http://www.garlic.com/~lynn/2004n.html#12 XML: The good, the bad, and the ugly
http://www.garlic.com/~lynn/2004n.html#19 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#20 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://www.garlic.com/~lynn/2004p.html#53 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#61 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
http://www.garlic.com/~lynn/2005f.html#28 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005h.html#5 Single System Image questions
http://www.garlic.com/~lynn/2005j.html#26 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005j.html#30 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005q.html#14 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#49 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2005t.html#19 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#61 DMV systems?

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

Is there a workaround for Thunderbird in a corporate environment?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is there a workaround for Thunderbird in a corporate environment?
Newsgroups: netscape.public.mozilla.general,netscape.public.mozilla.mail-news,netscape.public.mozilla.wishlist
Date: Sat, 04 Feb 2006 09:46:17 -0700

Andrew DeFaria writes:

Hmmm... "We have 5000 logins and we find it much easier to assign
each a nickname and have to remember an additional 5000
nicknames". To use your terms "AND YOU CALL THAT PROGRESS?!?". How
'bout cha refer to them by their given name? If you have LDAP, which
you do in Outlook, then use their proper names. If you want
nicknames then petition the LDAP admin to add the nickname as part
of the name (e.g. "Netwton Kenneth Rogers (dog)".

in the late 70s, i started a small corporate nickname file
... initially with 15,000 entries that i collected from various places
... it grew to over 25,000 before i abandoned the effort (in the early
80s). by that time, the work on online corporate telephone directories
was well along ... which added the ability to have email address
listed. part of the problem was having to constantly come up with
unique nicknames across 25,000-plus people (at the time, well under
ten percent of all employees).

of course, the internal network was larger than the whole
arpanet/internet from just about the beginning until sometime mid-85.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

misc old postings on doing the online corporate telephone
directories (started somewhat in parallel with doing the nickname
file):
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)
http://www.garlic.com/~lynn/2004c.html#0 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
http://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#43 History of performance counters
http://www.garlic.com/~lynn/2005t.html#44 FULIST

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

IBM 3090/VM Humor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3090/VM Humor
Newsgroups: bit.listserv.vmesa-l
Date: Sat, 04 Feb 2006 09:56:12 -0700

Paul Hanrahan writes:

VM was open source before it was cool ! - Paul Hanahan

recent posting on the subject ...
http://www.garlic.com/~lynn/2006b.html#8

various collected postings mentioning unbundling announcement
of 6/23/69 (becuase of gov. and other litigation) and resulting
transition to charging for software
http://www.garlic.com/~lynn/submain.html#unbundle

unbundling initially resulted in charging for application software,
but kernel software was still free (aka bundled, in the theory that it
was required to operate the hardware). the vm370 resource manager
(1976) was chosen as guinea pig for priced kernel software.

... vm was not only open source ... but also source maintenance.  the
original multi-level source update process was done as part of joint
endicott/cambridge project to emulate 370 virtual machines under cp/67
(running on 360/67) ... recent post mentioning effort
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory

misc. old posts mention source update procedure:
http://www.garlic.com/~lynn/99.html#9 IBM S/360
http://www.garlic.com/~lynn/2001e.html#57 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
http://www.garlic.com/~lynn/2001n.html#26 Open Architectures ?
http://www.garlic.com/~lynn/2001n.html#92 "blocking factors" (Was: Tapes)
http://www.garlic.com/~lynn/2002h.html#35 Computers in Science Fiction
http://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
http://www.garlic.com/~lynn/2003.html#27 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#58 Card Columns
http://www.garlic.com/~lynn/2003.html#62 Card Columns
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003e.html#77 unix
http://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003f.html#7 unix
http://www.garlic.com/~lynn/2003k.html#46 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003k.html#47 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004g.html#29 [IBM-MAIN] HERCULES
http://www.garlic.com/~lynn/2004g.html#40 IBM 7094 Emulator - An historic moment?
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#36 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#20 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#15 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#6 What ever happened to Tandem and NonStop OS ?

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Sat, 04 Feb 2006 14:16:04 -0700

blmblm writes:

Recommendation heartily seconded, especially for this group, where
people are more likely than the average techie to understand most of
the humor.  TECO is mentioned!

But, um, isn't the actual title of the essay "Real Programers Don't
Use Pascal"?

real programers and varitions take-offs, previously posted:
http://www.garlic.com/~lynn/2001e.html#31 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2002e.html#39 Why Use *-* ?
http://www.garlic.com/~lynn/2002o.html#69 So I tried this //vm.marist.edu stuff on a slow Sat. night,
http://www.garlic.com/~lynn/2002o.html#72 So I tried this //vm.marist.edu stuff on a slow Sat. night,
http://www.garlic.com/~lynn/2003b.html#58 When/why did "programming" become "software development?"
http://www.garlic.com/~lynn/2003j.html#43 An a.f.c bibliography?
http://www.garlic.com/~lynn/2004b.html#35 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004p.html#24 Systems software versus applications software definitions

... i.e. *real programmers don't eat quiche* and
*real software engineers don't read dumps*

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Sat, 04 Feb 2006 14:40:50 -0700

oh, and for some other random stuff ... an old version of jargon
leaked onto the internet and can be found here:
http://www.212.net/business/jargon.htm

for instance, and entry in the Bs
http://www.212.net/business/jargonb.htm

[backbone]
n. The central nodes of an electronic communication network. The
backbone of IBM's VNET network is managed directly by a corporate
organisation, and in the mid 1980s ran a much-enhanced version of the
RSCS product, known as IPORSCS. The nodes of the backbone, for example
HURBB, are identified by three characters of the location name,
followed by BB (for BackBone). At a time of a major software upgrade
numerous problems occurred, which led to the suggestion that in fact
the BB stands for bit-bucket (q.v.).

...

the internal network was larger than the arpanet/internet from just
about the beginning until around summer of '85. the network was well
along before corporate even was aware of its existance.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

in fact, there was an incident when a networking academic type from
corporate hdqtrs was making some rounds ... and given talks. somebody
explained to him about the internal network and how it worked in a
fully distributed manner w/o need for centralized (and/or corporate)
control.

the individual replied that it couldn't exist ... that it had been
prooved that such an implementation would require a specific minimum
amount of massive resources to implement ... which would have had to
show up as a significant line-item cost at the corporate level. he
personally knew that no such cost line-item had ever shown up in
the corporate financials ... and therefor it couldn't exist. it was
after corporate started getting involved that you started seeing
incidences like the one mentioned in the above reference.

at the time arpanet with approx. 250 nodes, converted to
internetworking protocol on 1/1/83 ... minor reference
http://www.garlc.com/~lynn/internet.htm#0

the internal network was nearing 1000 nodes, which it passed
later that year. minor reference
http://www.garlic.com/~lynn/internet.htm#22

... the internal network ... another item brought to you by the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

externally, bitnet and earn was a university implementation using
the same technology (although the count of bitnet and earn nodes
aren't included in the count of internal network nodes) ....
http://www.garlic.com/~lynn/subnetwork.html#bitnet

minor past reference to the formation of earn (european academic
research network) ... some email from spring of 1984
http://www.garlic.com/~lynn/2001h.html#65

for even more drift, gml was also invented at the science center,
percursor to sgml, html, xml, etc ... misc. collected postings:
http://www.garlic.com/~lynn/submain.html#sgml

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

Change in computers as a hobbiest

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Change in computers as a hobbiest...
Newsgroups: alt.folklore.computers
Date: Sun, 05 Feb 2006 09:23:20 -0700

"David Wade" writes:

3. The Windows/2000 resource kit (not sure about the XP one) include
implementations of Perl and REXX

past postings about doing applications in rexx ... before it was
released to customers ... and when it was still called rex (there was
something about conflict with existing software(?) that necessitated
the renaming).
http://www.garlic.com/~lynn/submain.html#dumprx

from a little later; part of assembly listing from dmsrex source from
1983
http://www.garlic.com/~lynn/2004d.html#26 REXX still going strong after 25 years

there was some recent posting complaining about object rexx not being
available on all platforms ... i think mainframe where it had
originated:
http://www-306.ibm.com/software/awdtools/obj-rexx/

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

Expanded Storage

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Expanded Storage
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 07 Feb 2006 00:21:01 -0700

Rob van der Heij writes:

Yes, in your configuration you should define expanded storage. It's
for providing a hierarchy in storage management as well as a
circumvention to reduce the impact of contention under the bar.
Especially when the total active memory of your Linux server is
getting close to 2G (and unless you do things, eventually the entire
Linux virtual machine main memory will appear active to VM).
25% has been suggested as a starting point, but measurements should
help you determine the right value. The right value depends a lot on
what Linux is doing. And make sure to disable MDC into expanded
storage as I suggested yesterday.

note if you have 16gbytes of expanded store and 16gbytes of regular
storage ... then only stuff in the 16gbytes of regular store and be
used/executed. stuff in expanded store has to be brought into regular
store to be accessed (and something in regular store pushed out
... possibly exchanging places with stuff in expanded store).

if you have 32gbytes of regular store ... then everything in regular
store can be directly used/executed ... w/o being moved around.

expanded store was introduced in 3090 because of memory physical
packaging problem. a lot more electronic memory could be attached cost
effectively to a 3090 than could be physically packaged within the
normal processor execution/access latency requirements.

rather than going to something like numa & sci ... it was packaged
on a special wide bus (with longer latency) and special software
introduced to manage pages. it might be considered akin to electronic
paging drums or controller caches ... but the movement was
singificantly more efficient being done with high-performance
synchronous instruction rather than very expensive asynchronous i/o
handling. as an aside, when 800mbit hippi i/o was attached to 3090 ...
it was crafted into the expanded storage bus using peek/poke semantics
since it was the only interface on the 3090 that was capable of
handling the data rate.

part of the issue was some cache and i/o studies performed by SJC in
the late 70s and and early 80s. a special vm system was built that
efficiently captured all record references (much more efficently than
monitor) and this was deployed on a number of systems in the san jose
area (standard product vm/cms ... but also some number of production
mvs systems running virtually).

the detailed i/o trace information was captured for weeks of data on
different systems. various cache, record, and paging models were built
and run with the actual trace data. for a given, fixed amount of
electronic store, the most efficient use of that electronic store was
a single global system cache ... that divided the same amount of
stored into (partitioned) channel, controller, and/or drive caches was
always less efficient than having a single large global system cache.

this also supports the issue i raised as an undergraduate in the 60s
with the enhancements i had done to cp/67. the original cp/67 had a
very inefficient thrashing controls and replacement algorithm. about
that time, there was some literature published about working set for
controlling thrashing and "local" LRU replacement algorithms. For
cp/67, I implemented a highly efficient global LRU replacment
algorithm and my own variation on working set for thrashing controls.

However, in much the same way that my global LRU replacement algorithm
was much more efficient that local LRU replacement algorithm ...the
I/O cache simulation studies showed that a single global cache was
more efficient that any partitioned cache implementation (given the
same amount of fixed electronic storage).

Somewhat in the same time frame as the electronic cache studies,
(better than ten years after i had done the original global LRU work)
there was a big uproar over a draft stanford phd thesis that involved
global LRU replacement strategies. There was significant pushback on
not granting the stanford phd on the grounds that the global LRU
strategies were in conflict with the local LRU stuff that had been
published in the literature in the late 60s. After much conflicts, the
stanford Phd thesis was finally approved and the person was awarded
their phd.

in any case, back to the original example. if you have 16gbytes of
normal storage and 16gbytes of expanded storage, then there can be a
total of 32gbytes of virtual pages resident in electronic storage, but
only 16gbytes of those virtual pages can be used at any one time.  Any
access to virtual pages in expanded storage (at best) requires moving
a page from expanded to normal and a page from normal to expanded
(exchanging pages).

however, if you configure 32gbytes of normal storage and no expanded
storage ... then you can also have 32gbytes of virtual pages resident
in electronic storage ... but all 32gbytes of virtual pages are
useable directly (no fiddling moving pages back & forth between
expanded storage and normal storage).

the possible exception is if the paging supervisor has some
difficiencies in identifying virtual pages with a variety of activity
levels ... and there is going to be access to more total virtual pages
than real pages (resulting in some real page i/o). reducing real
storage by allocating some to expanded storage can fix some page
management problems by forcing the kernel to more frequently "trim"
what it considers the number of active pages in an address space.  the
downside of this trimming is mitigated by pages being moved
back&forth to expanded storage. with more frequent trimming, the
code might do a better job of deciding which pages go to disk and
which stay in electronic storage some place. the hope is that bad
decisions about what is on disk and what is in memory are reduced and
the better decisions offset both things like more frequent trimming
and also the overhead of the brownian motion of any pages going to
& fro between expanded storage and normal storage.

of course the ideal situation is to not have expanded storage at all
(eliminating the unnecessary overhead of moving pages back &
forth).  and simply do a much more sophisticated job of managing all
the pages in a single global storage.

for some additional topic drift, a side effect of the i/o record trace
work was that it was noticed that there was daily, weekly and monthly
cycles ... where collections of data that wasn't normally being used
on a constant basis would have clustered bursty use. some of this
later showed up in places like adms (now tsm) having to do with
migration of clusters of data (that was used together) as part of a
"container". past collected postings on having done the internal
backup system that eventually morphed into workstation datasave
product and then into adsm (and since renamed tsm).
http://www.garlic.com/~lynn/submain.html#backup

past mention of the detailed i/o cache work:
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/99.html#105 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/2003g.html#55 Advantages of multiple cores on single chip
http://www.garlic.com/~lynn/2003n.html#33 Cray to commercialize Red Storm
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004i.html#0 Hard disk architecture: are outer cylinders still faster than
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2005.html#2 Athlon cache question
http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#13 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#55 54 Processors?
http://www.garlic.com/~lynn/2005n.html#23 Code density and performance?

past mention of the stanford phd global LRU work:
http://www.garlic.com/~lynn/98.html#2 CP-67 (was IBM 360 DOS (was Is Win95 without DOS...))
http://www.garlic.com/~lynn/99.html#18 Old Computers
http://www.garlic.com/~lynn/2001c.html#10 Memory management - Page replacement
http://www.garlic.com/~lynn/2002c.html#16 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002k.html#63 OT (sort-of) - Does it take math skills to do data processing ?
http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#55 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#0 Alpha performance, why?
http://www.garlic.com/~lynn/2003k.html#8 z VM 4.3
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2004.html#25 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005n.html#23 Code density and performance?

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

{SPAM?} Re: Expanded Storage

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: {SPAM?} Re: Expanded Storage
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 07 Feb 2006 10:30:36 -0700

Barton Robinson writes:

The real reason for ensuring a hierarchy of storage in z/VM
is to meet the objective of paging less to DASD.

The page stealing algorithm used to take pages from main storage
is not as efficient as the LRU algorithm for moving pages from
Expanded Storage.

Memory constrained systems found that their external paging rate
dropped when they converted some real storage to expanded.
The stealing algorithm steals a lot of the wrong pages, often
taking needed pages and moving them to dasd. bad.

Sure moving pages back and forth between expanded and real cost
CPU - but paging to disk is orders of magnitude worse.

that was one of the issues that happened in the initial morph from
cp67 to vm370. i had introduced global LRU into cp67 as an
undergraudate.

in the morph from cp67 to vm370, they severely perverted the global
LRU implementation (beside changing the dispatching algorithm and
other things). the morph to vm370 introduced a threaded list of all
real pages (as opposed to real storage index table). in theory the
threaded list was suppose to approx the real storage index table
... however, at queue transitions ... all pages for a specific address
space was collected and put on a flush list. if the virtual machine
re-entered queue ... any pages from the flush list were collected and
put back on the "in-q" list. the result was that the ordering that
pages were examined for stealing tended to have a fifo ordering with
most pages for the same virtual machine all clustered together.

the original global LRU implementation was based on having a
relatively uniform time between examining pages; aka a page was
examined and had its page reference bit reset. then all the other
pages in real storage was examined before that page was examined
again. this was uniformly true for all pages in real storage.  the
only change was that if the demand for real storage increased, the
time it took to cycle around all real pages decreased ... but
decreased relatively uniformly for all pages.

in any case, the list approached introduced in the morph from cp67 to
vm370 would drastically and constantly reorder how pages were
examined. there was an implicit feature of LRU algorithms (local or
global) that the examination process be uniform for all pages. the
list manipulation totally invalidated an implicit feature of LRU
implementation ... and while it appeared to still examine and reset
reference bits ... it was no longer approx. true LRU (either global or
local) ... and the number of "bad" decisions went way up.

this was "fixed" when the resource manager was shipped ... and the
code put back like I had originally done in cp67 ... and restored
having true LRU. now the resource manager was still a straight clock
(as defined later in the stanford PHD thesis). basically the way i had
implemented clock had a bunch of implicit charactierstics that had a
drastically reduced the pathlength implementation ... however that
made a lot of things about the implementation "implicit" ... there not
being necessarily an obvious correlation between the careful way that
pages were examined and how it preserved faithful implementation of
LRU.

i had somewhat similar argument with the people putting virtual memory
support into mvt for vs2 (first svs and then mvs). they observed if
they "stole" non-changed pages before "stealing" changed pages (while
still cycling examining and reseting reference bits corresponding to
some supposedly LRU paradigm) ... they could be more efficient. No
matter how hard i argued against doing it (that it violated
fundamental principles of LRU theory) ... they still insisted. so well
into mvs (3.8 or later) ... somebody finally realized that they were
stealing high-use linkpack (shared executable) instruction/non-changed
pages before stealing much lower used, private data pages. another
example if you are going to violate some fundamental principles of the
implementation ... you no longer really had an LRU implementation.

there was a side issue. shortly after joining the science center,
http://www.garlic.com/~lynn/subtopic.html#545tech
i discovered another variation (although this was not deployed
in the resource manager). basically it involved two observations

1) the usefullness of the history information degrades over time.
implicit in LRU is that if a page has been referenced ... it is more
likely to be used in the future than a page that hasn't been
referenced. since there is only a single bit, all you can determine is
that the page was referenced at some point since it was reset.  if it
is taking a long time between examinations ... some bits may have a
lot more meaning than other bits ... but it isn't determinable. in
this time frame, the guys on the 5th floor also published an article
about having multiple reference bits ... and instead of a straight
reset operations ... it became a one-bit shift operation (with zero
being introduced in the nearest bit). their article was performance
effects on using one, two, three, four, etc bits.

2) LRU is based on applications actually following references based on
LRU ... that if a page has been recently used ... it is more likely to
be used in the near future than pages that haven't been recently used.
However, there are (sometimes pathelogical) cases where that isn't
true. one case that can crop up is when you have a LRU implementation
running under an LRU implementation (the 2nd level can be a virtual
machine doing its own LRU page approx or a database system that is
managing a cache of records using an LRU-like implementation). So I
invented this slight of hand implementation ... it looked and tasted
almost exactly like my standard global LRU implementation except it
had the characteristic that in situations when LRU would nominal
perform well, it approximated LRU ... but in situations when LRU was
not a good solution, it magically was doing random replacement
selection. It was hard to understand this ... because the code still
cycled around resetting bits ... and it was a true slight of hand that
would result in it selecting based on LRU or random (you had to really
understand some very intricate implicit relationship behind code
implementation and the way each instruction related to true LRU
implemenation).

the science center was doing a lot of performance work including lots
of detailed traces and modeling ... both event-based model and
analytical models. this included a lot of stuff that today
is taken for granted ... including the early foundation for
capacity planning. some past collected posts on performance work
http://www.garlic.com/~lynn/submain.html#bench

this included what was eventually made available on HONE as the
performance predictor ... an APL analytical model ... SE and salesmen
could get on HONE ... feed in customer performance, configuration and
workload information and ask "what-if" questions about changing
configuration and/or workload.
http://www.garlic.com/~lynn/subtopic.html#hone

in any case, there was a detailed virtual memory and page replacement
model. we got exact page reference traces and fed it into the model
simulating lots of different page replacement algorithms. for one, the
model had a true, exact LRU implementation, as well as various
operating system global LRU approximation implementations, local LRU
implementations, etc. It turns out that the modeling also showed up
that global LRU was better than local LRU ... and that "true" LRU
tended to be 5-15 percent better than global LRU approximation.
However, the magic, slight-of-hand implementation tended to be 5-10
percent bettern than true LRU. It turned out that the slight-of-hand
implementation was magically changing from LRU approximation
replacement to random replacement in situations where LRU didn't apply
(i.e. the assumptions about least recently used pages being the most
likely next to be used wasn't holding true). So in the domain
environment where LRU tended to hold true, the code tended to approx
LRU (but not quite as good as "exact" LRU ... where all pages in real
memory are exactly ordered as to when they were most recently
referenced). However, in execution periods when LRU assumptions
weren't applicable ... the implementation started randomly selecting
pages for replacement. It was in these situations that LRU-algorithm
started making bad choices ... and random tended to be better than
LRU-based decisions.

In any case, there are a lot of assumptions about execution patterns
built into LRU replacement algorithms. Furthermore, there are several
implementation pitfalls ... where you may think you have an LRU
implementation and it is, in fact, exhibiting radically different
replacement selections. An issue is to know that you are really doing
LRU replacement when LRU replacement is appropriate ... and to really
know you are doing something else ... when something else is more
applicable (particularly when assumptions about execution patterns and
applicable of LRU replacement don't apply).

So there are a lot of pit-falls having to do with stealing pages ...
both because 1) the implementation can have significant problems with
correctly implementating any specific algorithm and 2) assumptions
about a specific algorithm being valid may not apply to specific
conditions at the moment.

Either of these deficiencies may appear to be randomly and/or
unexplicably affected by changes in configurations. trading off real
executable memory for expanded storage can be easily shown to cause
more overhead and lower thruput (i.e. pages start exhibiting brownian
motion ... moving back and forth between real storage and expanded
storage). however, the configuration change may have secondary effects
on a poorly implemented page steal/replacement implementation which
results in fewer wrong pages being shipped off to disk. the
inexplicable effects on the poorly implementated page
steal/replacement algorithm resulting in fewer bad choices being sent
to disk may more than offset any of the brownian motion of pages
moving back and forth between normal storage and expanded storage.

the original purpose of expanded store was to add additional
electronic memory more than could be available by straight processor
execution memory (and used for paging in lieu of doing some sort of
real i/o). in the current situations you are trading off real
executable memory for a memory construct that has fundamentally more
overhead. however, this trade-off has secondary effects on a
steal/replacement implementation that is otherwise making bad choices
(that it shouldn't be making).

various collected posts about clock, local lru, global LRU, magically
switching between lru and random, (wsclock was the stanford phd on
global LRU ... some ten plus years after i had done it as
undergraduate) etc
http://www.garlic.com/~lynn/subtopic.html#wsclock

for even more drift ... one of the other things done with the detailed
tracing was a product that eventually came out of the science center
(announced and shipped two months before i announced and shipped
resource manager) was called vs/repack. this basically took detailed
program storage traces and did semi-automated program re-organization
to improve page working set characteristics. i'm not sure how much
customer use the product got, but it was used extensively internally
by lots of development groups ... especially the big production stuff
that was migrating from os/360 real storage to virtual storage
operation (big user that comes to mind was the ims development group).
the traces also turned out to be useful for "hot-spot" identification
(particular parts of applications that were responsible for majority
of exeuction).

misc. past vs/repack posts
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!
http://www.garlic.com/~lynn/2004c.html#21 PSW Sampling
http://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2005.html#4 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#62 More on garbage collection
http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005o.html#5 Code density and performance?

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

{SPAM?} Re: Expanded Storage

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: {SPAM?} Re: Expanded Storage
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 07 Feb 2006 10:59:18 -0700

ref:
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Expanded Storage

minor addeda to what went wrong in the initial morph from cp67 to
vm370.

as i mentioned, LRU is based on the reference history being an correct
predictor of future references.

a one-bit clock basically orders all pages in real memory and then
cycles around them testing and resetting the reference bit. the cycle
interval looking at all other pages in storage establishes a uniform
interval between resetting the bit and testing it again.

the initial vm370 implementation went wrong by both reordering all
pages at queue transition as well as resetting the reference bits.

for small storage sizes ... the time it took to cycle thru all pages
in memory was less than the nominal queue stay ... so we are looking
at a reference bit that represents an elapsed period less than a queue
stay. as real storage sizes got larger ... the time to cycle all pages
became longer than the avg. queue stay. that required that the
reference period represented by the reference bit be a period longer
than the queue stay. however, at queue transition ... the pages were
both being reordered and the reference bit being reset. as a result it
only had memory about the most recent queue stay ... even tho pages
had real storage lifetimes that were becoming much longer than the
most recent queue stay. as a result of both the queue transition reset
and the constant reordering ... the testing and resetting
implementation bore little actual resemblance to any algorithm based
on theoritical foundation (even tho the testing and resetting code
looked the same).

on the other hand, the same could be said of my slight-of-hand change
to the testing and resetting code. however, I could demonstrate that
my change actually corresponded to well provable theoritical
principles and had well describable and predictable behavior under all
workloads and configurations.

qagain, collect postings related to wsclock, global LRU, local lru,
etc.
http://www.garlic.com/~lynn/subtopic.html#wsclock

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

{SPAM?} Re: Expanded Storage

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: {SPAM?} Re: Expanded Storage
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 07 Feb 2006 11:27:07 -0700

Anne & Lynn Wheeler writes:

on the other hand, the same could be said of my slight-of-hand change
to the testing and resetting code. however, I could demonstrate that
my change actually corresponded to well provable theoritical
principles and had well describable and predictable behavior under all
workloads and configurations.

re:
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Expanded Storage
http://www.garlic.com/~lynn/2006b.html#16 {SPAM?} Expanded Storage

ok, and for even more drift.

one of the things done for the resource manager was a automated
benchmarking process was developed.
http://www.garlic.com/~lynn/submain.html#bench

over the years, there had been lots of work done on workload and
configuration profiling (leading into the evoluation of things like
capacity planning). one of these that saw a lot of exposure was the
performance predictor analytical model available to SEs and salesmen
on HONE
http://www.garlic.com/~lynn/subtopic.html#hone

based on lots of customer and internal datacenter activity, in some
cases spanning nearly a decade ... an initial set of 1000 benchmarks
were defined for calibrating the resource manager ... selecting a wide
variety of workload profiles and configuration profiles. these were
specified and run by the automated benchmarking process.

in paralle a highly modified version of the performance predictor was
developed that would, the modified performance predictor would take
all workload, configuration and benchmark results done to date.  the
model then would select a new workload/configuraiton combination,
predict the benchmark results and dynamically specify the
workload/configuraiton profile to the automated benchmark process.
after the benchmark was run, the results would be feed back to the
model and checked against the predictions. then it would select
another workload/configuration and repeat the process. this was done
for an additional 1000 benchmarks ... each time validating that the
actual operation (cpu useage, paging rate, distribution of cpu across
different tasks, etc) corresponded to the predicted.

the full 2000 automated benchmarks took three months elapsed time to
run.  however, at the end, we were relatively confident that the
resource manager (cpu, dispatching, scheduling, paging, i/o, etc)
operating consistently and preditably with respect to theory as well
as developed analytical models across an extremely wide range of
workloads and configurations.

as a side issue. one of the things that we started with before with
the automated benchmarks ... before the actual 2000 final were run
... were some extremely pathelogical and extreme benchmarks
(i.e. number of users, total virtual pages, etc that were ten to
twenty times more than anybody had ever run before). this put extreme
stress on the operating system and initially resulted in lots of
system failures. as a result, before starting the final resource
manager phase ... i redesigned and rewrote the internal serialization
mechanism ... and then went thru the whole kernel fixing up all sorts
of things to use the new sycronization and serialization process. when
i was done all cases of zombie/hung users had been eliminated as well
as all cases of system failures because of
syncronization/serialization bugs. this code then was incorporated
into (and whipped as part of) the resource manager.

unfortunately, over the years, various rewrites and fixes corrupted
the purity of this serialization/syncronization rework ... and you
started to again see hung/zombie users as well as some
serialization/syncronization failures.

misc. collected past posts on debugging, zombine/hung users, etc
http://www.garlic.com/~lynn/submain.html#dumprx

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

{SPAM?} Re: Expanded Storage

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: {SPAM?} Re: Expanded Storage
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 07 Feb 2006 13:03:26 -0700

Anne & Lynn Wheeler writes:

based on lots of customer and internal datacenter activity, in some
cases spanning nearly a decade ... an initial set of 1000 benchmarks
were defined for calibrating the resource manager ... selecting a wide
variety of workload profiles and configuration profiles. these were
specified and run by the automated benchmarking process.

re:
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Expanded Storage
http://www.garlic.com/~lynn/2006b.html#16 {SPAM?} Expanded Storage
http://www.garlic.com/~lynn/2006b.html#17 {SPAM?} Expanded Storage

and minor addenda to actual (implementation) benchmarking results
corresponding to theory/model/prediction ...

the modified predictor not only specified the workload profile (things
like batch, interactive, mixed-mode, etc) and configuration ... but
also scheduling priority. so not only did the actual (implementation)
overall system benchmarking results had to correspond to
theory/model/predictation ... but each individual virtual machine
measured benchmark resource use (cpu, paging, i/o, etc) also had to
correspond to the theory/model/prediction for that virtual machine
... including any variations introduced by changing the individual
virtual machine scheduling priority.

a side issue was when i released the resource manager ... they wanted
me to do an updated release on the same schedule as the monthly PLC
releases for the base product. my problem was that i was responsible
for doing all the documentation, classes, support, changes,
benchmarking, maintenance, and (initially) answering all trouble calls
... basically as a sideline hobby ... indepedent of other stuff I was
supposed to be doing at the science center (aka i was not part
of the development organization ... at the time, occupying the old SBC
building in burlington mall). I argued for and won ... only having to
put out a new release every three months instead of along with every
monthly PLC.

part of this was that it was just a sideline hobby ... the other was
that i insisted that I repeat at least 100-200 benchmarks before each
new minor (3 month) release to validate that nothing had affected the
overall infrastructure (and major changes to the underlying system
might require several hundred or thousands of benchmarks to be
repeated).

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

IBM 3090/VM Humor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3090/VM Humor
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 07 Feb 2006 19:32:54 -0700

Tony Harminc writes:

You're not thinking of PL/360 by any chance? I believe PL/S and the others
are descendents of BSL (Basic Systems Language, which much of e.g. TSO for
MVT Release 20 was written in), and are True Blue inventions.

PL/360 has essentially Algol syntax, while PL/S has that of PL/I.

an old pl/? thread
http://www.garlic.com/~lynn/2004g.html#46 PL/? History
http://www.garlic.com/~lynn/2004g.html#47 PL/? History

there was also pl.8 developed in the 70s for 801/risc (one story
is that it is 80 percent of pl/1). cp.r was written in pl.8 as
was a lot of code for various 801 processors of the period.

there was a large project in endicott to make the follow-on to the
4341 a 801 based chip. this was part of a effort in the period to
converge the vast variety of internal microprocessors to 801. the
low-end and mid-range 370s were various microprocessors that had 370
implemented in native machine microcode. there was a position paper
written opposing the 801 strategy for the 4341 followon ... based on
the fact that silicon chips were getting to the point where 370 could
be directly implemented in silicon .. rather than a microcode layer on
top of some chip silicon. i contributed to that paper. misc. 360/370
mcode posts, including description of original ecps
http://www.garlic.com/~lynn/subtopic.html#mcode

a few past posts mentioning pl/s:
http://www.garlic.com/~lynn/2002h.html#35 Computers in Science Fiction
http://www.garlic.com/~lynn/2002j.html#20 MVS on Power (was Re: McKinley Cometh...)
http://www.garlic.com/~lynn/2004m.html#6 a history question
http://www.garlic.com/~lynn/2005e.html#1 [Lit.] Buffer overruns

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

Seeking Info on XDS Sigma 7 APL

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Seeking Info on XDS Sigma 7 APL
Newsgroups: alt.folklore.computers,comp.lang.apl
Date: Wed, 08 Feb 2006 12:44:47 -0700

Al Balmer writes:

I'm not sure what you mean by "wet copier." IBM made a xerographic dry
copier at the time, I'm pretty sure. Kodak got into the game, too, at
one point producing a copier that was technically superior to the
Xerox. I remember a conversation with a Xerox rep where he "proved"
that a xerographic copier couldn't produce large black areas (charge
cancellation problem) just before I showed him a Kodak in-house
newsletter clearly demonstrating otherwise. He insisted it must have
been printed, not copied :-)

there was joke about the tv ads for IBM Copier III ... the copier III
had problems with paper jamming ... and so they put out tv ads that
touted how easy it was to clear paper jams in the copier-III.  it
backfired ... since people didn't like being reminded of the paper
jams (i.e. featuring a bug/problem can backfire).

nothing to do with sigma ... but lots of apl related posts
http://www.garlic.com/~lynn/subtopic.html#hone

not to be totally off-topic ... a few past posts mentioning sigma
http://www.garlic.com/~lynn/2002h.html#53 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002p.html#0 Newsgroup cliques?
http://www.garlic.com/~lynn/2003k.html#5 What is timesharing, anyway?
http://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
http://www.garlic.com/~lynn/2004m.html#15 computer industry scenairo before the invention of the PC?
http://www.garlic.com/~lynn/2005r.html#44 What ever happened to Tandem and NonStop OS ?

copier III was the basis for 6670 ... computer connected printer.
misc. past posts mentioning 6670
http://www.garlic.com/~lynn/99.html#42 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#43 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000d.html#81 Coloured IBM DASD
http://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ?
http://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002h.html#7 disk write caching (was: ibm icecube -- return of
http://www.garlic.com/~lynn/2002m.html#52 Microsoft's innovations [was:the rtf format]
http://www.garlic.com/~lynn/2002o.html#24 IBM Selectric as printer
http://www.garlic.com/~lynn/2002o.html#29 6670
http://www.garlic.com/~lynn/2003c.html#43 Early attempts at console humor?
http://www.garlic.com/~lynn/2004c.html#1 Oldest running code
http://www.garlic.com/~lynn/2004d.html#13 JSX 328x printing (portrait)
http://www.garlic.com/~lynn/2004k.html#48 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#61 Shipwrecks
http://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#48 1403 printers
http://www.garlic.com/~lynn/2005f.html#51 1403 printers
http://www.garlic.com/~lynn/2005f.html#54 1403 printers
http://www.garlic.com/~lynn/2005r.html#29 Job seperators

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

IBM 3090/VM Humor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3090/VM Humor
Newsgroups: bit.listserv.vmesa-l
Date: Wed, 08 Feb 2006 13:23:27 -0700

Jack Woehr writes:

7. But the best feature of VM on the 3x0 architecture is that
the same jokes stay fresh forever, since that platform changes
at roughly the same rate as the continents drift !

somewhat more suptle joke from the resource manager ... initially
(re)release was 1976.

it introduced a new module ... dmkstp ... which was a take-off on
a old tv commercial ... something about the "racer's edge".

the resource manager had some policy setting parameters and all this
dynamic adaptive feedback stuff. however, leading up to release of the
product ... somebody from corporate insisted that all the "modern"
performance management implementations had enormous numbers of
performance turning knobs. the major operating system release of the
period had a system resource manager ... with a humongous matrix of
performance tuning options. there used to be frequent share
presentations about enormous number of benchmarks where the numerous
performance options were somewhat randomly changed ...attempting to
discover static combinations of tuning knob settings that showed up
(on the avg.) better thruput for specific kinds of workloads.

somehow it was felt that all the dynamic adaptive feedback features
weren't significantly modern ... and it required static performance
tuning nodes that could be tweaked this way and that.

so before release, some number of static tuning knobs were introduced
and fully documented. the joke had to do with the nature of dynamic
adaptive feedback algorithms and something sometimes referred to as
"degrees of freedom" (and what had the greatest degrees of freedom,
the static tuning knobs or the dynamic adaptive feedback controls, aka
could the dynamic feedback control compensate for all possible tuning
knob changes).

misc. collected scheduling & resource manager posts
http://www.garlic.com/~lynn/subtopic.html#fairshare

there is a story about a couple years before the resource manager was
released, an early version leaked out to AT&T longlines. longlines
migrated this kernel to some number of machines ... including bringing
it up on newer generaion of machines as they were installed. coming up
to about 3090 timeframe , I was contacted by the national account rep
for at&t ... who was facing a problem. this early, leaked kernel
predated smp support and it wouldn't be possible to sell SMP
processors to longlines unless they could be migrated off this
machine. however, the dynamic adaptive stuff in this leaked kernel had
managed to survive nearly ten years and operate on a range of
processors that had a two-orders of magnitude different in computer
power (i.e. there was an increase computing power of one hundred times
between the earliest, entry machine and the latest, highest end
machine). misc. past post mentioning at&t longlines
http://www.garlic.com/~lynn/95.html#14 characters
http://www.garlic.com/~lynn/96.html#35 Mainframes & Unix (and TPF)
http://www.garlic.com/~lynn/97.html#15 OSes commerical, history
http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001f.html#3 Oldest program you've written, and still in use?
http://www.garlic.com/~lynn/2002.html#4 Buffer overflow
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002c.html#11 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002i.html#32 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#66 OT (sort-of) - Does it take math skills to do data processing ?
http://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
http://www.garlic.com/~lynn/2003.html#17 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003d.html#46 unix
http://www.garlic.com/~lynn/2003k.html#4 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2004e.html#32 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004m.html#58 Shipwrecks
http://www.garlic.com/~lynn/2005p.html#31 z/VM performance

a 3090 specific story has to do with erep data. i had done the drivers
for hyperchannel as part of migrating something like 300 people from
the ims group in santa teresa lab to off-site building. lots of
collected hyperchannel & hsdt (high speed data transport) project
posts:
http://www.garlic.com/~lynn/subnetwork.html#hsdt

they had considered remote-3270s, but discarded it as intolerable.
hyperchannel supported mainframe channel extension over telco links
... so that local 3270s could be used at the remote location. the 3274
local channel controllers operated at something like 640kbytes and the
telco channele xtenders ran over T1-links (aka around 150kbytes).
instead of response slightly declining, it improved because of some
secondary issues with local channel attached 3274 and overall system
thruput.

in any case, i adopted the use of simulating channel check error in
situations where there was an unrecoverable telco error and i needed
to bump error retry/recovery up a level.

after 3090 had been in customer shops a year, somebody from POK
contacted me about a problem they were seeing in the industry
reporting error statistics about 3090. 3090 channels had been designed
to have something like 3-5 total channel check errors in a year over
all customers (not 3-5 errors per 3090 per year ... but total
aggregate 3-5 errors per year across all 3090s). Reports had shown up
a total of something like 15-20 rather than 3-5 (for the first year).
They had tracked it down to some customers with hyperchannel installed
(aka the extra were these simulated errors). I looked into it and
determined that reflected IFCC (interface control check) instead of CC
would kick off essentially the identical error retry operations.

misc. past mention of CC/IFCC 3090 issue:
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
http://www.garlic.com/~lynn/2004j.html#19 Wars against bad things
http://www.garlic.com/~lynn/2004q.html#51 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#28 Adversarial Testing, was Re: Thou shalt have no
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances

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

Would multi-core replace SMPs?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Would multi-core replace SMPs?
Newsgroups: comp.arch
Date: Wed, 08 Feb 2006 19:01:20 -0700

"John Mashey" writes:

There is nothing magically different about having multiple CPUs/die,
just the usual effect of getting more transistors in smaller spaces at
lower cost.  The same old architecture problems and bottlenecks still
happen, but cheaper.

as mentioned, not just limited to CPUs ... but functional units in
general. i have vaque memories of some 3090 processor engineer
complaining about offering vector processing option on 3090; claiming
that they had already optimized scalar fp to the point that it would
saturate the memory bus ... and the vector processing option wouldn't
be able to get any additional thruput out of the memory bus (however,
the scientific community apparently considered that it couldn't be a
serious numerical intensive processor if it didn't have a vector
processing unit).

misc. posts in same/related thread:
http://www.garlic.com/~lynn/2006.html#14 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006.html#32 UMA vs SMP? Clarification of terminology
http://www.garlic.com/~lynn/2006.html#34 UMA vs SMP? Clarification of terminology

there are other gimmicks possible at specific points in time. normal
(mainframe) 370 slowed cache cycle down for two-processor SMP
(allowing cross-cache chatter) so that a 2-smp raw hardware mip rate
was only 1.8 times a single processor mip rate (and only 1.5 times
effective thruput when smp kernel processing overhead was thrown
in). when i was first writting some kernel smp support ... i did some
slight-of-hand with regard to processor affinity and asynchronous
interrupt processing. I had one example where a uniprocessor ran about
1mip thruput ... and the two-processor smp had one processor running
about .6mips and the other processor running about 1.5mips
(i.e. aggregate 2.1mips). the finagling with processor affinity
improved the cache hit ratio (on one of the processors) to more than
compensate for the smp slower cache cycle time. Of course, the
slight-of-hand smp support ... not only resulted in some improved
cache hit ratios with effective processor affinity processing ... but
close to negligible additional smp-related kernel overhead processing
(compared to a uniprocessor kernel). misc. collected smp related
postings
http://www.garlic.com/~lynn/subtopic.html#smp

i've frequently asserted that some amount of the uniprocessor only,
simple architecture of the original risc/801 design philosiphy was
reaction

1) excessive hardware complexity in future system project (which
was canceled before it was ever announced) misc. past FS postings
http://www.garlic.com/~lynn/submain.html#futuresys

2) the significant smp cache consistency overhead supporting mainframe
(extremely) strong memory consistency model.

lots of collected 801, risc, romp, rios, power, etc posts
http://www.garlic.com/~lynn/subtopic.html#801

for some topic drift ... recent 3090 related posts.
http://www.garlic.com/~lynn/2006b.html#10 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006b.html#19 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor

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

Seekin