List of Archived Posts

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

EREP , sense ... manual

Average Seek times are pretty confusing

Average Seek times are pretty confusing

PVM protocol documentation found

Average Seek times are pretty confusing

Page fault question (zero-filling)

UDP and IP Addresses

EREP , sense ... manual

How to restore VMFPLC dumped files on z/VM V5.1

How to restore VMFPLC dumped files on z/VM V5.1

How to restore VMFPLC dumped files on z/VM V5.1

Some credible documented evidence that a MVS or later op sys has ever been hacked

Zeroing core

sox, auditing, finding improprieties

VM maclib reference

Would multi-core replace SMPs?

S/360

Would multi-core replace SMPs?

{SPAM?} DCSS as SWAP disk for z/Linux

DCSS as SWAP disk for z/Linux

DCSS as SWAP disk for z/Linux

multiple firefox with different profiles

IBM up for grabs?

IBM up for grabs?

auto industry

IBM up for grabs?

DCSS as SWAP disk for z/Linux

IBM microwave application--early data communications

IBM microwave application--early data communications

DCSS as SWAP disk for z/Linux

IBM microwave application--early data communications

IBM microwave application--early data communications

Is VIO mandatory?

UMA vs SMP? Clarification of terminology

The new High Assurance SSL Certificates

UMA vs SMP? Clarification of terminology

Charging Time

Charging Time

The new High Assurance SSL Certificates

Is VIO mandatory?

What happens if CR's are directly changed?

All Good Things

Is VIO mandatory?

IBM 610 workstation computer

Sprint backs out of IBM outsourcing deal

IBM 610 workstation computer

IBM 610 workstation computer

Free to good home: IBM RT UNIX

"VAX" Tradename reused !

Early microcomputer (esp i8008) software

EREP , sense ... manual

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EREP , sense ... manual
Newsgroups: alt.folklore.computers, listserv.bit.ibm-main
Date: Mon, 02 Jan 2006 09:06:33 -0700

freelance wrote:

Hi
on what manual can I find an explanation for the "sense data" reported
by EREP ?

some of the sense bits are generic ... most sense bits are device
specific. there was a ios3270 version of 360 green card done long ago
and far away.

ios3270 was part of a menua application package done by theo alkema at
the uithoorne (EU) HONE system that also included the 3720 screen
applications fulist and browse. HONE was the internal world-wide
marketing, sales, and field support vm/370-based system.
http://www.garlic.com/~lynn/subtopic.html#hone

many people may be familiar with ios3270 menu applications as the
screens in the 3090 service processor (the 3090 service processor was
actually a pair of 4361s running vm/370 with the service screens
implemented in ios3270).

the 360/67 "blue" card included several panels that gave sense bit
definitions for several devices. long ago and far away, I had updated
gcard with sense data for several devices.

i recently did a very rudimentary implementation of the original gcard
in html
http://www.garlic.com/~lynn/gcard.html

the sense data panels at:
http://www.garlic.com/~lynn/gcard.html#17

it is still somewhat a work in progress since it still doesn't convey
the feeling of the original gcard application.

misc. past fulist, browse, ios3270 postings
http://www.garlic.com/~lynn/96.html#41 IBM 4361 CPU technology
http://www.garlic.com/~lynn/99.html#60 Living legends
http://www.garlic.com/~lynn/99.html#61 Living legends
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#8 Theo Alkema
http://www.garlic.com/~lynn/2001f.html#9 Theo Alkema
http://www.garlic.com/~lynn/2002e.html#5 What goes into a 3090?
http://www.garlic.com/~lynn/2002i.html#79 Fw: HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
http://www.garlic.com/~lynn/2003l.html#12 Why are there few viruses for UNIX/Linux systems?
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#63 creat
http://www.garlic.com/~lynn/2005f.html#14 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005t.html#39 FULIST
http://www.garlic.com/~lynn/2005t.html#40 FULIST
http://www.garlic.com/~lynn/2005t.html#41 FULIST
http://www.garlic.com/~lynn/2005t.html#42 FULIST
http://www.garlic.com/~lynn/2005t.html#43 FULIST
http://www.garlic.com/~lynn/2005t.html#44 FULIST
http://www.garlic.com/~lynn/2005t.html#45 FULIST
http://www.garlic.com/~lynn/2005t.html#47 What is written on the keys of an ICL Hand Card Punch?
http://www.garlic.com/~lynn/2005t.html#48 FULIST
http://www.garlic.com/~lynn/2005t.html#49 FULIST

Average Seek times are pretty confusing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Average Seek times are pretty confusing
Newsgroups: comp.arch
Date: Mon, 02 Jan 2006 14:52:41 -0700

"cambpellster.john@gmail.com" writes:

I am trying to find the average seek time of the following
single-platter disk. I know that the seek time is 1ms for every 100
tracks traversed. The total number of tracks on one side of the platter
is 30,000. Then what is the average seek time?
I think it is: 1ms/100 .... it makes sense, right?

you need to take the avg. of all the seek distances. many times the
avg. seek distance is taken as half the maximum seek distance.  given
that you know the avg. seek distance, then you can calculate the
avg. seek time (based on the avg. seek distance).

many disks have situation where it takes longer per track for short
seek distances than for long seek distances (having at least to do
with startup inertia and acceleration of the arm from rest).

there was once a couple high-school kids visiting this dam late at
night (for the first time) ... and the driver turned onto the highway
across the top of the dam and floored the gas pedal ... attempting to
see peak speed across the top. as they were coming to the other end of
the dam, one of the passengers mentioned that the driver should slow
down ... and the driver said there was no problem that they would just
coast thru the upcoming tunnel.

turns out that it wasn't a tunnel ... it was a garage where they
parked a large crane ... with a solid concrete wall in the back. they
barely avoided an extremely distructive instantaneous deaccleration
what was the avg. speed across the top of the dam?

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

Average Seek times are pretty confusing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Average Seek times are pretty confusing
Newsgroups: comp.arch
Date: Mon, 02 Jan 2006 22:08:14 -0700

"Bob" writes:

Doesn't this assume the disk is full?  It also assumes that
disk accesses are random, which is far from true in most
real systems.  Files that are written close together tend to
be read close together.

when i was an undergraduate ... i reorganized a mainframe filesystem
so that the avg. elapsed time for a standard job at the university
improved by nearly a factor of three. the major thruput bottleneck was
seek time ... significantly reducing avg. seek time resulted in a
corresponding thruput increase (and decrease in elapsed time, from a
little over 30 seconds to a little under 13 seconds).

ref. to past postings on a presentation i gave at aug '68 user group
meeting in boston;
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/2001f.html#26 Price of core memory
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load

note, in the reference presentation in the above, there is several different
items discussed.

one is the re-organizing of the mainframe batch filesystem and disk
layout to significantly increase the thruput from well-over 30 seconds
(in a default, standard, out-of-the-box organization) and the 12.9
seconds (in the re-organization).

the other work described in the presentation was significantly
rewritting major pathlengths in the virtual machine cp/67 kernel.to
reduce the cpu utilization (and the combined result of running the
virtual machine cp/67 kernel in combination with the batch operating
system).

not described in the presentation ... was that i had also rewritten
portions of the disk i/o scheduling to introduced ordered arm seek
scheduling (aka when there are multiple queued i/o requests for the
same disk, the queue is re-ordered to sort the i/o requests for
minimum arm seek distance). the change to ordered arm seek queueing
(from FIFO) tended to further reduce the arg. arm seek distance under
heavy load. with ordered arm seek queuing, the avg. seek distance
tended to decrease as the load increased.

misc. past postings referring to changing implementation from F(IFO
queueing to ordered seek queueing:
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/98.html#17 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2002e.html#0 Storage Virtualization
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005j.html#51  Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction

another change that i made in the paging implementation was slot
chaining, when there was independent I/O requests for different
records on the same "cylinder" (records on the same track or records
on different tracks at the same arm position in multi-platter
devices). this had some benefit in the thruput in the records
processed per second on moveable arm disks ... but it showed even
greater thruput in the numbers of records per second in "fixed-head"
device (i.e. device that had a read/write head per track so there was
no track-to-track arm motion). request chaining on the 2301 fixed-head
device (used in cp/67 systems) increased the peak record transfer
thruput from approx. 80 4k records per second to 300 4k records per
second.

for moveable arm devices, request chaining somewhat increased the
avg. seek distance ... since multiple independent zero seek requests
are collapsed into a single, multiple-record request operation

misc. past posts on subject of request record chaining:
http://www.garlic.com/~lynn/95.html#12 slot chaining
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001d.html#49 VTOC position
http://www.garlic.com/~lynn/2001d.html#68 I/O contention
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/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2003g.html#25 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2004b.html#32 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005j.html#51  Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction

finally here is collected postings on numerous changes to filesystem
implementation code i made in the early 70s ... one of the changes was
support for contiguous allocation which tried to allocate records for
the same file at contiguous physical disk locations (increasing
the ability to do mutliple request record chaining):
http://www.garlic.com/~lynn/subtopic.html#mmap

improving contiguous allocation can increase the effectiveness of
multiple record chaining (i.e. multiple records transferred in a
single operation). again this can result in the avg. seek distance
increasing, since multiple request transfer may appear as a single
seek request (depends oon how the infrastructure statistics treats
zero arm motion operations and multiple record transfer operations).

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

PVM protocol documentation found

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PVM protocol documentation found.
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 03 Jan 2006 09:12:53 -0700

David Boyes writes:

Don't know whether anyone else may ever need this, but FYI:  Appendix 1
of the PVM Admin and Operation manual does document the buffer layout
and sequence of events for PVM link communications. There are also some
examples of applications talking to PVM on the old SHARE mods tapes that
were quite helpful.

Stay tuned. I should have some interesting results to present shortly.

old posting about a pair of applications; parasite that talked PVM and
story that implemented HLLAPI screen-scraping functionality (before
IBM/PCs and HLLAPI existed):
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#36 Newbie TOPS-10 7.03 question

the above references have the story source header describing the story
"language" and examples of story programs.

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

Average Seek times are pretty confusing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Average Seek times are pretty confusing
Newsgroups: comp.arch
Date: Tue, 03 Jan 2006 13:41:42 -0700

Jeremy Linton writes:

Again, i did some benchmarking on a true "average" seek time
for an application I was involved in writing a few years ago and was
amazed that the average seek time for the application was a factor
of 10 less than the average seek time published by the drive
manufacture. So that number is really sort of an average "worse"
case figure. Of course your mileage may vary...

an early full-track controller cache was 3880-13 for 3380 drives.  a
fairly typical 3380 configuration was ten 4k records per track.  for
sequential file reads ... the 3880-13 cache would do a miss on the 1st
record read for track and the subsequent nine record reads would all
then be "cache" hits. based on this characteristic there was 3880-13
marketing statements about having 90percent hit rate.

however, somebody pointed out that if the application was to do large
buffering resulting in full-track sequential reads rather than
individual record sequental reads ... the same, identical operation
would drop from 90percent cache hit to zero percent cache hit (and run
faster).

the avg. seek time is actually based on the avg. seek distance.
real-life seek distances can have enormous variance.  in many cases,
avg. seek time based on some assumed seek distance distribution ... is
more for comparison of different drives than accurately predicting
exactly how a particular environment is going to operate.

avg. access time tends to be a combination of some assumed seek
distance distribution and avg. rotational delay.

random past posts mentioning 3880-13/sheriff
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001b.html#61 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#49 VTOC position
http://www.garlic.com/~lynn/2001d.html#68 I/O contention
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#54 mainframe question
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2002d.html#55 Storage Virtualization
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2002o.html#52 ``Detrimental'' Disk Allocation
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003i.html#72 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#22 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005t.html#50 non ECC

when i got in trouble pointing out to the disk division that the
relative system thruput of disks had declined by a factor of ten over
a 10-15 year period ... they assigned their performance & modeling
organization to refute my statement. after a number of weeks, the
group came back with the finding that I had actually understated the
problem. part of this was that the other components of the system had
performance increases much larger than the avg. access time
performance increase (and/or other thruput measures) of disk
technology.

random past refs:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2004n.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005f.html#55 What is the "name" of a system?
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning

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

Page fault question (zero-filling)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page fault question (zero-filling)
Newsgroups: comp.arch
Date: Wed, 04 Jan 2006 16:04:08 -0700

"ldb" writes:

To make matters worse, deep within the bowels of the memory-management
code, linux basically has a line of code like this:
if(in_interrupt())
do_slow_zeroing();
else
do_fast_zeroing();

long ago and far away ... when cp67 was first delivered to the
university, the method of zero filling was to have a special all zeros
page on disk. address space virtual pages were all initialized to
point to that page on disk (so on on the 1st fault, the special zeros
page would be read from disk).

i changed that (when i was rewritting lots of other code) so that
address space tables were initialized to a special zeros indication
and then in the page fault handler, special code to do a (360) BXLE
loop where i initialized a bunch of registers to zero and did a (360)
STM/BXLE loop, clearing the page. at the time, on 360/67, it was the
fastest way that I could come up with clearing a block of storage to
zeros.

360/67 functional specification manual (gives detailed instruction
timings):
http://www.bitsavers.org/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf

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

UDP and IP Addresses

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: UDP and IP Addresses
Newsgroups: comp.protocols.tcp-ip
Date: Thu, 05 Jan 2006 10:58:21 -0700

"theinvisibleGhost" writes:

Thanks for your help, sorry for the slow reply I've not been around.
I must be misunderstanding something still however.  From
what I read I thought that UDP datagrams were placed in the data area
of the IP datagrams?  Are you saying that UDP datagrams actually
replaces the IP datagrams?

part of this is how you look at the implementation ... higher-level
transmission frequently is encapsulated by headers/trailers as they
proceed down the protocol stack (and then the outer layers are
stripped off at reception as they proceed back up the protocol stack
... peeling an onion).

one of the long time network protocol performance issues has been do
you copy the data from the higher level stack into your own buffer and
then wrapper it with lower-level control information ...  or can you
use scatter/gather i/o techniques with i/o address pointers and avoid
doing buffer copies as you proceed down&up the protocol stack.

scatter/gather would have a series of i/o addresses and lengths that
are processed sequently by the i/o hardware moving the data along as a
continuous stream (but from different, non-contiguous locations in
memory). the protocol encapsulation as you proceed down the protocol
stack ... instead of physically creating a new copy of the data with
the lower-level protocol header/trailers ... just create a continuous
stream of data in the correct logical order by the way you order the
sequence of i/o addresses being processed by the i/o hardware.

a side issue somewhat raised by scatter/gather scenario has been
header versis trailer error checking codes. if you use header error
checking codes, the complete data stream has to be processed btfore
you can fillin the error checking field in the header. in trailer
error checking codes, the i/o hardware can keep a running calculation
of the error checking code as the data streams thru and then fill-in
the error checking field as the trailer passes by.

the headere/trailer error checking issue isn't directly tied to
scatter/gather issues ... but if you aren't worried about doing the
overhead of lots of buffer copies, then you likely aren't worried
about the overhead of the preprocessing error checking overhead. if
you are looking at scatter/gather to avoid buffer copy overhead
... then you may also be concerned about the overhead of calculating
error checking field.

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

EREP , sense ... manual

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EREP , sense ... manual
Newsgroups: alt.folklore.computers, listserv.bit.ibm-main
Date: Fri, 06 Jan 2006 08:19:30 -0700

R.S. wrote:

It was called 'OEMI' I forgot what I stands for, presumably Interface.
This book descibes Bus&Tag infterface, including plug construction,
signal characteristics, voltage levels etc. See GA22-6974

other equipment manufactureinterface ... or something similar ...
synonym for pcm ... plug compatible manufacture. somewhere along the
way, there had been some litigation by pcm vendors.

when i was an undergraduate, some guys from the science center
(4th flr, 545tech sq, cambridge)
http://www.garlic.com/~lynn/subtopic.html#545tech

had come out and installed cp67 at the university. i got involved in
rewritting large portions of the kernel ... creating dynamic adaptive,
feedback scheduler (later customers would refer to it as fairshare
scheduler ... since one of the resource management policies was
fairshare), new paging algorithms, chain record, ordered seek queueing,
fast path, etc. i gave a presentation on some of the work at aug. 68
share meeting in boston (presentation also included extensive work done
on os/360 mft14) ... part of that presentation:
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

cp67 shipped with 2741 and 1052 terminal support but the university had
these m33 teletypes (ascii) terminals ... so i added tty/ascii terminal
support. the cp67 2741/1052 support had dynamic terminal identification
... i.e. it would play sending various commands and playing with the
2702 sad command to dynamically identify the terminal. i figured what
the heck, i could add tty/ascii support in similarly ... so that cp67
could do dynamic terminal identification for 2741/1052/tty.

i had this grandiose idea that you could have a single number on phone
rotory and let all kinds of terminals dial the same number ... and the
system would dynamically determine terminal type. well, it turned out
that the dynamic terminal identification worked fine for 2741/1052 ...
but there was a problem adding ty. while 2702 supported being able to
associate any line-scanner with any port/line ... it had a restriction
that the oscillator setting the baud rate for each line/port had to be
hired-wired.

this sort of kicked off a project at the univ. to reverse engineer the
360 channel interface, build our own channel interface board and program
an interdata/3 to emulate a 2702 controller (somebody even wrote an
article blaming four of us for originating the pcm controller market).
one of the things that was implemented in the interdata/3 was dynamic
buad rate in the software line-scanner ... i.e. the software would
strobe the signal rise/lower on the line to dynamically figure out the
terminal baud rate. misc. past posts about 360 oem/pcm
http://www.garlic.com/~lynn/subtopic.html#360pcm

later, supposedly a major motivating factor for FS was oem/pcm controllers
http://www.garlic.com/~lynn/subtopic.html#futuresys

specific article mentioning future system project by somebody that
worked on it (The rise and fall of IBM, Jean-Jacques DUBY Scientific
Director of UAP, Former Science & Technology Director of IBM Europe)
http://www.ecole.org/Crisis_and_change_1995_1.htm

quote from above:

IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead
that the competition would never be able to keep up, and to have such
a high level of integration that it would be impossible for
competitors to follow a compatible niche strategy. However, the
project failed because the objectives were too ambitious for the
available technology.  Many of the ideas that were developed were
nevertheless adapted for later generations. Once IBM had acknowledged
this failure, it launched its 'box strategy', which called for
competitiveness with all the different types of compatible
sub-systems. But this proved to be difficult because of IBM's cost
structure and its R&D spending, and the strategy only resulted in a
partial narrowing of the price gap between IBM and its rivals.

... snip ...

by that time, i had gone to work at the science center ... and i would
make some sarcastic comments about the similarity between FS project and
a long-playing "cult" film playing down in central sq. (something about
the inmates being in charge of the institution).

basically FS was going to completely replace 360 ... and was as
radically different from 360 than 360 had been from prior generations.
the focus on replacing 360 with FS somewhat dried up projects for 360
follow-ons ... so when FS was eventually killed there was a mad
scramble to re-invigerate work on 370 products. by that time, you were
starting to see plug-compatible processrs in addition to
plug-compatible controllers.

i remember a seminar that amdahl gave at mit to a large audience in the
early 70s. one of the questions was how did he justify getting
investment for his company. he described an analysis of the hundreds of
billions that customers had already invested in developing 360 software
and stated that even if ibm was to totally walk away from 360
architecture, there would still be enough customer 360 software until at
least the end of the century to keep him in business (at the time, the
end of the century was still almost 30 years away).

How to restore VMFPLC dumped files on z/VM V5.1

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to restore VMFPLC dumped files on z/VM V5.1
Newsgroups: bit.listserv.vmesa-l
Date: Fri, 06 Jan 2006 10:21:35 -0700

Rich Greenberg writes:

One possibility is that VMFPLC only understands 800 byte block
disks.

baiscally tape, vmfplc, and vmfplc2 put data on tape similarly; read
the FST, write the FST to tape, open the file, modify the file
characteristics to match the physical disk format ... file record
reads and physical data blocks then are the same.

processing the tape, read fst and save it, read physical blocks from
tape and write them to disk file (the file records then may, or may
not be the same as the physical disk records), when finished reading
each cms file on tape, close the file being written to disk and zap
the FST for the new disk file with the FST information read from disk.

vmfplc2 was update to add misc. new function and also handle FSTs for
both original filesystem (800 physical records) and EDF filesystem
(1k, 2k, 4k physical records) ... but there were some FST format
changes (and edf had filesystem call that avoided having to do some of
the FST fiddling).

old (ibm-main) posting about VMFPLC2
http://www.garlic.com/~lynn/2003b.html#42 VMFPLC2 tape format

in the above, the source code modification from vmfplc to vmfplc2
are identified as @V62B0H2.

i've even heard of peopledoing REXX code to handle old format tapes
... getting image copy of several physical blocks from tape is
frequently enuf to figure out what to do in the REXX code.

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

How to restore VMFPLC dumped files on z/VM V5.1

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to restore VMFPLC dumped files on z/VM V5.1
Newsgroups: bit.listserv.vmesa-l
Date: Sat, 07 Jan 2006 10:27:49 -0700

Anne & Lynn Wheeler writes:

old (ibm-main) posting about VMFPLC2
http://www.garlic.com/~lynn/2003b.html#42 VMFPLC2 tape format

i had done heavy modification of VMFPLC2 (for all sorts of reasons)
and called it VMXPLC and used it to implement a backup/archive
system. this was deployed at research, hone (vm/370 world-wide, sales,
marketing, field-support operation)
http://www.garlic.com/~lynn/subtopic.html#hone

and a couple other internal places.

this went thru a couple internal releases and then a project was
started to make it available to customers. with numerous enhancements
this eventually was released as workstation datasave ... i.e. it added
agents on distributed machines to do backup/resotre data transfer.
workstation datasave then morphed into ADSM and is now called TSM
misc. past posts, workstation datasave, adsm, tsm, etc
http://www.garlic.com/~lynn/subtopic.html#backup

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

How to restore VMFPLC dumped files on z/VM V5.1

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to restore VMFPLC dumped files on z/VM V5.1
Newsgroups: bit.listserv.vmesa-l
Date: Sat, 07 Jan 2006 11:17:58 -0700

misc. refs:
http://www.garlic.com/~lynn/2005p.html#42 VMFPLC2 to load EREP PTFs
http://www.garlic.com/~lynn/2006.html#8 How to restore VMFPLC dumped files on z/VM V5.1
http://www.garlic.com/~lynn/2006.html#9 How to restore VMFPLC dumped files on z/VM V5.1

Anne & Lynn Wheeler writes:

i had done heavy modification of VMFPLC2 (for all sorts of reasons)
and called it VMXPLC and used it to implement a backup/archive
system. this was deployed at research, hone (vm/370 world-wide, sales,

much larger blocking was done ... and also combining the FST record
with data records as single physical record (for small files you could
have majority of the tape as inter-record gaps, combinting the FST
record with the data block record would cut in half the inter-record
gaps).

i had done page-mapped filesystem for cms way back in cp67 ... along
with being able to define shared page stuff from the cms exectuable.
i would map the original cms filesystem semantics ontop of page-mapped
operations. later, i also modified the CMS edf filesystem semantics
ontop of page-mapped operations. misc. cms paged mapped filesystem
postings
http://www.garlic.com/~lynn/subtopic.html#mmap

if you had cms filesystem in a page mapped area ... and dealing with
old applications (that didn't deal in page-sized records aligned on
page boundaries) ... the implementation would push & pull the data
around so that it was transparent to the application that it was
dealing with a paged mapped filesystem. however, there were all sorts
of thruput and performance things that went on if filesystem i/o
happened to be in page record sizes and aligned on page boundaries. so
part of the changes for VMXPLC included doing some of that.

note that the basic filesystem changes were never included as part of
any mainframe shipped product (some of it was incorporated into some
version of xt370).

in the morph from cp67 to vm370, the standard system mechanism for
dealing with shared pages (shared segments) was to define them in a
special kernel paging area. the definitions were specified in a kernel
assembler module, DMKSYS. the process was to initialize an image in
virtual address space and issue a (privileged) "SAVESYS" command to
write an image from the virtual address space to the saved system
area. Access to these "named" systems was by specifying the DMKSYS
name in the CP IPL command.

the port of all the memory mapped stuff from cp67 to vm370 included a
bunch of stuff about handling all sorts of virtual address space stuff
... shared segments, non-shared segments ... dynamically loaded, etc.
While all the page mapped filesystem stuff wasn't picked up and
shipped ... there was a small subset of the vm370 kernel changes
picked up and released as DCSS (discontiguous shared segments).  This
allowed loading of sections of virtual memory from a DMKSYS named
system w/o having to go thru the IPL command semantics.

one of the heavy users of the paged map stuff was HONE
http://www.garlic.com/~lynn/subtopic.html#hone

not so much because they needed the filesystem performance
enhancements ... but they needed the capability of having shared
segments w/o using the IPL command (that reset the whole virtual
machine).

most of HONE applications (like configurators, as things evolved,
eventually all mainframe orders had to be run thru a hone configurator
before it was submitted) were implemented in APL ... and the systems
were heavily processor limited. APL interpreter was large amount of
code ... and prior to DCSS, the approach was to initialize a virtual
address space with cms along with the APL interpreter and save it as
something like CMSAPL named system. branch office logons would then
have automatic IPL of CMSAPL throwing them directly into the HONE APL
environment.

so all of that is standard system stuff ... except that they were
starting to find possibly 100:1 performance improvement by recoding
some of the APL stuff into compiled fortran. this required dropping
out of APL, running a cms fortran program and then reentering the
CMSAPL environment. this was a practical impossibility if the ipl
command had to be issued by the branch sales people for the transition
into and out of APL.

so the paged map filesystem support was installed at hone and rather
than having an IPL named system CMSAPL defined in DMKSYS, the APL
interpreter was a standard cms executable in cms page mapped
filesystem (with the appropriate indicators for shared page operations
... which were added to GENMOD command, recorded in new module field
and supported by LOADMOD). then dropping into and out of APL to run
fortran applications became simple CMS application execution.

this was all before a subset of the shared page kernel changes were
picked up for DCSS and remapped to DMKSYS named systems.

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

Some credible documented evidence that a MVS or later op sys has ever been hacked

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Some credible documented evidence that a MVS or later op sys has ever been hacked
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 09 Jan 2006 08:45:05 -0700

Gerard 46 wrote:

If there were holes in zVM, they'd be closed.  After all, ZVM is
designed to not let anyone out of their sandbox, even if you have
access to the source (as it was in the good ole days), and even back
then looking at the source, it was a hard thing to
do.
____________________________Gerard S.

a little drift on the next, new, new (40 yr old) thing in security
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

a lot of attacks on systems in the past have frequently been some sort
of escalation of privileges. something has enuf privileges to place a
file somewhere in the system that some other entity with more privileges
will execute.

automatic execution of code arriving in email (trojans/viruses) could be
classified this way. we actually had to look into a form of this in the
70s on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

... and formed some statements about automatic scripting of packages
arriving over the network.

lots of infrastructures are attacked at other vulnerability points ...
like harvesting of passwords for impersonation attacks. misc.
http://www.garlic.com/~lynn/subintegrity.html#harvest

during FS project
http://www.garlic.com/~lynn/subtopic.html#futuresys

there was a security effort to make much of the documents only available
electronicly online via special cms systems (considered more secure than
having lots of paper flowing around). some of the people working on the
effort once made the rash statement that even if I was in the machine
room, "even" i wouldn't be able to access the documents. one of the few
times i rose to the bait, i countered with it might take five minutes.
turns out most of the time was spent disabling the machine from access
outside the machine room; because i was about to flip a bit in kernel
memory. the bit i flipped was in the branch instruction that followed
the return from the authentication checking routine (everything was
about to be taken as valid authentication).

sox, auditing, finding improprieties

From: Anne & Lynn Wheeler 
Date: January 12, 2006 10:22:04 AM EST
To: dave@xxxxxxx
Cc: ip@xxxxxxx
Subject: Re: sox, auditing, finding improprieties

danial berniger wrote:


Dave,

I wrote a review of the new book by Vanguard founder Jack Bogle's for
clients that may be of interest to readers of IP.

"The Battle for the Soul of Capitalism" argues most of the forces that
produced the scandals among Enron, Worldcom, et al remain in place.
This means investors should expect another wave of scandals even as
the bad actors of the first wave go to trial.

Bogle believes the cycle will continue until investors get much more
active in holding CEO's and the financial intermediaries accountable.


re:
http://www.interesting-people.org/archives/interesting-people/200601/msg00169.html

in principle, auditors are looking for inconsistencies between
different information sources (which might be indication of fraud or
other improprieties). auditing internal corporate books somewhat
assumes that there are at least some that represent independent
sources and therefor might have inconsistencies. modern IT technology
can be leveraged to generate a complete consistent set of corporate
books. in face of being able to leverage IT technology to generate
complete consistency isn't going to be overcome by asking for more
information from the same source (more doesn't necessarily imply
independent)

looking for inconsistencies between independent sources then would
imply that sources of information from non-corporate sources would
have to be checked against corporate books (as opposed to assuming
that inconsistencies might exist in purely internal corporate books,
no matter how much the volume of information is specified).

that also somewhat has led to leveraging other sources of information
about possible fraud or improprieties ... like inside informers.

Zeroing core

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Zeroing core.
Newsgroups: alt.folklore.computers
Date: Fri, 13 Jan 2006 11:10:25 -0700

Robert Billing writes:

However I believe that there was a weird instruction which walked
backwards through memory leaving zeros behind and finally consumed
itself at address zero.

something similar ... was the MVCL instruction introduced on 370. the
source and destination lengths were different and if the source length
was less than the destination length ... there was a pad-fill
value. so you could set the source length to zero, the destination
length to all of memory and the pad-fill value to zero.

the was an early microcode bug on the 370/125 for the MVCL
instruction. all 360 instructions would pretest start and ending
addresses for valid and abort with approriate failure if either was a
problem. MVCL was a new type of instruction introduced on 370 which
incrementally executed and allowed restartable ... and that things
like access to memroy checking was done incrementally as the
instruction got to that address. 370/125 bug was that it did the
pretesting rules from 360 ... instead of the 370 incremental testing
rules. vm370 used the MVCL at boot to both clear and test for end of
memory ... setting a destination length to max. 125 would abort w/o
executing any of the instruction (doing pretest of ending address
instead of testing each location as processed) ... so the result
appeared as if the machine didn't have any memory.

theer was also story about

somewhere in the history ... somebody decided that the TR and TRT
instructions had a bug. TR/TRT references a 256byte table ... the
value of each character in the source is used to index the 256byte
table.  the 360 implementation did pretest on the starting address of
the table and assumed the ending address was +256 (for pretest before
starting the instruction). however, it is possible to use the
instructions with "short" tables for situations where the source input
is known to contain constrained values. one scenario is where the
starting address plus 256 crosses a page boundary and might result in
a page fault ... but the actual execution of short table wouldn't so
the TR/TRT insturction implementation was changed so that it tests the
+256 ending address and if there possibly is an access problem ... the
instruction is then pre-executed testing each of the possible source
character values to see if it results in a table address resulting in
some sort of access issue ... like a page fault. instead of
automatically taking an exception with access issue with +256 ending
address ... it prechecks each possible source character processing
(to see if it will result in calculated table position on the
other side of the access boundary).

i have some vague recollection of different MVCL microcode bug on some
machine when there was full 16mbytes of addressing memory (the 125
m'code bug i got involved in diagnosing, but this one i've just heard
stories about). microcode had been dependent on getting an invalid
memory address to stop the operation ... however with full 16mbytes of
addressable memory, the address wrap from 16mbytes back to zero and
kept going. the intention with 16mbyte length was to stop at end
of memory as opposed to wrapping around and actually wiping all of
memory.

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

VM maclib reference

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM maclib reference
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Sat, 14 Jan 2006 02:24:22 -0700

Steve Gentry writes:

I think the shared/saved/NSS/DCSS segments is a dead issue.
We have also discussed the idea of using Virtual Disk and mapping a
minidisk to expanded storage. XC and all that entails.
We still have to keep in mind how each of these methods would be
implemented and how much the change would impact the program(s).
We're trying to make minimal changes to existing programs. i.e., The logic
for table processing is already in the programs.  Where the table resides,
either above the line or below it are inconsequential.  Changing the
program logic to use mdisks, be it v-disk or dataspaces requires a lot
more program change.

the original superset of DCSS, I had started on CP/67 and referred to
it as virtual memory management (VMM) ... this included handling CMS
disk i/o as paged mapped operations (as opposed to emulated real i/o
with CCWs, locking & unlocking pages, etc) and various enhancements
for sharing pages. recent posting
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1

part of the idea for my vmm work came from having been exposed to some
tss/360 at the university ... and part from some of the multics stuff
going on in the 5th floor ... science center and cp67 stuff was on
the 4th floor
http://www.garlic.com/~lynn/subtopic.html#545tech

the original r/o cms shared pages done on cp/67 was at the page level
(not segment) and store protect was handled by fiddling the storage
keys. cms didn't use storage keys ... so virtual machine with shared
pages had the psw and storage keys fiddled; shared pages always had
storage keys set to zero; if the virtual machine attempted to set
storage key for shared page it was ignored, if the virtual machine
attempted to set zero storage key for non-shared page it was redone to
x'F'. if the virtual machine attempted to load a psw with a zero
protect key, it was reset to x'F'.

for 370 virtual memory, there was all sorts of new hardware stuff
defined, including r/o segment protect and selective invalidate
instructions.  for r/o segment protect, the segment table entry (in
the virtual address space table) for a specific segment could have the
r/o bit turned on.  the segment table entry then pointed to a set of
pages in a page table. the kernel could setup address space tables so
that some of the page tables were the same across multiple address
spaces (aka shared). however, whether or not a particular virtual
address space had read/write or read/only access to a shared page
table was set in the address space (segment) table (aka you could have
a mix of address spaces with r/o and r/w sharing of the same page
table).

for the cms morph to 370 ... the shared pages were reorganized into
segment and was planning on using the new 370 r/o segment protect
facility. however, before 370 virtual memory was announced an issue
arose with 370/165 hardware support for virtual memory. an
esacallation meeting in pok, the 165 engineers said that it would take
an extra six months to implement segment protect and selective
invalidates.  the vs2 system people said that they had no need for
segment protect and that their system would never do more than five
page i/os per second and they could do batch page steal once a second
for that many pages (so the different of doing a global PTLB once a
second or doing five individual IPTEs once a second was negligable).
It was only vm370 that came out for segment protect and high paging
rates. the resolution was to drop the additional features from the 370
announcement so that virtual memory could support six months earlier.

this left cms in a bind ... the mechanism they were planning on using
for protecting shared segments disappeared from the machines. they
were forced to punt and return to the cp/67 mechanism of protecting
individual shared pages.

not too long latter, virtual machine assist (VMA) microcode assist was
introduced ... which included support for loading new PSWs in the
hardware (rather than taking a privilege interrupt into the cp kernel
and emulating the instruction). this and other VMA features
represented thruput enhancement (by doing some of the virtual machine
stuff directly in hardware rather than having to interrupt into the cp
kernel for everything). for cms, the problem was that the VMA
microcode assist didn't no about the fiddling rules for protect keys
and so VMA couldn't be turned on for CMS virtual machines running with
shared pages.

so coming up to vm/370 release 3, there was some work done to allow
CMS virtual machines to run with VMA. basically since there was no way
of actually protecting the shared pages ... the paradigm changed to
allow shared pages to be modified ... but catching such modifications
before any but the virtual machine making the change saw it. basically
on every task switch ... dispatcher would check to see if it was going
to stop running a virtual machine with shared pages. it would then
scan that virtual machine's virtual pages for any shared pages that
had been modified. if the dispatcher found any, it would unshare the
shared system (for the virtual machine that made the modifications)
and update the shared tables to indicate that the recently modified
page(s) weren't in real memory and would have to be paged in from
disk.

at this time, normal cms had a single shared segment with 16 shared
pages. on the avg. running a cms workload with VMA saved X percent cpu
... and checking 16 shared pages on every task switch cost Y percen
cpu ... where Y was normally less than X ... yielding an overall
thrput improvement of X-Y.

however, for actual vm/370 release 3, it was decided to also pickup a
subset of my VMM changes and release them as DCSS. Now part of the
changes picked up was that I had modified some amount of additional
CMS code to make it run in shared segment (rewritten part of the
standard cms editor to make the code shareable as well as some amount
of other code). so what shipped in release 3 was the DCSS changes
where CMS now normally ran with 32 shared pages and with VMA turned
on. However, doubling the number of shared pages, then doubled the
avg. checking overhead to 2*Y ... and while nominally Y<X; 2*Y was
nominally greater than X.

this was even further aggravated with shipping of multiprocessor
support. The checking gimmick was predicated on treating the shared
pages as private while a specific virtual machine was actually running
... and then catching and fixing any changes before switching to a
different virtual machine. with 2-way smp support, you could now have
two virtual machines running concurrently ... simultaneously accessing
the same shared pages (violating the priniciples of the gimmick).  so
to perpetuate the fixup gimmick, real processor specific shared
segments/pages were defined. now, in addition to checking whether the
previous virtual machine had modified any shared pages ... before you
went to run a new virtual machine, you had to check whether the new
virtual machine had its virtual memory table entries pointing to the
shared segments specific for the processor it was about to run on.
Now, not only was 2*Y>X (i.e. overhead greater than savings from using
VMA), but the processor specific page table pointer fiddling really
blew it out of the water.

the posting reference above
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1

i had made the full vmm changes available internally before vm370 release 3,
and they were running at places like HONE
http://www.garlic.com/~lynn/subtopic.html#hone

and was using it along with extensive use of the APL interpreter
running with something like 64 shared pages. the release 3 gimmick for
using VMA would mean that HONE was having to check nearly 100 shared
pages on every task switch. furthermore, since they workload was
heavily apl interpreter execution bound ... VMA assist provided them
negligible thruput improvement.

other random past posts about dcss, dmksnt, loadsys, etc:
http://www.garlic.com/~lynn/99.html#149 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/2000.html#75 Mainframe operating systems
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003e.html#12 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003n.html#5 "Personal Computer" Re: Why haven't the email bobmers been shut down
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2003o.html#42 misc. dmksnt
http://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
http://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#11 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2005b.html#8 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005g.html#30 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005t.html#39 FULIST

random past posts mentioning 165 problem with implementing
the full 370 virtual memory architecture:
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#204 Core (word usage) was anti-equipment etc
http://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing not 32 bit?
http://www.garlic.com/~lynn/2001c.html#7 LINUS for S/390
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002m.html#2 Handling variable page sizes?
http://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs
http://www.garlic.com/~lynn/2002n.html#23 Tweaking old computers?
http://www.garlic.com/~lynn/2003g.html#19 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2005b.html#62 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#1 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#51 winscape?

--
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: Tue, 17 Jan 2006 15:55:27 -0700

hzmonte writes:

What I meant by "SMP" is the "traditional" SMP, the "pre-multicore"
SMPs.  That is, a computer with more than one sockets on its mothrboard
and each socket houses a processor and each processor has one core.  In
other words, how does one compare a computer with 2 single-core
processors with one that with one dual-core processor, for instance?
Note that I am not comparing with two computers each with a single-core
processor.  How about a computer with a quad-core processor and a
computer with 2 dual-core processors?

how 'bout the "traditional" SMP, the pre-LSI, pre-VLSI SMPs ... that
is a computer that filled a whole room

how do you compare a computer made up of chip technology that had 4
circuits per chip? say a two-processor 370/168smp.

how do you compare a processor chip with off-chip cache that is
shared with with another processor chip on the same board?
possibly in a configuration with 8 such boards (16 processors)
sharing memory?

how do you compare a chip with two independent processors sharing
onchip cache as well as offchip cache.

logically ...  the operational design may be identical ...
differences are possibly latency and level of circuit integration.

how 'bout if you don't bother to slice & dice the wafer ... just leave
all the chips in single piece of silicon wafer ... lets go for
thousands of "cores" on single piece of silicon?

how 'bout hercules emulating a 370/168smp but is running on current
dual-core processor.

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

S/360

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360
Newsgroups: comp.lang.pl1,comp.lang.asm370
Date: Tue, 17 Jan 2006 16:37:33 -0700

"robin" writes:

FYI, our s/360 was slower than the machine that it replaced for
small jobs -- yet the machine it replaced was 50 times slower (add
time 64uS).  When LCS was put on the S/360, it ran even slower,
because the OS took up most of the fast memory, so that user
programs were loaded into slow memory.

our 360/67 at the univ. had significantly worse thruput than the 709
(tube machine) that it replaced. the 360/67 had 8-byte wide 750ns
memory (and instruction) cycle time (compared to 360/50 2-byte 2mic
memory, and most LCS was 8mic). 360/67 was essentially a 360/65 that
had virtual memory hardware bolted on.

a dominate workload was fortran student jobs ... there was 1401
front-end that handled unitrecord<->tape ... and you carried tapes
between the 1401 and 709 (this was 40 yrs ago, 1966). the 709 fortran
monitor ran student jobs (tape to tape) at a couple seconds per.

360/67 came in with os/360 and 2311 disks. job processing was
synchronous with unit record process ... read the cards ... write stuff
to disk, read stuff from disk, eventually execute ... print output
... do the next job. this was taking minutes per student job. most of
the time 360/67 ran as non-virtual memory 360/65 with vanilla os/360.
the 67 associative array hardware lookup (virtual to real address
translation) did add 150ns to 750ns basic memory cycle (900ms total).

by os/mft11 release, the univ got HASP, which decoupled the unit
record processing from the job execution. the other operating system
gorp of moving lots of stuff back&forth between memory and disk was
still resulting in student fortran job processing taking over 30
seconds.

i did a lot of detailed analysis and careful construction/placement of
operating system stuff on disk for optimized arm seek operation and
got the typical student fortran job elapsed time to a little under 12
seconds (still longer than they had run on 709) ... but almost three
times faster than it had been taking.

it wasn't until we got watfor monitor from univ. of waterloo that
student fortran job thruput started to exceed what it had been on the
709.

i gave talk at fall '68 share meeting in boston on both the
optimization work on os/360 as well extensive kernel rewrites that i
had done to cp/67 (i was still undergraduate) ... previous posting
referencing part of that talk
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14

for a little drift ... i had done some of the work on gcard ...
an ios3270 version of the 360 green card ... and just recently
did something of a rough conversion to html
http://www.garlic.com/~lynn/gcard.html

and of course, the 360 functional characteristics documents game
detailed machine timings ... several have been scanned and are
available here (including 360/65, 360/67, 360/91, and 360/195):
http://bitsavers.trailing-edge.com/pdf/ibm/360/funcChar/
http://www.bitsavers.org/pdf/ibm/360/funcChar/

--
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: Thu, 19 Jan 2006 01:44:55 -0700

"Del Cecchi" writes:

Please look up SMP.  It is a architectural term, not a term related to
construction as you used it.  Lynn tried to point that out to you in his
own way, as did I.  If you can't understand this then perhaps you need to
do some studying.  And for a newbie to tell someone who has been
participating a while what to do is presumptuous.  So please don't
display your ignorance.  Thank you for playing.

i was always told respect was something that had to be earned.

it used to be that the rash of newbie questions coincided with new
semester ... kids getting access to newsgroups from some campus
terminal for the first time ... and asking questions which frequently
turned out to be some homework assignment. there may be all sort or
newsgroups where novice and homework type questions are considered
appropriate ... however, it isn't normally considered as such here
(and was treated very unkindly ... trying to nip the disease in the
bud so to speak, making an example tended to be a good thing).

misc. collected past postings on tightly-coupled, multiprocessor, smp,
compare&swap, etc (including multiple references that compare&swap
was chosen because we had to come up with something that stood
for charlie's initials CAS):
http://www.garlic.com/~lynn/subtopic.html#smp

and various references to my pet VAMPS smp project (which was
canceled before announcement, we were told because we could only
forcast a $8-9b revenue over five years and the minimum requirement was
$10b revenue over five years)
http://www.garlic.com/~lynn/subtopic.html#bounce

previous posts in this thread:
http://www.garlic.com/~lynn/2006.html#14 Would multi-core replace SMPs?

there use to be a taxonomy of

tightly-coupled multiprocessing ... where SMP was either symmetrical
multiprocessing or shared memory processing. in the past there were
some genre of asymmetrical multiprocessors ... collections of shared
memory processors but not all with i/o capability (thus the reference
asymmetric, there were also sometimes called attached processors).
then there is the numa variety of shared memory processing. a
recent posting mentioning numa:
http://www.garlic.com/~lynn/2005v.html#0 DMV systems?

closely-coupled multiprocessing .... didn't tend to have cache
consistency, but data and serialization could be done with memory
access type semantics (but were all in software). say a collection of
3090-type processors that didn't share normal instruction/data memory
but might have a shared extended-store type box. some similarities to
numa ... but different.

loosely-coupled multiprocessing ... frequently referred to as clusters
these day ... data sharing and serialization was achieved with
io/message-passing semantics. also big in GRID.

...

my wife did get con'ed into doing a stint in pok in charge of
loosely-coupled architecture where she came up with peer-coupled
shared data architecture
http://www.garlic.com/~lynn/subtopic.html#shareddata

then again, she also got con'ed into doing a stint as manager in
rios/6000 engineering architecture in austin. misc. 801, romp, rios,
power, 6000, fort knox, etc postings
http://www.garlic.com/~lynn/subtopic.html#801

we used some of this background when we came up with 3-tier
architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier

and later when we were doing the ha/cmp (high availability, cluster
multiprocessing) product
http://www.garlic.com/~lynn/subtopic.html#hacmp

then again ... some of the 3-tier architecture and ha/cmp was also
outgrowth of the high-speed backbone
http://www.garlic.com/~lynn/subnetwork.html#hsdt

we operated on the internal network:
http://www.garlic.com/~lynn/subnetwork.html#internalnet

minor reference:
http://www.garlic.com/~lynn/internet.htm#0

of course it was also very valuable when we were working with this
small client/server startup that wanted to do payment transactions on
their server ... and there was a need for something called a payment
gateway on the internet
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

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

{SPAM?} DCSS as SWAP disk for z/Linux

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: {SPAM?} DCSS as SWAP disk for z/Linux
Newsgroups: bit.listserv.vmesa-l
Date: Thu, 19 Jan 2006 15:30:18 -0700

Rob van der Heij writes:

From a pure technical point of view, swapping to DCSS is much more
elegant because you copy a page under SIE and don't step out to CP to
interpret a channel program. But the drawback is that the DCSS is
relatively small and requires additional management structures in the
Linux virtual machine memory. I see some goodness for very small
virtual machines, I think.

in one sense it is like extended memory on 3090 ... fast memory move
operations. however, real extended memory was real storage.  dcss is
just another part of virtual memory. in theory you could achieve
similar operational characteristics just by setting up linux to have
larger virtual memory by the amount that would have gone to dcss
... and having linux rope it off and treat that range of memory the
same way it might treat a range of dcss memory. minor drift, recent
post mentiond 3090 extended memory
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?

the original point of dcss was having some virtual memory semantics
that allowed definition of some stuff that appeared in multiple
virtual address spaces ... recent post discussing some of the dcss
history
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1

if the virtual space range only occupies a single virtual address
space ... for most practical purposes, what is the difference between
that and just having equivalent virtual space range as non-DCSS (but
treated by linux in the same way that you would treat a DCSS space).

note that in the originally virtual memory management implementation
... only a small subset was picked up for the original DCSS
implemenation, a virtual machine could arbitrarily changes its
allocated segments (contiguous or non-contiguous) ... so long as it
didn't exceed its aggregate resource limit. however, the original
implementation also included support for extremely simplified api and
veriy high performance page mapped disk access (on which page mapped
filesystem was layered)
http://www.garlic.com/~lynn/subtopic.html#mmap

... and sharing across multiple virtual address spaces could be done
as part of the page mapped semantics (aka create a module on a page
mapped disk ... and then the cms loading of that module included
directives about shared segment semantics).

note that one of the issues in unix-based infrastructure ... is that
the unix-flavored kernels may already be using 1/3 to 1/2 of their
(supposedly) real storage for various kinds of caching (which
basically gets you very quickly into 3-level paging logic ... the
stuff linux is using currently, the stuff it has decided to save in
its own cache, and the total stuff that vm is deciding to keep in real
storage). for linux operation in constrained virtual machine memory
sizes, you might get as much or better improvement by tuning its own
internal cache operation.

one of the things i pointed out long ago and far away about running a
lru-algorithm under a lru-algorithm ... is that that things can get
into pathelogical situations (back in the original days of mft/mvt
adding virtual memory for original vs1 & vs2). the cp kernel has
selected a page for replacement based on its not having been used
recently ... however, the virtual machine page manager also discovers
that it needs to replace a page and picks the very same page as the
next one to use (because both algorithms are using the same "use"
criteria). the issue is that both implementations are using the least
used characteristic for the basis for replacement decision. the first
level system is removing the virtual machine page because it believes
it is not going to be used in the near future. however, the virtual
machine is choosing the least recently used page to be the next page
that is used (as opposed to be the next page not to be used).

running a LRU page replacement algorithm under a LRU page replacement
aglorithm is not just an issue of processing overhead ... there is
also the characteristic that LRU algorithm doesn't recurse gracefully
(i.e. a virtual LRU algorithm starts to take on characteristics of an
MRU algorithm to the 1st level algorithm ... i.e. the least recently
used page is the next most likely to be used instead of the least
likely to be used). misc. past stuff about page replacement work ...
originally done as undergraduate for cp67 in the 60s
http://www.garlic.com/~lynn/subtopic.html#wsclock

some specific past posts on LRU algorithm running under LRU algorithm
http://www.garlic.com/~lynn/94.html#01 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#51 Rethinking Virtual Memory
http://www.garlic.com/~lynn/95.html#2 Why is there only VM/370?
http://www.garlic.com/~lynn/96.html#10 Caches, (Random and LRU strategies)
http://www.garlic.com/~lynn/96.html#11 Caches, (Random and LRU strategies)
http://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001f.html#54 any 70's era supercomputers that ran as slow as today's  supercomputers?
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/2002p.html#4 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2003c.html#13 Unused address bits
http://www.garlic.com/~lynn/2003j.html#25 Idea for secure login
http://www.garlic.com/~lynn/2004l.html#66 Lock-free algorithms
http://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005n.html#21 Code density and performance?

with respect to this particular scenario or 2nd level disk access
... one of the characteristics of this long ago and far away page
mapped semantics for high performance disk access (originally done on
cp/67 base) was that it could be used by any virtual machine for all
of their disk accesses (at least those involving page size chunks)
whether it was filesystem or swapping area.

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

DCSS as SWAP disk for z/Linux

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCSS as SWAP disk for z/Linux
Newsgroups: bit.listserv.vmesa-l
Date: Fri, 20 Jan 2006 16:43:33 -0700

Adam Thornton writes:

Yes.  You save a few megabytes per image.

It makes maintenance more difficult, though.

in the original virtual memory mapped paged-map implementation (that
predated DCSS, vm/370 release 3 just picked up a small subset), the
source of the system was on standard virtual machine accessed disk
that was accessed using page mapped semantics. infrastructure layered
on top could be standard filesystem semantics ... and the object
loaded could be managed with standard filesystem operation (the load
command specified both the mapping between paged mapped disk and
virtual address space as well as any sharing options ... with various
kinds of integrity rules applied).

the issue for cms then easily becomes having multiply managed kernel
image ... you create a new kernel image at a new location and update
the boot information to point to the latest kernel image location.
people booting cms after the boot pointer change get the new image,
people that had the earlier kernel image have the previous kernel
image.
http://www.garlic.com/~lynn/subtopic.html#mmap

in theory, linux kernel images and maint. could be handled in a
similar way ... just create a new boot image in a new location.

translated to conventional dcss methodology ... this requires
multiple, similarly named (say linux01-linux-05), systems. maint
process cycles thru the different names.

virtual machines then are modified to load a named system ... say
linuxredirect ... which is just a trivial piece of redirection code
which does the actual loading of named systems. the redirection code
is updated after some maint. process and the appropriate images have
been saved to available place.

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

DCSS as SWAP disk for z/Linux

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCSS as SWAP disk for z/Linux
Newsgroups: bit.listserv.vmesa-l
Date: Fri, 20 Jan 2006 22:08:06 -0700

Rick Troth writes:

Sounds a lot like XIP,  which is based on EXT2.
Define a partition of the same size as the intended DCSS
(or slightly less),  put your stuff there,  unmount it,
use 'dd' or something like it to grab a snap-shot,  and store.

there was science center
http://www.garlic.com/~lynn/subtopic.html#545tech

report done on the initial port of vmm from cp67 to vm370

L. Wheeler, CSC VM/370 Extended II: Virtual Memory Management, IBM
Science Center Report ZZ20-6002, July 1974, 19 pp., shared segments,
migration.

the dcss subset of vmm
http://www.garlic.com/~lynn/subtopic.html#mmap

was then done for vm/370 release 3, 30 years ago.

vmm also included a lot of work on address independent
code:
http://www.garlic.com/~lynn/subtopic.html#adcon

mmap support allowed the use of the kernel paging support to directly
read/write any standard disk area. it eliminated a lot of the overhead
of simulating virtual i/o (among other things).

a little drift, i included some part of "migration" in the resource
manager.
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

from above (taken from the "blue" letter):

Enhancements are made to VM/370 in these areas:

Scheduling ALgorithm. A fair share approach to distribute the
resources of the system equally among the users with improved
interactive performance on trivial commands.

Page Migration. Designation of preferred paging areas on DASD with
migration to other devices is based on how long the pages are unused.

Swaptable Migration. Seldom used segment tables are swapped to DASD
thereby freeing up main storage.

Reset Pages and Time Stamp Segments. The working set algorithm
improves page selection, while time stamping facilitates page
migration and swaptable migration.

Working Set Estimate. Dynamically adjusted multiprogramming levels are
achieved by periodic evaluation of total system performance based on
feedback control.

Fast Redispatch Extension. The number of cases where fast redispatch
implementation is used after privileged instruction simulation and I/O
interruptions are increased.

Enable Window. It increases the extent to which VM/370 runs enabled and
thus can accept I/O and external interruptions

Set Favored Extension. The specification of multiple users with the
set favored percent option is provided.

Indicate Command Extension. Additional performance status data is made
available to the systems performance evaluation routine.

Selective Path Length Reductions.

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

multiple firefox with different profiles

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: multiple firefox with different profiles
Newsgroups: netscape.public.mozilla.browser
Date: Sat, 21 Jan 2006 09:06:12 -0700

firefox 1.5.0.1, 200601011

i have two machines, firefox is running on both. if i x-windows from
one machine to another via ssh tunnel, and try and start a 3rd
firefox, it aborts after saying something about already present.

if i kill firefox on the target machine and try and restart firefox,
it says the same thing. if i have firefox running on the target
machine and not on the x-windows machine ... and do a firefox
(profile) start ... i can run two different firefox simulataneously on
the same machine (with different profiles) as long as the windows are
on different x-window displays.

at startup, there seems to be some early checking for window display
with the same name(?) ... even before it checks for -profilemanager
option.

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

IBM up for grabs?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM up for grabs?
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Mon, 23 Jan 2006 08:50:14 -0700

bob.shannon@ibm-main.lst (Bob Shannon) writes:

You didn't say where. IBM sold its Cottle Road facility in San Jose. I
can't imagine how much it sold for, but given the value of property in
Silicon Valley, and given the potential cost of cleanup after 50 years
of disk manufacturing, they probably made out pretty well. I believe
the employees moved to SVL.

before they sold the cottle rd facility (to hitachi)
http://www.hitachigst.com/portal/site/sanjosesite/menuitem.fc9e54fd8b6d6fa7b8c22714bac4f0a0/
http://www.hitachigst.com/portal/site/en/?epi_menuItemID=58b0ea6df4571f8056fb11f0aac4f0a0&epi_menuID=3d0cb215112b6934ab937c27aac4f0a0&epi_baseMenuID=3d0cb215112b6934ab937c27aac4f0a0
http://www.hoovers.com/hitachi-global-storage/--ID__107188--/freeuk-co-factsheet.xhtml

... when 85 cut thru the middle of the property, the plant rec area
came up on the other side of 85 ... as a result they had to put in a
special underpass between the main facility and the rec area. shortly
afterwards they sold off the rec area for development and it turned
into apts/condos ... and they filled in the underpass. in the same
time they sold off los gatos lab.  (along with something like 200
acres of open land) ... which got torn down and turned into housing
development.

more recently, hitachi cutting site from 332 acres to 150 acres
http://evergreentimes.com/100705/hitachi.htm

earlier, there had been consolidation of a number of a off-site leased
bldgs adjacent to main plant site (bldgs, 86, 96, 97, 98, etc which
also came up on the other side of hiway 85 when it was built).

in the mid-80s there was a predication that ibm world-wide business
was going to double ($60b/annuum to $120b/annum) and there was a
massive manufacturing facility construction program. one of those was
large (disk manufacturing) bldg. 50 on the main plant site. in the
later downsizing from the offsite bldgs, some were consolidated into
offices in bldg. 50 and others to santa teresa lab (bldg. 90, some 10
miles to the south). slightly related
http://www.garlic.com/~lynn/2005j.html#32 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005s.html#16 Is a Hurricane about to hit IBM ?

one of the groups that got moved into bldg. 50 was the adsm group (much
of the organizations had previously been in bldg. 98). adsm had morphed
from workstation datasave faciilty (and has now been renamed tsm).
workstation datasave facility had grown out of a backup/archive
system i had written and deployed internally.
http://www.garlic.com/~lynn/subtopic.html#backup

santa teresa lab has been renamed silicon valley lab:
http://www.ajnordley.com/IBM/Air/SVL/

in the photos from the above ... you can sort of see that the lab. was
built on a marsh that got extremely wet during the rainy season from
run-off (both surface and sub-surface) off the nearby hills. the
datacenter is below ground and when it was first built ... they had
significant water seepage problems into the machine room (separate
from the later flooding problems mentioned in the above). I found the
problem somewhat interesting since during college, I had a summer job
as foreman on a construction project that was located on similar
terrain ... large surface and sub-surface drains had been installed to
divert the water flow around the site.

past postings about the naming of the santa teresa lab.:
http://www.garlic.com/~lynn/2000b.html#56 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001g.html#34 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#37 Thread drift: Coyote Union (or Coyote Ugly?)
http://www.garlic.com/~lynn/2001i.html#11 YKYGOW...
http://www.garlic.com/~lynn/2002j.html#6 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002o.html#11 Home mainframes
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/2003b.html#63 When/why did "programming" become "software development?"
http://www.garlic.com/~lynn/2003e.html#60 reviving Multics -- Computer Museum
http://www.garlic.com/~lynn/2003i.html#25 TGV in the USA?
http://www.garlic.com/~lynn/2003m.html#14 Seven of Nine
http://www.garlic.com/~lynn/2003o.html#10 IS CP/M an OS?
http://www.garlic.com/~lynn/2003p.html#32 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E
http://www.garlic.com/~lynn/2004e.html#12 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
http://www.garlic.com/~lynn/2004m.html#6 a history question
http://www.garlic.com/~lynn/2005.html#25 Network databases
http://www.garlic.com/~lynn/2005m.html#21 Old Computers and Moisture don't mix - fairly  OT
http://www.garlic.com/~lynn/2005m.html#22 Old Computers and Moisture don't mix - fairly  OT

past postings about filling up stl and having to move something like 300
from the ims group to "new" offsite bldgs. 96/97
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#14 mainframe tcp/ip
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#34 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2003c.html#72 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003d.html#24 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005e.html#21 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#14 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#45 winscape?
http://www.garlic.com/~lynn/2005t.html#45 FULIST
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances
http://www.garlic.com/~lynn/2005u.html#23 Channel Distances

IBM up for grabs?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM up for grabs?
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Mon, 23 Jan 2006 10:49:29 -0700

Anne & Lynn Wheeler wrote:

in the mid-80s there was a predication that ibm world-wide business
was going to double ($60b/annuum to $120b/annum) and there was a
massive manufacturing construction program. one of those was large
bldg. 50 on the main plant site. in the later downsizing from the
offsite bldgs, some were consolidating into offices in bldg. 50 and
others to santa teresa lab (bldg. 90, some 10 miles to the south).

ref:
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?

some other pictures from site referenced in previous article ... cottle
road site:
http://www.ajnordley.com/IBM/Air/SSD/index.html

in the plant site picture from the air ....  hiway 85 crosses the
picutre from top left center ... to mid-left edge. the railroad and
old hiway 101 (monterey rd) is from right center edge to bottom
middle.

you can just make out cottle rd overpass on hiway 85, horizontal
towards the top of the picture. most of the "old" plant site is top
half of the picture along cottle. including bldg. 10, 12, 14, 15, 26,
etc. various stories about disk engineering work in bldg. 14 & 15
http://www.garlic.com/~lynn/subtopic.html#disk

and the "old" sjr bldg 28 ... where the original relational/sql work was
done (bracketed by the intersection of cottle & hiway 85):
http://www.garlic.com/~lynn/subtopic.html#systemr

this was before new almaden research facility was built up the hill
http://www.ajnordley.com/IBM/Air/ARC/index.html

if cottle road were to be extended straight up the hill ... it would
almost intersect the almaden facility (but cottle terminates at the
bottom of the hill). to get to almaden research (from cottle rd
facility) ... you take the bernal rd thru santa teresa county park
(the other access is via harry rd from the almaden valley side). in
the right middle and bottom left pictures, harry road is seen heading
down into almaden valley (towards the top of the pictures) and bernal
road heading off to the right

in the cottle rd image
http://www.ajnordley.com/IBM/Air/SSD/index.html

the large bldg. in the left center of the image is bldg. 50 built in
the mid-80s (as part of the huge manufacturing expansion) for disk
manufacturing. in the later downsizing, the offices in 50 was used to
absorb some number of the people from off-site leased bldgs.

auto industry

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: auto industry
Newsgroups: alt.folklore.computers
Date: Mon, 23 Jan 2006 15:55:25 -0700

news report today claimed that auto industry restructuring includes
remaking them more competive and agile, trying to reduce elapsed time
from concept to showroom to 3yrs.

in the late 80s, there were statements about leveraging IT (and other
technology) for remaking themselves more competitive and agile,
reducing elapsed time from concept to showroom to 18-36 months
... compareable to that of some of the foreign imports (zoom forward
15+ yrs and the objective is now only 3yrs).

sometime around 1980, there was an article in east coast paper
(washington post?) proposing unearned profit tax on the auto
industry. supposedly the foreign auto import quotas were to provide
the american auto industry breathing room to restructure and remake
themselves more competitive (and agile?) ... the article said instead,
they were taking the increased profits (that they were making in the
wake of the import quotas) and paying it out in dividends, bonuses,
and salaries (rather than investing in restructuring). of course,
agility is major boyd & OODA-loop theme
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

past posts mentioning c4, import quotas, unearned profit tax, etc.
http://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2001d.html#43 Economic Factors on Automation
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2003i.html#61 TGV in the USA?
http://www.garlic.com/~lynn/2003k.html#61 The Incredible Shrinking Legacy Workforces
http://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004c.html#51 [OT] Lockheed puts F-16 manuals online
http://www.garlic.com/~lynn/2004e.html#22 Pre-relational, post-relational, 1968 CODASYL "Survey of Data  Base Systems"
http://www.garlic.com/~lynn/2004h.html#22 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005s.html#2 Internet today -- what's left for hobbiests

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

IBM up for grabs?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM up for grabs?
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Wed, 25 Jan 2006 08:43:09 -0700

Joe Morris writes:

Sigh...when did this happen?  I've never been to Santa Teresa, but
I've got fond memories of its name, courtesy of the SHARE button
that John Ehrman created many years ago:

Santa Teresa
Ora pro nobis

and there is the story about renaming Santa Teresa Lab at the last moment.

i was on trip to DC the week before smithsonian air & space museum
(and santa teresa lab) were to open. normal corporate naming process
was for the closest post office. however, the week before the opening,
there was a demonstration on the steps of the capital by a group of
working ladies from san francisco who belonged to coyote organization
(which happened to also be the name of the closest post office to the
new facility). santa teresa is the name of the closest cross-street.

refs:
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs
http://www.garlic.com/~lynn/2006.html#22 IBM up for grabs

way back when, when i needed to do some stuff at stl, i would
periodically ride my bike from cottle to stl ... on santa teresa
(closest north/south street).

i objected to there being a head wind going south in the morning and
also a head wind coming back north in the afternoon. especially during
the summer there is interesting wind pattern between the hills on both
sides of the valley. in the morning the hotter air rising over the bay
pulls air from the south valley. By the afternoon, sun heating in the
south valley reverses the wind pattern (with the hotter rising air in
the south valley pulling air from the bay). the hills also form a
narrowing of the valley about half way between cottle and bailey
... the constriction accentuating the wind.

in the summer, the morning wind also can bring the strong smell of the
garlic fields around gilroy ("garlic" capital of the world).

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

DCSS as SWAP disk for z/Linux

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCSS as SWAP disk for z/Linux
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Thu, 26 Jan 2006 01:00:33 -0700

The following is from a presentation made on 86.10.07 at the SEAS
meeting on Jersey. List of SEAS meetings:
http://www.daube.ch/share/seas01.html#places

It describes a series of test on production VM/370 release 6 system
comparing PAM/CDF, PAM/EDF, and 4k/EDF. Lots of past PAM references
http://www.garlic.com/~lynn/subtopic.html#mmap

                    Comparison of PAM, CDF and EDF

            pam/cdf         pam/edf        4k/edf
runl     2.89/39l0/33.   3.28/4103/4l.   3 72/1978/95.
run2     2.90/3768/49.   3.32/4ll5/54.   3.65/1965/79.
run3     3.01/3749/47.   3.35/4l23/8l.   3.66/1932/77.
runq     2.94/4033/34.   3.46/3975/46.   3.66/1920/63.
run5     3.0l/3472/36.   3.62/3884/68.   3.75/1948/85.
run6     3.08/3776/70.   3.46/3784/60.   3.79/1986/84.
run7     3.l3/3740/57.   3.37/3979/46.   3.75/1977/84
run8     2.99/3868/87.   3.4l/3836/52..  3.77/1958/88.

system     CPU      I/O    elapsed
           avg.     avg.    avg.
4k/EDF    3.72     1958      81.
PAM/EDF   3.4l     3836      56.
PAM/CDF   3.02     3790      52.

         (min.)   (min.)   (min.)
4k/EDF    3.66     1920      63.
PAM/EDF   3.28     3784      41.
PAM/CDF   2.89     3472      33.

4k/EDF is the EDF CMS filesystem introduced in VM/370 release 6 used
with 4k block option.

PAM/CDF is the original CMS filesystem modified to use 4K records
rather than 800 and page-map interface.

PAM/EDF is the EDF CMS filesystem modified to use the page-map interface.

CPU is total (combination of virtual and supervisor).

The test was run on standard production system with other activity.  A
run consisted of doing the same exact operations involving pam/cdf
filesystem, then pam/edf filesystem, then 4k/edf filesystem. This was
repeated eight times and the avg. values and the minimum values used.

There is not a direct comparison between 4k/edf i/o and pam i/o.  For
4k/edf, I/O is reported as the number of virtual i/o operations
(independent of number of records transferred). There is slight
variability in 4k/edf i/o based on state of the filesystem and the
number of contiguous records that might be involved for operation.
For pam i/o, reported is the number of 4k page transfers (which might
also include other paging operations for the virtual machine during
the period and doesn't directly indicate the number of physical i/o
operations).

Both PAM test performed better than 4k/edf because of 1) reduced CP
overhead for supporting the operation, 2) better CP logic for chaining
multiple 4k transfers in single I/O,

The minimum values are going to be closest to base operation excluding
interferance from other workload on the system. pam/cdf is nearly
twice as fast and approx. 1/4 less cpu for the workload compared to
the same workload running on 4k/edf filesystem.

When the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

eventually replaced its 360/67 with 370/155, there was a port of a lot
of local modifications from cp67 to vm370. another page from the same
SEAS presentation

Release 2.15 CSC/VM

• Relocatable (floating) Shared Segments
• Paging Access Method (PAM)
• CP/67 Feedback controls
• CP/67 Working Set controls
• CP/67 Global LRU Page Replacement
• CP/67 Fastpath
• Restructured Page Supervisor
• Page and Swaptable Migration
• Q3
• Scheduling based on resource objectives
• Resource objectives either fixed or fairshare

note that much of this, I subsequently released in the resource
manager ... blue letter reference in recent posting
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux

a small subset of the cms & cp relocatable (floating) shared segments
http://www.garlic.com/~lynn/subtopic.html#adcon

(w/o paged-map support) had been released as DCSS (prior to the
resource manager release).

a couple other posts in this thread:
http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux

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

IBM microwave application--early data communications

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM microwave application--early data communications
Newsgroups: alt.folklore.computers
Date: Thu, 26 Jan 2006 09:33:33 -0700

"Tim Shoppa" writes:

It's at 41st and Wisconsin in NW DC. It is still standing. Although the
concrete tower is dwarfed by the big metal towers in the area around
it, it looks like the concrete structure could withstand anything but a
direct nuclear blast. Some of the ancillary buildings around the tower
have been torn down/rebuilt in the past decade.

The neighborhood that the tower is in is dominated by TV and radio
stations. The industrial warehouses and workshops on Wisconsin have
generally been converted into retail use over the past couple of
decades (although there are still a few car dealerships in that
neighborhood.)

AT&T had a microwave tower built from concrete on a high point in my
old neighborhood.  It was later replaced by a steel tower.  Indeed,
given the changes in the telecom world, I wonder if it is still there.

It looks to me that the concrete WU tower may be too hard to tear down
:-).

isn't there a big unfinished half-built tower off of connecticut(?)
somewhere around friendship hills(?) ... behind a whole foods(?)
store.

sometime in the early 70s(?, late 60s?), san jose had put in
(microwave) T3 (44mbits) collins digital radio. roof of bldg. 12 (on
the main plant site) had dishes to a repeater tower on the hill above
santa teresa lab (and down to STL) and to a repeater tower above los
gatos lab (and down to bldg. 29). there were a number of subchannels
split on T3. this is standard c-band ... when (elevated section) 85
was built, some number of people noted radar detectors being tripped
when passing line-of-site between bldg. 12 and the tower above STL
(tower above lsg went when that site was sold off for housing
development).

when almaden was built, something like six fiber pairs were run from
main plant site up the hill (instead of doing microwave), i believe
the drivers were initially oc3.

recent postings on main plant site, stl, almaden
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006.html#22 IBM up for grabs?
http://www.garlic.com/~lynn/2006.html#24 IBM up for grabs?

when ibm formed sbs (with comsat and aetna), there were something like
a dozen or two 10m dishes put into major sites around the US that ran
T3, this was also c-band. there was some runs-ins with the MIB when
the data aggregator (aggravator) was built and installed on the
network (doing bulk T3 encryption).

misc. past posts mention collins digital radio
http://www.garlic.com/~lynn/2000b.html#57 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2002q.html#45 ibm time machine in new york times?
http://www.garlic.com/~lynn/2003k.html#3 Ping:  Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E
http://www.garlic.com/~lynn/2005n.html#17 Communications Computers - Data communications over telegraph

when big part of the ims group was moved out of STL to off-site
(leased) bldgs (96 & 97), instead of doing traditional remote 3270 for
access back into stl datacenter (really, really slow and tortuous), we
put in T1 channel extenders (using HYPERChannel) and ran "local" 3270s
at the site (subchannel over the T3 stl/bldg12 and the microwave
tail-circuit from bldg12 to bldg98 (and wires into the two adjacent
bldgs). detailed discussion:
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances

this was essentially one of the first hsdt (high-speed data transport)
projects.
http://www.garlic.com/~lynn/subnetwork.html#hsdt

we also did a number of terrestrial and satellite high-speed links.
in conjunction with sbs, hsdt designed a new tdma earth station and
put in an three-node satellite dish network with lots of high-speed
terrestrial circuits. it had 4.5m dishes at los gatos lab and ykt
research and a 7m dish in austin. this used a ku-band transponder on
sbs-4.

misc. past posts mentioning hsdt & ku-band on sbs-4:
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/94.html#25 CP spooling & programming technology
http://www.garlic.com/~lynn/2000b.html#27 Tysons Corner, Virginia
http://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
http://www.garlic.com/~lynn/2003j.html#29 IBM 3725 Comms. controller - Worth saving?
http://www.garlic.com/~lynn/2003j.html#76 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2003k.html#3 Ping:  Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2005h.html#21 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD -

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

IBM microwave application--early data communications

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM microwave application--early data communications
Newsgroups: alt.folklore.computers
Date: Thu, 26 Jan 2006 11:02:22 -0700

"Tim Shoppa" writes:

That is the site exactly. Although from my usual perspective it's in
front of the whole foods. Several of the warehouses have been converted
into big-box stores in the past year-and-a-half.

re:
http://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications

random trivia drift ... the 7m hsdt tdma dish in austin was about a
mile up (north) burnet (several miles south of round rock and dell)
from the orignal whole foods at the intersection of burnet and 183

it was more like a medium sized health food store ... the big guys
like HEB had already started the super sized store craze.

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

DCSS as SWAP disk for z/Linux

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCSS as SWAP disk for z/Linux
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Thu, 26 Jan 2006 11:23:27 -0700

Anne & Lynn Wheeler writes:

The following is from a presentation made on 86.10.07 at the SEAS
meeting on Jersey. List of SEAS meetings:
http://www.daube.ch/share/seas01.html#places

re:
http://www.garlic.com/~lynn/2006.html#26 DCSS as SWAP disk for z/Linux

i couldn't find softcopy for my presentation ... so last night, i
scanned the hardcopy. the pdf isn't bad, but the ocr processing was
only about 80-90percent correct, i had to manually correct 10-20
percent of it.

I did find softcopy of the vm project agenda.

my talk was suppose to be on the history of vm performance ... dating
back to spring of '68 when i was an undergraduate (38 years now). I
had an hour and 60+ foils. i managed to only get thru the first couple
foils ... so we scheduled a bof during scids that night ... and i
talked from 6pm to midnight (room off scids, with interruptions for
refreshments).

SEAS OCT 6-10 1986, JERSEY, VM PROJECT.
_______________________________________

*----------------------------------------------------------*
| Monday 6th |1400-1445 | Introduction                     |
| October    |  and     | to the VM project                |
|            |1450-1535 |     Steve Bouch BT               |
|            |          |      (project chairman)          |
|            | 1.4V     | Show and Tell                    |
|            |  and     | VM-related announcements since   |
|            | 1.5V     | SM86                             |
|            |          |     Adrian Walmsley, IBM UK      |
|            |          | VM/SP Entry User experiences     |
|            |          |     Vlady Priplata               |
|            |----------+----------------------------------|
|            |1600-1645 | XA I/O Architecture Overview     |
|            |  and     |  functions used by VM and MVS    |
|            |1650-1735 |  IOCP and sysgen                 |
|            |          |  Adrian Walmsley, IBM UK         |
|            | 1.6V     |                                  |
|            |  and     | VM XA SF preferred guest planning|
|            | 1.7V     |  configuration, performance tools|
|            |          |  recovery                        |
|            |          |  Gisela Lotringer,               |
|            |          |                IBM South Africa  |
|            |          |  (joint with MVS project)        |
*----------------------------------------------------------*

*----------------------------------------------------------*
| Tuesday 7th|1400-1445 | IBM announcements                |
| October    |  and     |  Bob Knaus IBM Endicott          |
|            |1450-1535 | CMS Update                       |
|            |2.4V, 2.5V|  Dave Getson IBM Endicott        |
|            |----------+----------------------------------|
|            |1600-1645 | CMS Free Storage Management      |
|            | 2.6V     |   Stuart McRae                   |
|            |          |     Systems and Telecomms, UK    |
|            |----------+----------------------------------|
|            |1650-1735 | Using 7171s                      |
|            | 2.7V     |     nn, User                     |
*----------------------------------------------------------*

SEAS Oct 6-10 1986, Jersey, VM Project.                    1

*----------------------------------------------------------*
| Weds 8th   |1400-1445 | Electronic Mail                  |
| October    |          |   Stuart McRae                   |
|            |  3.4V    |     Systems and Telecomms        |
|            |          |   Dave Barker                    |
|            |          |     Rutherford Lab (?)           |
|            |          | (joint with OA project)          |
|            |----------+----------------------------------|
|            |1450-1535 | VM SECURE User experiences       |
|            |          |   Graham Taplin,                 |
|            |          |   Watson Calculating             |
|            |  3.5V    |   (joint with IM project)        |
|            |----------+----------------------------------|
|            |1660-1645 | Page mode printing on VM         |
|            |          |     Mike Kay                     |
|            |  3.6V    |     IBM Almaden  Research        |
|            |----------+----------------------------------|
|            |1650-1735 |  Business Session                |
|            |  3.7V    |  including IBM responses to      |
|            |          |  resolutions                     |
|            |          |      Bob Knaus IBM Endicott      |
*----------------------------------------------------------*

*----------------------------------------------------------*
| Thurs 9th  |1400-1445 | VM VTAM User Experiences         |
| October    |  4.4V    |    John Wilshaw, Metier          |
|            |----------+----------------------------------|
|            |1450-1535 | Automating Operations in VM      |
|            |  4.5V    |    nn, User  (BT ?)              |
|            |----------+----------------------------------|
|            |1600-1645 | Tape staging                     |
|            |  4.6V    |   nn, CERN, Geneva               |
|            |----------+----------------------------------|
|            |1650-1735 | Highly available VM systems      |
|            |  4.7V    |   Al Griefer, IBM Almaden Res.   |
*----------------------------------------------------------*

SEAS Oct 6-10 1986, Jersey, VM P