List of Archived Posts

2004 Newsgroup Postings (11/02 - 11/20)

CKD Disks?

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

CKD Disks?

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Multi-processor timing issue

Integer types for 128-bit addressing

some recent archeological threads in ibm-main, comp.arch, & alt.folklore.computers ... fyi

Integer types for 128-bit addressing

Multi-processor timing issue

360 longevity, was RISCs too close to hardware?

360 longevity, was RISCs too close to hardware?

360 longevity, was RISCs too close to hardware?

Integer types for 128-bit addressing

Integer types for 128-bit addressing

RISCs too close to hardware?

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Demo: Things in Hierarchies (w/o RM/SQL)

Demo: Things in Hierarchies (w/o RM/SQL)

CKD Disks?

pop secure connection

Integer types for 128-bit addressing

pop secure connection

Integer types for 128-bit addressing

z/OS UNIX

NEC drives

What system Release do you use... OS390? z/os? I'm a Vendor S

Integer types for 128-bit addressing

The Sling and the Stone & Certain to Win

Scanning old manuals

Integer types for 128-bit addressing

pop secure connection

Facilities "owned" by MVS

Facilities "owned" by MVS

Facilities "owned" by MVS

osi bits

how it works, the computer, 1971

360 longevity, was RISCs too close to hardware?

360 longevity, was RISCs too close to hardware?

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

360 longevity, was RISCs too close to hardware?

360 longevity, was RISCs too close to hardware?

evoluation (1.4) and ssl (FC2) update

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

Integer types for 128-bit addressing

JES2 NJE setup

360 longevity, was RISCs too close to hardware?

360 longevity, was RISCs too close to hardware?

360 longevity, was RISCs too close to hardware?

360 longevity, was RISCs too close to hardware?

360 longevity, was RISCs too close to hardware?

Integer types for 128-bit addressing

Relational vs network vs hierarchic databases

CKD Disks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CKD Disks?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 02 Nov 2004 09:18:52 -0700

bblack@ibm-main.lst (Bruce Black) writes:

Art, are you sure you didn't work for IBM ISAM? <gr> ISAM was famous
for using complicated, branching CKD CCW chains. The ISAM logic
manual had pages of such chains.

The downside of such search chains is that they tended to tie up the
channel and the disk while all this searching and seeking was going
on.  It was fine if only the one file was on the disk and there were
extra channels for other disks, but they were bad neighbors when
systems got bigger and busier.

as per previous post ... even multi-track search of pds directory
could tie up channel, controller, (string) and disk for extended
periods of time ... 3330 with 19tracks and 60rps was almost 1/3rd sec
per operation.
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?

this was trade-off of a one-level index (pds directory or vtoc) being
constantly scanned by I/O subsystem or keeping the index in memory.
With the real storage constraints of the mid-60s, the constant I/O
scanning appeared to be a reasonable IO-resource/memory-resource
trade-off. By the mid to late 70s ... the situation had exactly
reversed.

It wasn't just that ISAM CKD channel programs were long and
complicated ...  they were effectively implementing multi-level index
searches with expensive i/o scanning ... earlier reads could provide
the subsequent seek&search CCHHR for subsequent CCWs.

recent post about having to spend a week (back in 1970) at a customer
site working on an ISAM issue
http://www.garlic.com/~lynn/2004m.html#16 computer idnustry scenarios before the invention of the PC?

misc. past ckd posts
http://www.garlic.com/~lynn/submain.html#dasd

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch
Date: Tue, 02 Nov 2004 10:12:19 -0700

Benny Amorsen <benny+usenet@amorsen.dk> writes:

Err no, I don't. With the default 3/1GB user/kernel memory split, the
limit for directly kernel addressable memory is somewhere around
900MB. You can of course still use memory above that limit, and even
memory above the 4GB limit.

With 1024MB installed you end up with a 896MB zone-NORMAL, and a 128MB
zone-HIGHMEM, if I recall correctly. The VM has much fun trying to
find an effective way to use the 128MB zone-HIGHMEM. In that respect
you're better off with 1536MB or 2048MB installed -- you still have
the highmem overhead, but at least you get a decent amount of extra
memory and no castrated 128MB-zone.

i'm sitting here on 4gbyte real machine with fedora core 2 ... and it is
telling me i only have 3.5gbytes.

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 02 Nov 2004 13:48:34 -0700

"mike" writes:

Both Lynn & Nick have objected that tuning is a problem because applications
that use a large address space, much bigger than main memory, will slow down
all other concurrent applications.

While early versions of the S/38 suffered from many of these tuning
problems, they have been solved since then.  OS/400 has the concept of jobs
running in "subsystems".  The subsystems have optional limits on the amount
of main memory available to them.  This permits huge memory consuming batch
jobs to run concurrently with smaller interactive jobs.  They will compete
for cycles based on processor priority but will not compete for main memory.

The /400 is also more efficient at sequential file processing than Lynn
seems to think based on these old /360-370 references.  In the /400 like the
/370 virtual memory pages are 4KB.  However, disk storage is managed in 16MB
segments and the OS can detect sequential processing and bring in whole 16MB
segments when appropriate.

I never claimed that an effective, efficient and manageable 128 bit huge
sparse virtual system was easy to implement for the system programmers, only
that it offers many benefits to application programmers.  Since application
programmers out number system programmers by 100 to 1 the efficiency gains
are worth the effort.

the issue is somewhat analogous to abstracting away the length in C
string libraries .... it may improve the productivity of the casual
programmer by some significant amount ... but it also has led to
something like a a factor of two orders of magnitude increase in
buffer exploits.

an issue is totally abstracting away some concepts1 like locality of
reference (as was done in tss/360), while resulting in some
productivity increases for the casual programmer ... could lead to
enormous thruput difficulties for production systems. GM claimed
enormous productivity increases for their programmers developing 32bit
address mode applications on tss/360 for the 360/67 ... but there
wasn't much mention of things like system thruput.

the issue is trying to abstract concepts for programming productivity
while at the same time not totally sacrificing system operational
efficiency.

a large number of cp67/cms and vm370 installation were mixed mode
environments running significant batch operations concurrent with
loads of interactive activity. i originally did fairshare resource
manager as undergraduate (actually generalized policy resource manager
with fairshare the default)
http://www.garlic.com/~lynn/subtopic.html#fairshare

one of the issues in the background was scheduling to the bottleneck
...  aka attempting to identify resources that represented significant
resource bottleneck thruput and dynamically adapting strategies to
deal with the resource bottlenecks. the remapping of cms filesystem
into a memory mapping paradigm ...
http://www.garlic.com/~lynn/submain.html#mmap

was not only dynamically recognizing large logical requests ... but
also being able to contiguously allocate on disk ... and bring in
large contiguous sections (as appropriate) if there was sufficent real
memory for the operation. in situations where real memory was more
constrained, either because there wasn't a lot ... or there was large
amount of contention for real memory ... the service requests were
dynamically adapted to the operational environment.

note that for quite a long time ... a large amount of the work that
went on in rochester actually was done on vm370 systems ... for minor
reference, this internal network update from 1983 lists several
rochester vm systems
http://www.garlic.com/~lynn/internet.htm#22

for total topic drift circa 1990 ... there was significant contention
between rochester and austin with regard to 64bit chip design ...
rochester kept insisting on having 65bit rather than 64bit.
http://www.garlic.com/~lynn/subtopic.html#801

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 02 Nov 2004 14:07:23 -0700

part of the issue was that during FS, i frequently commented that I
thot what I had deployed in production systems were more advanced than
some of the stuff that was being specified in FS; there was this cult
film that had been playing for a long time down in central sq ... and
i sometimes drew analogies between what was going on in FS and the
inmates being in charge of the institution. after FS was killed, it
was some number of these FS'ers that went off to rochester to do s/38
...  random future system references:
http://www.garlic.com/~lynn/submain.html#futuresys

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 02 Nov 2004 15:54:07 -0700

"mike" writes:

Indeed, while there may be theoretical performance advantages to Z/OS and
CICS, the latest iSeries and pSeries 595 can support tens of thousands of
concurrent users and that is more than enough for all but the very largest
application.

slight scale-up issue when we were doing ha/cmp
http://www.garlic.com/~lynn/95.html#13

at the time, i was asked to write a section for the corporate
continuous availability strategy document .... however, both pok and
rochester non-concurred
http://www.garlic.com/~lynn/submain.html#available

however, file i/o can benefit a lot from both contiguous allocation
and large block transfers (regardless of the file mapping).

note however, (i'be been told that) 400 seems to have fairly heavy
weight file open/close overhead.

we were doing this thing called electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and got involved a couple years ago looking at doing a fairly large
deployment of servers for financial transactions. there was a 400
review with consulting house that specializes in cold fusion on
400s. they claimed that doing mandatory access control on file
opens/closed increased overhead by something like ten times and would
make it impractical in a 400 environment.

i had showed that contiguous allocation and block transfers with
mapping cms filesystem to page mapped infrastructure in the '70s. lots
of the *ixes frequently default to relatively scatter allocation
strategry (basic cms filesystem allocation tended to be much more like
the *ixes with scattered allocation). even tho cms (& cp) used ckd
disks ... their original strategy from the mid-60s was to treat ckd
disks as logical FBA having fixed records ... and tended toward using
a scatter record allocation strategy.  When i did the remap to a page
mapped infrastructure ... i also put in contiguous allocation support
and (large) block transfer support.  note the page mapped stuff never
shipped to customers as part of standard product ... although it was
used extensively at internal sites like hone
http://www.garlic.com/~lynn/subtopic.html#hone

there has been recent thread running in another n.g. on ckd, fba,
etc
http://www.garlic.com/~lynn/2004n.html#51 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#0 CKD Disks?

lots of other ckd posts
http://www.garlic.com/~lynn/submain.html#dasd

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 02 Nov 2004 19:13:38 -0700

"mike" writes:

On the other hand:
a) starting new jobs on the /400 is more like starting a new VM on VM/CMS or
TSO session on MVS and "pre-start jobs", a skeleton job waiting to be used,
are available.
b) files can be opened multiple times concurrently with different usages -
read, append, update, etc with several separate handles allowing many
programs to open files once and leave them open for an entire session.
c) one or more jobs can be used as servers to support transactions from
multiple devices just like CICS on the mainframe.
d) database journalling and remote database journaling can be used for high
availability.
e) the /400 has automatic tuning jobs that watch file and disk usage.  These
jobs balance the workload across disk arms, make file allocations contiguous
and place "hot" objects for fastest retrieval.

i wasn't saying that they weren't not necessarily not available on the
400 ... but possibly were made available 10 to sometimes 20 years
after other infrastructures had done some of them (it is a lot easier
if there has been example that has been around for 20 years to copy
... as opposed to needing to having to invent it from scratch). in
fact, that a lot of the popular lore about one level store from
tss/360, future system, and s/38 was wrong ... and needed quite a bit
of evoluation for the 400 (although i don't know if that happened in
the 80s for cisc 400 or not until the 90s for risc 400 ... i do know
that i was deploying some amount of the stuff in the 70s).

with respect to watching files for re-org, ... i think even windows/xp
now has something similar. however, bunches of this stuff is
orthogonal to whether there is a one level store paradigm or not
... just simple operational stuff that has been done (in some cases
for decades) for operational systems.

the cold fusion/financial example was specifically a web server
scenario where a huge numbers of file open/closes were happening. i
did get the impression that some amount of the file open/close
overhead ... was in fact related to the way 400 handled one level
store objects. the issue (compared to some locked-down unix web
servers) was that you couldn't be running cics-like operation with
light-weight threads (frequently in the same address space) with
startup pre-opened files (long ago and far away, when i as an
undergraduate, the university got to be beta-test for original cics on
project for library card catalog automation with a grant from onr
... i got the privilege of shooting several of the cics bugs).

the mention about continuous availability strategy document wasn't so
much about high availability ... although we started out calling the
project we were doing ha/cmp ... but along the way we coined the terms
disaster survivability and geographic survivability ....  in fact
along the lines of some large financial transaction systems have done
with IMS hot-standy (geographically triple redundant). misc. stuff
from the past ... semi-related to IMS hot-standby
http://www.garlic.com/~lynn/submain.html#shareddata

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

CKD Disks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CKD Disks?
Newsgroups: bit.listserv.ibm-main,alt.folkore.computers
Date: Tue, 02 Nov 2004 21:43:30 -0700

shmuel+ibm-main@ibm-main.lst (Shmuel  Metz , Seymour J.) writes:

The 3375 used 3370 technology under the covers. AFAIK the 3340, 3344
and 3350 were the last true CKD disk drives that IBM sold.

and while 3375 used control logic to map/emulate ckd to 3370 fba ...
the 3344 used control logic to map/emulate multiple 3340s to a *real*
3350 drive.

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 03 Nov 2004 09:00:30 -0700

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:

As I understand it, XP watches file accesses during boot (and
probably also during login) and re-orders those files for sequential
access. Makes for sub- stantially faster booting, especially if you
have a slow (laptop) disk drive.

when i was undergraduate ... i re-orged os/360 system ... by careful
ordering the sequence that files were built on the disks. for typical
university workload, thruput was increased by a factor of three times
(typical job elapsed time was decreased by 2/3rds). recent post
http://www.garlic.com/~lynn/2004n.html#23 Shipwrecks

two issues for windowing paradigm associated with page-mapped
filesystem ... was that it gave efficient hints to system for both 1)
loading the new stuff and 2) flushing the stuff no longer being used
(even for stuff that wasn't being sequentially accessed ... and
nominal read ahead strategies aren't triggered). this is somewhat
analogous to some of the cache preload instructions that give hints
about storage to be used:
http://www.garlic.com/~lynn/submain.html#mmap

of course this would enhanced by something like vs/repack
... attempting to group program & data being used together into more
condenced memory collection. recent post referencing vs/repack from
the 70s:
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing

basically vs/repack and disk re-org technologies are very similar ...
analysis of access patterns and attempting to re-og to maximuse system
thruput ... where vs/repack applied to things like working set (but
granularity of pattern analysis used by vs/repack was 32bytes which
would also make it applicable to cache line).

at sjr in 1979, i did a special modification to vm/370 kernel to
capture record addresses of all disk accesses (fba and ckd, it was
extended in fall of 1980 to supprot extended-ckd, aka Calypso). this
was deployed on internal installations in the san jose area capturing
typical cms useage ... as well as a lot of mvs pattern useage (run
under vm) from operations at stl.

the trace information was originally used in a detailed file cache model
... which investigated various combinations of disk drive, disk
controller, channel, groups of channels (like 303x channel director)
and system cache strategies. one of the results of the cache study was
for any total amount of cache storage ... the most efficient use of
that cache storage was a system-level cache ... aka 20mbytes of
system-level cache was more efficient than 1mbyte caches on 20
different disks. this corresponds with theory of global LRU
replacement algorithms ... that i did in the 60s when i was an
undergraduate
http://www.garlic.com/~lynn/subtopic.html#wsclock

the published literature at the time (in the 60s) was very oriented
towards local LRU replacement strategies ... and I showed that global
LRU replacement strategies always outperformed local LRU (except in a
few, fringe, pathological cases). some ten years later, this work
became involved in somebody's phd at stanford.

The next stage of using the disk record level trace information was
showing how it could be used for arm load balancing as well as
clustering of information that was frequently used together. There was
an issue regarding the volume of such trace data for standard
production systems, ... but a methodology was developed for being able
to reduce the information in real time.

Note that at the time ... that standard vm system had a "MONITOR"
facility that would record all sorts of performance & thruput related
data ... but it went to disk in raw format. What was developed was a
much more efficient implementation that was targeted at being of low
enuf overhead that it could potentially always be active in all
standard production systems ... and be able to support file load
balanching and file clustering as part of normal system operation.

misc. other posts about activities done in conjunction with disk
engineering and product test labs
http://www.garlic.com/~lynn/subtopic.html#disk

as distinct from posts about ckd disk
http://www.garlic.com/~lynn/submain.html#dasd

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 03 Nov 2004 11:19:05 -0700

oh, and couple random past posts about the disk activity analysis,
file/disk cache modeling work, etc. in 79-80:
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
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

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 03 Nov 2004 17:55:42 -0700

"David Wade" writes:

The way the system fits together has a certain beauty.  CP(VM) has a
pretty simple task. It makes VM's which are "machines".  I don't
think these are like the VM's in other OS's. They are low level VMs.
A 370, with disk, tape and console. There is no file system, No
shared write access to DASD/files, the two things that make a
conventional multi-user system complex. It just carves the disks
into STATIC chunks and its up to the users how they access them Yes
it tweaks the IO programs, but it just has to relocate the cylinders
and check for writes...  (and you can have shared memory, but its a
really simple model)

CMS is also pretty simple, like an eary MSDOS. Its a single user OS.
No virtual memory, very simple file system, talks to one terminal..
Very low overhead...

I seem to remember many years ago that in terms of OS over head, it
was about 1/10 of that of MVS. So I think from a program issuing a
disk read instruction it took around 100,000 instructions before the
SIO got sent to the channel, compared with 1,000,000 in MVS.

Of course sharing files in this environment was "interesting"

CP is around 260,000 lines of assembler code, CMS slightly
less.... I think this is a but less than MVS/TSO...

note that some number of applications running under cms are
effectively the same as their counterparts running under mvs
(compilers, assemblers, etc). i used to joke (in the '70s) that the
cms 64kbyte os/360 simulation ... didn't quite do everything that the
mvs 8mbyte os/360 simulation did ... but it did a significant subset
... and much, much faster and more efficient.

the original cms (cambridge monitor system) under cp/67 ran as if it
was on the real machine ... and in fact, it could run on a real 360.

i was doing a bunch of cp/67 pathlength optimizations as an
undergraduate ... as well as developing fair share scheduling, global
lru page replacement, etc ... in some of the stuff of running os/360
under cp/67 ... i reduced some amount of cp/67 pathlength by up to two
orders of magnitude (for running os/360 in a cp/67 virtual machine)
... compared to the original version that had been installed at the
university.

one of the issues then became cp/67 support of cms operations. since
each cms (virtual machine) was pretty much single thread ... the
SIO/LPSW-wait/interrupt/resume faithful virtual machine simulation was
pretty superfluous. I originally created a special disk I/O operation
(cms disk operations were extremely uniform so could special
case/fastpath their translation) that was treated as a CC=1,
csw-stored operation ... aka the return to the cms virtual machine
after the SIO instruction was when the operation had been totally
completed. With some other operations ... this cut typical cp67
related pathlength supporting cms virtual machines by 2/3rds or more.

The people controlling cp/67 architecture claimed that this exposed a
violation of the 360 principle of operations ... since there were no
defined disk i/o transfer commands that resulted in cc=1/csw-stored.
However, they observed that the 360 principle of operations defines
the hardware *diagnose* instruction as model specific implementation.
They took this as an opportunity to create the abstraction of a cp67
virtual machine 360 model machine ... which defined some number of
*diagnose* instruction operations specific to operations in a cp67
virtual machine. the cc=1/csw-stored simulation for sio was redone
as a variation of a special *diagnose* instruction.

when i was redoing the page replacement algorithm, the disk device
driver (including adding ordered seek queueing to what had been FIFO,
and chained requests for 2301 fixed-head drum), interrupt handler,
task switching, dispatching, etc .... i got the total round-trip
pathlength for taking a page fault, executing the page replacement
algorithm, scheduling the page read (and write if necessary),
scheduling the page I/O, starting the i/o, doing a task switch,
handling the subsequent page i/o interrupt, and the task switch back
to the original task ... down to nearly 500 instruction pathlength
total for everything. this is compared to typical bare minimum of 50k
(and frequently significantly more) instructions pathlength for most
any other operating system. note that later vm/370 versions possibly
bloated this by a factor of five to six (maybe 3k instructions).

the ordered seek queueing allowed 2314 to peak out at over 30 i/o
requests per second ... rather than the 20 or so with fifo queueing.
the 2301 fixed-head drum had originally had single request page
transfers and would max. out at about 80 transfers per second
.... with chained requests ... and any sort of queue ... it could
easily hit 150 transfers per second and peak at nearly 300/second
under worst case scenarios.

an old posting on some of this
http://www.garlic.com/~lynn/93.html#31 Big I/O or kicking the Mainframe out the Door

for a little drift ... appropriately configured vs/1 operating systems
with handshaking would run faster in a vm/370 virtual machine than on
the bare hardware w/o vm/370. part of this was because the handshaking
interface allowed responsibility for all vs/1 page i/o operations to
be handled by vm/370 (rather than by vs/1 native code which had a
significantly longer pathlength).

the original cp/67 could boot and do useful work in 256kbyte real 360/67.

the machine at the university was a 768kbyte real 360/67 ... but there
was an issue of the fix kernel starting to grow upwards over 80kbytes
(and this was all code in the cp/67 kernel, including all the console
functions and operator commands). if you added the fixed data storage
for each virtual machine you easily double the fixed storage
requirements. various development was then starting to add
feature/function & commands so the fixed kernel requirements were
growing. to address some of this at the university, i did the original
support for "paging" selective portions of the cp/67 kernel ... to
help cut down on the fixed kernel requirements. This pageable kernel
was never released to customers (although lots of the other stuff i
had done as undergraduate was regularly integrated into standard cp/67
release). The pageable kernel stuff did finally ship with vm/370.

later, near the tail-end of cp/67 cycle ... about when vm/370 was
ready to come out ... I did the translation of the cms filesystem
support to a new feature in cp/67 supporting paged mapped disk
operations ... along with a whole bunch of stuff extending the concept
of shared segments.
http://www.garlic.com/~lynn/submain.html#mmap
http://www.garlic.com/~lynn/submain.html#adcon

I finally got around to porting all of this to early vm/370 release 2
and making it available to a large number of internal installations ...
for instance it was used extensively at hone for a number of things
http://www.garlic.com/~lynn/subtopic.html#hone

a small subset of the shared segment stuff was incorporated into
vm/370 release 3 and released as something called discontiguous shared
segments. one of the reasons that the discontiguous shared segment
stuff is such a simple and small subset of the full stuff ... was that
the original code heavily leveraged the cms page mapped filesystem
work as part of the shared segment implementation.

the page mapped version of the cms filesystem was never shipped in a
standard vm/cms product (except for a custom version for xt/at/370).
and since the page mapped cms filesystem stuff didn't ship ... none of
the fancy bell & whistles that were part of the original shared
segment support shipped either.

while the *diagnose* i/o significantly cut the pathlength for support
cms disk i/o ... it retained the traditional 360 i/o semantics
... which when mapped to a virtual address space environment
... required all the virtual pages in the operation to be fixed/pinned
in real storage before the operation is initiated ... and then
subsequently released ... which still represents some amount of
pathlength overhead.

going to paged mapped semantics for cms filesystem in virtual address
space environment allows a much more efficient implementation (in part
because the paradigms are synergistic as opposed to being in
conflict).

a few recent descriptions of the overhead involved in mapping
the 360 channel i/o semantics into a virtual memory environment
http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's
http://www.garlic.com/~lynn/2004m.html#16 computer industry scenairo before the invention of the PC?
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?

random past posts mentioning pageable kernel work:
http://www.garlic.com/~lynn/2000b.html#32 20th March 2000
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
http://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#12 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#23 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004b.html#26 determining memory size
http://www.garlic.com/~lynn/2004f.html#46 Finites State Machine (OT?)
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]

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

Multi-processor timing issue

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multi-processor timing issue
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 04 Nov 2004 06:27:37 -0700

jmfbahciv writes:

A lot of times, doing a tweak of software would help (raising
the core limit) or there were times that the hardware needed
configuration.  In addition, learning about how your system
worked during the day over a week gave the sysadmin enough
information to plan future hardware upgrades.

the system performance model done in (originally cms\apl) apl
at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
evolved into driving the benchmarks for the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
calibration and validation
http://www.garlic.com/~lynn/submain.html#bench
evolved into the performance predictor tool on the hone
systems
http://www.garlic.com/~lynn/subtopic.html#hone
for world-wide sales and marketing support (be able to answer
guestions about the effects of some hardware change on the customer's
workload) and significantly helped drive the evolution of performance
turning into capacity planning.

one of the jokes leading up to releasing the resource manager ... was
that an enormous amount of work went into dynanmic adaptive system
operation ... and somebody in the corporation ruled that the "state of
the art" for resource managers were lots of performance tuning knobs
for use by the system tuning witch doctors ... and that the resource
manager couldn't be released w/o any performance tuning knobs.

So i added some number of resource tuning knobs, documented the
formulas on how the tuning knobs worked and gave classes on them
... and all the source was shipped with the product. With all of that,
as far as I know, nobody caught the joke. The issue was that the base
implementation operated with a lot of dynamic feedback stuff as part
of its dynamic adaptive operation. The hint is from traditional
operational research .... and the degrees of freedom giving the base
implementation and the degrees of freedom giving the add-on
performance tuning knobs (and whether the native base implementation
could dynamically compensate for any change in a any tuning knob).

part of the driving factor (leading up to the joke) was that the big
batch TLA system had hundreds of paramenters and there were tons of
studies reported at share about effectively random walks performed of
parameter changes ... attempting to discover some majic combination of
tuning parameter changes that represented something meaningful.

part of the issue is that over the course of a day or a week or a
month ... there can be a large variation in workload and thruput
characteristics ... and the common, "static", tuning paramether
methodology (from the period) wasn't adaptable to things like natural
workload variation over time.  Specific, fixed paramenters might be
better during some part of the day and worse at other parts of the day
... and the reverse might be true of other specific, fixed parameters
.... so there might be a large number of different combinatorial
parameter settings all with similar, avg. overall results.

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 04 Nov 2004 08:57:02 -0700

"David Wade" writes:

and its up to the users how they access them Yes it tweaks the IO
programs, but it just has to relocate the cylinders and check for
writes...  (and you can have shared memory, but its a really simple
model)

the base vm/370 (and cp/67) shared memory model was primarily focused
on sharing read-only pages for (page) performance (reduced paging,
reduced real-storage requirements).

the basic vm/370 structure had something called DMKSNT that had tables
of named systems ... and pointed to reserved page slots on disk.  A
privileged user could issue a "savesys" command referencing a DMKSNT
named system entry. The named system entry specified a set of
virtual memory page addresses ... in the savesys command, the current
contents of those specified virtual pages (belonging to the entity
issuing the command) would be written to the specified reserved disk
slots.

the "ipl" command simulated the front panel hardware IPL (initial
program load, aka boot) button. a form of the ipl command could
specify a named system ... in which case the issuers virtual memory
would be cleared and initialized with pointers to the corresponding
reserved disk locations. The named system could also specify spans
on virtual page addresses (segments) that were to be be read/only
shared across all users of that named system.

the problem was that this was primarily useful for sharing (virtual)
kernel type software (like much of the cms kernel) but didn't work
well with application code ... since the IPL command also completely
reset the users virtual machine.

as part of redoing the cms filesystem to a paged mapped
infrastructure, the result effectively subsumed the DMKSNT named
system function ... and could be applied to any set of virtual pages
... and could be defined by all users (not just limited subset of
things in the DMKSNT table under control of privileged control).  The
page mapped semantics included the ability to specify segments as
read/only shared ... as part of the page mapping operation.

one of the most extensive early adopters of this was HONE
http://www.garlic.com/~lynn/subtopic.html#hone

their environment was primarily an extremely large APL application
that provided a very constrained environment for the sales and
marketing people world-wide. It provided almost all of the interactive
environment characteristics ... and many users weren't even aware that
CMS (and/or vm/370) existed.

The issue was that they wanted 1) "cms" named system with shared segments,
2) custom "apl" application named system that consisted of a custom
APL interpreter that included much of the APL code for the
customized environment integrated with the interpreter ... and almost
all of it defined as shared segments, 3) over time it was realized
that some number of the applications that had been written in APL ... could
benefit from 10:1 to 100:1 performance improvement if it was recoded in
fortran, and 4) they then needed to be able to gracefully transition back
and forth between APL environment and the Fortran environment ... completely
transparent to the end-user.

In the IPL paradigm supporting shared-segments ... there was no way of
gracefully transitioning back & forth between the apl environment
(with lots of shared segments) and the fortran environment.

Also, because of the ease with which shared-segments could be defined
in the page-mapped filesystem environment ... it was easy to adopt a
number of additional cms facilities to the read-only shared segment
paradigm.

For vm/370 release 3, it was decided to release the enhanced,
non-disruptive (non-IPL command) implementation of mapping memory
sections. A subset of the CP code was picked up (but w/o the cms
filesystem page mapped capability), the non-disruptive mapping had to
be kludged into the DMKSNT named system paradigm. Some number of
additional "name tables" were added to DMKSNT ... and a LOADSYS
function was introduced ... which performed the memory mapping
function of the IPL command w/o the disruptive reset of the virtual
machine. Some amount of the CMS application code that had been
reworked for read-only, shared-segment environment was also picked up
(and mapped into the DMKSNT named system paradigm). This extremely
small subset function was released as Discontiguous Shared Segements
in vm/370 release 3.

there were still all the restrictions of having single set of system
wide named systems that required special administrative privileges to
manage ... and only applied to introducing the mapping new (and for
shared segments, only read-only) pages into the virtual address
spaced.

in the original filesystem paged mapped implementation ... any image
in the filesystem was available for mapping into the virtual address
space ... and the access semantics were provided by the filesystem
infrastructure (aka trivial things like if you didn't have access to
the specific filesystem components ... then you obviously couldn't map
them into your address space).

misc. past posts on the subject:
http://www.garlic.com/~lynn/submain.html#mmap
http://www.garlic.com/~lynn/submain.html#adcon

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

some recent archeological threads in ibm-main, comp.arch, & alt.folklore.computers ... fyi

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: some recent archeological threads in ibm-main, comp.arch, & alt.folklore.computers ... fyi
Newsgroups: bit.listserv.vmesa-l
Date: Thu, 04 Nov 2004 09:09:23 -0700

http://www.garlic.com/~lynn/2004k.html#46 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004k.html#47 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004k.html#49 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004k.html#51 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#0 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#2 IBM 3090 : Was (and fek that) : Re: new computer kits
http://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#9 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#18 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2004l.html#20 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004l.html#22 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004l.html#24 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2004l.html#61 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#70 computer industry scenairo before the invention of the PC?
http://www.garlic.com/~lynn/2004l.html#72 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004l.html#73 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004l.html#74 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#3 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#18 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#20 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#25 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#26 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#36 Multi-processor timing issue
http://www.garlic.com/~lynn/2004m.html#45 Multi-processor timing issue
http://www.garlic.com/~lynn/2004m.html#47 IBM Open Sources Object Rexx
http://www.garlic.com/~lynn/2004m.html#48 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
http://www.garlic.com/~lynn/2004m.html#54 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#58 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#63 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#0 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#3 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#6 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#7 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#13 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#14 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#17 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2004n.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#34 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#36 Shipwrecks (dynamic linking)
http://www.garlic.com/~lynn/2004n.html#37 passing of iverson
http://www.garlic.com/~lynn/2004n.html#45 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#51 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#0 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#2 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#4 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#5 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#6 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue
http://www.garlic.com/~lynn/2004o.html#11 Integer types for 128-bit addressing

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 04 Nov 2004 17:43:14 -0700

"David Wade" writes:

I think IBM did it the other way round. CP would simulate a 16Meg
virtual machine regardless of the amount of real memory in the
machine. And CMS did not have any understanding of Virtual Memory or
paging. As CMS only had to support a single user this was O.K.

In fact you could/can IPL an OS that needs Virtual Memory in a
Virtual Machines but when you did so CP had to simalate the paging
hardware and performance takes a dive. Later machines had (I think)
"assists" (microcode) that help in this case.

360 principle of operations & architecture defined a relatively clean
privilege instruction operation ... anything that affected the state
of the machine was a privilege instruction. CP/67 ran virtual machines
in virtual memory mode and problem state. Any time a virtual machine
attempted to execute a supervisor/privilege instruction, it would
program check into the cp/67 kernel ... and the cp kernel would
simulate the operation according to various virtual machine rules.
In some sense, the cp/67 kernel became the "microcode" of the virtual
machine since it was "interpreting" all supervisor state instructions.

the ratio of cp/67 kernel "overhead" execution to virtual machine
"problem state" execution tended to be associated with the ratio of
supervisor state instructions to problem state instructions in the
code running in the virtual machine. for what ever reason, the ratio
of supervisor state instructions to problem state instructions
significantly increased in the transition from os/360 MFT to os/360
MVT.

The transition of os/360 MVT to VS2/SVS was even more dramatic, in
part because the cp kernel was now faced with emulated the hardware
TLB with a lot of software (since the SVS kernel now was using virtual
address space architecture ... while MVT had been running as if it was
in real address space).

the 158 & 168 first got (limited) microcode virtual machine "assists"
(vma); the vm/370 kernel would set a (privilege) control register
... and when various privilege instructions were encountered by the
"hardware", ... rather than interrupting into the cp kernel, the
native machine microcode would execute the instruction according to
virtual machine rules (rather than "real machine" rules).

The amount and completeness of the virtual machine assists increased
over time ... until you come to PR/SM and LPARS ... where there a
logical partition can be defined and the microcode completely handles
everything according to virtual machine rules (w/o having to resort to
a cp kernel at all).

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

Multi-processor timing issue

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multi-processor timing issue
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 05 Nov 2004 07:05:58 -0700

jmfbahciv writes:

We would have worried about offending the customer who did get the
joke.  OTOH, the people who did today's equivalent of sysadmin at
our customer sites appreciated the hooks for a few knobs when they
had PHBs who wanted to help run the system.

i would have taken most of the heat ... it was possibly the only
corporate product that customers commonly referred to using the
author's name (as opposed to the provided corporate name).

since all code shipped ... they could actually do to it anything they
wanted. there were actually knobs ... but they goverened
administrative resource policy issues ... as opposed to performance
tuning issues. note that even experienced operators weren't able to
change performance tuninng knobs in real-time as workload and
requirements changed over the course of the day.

as always
http://www.garlic.com/~lynn/subtopic.html#fairshare

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

360 longevity, was RISCs too close to hardware?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 longevity, was RISCs too close to hardware?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 05 Nov 2004 07:51:22 -0700

pg_nh@0409.exp.sabi.co.UK (Peter Grandi) writes:

Perhaps at your IBM office people tolerated you for trying to do your
job well, but usually that kind of attitude gets you labeled as a
non-team-player, a know-it-all busybody. :-)

In other countries, or perhaps on the opposite coast, in the offices of
another big monopoly, people would consider it as a challenge to write
an i/o subsystem that would crash and hang the system as often as
possible, and get away with it. :-)

it was at the internal disk engineering and product test labs
(bldg 14 & 15 on the san jose plant site)
http://www.garlic.com/~lynn/subtopic.html#disk

they had been doing all their testing using stand-alone machine time
...  that had to be serialized/scheduled among all the testers and
different testcells. they had tried running concurrently under MVS but
the MTBF for the operating system was on the order of 15 minutes.

the objective was a bullet proof i/o subsystem so that all disk
engineering activities could go on simulataneously & concurrently
sharing the same machine.

of course it had other side effects ... since the machines under heavy
testcell load was possibly 1 percent cpu utilization ... which met
that we could siphon off a lot of extraneously & otherwise,
unaccounted for cpu. the enginnering & product test labs tended to be
the 2nd to get the newest processors out of POK (typically something
like serial 003, still engineering models ... but the processor
engineers had the first two ... and then disk engineering and product
test got the next one).

at one point, one of the projects that was needing lots of cpu and
having trouble getting it allocated from the normal computing center
machines was the air bearing simulation work ... for designing the
flying disk (3380) heads. dropped it on a brand new 3033 engineering
model in bldg. 15 ... and let it rip for all the time it needed.

a recent posting about dealing with 3880 issue when it was first
deployed in the bldg. 15 ... for standard string of 16 3330 drives as
part of interactive use by the engineers ... fortunately it was still
six months prior to first customer ship ... so there was time to
improve some of the issues:
http://www.garlic.com/~lynn/2004n.html#15 360 longevity, was RISCs too close to hardware

there was a problem raised from a somewhat unexpected source. there
was an internal only corporate report and the MVS RAS manager in POK
strenously objected to the mention of MVS 15 minute MTBF. There was
some rumor that the objection was so strenuous that it quelshed any
possibility for any award for significantly contributing to the
productivity of the disk engineering and product test labs.

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

360 longevity, was RISCs too close to hardware?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 longevity, was RISCs too close to hardware?
Newsgroups: comp.arch
Date: Fri, 05 Nov 2004 07:59:19 -0700

torbenm@diku.dk (Torben Ægidius Mogensen) writes:

Reminds me of another Japan/US comment I once heard: "The reason the
Japanese economy works better than the US economy is that Japan has
ten engineers for each lawyer, while the US has ten lawyers for each
engineer".

several weeks ago, in another forum, i posted a quote from some UK
financial institution about improving economic conditions in the 2nd
largest economy in the world, japan. i got called to task for posting
the quote ... because japan is not the 2nd largest economy in the
world ... the EU is (and i should know better ... or maybe UK
financial institutions should know that?)

more recently there was some issue that as the EU consolidation
proceeds, shouldn't various international bodies replace the
individual EU member country memberships with a single EU membership.

my first trip to japan was to do the HONE
http://www.garlic.com/~lynn/subtopic.html#hone

installation for IBM Japan in Tokyo in the early 70s. At that time,
the yen exchange was greater than 300/dollar. what is it now?

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

360 longevity, was RISCs too close to hardware?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 longevity, was RISCs too close to hardware?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 05 Nov 2004 09:54:43 -0700

oh, and one reason that the disk engineering and product test labs
tolerated me ... was that i wasn't in the gpd organizations. i had a
day job in research (bldg 28) ... the stuff in bldg. 14&15 was just
for the fun of it. something similar for the hone complex further up
the peninsula or for stl/bldg-90 or for the vlsi group out in
lsg/bldg.29. i would just show up and fix problems and go away. one of
the harder problems was keeping track of all the security
authorizations for the different data centers. I didn't exist in any
of those organizations.

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 05 Nov 2004 13:10:29 -0700

"David Wade" writes:

Ah the joys of VM under VM. When I went on the VM systems
programming courses of course we ran VM under VM (at St Johns
Wood. 4361 I think)..

And didn;t the itcrawl when when the whole class did it. I think we
only had eight or nine on the course but it did slug response....

one of the issues is that shadow table maintenance follows the TLB
hardware mainenance rules. for instance how big a pool of shadow
tables to you keep ... so that when the virtual machine switches
address space register(s). typical virtual memory operating systems
tend to have a large number of virtual address spaces (modulo the
single address space conversions like vs1, even SVS had at least "two"
virtual address spaces ... although they are almost the same).

The simple case is to have a single set of shadow tables and everytime
the virtual machine switches virtual address space, wipe it clean and
start all over. This was the original implementation up until release
5/HPO, which would support keeping around a few shadow tables (per
virtual machine) ... and hopefully when the virtual machine switched
virtual address spaces, it was to one that had been cached.

not published, but dual-address space introduced on 3033 had somewhat
similar effect on the real hardware TLB. while dual-address
introduction brought common segment relief (so you didn't totally run
out of room in address space for application execution) ... it
frequently increased the number of concurrent distinct address spaces
needed passed the 3033 TLB limit ... in which case it needed to
scavenge a cached address space and all the associated TLB entries
(which resulted in measurable performance decreased compared to
non-dual-space operation on the same hardware). recent posting
discussing some dual-address space
http://www.garlic.com/~lynn/2004n.html#26 PCIs as chip-to-chip interconnect

one of the first production uses of virtual machines supporting
virtual address spaces was the 370 hardware emulation project (it was
also a something of stress case for the relatively new multi-level
source management support). the 370 hardware architecture book was
out but there was no actual hardware. cambridge was operating something
of a open time-sharing service on their cp/67 system
http://www.garlic.com/~lynn/subtopic.html#545tech
http://www.garlic.com/~lynn/submain.html#timeshare

with some number of mit, bu, harvard, etc students as well as others.

the issue was that we couldn't just start modifying the production
cp/67 system providing 370 virtual machines ... because there was some
possibility that some non-employee would trip over the new
capabilities.

so the base production update level was somewhat called the "l" system
... lots of standard operational and performance enhancements to a normal
cp/67 system.

a new level of kernel source updates were started ... referred to as
the "h" updates; they were the stuff that when the operation was
specified, the kernel emulated a virtual 370 machine (with virtual 370
relocate architecture) ... rather than a 360/67 virtual machine.

an "h" level kernel would be run in a virtual 360/67 machine on the
production system (but isolated from all the other normal time-sharing
users).

a third level of kernel source updates then were created, the "i"
level ... which were the modifications to the kernel to operate on
real 370 hardware ... rather than on real 360/67 hardware. the "i"
level kernel was in regular operational a year before the first real
370 hardware with virtual memory support existed (in fact it was a
370/145 engineering machine in endicott that used a knife switch as an
ipl-button ... and the "i" system kernel was booted to validate the
real hardware).

in any case, the operation in cambridge then could be:

real 360/67 running a "l" level cp/67 kernel
  virtual 360/67 machine running a "h" level cp/67 kernel
     virtual 370 machine running an "i" level cp/67 kernel
        virtual 370 machine running cms

this was something of a joint project with engineers in endicott and
one of the first uses of the "internal" network for distributed source
development (link between cambridge and endicott)
http://www.garlic.com/~lynn/subnetwork.html#internalnet

later there was a "q" level source updates (or maybe the project was
called "q" and the update level was "g", somewhat lost in the fog of
time) ... that included some 195 people.  the project was to provide
cp/67 support for virtual 4-way 370 smp. this was slightly related to
the later effort to add dual i-stream hardware to an otherwise
standard 195 (something akin to the current multi-threading hardware
stuff). for most intents the kernel programming was as if it was a
normal 2-way smp ... but it was standard 195 pipeline with one-bit
flags tagging which i-stream an instruction belonged to.

a few random past l, h, & i kernel posts:
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2001k.html#29 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004j.html#45 A quote from Crypto-Gram

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 05 Nov 2004 16:03:19 -0700

Jon Forrest writes:

This is slightly off-topic but the thing I remember disliking
about CMS (and other IBM OSs) is that you couldn't write
a program that prompted for the name of a file, and then
opened the file. Instead, you had to predefine a handle-like
name outside of the program, and refer to the handle when
opening the file. This is basically what the redoubted
JCL 'DD' card also used to do.

that was the emulated os/360 services semantics (from earlier comment
that cms had a 64kbyte os/360 services simulator subset that did
almost as as much as MVS 8mbyte os/360 services simulator)

it was trivial to do in using cms filesystem semantics

also if you new the os/360 services magic words ... you could fake it
out ... that was how the various compilers and assemblers that were
brought over from os/360 worked ... they had some interface routine
glue that you could specify the filename to the command ... and then
inside the cms glue routine it made the magic os/360 services
incantations.

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

RISCs too close to hardware?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RISCs too close to hardware?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 06 Nov 2004 08:25:15 -0700

Gene Wirchenko writes:

I remember docs that the standard MTS system ran under UMMPS
(University of Michigan Multi-Program Supervisor).  I also heard it
could run under JESS/2 (not sure of spelling).  I never heard of it
running under MVS.

the folklore is that michigan adopted LLMPS (lincoln labs multi
programming supervisor) for UMMPS.

random past posts mentioning llmps ... (i have hardcopy of the old
share contribution library document for llmps):
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000.html#89 Ux's good points.
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001e.html#13 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001h.html#24 "Hollerith" card code to EBCDIC conversion
http://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001k.html#27 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#9 mainframe question
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#45 Valid reference on lunar mission data being unreadable?
http://www.garlic.com/~lynn/2001n.html#89 TSS/360
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002b.html#6 Microcode?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002d.html#49 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002m.html#28 simple architecture machine instruction set
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
http://www.garlic.com/~lynn/2003i.html#8 A Dark Day
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004d.html#31 someone looking to donate IBM magazines and stuff
http://www.garlic.com/~lynn/2004g.html#57 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004l.html#16 Xah Lee's Unixism

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 06 Nov 2004 08:44:52 -0700

"Stephen Fuld" writes:

But there were other, non-IBM implementations that allowed that.
The "batch" orientation of OS/360 required that all resources needed
by the job to be identified in the JCL so the job wouldn't "stall"
waiting for resources.  This was needed since the program, once
loaded used real addresses and essentially couldn't be swapped out
(unless it was swapped back in to the same physical memory space).
Thus "dynamic" allocation of files was a no-no.  The result was that
things like compilers, that needed scratch files, couldn't allocate
them internally and you had to have them expressly allocated
externally in the catalogued procedures (essentially JCL macros).
It was definitly icky!  :-)

somewhat the issue in the batch paradigm is that the resources are
known before the job starts ... because there is not nominally the
human responsible for the batch program present.  the other
characteristic was that extents tended to be pre-allocated and
pre-reserved before the program started (to somewhat limit the issue
that the program gets part way in and can't continue ... and again the
person responsible for the batch program was not present).

the interactive paradigms tend to do much more allocation on the fly
... frequently even a record at a time as needed. they tend to have
filesystems that have allocation bit-map per record of allocation and
files have indexes listing all the record for the file, which is
updated as additional records are allocated. cms started this way with
the original filesystem built starting in '65.

i did a morphing of this filesystem to a page map paradigm where the
records were pages ... and did some infrastructure smarts to promote
contiguous record allocation ... rather than the straight-forword
record at a time ... which could be quite scattered. previous page
map refs:
http://www.garlic.com/~lynn/submain.html#mmap

cms also imported some number of applications from the os/360 world
(as did MTS) where the code did open/closes on DCBs ... and the
traditional DCBs were expecting the DD-oriented file specification.
The basics for this was provided by a bit of os/360 simulation code
... that was about 64kbytes in size. This included a filedef command
that would do a straight forward simulation of the DD
specification. However, for some number of the imported os/360
applications (commonly used compliers and assemblers) there were
sometimes magic glue code written that handled the mapping of cms
filesystem conventions to os/360 filesystem conventions at a much
lower and granular level ... which tended to hide much more of
the os/360 gorp in a cms interactive oriented environment.

the os/360/batch paradigm has evolved over the years ... providing
more and more sophisticated facilities in support of running
applications and programs where the default assumption is that the
responsible party for the application is not present (as opposed to
the interactive paradigm which assumes that the person responsible for
the execution of the application, is in fact present).

the batch paradigm has somewhat found a resurgance ... even in the
online and internet environment ... where there are deployed server
applications that may have hundred of thousands of clients ... but
there is some expectation that the server has much more characteristic
of the batch paradigm ... the person responsible for the server
operation isn't necessarily present when it is running.

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 06 Nov 2004 09:14:16 -0700

the other characteristic of the os/360 extent, non-record allocation
was the trade-off between i/o capacity and real storage requirements
in the filesystem design around multi-track search.

basically the os/360 had very simple, one level index filesystem
orientation. the file information with the pointer to the start of the
file was located in the vtoc (which contained a list of all the
files). to open/find a file, the system would do a multi-track search
on the vtoc to find (and read) the record with the specific file
information. this traded off the seemingly significant real-storage
requirements needed for record level bit-maps of various kinds with
simple disk-based structure that could be searched with i/o commands.

"library" files could have members ... and for these kind of files,
called partition directory datasets (or PDS) ... the PDS directory was
simple and could also be searched&read with i/o command (rather than
having index/directory storage that could tie-up real memory). members
in directories were contiguous allocation ... and PDS were contiguous
... and deleting/replacing members just left gaps in the PDS database.
At some point, PDS datasets had to be "compressed" to recover the
gaps.

as i've pointed out previously sometime in the 70s, the io/memory
trade-off for disk-based structures had shifted ... and it became more
efficient to have memory based index structures and attempt to
conserve/optimize i/o infrastructure.

minor ckd threads
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/2004n.html#51 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#0 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#6 CKD Disks?

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

Demo: Things in Hierarchies (w/o RM/SQL)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Demo: Things in Hierarchies (w/o RM/SQL)
Newsgroups: comp.databases,comp.databases.object,comp.databases.theory
Date: Sat, 06 Nov 2004 11:08:41 -0700

"Laconic2" writes:

An airline reservation system covering about 45 airlines,  about 100,000
flights per day, about 10,000,000 passengers,
credit cards,  airplanes, seating capacity in several classes, and about
10,000 fare changes a day.  200 simultaneous users on the web.

say 100 passengers/flight? ... then it is 10m PNR records ...  so you
might say that there are 5m new PNR records created each day (covers
round-trip); 10m PNR records are updated as the flight is taken. The
5m new PNR records are typically created at some time for a future
flight and will exist for 90 days after the flight is taken and then
5m old PNR records are deleted each day as they expire. Say an
avg. PNR record is created ten days before the flight, that gives PNR
record something like 100 days ... or total PNR databse of possibly
approaching 500m records (multiply by 8 if you want to keep for two
years instead of 90-some days).

there are actually (at least) four different databases (for
res)

PNR database
flight segment/seat database
routes database (i once got to rewrite routes from scratch)
fares database

random past posts re: working on routes and/or amadeus
http://www.garlic.com/~lynn/96.html#29 Mainframes & Unix
http://www.garlic.com/~lynn/96.html#31 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#153 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#61 64 bit X86 ugliness (Re: Williamette trace cache (Re: First view of Willamette))
http://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001d.html#74 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#50 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001k.html#26 microsoft going poof [was: HP Compaq merger, here we go again.]
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2002i.html#38 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#40 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#83 Summary: Robots of Doom
http://www.garlic.com/~lynn/2002l.html#39 Moore law
http://www.garlic.com/~lynn/2003b.html#12 InfiniBand Group Sharply, Evenly Divided
http://www.garlic.com/~lynn/2003c.html#52 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2003o.html#17 Rationale for Supercomputers
http://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004m.html#27 Shipwrecks

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

Demo: Things in Hierarchies (w/o RM/SQL)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Demo: Things in Hierarchies (w/o RM/SQL)
Newsgroups: comp.databases,comp.databases.object,comp.databases.theory
Date: Sat, 06 Nov 2004 14:55:30 -0700

a few years ago, oag for all commercial flights segments in the world
had a little over 4000 airports (with commercial scheduled flights)
and about half million "flight segments" (i.e. take/off landings). the
number of flights segments didn't exactly correspond to flights/day
... since some flight segments didn't fly every day. there was also an
issue that each individual flight segment was a flight ... plus
combinations of flight segments were also flights (i.e. say flight
from west coast to east coast with two stops could represent 3+2+1
different "flights"). the longest such flight that i found had 15
flight segments (it wasn't in the US) ... taking off first thing in
the morning and eventually arriving back at the same airport that
night ... after making the round of a lot of intervening airports.

there is also some practice of the same flight segment having multiple
different flight numbers. the first instance of this (that i know of)
was in the very early 70s ... the first twa flight out of sjc in the
morning ... flew both to seatac and kennedy. it turns out that the
people going to kennedy had a change of equipment at sfo (not a
connection).

this is an airline "gimmick" ... traditionally the non-stops and
directs are listed before the flights with connections. if you had a
dual flight number ... with change of equipment ... tho flights would
show up in the first "direct" section ... not in the following
"connections" section.

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

CKD Disks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CKD Disks?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 06 Nov 2004 15:22:38 -0700

tedmacneil@bell.blackberry.net (Ted MacNEIL) writes:

..
IBM was forced into the technological leap to thin film heads, but
they just weren't ready in time.
..

I learned a valuable lesson at an HDS presentation when the
arguments were bounding about thin heads and sputtering of
'particulate matter' on media.

There were as many management types as techies at this presentation
and the presenter started with: 'Let me again talk about the
benefits of metal heads vs thin film...'. Before he could
continue, one of the management types yelled: 'Who cares?' She
wanted to know the business value, rather than the technical value.

As a performance/capacity analyst, it took this to heart. I realised
that the people holding the purse strings are not going to pay for
technology for technology's sake.  This is a lesson many techies
still have to learn.

I have spent the last 20 years working on the skill that allows me
to explain technology in business terms. No matter how much one may
despise management, if you can't convince them why the money has to
be spent, it won't be spent.

recent post discussing some of this period
http://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?

other posts about the period
http://www.garlic.com/~lynn/subtopic.html#disk

and mention of the air bearing simulations doing the calculations for
(physical) design of the floating/thin-film heads.

so the heads fly closer ... enabling signficant increases in density
and transfer rate ... resulting in the manufacturing cost per bit
being reduced dramatically ... i try and stay out of pricing issues ...
although i got dragged into for the resource manager ... being the
guinea pig for first pricing kernel software
http://www.garlic.com/~lynn/subtopic.html#fairshare

the other part of the thin-film head design was chip that had both
digital and analog circuits. a lot of this work was done over in the
los gatos vlsi lab (bldg. 29, which has since been torn down, it was
originally built in the 60s as advanced system development division
hdqtrs).  the group also did jib-prime ... which was the
microprocessor in the 3880 controller.

in any case, they built the high performance logic simulation engine,
LSM (originally named the los gotos simulation machine, but renamed
logic simulation machine for external publication) ... and it included
support for timing. it ran chip logic simulation about 50,000 times
faster than could be done with convential programming on 3033. the
subsequent logic simulators may have improved on that thruput ... but
they dropped support for timing ... effectively assuming synchronous
clock chip designs.  One of the things that the LSM gave them with
timing support was the ability to run a chip design that had
non-synchronous timing and/or chip design that had combination of
digital (potentially synchronous or asynchronous) circuits and analog
circuits (like the design for the thin-film heads).

random past references to lsm & other logic simulators:
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#82 Future architecture
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
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/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

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

pop secure connection

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: pop secure connection
Newsgroups: netscape.public.mozilla.general
Date: Sun, 07 Nov 2004 18:41:44 -0700

i've been trying to get mozilla mail &/or thunderbird to read
pop mail on port 110 using secure connection.

i've got all unnecessary incoming/outgoing ports blocked using
iptables.

evolution reads mail fine using SSL on port 110

i set mozilla mail (& thunderbird) to ssl on part 110 and try and
read mail ... and it just hangs and eventually times out.

i can see it has established a connection to port 110 ... but iptables
is also showing it is blocking attempts to port 995.

this is with older thunderbirds, older mozillas, brand new
thunderbird, brand new mozilla, and brand new mozilla nightly build.

mozilla & thunderbird both handle outgoing/sent mail using SSL just
fine.

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 08 Nov 2004 12:58:49 -0700

"Stephen Fuld" writes:

OK, but the organization of the file system is an orthogonal issue to
whether dynamic allocations are allowed.

it was much easier to mask os/360 applications (compilers, assemblers,
etc) running batch-oriented filesystem expectations on cms (with
incremental record allocation, total space record-based allocation
map, per file allocated record map, etc) than the other way around.

the two scenarios mentioned for the paradigm was

1) original batch-oriented (rather than interactive which could assume
responsable human was present)

2) original io/real-storage tradeoff ... where real storage was
conserved by having a relatively trivial filesystem structure that was
totally resident on disk and could be searched/used by relatively
trivial ckd multi-track search commands.

some cross-over from recent ckd thread
http://www.garlic.com/~lynn/2004n.html#51 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#0 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#6 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#21 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?

low-end target for os/360 was (at least) the 32kbyte to 64kbyte
360/30; I did assemblies on 360/30 with something like os/360 pcp
release 5 or 6(?).

later releases added some additional incremental, dynamic capability
...  but the os/360 genre was never really targeted at the interactive
computing environment ... and so didn't have a lot of (market?)
motivation to support features for the interactive environment ... aka
could they have done better?, very probabily; did they think that
better interactive facilities would provide sufficient ROI to justify
it ... i don't think they believed so.

Furthermore they continued to be saddled with the original filesystem
design with its io/real-storage trade-off ... aka effectively all disk
storage allocation was disk resident, no memory based structures,
simple enuf structure that it could be managed with ckd disk i/o
commands. Dynamic allocation in the abstract is possible ... but the
amount of work to perform any allocation at all (static or dynamic) is
extremely heavy weight ... and requires a lot of disk i/o activity.

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

pop secure connection

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: pop secure connection
Newsgroups: netscape.public.mozilla.general
Date: Mon, 08 Nov 2004 13:07:57 -0700

Jay Garcia writes:

The port in the account settings MUST be set to 995 and not 110. That's
the way it works here.

configuration says that 995 is the ssl (secure connection) default
... but allows it to be changed.

my isp supports ssl on port 110 (not 995).

evolution does it fine. even windows/laptop w/eudora does it
fine. eudora even has a window that shows the last certificate &
session ... which also shows it at port 110.

All versions of mozilla/thunderbird that i've tried with ssl/110
has failed to work (even when overriding the default 995 in the
configuration menu).

one issue is that i have locked down all ports with iptables that are
absolutely necessary (both incoming and outgoing).

when i try mozilla (&/or thunderbird) with ssl/110 ... i can see that
a session has been established on port 110 ... but i also see in the
iptables log that there are attempts at port 995 being discarded.

it almost appears that both mozilla and thunderbird, even when 110 is
specified for secure connection (ssl) operation has vistages of code
that still tries port 995 (even tho there is at least some code that
honors the 110 configuration specification).

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 08 Nov 2004 15:36:12 -0700

now (vm, cms, apl, etc based) US HONE
http://www.garlic.com/~lynn/subtopic.html#hone

in the late '70s put together something different for large scale
cluster operation (eight large mainframe SMPs all sharing large disk
farm and workload for all the branch/field service, sales and
marketing in the US).  it was the largest single-system-image cluster
that i know of at the time (had something approaching 40,000 defined
userids at the time)

they used a different on-disk structure ... not for allocation ... but
for locking disk space use across all processors in the complex. there
was a lock/in-use map on each disk (read-only, write-exclusive, etc,
by processor). a processor that wanted to enable access to an area on
disk, would read the disk's lock/in-use map ... check to see if the
area was available, update the lock-type for that area, and use a ckd
ccw sequence that emulated smp compare&swap semantics (aka search
equal ... and then rewrite/update if the search still mapped).

misc. ckd dasd posts
http://www.garlic.com/~lynn/submain.html#dasd

it used standard disk controllers for the operation ... not the
"airline control program" (acp, later renamed to tpf) disk locking
RPQ. the acp controller rpq extended a little memory in the disk
controller and allowed symbolic locks that were used for various kinds
of cluster (aka loosely-coupled) disk access serialization &
coordination ... w/o resorting to the whole device reserve/release
locking, or a disk-based structure (like hone used). I know the
rpq was available in the early 70s on 3830 disk controller. 3330/3830
page:
http://www-1.ibm.com/ibm/history/exhibits/storage/storage_3330.html

total aside ... possible typo in the above:

Features
 * 30 milliseconds was average access time; minimum was 55 milliseconds.

========

and a ACP/TPF history page
http://www.blackbeard.com/tpf/tpfhist.htm

some drift from the above ... one of the airline res efforts in the
80s was amadeus and my wife served for a brief time as chief architect
for amadeus

random posts mentioning amadeus
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#50 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004m.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
http://www.garlic.com/~lynn/2004o.html#24 Demo: Things in Hierarchies (w/o RM/SQL)

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

z/OS UNIX

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: z/OS UNIX
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 08 Nov 2004 16:06:03 -0700

WGShirey@ibm-main.lst (Greg Shirey) writes:

The I originally stood for Iceberg, Storagetek's name for the RVA before
they licensed it to IBM.  I suppose IBM could have renamed the product
rather than just substitute "IBM" for "Iceberg", but they were just working
with what they inherited.

in the middle of all this was c-star (or was it seastar?, must have
been seastar, since the software was called seahorse ... a brand-new
controller being worked on by adstar, started sometime around 91).

old reference that has buried references to both iceberg and seastar
(from 2/96):
http://www.informationweek.com/565/65mtrob.htm
and another here
http://www.stkhi.com/nearline.htm

so if it was seastar ... might there be some topic drift to seascape
and then netscape. ... so for some real topic drift and trivia
question ... when mosaic was told that they couldn't use the name and
had to change their corporate name ... who owned the term netscape and
donated it to mosaic?

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

NEC drives

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: NEC drives
Newsgroups: alt.folklore.computers
Date: Tue, 09 Nov 2004 14:01:17 -0700

Morten Reistad  writes:

But I admit freely to have used e-mail regularly since November 17th,
1978 (with a small hiatus in 1984) and emacs since January 17th 1979.
Being an old fart is also a state of mind. (Lame excuse).

i admit freely to trying to read email back in the states while on a
business trip to paris in the early 70s ...
http://www.garlic.com/~lynn/subnetwork.html#internalnet

around the time EMEA hdqtrs moved from the states to Paris (new bldgs.,
La Defense, on the outskirts of paris) and I got to help clone a copy
of HONE for them
http://www.garlic.com/~lynn/subtopic.html#hone

i lost some archives from the early & mid '70s when there was a
datacenter glitch in the mid-80s that managed to clobber all three
tape copies.

does having a dial-up home terminal since march 1970 count?

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

What system Release do you use... OS390? z/os? I'm a Vendor S

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What system Release do you use... OS390? z/os? I'm a Vendor S
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 09 Nov 2004 21:23:20 -0700

rhalpern@ibm-main.lst (Bob Halpern) writes:

Do Interpretive Loop (DIL) instruction with the emulator
hardware. The 360/65 could do 704/709/7040/7090/7044/7094 series of
machines. JES3 was originally ASP (Attached Support Processor) to
batch up 70xx programs to run on a 360/65. The first support
processor was a 360/40. Later, a 65 could drive bunch of 360.50s.

in the early 70s (before virtual memory was announced for 370s), IBM
SE on the boeing account did a hack on the cp/67 kernel at the (ibm)
seattle datacenter to run on a 360/50 using DIL to provide base&bound
contiguous storage address relocation (as opposed to virtual memory
and paging).

basically a 30+ year old software version of LPARs.

totally unrelated ... my wife was a catcher in the gburg JES group
when ASP was transferred to gburg for JES3 ... one of her tasks was
reading the ASP listings and writing JES3 documents.

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 10 Nov 2004 06:51:13 -0700

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:

No, those in the know understood, and the others don't care 8-|.

Case in point: When VMS went SMP, the architects defined a hierarchy of
spinlocks to achieve deadlock avoidance. The implementors then created
three versions of the spinlock code, the version to be loaded being deter-
mined at boot time. One version was the NOP version for uniprocessors;
one version implemented the spinlocks _and_ checked that the acquisition
hierarchy was respected, with a bugcheck (aka suicide crash) happening
if not - this was the debugging and diagnosis aid for the SMP code; and
a third version that left out the checking for performance reasons.

charlie first did smp support for cp/67 after Lincoln Labs
discontinued one of its 360/67 processors and shipped it back to the
plant (and cambridge called the moving company and had it redirected
to 545tech sq ... and cambridge got to upgrade their machine to two
processor smp). it used a lot of spin-locks with test&set instruction
available on the 360/67 smp. this support never shipped to customers,
but out of the work, charlie invented compare&swap instruction which
showed up in 370s.
http://www.garlic.com/~lynn/subtopic.html#smp

later, i got to do a microcoded smp project called VAMPS
http://www.garlic.com/~lynn/submain.html#bounce

where i migrates lots of the vm/370 to microcode ... sort of enhanced
version of various vm microcode performance assists (i was working on
ecps for the 138/148 about the same time)
http://www.garlic.com/~lynn/subtopic.html#mcode

what remained of the vm kernel was essentially single-threaded but it
would use compare&swap semantics to place work on the
dispatch queue.  the microcode dispatcher pulled stuff off the
dispatch queue for different processors. if a processor had something
for the kernel and no other processor was currently executing in the
kernel (global kernel lock), it would enter the kernel. however, if
another processor was executing in the kernel ... there was a "kernel"
interrupt queued against the kernel ... and the microcoded dispatcher
would go off and look for other work (bounce lock, rather than
spinning on a global kernel lock that was common at the time). when
the microcode smp project was killed, there was an activity to adapt
the design to a software only implementation. The equivalent kernel
software (that had been migrated to microcode) was modified to support
fine-grain locking and super lightweight thread queuing mechanism (as
opposed to the hardware kernel interrupt).

this was shipped to customers as standard vm/370 product ... where the
customers now had two different kernels ... one with the inline
fine-grain locking and one w/o. however, all source was shipped and it
was common for a large number of the customers to completely rebuild
from source. the fine-grain locking was a combination of inline logic
with conditional assembly and "lock" macro which also had conditional
assembly statements. part of the issue was that there was actual
inline code in the dispatcher and other places for smp queue/dequeue
operations (instead of the possibly more straight-forward kernel
spin-lock logic).

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

The Sling and the Stone & Certain to Win

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: The Sling and the Stone & Certain to Win
Newsgroups: alt.folklore.computers
Date: Wed, 10 Nov 2004 07:04:19 -0700

some Boyd and OODA-loop drift ....

The Sling And The Stone ... off an infosec mailing list yesterday
http://www.washingtondispatch.com/article_10508.shtml

and related article, 4th Generation Warfare & the Changing Face of War
http://d-n-i.net/fcs/comments/c528.htm

Certain to Win, The Strategy of John Boyd, Applied to Business
http://d-n-i.net/richards/ctw.htm

Advance Reviews of Certain to Win
http://d-n-i.net/richards/advance_reviews.htm

and of course, lots of my other Boyd references
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

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

Scanning old manuals

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scanning old manuals
Newsgroups: alt.folklore.computers
Date: Wed, 10 Nov 2004 15:19:59 -0700

"Charlie Gibbs" writes:

Like many of us, I'm sure, I have a collection of old computer
manuals that's taking up a lot of shelf space.  In the name of home
renovations (and marital bliss) I would be willing to let go of some
of the newer (i.e. later than 1980) ones if I could scan them.  Like
most such manuals, they're 95% text (in a couple of typefaces and
sizes) and line drawings.  I presume the ideal solution is to use
some sort of scanning/OCR software to turn them into PDF files.  Is
there readily available software (preferably for Linux) to do this?
Have any of you embarked on such a project, and do you have any
words of wisdom to share?

i was just looking at asking the same question ... all sorts of odds
and ends stuff from the 60s and 70s.

however we just unearthed a bunch of old handwritten letters from the
40s ... that i would also be interested in scanning(?).

when i looked at some of this stuff nearly 10 years ago ... it all
seemed to be scaffolded off fax scanning, tiff format and ocr of
tiff/fax softcopy (current scanners appear to have much higher
resolution as well as color capability compared to the older fax
oriented stuff).

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

Integer types for 128-bit addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 10 Nov 2004 15:53:08 -0700

Anne & Lynn Wheeler writes:

this was shipped to customers as standard vm/370 product ... where
the customers now had two different kernels ... one with the inline
fine-grain locking and one w/o. however, all source was shipped and
it was common for a large number of the customers to completely
rebuild from source. the fine-grain locking was a combination of
inline logic with conditional assembly and "lock" macro which also
had conditional assembly statements. part of the issue was that
there was actual inline code in the dispatcher and other places for
smp queue/dequeue operations (instead of the possibly more
straight-forward kernel spin-lock logic).

for some source update drift ... there was some task (which has
somehow been lost in the fog of time) which required to go thru all of
the kernel source and change something(?) to something else(?) and add
something(?). people were complaining that it was going to take
possibly people weeks of time.

in a couple hrs we had written a RED edit exec (edimac, RED was one of
the fullscreen editors that some what predated xedit ... but never got
passed the internal use only scenario) ... and had its own exec
language ..  with a lot of the characteristics of rexx ... but
red-editor specific ...  while rexx can run as either xedit
environment or most any other environment) and some glue execs.

cms source update process used updates (as opposed to "down dates"
that you find with things like RCS); each change was a separate cms
file ... and the source update procedure would sequentially apply all
appilicable updates to the base source file and then re-assemble the
result (which was viewed as a temporary file).

the RED edit exec made whatever change that was necessary and
generated a unique sorce update file for the change. the process then
reran the build process to all kernel modules, applying all the source
updates (including the brand new generate file), re-assembled each
module and rebuilt the executable kernel.

instead of several person weeks ... it was a couple hrs to write all
the necessary procedural code ... and then turn it loose and the total
rebuild process (including finding and making the necessary source
code changes, generating the new source update file, re-assemble the
resulting temporary file, etc) took something like 22minutes elapsed
time (i have no idea why i remember how long it took to run ... and
don't remember what the change was).

at one time there was an analysis ... that the total number of lines
of source code modifications (to the kernel) on the waterloo/share
tape was greater than the total lines of source code in the base
product.

random past descriptions of the cms source update process:
http://www.garlic.com/~lynn/2000b.html#80 write rings
http://www.garlic.com/~lynn/2001e.html#57 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
http://www.garlic.com/~lynn/2002g.html#67 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002h.html#67 history of CMS
http://www.garlic.com/~lynn/2002n.html#39 CMS update
http://www.garlic.com/~lynn/2002n.html#73 Home mainframes
http://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
http://www.garlic.com/~lynn/2003.html#58 Card Columns
http://www.garlic.com/~lynn/2003e.html#38 editors/termcap
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003k.html#47 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#17 how long does (or did) it take to boot a timesharing system?
http://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004d.html#69 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2004g.html#44 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#21 Integer types for 128-bit addressing

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

pop secure connection

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: pop secure connection
Newsgroups: netscape.public.mozilla.general
Date: Wed, 10 Nov 2004 18:48:04 -0700

Nelson B writes:

so, I conclude that the server known as mail.garlic.com and also as
pop.garlic.com does NOT support StartTLS.

evolution does it fine. even windows/laptop w/eudora does it
fine. eudora even has a window that shows the last certificate &
session ... which also shows it at port 110.

I gather that either (a) these clients were not actually using
StartTLS or (b) you were using a different server.

Hope this helps clear it up.  I know this was pedantic for you, but
I wrote it for the benefit of others who may read it also.

i keep garlic.com even after a couple moves ... so many people know
the email as well as the urls for things like ietf index (the
rfc-editor's page lists this as one of the places for looking up
rfcs):
http://www.garlic.com/~lynn/rfcietff.htm

the glossaries
http://www.garlic.com/~lynn/index.html#glosnotes

etc. and so i use .forward, etc.

as i stated originally ... the isp (that i currently use) ...  works
using SSL to port 110 ... and that is how both eudora and evolution
are working.

i have iptables on (internet) interface machine with all ports locked
down ...  other than what is absolutely necessary ... aka outgoing 25
& 110 is enabled; outgoing 465 and 995 are not enabled. both eudora
and evolution are setup for SSL on port 110. eudora has feature that
shows last session, port number and server certificate used for the
ssl session. it shows port 110 used with the server certificate for
the ssl session.

even if i go outside the iptables boundary and try port 995 with this
specific isp ... it doesn't work. it only works with port 110.

as i mentioned in the previous post, inside iptables boundary ... with
outgoing port 110 enabled and outgoing port 995 disabled ... eudora
and evolution both work with SSL specified using port 110 (and you
can query eudora for the last pop session and it will show the ssl
certificate sent by the server and the port used ... aka port 110).

also, as per previous posts,
http://www.garlic.com/~lynn/2004o.html#26 pop secure connection
http://www.garlic.com/~lynn/2004o.html#28 pop secure connection

inside iptables "boundary", using numerous different versions of
mozilla and thunderbird ... i set things up for ssl pop on port 110
and they all hang and then eventually time-out w/o transferring any
email. i can see that there is a session initiated for port 110
... but i also see in the iptables log that mozilla/thunderbird while
having initiated a session on port 110 are also trying to do something
on port 995 ... which is being thrown away by the iptables rules.

again, both evolution (fc2 & evolution 1.4 and fc3 & evoluation
2.0) and eudora (6.0) work with ssl on port 110 going to the internet
thru the same iptable rules.

sending mail with ssl thru port 25 works for all ... evolution,
eudora, mozilla, and thunderbird. pop receiving mail with ssl thru
port 110 works for evolution and eudora but not with mozilla and
thunderbird.

based on seeing port 110 session being active when trying to use
mozilla and thunderbird ... but also seeing port 995 packets being
discarded (by iptables), i suspect that there is some common code
someplace that is ignoring the port 110 specification.

for some topic drift ... misc. other refs at garlic.com:

posts about domain name ssl certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

and a little about electronic commerce (from the early days of ssl,
even before the group moved to mountain view and changed their name):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

summary for rfc 2595
http://www.garlic.com/~lynn/rfcidx8.htm#2595

in the summary fields, clicking on the ".txt=nnn" field, retrieves
that actual rfc. clicking on the rfc number brings up the term
classification display for that rfc. clicking on any term
classification ... brings up a list of all RFCs that have been
classified with that term. clicking on any of the updated, obsoleted,
refs, refed by, etc RFC numbers ... switches to the summary for that
RFC.

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

Facilities "owned" by MVS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Facilities "owned" by MVS
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 11 Nov 20