List of Archived Posts

2005 Newsgroup Postings (08/31 - 09/18)

Article: The True Value of Mainframe Security

Intel engineer discusses their dual-core design

Innovative password security

What ever happened to Tandem and NonStop OS ?

What ever happened to Tandem and NonStop OS ?

What ever happened to Tandem and NonStop OS ?

Innovative password security

What ever happened to Tandem and NonStop OS ?

EBCDIC to 6-bit and back

EBCDIC to 6-bit and back

What ever happened to Tandem and NonStop OS ?

What ever happened to Tandem and NonStop OS ?

Is there any RFC for telnet proxy?

One more about SYRES Sharing

Multicores

DUMP Datasets and SMS

DUMP Datasets and SMS

DUMP Datasets and SMS

address space

address space

address space

Multicores

Multicores

What ever happened to Tandem and NonStop OS ?

Hi-tech no panacea for ID theft woes

Hi-tech no panacea for ID theft woes

What ever happened to Tandem and NonStop OS ?

What ever happened to Tandem and NonStop OS ?

Canon Cat for Sale

Documentation for the New Instructions for the z9 Processor

What ever happened to Tandem and NonStop OS ?

z/VM performance

PKI Certificate question

Digital Singatures question

What is CRJE

PKI

PKI

CRJE and CRBE

storage key question

What ever happened to Tandem and NonStop OS ?

how password is stored and check the authentication??

how password is stored and check the authentication??

VMFPLC2 to load EREP PTFs

Security of Secret Algorithm encruption

hasp, jes, rasp, aspen, gold

HASP/ASP JES/JES2/JES3

Article: The True Value of Mainframe Security

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Article: The True Value of Mainframe Security
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Wed, 31 Aug 2005 18:34:29 -0600

"Shmuel Metz (Seymour J.)" <shmuel+ibm-main@PATRIOT.NET> writes:

IBM had RSS and General HoneyBULL had Multics.

multics was on the 5th floor of 545 tech sq.
http://www.multicians.org/

cp67 and misc. other stuff
http://www.garlic.com/~lynn/2004o.html#38 SHARE reflections

was done by the science center on the 4th floor of 545 tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech

as part of cp67 morphing into vm370 ... the group absorbed the boston
programming center on the 3rd floor (545 tech sq). eventually vm370
outgrew the 3rd floor and moved out to the old sbc building in
burlington mall (this was after sbc had been sold off as part of some
settlement).

the science center machine room was on the 2nd floor.

refs:
http://www.garlic.com/~lynn/2005o.html#45 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005o.html#47 Article: The True Value of Mainframe Security

and anothor ref
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

from
http://www.garlic.com/~lynn/2005k.html#30</a> Public disclosure of discovered vulnerabilities
http://www.garlic.com/~lynn/2005k.html#35</a> Determining processor status without IPIs

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

Intel engineer discusses their dual-core design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel engineer discusses their dual-core design
Newsgroups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch,alt.folklore.computers
Date: Wed, 31 Aug 2005 19:53:56 -0600

keith writes:

Wasn't the 3033 a 3168 on steriods?  ...complete with dual I-streams?

303x machines were organized to use the 303x channel director.

the 370/158 had integrated channels ... i.e. the 158 engine was
shared between the microcode that executed 370 instructions and
the microcode that executed channel (I/O) programs.

for the 303x channel director they took the 370/158 and removed
the microcode that executed 370 instructions leaving just
the channel execution microcode.

a 3031 was a 370/158 remapped to use a channel director box
i.e. a 3031 was a 370/158 that had the channel program microcode
removed ... leaving the engine dedicated to executing the
370 instruction microcode.

in some sense a single processor 3031 was a two 158-engine smp system
... but with one of the 158 engines dedicated to running 370
instruction microcode and the other processor dedicated to running the
channel program microcode.

a 3032 was a 370/168 modified to use the 303x channel director.

a 3033 started out being a 370/168 wiring diagram remapped to new chip
technology. the 168 chip technology was 4 circuits per chip. the 3033
chip technology was about 20% faster but had about ten times as many
circuits per chip. the initial straight wiring remap would have
resulted in the 3033 being about 20% faster than 168-3 (using only 4
cicuits/chip). somewhere in the cycle, there was a decision to
redesign critical sections of the machine to better utilize the higher
circuit density ... which eventually resulted in the 3033 being about
50% faster than the 168-3.

basic 3033 was single processor (modulo having up to three 303x
channel directors for 16 channels). you could get two-processor
(real) 3033 smp systems (not dual i-stream).

there was some internal issues with the 3031 being in competition with
4341 ... with the 4341 being significantly better price/performance.
A cluster of six 4341s also were cheaper than a 3033 also with much
better price/performance and higher aggregate thruput. Each 4341 could
have 16mbytes of real storage and 6channels for an aggregate of
96mbytes of real storage and 36 i/o channels. A single processor 3033
was still limited to 16 i/o channels and 16mbytes.

somewhat in recognition of the real stroage constraint on 3033 thruput
... a hack was done to support 32mbytes of real storage even tho the
machines had only 16mbyte addressing. A standard page table entry had
16bits, 12bit page number (with 4k pages giving 24bit real storage
addrssing), 2 defined bits, and two undefined bits. The undefined bits
were remapped on the 3033 to be used in specifying real page
numbers. That allowed up to 14bit page number ... with 4k pages giving
up to 26bit real storage addressing (64mbytes). channel program idals
had been introduced with 370 ... allowing for up to 31bit real storage
addressing (even tho only 24bits were used). This allowed the
operating system to do page I/O into and out of storage above the
16mbyte line.

around the same time that the product test lab (bldg. 15) got their
3033, they also got a brand new engineering 4341 (for the same purpose
doing channel disk i/o testing). we could co-op the 4341 in much
the same way that the 3033 was co-op'ed. In fact, for a period of
time, I had better access to the 4341 for running tests than 4341
product people in endicott did; as a result I got asked to run some
number of benchmarks on the bldg. 15 4341 for the endicott 4341
product people. minor past 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/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
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/2002i.html#22 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof

some number of past posts on 303x channel director:
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/97.html#20 Why Mainframes?
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/2000c.html#69 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#21 S/360 development burnout?
http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000.html#78 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/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002p.html#59 AMP  vs  SMP
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003g.html#32 One Processor is bad?
http://www.garlic.com/~lynn/2003.html#39 Flex Question
http://www.garlic.com/~lynn/2004d.html#12 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004d.html#65 System/360 40 years old today
http://www.garlic.com/~lynn/2004e.html#51 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's
http://www.garlic.com/~lynn/2004.html#9 Dyadic
http://www.garlic.com/~lynn/2004.html#10 Dyadic
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
http://www.garlic.com/~lynn/2004n.html#14 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#26 CAS and LL/SC
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005h.html#40 Software for IBM 360/30
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof

in the late 70s and early 80s, 4341 competed with and sold into the
same market segment as vax machines
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
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/2000d.html#9 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#3 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2003c.html#17 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#19 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#0 big buys was: Tubes in IBM 1620?
http://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#61 Another light on the map going out
http://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix
http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004.html#46 DE-skilling was Re: ServerPak Install via QuickLoad Product
http://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Re: Vintage computers are better
http://www.garlic.com/~lynn/2004l.html#10 Complex Instructions
http://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004m.html#63 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#71 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005f.html#30 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005m.html#8 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#10 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#12 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#16 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?

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

Innovative password security

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Innovative password security
Newsgroups: alt.computer.security
Date: Thu, 01 Sep 2005 15:50:37 -0600

nunodonato writes:

sorry to disagree but i prefer the master password. remembering ONE
password is not hard, even if it has to be a bit more complicated than
the usual.

biometric scans are very secure, thats for sure, but its no so
pratical.. and you need another device for that. what happens when you
go to a place where it is not available?

the issues are what are the treats and the countermeasures.

biometric information can be left around all over the place ...  and
once compromised it can be a lot more difficult to re-issue a thumb
than it is to replace a compromised password (although there
have been a couple recent news items attempting to address
compromised biometrics).

frequently, access passwords tend to be shared-secrets .... they tend
to be exposed in a lot more different places ... it is one of the
reasons for security recommendations that there has to be a unique
shared-secret for every unique security environment.  This in turn
leads to people having several scores of different (shared-secret)
passwords that result in the difficult (human) memory problem 2and in
turn results the (shared-secret) password management problems.
http://www.garlic.com/~lynn/subintegrity.html#secret

The master password scenario tends to be simply a secret ... as
opposed to a shared-secret ... which tends to imply that there are a
much fewer places where they are exposed and may be subject to
compromise.

The basic model tends to be that there is some sort of container for
the authentication material ... either a software/file container
... or a separate hardware token container.

The (master) password tends to be a countermeasure for a lost/stolen
"container" (whether it is a real physical container or purely
software container).

At a 100k foot level ... it is two-factor authentication:

• container (hardware or software), something you have
• (secret only, not shared-secret) password, something you know

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

multi-factor authenticatin carries with it the implication that the
different authentication factors are subject to different kinds of
vulnerability and threats (for instance something you are biometric
value and a something you know password value transmitted in the
same communication may be subject to a common evesdropping
vulnerability and replay attack ... negating the benefit of
having multi-factor authentication).

the overall integrity can be related to how easy it is to steal the
container, whether the owner realizes the container has been stolen
(physical or software copy), and how hard it is to crack the (master)
pin/password.

a separate hardware container may be harder to steal than a software
file resident on an extremely vulnerable internet connected
PC. Vulnerable, internet connected PC may also be subject to
keyloggers (capturing the master password) and sniffing (capturing the
actual shared-secret passwords as they are being used).

So compare various threat models to hardware token with private key
and infrastructures that replace shared-secret password registration
with registration of public keys ... and digital signature
verification in lieu of password checking.

Requiring unique shared-secret registration for every unique security
domain is because the shared-secret is used for both authentication as
well as origination (i.e. knowing the shared-secret can be sufficient
for impersonation). A public key can only be used for authentication,
but not for impersonation ... so the same public key can be registered
in a large number of different places w/o increasing the threat of
impersonation (that can happen if the same shared-secret is repeatedly
used).

Correctly implemented digital signature protocols result in a unique
value for every authentication, eliminating threat of evesdropping and
replay attacks for impersonation.

A real hardware token tends to eliminate electronic, software theft
(which can happen with emulated software containers).

So a hardware token tends to require physical stealing the object.

For this situation, pin/password (required for token operation) is a
countermeasure for physical lost/stolen token ... as long as the
pin/password hasn't been written on the token.

A hardware token with a built in fingerprint sensor ... might leave
around a latent print on the sensor ... so if the token is stolen
.. the thief may be able to lift the latent print and spoof the
sensor. Some organizations are featuring "line sensor" (where you have
to drag you finger across the sensor) as a security enhancement
(compared to full finger sensors where a latent print may be left
around).

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Thu, 01 Sep 2005 19:55:40 -0600

scott@slp53.sl.home (Scott Lurndal) writes:

Actually, capacity planning courses of the day (do they still have
them?)  would usually [t][pr]each that there was a knee in the
throughput/utilization curve somewhere around 65-70%.  Higher
utilizations would led to less optimal throughput.  IIRC.

depending on the system structure. much of the performance
modeling and workload profiling that was pioneered at the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

is what eventually evolved into capacity planning
http://www.garlic.com/~lynn/submain.html#bench

we got cp67 (and then vm370) tuned to the point ... a lot of it was the
rewrites i had done for i/o subsystem, paging, replacement algorithms,
dispatching, and scheduling ..
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/submain.html#adcon
http://www.garlic.com/~lynn/submain.html#mmap

where it was common to have systems with mix-mode workloads operating
at 100 percent cpu utilization and essentially immediate interactive
response.

systems that have difficulty doing dynamic resource allocation well
... have problems handling instantaneous service requests. A lot of
real-world environments can be very bursty types of activity. if you
have difficulty doing dynamic resource allocation well ... the only
method of handling bursty activity is operating with significant
amount of spare headroom.

it helps being able to do well balanced system configuration ... not
only system structures and opertaion ... but also decent job of balanced
hardware configuration.

note however this aspect can be constantly changing based on
combination of workload and advances in hardware. dynamic adaptive
resource managerment can be interesting across a wide range of
workloads and hardware configurations. part of this may sometimes
covered as gradeful degradation under stress conditions.

for instance the following theme is about typical hardware
configurations where cpu and real storage resources increases by a
factor of 50 times ... but disk thruput only increased by a factor of
5 times (relative system disk thruput decreased by an order of
magnitude in the period). as more and more systems became primarily
disk bottleneck rather than processor bottleneck (over this period),
optimizing disk I/O (including caching) became more and more
important.
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Do or
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005n.html#29 Data communications over telegraph circuits

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Fri, 02 Sep 2005 11:11:25 -0600

scott@slp53.sl.home (Scott Lurndal) writes:

Actually, capacity planning courses of the day (do they still have
them?)  would usually [t][pr]each that there was a knee in the
throughput/utilization curve somewhere around 65-70%.  Higher
utilizations would led to less optimal throughput.  IIRC.

re:
http://www.garlic.com/~lynn/2005p.html#3 What ever happened to Tandem and NonStop OS ?

however there various kinds of other complex systems that experience
non-graceful degradation operating near saturation.

air traffic and chicago airport
http://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?

railroad operation in texas
http://www.garlic.com/~lynn/2005o.html#29 Penn Central RR computer system failure?

countermeasures needed for traffic gridlock in donwtown areas.

I've also claimed that as little as one percent or less feral drivers
results in the difference between free flowing heavy traffic and stop
and go. these are drivers that make frequent rapid lane changes, also
attempt to cross all lanes in close vacinity to exits and
entrances. some interstate highway sections are being designed with
feral driver countermeasures; I270 north of DC beltway has physical
barrier between thru-lanes and local access lanes (with off/on ramps),
i5 north of seattle, etc.

that still leaves feral drivers frequent, rapid lane changes on the
thru-lanes ... single incidence can result in cascading braking
involving hundreds vehicles ... and precipitate transition from heavy
free flowing traffic to stop&go. one might be tempted to wonder that
if driving privileges on interstates were revoked for feral drivers,
whether you might see 5-10 percent gasoline conservation savings.

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Fri, 02 Sep 2005 14:20:47 -0600

echomko_at_@polaris.umuc.edu (Eric Chomko) writes:

Do you have marketing numbers to back that up? Exactly what did DEC make
microprocessor-wise that turned them any sort of profit from 1980 to 1992?

1988 idc report on vax 1978-1987, sliced and diced by us/non-us, model,
year, etc.
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
http://www.garlic.com/~lynn/2005f.html#37 Where should the type information be: in tags and descriptors

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

Innovative password security

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Innovative password security
Newsgroups: alt.computer.security
Date: Fri, 02 Sep 2005 19:30:05 -0600

"Hairy One Kenobi" <abuse@[127.0.0.1]> writes:

Nice post.

The big argument between SSO (as the subject has called for at least
seven years) and non-SSO has always been that loss of a single
credential exposes everything, vs. username couplets stuck on
Post-Its all over the place (been there, etc.)

Shame that we no longer have the option for *two* independent
passwords (possibly one of HP/Compaq/DEC's patents). That was a
useful compromise (as well as allowing the requirement for *two*
people to authorise a privileged login)

But. The only way it ever works with any degree of safety is to not
have the store on the (vulnerable) local machine.

And that brings the issue of a juicy target that you - as the user -
has to trust absolutely. Excellent for corporations, not so hot for
individuals, IMHO.

re:
http://www.garlic.com/~lynn/2005p.html#2 Innovative password security

a person-centric token ... say with digital signature verification as
the mechanism for implying something you have authentication
(i.e. hardware token that calculates key pair and never exposes the
private key) ... then the person can determine how many tokens and/or
how many environments used with each token.

an institution might be concerned about the integrity of the token
... but using a single token with multiple institutions doesn't impact
any specific institution. using a single token for multiple
institutions or unique token per institution ... is a person-centric
consideration (modulo the integrity level of the token).

however if a person tends to carry all tokens on the same ring ...
then whether they are carrying a single token or multiple tokens on
that ring has little impact on the lost/stolen threat scenario
... they will all tend to be lost/stolen at the same time.

the objective of multiple tokens is if they have independent threats
... if they are subject to a common threat then the advantage of
multiple tokens is lost.

there is a similar argument about multiple credit cards as
countermeasure for lost/stolen threat ... which is negated if they are
all carried in the same wallet ... since the lost/stolen scenario
tends to be the whole wallet ... not individual contents.

so if you really want to get fancy ... some topic drift to
security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

one of the other countermeasures to lost/stolen in an online
environment is the person recognizing that there has been a
lost/stolen compromise and reporting it (limiting the scope/duration
of the compromise).  many of the PC/software and pure password based
infrastructures can suffer a lost/stolen compromise w/o the person
recognizing it has happened.

in any case, in a person-centric scenario ... a person wishing
to have multiple tokens ... should recognize that they would be
using multiple tokens instead of single token as a
countermeasure to common lost/stolen threat scenario ... which
means that the person needs to be prepared to keep the different
tokens physically separate.

some past posts on person-centric models
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb?>?
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sat, 03 Sep 2005 09:43:11 -0600

Larry Elmore writes:

Personally, I'd love to have some kind of directional EMP "gun" to zap
the electrical systems of some of these feral drivers' cars.  BTW, I
love that term -- much politer than what I usually call them, and more
descriptive to boot.

note that feral drivers rapid lane change and the resulting cascading
breaking can not only force transition from heavy flow to stop&go
... but also tends to create this accordion effect.  The cascading
braking accordion effect is one of the scenarios that is heavy
contributor to rear-end collisions.

there is this interesting intermediate heavy traffic flow ...  where
the traffic isn't quite heavy enuf to make permanent transition to
stop&go ... but the accordion effect brings some area of the traffic
to a stop ... and then it opens up again ... until the next rapid lane
change resulting in cascading braking and repeat of the accordion
effect. It is the heaviest part of the accordion effect where traffic
(momentarily) comes to a stop that there is highest probability of
rear-end collision.

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

EBCDIC to 6-bit and back

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EBCDIC to 6-bit and back
Newsgroups: bit.listserv.vmesa-l
Date: Sat, 03 Sep 2005 10:37:21 -0600

Alan Ackerman writes:

Maybe this will help?

From: <http://everything2.org/index.pl?node=ALC>

ALC
(thing) by Mit Wahsmircs (2.3 y) (print)

?

Thu Mar 22 2001 at 12:44:24

Airlines Link Control - a primitive data communications protocol,
devised by SITA, and therefore peculiar to the airline industry. It
works by having a central hub poll outlying "interchanges" (cluster
controllers). ALC is a 5 bit code, thus limiting the character set
to the basic alphanumerics (no lower case here!), and a handful of
punctuation marks. There is no error correction, merely a
rudimentary error detection. If a transmission error is detected,
REENTER (or in more minimalist implementations RENT) is displayed on
the terminal, and the user is expected to re-input the failed
command. If the link fails altogether UNAVBL is displayed - the user
then waits until some long-suffering techie restores service (AVBL).
In spite of its age and deficiencies, ALC is still quite widely
used, as it is simple and it works. There is also a large amount of
cheap, pre-owned terminal equipment available. Nowadays, one can
expect to find ALC encapsulated in a marginally less archaic
protocol (X.25, for example).

... snip ...

there are a couple other issues here. in the 70s, in conjunction with
Moldow, my wife produced AWP39 which was a peer-to-peer networking
architecture ... which casued a lot of heartburn from the SNA
crowd. This was before she was con'ed into going to POK to be in
charge of loosely-coupled architecture. A couple past posts mentioning
AWP39:
http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
http://www.garlic.com/~lynn/2004p.html#31 IBM 3705 and UC.5

during her stint in pok, she produced peer-coupled shared data
architecture
http://www.garlic.com/~lynn/submain.html#shareddata

Part of issue is that SNA is a misnomer ... not even having a
networking layer ... it primarily is a centralized telecommunication
structure. The first appearance of network layer was in APPN ... which
SNA group non-concurred with even announcing. After 6-8 weeks
escalation, the APPN announcement letter was rewritten to remove any
implication that APPN and SNA might be related. We actually had some
number of friendly arguments with the chief APPN architecture on why
didn't he come work on a modern networking infrastructure.

My wife later did a stint as chief architect of amadeus (the other res
system). One of the areas of contention was whether it would be x.25
based or sna based. My wife came down on the side of x.25 ... which
led to a lot of lobbying to have her replaced ... which happened
shortly later. It turned out that it didn't do any good since amadeus
went x.25 anyway.

recent, random amadeus reference:
http://www.btnmag.com/businesstravelnews/headlines/article_display.jsp?vnu_content_id=1001015510 Star Alliance Cites 'Firm Commitments' For Amadeus IT

my wife also co-authered and presented corporate response to large fed
gov. bid ... where she layed out the foundation for 3-tier
architecture. We took that work and expanded on it during the SAA
period ... which somewhat can be construed as the SNA crowd attempting
to put the client/server genie back into the bottle ... i.e.  return
to the days of terminal emulation
http://www.garlic.com/~lynn/subtopic.html#emulation

going around making customer executive presentation on 3-tier
architecture and middle layer during this period tended to cause a lot
of pushback from the SNA/SAA people
http://www.garlic.com/~lynn/subnetwork.html#3tier

for some other topic drift and folklore. as undergraudate ... I had
added ascii/tty terminal support to cp67. I had tried to do some
tricks with 2702 telecommunication controller ... which almost, but
didn't actually work. this led to a univ. project that reversed
engineered the ibm channel interface and built our own channel board
for a minicomputer and programmed the minicomputer to emulate ibm
controller.  somewhere there is this article that blames four of us
for precipitating the oem, plug-compatible controller business.
http://www.garlic.com/~lynn/subtopic.html#360pcm

the plug-compatible controller business has been blamed for contributing
to FS
http://www.garlic.com/~lynn/submain.html#futuresys

specific reference
http://www.ecole.org/Crisis_and_change_1995_1.htm

and quote from above:

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

... snip ...

there has been numerous claims that many SNA characteristics were
result of the above strategy.

there is a FS & res. system tiein. The folklore is that one of the
final nails in the FS coffin was study by the Houston Science Center.
The FS hardware architecture was extremely complex ... and Houston did
some modeling that if you moved the Eastern 370/195-based res system
(one of the precursors to amadeus) to FS ... and the FS machine used
the same level of hardware technology as the 195, it would have the
thruput of ACP running on a 370/145 (the complexity of the hardware
could result in something like 30:1 thruput degradation).

... for even more drift ... some years ago, we got the opportunity to
rewrite pieces of major res. systems. one that we completely rewrote
from scratch was routes. a couple past posts:
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2003o.html#17 Rationale for Supercomputers
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
http://www.garlic.com/~lynn/2005k.html#37 The 8008 (was: Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELYwith slide rules)
http://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?

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

EBCDIC to 6-bit and back

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EBCDIC to 6-bit and back
Newsgroups: bit.listserv.vmesa-l
Date: Sat, 03 Sep 2005 10:56:11 -0600

Anne & Lynn Wheeler writes:

Part of issue is that SNA is a misnomer ... not even having a
networking layer ... it primarily is a centralized telecommunication
structure. The first appearance of network layer was in APPC ... which
SNA group non-concurred with even announcing. After 6-8 weeks
escalation, the APPC announcement letter was rewritten to remove any
implication that APPC and SNA might be related. We actually had some
number of friendly arguments with the chief APPC architecture on why
didn't he come work on a modern networking infrastructure.

oops, sorry, slight brain/finger check ... that is APPN not APPC.

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 04 Sep 2005 09:24:46 -0600

Peter Flass writes:

People follow too close; the more the driver in front of me rides
his/her brakes, the farther I drop back.  I seldome have to use my
brakes at all.  Of course when traffic is heavy, the more room you
leave the more people cut in.  To bring this back to computing, it
would be interesting to run traffic simulations making different
assumptions about driver behavior.

there was an article on such work within the past six months ...
but I can't seem to find it now. quick search engine use doesn't
find it ... although it turns up lots of articles on modeling
driver and traffic behavior.

this is recent article that slightly touches on the subject
http://www.theoaklandpress.com/stories/090305/opi_200509030016.shtml

it sort of uses aggresive driving in lieu of my feral driver label
... although disregard for others can be somewhat related to
undomesticated.

my observation wasn't on the behavior of the vast majority of the
drivers ... but that takes only a couple drivers engaging in rapid
lane changing to precipitate transition from heavy flow to stop&go.

another recent article (that i wasn't looking for) that slightly
touches on the following too closely
http://communitydispatch.com/artman/publish/article_1772.shtml

part of it is having spent a large amount of time on dynamic resource
management, congestion control, and graceful degradation ... complex
systems that fail in this respect have some interest.
http://www.garlic.com/~lynn/subtopic.html#fairshare

when we were running high-speed backbone ... and not allowed to bid on
nsfnet backbone (could be considered the operational transition to
modern internet ... as opposed to technology). However, did talk nsf
into audit of what we had running ... which resulted in the
observation that what we had already running was at least five years
ahead of all nsfnet bid submissions to build something new. however I
had implemented some congestion control stuff ... that something
similar will appear in internet2 (so there is some claim that it is
going to be closer to 20 years than 5 years).

similar past comments on the subject
http://www.garlic.com/~lynn/internet.htm#0
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2003d.html#59 unix
http://www.garlic.com/~lynn/2003g.html#36 netscape firebird contraversy
http://www.garlic.com/~lynn/2004l.html#5 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004m.html#62 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2004q.html#58 CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)
http://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#10 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 04 Sep 2005 12:02:46 -0600

ref:
http://www.garlic.com/~lynn/2005p.html#3 What ever happened to Tandem and NonStop OS?
http://www.garlic.com/~lynn/2005p.html#4 What ever happened to Tandem and NonStop OS?
http://www.garlic.com/~lynn/2005p.html#7 What ever happened to Tandem and NonStop OS?
http://www.garlic.com/~lynn/2005p.html#10 What ever happened to Tandem and NonStop OS?

at a more philosophical level ... there is relationship between
graceful degradation, failure resistance, systemic failures of
complex systems, etc.

graceful degradation, failure resistance, and any resiliancy in
complex systems can  be

1) lots of redundant resources. an issue in a culture focused on next
quarterly report, there has been a tendency to optimize away all
redundant resources (cutting costs, improving profit) ... little
planning for the 50year and 100year events.

2) extremely agile operaton. this can be viewed from the perspective of
Boyd's OODA-loops
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

where resources can be quickly reallocated to the biggest problem or
bottleneck. this of course implies that people have fundamental
understanding of the reasons for why things work they way they do and
have accurate observations. in boyd's OODA-loop ... aka
observe, orient, decide, and act .... the faster that you can iterate
the OODA-loop, the more effective the actions.  orient
implies that you can place observations in context and understand
them. some number of people may believe that they have an highly
efficient OODA-loop ... mistakenly believing that they
understand what is going on ... but actually it may be a very static
environment and they are just performing their operations by rote. It
is when things are constantly changing ... that the real test occurs
whether people really can observe, orient (understand), decide
and act.

when we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

some number of the systems were fast restart/recover/take-over. we
also coined the term disaster survivability and geographic
survivability to differentiate from disaster recovery.
http://www.garlic.com/~lynn/submain.html#available

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

Is there any RFC for telnet proxy?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is there any RFC for telnet proxy?
Newsgroups: comp.security.firewalls
Date: Mon, 05 Sep 2005 10:23:13 -0600

xiebopublic writes:

Thank you very much for your advice. I've tried the search engine of
www.rfc-editor.org, and it has no any result for "telnet proxy" or
"telnet gateway". I also have tried google, but not result too. That's
why I post it here.

one pointed to by
http://www.rfc-editor.org/repositories.html

not specifically search
http://www.garlic.com/~lynn/rfcietff.htm

but categorization (organized by keywords found in titles and
abstracts) ... click on Term (term>RFC#) in RFCs listed by section
...  and find/move down to "proxy"

proxy
  see also firewall
 3820 3666 3665 3620 3603 3527 3487 3413 3361 3319 3313 3261 3238
 3143 3135 3040 2844 2843 2607 2577 2573 2543 2322 2273 2263 2186
 1919

clicking on the RFC number, brings up the RFC summary in the lower
frame. clicking on the ".txt=nnn" field retrieves the actual
RFC.

proxies started out being stub applications that did application-level
sanity checking of incoming requests (aka you actually had an
application that listened on the socket ... accepted the tcp
connection ... did minimal processing and then created a new tcp
connection to the "real" application, forwaring the information). much
of the early checking was trying to catch things like buffer overflow
exploits
http://www.garlic.com/~lynn/subintegrity.html#overflow

for instance

1919 I
  Classical versus Transparent IP Proxies, Chatel M., 1996/03/28
  (35pp) (.txt=87374) (Refs 959, 1383, 1597)

in contrast, early firewalls started out doing various kind of
checking & filtering below the application level.

early on, you also had (port) wrappers ... possibly running on same
machine (rather than boundary machine). the wrappers might provide
things like different authentication checking (aka rather than have
straight telnet userid/password ... front-end providing more
sophisticated authentication processes ... before directly contacting
telnet). i don't have keyword entry for wrappers.

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

One more about SYRES Sharing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One more about SYRES Sharing
Newsgroups: bit.listserv.ibm-main
Date: Mon, 05 Sep 2005 10:34:22 -0600

Terry Sambrooks writes:

Hi,

I have been following the dialogue about sharing SYSRES both within
and across SYSPLEX, and I have an old fashioned concern.

Whilst accepting the technical feasibility, the issue I have is with
the concept of introducing a potential single point of failure into
an environment which may have reliability as one of its principal
aims. The concept of disk mirroring and duplexing within modern DASD
systems is fine, but if human error introduces a fault the
consequences can be just a tad embarrassing.

starting in the early 80s, some study found that software & people
errors were starting to dominate failure (rather than hardware
failures).

single sysres in combination with change-control staging between test,
current, and previous volumes ... would be used to address primary
(non-hardware) failure modes. various dasd hardware redundancy
techniques can be used to address residual hardware failure issues.

the issue is whether any human resources are spent managing
correctness of independent, but nearly identical sysres ... or
automating much of that process and devoting the human resources to
managing a single, common change process.

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

Multicores

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multicores
Newsgroups: comp.arch
Date: Tue, 06 Sep 2005 10:18:46 -0600

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:

To avoid context switching, you don't need to have another whole
core.  Just use register renaming, and have a multi-threaded CPU.

First, make the fastest possible single core you can.

Then, make it multithreaded, so that the only context switches you
have are the unavoidable ones due to procedure calls.

Then, if you still have die area, add cores.

that was sort of the 370/195 dual i-stream proposal from the early
70s. the issue was that most codes kept the pipeline only about
half-full. having dual instruction counters and dual registers
... with pipeline tagging registers and i-stream had a change of
maintaining close to aggregate, peak thruput of the pipeline.

amdahl in the early 80s ... had another variation on that.

running straight virtual machine hypervisor ... resulted in context
switch on privilege instructions and i/o interrupts (between the
virtual machine and the virtual machine hypervisor), including saving
registers, other state, etc (and then restoring).

starting with virtual machine assist on the 370/158 and continuing
with ECPS on the 138/148 to the LPAR support on modern machines ...
more and more of the virtual machine hypervisor was being implemented
in the microcode of the real machine ... aka the real machine
instruction implementation (for some instructions) would recognize
whether it was in real machine state or virtual machine state and
modify the instruction decode and execution appropriately. one of the
issues was that microcode tended to be a totally different beast and
with little in the way of software support tools.
http://www.garlic.com/~lynn/subtopic.html#mcode

amdahl 370 clones implemented an intermediate layer called macrocode
that effectively looked and tasted almost exactly like 370 ... but had
its own independent machine state. this basically allowed almost
exactly moving some virtual machine hypervisor code to macrocode level
... w/o the sometimes difficult translation issues ... while
eliminating standard context switching overhead (register and other
state save/restore).

it was also an opportunity to do some quick speed up. standard 370
architecture allows for self-modifying instructions ... before stuff
like speculative execution (with rollback) support ... the checking
for catching whether the previous instruction had modified the current
(following) instruction being decoded & scheduled for execution
... frequently doubled 370 instruction elapsed time processing.
macrocode architecture was specified as not supporting self-modifying
370 instruction streams.

i've frequently claimed that the 801/risc formulation in the mid-70s,
http://www.garlic.com/~lynn/subtopic.html#801

was opportunity to do the exact opposite of other stuff in the period:
combination of the failure of future system project (extremely complex
hardware architecture)
http://www.garlic.com/~lynn/submain.html#futuresys

and heavy overhead performance paid by 370 architecture supporting
self-modifying instruction stream and very strong memory coherency
(and overhead) in smp implementations.

separating instruction and data caches and providing for no coherency
support between stores to the data cache and what was in the
instruction cache ... precluded even worrying about self-modifying
instruction operation. no support for for any kind of cache coherency
... down to the very lowest of levels ... also precluded such support
for multiprocessing operations.

i've sometimes observed that ibm/motorola/apple/etc somerset was sort
of taking the rios risc core and marrying it with 88k cache coherencyl.
recent, slightly related posting
http://www.garlic.com/~lynn/2005o.html#37 What ever happened to Tandem and NonStop OS?

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

DUMP Datasets and SMS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DUMP Datasets and SMS
Newsgroups: bit.listserv.ibm-main
Date: Tue, 06 Sep 2005 14:37:44 -0600

"Edward E. Jaffe" writes:

SNA is indeed a lower layer than NJE. VTAM is a subsystem that
implements SNA (e.g., LU2, LU6.2) and non-SNA (e.g., LU0) under
z/OS, z/VM, and z/VSE -- not a protocol.

Why has TCP/IP so surpassed SNA?

and sna is not a network, basically SNA/vtam is a terminal control
system ... it didn't even have a network layer. my wife and moldow did
peer-to-peer networking architecture (AWP39) in the early SNA days
... and got lots of grief from the SNA people ...  slightly related
posting
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 8-bit and back

this was before she was con'ed into going to POK to be in charge of of
loosely coupled architecture.  In POK, she was responsible for
peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

which didn't see much play until parallel sysplex ... except for
possibly the ims hot-standby work.

APPN was possibly the first SNA-related architecture with network
layer support. However, the SNA organization non-concurred with
announcing APPN and it took several weeks of escalation until the APPN
announcement letter was rewritten to not claim any relationship at all
between SNA and APPN.

While arpanet and OSI had true networking layer ... they shared common
characteristic with SNA ... effectively a homogenuous architecture.  A
big step forward for arpanet was the big cut-over to internetworking
protocol on 1/1/83 (gateways and the internetworking of possibly
heterogeneous networks).

I've often claimed that one of the reasons that the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

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

... was larger than the arpanet from just about the beginning until
sometime in the summer of 1985 ...
http://www.garlic.com/~lynn/internet.htm#22

was that the primary internal network technology effectively had a
form of gateway support built into every node.

For instance, NJE implemented the traditional arpanet, osi, sna
homogeneous architecture. NJE also made a serious mistake of
intermixing networking protocol fields and job control fields.  NJE
was also scaffolded off the HASP networking control (early on some of
the code still carried the "TUCC" customer identification). The HASP
heritage basically mapped networking nodes into unused psuedo device
table entries ... which (originally) had limitation of 255 entries. A
large HASP/JES2 system might have 60-80 psuedo devices leaving only
170-190 entries free for defining network nodes.

By the time NJE was announced a made available to customers, the
internal network already had over 255 nodes (and the arpanet had
approx. 250 nodes at the 1/1/83 switch-over ... a point in time that
the internal network was nearing 1000 nodes).

NJE would trash traffic (even traffic purely passing thru), where NJE
didn't have valid definitions for both the origin and destination
nodes. Once the internal network exceeded the NJE table size ... you
had to relegate NJE nodes to purely boundary end-points (they couldn't
be trusted with generalized network traffic).

The arbitrary NJE confusion of mixing networking fields and job
control fields ... frequently had the effect if some network traffic
originated from an NJE node that was at different level than the
destination node ... slight field changes between releases could
result in bringing down the destination node MVS system. In a
world-wide network spanning numerous datacenters and organization
... it was just about guaraneteed that you wouldn't have all NJE nodes
in the world operating at the same release. There is somewhat infamous
folklore story of some traffic originating at a san jose NJE node
causing MVS systems in Hursley to crash.

As a result, a large library of specialized gateway code grew-up for
the core internal networking technology. All NJE nodes were placed
behind real networking nodes ... where specialized gateway code was
defined for each connected NJE release. It was the responsibility of
the gateway code to recognize incoming NJE traffic (destined for a
local NJE node), convert the incoming NJE header to canonical format
and then reformat to exactly corresponds to the destination NJE node
(to prevent constant MVS system crashes all over the world).

For some slight topic drift, there was this project in the late 80s
called HSP (high-speed protocol) that was attempting to address some
of the performance issues with TCP. It identified that typical TCP
pathlength implementation was around 5000 instructions and required
five buffer copies (and it was starting to be a concern that for large
message sizes, cache effects and processor cycle overhead related to
buffer copies might exceed actual instruction execution). In any case,
HSP was moving to zero buffer copies and significant cut in
pathlength.  However, a somewhat corresponding function done thru VTAM
was measured around 150,000 instructions and 15 buffer copies.

We tried to get HSP introduced into ANSI x3s3.3 body for standards
work (iso charactered us standards body responsible for standards
corresponding to OSI levels 3&4). However, ISO (& ANSI) had policy
that standards work couldn't be done on protocols that violated OSI.

HSP protocol work was a problem because

1) it was going directly from transport (4/5) interface directly to
lan/mac interface. this bypassed network (3/4) interface and so
violated osi

2) it supported internetworking ... OSI doesn't have an
internetworking layer ... and so violated OSI.

3) LAN/MAC interface sits somewhere in the middle of OSI layer
3/networking and therefor violates OSI. therefor any protocol that
supports LAN/MAC interface also violates OSI.

In any case, arpanet, OSI, and SNA all suffered common shortcoming
dictating a homogeneous environment. The internal network technology
developed at the science center avoided this shortcoming from just
about the original implementation. arpanet overcame this shortcoming
in the great conversion to internetworking protocol on 1/1/83.

There is some folklore that the specifics of SNA terminal control
specification is somewhat the outgrowth of future system ...
which was canceled before even being announced
http://www.garlic.com/~lynn/submain.html#futuresys

a specific reference
http://www.ecole.org/Crisis_and_change_1995_1.htm

from above:

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

... snip

And future system motivation is somewhat blamed on plug compatible
controllers.

when i was an undergraduate, I had added the tty/ascii terminal
support to cp67. I had tried to do some fancy 2702 program to
dynamically identify terminals and allow any terminal to dial-in on
any port. It turns out that I could do dynamic terminal recognition,
but 2702 had a hardware restriction that prevented allowing any
terminal to dial-in on any port.

this somewhat spawed a university project that reversed engineered the
channel interface and built a channel inteface board for a
minicomputer. The minicomputer was programmed to emulate terminal
controller ... and do terminal and baud rate determination. somewhere
there is a rightup that blames four of us for spawning the plug
compatible controller business.
http://www.garlic.com/~lynn/subtopic.html#360pcm

In the mid-80s I got involved in doing somewhat similar repeat
.. which I had the opportunity to present at an SNA architecture
review board meeting in raleigh (after my talk, the guy that ran the
ARB wanted to know the responsible person that authorized me to
present).
http://www.garlic.com/~lynn/99.html#66 System/1
http://www.garlic.com/~lynn/99.html#67 System/1
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP

there were minor other SNA issues. internal product houses that would
develop there own box and created an exact state regression test
according to official SNA specification ... would find that there
could be significant differences from what was the SNA specification
and how VTAM actually operated (it didn't matter what the SNA
specificatioo said, to ship it had to interoperate with VTAM).

slightly drifting the topic in another direction, one of the mainframe
early tcp/ip product issues was the level of programming required to
support the availble interface controller box.  The early
implementation would consume a 3090 processor getting 44kbytes/sec
thruput. I had modified the standard product and added rfc 1044
support ... and some tuning at cray research between a 4341-clone and
a cray ... the 4341 got 1mbyte (channel) speed thruput using only
modest amount of 4341 processor.
http://www.garlic.com/~lynn/subnetwork.html#1044

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

DUMP Datasets and SMS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DUMP Datasets and SMS
Newsgroups: bit.listserv.ibm-main
Date: Tue, 06 Sep 2005 15:02:23 -0600

ref:
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS

... slight additional drift on the internet side.

about the time of the 1/1/83 great switchover to tcp ... bitnet
... similar technology to the internal network ... but a completely
separate network ... was compareable size to the arpanet.
http://www.garlic.com/~lynn/subnetwork.html#bitnet

and this was expanded international as earn ... reference from 1984
http://www.garlic.com/~lynn/2001h.html#65

internet had two parts of the success ... the internetworking
technology ... which saw conversion to in the great 1/1/83 cut-over
... and real live production backbones that internetworked different
networks ... a major advance was the NSFNET backbone.

we were operating an internal high-speed backbone at the time, but
weren't allowed to bid on NSFNET. however a technical audit by NSF
came up with some statement that what we were operating was at least
five years ahead of all NSFNET bid submissions. minor
reference
http://www.garlic.com/~lynn/internet.htm#0

our internet standards index
http://www.garlic.com/~lynn/rfcietff.htm

misc. historical references:
http://www.garlic.com/~lynn/rfcietf.htm#history

NSFNET bid and award announcement reference
http://www.garlic.com/~lynn/internet.htm#nsfnet

the NSFNET program announcement text:
http://www.garlic.com/~lynn/2002k.html#12

and posting reference about the NSFNET bid award:
http://www.garlic.com/~lynn/2000e.html#10

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

DUMP Datasets and SMS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DUMP Datasets and SMS
Newsgroups: bit.listserv.ibm-main
Date: Tue, 06 Sep 2005 16:49:28 -0600

Anne & Lynn Wheeler writes:

and sna is not a network, basically SNA/vtam is a terminal control
system ... it didn't even have a network layer. my wife and moldow did
peer-to-peer networking architecture (AWP39) in the early SNA days
... and got lots of grief from the SNA people ...  slightly related
posting
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 8-bit and back

one of the other issues with respect to the internal network vis-a-vis
the internet (even tho the majority of the internal network had little
to do with SNA/vtam) ... was the transition between 83 & 85 with the
number of nodes in the internet exceeding the number of nodes in the
internal network. obviously the internet got gateway technology
allowing the interconnecting of multiple disjoint infrastructures ...
allowing it to catch up with the internal network technology (at least
with that respect).

however, the SNA/vtam faction heavily enforced position regarding
interconnection of PCs and workstations via terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation

vis-a-vis tcp/ip implementation turning PCs and workstations into
peer-to-peer nodes.

this continued thru the 80s ... and somewhat cumulated in SAA ..
which can be construed as an attempt to return the client/server genie
to its bottle, helping reinforcing the terminal emulation paradigm.

besides the previous references of real peer-to-peer being at odds
with SNA's underlying centralized terminal control (and homogeneous)
paradigm ... we ran into disagreements when we started pushing 3-tier
architecture, middle layer and middleware in the SAA hey day. my wife
had co-authored and presented a response to a large campus-like
environment, federal networking request. In it she had started the
formulation of 3-tier architecture. We expanded on that and started
doing middle layer (aka 3-tier architecture) customer executive
presentations. It involved tcp/ip, ethernet, client/server, and 3-tier
architecture.  This caused all sorts of pushback from T/R, SNA, and
SAA organizations.
http://www.garlic.com/~lynn/subnetwork.html#3tier

some specific
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?

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

address space

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: address space
Newsgroups: bit.listserv.ibm-main
Date: Tue, 06 Sep 2005 17:59:51 -0600

Jay Maynard writes:

ISTR this was because the answer wasn't specified in the POO when
the machines that implementd the feature were being developed, and
so the POO was changed to make it model-dependent because two
systems were implemented differently and couldn't be changed to be
consistent. Am I correct, or is there a parity check in that block?

basically xa (frequently called 811, aka nov. 1978) architecture had
an architecture, access registers, program call, etc. basically move
all sort of library and system of the same address space as the
application ... but retain the efficiency of pointer passing and
branch&link.

the initial transition from mvt real memory to vs2/svs ... basically
layed mvt out in 16mbyte virtual memory. the prototype for vs2 was
done on 360/67 by borrowing CCWTRANS from cp67 and hacking it into an
MVT kernel along with some stub virtual memory and paging support.

The transition from VS2/svs to VS2/mvs gave each application its own
16mbyte virtual address space ... however since the pointer passing
paradigm was so engrained (from mvt days), the kernel occupied 8mbytes
of each application address space (theoritically leaving 8mbytes for
application code).

However, there was this issue with subsystem code ... which is sort of
half-way between kernel stuff and application stuff. With subsystem
code in their own address space, continuing to support pointer passing
paradigm became more difficult. Infrastructures that grew up with
virtual address space tended to do things like message passing rather
than pointer passing. The subsystem hack in MVS was to define the
"common segment" ... basically some stub subsystem code in the
application address space could copy the parameters into an area of
the common segment, and make a supervisor call ... passing a pointer
to the common segment resident parameters. Execution would eventually
pop-up in the subsystem which then would have the common segment at
the same virtual address ... so the passed address pointer would work.

The problem was that there was just a single common Common Segment for
the whole environment. By the 3033 time-frame, it was common to find
installations with four and five megabyte common segments ... 16mbytes
address space minus 8mbyte kernel, minus 5mbyte common segment
... leaving only 3mbytes (and sometimes less) for applications.

Worley was in large part responsible for the 3033 dual-address space
and cross-memory support. Basically applications could do a kernel
call for some subsystem service passing a address pointer. The
subsystem eventually received control ... and used the address pointer
to pick up the data out of the secondary address space (rather than
requiring its movement to common segment area).

trivia ... worley also worked on risc chips and eventually left to
join HP. What current chip architecture was he one of the primary
architects for?

some past worley specific references:
http://www.garlic.com/~lynn/2000c.html#84 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2002g.html#18 Black magic in POWER5
http://www.garlic.com/~lynn/2003j.html#35 why doesn't processor reordering instructions affect most
http://www.garlic.com/~lynn/2004f.html#28 [Meta] Marketplace argument
http://www.garlic.com/~lynn/2004f.html#29 [Meta] Marketplace argument

misc. past aos2 prototype postings:
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000.html#68 Mainframe operating systems
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line

misc past 3033 dual-address space postings:
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"
http://www.garlic.com/~lynn/2005f.html#7 new Enterprise Architecture online user group
http://www.garlic.com/~lynn/2005f.html#57 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns

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

address space

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: address space
Newsgroups: bit.listserv.ibm-main
Date: Tue, 06 Sep 2005 18:22:58 -0600

another hack done for 3033 ... was 32mbyte support (besides
dual-address space and cross memory support)

basically 370 still had only 16mbyte real and 16mbyte virtual support
(note that 360/67 had both 24bit and 32bit virtual address modes).

i/o wasn't keeping up so the best way to improve performance was to
avoid as much i/o as possible ... that required keeping large amount
of stuff in real memory. that strategry was starting to be a thruput
bottleneck for the 3033. for one thing ... not only were 4341s beating
3031 and vaxes in performance and price/performance ... but cluster of
six 4341s was beating 3033 in aggregate performance and
priace/performance (a 3033 having 16 channel and 16mbytes of real
stroage, six 4341s having aggregate of 36 channels and 96mbytes of
real storage).

so the gimmick was to define 14bit real page numbers. standard page
table had 16bits, 12-bit (real) page number (times 4k pages gives
16mbyte real addressing), 2 defined flag bits, and 2 undefined
bits. They took two undefined bits and allowed them to be prefixed to
the (real) page number ... so instead of being able to specify 4096 4k
real pages ... it could specify up to 16384 4k real pages (64mbytes).
Instructions could only generate 24bit virtual addresses ... but
relocate hardware could take a 24bit virtual address and convert it to
a 26bit real address.

thus was born the 16mbyte line.

kernel code running in real address made ... might be required to
access some information in a virtual page above the 16mbyte line.  The
hack was to use some slight-of-hand virtual memory system tricks to
copy/move the virtual page from above the line to below the line.

this carried over to 32mbyte 3081s running in 370 mode.

misc. past postings on the 3033 32mbyte hack
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005.html#43 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#0 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2004.html#17 Holee shit!  30 years ago!
http://www.garlic.com/~lynn/2004n.html#50 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/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design

some more recent postings on the 4341 subject:
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005.html#51 something like a CTC on a PC
http://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#63 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005d.html#30 The Mainframe and its future.. or furniture
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#30 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#36 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005g.html#24 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#11 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
http://www.garlic.com/~lynn/2005h.html#43 Systems Programming for 8 Year-olds
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005m.html#8 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#10 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#12 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#16 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#29 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
http://www.garlic.com/~lynn/2005o.html#16 ISA-independent programming language
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design

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

address space

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: address space
Newsgroups: bit.listserv.ibm-main,bit.listserv.vmesa-l
Date: Wed, 07 Sep 2005 11:46:12 -0600

Bruce Black writes:

Gosh, the APL ball.  That brings back memories.

For you newbies, he is referring to the IBM Selectric Typewriter, which
had a replaceable ball with all the characters on it, depending on what
special character set you wanted.  Selectrics were also used as
interactive terminals.  APL uses a lot of arcane characters, so you
needed a special Selectric ball and key tops to program in APL, or read
the code.  Selectrics were fun to watch when typing fast.  The ball
would spin and tilt just like those gut-spewing rides at traveling
carnivals.

Neat language, too.  Back at Brown University in the early 70s, I worked
with OS and CP/67 and CMS, but I learned APL and as an exercise I wrote
the equivalent of the CMS file editor in a half-page of APL code (of
course the CMS editor of the time was a simple line-oriented editor)

I have an 2741 apl ball sitting here next to my screen.

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

ported apl\360 interpretor (done at phili science center) to cms.
part of this was that the apl\360 monitor supported swapping 16k-32k
real memory apl workspaces. they used a storage allocation mechanism
that allocated a new block of stroage on every assigned ... until it
reached the top of the workspace ... and then invoked garbage
collection to compact all allocated storage. this worked fine in 16k
real storage workstapce ... but looked like page thrashing running in
cms virtual memory environment with possibly hundreds of kbytes of
mbytes of address space. the apl storage allocation mechanism had to
be reworked for operation in large virtual memory environment.

besides making cms\apl available as product (for both external and
internal users) ... it was also made available on cambridge's cp67
service. back then, apl was getting heavy use for lots of business
modeling "what if" questions (some of the stuff that you find being
implemented these days with spreadsheets). one of the early, heavy
users of cms\apl on cambridge machine, were business planning people
from corporate hdqtrs in armonk. They loaded the most secret of
corporate information on the cambridge machine and then ran various
business models. one of the reasons for using the cambridge system was
that it was the first that offered reasonably large APL workspaces
that allowed dealing with more real-world environments.

this somewhat created interesting security issues since the cambridge
machine was also being used by numerous univ. & col. students in the
boston area (i.e. mit, harvard, bu, etc). misc. comments about cp67
based commercial time-sharing services
http://www.garlic.com/~lynn/submain.html#timeshare

DP division also started deploying a large number of apl-based
applications for sales, marketing and field people on their own cp67
systems ... which was later migrated go vm370. eventually all sales,
marketing and field people worldwide were using vm370 for their
day-to-day business.
http://www.garlic.com/~lynn/subtopic.html#hone

cms\apl also caused some complaints from iverson, folkoff, et all at
phili science center ... because it introduced system calls that
allowed apl to do things like read & write files (also allowing apl
applications to address some more real world operations, including
huge amounts of data). however, this violated the purity of the apl
language ...which had been restricted to purely doing things
internally within the self-contained apl workspace (modulo typing on
the 2741). this was later resolved with the introduction of apl shared
variables as a paradigm for accessing external facilities.

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

Multicores

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multicores
Newsgroups: comp.arch,bit.listserv.vmesa-l
Date: Wed, 07 Sep 2005 11:58:46 -0600

"robertwessel2@yahoo.com" writes:

Windows, like pretty much any other OS, will dole out CPU time in
time-slice increments to threads that run CPU bound, but only rarely
does a thread (in most systems) ever run out a time slice before
blocking on some event (and thus threads are rarely CPU bound).

i had done dynamic adaptive scheduling back in the 60s as an
undergraduate. this was sometimes referred to as fairshare (or
wheeler) scheduler ... because the default scheduling policy
was fairshare

basically light-weight interactive tasks got shorter quanta than more
heavy-weight longer running tasks. advistory deadline was calculated
proportional to size of the quanta and the recent resource
utilization.  quanta could span certain short i/os (disk, etc) ...  so
heavy utilization wasn't necessary restricted to absolutely pure cpu
bound (just reasonably high rate of cpu consumption).

light-weight interactive tasks would tend to have more frequent quanta
with shorter deadlines ... and heavy weight tasks would have less
frequent larger quanta. interactive tasks would appear to be more
responsive if they could complete within a few of the shorter quanta
and/or if they haven't been using a lot of resources recently.
basically the objective was to uniformally control of the overall rate
of resource consumption (regardless of the quanta size).

the other issue was that this was done as modifications to existing
cp67 system that had an extremely complex scheduler that wasn't
directly controlling resource utilization ... just moving priorities
up & done and itself could consumer 10-15 percent of total cpu
utilization.  so a major objective of the scheduler change was to not
only implement effective resource consumption supporting a variety of
scheduling policies ... but do it with as close as possible to zero
pathlength.
http://www.garlic.com/~lynn/subtopic.html#fairshare

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

Multicores

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multicores
Newsgroups: comp.arch,bit.listserv.vmesa-l
Date: Thu, 08 Sep 2005 12:56:39 -0600

"robertwessel2@yahoo.com" writes:

Of course that's not anything like the way it actually works.  If
two threads, one high and one low priority, are ready to run, the
high priority thread will be dispatched, and time slices have
nothing to do with it.  In the basic case a runnable high priority
thread will prevent all low priority threads from running, period.
If two threads of equal priority are both runnable, then, and only
then, will time slices come into play to switch between those equal
priority threads.  That being said, many OSs will apply a dynamic
temporary priority boost to lower priority threads if they've not
been allowed to run for an extended period of time so that they're
not starved of CPU time completely.  And there are, of course, more
complex schedulers that work not just on thread priority, but take
into account system policies that say things like "guarantee at
least 15 % of the CPU to job#3."  Those often work by watching the
run history and adjusting a more traditional priority scheme to meet
the goals.

dynamic adaptive resource management that i was doing in the 60s as
undergraduate ... used advisory deadlines for dispatching/scheduling
(effectively based on size of quanta and the amount of resources the
task was getting relative to its target resources).

priorities were an aspect of scheduling policy ... default policy was
fair share and default priority mechanism adjusted a tasks relative
portion of fair share (translated into more or less than overall
infrastructure fair share).

evolution of that infrastructure were things like partitioning
resources among departments and then making individual fair share a
portion of the related departments allication ... as opposed to
overall total system resources.

one of the reasons for doing the change ... was to drastically reduce
the pathlength of the then available implementation which was starting
to take 10-15 percent of elapsed time ... and used a priority scheme
more like that outlined above. previous post
http://www.garlic.com/~lynn/2005p.html#21 Multicores

the code that i had done as undergraduate was eventually picked up and
shipped in the cp67 product. Much of the code was then dropped in the
morphing from cp67 to vm370. however it was re-introduced when i did
the resource manager for vm370.
http://www.garlic.com/~lynn/subtopic.html#fairshare

one of the other distinctions of the resource manager was that it was
chosen to be the guinea pig for licensed/priced kernel software.

with the 6/23/69 unbundling announcement (large part motivated by
various litigation activities), there was a switch to start
charging/licensing application softwoare ... although kernel software
still was free.
http://www.garlic.com/~lynn/submain.html#unbundle

the resource manager got tapped to be priced/licensed kernel software.
I got the reward to spend time over period of several months with
various business groups working out the changes for pricing for kernel
software. the guidelines established with the resource manager was
that kernel software not directly involved with hardware support (like
device drivers) would still be free ... but other kernel software
could be priced separately.

this caused a problem for the next base kernel release where they were
going to ship SMP support (something else that didn't make the
transition from cp67 to vm370 ... even tho all the invention leading
up to the compare and swap instruction had been done on cp67). I had
included a bunch of stuff in the resource manager that SMP support
needed. However the pricing policy wa that SMP support had to be free
(aka hardware support) ... so it was a violation of the policy with
you had to buy the resource manager in order for SMP support to work.
Eventually they moved stuff required by SMP support out of the
licensed/priced resource manager into the base (free) kernel.
http://www.garlic.com/~lynn/subtopic.html#smp

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Thu, 08 Sep 2005 20:28:35 -0600

Peter Flass writes:

My understanding is that a "workstation" is a single-user system.
If so, workstations certanly didn't obsolete minis.  The PC
obsoleted both, except for specialized applications, either as a
single-user workstation replacement or in its "server" guise.  Only
a few workstation manufacturers survive.  Sun and IBM are major
players in the server market as well as WS.  Maybe only SGI doesn't
sell servers?

small historical mention of (very) early sun days
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party

for total topic drift ... more mention of DataHub ... also referenced
in the above post
http://www.garlic.com/~lynn/2000g.html#40 No more innovation?  Get serious
http://www.garlic.com/~lynn/2002f.html#19 When will IBM buy Sun?
http://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
http://www.garlic.com/~lynn/2003e.html#26 MP cost effectiveness
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small clusters

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

Hi-tech no panacea for ID theft woes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hi-tech no panacea for ID theft woes
Newsgroups: alt.computer.security
Date: Fri, 09 Sep 2005 11:36:20 -0600

Unruh <unruh-spam@physics.ubc.ca> writes:

Actually no. Common sense is our intuitive solution to problems
based on past experience. For most of these electronic things past
experience is a very poor guide, and thus so is common
sense. Especially when allied with an almost complete ignorance with
how it all works. There is nothing in past experience which would
say that opening a letter was dangerous in and of itself. Opening an
email is. There is nothing in past experience that says that the
actions of someone 5000 miles away could be of danger to you.  On
the net there is.

some related comments regarding some of the threats and countermeasure
issues:
http://www.garlic.com/~lynn/aadsm20.htm#23 Online ID Theives Exploit Lax ATM Security
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#0 ID theft ring proves difficult to stop

there is always the issue that crooks may be going after the
low-hanging fruit ... and in a target rich environment ... closing one
vulnerability may just find the crooks moving on to a different
vulnerability. that is typically where a detailed threat model can
come in handy.

some mention that there is difference between identity fraud and
account fraud, even tho lots of identity theft stories tend to lump
them together (i.e. account fraud just needs to counterfeit authentication
w/o necessarily requiring any identification):
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
http://www.garlic.com/~lynn/2005j.html#52 Banks
http://www.garlic.com/~lynn/2005j.html#53 Banks
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#42 public key authentication

and lots of posts on account harvesting for fraud purposes
http://www.garlic.com/~lynn/subintegrity.html#harvest

and for a little drift ... post on data breach vulnerability and
security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk<

note part of the issue is that sometimes there is confusion between
identification and authentication ... recent post touching on some of
the confusion issues:
http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame

it is possible to come up with countermeasures that make
account fraud much more difficult (by strengthen various
authentication weaknesses) ... independent of addressing identity
fraud issues. a simple example of the difference is say it was
possible for somebody to open an offshore anonymous bank account
... and be provided with authentication technology for performing
transactions. by definition, there has been absolutely no
identification involved (and the authentication technology could still
prevent fraudulent account transactions).

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

Hi-tech no panacea for ID theft woes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hi-tech no panacea for ID theft woes
Newsgroups: alt.computer.security
Date: Fri, 09 Sep 2005 13:31:17 -0600

"Brett Michaels From Poison" writes:

I'm talking along the lines of end users, which I beleive are the
number one weakness in any security structure. Most end users don't
know a hammer from a nail when it comes to computer security.  I'm
not speaking common sense on a specific user, but rather a general
base of common sense.

If these end users were more educated and used more common sense
measures, eg. not opening unknown attachments, not writing your pin
on your mac card, this would allow IT Admins to concentrate their
efforts on more difficult security measures.  Some end users
actually do "dumb things" more than anyone realizes.  As a security
auditor, the place we find the largest pool of weaknesses is end
user behavior/lack of policy adherance.

ref:
http://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes

nominally multi-factor authentication requires that the different
factors be subject to different vulnerabilities ... i.e. from
3-factor authentcation model
http://www.garlic.com/~lynn/subintegrity.html#3factor

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

... a something you know PIN is nominal a countermeasure to
lost/stoeln something you have physical card.

an institutional-centric view has been that shared-secret pin/password
based something you know implementations require that the person
have a unique pin/password for every unique security environment (as
countermeasure to somebody in one environment attacking another
environment ... say, part-time employee in garage ISP accessing
people's online web financial services ... assuming common password
for both environments).
http://www.garlic.com/~lynn/subintegrity.html#secrets

from a person-centric view, as the number of electronic proliferated,
people may now be faced with memorizing scores of unique & different
pin/passwords. one of the consequences is that you find people making
lists and storing them in their wallet. also some study claimed that
something like 30 percent of the people write their PINs on their
debit cards.

so a common lost/stolen scenario is the wallet is lost ... which
includes any lists of pin/passwords and all cards (including cards
that have pins separately written on the cards. as a result, there is
a common vulnerability (failure mode) for lost/stolen wallet that
effects all cards and some number of recorded pins/passwords
... defeating the objecting of having multi-factor authentication.

another threat/exploit for account fraud is getting people to divulge
the information on their cards and related information (phishing
attacks).

so there is a requirement for two countermeasures

1) making valid account transactions based on a something you have
physical object ... which uses some paradigm where the owner of the
physical object isn't able to verbally disclose the information
2) eliminate the enormous proliferation of the shared-secret paradigm
... resulting in the impossible requirement for people to memorize scores
of different pieces of information.

so one implementation uses asymmetric cryptography where keys are
generated inside a chip/token and the private key is never divulaged.
proof of possesing the chip/token (something you have
authentication) is done with digital signatures ...  which doesn't
expose the private key. It is possible for the person possessing the
token to proove that they have the token ... but they aren't able to
divulge the information required for the proof (i.e. the private key
contained in the token). The digital signature methodology generates a
new value on every use ... so the operation is resistant to replay
attacks (somebody having recorded a previous use).

That still leaves shared-secret vulnerabilities associated with
memorizing human factors (and countermeasure against
lost/stolen token). Using a chip/token would allow a PIN to be used
for correct operation of the chip/token ... w/o requiring the PIN to
be recorded.  That makes the PIN a secret (as opposed to
shared-secret) and eliminates the shared-secret based
security requirement for having a unique PIN for every environment (if
person has a single PIN for everything they do ... it is less of a
problem to memorize ... and also opens the possibility of making it
more complex than four numeric digits).

Such an approach makes phishing attacks for account fraud much more
difficult ... since the person can't even divulge information in the
token that they don't now (crooks can't simply ask tens of thousands
of people to type in their account numbers and PINs and then go off
and extract money, they now actually require the exact physical
token).

it also makes crooks work harder for physical stealing tokens and also
obtaining the associated PIN (much higher effort in order to perform a
fraudulent transaction).

note also that a countermeasure associated with online
transaction environment and lost/stolen (physcial) tokens ... is the
owner is likely to notice that it is missing and report it, resulting
in the associated account access being deactivated. In the phishing
(also record/replay, key logger, etc) scenarios, the victim might not
realize that there is money leaking out of their account until weeks
later.

so much of the current electronic based account fraud could be
eliminated ... forcing it purely to stealing physical object (where a
crook actually has to physically take them one or two at a time, can't
program a computer to lift millions)... which also will nominally have
a much shorter window of (crime) opportunity (unitl it is reported
lost/stolen).

The other way of looking at it is that the fraud ROI (return on
investment) is significantly reduced (enormous increase in physical
effort, limited window of opportunity).

You still have some number of social engineering attacks (other than
the phishing kind) ...  where the crook convinces the victim to
perform the actual transaction (as opposed to the crook obtaining
sufficient information to perform the transactions themselves). Some
of these are currently getting wide-spread coverage under the heading
of some sort of scam.

misc. past person-centric related postings:
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Fri, 09 Sep 2005 14:36:30 -0600

iddw@hotmail.com (Dave Hansen) writes:

FWIW, I believe the term originally came from retail markets where,
for example, Whirlpool would sell their washing machines to Sears, who
would slap a Kenmore label on them, and sell them to the public.  In
that scenario, the OEM is Whirlpool, because they were ones who
actually built the equipment.  The term makes sense here.

I think it transmogrified from that sensible meaning to "the
manufacturer of the final product."  Note that, in the above example,
Whirlpool manufactured the final product, and they are the OEM.  And
now, when Cambridge Instruments designs an e-beam lithography system
that incorporates a PDP-11 as the control computer, Cambridge becomes
the OEM, because they built the system that is sold to the, er,
consumer.

OEM .. original equipment manufacture

... however it was also sometimes used as in

OEM ... other equipment manufacture

with somewhat similar sense as

PCM ... plug compatible manufacture

in the tales about mainframe plug compatible (clone) controller
http://www.garlic.com/~lynn/subtopic.html#360pcm

the story starts back with 2702 telecommunication controller.  the
university had type-I and type-III linescanners installed in the 2702
(for 2741 and 1052s). the university was getting some number of
tty/ascii terminals and needed to upgrade the 2702 with type-II
linescanner that supported tty terminals.

the field-installable 2702 type-II linescanner kit came in a couple
big boxes labled "heathkit" (as in original equipment manufacture?).

the basic cp67 terminal support did dynamic terminal identification
between 2741 and 1052 (the 2702 had "SAD" command where you could
dynamically associate a specific linescanner with a particular port).

I had to add tty/ascii terminal support to cp67 ... and so i thot it
would be neat if i could dynamically recognize tty, 2741, and 1052
including allowing any dial-up terminal to connect to any dial-up
number (in practice this nominal met that there was rotary with a
single dial-in number ... and the box would find the first unused
number/port).

it turned out that 2702 had a hardware restriction ... while you could
use the SAD command to dyna