List of Archived Posts

2005 Newsgroup Postings (04/05 - 04/22)

IBM Password fun

System/360; Hardwired vs. Microcoded

Mozilla v Firefox

Mozilla v Firefox

System/360; Hardwired vs. Microcoded

System/360; Hardwired vs. Microcoded

Where should the type information be: in tags and descriptors

new Enterprise Architecture online user group

Mozilla v Firefox

TLS-certificates and interoperability-issues sendmail/Exchange/postfix

Where should the type information be: in tags and descriptors

Mozilla v Firefox

Mozilla v Firefox

ISA vs. patent/trademark

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

Mozilla v Firefox

Is Supercomputing Possible?

Where should the type information be: in tags and descriptors

Some questions on smart cards (Software licensing using smart cards)

Where should the type information be: in tags and descriptors

System/360; Hardwired vs. Microcoded

the relational model of data objects *and* program objects

System/360; Hardwired vs. Microcoded

Where should the type information be: in tags and descriptors

the relational model of data objects *and* program objects

the relational model of data objects *and* program objects

Where should the type information be: in tags and descriptors

Where should the type information be?

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

the relational model of data objects *and* program objects

Where should the type information be: in tags and descriptors

[Lit.] Buffer overruns

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

[Lit.] Buffer overruns

OTP (One-Time Pad Generator Program) and MD5 signature

Moving assembler programs above the line

Moving assembler programs above the line

Moving assembler programs above the line

DNS Name Caching

Moving assembler programs above the line

Moving assembler programs above the line

Moving assembler programs above the line

1403 printers

Moving assembler programs above the line

Where should the type information be?

1403 printers

1403 printers

Where should the type information be: in tags and descriptors

1403 printers

What is the "name" of a system?

1401-S, 1470 "last gasp" computers?

Moving assembler programs above the line

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

Where should the type information be: in tags and descriptors

single-signon with X.509 certificates

Moving assembler programs above the line

IBM Password fun

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Password fun
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 05 Apr 2005 10:09:28 -0600

edgould@ibm-main.lst (Ed Gould) writes:

Hi,

Two days ago I complained on here about IBM's insistance on a "strong"
password silliness for a subscription to their HOT TOPICS bulletin.

I sent in a *NICE* email and ask them to revisit the password issue. I got
back the following reply:
------------------------------------------------------

The site you have mentioned is being closed down at the end of May. It
will then be converted to another site
:https://www-1.ibm.com/support/mysupport/us/en/
This site runs on what is called an IBM ID, This id is used on most
of IBM´s sites. If you already have one then you can use that here
as well. It works the same way as the site you have linked to below.

ref. to password rules from long ago and far away
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#53 April Fools Day

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

System/360; Hardwired vs. Microcoded

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/360; Hardwired vs. Microcoded
Newsgroups: alt.folklore.computers,comp.arch
Date: Tue, 05 Apr 2005 11:37:46 -0600

"Lee Courtney" writes:

At HP we went though what I believe was a similar exercise with the
HP 3000 Series 64. When VISION was delayed in lieu of SPECTRUM, the
3000 product line was in a bad place with no imminent performance
upgrade in the pipeline. As a stop-gap measure we shipped
disc-caching as the Series 68 and Series 70. When the customer
upgraded they got a new face-plate (64-68) and a microcode tape. I
believe the 70 included additional memory (important for disc
caching). But, many customers were under-whelmed with the amount of
change they saw for the dollars they paid. However, a great product
with lots of customer benefit that really saved HP's bacon at the
time.

Sounds like the 168 was a field upgrade from the 165. Was the
original 165 designed to accommodate virtual memory, or was VM an
after-thought?

On a related note I am assuming that the 158 did not share any
lineage with the 155? That the 155 was more a backwards leaning
360'ish machine than forward leaning 370 architecture machine. The
timing of the 155/165 relative to the 158/168 announcements might
lead one to believe there was some linkage between the systems.

Thanks!

Lee Courtney

158/168 were new technology ... compared to 155/165 ... especially the
faster real memory technology. however, i believe the architecture of
the native engines were the same and so the same microcode could work.

155/165 weren't designed for virtual memory and required extensive
hardware retrofit to install it in existing boxes.

in the early 70s ... most of my POK visits involved 370 architecture
meetings ... and didn't run into many cpu engineers ... other than who
might show up in such meetings.

in the mid/late 70s ... i got involved with the cpu engineers working
on the 3033 ... i was even invited to their weekly after work events,
if i happened to be in town (honorary cpu engineer?).

part of the issue was that 370 (non-virtual memory) was just an
interim/stop-gap. the real followon was going to be FS (future
system). there was huge resources poured into FS ... and it was
finally canceled w/o being announced (and few were even aware of it).
http://www.garlic.com/~lynn/subtopic.html#futuresys

as noted in previous posts on FS ... i didn't make myself very popular
with the FS crowd ... somewhat panning their effort (there was this
long-playing cult film down in central sq ... and I made the analogy
to FS of the inmates being in charge of the asylum).

as in other references to FS, FS was supposedly spawned by the emergence
of the 360 control clone market ... example:
http://www.garlic.com/~lynn/2000f.html#16 FS - IBM Future System

... aka in above refernece it mentions that 2500 were initially
assigned to the project designing FS.

I worked on a project as an undergraduate that created a clone
telecommunication controller (reverse engineer the ibm channel,
adapt a interdata/3, etc)
http://www.garlic.com/~lynn/subtopic.html#360pcm

there later was a write up blaming the four of us for spawning
the controller clone business.

FS may have then contributed to creating 370 clone mainframe market.
Amdahl may have left to form his own 370 company in disagreement over
the FS direction/strategy (as opposed to bigger, faster 370).
http://www.garlic.com/~lynn/2005e.html#29 Using the Cache to Change the Width of Memory
http://www.garlic.com/~lynn/2005e.html#35 Thou shalt have no other gods before the ANSI C standard

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

Mozilla v Firefox

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mozilla v Firefox
Newsgroups: netscape.public.mozilla.general,alt.folklore.computers
Date: Tue, 05 Apr 2005 13:03:29 -0600

"Phillip M. Jones, C.E.T" writes:

Ahh! but that is only a weak excuse. As you can pickup a brand new
windoze keyboard at OfficeMax for 30 bucks or less.

Now on a Macintosh That's another story. Mac keyboards can only be
found at Apple stores, Apple sanctioned outlets (CompUSA being an
example) or Catalog only. Place like OfficeMax, and Staples, and
Office Depot just don't carry them.

I uses a MacAlley iKey USB extended keyboard I bought when I purchased
my G4-500.

I use compressed air to blow it out every so often. But key feel, and
ability to type all the characters are as good now as then. My problem
is my Hunt and Peck typing system.

I was brought up in an era when if men/boys were caught in typing
class they were considered "gay". because Typing was a womens' only
profession.

Boys were expected to do vocational training, (Car repair,
metalworking, Woodworking, Electronics).

Also, if girls were caught taking VoTech training they also were
considered "gay" as well. (Note I am using the modern term, then they
used the 50/60ites term which was not as endearing).

In any event I never took typing. and By the time computers rolled
around I s too old and had too much arthritis to take the classes.
So its amazing that I ell as well as I do.

i was greasing trucks, tractors, plows and driving 2.5 ton truck the
summer i turned 9; starter motor was a pedal you pushed on the floor;
didn't have syncro-mesh ... had to double-clutch most of the vehicles.
one of the trucks and some of the tractors didn't even have starter
motors, old fashioned hand crank at the front. one of the things i
still don't think i've figured out is how you get fence posts in
perfectly straight-line ... even when you have stretched the top wire
as a guide (mine were always off a couple inches one way or another).

when i was about 11-12, i found a 30s-era typewriter and a
instructional typing manual also published in the 30s ... and taught
myself how to type. i got up to about 35-40wpm.

its a laptop ... nearly 3month old vaio a290 with 17in screen (hard
disk completely wiped with fresh FC3 install). I called sony ... but
they said take it into the store i bought it from.

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

Mozilla v Firefox

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mozilla v Firefox
Newsgroups: netscape.public.mozilla.general,alt.folklore.computers
Date: Tue, 05 Apr 2005 17:41:30 -0600

Anne & Lynn Wheeler writes:

still don't think i've figured out is how you get fence posts in
perfectly straight-line ... even when you have stretched the top wire
as a guide (mine were always off a couple inches one way or another).

something i learned how to use when i was a kid:
http://website.lineone.net/~dave.cushman/fencepliers.html

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

System/360; Hardwired vs. Microcoded

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/360; Hardwired vs. Microcoded
Newsgroups: alt.folklore.computers,comp.arch
Date: Wed, 06 Apr 2005 09:27:32 -0600

mschaef@fnord.io.com (MSCHAEF.COM) writes:

Can anybody talk a little more about what made the 195 special?

an unrelated 195 story ... the 195 had 64 instructions in the pipeline
and no branch prediction ... a branch (that wasn't to an instruction
already in the pipeline ... aka loop) would cause the pipeline to
draine. unless it was very specialized looping codes ... normal
instruction stream ran the 195 at about half peak ... because of the
frequence of branches.

i got somewhat involved when the 195 product engineers were looking at
adding two processor 195 support ... actually the original
hyperthreading (that intel processors have recently gone thru a
phase); basically a second set of registers and psw and the pipeline
would have red/black flag ... indicating which instruction stream
stuff was associated with. it looked like SMP to software ... but to
the hardware it was hyperthreading two instruction streams (dual
i-stream).  the idea was that if avg. software only kept the pipeline
half full because of branches ... that two instruction streams had a
chance of keeping the pipeline full ... and achieving peak instruction
processing rates (these machines had no caches ... and so were much
more sensitive to memory latencies).

however, it was never announced and shipped.

sjr/bld28 still had a 195 in the late 70s ... running heavy batch
workload. palo alto science center had an application that they
submitted ... but because of the processing queue ... it only got run
about once every three months. pasc finally did some work on the
application for checkpointing and running under cms batch in the
background on their 370/145 vm/cms system. it would soak up spare
cycles on the machine offshift and weekends. the elapsed time was
slightly better than the 3month turnaround at the sjr 195 (because of
the long work queue).

gpd was also running an application on the 195 that was getting
excessive long turn arounds ... air bearing simulation ... for design
of the new disk floating heads.

we had done this work over in the disk enginnering lab (bldg 14) and
product test lab (bldg 15) so that they could run under operating
system environment. prior to that, they were running dedicated
stand-alone ... they had tried MVS at one time and were getting about
15minutes MTBF when running a single test cell. bullet proofing the
operating system I/O subsytem allowed them to operate half-dozen or so
test cells concurrently w/o failing.
http://www.garlic.com/~lynn/subtopic.html#disk

in any case, the disk product test lab in bldg. 15 tended to get
something like the 3rd machine model ... after the first two that cpu
engineers were testing with. because of the operating system work for
the disk guys ... i would have access to these new machines.  when
endicott was building the 4341 ... the endicott performance people
asked me to do benchmarks on the bldg. 15 4341 (because i had better
access to a 4341 than they did in endicott).

anyway, bldg. 15 also got an early 3033. 3033 ran about half the speed
of 195 peak ... but about the same as the 195 for most normal
workloads. while the disk regression tests in bldg. 15 were i/o
intensive ... they bairly blimped the cpu meter. so one of the things
we thought would be useful was get the air bearing simulation
application up and running on the bldg. 15 3033 ... where it could
soak up almost the complete cpu with little competition ...  much
better than a couple turn-arounds a month on 195 across the street in
sjr/28.

minor past posts mentioning the air bearing simulation application:
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004b.html#15 harddisk in space
http://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns

some past posts mentioning 195
http://www.garlic.com/~lynn/2000c.html#38 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#21 Competitors to SABRE?  Big Iron
http://www.garlic.com/~lynn/2000f.html#13 Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?
http://www.garlic.com/~lynn/2000f.html#21 OT?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#18 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001c.html#27 Massive windows waisting time (was Re: StarOffice for free)
http://www.garlic.com/~lynn/2001h.html#49 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001n.html#38 Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#41 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2001n.html#80 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2001n.html#86 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2002h.html#19 PowerPC Mainframe?
http://www.garlic.com/~lynn/2002h.html#23 System/360 shortcuts
http://www.garlic.com/~lynn/2002.html#50 Microcode?
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2002o.html#44 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002p.html#58 AMP  vs  SMP
http://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#37 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
http://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003h.html#47 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003j.html#41 Of what use 64-bit "General Purpose" registers?
http://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2004b.html#15 harddisk in space
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004c.html#13 Yakaota
http://www.garlic.com/~lynn/2004c.html#29 separate MMU chips
http://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
http://www.garlic.com/~lynn/2004f.html#58 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004.html#22 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004.html#24 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?
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#59 Lock-free algorithms
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#2 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#19 The Soul of Barb's New Machine (was Re: creat)
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/94.html#39 IBM 370/195
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#24 old manuals
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/99.html#209 Core (word usage) was anti-equipment etc

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

System/360; Hardwired vs. Microcoded

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/360; Hardwired vs. Microcoded
Newsgroups: alt.folklore.computers,comp.arch
Date: Wed, 06 Apr 2005 12:18:51 -0600

ref:
http://www.garlic.com/~lynn/2005f.html#4 System/360, Hardwired vs. Microcoded

195 ran about 10mips peak ... but most normal codes (not specifically
designed for looping in the pipeline) ran more like 5mips.

related to previous post about 168 ... 168-3 was about a 3mips
machine
http://www.garlic.com/~lynn/2005f.html#1 System/360, Hardwired vs. Microcoded

the 3033 started out being a mapping of the 168 design to faster chip
technology resulting in about 20% higher mips. the chips in the 3033
were much higher density than those used in 168 (by about factor of
ten times) ... but the design started out only using the same number
of cicuits/chip as in the 168 original implementatation. part-way thru
the design ... there was an effort to do partial redesign and leverage
much higher circuit chip density ... which brought the 3033 up to
about 4.5mips (50% more than 168).

moving the air bearing simulation application from the sjr/28 195 to
the 3033 in bldg.15 ran about the same speed ... but the 3033 was
effectively cpu idle with no backlog (of cpu related work) ...
significantly improving the design cycle for the new 3380 floating
heads
http://www.garlic.com/~lynn/subtopic.html#disk

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Thu, 07 Apr 2005 19:36:50 -0600

"Stephen Fuld" writes:

I don't think we would necessarily be better off.  I just don't see
using MVS as a "desktop" OS, and even VM/CMS is far from what most
programmers today would like to use.  Besides, there have been
"desktop 370s" and they didn't sell very well.  They were expensive
and somewhat limited.

there was this joke in the early MVS time-frame that CMS had a 64kbyte
MVT simulator (built into the CMS kernel) and MVS had an 8mbyte MVT
simulator (and CMS did a very respectable job with its 64kbyte MVT
simulator ... compared to MVS's 8mbyte MVT simulator).

the first deckstop 370 was the xt/370 ... which was a co-processor
board for an xt/pc. the CMS applications and orientation was
significantly more resource (disk I/O and real storage) hungry
compared to dos applications of the period (somewhat analogous to the
difficulty they had craming mac/os into the early mac machines).

the initial project was called washington and it was going to ship
with 384k bytes memory for the 370 side. the cp kernel was specially
modified to do all i/o from interprocessor communication to an
application called cp/88 running on the 8088 side (which then do
various disk, screen, keyboard, etc i/o).

the combination of the cp kernel fixed memory requires and the cms
applications of the period (which typically might be used for
interactive computing and/or program development) resulting in severe
page thrashing. the page thrashing was aggravated by the fact that the
page i/o had to be passed over to cp/88 which then would perform the
operation on a 100ms/operation hard disk (when mainframe users were
use to doing multiple collected in i/o operations in 16ms or less).

i showed a number of page trashing benchmarks and they then blamed me
for causing the product ship being delayed while they upgraded the
memory from 384k to 512k. the extra memory slightly mitigated some of
the worst page thrashing scenarios ... but it still couldn't redo the
significant memory and disk i/o requirements of the typical cms
operations. As a side note, the earlier cp67/cms had been able to
support multiple users on 256k byte 360/67.

even when the hardware (real memory sizes and disk thruput) started to
catch up with the typical CMS application operational target ... it
was still stuck with a lot of the mainframe oriented application
pricing structures.

there was a project in the early to mid-80s that looked at redoing
a cms-type implementation that would be agile ... somewhat the
boyd influence
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

and portable across a number of different platforms ... but it
somewhat collapsed when they started trying to through everything into
the project ... including the kitchen sink.

misc. past washington, xt/at/370 postings
http://www.garlic.com/~lynn/94.html#42 bloat
http://www.garlic.com/~lynn/96.html#23 Old IBM's
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
http://www.garlic.com/~lynn/2000.html#75 Mainframe operating systems
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#89 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001f.html#28 IBM's "VM for the PC" c.1984??
http://www.garlic.com/~lynn/2001i.html#19 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001k.html#24 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002f.html#44 Blade architectures
http://www.garlic.com/~lynn/2002f.html#49 Blade architectures
http://www.garlic.com/~lynn/2002f.html#50 Blade architectures
http://www.garlic.com/~lynn/2002f.html#52 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003f.html#8 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003h.html#40 IBM system 370
http://www.garlic.com/~lynn/2003m.html#27 Microsoft Internet Patch
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2004f.html#58 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
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#13 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#27 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005f.html#1 System/360; Hardwired vs. Microcoded

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

new Enterprise Architecture online user group

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: new Enterprise Architecture online user group
Newsgroups: comp.arch
Date: Fri, 08 Apr 2005 09:45:01 -0600

"Michel Hack" writes:

The net of all of this is that IBM mainframes have had mechanisms to
manage large amounts of memory for nearly 20 years.  The 31-bit
addressing limit still applied to the maximum size of a single
object (e.g. an array), which may have limited scientific
applications, or (more recently) image processing -- but commercial
applications (the primary market for this architecture) were served
well enough that the pressure to move to 64-bit was not as great as
one might have thought.  (The multiple-space features still exist in
64-bit mode, btw, but the motivation to exploit this would most
likely be to structure space, not to expand it.)

recent post on some of the evolution of dual-address space, program
call, and access registers (originating from 24-bit addressing days):
http://www.garlic.com/~lynn/2005b.html#53 The mid-seventies SHARE survey

note that this sort of like using segment registers to "window" across
larger address space, except kernel calls weren't needed. early ROMP
documentation sort of alluded to something similar by claiming 40-bit
addressing (but only 32-bits at a time) and then later RIOS claiming
52-bit addressing (again only 32-bits at a time).

misc. past program call references:
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/98.html#36 What is MVS/ESA?
http://www.garlic.com/~lynn/2001d.html#30 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001h.html#73 Most complex instructions
http://www.garlic.com/~lynn/2001k.html#16 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002n.html#74 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003c.html#13 Unused address bits
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#53 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#52 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general

lots of past references to dual-address space, etc
http://www.garlic.com/~lynn/2000c.html#84 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#58 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
http://www.garlic.com/~lynn/2002g.html#18 Black magic in POWER5
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2002l.html#57 Handling variable page sizes?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002q.html#1 Linux paging
http://www.garlic.com/~lynn/2003c.html#13 Unused address bits
http://www.garlic.com/~lynn/2003d.html#53 Reviving Multics
http://www.garlic.com/~lynn/2003d.html#69 unix
http://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003m.html#29 SR 15,15
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004f.html#27 [Meta] Marketplace argument
http://www.garlic.com/~lynn/2004f.html#53 Infiniband - practicalities for small clusters
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?
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#53 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"

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

Mozilla v Firefox

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mozilla v Firefox
Newsgroups: netscape.public.mozilla.general,alt.folklore.computers
Date: Fri, 08 Apr 2005 10:38:55 -0600

stanb45@dial.pipex.com (Stan Barr) writes:

...and I use a laptop-size keyboard on one of my machines, only the
basic keys and doesn't take over all the workspace.  I can't
understand this fascination for having *hundreds* of keys so you
have to keep moving your hands away from the main keys, it's bad
enough having to dive over to the mouse all the time!

in late 70s, early 80s, the san jose human factors group had built a
chord keyboard ... somewhat in the shape of a mouse, sort of rounded
half-sphere with figner tip depressions ... which had multi-position
rocker switches; touch typists that would spent a little time with the
device ... claimed they quickly exceeded qwerty typing speed (80 wpm
not unusual).

you marry such a design with an optical mouse ... with one for both
hands ... you never have to leave position.

the original prototype for the eraser head "mouse" (between g/h/b
keys) was two thumb sliders in front of the space bar (one controlling
x-motion and the other controlling y-motion).

quicky search engine use ... a couple descriptions/discussions of
chord keyboards:
http://deafandblind.com/computer-keyboard.html

augment had a much simpler chord keyboard for one hand leaving
the other hand available for mouse
http://www.idealliance.org/papers/dx_xml03/papers/05-00-00/05-00-00.html
http://www.comphist.org/computing_history/new_page_11.htm

somewhere i thot i had a URL for picture of augment chord keyboard,
but can't seem to find it at the moment

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

TLS-certificates and interoperability-issues sendmail/Exchange/postfix

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TLS-certificates and interoperability-issues sendmail/Exchange/postfix ..
Newsgroups: comp.security.unix,comp.mail.misc,comp.mail.sendmail
Date: Fri, 08 Apr 2005 12:02:00 -0600

another kind of attack on the SSL domain name certificates ... is
the limited use of SSL.

the original SSL was supposed to be for the whole e-commerce
experience ... starting at the time you selected the web site.  the
browser then checked that the URL that was typed in matched the domain
name in the certificate that the webserver provided (after validating
the certificate with a public key in the browser's trusted public key
repository and validating that the server could do some valid
operation with a private key that corresponded to the public key in
the SSL domain name certificate).
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the problem was that most web sites found SSL too expensive for most
operations ... as a result you went to a website with the URL that you
had provided, but it wasn't using SSL and so there was no cross-check
that the website your were visiting was the website you thot you were
visiting (corresponding to the URL that you had typed in).

later in the shopping experience, a button was provided that would
take you to an SSL payment website. However, since you hadn't typed in
the URL for the SSL payment website ... but the URL had been provided
by the button ... it is likely that any fradulent e-commerce site
would provide a button with a URL that corresponded to some SSL domain
name certificate that was under the crooks control (i.e. the crooks
would make sure that the URL invoked by a button from a fraudulent
website ... would correspond to a URL in a valid SSL domain name
certificate that they had obtained).

some additional topic drift ... recent domain name infrastructure
integrity news items:
http://it.slashdot.org/it/05/04/08/1528213.shtml?tid=172&tid=95&tid=218
http://isc.sans.org/diary.php?date=2005-04-07

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Fri, 08 Apr 2005 13:50:01 -0600

"gerard46" writes:

| If you are talking VM/370 then I think it was about 800k.

For a single user?  256k, maybe even 128k if you don't mind a little
paging.  I supported VM/370 in 512k, and that was with a 256k VS/1
V=R region, and about 20 CMS
users. ________________________________Gerard S.

it depends when you are tallking about ... late 70s and continuing
into the 80s, there was increasing bloat ... with more and more code
migrating to the fixed kernel. also you have to consider the "working
set" sizes of the applications that were also bloating (less & less
space for paging because of fixed kernel requirements and larger and
larger working set sizes as applications bloated).

original cp/40 with cms ran on 256k 360/40 (custom modified with
virtual memory hardware) supporting multiple cms users. cp/40 then
morphed into cp/67 with the availability of 360/67

here is some paging and and storage size benchmark from '68 ... where
i artificially would reduce amount of pageable real memory
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14

cp/67 fixed kernel size continued to grow over time. part of the issue
was people from traditional operating system viewed the kernel as the
place to implement function ... as opposed to the baseic cp/67 premise
of being a hypervisor/microkernel.

the summer of '69, i did a stint at recently formed BCS and started
fealing that the kernel size was getting out of hand. As part of that
i created the pageable kernel paradigm (which was not shipped as part
of cp/67 ... but was picked up later for vm/370). The implementation
didn't use virtual memory ... it just moved 4k hunks of kernel code
to&from memory & disk.

In order to do it, I had to facture some number of low-useage routines
that were much larger than 4k. One was console functions. Previously
console functions had been one large module (with internal address
constant pointers). With the fracture, the command lookup was in fixed
kernel ... but most of the actual console command handling code was
split out into individual routines (each less than 4k and package on
4k boundaries).

CP67 and CMS shipped effectively everything as source ... except for a
modified BPS loader that was used for kernel initialization. The BPS
loader still contained a limit of 256 entry symbols/points. With the
facture of routines for 4k page packaging ... a lot of new entry
symbolds were introduced which drive the total number of cp67 ESD
entries over 256 ... causing the modified BPS loader to fail ... and
you could no longer initialize the kernel. This caused me quite a fit.

In any case, by the end of the cp67 cycle ... I don't remember any
256k 360/67 still being used. Then there was the morph to vm/370. I
don't remember the release 1 customers ... but I do remember being
called down to NYC to a nowegian shipping company that was trying to
get vm/370 running on a 256kbyte 370/125 ... and having huge
difficulties. I did several things to (late release 2?) vm/370 fixed
kernel to get it back comperable to cp67 kernel (aka under 100k
bytes).

as i mentioned in the recent xt370 post ...
http://www.garlic.com/~lynn/2005f.html#6 Where should the type information be: in tags and descriptors

the original xt/370 going to ship with 384k (370) memory ... which was
to hold both fixed kernel as well as all application
paging. Benchmarking that I did on the machine showed almost
everything you wanted to do resulted in some kind of page
thrashing. The page thrashing was exacerbated by all I/O operations
were handed off to CP/88 monitor ... running on dos which in turned
translated it to dos i/o to a 100ms/operation hard disk.

on a real mainframe ... there were much faster hard disks ... and for
big operations ... you could have large multi-block transfers ...
which tended to mitigate human factor perception related to latencies.

Almost any interactive thing you might try and the xt370 side
... tended to compare very poorly with similar application designed
specific for the resources available in typical dos environment.

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

Mozilla v Firefox

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mozilla v Firefox
Newsgroups: netscape.public.mozilla.general,alt.folklore.computers
Date: Fri, 08 Apr 2005 15:45:53 -0600

Brian Inglis writes:

2780/3780 JES2/3 links are notoriously finicky and tend to drop the
connection if it gets something it doesn't like; sometimes it even
brings JES down, which effectively shuts down MVS.

it used to be when JES crashed it would cause the whole system to
crash ... including MVS.

one of the early JES networking problems was that it had jumbled up
the design of the JES networking header fields ... and slight changes
in JES networking fields could cause the system to crash.

one of the issues on the internal network (larger than the
arpanet/internet until about mid-85)
http://www.garlic.com/~lynn/subnetwork.html#internalnet

was JES boundary nodes that could crash each other ... different JES
releases might have slight variation in networking header fields,
sufficient to cause other JES nodes (on the internal network) at
slightly different releases to crash.

one of the other early JES networking design problems was that it
built its networking node definitions using the old time hasp psuedo
device table ... which had 255 entries (one byte index). a typical
installation might have 60-80 psuedo devices defined ... leaving
something like 160-190 entries for networking node definitions.
further exaserbating the problem was that JES would discard all
traffice where it didn't recognize either the destination or the
origin node.

the internal network had quickly passed 255 nodes in the mid-70s
(something that the arpanet/internet didn't do until after the great
1/1/83 switch over to internworking protocol) ... and so JES was
unuseable on the internal network for other edge/boundary nodes. Eeven
as an edge/boundary node, it still had the habit of discarding traffic
where it didn't recognize the origin (a MVS system with a large and
varied user population found it impossible to juggle the 160 or so
network node definitions to keep all the users happy all the time).

the tendency for different JES releases to crash each other resulted
in a body of canonicalizing gateway code in the internal network
mainstay nodes. This gateway code directly talking to a JES node would
be setup with JES header rewrite code specific for that JES release.
(in order to prevent one JES node from crashing other JES nodes).

there was an early-on infamous case where JES systems in San Jose
(cal.) was causing MVS systems in Hursley (uk) to crash ... and they
blamed it on the gateway code not keeping one JES system from
crashing another JES system.

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

Mozilla v Firefox

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mozilla v Firefox
Newsgroups: netscape.public.mozilla.general,alt.folklore.computers
Date: Fri, 08 Apr 2005 19:20:14 -0600

Brian Inglis writes:

One question I always meant to ask: did it never occur to the MVS
weenies that adding similar code to JES itself might be a good idea?
I'd have written a Script APAR DTD and been mailing IBM daily if I'd
ever encountered such stupid problems, probably with suggested PTFs.

"customers" never had that large a network ... and always keep their
"small" configurations in-sync .... and back then you never had
customers "interconnecting" with one another.

it only became a problem in larger networks where organizations
weren't keeping all their interconnected networking JES systems
in-sync (aka working as designed).

basically the JES2 code was pretty much the HASP "networking" code (in
the morphing and renaming from HASP -> JES2) ... some of the JES2
networking code still retained the "TUCC" identifier in in cols 68-71
... from hasp days from networking implementation for hasp by triangle
university.

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

ISA vs. patent/trademark

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ISA vs. patent/trademark
Newsgroups: comp.arch,comp.arch.embedded,comp.arch.fpga
Date: Sat, 09 Apr 2005 11:44:17 -0600

jsavard writes:

And they can handle unaligned operands, but it takes at least four
instructions:

A     5,ALIGNED

becomes, say

LH    6,UALIGNED
SLL   6,16
IH    6,UALIGNED+2
A     5,6

or even

LC    6,UALIGNED
SLL   6,24
L     7,UALIGNED+1
SR    7,8
N     7,#X'00FFFFFF'
O     6,7
A     5,6

ICM was introduced with 370 ... insert character under mask

     ICM   6,B'1111',UNALIGNED
     AR    5,6

problem with LH was that it was arithmetic (not logical) and
propagated the sign bit (and it required half-word alignment).

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Sat, 09 Apr 2005 15:00:54 -0600

"David Wade" writes:

I did try ZED briefly but probably not enough to be a 1st DAN black
belt, whereas with REXX/XEDIT I guess I was getting close:-) (former
collegues may not share this view)

But if you have never used the full screen directory functions that
are RDRLISt and FILELIST and the sname/stype/smode commands then you
would not appreciate how powerfull a 3270 was. The things you could
do with those and few well defined PF keys and a quick REXX
exec. Then when you add in the prefix area and block moves and
copies. If you really wanted to fly you might try split screen
editing when you want to look at multiple files.  Don't tell me you
print it out! I will admit you needed a Co-ax attached local
terminal, but once you had one you could stick line mode in dark
place where no one wandered.

I still miss some of these things on Windows and Solaris, but for
some reason Thomas Hessling Editor (THE) or even EMACS which provide
much of the equivalent functionality do not seem to cut the mustard
in the same way as the above did....  When on Windows I find myself
using Explorer and PFE32, which I am sure are not as good. (though
again the old right click and open with....)

theo alkema's fulist, browse, ios3270, etc predated RDRLIST &
FILELIST.  then somebody at SJR did a PC flist clone that was released
thru the productivity program (fairly early in the dos cycle ... i
think about the time of the internal only distribution referred to as
dos1.8)

minor past fulist refs:
http://www.garlic.com/~lynn/2001f.html#8 Theo Alkema
http://www.garlic.com/~lynn/2001f.html#9 Theo Alkema
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004q.html#63 creat

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Sun, 10 Apr 2005 08:02:57 -0600

"David Wade" writes:

things like FILELIST etc were actually pretty easy to debug as they
were largeley written in REXX...

very early in rexx cycle (when it was still called rex and before it
was released) ... i wanted to demonstrate the usefulness of rex as not
just another command scripting language (i.e. sort of the norm at the
time and being compared to the original cms EXEC and the newer EXEC2
from ykt).

there was ipcs, a dump analysis program ... written in some 40(?)
klocs assembler; some of the objectivives were 1) working half-time
over a 3month period ... 2) write in rex something that had ten times
more function than the original ipcs, 3) was ten times faster than
(the assembler) ipcs, and 3) (since this was in the start of the
object-code-only debate/wars) do an implementation where the source
had to be shipped.

misc. past posts
http://www.garlic.com/~lynn/subtopic.html#dumprx

... from long ago and far away

DUMPRX Release 2 - ENHANCED DUMPSCAN PROGRAM WRITTEN IN REX

DUMPRX release two is now available. DUMPRX is a program for
processing IPCS abend PRB files. It is similar to the IPCS DUMPSCAN
program. DUMPRX is almost completely written in REX and has several
additional features not found in DUMPSCAN. The major new enhancement
in release 2 of DUMPX is support for XEDIT-mode.  DUMPRX will now
operate as a XEDIT macro with all input and output being processed
through a work file.  Rather than displaying responses directly to the
terminal, the information is inserted into the work file. This allows:

1) XEDIT commands to display, scan, and/or search the DUMPRX replies.

2) save and restore the complete log of the terminal session(s)
associated with the DUMPRX analsysis of a particular PRB file.

3) allow the specificiation of particular screen tokens for use as
arguments in DUMPRX commands.

Optionally available are updates to the CP source which enhance the
ability of DUMPRX for use in problem determination.

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Sun, 10 Apr 2005 08:30:08 -0600

Anne & Lynn Wheeler writes:

Optionally available are updates to the CP source which enhance the
ability of DUMPRX for use in problem determination.

so one of the CP source enhancements indirectly arose from
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors

when i was originally doing cp67 pageable kernal code and trying to
figure out the modified BPS loader problem ... I realized that when
the BPS loader exited to the loaded program ... it passed the address
of its symbol table (and the number of entries) in registers. so I did
this hack that before CP wrote the kernel boot image to disk, it would
copy the complete symbol table ... entry point symbols, entry point
symbol type type (ESDID), and addresses ... to the end of the pageable
kernel so it would be included in the boot image written to disk.

this bit of cp67 code was never shipped to customers and in the morph
from cp67 to vm370 pageable kernel support ... the part about
appending the complete kernel symbol table was dropped.

as part of DUMPRX kernel debugging enhancements, i included the kernel
updates to automatically capture and include the complete kernel
symbol table as part of the boot image.

if DUMPRX found a complete symbol table ... it would optional display
the appropriate addresses as "aboslute" ... or as relative to closest
"type 0 kernel entry point symbol" plus displacement. this was an
alternative to the "IPCS" supported option which allowed the appending
of a kernel subset symbol table as part of post processing. One of the
issues with doing it as part of post processing was that the selected
subset table might be out-of-sync with the kernel actually being
processed. having it appended as part of the base kernel image, made
sure you were never dealing with an out-of-sync kernel symbol table.

couple old posts describing compiler/assembler generated ESD image
format (i.e. the imput for loaded processing ... stuff that then went
into the loader symbol table):
http://www.garlic.com/~lynn/2001.html#8 finding object decks with multiple entry points
http://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)
http://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)

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

Mozilla v Firefox

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mozilla v Firefox
Newsgroups: netscape.public.mozilla.general,alt.folklore.computers
Date: Sun, 10 Apr 2005 09:26:41 -0600

rsteiner@visi.com (Richard Steiner) writes:

My KVM switch uses Scroll Lock as the hot key (ScrLck-ScrLck-1 takes me
to system #1, ScrLck-ScrLck-2 to system #2, etc).

i have two different switches ... one does double taping scrlck and
then number; the other just does double taping scrlck and toggles
between two systems.

I assume the first must be a subset of some switch that allows more
than two system connections (and therefor need to select). the other
is much simpler to just toggle between two systems.

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

Is Supercomputing Possible?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Supercomputing Possible?
Newsgroups: comp.arch
Date: Sun, 10 Apr 2005 09:41:30 -0600

"Rupert Pigott" writes:

Cray did make a stab at the DB/server market, but they used a pile
of SPARCs to do it in the form of the CS6400.

Here's some Oracle 7 related PR fluff for it.

we were sort of went the opposite with ha/cmp, minor
reference:
http://www.garlic.com/~lynn/95.html#13

at the time, there was standardization on three interconnects
... hippi, somewhat out of lanl on standardizing cray channel;
... fcs, someout out of llnl (they had a copper serial that started
out somewhat being the basis of fiber fcs); ... sci, somewhat out of
slac.

(at least) convex, sequent, and dg did sci implementations (convex
using 2-way HP boards for 128 processors; sequent and dg using 4-way
intel boards for 256 processors).

past ha/cmp posts
http://www.garlic.com/~lynn/subtopic.html#hacmp

random past dlm posts
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001.html#40 Disk drive behavior
http://www.garlic.com/~lynn/2001i.html#21 3745 and SNI
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#47 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2002b.html#36 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002e.html#67 Blade architectures
http://www.garlic.com/~lynn/2002f.html#1 Blade architectures
http://www.garlic.com/~lynn/2002f.html#17 Blade architectures
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#2 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003h.html#35 UNIX on LINUX on VM/ESA or z/VM
http://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003k.html#10 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#17 Dealing with complexity
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004d.html#72 ibm mainframe or unix
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004m.html#0 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004q.html#10 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2004q.html#70 CAS and LL/SC
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005.html#55 Foreign key in Oracle Sql

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Mon, 11 Apr 2005 21:26:38 -0600

"David Wade" writes:

I think most businesses face this type of dilema at some point or
other in Business. When its time for a major change in paradigm how
do you move forward without loosing too many existing users. IBM
faced it at the time came to replace S/360. They chickened out and
went for S/370 rather than Future Systems. Later when they tried to
move folks from DOS to OS/2 they failed because at the same tim M$
offered an option (Windows/95) with a lower pain threshold...

it wasn't so much chickening out ... but rather a question of
could it be done at all; during the period, I had made references
to the effort akin to a cult film that had been long running
down in central sq ... or the inmates being in charge of the
institution.

one of the nails in the coffin was analysis by houston science center
that if a FS machine was built from the fastest components then
available ... bssically 195 ... then the thruput of existing
applications running on 195 ... would drop to that of about the
thruput of 370/145 (20 to 30 times slower); this was of particular
concern to the high-end transaction customers ... like the "res"
systems and the financial transaction systems.

misc past FS posts
http://www.garlic.com/~lynn/subtopic.html#futuresys

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

Some questions on smart cards (Software licensing using smart cards)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Some questions on smart cards (Software licensing using smart cards)
Newsgroups: alt.technology.smartcards
Date: Tue, 12 Apr 2005 09:00:59 -0600

"Denis Lavrukhin" writes:

I am working on a subject, so I have some questions.

The main requirement is to activate program. User has serial number
and a smart card. We could work with any smart card or maybe with
some of them.

One of the biggest problems from my point of view is to detect is it
smart card or software emulator. Emulator should be detected on
server side and if detected, activation stops.  If no emulator
detected, some data should be securely transmitted (or smart card
unique data) and then program should be able to check for this data
validity.

1. How could I determine is this is a smart card or emulator in
common case (using high level API, such as MS cryptoapi)?  2. If I
will require specific card which support cardlets (for example
javacard based), could it help me to do that?

Please, help me or give me a links to articles which may help me.

basically asymmetric cryptography technology is mapped to a business
process called public key .... where business process defines that one
of a public/private key pair is made public and the other key is kept
private and never divulged.

from 3-factor authentication paradigm

• something you know
• something you have
• something you are

lots of past posts on 3-factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor

a public/private key implementation is a something you have
authenticatione; aka somebody (within the public key business process
definition) has access and use of the specific private key. the
verification of a digital signature with a public key by the receiver
(or relying party) implies that the originator had access and use of
the corresponding private key.

one of the issues is that there has been lots of discussion about
public/private key implementations within the context of PKIs
... where there are certification authorities that certify some amount
of information and generate digital certificates as indication of
their certification. There typically is little discussion about the
integrity of the certification process and lots of discussion of the
integrity of the digital certificates themselves.

The focus on the integrity of the digital certificates frequently
obfuscates issues regarding integrity of the certification process as
well as the integrity of the business implementation related to
keeping the private key really private and never divulged. This can
create some conflict for PKI oriented industries ... where the
fundamental security of the whole infrastructure is based on the
integrity of the private key protection and confidentiality ... while
their business model is based on convincing everybody of the value of
the digital certificates.

The focus on the integrity of the digital certificates tends to take
focus away from the actual certification business process as well as
any business process that prooves the integrity of protection and
confidentiality of the private key.

so one possible mechanism is to provide a certification infrastructure
related to the protection supporting the confidentiality of a private
key ... so an online service that you send it a specific public key
... and the online service sends back an assurance level related to
the protection of the associated private key. If there is no known
assurance level for the protection of a private key that corresponds
to a specific public key ... then assume the poorest possible
assurance.

we actually looked at this quite a bit in connection with AADS
http://www.garlic.com/~lynn/x959.html#aads

in part, since we weren't distracted by the management of digital
certificates, we could concentrate on other aspects of authentication
infrastructures requiring assurance and integrity.

recent thread with lots more description of various strengths
and vulnerabilities related to SSL-oriented digital certificate
infrastructures:
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix</a>
http://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and interoperability-issues sendmail/Exchange/postfix</a>
http://www.garlic.com/~lynn/2005e.html#62 TLS-certificates and interoperability-issues sendmail/Exchange/postfix</a>
http://www.garlic.com/~lynn/2005f.html#9 TLS-certificates and interoperability-issues sendmail/Exchange/postfix</a>

lots of past postings about ssl digital certificate oriented
infrastructures
http://www.garlic.com/~lynn/subpubkey.html#sslcert

There is a separate issue related to what/whether a digital signature
means anything more than simple origin authentication.  Sometimes
there is semantic confusion since "digital signature" contains the
word "signature". This can somehow get confused with the concept of
"human signature".

A "human signature" tends to imply that a person has observed, read,
approved, authorizes, and/or agrees with the contents being digitally
signed. None of this is implied in the fundamental digital signature
operation which is simple something you have authentication.

Some of this was attempted to be addressed by the EU FINREAD standard
http://www.garlic.com/~lynn/subintegrity.html#finread

where a certified environment is defined (a finread terminal) where
there are some processes (imposed by the finread terminal) that may
attempt to assure that some human has actually observed what they
believe to be signing ... and that other steps or processes are
involved.

However, in the basic finread definition ... for any particular
digitally signed message ... there is no more proof that a finread
terminal was involved ... than there is proof about the assurance
level surrounding the protection of a private key (is it contained
within a chip of a particular security level, and never has left that
chip).

One of the possible extensions to the EU finread standard ... is not
only making them a certified environment .... but also providing
them with a private key embedded in their security module ... and the
finread terminal digitally signs all transactions ... in addition
to a private key signing contained in a smart card (or other
hardware token).

There then is an online service that has registered all certified
finread terminals and their corresponding public key. Then there are
transactions with two digital signatures, one from the originator (say
from some sort of hardware token with a registered public key that
includes the assurance level of the associated hardware token) and one
from the certified finread terminal (indicating that certain business
processes were observed as part of the first digital signature
signing).

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers
Date: Tue, 12 Apr 2005 11:49:35 -0600

Steve O'Hara-Smith writes:

400KB or 800KB on the 5 1/4in floppies (860KB on the Lisa
apparently) until IBM decided that the floppy everyone else got
400KB on could only hold 360KB. OTOH 8in floppies could hold 1MB as
long ago as 1975 and ISTR a 2MB format just before they vanished
from the scene.

problem i saw sporadically at the higher densities were
interoperability issues across different floppy drives.

at one time i had an original 64kbyte ibm/pc that i had upgraded with
more memory, 2nd internal floppy drive and two external teak 80track
half-height floppy drives. i no longer have it or any floppy drives
... although i've got possible 100 5-1/4in floppies someplace.

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

System/360; Hardwired vs. Microcoded

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/360; Hardwired vs. Microcoded
Newsgroups: alt.folklore.computers,comp.arch
Date: Tue, 12 Apr 2005 13:48:05 -0600

hancock4 writes:

I'm still confused as to the differences, if any, between the
S/360-195 and the S/370-195.  Could anyone explain the differences
and how many built?  (I think even the S/360 version had monolithic
storage).  I gather that both models evolved out of work for the
S/360-91.

the 370/195 had the "new" (non-virtual memory) 370 instructions (like
insert character under mask, etc).

i was also told the 370/195 had better fault tolerant characteristics
and some retry of soft-errors (compared to 360/195) ... some statistic
that the number of components in the 195 ... the probability of some
kind of soft failures was on the order of daily..

sjr had 195 up thru the late 70s ... and besides the supercomputer
venue some of the large financial houses and airlines had them for
high end transaction processing (financial transaction switching and
airline res system). the eastern airline res system was one of that i
believe ran on 195 (south florida) and was part of the input into
amadeus (my wife served stint as amadeus chief architect for a time).

also related references to the nail in FS (future system) coffin
http://www.garlic.com/~lynn/2005f.html#19 Where should the type information be: in tags and descriptors

i got involved with the 195 group when they were looking at adding
dual i-stream support to 370/195 ... from the software
standpoint it would look like dual-processor operation ... but it was
very akin to the recent processor hardware threading ... aka the
scenario was that most codes weren't able to keep the pipeline full
because most branches causing pipeline stall/drain (mip/thruput
nominally was about half of peak). there was some hope that dual
i-stream support would keep the pipeline full ... and show
aggregate peak thruput.

recent past post in this thread
http://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded

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

the relational model of data objects *and* program objects

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the relational model of data objects *and* program objects
Newsgroups: comp.databases.theory
Date: Tue, 12 Apr 2005 14:48:53 -0600

"erk" writes:

It's not an assertion, it's true by definition (modulo the original
use of relation in mathematics). You can easily say "SQL DBMS" and
be both correct and non-irritating. Given that this is a theory
group, I think definitions are important. Not that they're not
important outside theory...

my impression of the early systemr/sql work at sjr was that it was
very much modeled after bank accounts (and Codd was also at sjr)
.... two dimensional table structure with bank account number as the
primary index and all the related information for each account very
uniform. this was in the time-frame that one of the major people from
IMS had joined a large financial institution ... and was putting
together a larger IMS development group ... than the IMS development
group in STL. there was a lot of focus on creating solutions to basic
financial industry operations & business processes.

the row&column model was quite useful abstraction simplification that
also shows up in the uptake of spreadsheet technology ... and fits
well with the prevalent paper-based orientation of the period.

misc. past system/r postings
http://www.garlic.com/~lynn/subtopic.html#systemr

system/r site
http://www.mcjones.org/System_R/

SQL reunion
http://www.mcjones.org/System_R/SQL_Reunion_95/index.html

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

System/360; Hardwired vs. Microcoded

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/360; Hardwired vs. Microcoded
Newsgroups: alt.folklore.computers,comp.arch
Date: Tue, 12 Apr 2005 17:57:29 -0600

the death of FS also saw the (re-)ascension of marketing, accountants,
and MBAs.
http://www.garlic.com/~lynn/subtopic.html#futuresys

801/risc could be viewed as a swinging to the opposite extreme
... demonstrating with cp.r and pl.8 software technology could
be used to compensate for extremely simple hardware
(lack of features)
http://www.garlic.com/~lynn/subtopic.html#801

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Wed, 13 Apr 2005 08:38:23 -0600

jmfbahciv writes:

There were lots of titles because a few people keep changing
the header to reflect the contents.  This irritates me because
it makes backtracing exteremely difficult to do.

A better suggestion to Edward would be to read Hank's  and mrr's
posts which would keep him from fainting from the shock of
a high post count.

I have a long collection of posts on assurance:
http://www.garlic.com/~lynn/subintegrity.html#assurance

buffer overflows
http://www.garlic.com/~lynn/subintegrity.html#overflow

and fraud, exploits, vulnerabilities
http://www.garlic.com/~lynn/subintegrity.html#fraud

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

the relational model of data objects *and* program objects

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the relational model of data objects *and* program objects
Newsgroups: comp.databases.theory
Date: Wed, 13 Apr 2005 08:45:50 -0600

"erk" writes:

Spreadsheets and even SQL DBMSs are very different beasts, as has been
described over and over again in these pages, and relational is
different yet. If you're placing spreadsheets, relational, and SQL all
in the same category, then there's not much left to discuss, I suppose.

while they may be different beasts ... they originally were targeted
at very similar financial account oriented environments ... possibly
in part because financial operations as early adopters had lots of
money to spend on new stuff ... and there also possibly being some
prospect of ROI ... for the money spent.

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

the relational model of data objects *and* program objects

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the relational model of data objects *and* program objects
Newsgroups: comp.databases.theory
Date: Wed, 13 Apr 2005 08:57:49 -0600

and small quote from previous reference
http://www.mcjones.org/System_R/

System R is a database system built as a research project at IBM San
Jose Research (now IBM Almaden Research Center) in the 1970's. System
R introduced the SQL language and also demonstrated that a relational
system could provide good transaction processing performance.

.... which might be interpreted that it demonstrated a reaonable
paradigm match up between system/r's transaction processing and
financial infrastructure transaction processing.

now it is obvious that system/r transaction processing capability
didn't exist in spreedsheet implementations ... however both basic
information organizations just happened to conform pretty well to
standard paradigm of some (financial) market segments that had money to
spend on new products.

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Wed, 13 Apr 2005 19:23:19 -0600

Peter Flass writes:

My feeling is that it isn't either-or, but few vendors have taken this
line.  I think PCs should have been marketed as super-intelligent
terminals that interacted seamlessly with mainframes.  Users shouldn't
have had to know where applications resided, ran, or got their data
from.  They should have just run.  You could sell timesharing with
gee-whiz editing, graphing programs, or whatever.

can you say SAA (aka system application architecture)?

however, it seemed that a lot of SAA effort was spent on porting PC
implemented applications to backend mainframe ... under the guise of
execution location transparency.

somewhat more capable SAA-related effort was taking UCLA's locus
and releasing it as AIX/370 and AIX/PS2.

we also took some heat from the SAA factions when we were coming
up with 3-tier architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier

since some might accuse the SAA forces of attempting to put the
client/server genia back in the bottle ... and 3-tier architecture was
just aggravating the situation.

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

Where should the type information be?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be?
Newsgroups: alt.folklore.computers
Date: Thu, 14 Apr 2005 08:01:35 -0600

Brian Inglis writes:

Ditto for all three items: slide rule, PDP-11 card, IBM template;
also have: chem lab spatula, TECO 8/10/11 booklet, VAX 11/780 white
booklet, S/370 yellow booklet, various VM cards/booklets; and I've
got one of those IBM double ended crochet hook/slot tools, as a
deinstall souvenir: anyone remember what they were used for?

early on in HSDT
http://www.garlic.com/~lynn/subnetwork.html#hsdt

there was a lot of physical install stuff going on and I needed in
tool set ... so I put in an order for a standard FE tool briefcase.  I
got back a rejection because I wasn't an FE ... I was able to escalate
and finally the order went thru. It has various kinds of stuff
... including various and sundry items for electric typewriter
(selectric, computer terminals, etc) repair (the mechanical part of
the golf ball movement).

it used to sit in my office and over the years ... some number of
pieces have disappeared ... but none of the typewriter stuff.  It is
sitting in my current office.

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Thu, 14 Apr 2005 08:36:40 -0600

Andrew Swallow writes:

When writing the cheques DEC $20k mini computers had a few
additional costs.

Boasting is probably why minicomputer company DEC preferred selling
£30k minis over $1k micros.

Even if you sell a thousand $1k micros they are still $1,000
machines and therefore lacking in prestige.

Externaly IBM considered PCs toys until the micro division had
bigger sales that the mainframe division.

As to why DEC dropped its "mainframes" that was probably just
returning to its roots when under financial pressure.

the entry level market tends to be much more competitive and the
profit margin significantly slimmer. The profit off a thousand $1k
micros is likely to be 1/10th the profit off a million dollar machine
aka they might have to sell 10k (or even $50k) $1k micros to take home
the money that they could get from one $1m machine.

it is one thing to have sales and possibly something completely
different to have profit. I once heard a phrase that went something
like ... they were loosing $5 on every sale ... but they were planning
on making it up in volume.

for a little more topic drift ... some vax volume numbers:
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#5 Blade architectures
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?

one of my assertion was that technology had advanced to the point
where 4341s and vax machines hit a price/point for departmental
computers ... and there was a huge proliferation in that market
segment. however, moving further into the 80s ... you started to see
that market segment erode and be taken up by larger workstations and
PCs (it wasn't so much customers buying lots workstations ... but that
they could replace their 4341/vax with a large workstation).
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#7 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#34 ...killer PC's
http://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers
Date: Thu, 14 Apr 2005 10:18:29 -0600

David Gay writes:

The context was PCs (presumably IBM compatible ones). 160k on the
original single-sided, 8 sectors/track 5 1/4in floppies. Increased to
360k when they went to double sided and 9 sectors/track (I think
there was also a double sided, 8 sectors/track stage, hence
320k). 1.44MB only happened when 3 1/2in floppies showed up.

(internal distribution) dos 1.8 had support for trying to cram 10
sectors per track ... 400k ... and before the AT came out there were
80track drives starting to appear and getting 800k (or 720k with
9sectors/track). I had an original IBM/PC ... that I eventually
attached two external teac 80track drives. all used the same 5.25in
floppies. I have hundred or so floppies in a box someplace with no
drives to read them.

1.2mb high density (5.25in) floppies (and drives) were introduced with
PC/AT In theory the high density drives could also be used to
read/write regular 40track & 80track "regular" floppies (however, i
remember having frequent problems with using normal 40track drive to
read normal 40track floppies that had been written on high-density AT
drive).

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

the relational model of data objects *and* program objects

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the relational model of data objects *and* program objects
Newsgroups: comp.databases.theory
Date: Thu, 14 Apr 2005 13:41:27 -0600

Anne & Lynn Wheeler writes:

and small quote from previous reference
http://www.mcjones.org/System_R/

System R is a database system built as a research project at IBM San
Jose Research (now IBM Almaden Research Center) in the 1970's. System
R introduced the SQL language and also demonstrated that a relational
system could provide good transaction processing performance.

there have been a number things done for practical, implementation
reasons, as opposed to theory and abstraction; there have been more
than a few references to codd believing that SQL compromised his
(codd's) relational model.

a big issue during the evolution of system/r was the battle with the
earlier generation of physical databases ... was the excessive
overhead of the index (it minimized some of the manual administrative
overhead but typically doubled the physical disk storage and increase
real memory and processing overhead). having a single "primary" index
with all the rest of the fields (columns) related to the pimrary index
... normally in the same physical record ... allowed things like bank
account transactions to update an account balance field w/o impacting
the index. carefully constructed model could select a fairly stable
characteristic as the primary index and make all the other fields (in
the same physical record) related to the primary index (and related
updates wouldn't impact index structure).

having single index with large body of information physically
collected under that index also minimized the index overhead on
retrieval. being able to update nearly all of the fields ... resulting
in single physical record write w/o impacting the index ... also
minimized the index overhead.

Mapping financial transactions to database "transactions" (with acid
and commit characteristics) with most stuff in a singled physical
record, resulted in a large class of transaction updates only
involving a single physical record needing to be logged as part of
acid/commit (and with no impact on things like the index, where an
index change might involve a large number of physical records being
changed).

when i did the original prototype DLM for ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

minor related posting
http://www.garlic.com/~lynn/95.html#13

one of the things i worked out was how to do fast commit across a
distributed set of machines (sharing the same disk pool).

a normal fast commit would involve writing the "after image" record
(s) and the commit record to the log. Logs are written sequentially
and for high performance may having either a high-speed sequenctial
I/O device and/or a dedicated disk arm. database transactions however
tend towards (possibly randomly) scattered records all over a set of
disks. ACID/commit require fairly time-ordered activity. Disk arms can
have much higher performance if i/o is order by disk position rather
than time-sequence. fast commit leaves updated record in main memory
cache, sequentially writes the log record ... and does lazy writes of
the ("dirty") cache record to database "home position". The lazy
writes of dirty cache records can be ordered by disk arm location
(rather than transaction time sequence) potentially significantly
improving disk thruput.

At the time, fast commit was crippled for distributed machines.  If
a lock (and record) migrated to a different machine ... there was a
force write of the (dirty cache) record to its database home position
and the "migrated to" machine read the record from disk. This
preserves the simplified transaction record logging and recovery
... somewhat implicit in the original RDBMS implementations.

The DLM prootype work allowed a cache-to-cache copy of the database
record (even dirty records), potentially piggybacked on the same I/O
operation that migrated the specific lock. This avoided having to
force a disk transit (out and back in again). The problem was that
this severely complicated log recovery in case of a failure. In the
single processor case, there could be a whole sequence of (commited)
transactions to the same (dirty) record (none of which have shown up
in the database home location for that record) ... that were all
recorded sequentially in the same physical log. Recovery after a
failure, just requires sequentlly reading the log and updating the
home record locations for each correspond record.

In a distributed fast commit recovery ... multiple different
transactions to the same record may in exist in several different
physical logs (none of which have shown up yet in the home database
location). The recovery process is attempting to recreate an
integrated global sequence from multiple different physical ... when
the typical transaction rate may be much higher than any global clock
resolution (i.e. simple time-stamping of each record in the log may
not be sufficient since it is very expensive to maintain fine-grain
clock syncronization across multiple real machines).

So the approaches written up in the literature tends to involve things
like log versioning or log virtual time (some global increasing value
that allows recreating operation operation sequence from multiple
different physical logs).

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Fri, 15 Apr 2005 08:04:19 -0600

David Dyer-Bennet <dd-b@dd-b.net> writes:

Yes, there's a niche for mainframe computing, definitely.
Generally, for single central systems for database and
transaction-processing networks.  For small to medium companies
that's a super-mini in the old terms, probably a Sun server these
days.  For bigger companies, it's a full-blown mainframe.

DEC might have been able to keep the mainframe lines going, but they
were looking fairly old at the time.  And that's not the market
where going head-to-head with IBM has ever been a big success.

there was a slightly separate issue regarding the "glass house" and
that was managed storage ... backups, disaster/recovery, etc.
... regardless of what kind of processor was accessing the data.

the disk division was seeing lots of data migrating out of the glass
house ... in part because the spigot/access to data in the glass house
was severely constrained. the issue was frequently this data migration
involved some of the highest valued corporate assets ... and if it got
lost while out in the distributed wilds ... it could really be lost.

some past refs:
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2003f.html#27 Ibm's disasters in the 70's
http://www.garlic.com/~lynn/2003j.html#44 Hand cranking telephones
http://www.garlic.com/~lynn/2003m.html#12 Seven of Nine

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: alt.folklore.computers
Date: Fri, 15 Apr 2005 09:00:45 -0600

Jeff Teunissen writes:

[snip]

Mike Cowlishaw

[snip]

slightly related:
http://www.garlic.com/~lynn/2004d.html#17 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004d.html#26 REXX still going strong after 25 years

I'm trying to remember ... this may have been the VMITE that happened
shortly after the first Chucky Cheese opened .... out behind the
Blossom Hill shopping center (in an old, converted supermarket bldg).

For more topic drift, i had done backup/archive system that was
deployed at several installations in the san jose area. Mark had
helped me with "release 2" (and gave a presentation on it at this
vmite). A group was assigned to the effort and it eventually morphed into
Workstation Datasave Facility ... and then later into ADSM; it is now
called TSM (tivoli storage manager) ... misc. postings:
http://www.garlic.com/~lynn/subtopic.html#backup

In any case, Mike is on the agenda .. from somewhere long ago and
far away ...


Date:  01/21/80  18:17:21
From: STLVM2   xxxxxx
To: Distribution

Hi Everyone, This is the semi-final agenda. Please contact me if you
have any questions or concerns. This agenda is only being sent to
those of you who appear in the distribution list. If I over looked
anyone, I hope you find out in time to do something about it!

                  GPD VM/370 Internal Technical Exchange

VM/370 Support
R93/D12
Santa Teresa Laboratory
San Jose, California 95150

VM/370 Internal Technical Exchange

On February 26, 27 and 28, GPD-IS will host a VM/370 Internal Users
Meeting at the San Jose Research facility, building 028, 5600 Cottle
Rd., San Jose, California 95193.  The object of the meeting will be a
technical exc hange of information among IBM locations using VM/370
around the world.  P lease direct any questions about this meeting to
me at xxxxxxxx. If you wi sh to use the internal network, my node is
STLVM2 and my userid is xxxxxxxx.

Please bring your badge or ID card as it will be required for everyone.

The total meeting attendance will be limited to 260 so make your
reservations early!  If you are commimg from the USA you will need to
make own room reservation. If you are comming from outside the USA you
may send an ITPS to xxxxxx, R14/D184, Santa Teresa, AAST and she will
make the requested reservations and send you a conformation ITPS.
Please in clude your ITPS address as part of the original ITPS so
Marge can send your conformation.

I will have all the presentations reproduced and distributed after the
meeting to all attendees unless they request otherwise.  I will have
them ready before the meeting IF I receive them in time.

xxxxxxxx will be our secretary for the meeting this year.  The message
phone number is 8/xxxxxxxx. It will only be available from 1:30 to
3:30 PST.  Any return travel conformations can be made through Marge
at these times.  There will be 2 phones available just outside the
conference room for your use.

The emergency (personal emergency only) phone number is (408)
xxxxxxxx.  DO NOT USE THE EMERGENCY NUMBER FOR BUSINESS MESSAGES!

                  GPD VM/370 Internal Technical Exchange

The following is the agenda for the meeting.

 Tuesday, February 26, 1980:

    9:00 -  W.W.            - VM/370 ITE Kickoff, Mr. W.W. is
                              the President of GPD.

    9:30 -  Ray             - ITE Overview.

    9:45 -  Forrest         - Dynamic Writable Shared Segment Over
                              View.
   10:00 -  Jim             - System R , An Overview.
   10:30 -  Break
   11:00 -  Gene            - Extended Networking.
   11:30 -  Roy             - Network management and load balancing
                              tools.
   12:00 -  Lunch
    1:00 -  Peter           - Network Response monitoning, Remote
                              Dial Support, and VM/370 HyperChannel
                              attachment
    1:20 -  Jeff            - CADCOM - Series/1 to VM/370
                              Inter-program communications.
    1:35 -  Noah            - PVM - Pass Through Virtual Machine
                              Facility.
    2:00 -  Noah            - EDX on Series/1 as a VNET
                              workstation.
    2:15 -  Tom             - Clock - Timer Driven CMS Virtual
                              machine.
    2:30 -  Break
    3:00 -  Vern            - 3540 Diskett Read/Write Support in
                              CMS.
    3:30 -  Bobby           - VM/SP - System Product offering
                              overview and discussion.
    4:30 -  Closing         - from this point on there can be small
                              informal sessions of points of
                              interest.

 Wednesday, February 27, 1980

    9:00 -  Billie          - Common System Plans.
                              modifications and results.
    9:30 -  Claude          - XEDIT Update.
            Nagib
   10:00 -  Graham          - SNATAM - Controlling SNA devices
                              from CMS.
   10:30 -  Break
   11:00 -  Mike Cowlishaw  - REX Executor.
   11:45 -  Mark            - San Jose File Back-up System.
   12:00 -  Lunch
    1:00 -  Albert          - VMBARS - VM/370 Backup and
                              Retrieval System.
    1:45 -  Chris           - 6670 Office System Printer and
            Tom               VM/370
    2:15 -  Break
    2:45 -  Rodger          - VM/370 Based Publication System.
    3:15 -  Dieter          - Photo-composition Support in DCF
    3:30 -  John            - VM Emulator Extensions.
            Dave
    3:40 -  Tom             - DPPG Interavtive Strategy and VM/CMS

    4:30 -  Closing         - From this point on there can be small
                              informal sessions of points of
                              interest.
  * 4:30 -  Editor Authors  - This will be an informal exchange of
                              information on the changes comming
                              and any input from users on edit
                              concepts. All those wishing to express
                              their opinions should attend.

 Thursday, February 28, 1980:

    9:00 -  Ed              - VM/370 Mulit-Drop Support
    9:30 -  Ann             - Individual Password System for VM/370.
   10:00 -  Walt            - Individual Computing based on EM/YMS.
   10:30 -  Break
   11:00 -  Chris           - EM/370 - Extended Machine 370 and
                              EM/YMS Extended Machine Yorktown
                              Monitor System.
   12:00 -  Lunch
    1:00 -  Simon           - Extended CMS Performance Monitoring
                              Facility
    1:30 -  George          - Distributed Processing Maching
                              Controls.
    2:00 -  Mike            - Planned Security Extensions to VM/370
                              at the Cambridge Scientific Center
    2:30 -  Break
    3:00 -  Steve           - Intra Virtual Machine
                              Synchronization Enqueue/Dequeue
                              Mechanisms.
    3:30 -  Jeff            - Boulder F.E. Source Library Control
                              System.
    4:00 -  Ray             - VMITE Closing.

... snip ... top of post, old email index

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Sun, 17 Apr 2005 14:34:16 -0600

rpl writes:

np, "White Plains" I got, "POK" was left field (and Dylan struck some
sort of paisely flashback we won't go into).

I'm not a DECite as such, I have more experience on Big Blue
big/medium iron than VAXen (though I think you're referring to /BAH).

But I'm *not* saying that Big Blue was a contender with their
model-line at that time (mid 80s) for that market; DEC was and
could've (IMHO) grabbed a good portion of any installation 8 < x < 20
terminals[1].

somewhat related
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Mon, 18 Apr 2005 00:10:39 -0600

rpl writes:

I'm surprised at the bang/buck ratio of 4341s vs 303xs (as well as
that *any* 43xxs had MVS), though I have to admit I never fully
understood the target market differences bettwen OS & DOS.

a couple benchmark refs:
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: alt.folklore.computers,comp.arch
Date: Mon, 18 Apr 2005 09:58:20 -0600

"Tom Linden" writes:

I acquired a 751 in early 82 and I think the 730 came out later that year

unfortunately, doesn't give breakdown for years 78-84

from:
http://www.garlic.com/~lynn/2002f.html#0  Computers in Science Fiction

posting of 1988 IDC report .... repeat of portion:

                 VAX SHIPMENTS - WORLD-WIDE
                 --------------------------
             1978-
SYSTEM       1984      1985      1986      1987     TOTAL
--------   --------  --------  --------  --------  --------
11/725       1,100       400         0         0     1,500
11/730       5,550     1,500         0         0     7,050
11/750      16,340     3,900       990       370    21,600
11/780      19,200     3,700       670       370    23,940
11/782         310         0         0         0       310
11/785         300     2,700       850       200     4,050
MVI          2,200       600         0         0     2,800
MVII             0    10,900    25,000    29,000    64,900
82XX             0         0     1,875     2,795     4,670
83XX             0         0       500     1,000     1,500
85XX             0         0       725     1,380     2,105
86XX             0     1,200     1,200     1,200     3,600
8700             0         0       140       530       640
8800             0         0        80       420       500
           --------  --------  --------  --------  --------
TOTAL       45,000    24,900    32,030    37,265   139,195

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

Where should the type information be: in tags and descriptors

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be: in tags and descriptors
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 15 Apr 2005 11:53:50 -0600

Janne Blomqvist writes:

AFAIK Ericsson mainly used a proprietary language called "PLEX" for
the switch code (AXE-10). In the late 80's they embarked upon a next
generation switch project using C++, the infamous AXE-N project. About
8 years and 6 billion SEK later the AXE-N project was cancelled. While
projects obviously fail for a lot of different reasons, in this case a
lot of blame has been attributed to the use of C++ (immaturity of C++
at the time, memory management issues, concurrency issues, fault
tolerance etc. due to the lack of language support for these
features). After AXE-N tanked they essentially restarted the project
using another language, Erlang, which eventually resulted in the AXD
switch which is what they peddle these days, if I'm not mistaken.

long ago we did a one week jad on taligent about what would it take to
upgrade it for business critical data processing (upgrade it with
facilities to make it useful for business critical data processing).
first cut estimate was about a 30 percent hit to their current base
and about 1/3rd increase in new frameworks (specifically for business
critical data processing).

as it happened, there were some "nextstep" people around during that
period ... claiming that you could get just about everything needed
for lots of business critical dataprocessing from nextstep.

random past taligent posts
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2000e.html#48 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2000.html#10 Taligent
http://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002i.html#60 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002j.html#76 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002m.html#60 The next big things that weren't
http://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003e.html#28 A Speculative question
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Fri, 15 Apr 2005 17:18:27 -0600

at least one new buffer overflow article or book a week
http://www.linuxsecurity.com/content/view/118881/49/

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

OTP (One-Time Pad Generator Program) and MD5 signature

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OTP (One-Time Pad Generator Program) and MD5 signature
Newsgroups: comp.security.firewalls,comp.security.misc,comp.security.unix
Date: Mon, 18 Apr 2005 10:06:13 -0600

Harald Hanche-Olsen writes:

Almost: You send 'choginzx', the server computes the MD5 signature,
and checks it against the next MD5 signature in its file.  If they
match, it lets you in.  It also marks that signature as having been
used, so it cannot be used again to gain access.

(I'm confused by your use of the word recipient, though: This is for
access control, not for sending and receiving encrypted messages.)

misc. discussions of one-time-password & associated internet standard
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?

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

Moving assembler programs above the line

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moving assembler programs above the line
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 18 Apr 2005 17:06:04 -0600

edgould@ibm-main.lst (Ed Gould) writes:

Bruce,

That was a good story, thanks for sharing.

My favorite was a "timing" issue a field was being updated between
two instructions. Our SE suggested a CS (compare and swap) and it
worked like a champ. The problem didn't happen on SVS (or MVT for
that matter).

Nice having to debug a vendors code.

Test&Set atomic instruction was available on 360 ... basically for
multiprocessor locking/syncronization ... 360/65 MPs and 360/67 MPs.

360/67 was the only 360 with virtual memory support ... very similar
to what was later introduced in 370. 370/67 also had both 24-bit and
32-bit virtual addressing modes (32bit was dropped in 370, however
31bit addressing was later introduced with 370/xa on 3081s).

360/67 multiprocessing was announced with up to 4-way and a box called
a channel director .... which allowed all processors to address all
channels. I don't know of any 4-way machines that were build and I'm
only away of a single 3-way machine was built ... the rest were 2-way
SMPs.

The 360/67 "channel director" had a bunch of switch settings that
could partition the configuration, associate various components in
subset configurations, etc. The values of the switch settings were
available in half-dozen or so control registers (used these days for
access registers). The one 3-way SMP channel director also had a
feature that it was possible to reset the channel director switch
settings by loading values into the control registers.

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

charlie was doing a lot of work on fine-grain locking and
serialization (with cp67 and 360/67 smp) and invented a new
instruction ... which was given a mnemonic of his initials, CAS. Then
we had to come up with a name for the new instruction that matched his
initials ...  and compare&swap was born ... various smp and
compare&swap posts