List of Archived Posts

2005 Newsgroup Postings (1/1 - 1/19)

[Lit.] Buffer overruns

[Lit.] Buffer overruns

Athlon cache question

[Lit.] Buffer overruns

Athlon cache question

[Lit.] Buffer overruns

[Lit.] Buffer overruns

How do you say "gnus"?

[Lit.] Buffer overruns

OSI - TCP/IP Relationships

The Soul of Barb's New Machine

CAS and LL/SC

The Soul of Barb's New Machine

Amusing acronym

Using smart cards for signing and authorization in applets

Amusing acronym

Amusing acronym

Amusing acronym

IBM, UNIVAC/SPERRY, BURROUGHS, and friends. Compare?

The Soul of Barb's New Machine (was Re: creat)

I told you ... everybody is going to Dalian,China

The Soul of Barb's New Machine (was Re: creat)

The Soul of Barb's New Machine (was Re: creat)

Network databases

Network databases

Network databases

Network databases

Network databases

Smart cards and use the private key

Network databases

Network databases

Do I need a certificat?

8086 memory space [was: The Soul of Barb's New Machine]

some RDBMS history (x-over from comp.databases.theory)

increasing addressable memory via paged memory?

Do I need a certificat?

Network databases

[OT?] FBI Virtual Case File is even possible?

something like a CTC on a PC

CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)

clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))

something like a CTC on a PC

Higher Education places still use mainframes?

increasing addressable memory via paged memory?

John Titor was right? IBM 5100

OSI model and SSH, TCP, etc

8086 memory space

creat

[OT?] FBI Virtual Case File is even possible?

increasing addressable memory via paged memory?

something like a CTC on a PC

something like a CTC on a PC

8086 memory space

8086 memory space

creat

Foreign key in Oracle Sql

8086 memory space

Foreign key in Oracle Sql

Foreign key in Oracle Sql

8086 memory space

8086 memory space

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Sun, 02 Jan 2005 08:02:59 -0700

bryanjugglercryptographer writes:

Right; that's why Mr. Wheeler's previous comparisons
distinguished C environments from others.

another minor example ..

I was at a small conference in '76 ... presenting part of a new 16-way
smp hardware design and software support for the hardware, virtual
memory, use of virtual memory address space to partition environment
and use of privilege/non-privilege hardware modes to also partition
environment.

The 801 group also did presentation on design of new type of hardware
architecture ... where the hardware was extremely simplified and lots
of traditional integrity and isolation features had been eliminated
from the hardware and moved to the software. Everything would be
implemented in a simplified version of PLI called PL.8 and the
operating system was called cp.r. There was no hardware support for
privilege/non-previlege mode ... all programs could access all
hardware features ... it was totally up to the compiler to guarantee
correct program operation. The operating system had a special
binder/loader ... that would validate that any programs being loaded
only came from a valid, acceptable PL.8 compiler (the compiler
generated a form of signature on the executable tha could be checked
by the operating system at load time). Once a program was loaded, it
(and runtime libraries) had direct access to all hardware features
(w/o any sort of intervening operating system layer). random
past 801 postings
http://www.garlic.com/~lynn/subtopic.html#801

One of the features was that the hardware support had been
significantly simplified ... instead of having virtual memory segment
tables with possibility of large number of defined virtual memory
objects, there were just 16 segment registers. Instead of having
operating system calls (like unix mmap) to handle calls for accessing
different defined virtual memory objects (and validating privileges),
the program could directly manipulate the segment registers (as easily
as it could manipulate any base/address registers). The integrity of
the system was totally dependent on the PL.8 compiler only generating
correct code (and the loader only loading valid PL.8 compiled
programs).

This was a integrated design trade-off involving processor
architecture, operating system implementation and compiler technology
that favored simplifying hardware implementation by shifting several
hardware integrity features to compiler correctness technology.

Current day scenarios have privilege/non-privilege mode and use of
virtual memory hardware as part of integrity isolation ... with
various kinds of privilege checking by kernel calls (crossing the
privilege/non-privilege boundary). There are other hardware features
like low-storage-protect to trap/isolate use of zero pointers by
incorrect code inside the kernel ... i.e. a big issue is problem
detection & isolation (for possibly subsequent correction). A big
issue is that normal failure modes when incorrect code uses zero
pointer to modify low-core ... the actual failure may occur much later
and it proves difficult to isolate and identity the original cause of
the failure (making correct and remediation extremely difficult).

In the past couple years, hardware support for identifying memory
regions as execute/no-execute and modifiable/non-modifiable has been
newly introduced on common processor chips (that didn't have the
support in the past). It was specifically was done to address a common
length exploit associated with c programming environment where an
incorrect/long length could introduce a branch to some exploit code
packaged as part of extra long input data. Executable code would be
marked as non-modifiable (precluding incorrect length of standard
string libraries from overlaying executable code with exploit package
carried in long string) and also include incorrect length overlaying
branch address being able to branch to some exploit code carried as
part of some long string (this results in program failure, but it
catches and isolates being to execute exploit code packaged inside
long string and taking advantage of common c programming environment
mistakes).

so there has been a lot of information gathered about standard c
programming environment leading to large number of length related
exploits ... and apparently sufficient information to introduce (new)
hardware related features to specifically address some of these
exploits that are common in standard c programming environment.

the cve database is one such source of information about the
frequency of such exploits.

for some of the hardware threads (in a number of different groups)
discussing the necessity of new hardware features (and support by
operating systems/kernels) to address these buffer length related
exploits so common in standard c programming environments
http://hardware.mcse.ms/message13436-4.html
http://groups-beta.google.com/group/comp.sys.ibm.pc.hardware.chips/browse_thread/thread/77e8d7bce716a43e/449306e22ebc73f8?q=%2Bcomp.arch+%2B%22no+execute%22&_done=%2Fgroups%3Fq%3D%2Bcomp.arch+%2B%22no+execute%22%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg%26&_doneTitle=Back+to+Search&&d#449306e22ebc73f8
http://groups-beta.google.com/group/comp.sys.ibm.pc.hardware.chips/browse_thread/thread/77e8d7bce716a43e/449306e22ebc73f8?q=%2Bcomp.arch+%2B%22no+execute%22&_done=%2Fgroups%3Fq%3D%2Bcomp.arch+%2B%22no+execute%22%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg%26&_doneTitle=Back+to+Search&&d#449306e22ebc73f8
http://groups-beta.google.com/group/comp.sys.ibm.pc.hardware.chips/browse_thread/thread/77e8d7bce716a43e/449306e22ebc73f8?q=%2Bcomp.arch+%2B%22no+execute%22&_done=%2Fgroups%3Fq%3D%2Bcomp.arch+%2B%22no+execute%22%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg%26&_doneTitle=Back+to+Search&&d#449306e22ebc73f8

the above are just a few examples; for futher discussions about buffer
overflow and no-execute hardware support, use google groups
http://groups-beta.google.com/
and search on buffer overflow and no execute.

the implication is that (at least in some circles) that the buffer
overflow specifically associated with common c programming environment
is so well accepted ... that hardware specific implementations are
being done to address the problem(s).

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Sun, 02 Jan 2005 08:36:00 -0700

note this article from 2001
http://www.theregister.co.uk/2001/08/29/win_xp_slays_buffer_overflow/

however, even given the concerted effort ... new buffer overflow
mistakes continue to be coded (the assertion is that it is so
especially easy in common c programming environment).

more recent article
http://www.theregister.co.uk/2004/12/24/amd_dutch_ads/
about AMD chip hardware and support by Windows XP service pack 2

other kind of descriptions about no execute hardware
for various kinds of buffer overflow issues:
http://gary.burd.info/space/Entry81.html

example comment/post from one of these hardware venues (looking at
trying compensate for buffer length associated exploits in common c
programming environment)

... trivial quote from some random post in one of the hardware
forums

Trivial: use a language where it's automatically enforced.
I.e. basically any language other than C.

... snip ...

other topic drift, just for the fun of it ... a lot of other
801-related posts
http://www.garlic.com/~lynn/subtopic.html#801

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

Athlon cache question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Athlon cache question.
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 02 Jan 2005 11:38:28 -0700

glen herrmannsfeldt writes:

I would think it would depend on the workload, and also the
expectation of the users.   In a case where you have mixed
long and short term jobs, where the long term jobs are supposed
to have lower priority, I would have thought that global would
not work so well.  That is, everyone is not equal, but global
assumes that they are.

In the case where all users are to be treated equally, my
guess would be that global would be better.

in general, global ... regardless of cache type, processor, paging,
file, etc ... attempts to keep the most highly used information around
for the overall system thruput. local tends to perform less well since
it doesn't optimize for the overall system performance ...  resulting
in keeping around lower-use pages for one process while kicking out
higher-user pages for another process.

The issue of LRU is whether or not recent acdess patterns accurately
predict future access patterns (but that is somewhat independent of
the global/local issue).

so another way of viewing it is the impact on overall system
performance (cpu stall) of not having a specific page compared to not
having another specific page.

so long ago, i did this policy based resource manager ... and a lot of
customers started calling it the fair share scheduler because the
default policty was fair share. processes using less then their target
(possibly target as defined as fair share) got better dispatching
priority ... so that they ran faster (at least until they caught up in
their resource utilization objective).

The issue on total system thruput isn't so much dispatching priority
... but total resource thruput objectives. If you have a process that
is supposed to get 80 percent of the processor ... and it is having
frequent page faults ... then the impact on the overall system is much
worse than a process that is supposed to get 5 percent of the
processor (having the same page fault rate).

Some number of strategies were developed to directly address page
fault rate of processess that deemed critical (supposed to get some
significant resources) and behind schedule. One such stratigy was to
run the standard global replacement ... but sporadically
bypass/skip-over selected pages for process in such situation. There
effectively was a global ordering of pages based on projected overall
benefit to the system .... but (in effect) pages belonging to
behind-schedule critical processess could be given extra points).

Part of the issue wasn't strictly page-fault rate ... is was the
combination of relative page-fault rate and page-fault service time
... resulting in total non-executable time for a specific process
... and to what extent that total page-fault related non-executable
time was contributing to the process not meeting the established
resource utilization objective.

this is all predicated that some existing used virtual page in any way
relates to future use of that same virtual page. there are the edge
and pathelogical cases where there is no virtual page re-use and
caching provide no benefit what-so-ever.

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Sun, 02 Jan 2005 11:12:05 -0700

"John E. Hadstate" writes:

I don't remember the "problems" of the C programming environment
being a big factor influencing the architectural development of
S/360 and S/370 (with their Execute-only memory protection).  In
fact, I'm pretty sure that most of the buffer overflow problems in
those days were found in FORTRAN, COBOL, RPG and Autocoder programs.
C hadn't even been invented.

so i assume that you are being flippant or sarcastic ... since 360/370
didn't have execute only memory regions. my reference to no-execute
(aka somewhat the inverse of execute-only) is to recent changes to
existing hardware processors to address buffer length related exploits
in common c programming environments. also, i specifically mentioned
that the no-execute (sort of inverse of execute-only) was recent
addition to some existing processors.

original 360 had storage protection (store & fetch options), in part
because standard 360 had linear real storage addressing model ...  all
execution was in the same, single, real address space (kernel and all
applications). common in virtual memory architectures, different
address spaces have been used to partition kernel and different
applications from each other (i.e. the requirement for store & fetch
protection features are somewhat mitigated if it isn't even possible
to address the region). however, it didn't have a mechanism for
marking specific storage areas as either execute or non-execute
(I-fetch in the PSW could point at any location ... and could fail
because of generalized storage fetch protection or invalid operation
code ... but didn't have any feature tha would prevent I-fetch if the
storage was accessable).

the folklore is that some of the CTSS people went to the science
center on the 4th floor, 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

and worked on virtual machine/memory operating system, gml/sgml,
internal operating system, etc.

other CTSS people went to the 5th floor, 545 tech sq and did Multics
implemented in PLI. The unix/C genre was somewhat a re-action to the
complexity and early performance implementation of multics (in much
the same way that the early success of virtual machine/memory
operating system done on the 4th floor was due to the complexity and
early performance implementation of tss/360).

virtual memory wasn't originally introduced with 370 ... and when it
was finally introduced ... the virtual machine/memory work done on the
4th floor (545 tech sq) was adapted to 370 virtual memory
operation. However, the traditional batch operating system environment
had linear addressing (and pointer passing paradigm) so ingrained that
even with multiple virtual address space (in theory providing
separation and partitioning), the kernel and applications continued to
occupy the same (virtual) address space (and require storage
protection to keep application code from overwriting kernel or other
application routines ... carried over from the 360/370 real storage
days).

the original base 370 virtual memory architecture included read-only
"segment" protect (i.e. flag in the segment table entry that
identified the whole virtual memory as read-only storage) ... but
because of hardware implementation problem in the 370/165, it was not
announced (and disabled on the models that had already implemented
it). a page table entry R/O flag was finally introduced with the 3033
(providing store protection on a 4k virtual page boundary). somewhat
orthogonal, low-storage-protection was introduced in the 80s
... specifically to address issue of zero pointer failure in kernel
code (i.e. bugs in kernel code using incorrect zero pointer to
scribble over low real storage).

the pointer passing paradigm was so ingrained in the batch orientation
... that for the evoluation into coordination between different
applications isolated in their own virtual address space ...
dual-address space (which was later generalized to multiple address
sapce) operation was introduced. With some specific kinds of
restrictions and special use ... applications could utilize pointers
to address storage in different virtual address spaces (using new
forms of semi-privilege operation).

some of the issues in traditional c programming environments is heavy
use of value passing paradigm (compared to pointer passing paradigm)
... coupled with frequent/common length ambiquity about buffers and
strings. the general scenario is the copy of data with arbitrary
length into storage area that is of possibly ambiquous size.

the rather recent hardware support to some processors for non-execute
support is specifically looking at scenario of copy operation of data
of arbitrary length into an area ... which results in overlaying other
data. the exploit scenario is to package into a long string (longer
than anticipated by the application) a relative address pointer and
some exploit code ... which when copied, the exploit address pointer
is designed to overlay an infrastructure value; eventually resulting
in execution being transfered to the packaged exploit code.

The countermeasure for executing the exploit code embedded in an
arbitrary string ... is to require storage areas to be specifically
identified as executable (and/or non-executable). Note this is
different that the execute-only feature which was originally designed
as sort of a copyprotect feature ... it wasn't designed to prevent
execution of arbitrary memory areas ... it was designed so that only
I-fetch could fetch form the specific memory areas and prevent code
from examining the executed instructions (i.e. the exact nature of the
executable code was to be hidden ... but still be allowed to execute).

• Execute-only is different than no execute ... execute-only is sort
of copyprotect countermeasure on executable code; no execute is
countermeasure to prevent random/arbitrary locations of memory being
able to execute.

• 360 had fetch protect (not limited to execution ... but all kinds of
fetches) ... in part because the standard paradigm was single linear
real address space (no virtual memory address spaces to provide
partitioning/separation). fetch protect wasn't very extensively used

• 360 had store protect ... again, in part because the standard paradigm
was single linear real address space (no virtual memory address spaces
to provide partitioning/separation).

• execute-only was not a 360/370 feature ... but was found in some
places in the industry ... somewhat more as a copyprotect of
executable code.

• virtual memory systems haved tended to have things like r/o segment
protection ... allowing the same storage image (shared segment) to
appear in multiple different address spaces concurrently ... but
preventing polution of one address space by application running in a
different address space (preserving partitioning/isolation of virtual
address space paradigm). this was more difficult to adapt to a lot of
360/370 code because of relatively common use of "self-modifying" code
technique (where a preceeding instruction modifies a following
instruction).

• finer granularity memory region R/O protection is possible to
specifically address (shared) code modification by other code (in
error) ...  as opposed to the more generalized R/O storage potectuion.
this is somewhat aided added by RISC/Harvard architectures with
separate I & D caches and requiring specific instructions to
materialize storage alteration operations (that might show up in the D
cache) in the I cache. 360/370 actually has performance/implementation
issues in this area since it has allowed "self-modifying code" (aka
the previous instruction stores some data into the following
instruction ... which causes problems with things like pipelined
prefetch & decoding of instructions in pipeline).

• some-what relatively recent no execute memory regions (as distinct
from more generalized fetch protect) as countermeasure to relative
common length related exploits in standard c programming environments.

for some topic drift ... random past posts about common 360/370 use of
self-modifying instruction paradigm
http://www.garlic.com/~lynn/2001.html#39 Life as a programmer--1960, 1965?
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002h.html#19 PowerPC Mainframe?
http://www.garlic.com/~lynn/2002h.html#21 PowerPC Mainframe

some extended posts about pointer passing paradigm and the evoluation
of dual-address space, multi-address space and access register
operation:
http://www.garlic.com/~lynn/98.html#36 What is MVS/ESA?
http://www.garlic.com/~lynn/2000c.html#84 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#28 RS/6000 vs. System/390 architecture?
http://www.garlic.com/~lynn/2000e.html#58 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001d.html#28 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001d.html#30 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001h.html#73 Most complex instructions
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2001k.html#16 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002g.html#5 Black magic in POWER5
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/2002h.html#21 PowerPC Mainframe
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/2002n.html#74 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#43 cost of crossing kernel/user boundary
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/2003e.html#12 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/2004e.html#41 Infiniband - practicalities for small clusters
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

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

Athlon cache question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Athlon cache question.
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 02 Jan 2005 14:13:08 -0700

the other slightly related access pattern "cache" management is more
associated with (longer term) file access ... although the basic
principle applies to all kinds of caches.

i mentioned having done the disk record access trace (highly
optimized, capable of being used in high-thruput production
environments) ... first for modeling lots of different file behavior
(system file caches, controller caches, disk device caches, etc)
... and then later looking at using the information as part of
standard production system operation
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#79 Athlon cache question

i had also done the implementation for an internal backup/archive
system that was used in a lot of internal locations (especially
in the silicon valley area) ... which went thru a few internal
releases ... and then became available as workstation datasave ...
morphing into adsm and currently tsm
http://www.garlic.com/~lynn/subtopic.html#backup

there have been a couple of infrastructures that attempt to manage the
disk storage space as file cache ... HSM (hierarchical storage
manager), SMS (system managed storage), and ADSM/TSM.

In the vs/repack traces and program re-ordering ... it attempted to
pack things into the same page(s) that tended to be used together
... this frequently would take large, relatively weak working sets and
turn them into much more compact, stronger working sets.

the file storage stuff has coming up with similar constructus ... i
think in TSM they are currently referred to as something like
containers ... collection of files that will tend to be migrated
together ... because the indications are that they tend to be used
together.

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 02 Jan 2005 17:16:14 -0700

"John E. Hadstate" writes:

If you recall, there were two bits for each memory region:
read-enable and write enable.  No-read, No-write meant
no-access.  Write-no-read meant I-fetch-only access if the
processor was in non-privileged state.  It meant read-write
if the processor was in privileged state.

Your Big Blue credentials notwithstanding.  I spent many
nights reading the system architecture documents for S/360,
some of which were intended for distribution only to Field
Service engineers, during the summer of 1970. The
architecture did have support for no-access, read-only,
read-write, and execute only.  Whether the hardware for a
particular model of S/360 supported it depended on other
(sometimes unreasonable) things, such as the presence of
floating point support or a memory expansion option.

You are right about the lack of VM support in S/360.  O/S
360 MFT could have multiple partitions, but the linker did
all the relocation work up front.  However, I believe the
S/360 Model 91 did have virtual memory support.  To be fair,
I believe NASA was the only customer for it and it had
problems and a price tag that made it uninteresting to the
commercial world.  Clemson University had a S/370-155, then
a 165 in 1970 that had virtual memory.  IBM sales tried to
sell me a S/370-110 in 1972 that had virtual memory
hardware.  They were still peddling DOS for it which, by
that time, had virtual memory support grafted on.

Self-modifying application code became an interesting
problem in the 360 Model 91 (was there also a 61) because of
pipelined prefetch.  IBM's official (and documented) answer
was, "Don't do that."  The 360/370 instruction set included
an "Execute" instruction for modifying fields (mostly length
fields) in arbitrary instructions outside the instruction
stream without actually changing the contents of memory
where the modified instruction was fetched from.  (This
presented some interesting problems if the target
instruction crossed a page boundary and one of the pages was
missing.) Thus, while the code could be self-modifying in a
sense, it didn't have to be as bad as it sounds.  Of course,
that's not to say that some people didn't get away with it,
especially on small 360's running DOS or TOS where memory
management was pretty loose.

there might be lots of stuff that could be model specific ...  but
because they weren't in general use ... didn't gain support as part of
the standard programming paradigm.

the original virtual memory on 360 was done on a specially modified
360/40 ... but as far as I know, only one such machine was built. This
was built for the virtual memory/machine project at the science center,
4th floor, 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

The standard virtual memory offering for 360 was the 360/67, which
also supported both 24-bit and 32-bit virtual addressing modes. It
basically was a 360/65 with virtual memory hardware support added (and
in the smp case, other types of stuff). The official corporate virtual
memory operating system for the 360/67 was tss/360. Because of
complexity, performance, and implementation issues, a lot of places
took their 360/67 and used them for other stuff. Some number of places
just ran their 360/67 in straight 360/65 mode with batch operating
system. UofM wrote the Michigan Terminal System (MTS) which some
number of locations ran on 360/67. The majority of the 360/67s
eventually were running the virtual machine/memory system developed at
the science center (the center converted the system from the custom
modified 360/40 to 360/67 when the machine became available) ... or
some commercial derivative of the same ... aka IDC, NCSS, etc for
commerical time-sharing service bureaus, misc. past postings
http://www.garlic.com/~lynn/subtopic.html#timeshare

There are some similarities about the unic/C split off from Multics
and the virtual memory/machine system done by the science center
vis-a-vis the official coporate strategic operating system TSS/360.

The folklore is that the original announced products were 360/60,
360/62 and 360/70 ... all machines with real storage that cycled at
one microsecond. I don't know if any such machines actually shipped.
These machines were quickly replaced with the announcement of the
360/65, 360/67, and 360/75 ... which were the machines upgraded with
real storage that cycled at 750ns.


note/update:

I remember reading an early document about 360/6x machine with virtual
memory having one, two, and four processors. I sort of had vaque
recollection that it was model number other than 360/67.

however, i've subsequently been told that 360/60 was with 2mic memory
and 360/62 was with 1mic memory. both models never shipped, and were
replaced with 360/65 with 750ns memory. the 360/67 then shipped as
360/65 with virtual memory ... only available in one (uniprocessor)
and two processor (multiprocessor) configurations

http://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That


I never heard of 61. There was 91, 92, 95, 360/195 and 370/195.  There
was also a 360/44 ... sort of subset of 360/40 instructions/hardware
with enhanced floating point hardware performance.

I had some involvement with a project that looked at doing a 370/195
that emulated two processor machine ... doing red/black tagging of
registers and instructions in the pipeline. The problem with these
pipeline machines was that a (almost all) branch instruction would
drain the pipeline (no branch prediction &/or speculative
execution). Except for very specialized codes, 370/195 pipeline rarely
got more than half-full before encountering a branch instruction
(resulting it running at something like half the peak rated mip rate).
Simulating two-processor machine with dual i-streams (something like
the modern day hyperthreading support), could have two i-streams, each
keeping the 370/195 i-stream half-full ... which might amount to a
full pipeline.

The execute instruction took another instruction as an argument and
used a parameter from the execute instruction to modify the 2nd byte
in the target instruction. This was the length field in the character
and decimal instructions and the "immediate" field, in the immediate
instructions. The 360/67 required a mimimum of 8 hardware relocate
look-aside registers ... since the worst case minimum instruction
execution could require 8 different addresses:

2; execute instruction crosses a page boundary,
2; target instruction crosses a page boundary,
2; target is "ss" instruction (aka storage to storage) with two
   storage address operands
2; target is "ss" nstruction with both storage operands crossing a
   page boundary (i.e. precalculates both start and end of storage
   operands)
=
8

The maximum possible length of ss-instruction storage operand is
256byte, instruction decode only needed to preresolve the start and
end address (which wouldn't cross more than one page boundary using
either 2k pages or 4k pages). on 360 and most 370 instructions,
instruction decode would resolve both starting and ending operatnd
address ... and test for access permission. If there wasn't access
permission for all storage references (single storage operate for
rs/rx/ri and two in the ss-instruction case) for both the starting and
ending addresses of the resepective storage location, there would be a
hardware interrupt before start of instruction execution.

It might be observed that this may have helped promote software
paradigms that kept track of all lengths ...  since there were no
standard machine instructions that supported implied lengths.

Images of executable code on disk included control information about
address location dependencies in the code. The link/loader would
modify the executable code image after it was brought into storage to
adjust address location dependenies. This loader/link function was
independent of whether you ran PCP, MFT, or MVT. Even in the purely
PCP environment running only a signle application at a time ...  an
application program executable image would be loaded (and the address
dependencies adjusted) ... and then any library program images tended
to get loaded after the application program code. Since the
application program code could be of arbitrary size ... the load
location of library code could be somewhat arbitrary. Quite a few of
the address location dependencies were address constants of subroutine
entry points that tended to be intermixed with code. A specific PCP
release would tend to have a constant starting address for loading
application code ... but things like library code would be loaded at
somewhat arbitrary locations (dependent on the size of the application
being run). MFT (& MVT) could have multiple different addresses
for starting the load of application code (but the link/loader already
had to default for arbritrary address adjustments because of the
generalize issue of loading library code). This is characteristic
somewhat orthogonal to having a pointer passing paradigm vis-a-vis
possibly value passing paradigm, whether standard programming model
allowed for execute only, read only, no execute, etc. however, for
lots of postings on the address dependency problem with shared, r/o
code (in 360/370 architecture):
http://www.garlic.com/~lynn/subtopic.html#adcon

The first engineering 370 with virtual memory support was the 370/145.
The standard front panel of all 370/145s had a light labeled XLATE
(long before virtual memory was announced for the 370). There was lots
of customer speculation that "XLATE" stuod for translate-mode (aka
address relocation support virtual address spaces).

This machine was used to port the virtual machine/memory operating
system done by the science center from 360/67 to 370 (there was some
number of differences between the 360/67 and 370 virtual memory
architecture, including the 370 architecture only supported 24-bit
address mode and didn't support 32-bit address mode). The initial
prototype of the standard corporate batch operating system involved
taking a straight forward MVT operating system ... and crafting a
small virtual address space layer .... quite a bit of it from bits
& pieces from the science center operating system. For the most
part the existing MVT operating system code ... continued to operate
as if it was running on a real storage machine that happened to have
16mbytes of memory.

Actually, the science center had a joint project with the endicott
engineers responsible for the 370/145 virtual memory hardware. The
standard 360/370 hardware reference manual is called the principle of
operations ... which has detailed description and operation of
instructions had infrastructure for 360/370. It has traditional been
(since the late '60s) a machine readable file that is part of
something called the architecture manual "red-book" (because it was
traditional distributed in a red 3ring binder). The file could be
printed/formated under command control as the full architecture manual
... or as the publicly available principle of operation subset (with
conditional formating controls). The full architecture manual tended
to have lots of engineering notes, justifications for the instruction
or feature, and various trade-off discussions ... like why some things
might be feasable with a specific hardware technology ... but not
possible as part of the official 360/370 architecture (because it
possibly wasn't practical across all hardware technology used in the
various different processor models). In any case, special operating
system software was crafted to emulate the full virtual memory 370
architecture ... running on a 360/67. The result was 370 virtual
machines that could be used for testing (even tho the 360/67 and 370
virtual memory architecture had numerous differences). This project
had virtual 370 machines up and running production a year before the
first engineering virtual memory 370 machine was operational.

principle of operations is a generally available customer manual
(current versions for 390 and Z series have been available online)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/CCONTENTS?SHELF=EZ2HW125&DN=SA22-7201-04&DT=19970613131822

it is unlikely the architecture red-book version was available in the
field.

for specific models, you could also get the functional characteristic
manual. Some number of the 360 functional characteristics manuals have
been scanned and made available online:
http://bitsavers.org/pdf/ibm/360/

including 40, 44, 65, 67, 91, 195, etc, the 360 functional
characteristic manauals tended to included detailed model specific
things like instruction timings. numerous other early hardware and
software manuals have also been scanned and are online

For each specific machine, FEs would also have detailed wiring and
microcode implementation manuals ... typically located in the machine
room near the machine. Specific machine models might have implementation
for stuff not prescribed by 360/370 architecture

at the above site, there are (at least) "-0", "-6", and "-7" of the
principle of operations manual. Page 17 has short description of
"protection features" ...which might be available on a 360 machine,
one is store protection feature and the other is fetch protection
feature. I believe for OS/MFT (OS/MVT, and later) the only required
feature was store protect (I don't believe the operating system and/or
any other software required fetch protection feature to be available
for operation).

Prior to MFT (and then MVT) requiring store protect feature, it was
possible for applications to stomp on low-storage and do things like
enter privilege/supervisor state ... possibly an exploit, but also a
mechanism used by some number of regular application ... like hasp
... some number of past hasp postings
http://www.garlic.com/~lynn/subtopic.html#hasp

Note, it doesn't mention execute-only as any standard 360 feature.
However 360 architecture wouldn't preclude the 360/40 engineers from
implementing such a feature ... it just wasn't part of 360 (and
wouldn't likely be used by any standard programming paradigm).
360/40s typically had other stuff that weren't part of 360 ... like
microcode for hardware emulation of 1401/1410/etc ... as an
alternative to the micrcode engine emulating 360 instructions
... typically controlled by some switch on the front panel ... a
picture of real 1401:
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH2044.html

picture of 360/40 (there should be some sort of switch on the front
panel ... probably lower center cluster that could select between 360
instruction microcode or 1401 instruction microcode operation of the
machine):
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH2040.html

a picture of similar 360/44 used for floating point/scientific workloads:
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH2044.html

the following reference has some amount material about the evolution
of CTSS to multics ... project mac choosing the GE machine instead of
the ibm 360/67 hardware, and various and sundry tidbits about tss/360
... but mostly about the virtual memory/machine operating system
developed by the science center (initially on a custom modified 360/40
with virtual memory and later converted to standard 360/67 product
line machine)
http://www.princeton.edu/~melinda/

The "low-end" 370 was the 115/125 models developed by Boeblingon.
Except for a few exceptions, the 360 and 370 machines were microcoded
implementations. On the low & mid-range 370s ... the native
processor engine typically executed an avg. of 10 instructions for
every 370 instruction. The 115/125 hardware implementation used a 9
position, shared memory buse ... which could have microprocessor
engines installed. One microprocessor would have microcode loaded for 370
instruction set and the other (typically) 3-8 microprocessor
engines would have other microcode installed to handle various control
and I/O functions. In the 115 all the microprocessors were identical
(except for the microcode load). The 125 was identical to a 115 except
the microprocessor engine that had the 370 microcode load was approx.
25% faster than the other engines. The 115 was rated at about 80KIPS
370 (requiring a native processor engine of about 800KIPS) and the 125
was rated at about 100KIPS 370 (requiring a native processor engine of
about 1MIPS).

a site listing most of the 360 and 370 models with original announce
data as well as first customer ship (including 360/60, 360/62, 360/70
announce dates):
http://www.isham-research.com/chrono.html

per above reference, 370/165 (w/o virtual memory) was announced June,
1970 and first customer ship of a machine was spring of 1971.

and for some clemson related topic drift:
http://www.cs.clemson.edu/~mark/fs.html
misc. other clemson references that somebody might find of interest:
http://www.cs.clemson.edu/~mark/acs_technical.html
http://www.cs.clemson.edu/~mark/acs_timeline.html

also per above, misc 370 announce & ship dates: 370/125 ANN 10/72,
first ship, spring 73; 370/115 ANN 3/73, first ship spring 74.

370 virtual storage was announced 8/72 and immediately available on
370/135 and 370/145 with new microcode load .. but required purchase
of field installable hardware to add virtual memory to 370/155 and
370/165. Operating systems were dos/vs (virtual storage version of
dos), vs1 (somewhat virtual storage version of mft), and vs2 (virtual
storage version of mvt).

There was some argument with the 360/165 engineers about implementing
the full 370 virtual memory architecture (as per the "red-book"); they
claimed it would add six month delay to the schedule to include
support for selective invalidate as well as segment r/o protect. They
won since it was more important to get virtual storage announced and
in the field than to make sure that all features of the architecture
were included (the excluded features then had to be removed from the
135 & 145 implementations that already existed).

minor summary

 8/70  370/165 announced
2q/71  370/165 FCS .. first customer ship
 8/72  virtual memory/storage announced
10/72  370/125 announced
 3/73  370/115 announced
2q/73  370/125 FCS
2q/74  370/115 FCS

short description of 360 & 370 machine models:
http://www.beagle-ears.com/lars/engineer/comphist/model360.htm

30 year history of MTS:
http://www.clock.org/~jss/work/mts/30years.html

random past references to 370/195 dual i-stream project:
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing

random past references to UofM MTS (virtual memory operating system
built for the 360/67 and later ported to 370 virtual memory)
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#44 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000f.html#52 TSS ancient history, was X86 ultimate CISC?  designs)
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000.html#91 Ux's good points.
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#45 Valid reference on lunar mission data being unreadable?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
http://www.garlic.com/~lynn/2003j.html#54 June 23, 1969: IBM "unbundles" software
http://www.garlic.com/~lynn/2003k.html#5 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#41 Secure OS Thoughts
http://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
http://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#46 DE-skilling was Re: ServerPak Install via QuickLoad Product
http://www.garlic.com/~lynn/2004.html#47 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004l.html#16 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#25 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#34 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 02 Jan 2005 19:17:57 -0700

Anne & Lynn Wheeler writes:

for specific models, you could also get the functional specification
manual. Some number of the 360 functional characteristics manuals have
been scanned and made available online:
http://bitsavers.org/pdf/ibm/360/

oh and this is the 370 principle of operations ... after virtual
storage was announced ... and it includes a little more detailed
description of the storage key-based protection mechanism ...
as well as stuff added to the storage keys for virtual memory
operation (pg. 38) ... and is nominally defined to be upward
compatible with 360.
http://www.bitsavers.org/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf

The psw status storage protection is privilege status ... it can have
a value between 0&15 (zero meaning matches everything). If the value
in the psw is non-zero and doesn't match the 4bit value in the
"storage key" (one for each 2k block of real memory) then there is a
storage protection exception.

for 370 there are 7 bits (of logical 8bit byte) defined (see
pge. 38 in the above referenced document):

bit(s)
0-3        protection key value
4          fetch protection flag
5          storage reference bit
6          storage change bit
7          unused

bits 5&6 are status bits added for 370 so that the hardware can
record if the associated 2k block of memory has ever been referenced
and/or changed. normal programming operation is to test the bits
and then reset the storage key value with zeros for bit 5
(and possibly bit 6).

standard 360 only had (privilege mode) insert storage key (ISK) and
set storage key (SSK) operations (which is how the page replacement
algorithm on 360/67 interegated the reference bit). for 370, a new
instructiuon, reset reference bit (RRB) ... the instruction condition
code indicated the reference bit value before it was cleared to zero.

standard 360 (& 370) store protect was implied by a non-zero key in
the psw and a mismatch between the PSW key and the storage key for a
2k block of storage. there was no separate bit that specified store
protection. Setting the fetch protect flag resulted in both fetches
and stores being checked for a mismatch between the 4bit PSW key and
the 4kbit storage protection key (for 2k range of storage). the
description on pg. 38 in the above referenced principle of operations
specifically says that with fetch protection flag is set ... fetch
protection is applied to all storage fetches ... both instruction and
instruction operands (w/o regard to the type of fetch).

there is no provision (at least in the standard 360/370 architecture
implementation) for execute-only fetch operation (i.e. allow
instruction fetches but disallow instruction operand fetches) because
there is only a single bit used .... the fetch protection bit

• when the fetch protect bit is zero there is only store protect
checks when there is a non-zero PSW key and a mismatch between the PSW
key and the storage key for the 2k block of storage.

• when the fetch protect bit is one there is both store protect checks
and fetch protect checks when there is a non-zero PSW key and a
mismatch between the PSW key and the storag ekey for the 2k block of
storage (and as specified, fetch protection is applied equally to
instruction fetches as well as instruction operation fetches).

In most of the 360s & 370s .. the storage key array could have an 8bit
byte for each 2k block of real memory. In the vanilla 360 case, that
might result in their being 3 unused bits for every storage key
(although in 360 time-frame, it might just be as likely to have
implemented only the five bits per 2k real memory ... and if the
feature wasn't installed the storage key array wouldn't exist at all
on the machine ... and ISK/SSK instructions would just be null
operations).

The 360/67 used the 7bit storage key array defined in 370 ... aka a
4bit protection key value, a fetch protection flag, a storage
reference bit and a storage change bit.

I have no knowledge of any possible "under the covers" support in the
storage protection feature implementation on the 360/40 that could
have used an extra bit in the storage key array to be able to specify
execute-only (aka allow instruction storage fetch ... but preclude
instruction operand storage fetch). I never tripped across any
definition of any 360 or 370 documents that happen to mention it.

Given the description of separate fetch and store protection
"features" on 360 ... it is possible that if the fetch protection
wasn't installed ... there would only be 4bit key for each 2k storage
block in the storage key array ... and the only support check for
storage protection violation on stores (with no hardware or microcode
added to check for storage protection violations on fetches).

note that in the 360 principle of operations manual (referenced in the
previous posting) description that starts on pg.17 and carries over to
pg.18 ... specifically describes setting store protect (i.e. fetch
protect bit is zero) or setting "fetch-and-store" protect (i.e.
setting the fetch protect bit to one). There is no additional flag bit
defined (at least in the 360 principle of operations) ... supporting
an 3rd state/condition ... allow instruction fetch but disallow
instruction operand fetch.

for some topic drift ... a couple recent posts on cache replacement
algorithms:
http://www.garlic.com/~lynn/2004q.html#18 PR/SM Dynamic Time Slice calculation
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/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#77 Athlon cache question

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

How do you say "gnus"?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How do you say "gnus"?
Newsgroups: gnu.emacs.gnus,alt.folklore.computers
Date: Sun, 02 Jan 2005 19:51:54 -0700

David Sumbler writes:

Now for the trivial question: how do you say "Gnus"?  Is it pronounced
like "News", or do the cognoscienti pronounce it in some other way?

i always pronounced it ga-news ... similarly to having pronounced
gnosis as ga-nosis ... and later gnu as ga-new (g wasn't silent)
http://www.gnu.org/

gnosis was/is "great new operating system in (the) sky"
(capability-based operating system) done by tymshare in the late 70s
and early 80s ... before M/D bought them and spun-off tymnet to
british telecom and gnosis to a startup called key logic and renamed
keykos. in that time-frame, i tended to have regularly monthly
meetings with some of the tymshare people (in part because they had a
vm/370-based time-sharing service) ... and was brought in by M/D to do
gnosis technical audit for the spin-off.

keykos/gnosis somewhat was reborn as eros on intel architecture
... and is being touted as operating system designed to get an CC/EAL7
evaluation:
http://www.eros-os.org/

and keykos
http://www.cis.upenn.edu/~KeyKOS/

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Tue, 04 Jan 2005 17:30:29 -0700

and for even more on microcode, languages, etc lore

multics was on 5th floor of 545 tech sq ... and had implemented it in
PLI ... and relatively recent study claimed that there had been no
instances of buffer overrun in multics.

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

and the boston programming center was on the 3rd floor. the boston
programming center was responsible for something called CPS
(conversational programming system ... that supported interactive PLI
and BASIC ... running under various flavors of os/360. BPC had done a
microcode package for the 360/50 that allowd CPS to run significant
faster than with standard 360 instruction set (I don't have details on
what was in the microcode package, but I believed it got most of its
speed up from specifialized hardware string processing instructions).

when the development group split off from the science center ...  they
eventually expanded and took-over the 3flr and much of BPC people. A
couple people that they didn't pick up, like Nat Rochester and Jeen
Sammet ... eventually moved up to 4th floor science center.

could use search engine on "programming languages" and "Sammet".

in the early '70s, the science center ported apl\360 to cms\apl
... from a 16k-32k byte real memory environment to a 8m-16mbyte
virtual memory environment. one of the things that had to be done as
part of that effort was to redo the storage manager for a virtual
memory environment. apl & list share some of the same characteristics
that pointers and storage allocation are underneath the covers
(somewhat analogous to java).

when i transferred from science center to SJR in the late '70s ... i
got an office about 8-10 doors down from John Backus. search engine
could be used on "backus" and "fortran".

at that time, sjr was still running 370/195 with mvt (one of the last
before the conversion of batch operating system to virtual
memory). Numerous people were complaining that job stream backlog on
370/195 was 3 months. palo alto science center eventually added some
checkpointing on one of their jobs that they were getting 3mth
turn-around and ran it in the background and offshift on their
370/145.  They claimed to have gotten slightly bettern than 3mth turn
around using that mechanism.

another job that was getting long turn around was the air bearing
simulation work. work was going on with regard to "flying" disk heads
and the air bearing simulation was critical part of finding out how to
keep the heads off the surface.

we had done some operating system assurance work in bldgs. 14&15 that
enabled them to do their disk development testing in operating system
environment including being able to concurrently test multiple devices
(they had been doing stand-alone testing with one device at a time on
schedule program .... because running with an operating system had
been 15 minutes MTBF). Because of critical nature of disk testing, the
engineering &/or product test labs would frequently get engineering
model #3 (cpu engineers got the first two enginnering cpus and disk
enginneering got the 3rd).
http://www.garlic.com/~lynn/subtopic.html#disk

Any case, in that time-frame, bldg. 15 got something like engineering
model #3 of 3033.  For very specialized codes, you could get sustained
peak thruput on 370/195, but most stuff ran about half of peak (about
the same as 3033). bldg. 15 was happy that they were able to get 4-6
engineering devices concurrently ... w/o having to resort to
scheduling dedicated, stand-alone machine time ... even if it only
used 2-3 percent of the 3033 cpu. So, in general the machine was
essentially idle (from CPU standpoint) and we managed to move the air
bearing simulator from the 370/195 in bldg. 28 (with backlogs listed
in weeks/months) to the 3033 in bldg. 15 (with effectively immediate
access ... but only for our good friends).

random drift ... other stuff at sjr was original rdbms work ... random
past posts
http://www.garlic.com/~lynn/subtopic.html#systemr

random past posts mentioning Jean Sammet:
http://www.garlic.com/~lynn/2000d.html#37 S/360 development burnout?
http://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002j.html#17 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002o.html#76 (old) list of (old) books
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2003c.html#0 Wanted: Weird Programming Language
http://www.garlic.com/~lynn/2003c.html#1 Wanted: Weird Programming Language
http://www.garlic.com/~lynn/2003k.html#55 S/360 IPL from 7 track tape
http://www.garlic.com/~lynn/2004d.html#42 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004.html#20 BASIC Language History?
http://www.garlic.com/~lynn/2004m.html#54 Shipwrecks

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

OSI - TCP/IP Relationships

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OSI - TCP/IP Relationships
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 05 Jan 2005 13:35:49 -0700

firadat writes:

Firstly - "Does TCP/IP inherit anything from OSI" and the next question
is "Is it valid to say that OSI was the basis of TCP/IP existance"

OSI has a very point-to-point copper wire network orientation ... many
claimed it reflects the viewpoint of telco people.

in the late 80s, there was an attempt to get work item on HSP (high
speed protocol) introduced in x3s3.3 (iso chartered body for network &
transport layer standards). ISO had compounded the problem of the
severe OSI limitions by directives that no standards work could go on
for anything that didn't conform to the OSI model.

HSP would go directly from the transport layer to the MAC interface
(with internetworking support) and therefor violated the OSI model
because

it bypassed the layer 3/4 interface, violating the OSI model
it supported internetworking (aka IP, which doesn't exist in the
OSI model) and therefor violated the OSI model
it interfaced to the LAN/MAC interface. LAN/MAC interface violates
the OSI model ... being an interface that sits somewhere in the middle
of layer3/networking .... and therefor anything interfacing to the
LAN/MAC interface also violates the OSI model.

random other posts on the subject:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

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

The Soul of Barb's New Machine

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Soul of Barb's New Machine
Newsgroups: alt.folklore.computers
Date: Wed, 05 Jan 2005 14:19:25 -0700

"David Wade" writes:

Personally I think IBM has killed VM in its current incarnation,
I thought SP6 and fullscreen CMS was dire, but with all the gunge on
a modern system it seems like "bloatware" to me!

there was frequently an ongoing battle between architecture purity and
consistency and people from traditional operating system background
who were in the habit of adding anything to the system with any thot
to the architecture consequences.

for a long time it seemed trivially easy to add stuff because there
had been so much work on preserving architecture simplicity and purity
... but as more and more people crafted traditional operating system
warts on the infrastructure with little or no regard to KISS &
architecture ... it started to loose some of the very characteristic
that made it so easy to modify (they modified because it was so easy
to modify ... and with enuf modifications .... it can totally corrupt
its original architecture consistency ... and at some point it starts
to look like just another operating system).

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

CAS and LL/SC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CAS and LL/SC
Newsgroups: comp.arch
Date: Wed, 05 Jan 2005 14:33:09 -0700

Del Cecchi writes:

Just to throw some gasoline on the fire, now that it is the new
year, isn't a parallel Systplex of Z series e-servers (formerly
known as 390) a cluster?  Does it use message passing?

my wife did her stint in POK in charge of loosely coupled architecture
(she and the person responsible for tightly coupled architecture
reported to the same person). she specified a lot of the architecture
at that time .... but almost all of the focus was on building bigger
and faster SMPs.

she claimed that at the time, one of the few operations that paid any
attention was the group doing IMS hot-standby. she lost some number of
battles like trotter to try and turn it into a really efficient
message passing operation. there was a story from SJR using a modified
trotter with a broadcast protocol to syncronize eight loosely-coupled
complexes taking subsecond time ... but when forced to a half-duplex
LU6.2 protocol, it took on the order of a minute or two to achieve the
same syncronization of the complex.

random past post related to my wife's stint in POK and her
peer-coupled shared data architecture
http://www.garlic.com/~lynn/subtopic.html#shareddata

we subsequently did a project that turned out ha/cmp ... lots of past
references
http://www.garlic.com/~lynn/subtopic.html#hacmp

a specific reference from the project
http://www.garlic.com/~lynn/95.html#13

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

The Soul of Barb's New Machine

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Soul of Barb's New Machine
Newsgroups: alt.folklore.computers
Date: Wed, 05 Jan 2005 14:50:33 -0700

there is some claim, some place ... that KISS can be much, much
harder than complex.

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

Amusing acronym

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amusing acronym
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 05 Jan 2005 16:52:35 -0700

patrick.okeefe@ibm-main.lst (Patrick O'Keefe) writes:

Sarcasm.  "I've been moved", like almost all other "meanings" does not
reflect well on IBM.  It's something IBM would not want associated with
its initials.  To make matters worse, it was a true attribute.

during the '60s & '70s was period of very rapid growth for IBM ...
and experienced people in the sales, marketing, & field support
were sometimes spread pretty thin. sometimes as soon as anybody gained
any experience they were rotated to a new location. when i was an
undergraudate ... tqhere was a period where it seemed the university
got a new system engineer or two every six months ... and as soon as
we started to get them trained ... they were rotated someplace else
and we got system engineers.

i was helping with HONE during the 70s and into the 80s. It was the
online infrastructure for sales and marketing (and sales/marketing
support). In the late '70s, HONE US was consolidated at a single site
in Cal. ... and it was pushing 40,000 userids (a couple years later as
we got loosely-coupled working better, it was replicated with a second
site in Dallas and then a third site in Boulder for availability
.... basically triple redundant on the possibility that something like
an earthquake might take out the cal. site).

In the early 70s when EMEA hdqtrs was moved from the US to La Defense
(outside of paris) ... i handled the cloning of HONE to the new site.
Eventually there were a large number of clones of the HONE US site (of
various sizes and shapes) around the world (some that I got to
handle).

i think that there was much less of a moving issue with people in
research, development, manufacturing, etc .... it was the sales,
marketing and other field people where they were constantly being
moved around to try a get customer coverage.

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

sligthly related post from another n.g.
http://www.garlic.com/~lynn/2005.html#11 CAS and LL/SC

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

Using smart cards for signing and authorization in applets

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Using smart cards for signing and authorization in applets
Newsgroups: alt.technology.smartcards
Date: Thu, 06 Jan 2005 08:28:29 -0700

mac@theoffice.net (Mac) writes:

First my apologies if my question has been already replied.

I'm new to smart cards and I need some help to understand this
technology.

What we´re planning to do is:
- let our clients to fill html forms, sign data with a smart card
and send back signed data.
- let clients authenticate via Web using smart cards.

For the time being this is only a plan, but we'd like to have an
idea of how difficult it is to build this on java.

Is there any java sample code that makes this tasks? which card
reader would fit best our needs?

Thanks a lot for your help, and sorry if my questions are to
general.

basically from 3-factor authentication paradigm

• something you know (like pin/password)
• something you have (like smartcard or hardware token)
• something you are (aka biometrics)

w/o any additional infrastructure ... a smartcard represents
something you have authentcation ... the private key
is certified as only existing in a specific hardware token,
so a relying party, when validating a digital signature
with the corresponding public key, can assume that it originated
from a specific hardware token (aka something you have
authentication)

w/o the additional infrastructure ... something you have
authentcation doesn't directly represent "signing" or "authorization"
as in "human signing" which includes the demonstration of some sort of
intent, agrees, approves, and/or authorizes.

there has possibly been some comfusion generated by the use of the
term "digital signature" ... with public/private key technology
that is used for authentication and message integrity. Encrypting
a hash of a message with a private key (for later validation with
the corresponding public key) is orthogonal and independent of the
things referred to as digital certificates ... various postings
on certificate-less public/private key operation
http://www.garlic.com/~lynn/subpubkey.html#certless

... or for that matter, independent of human signatures that imply
intent, consent, approval, etc. It is possible to use digital
signatures (with or w/o digital certificates) as part of an
infrastructure to establish human intent ... but a digital signature
by itself only establishes authentcation and message integrity.

There is even the possibility of dual-use (digital signature)
compromise ... where the same public/private key pair is used for both
authentcation infrastructures as well as authorization
infrastructures.

Numerous public key authentication infrastructures (use of private key
to create a digital signature) are implemeted as challenge/response
system; the server transmits a random challenge, the private key is
used to digitally sign the random data and the digital signature is
returned.

A human signature infrastructure implies that the human has read,
understood, agrees, approves, and/or authorizes the content before it
is digitally signed (and to repeat, digitally signing can occur in a
certificate-based or a certificate-less-based infrastructure).
The issue with dual-use compromise, is can an attacker ever transmit
supposedly random data in a challenge/response authentication-only
scenario ... where the random data actually looks like valid
transaction (that might be found in a authorization paradigm). The key
owner signs something that they believe to be random data (as part
authentication infrastructure) which turns out to be some sort of
transaction.

The problem is that an authorization infrastructure may have
absolutely no control over additional uses that somebody puts their
public/private key pair ... and in theory, may be defenseless against a
dual-use attack. The key owner may choose to defend themselves against
dual-use attack by possibly

always modify a random challenge message before signing with some
additional disclaimer that reads something to the effect that the
associated digital signature in no way implies any kind of intent,
consent, agrees, approves, and/or authorizes the contents of
what is being digital signed.

The issue is that if the key owner isn't meticulously about the use of
their public/private key ... it puts any authorization/approval
infrastructure at risk ... and the risk occurs outside of anything
that the authorization/approval infrastructure may have control over.

misc. past posts related to dual-use compromise:
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm17.htm#50 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards

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

Amusing acronym

From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: 7 Jan 2005 11:36:45 -0800
Subject: Re: Amusing acronym

Dave Hansen wrote:

As a freshman, my college roommate and I were kicking around some
ideas for a base-3 computer (who wasn't? kind of a fun exercise).
We called it a "trinary" system, and the digits
"trits". Unfortuately, "trinary" isn't really a word...

mildly related ... 3-value logic posts
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
http://www.garlic.com/~lynn/2004f.html#2 Quote of the Week
http://www.garlic.com/~lynn/2004l.html#75 NULL

Amusing acronym

From: lynnr@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: 8 Jan 2005 09:03:32 -0800
Subject: Re: Amusing acronym

Joe Morris wrote:

...and the original name survived as the infix of the product number
for PL/I under OS/360: 360S-NL-511. I never had a reason to poke
around in the source for the compiler (yes, IBM distributed the
full source to its systems back then -- and didn't even bother to
copyright it!) to see if there were any comments referencing the
original name.

i have vague memories of ibm coming by the university and demonstrated
a new (not yet available) programming language that was going to be
called soemthing (pli). they loaded the libraries on our system and ran
some number of the demos. at the end of the week they scratched all the
files.

they came back later to investigate the datacenter backup process and
the probability that the drive with the temporarily loaded libraries
had been backed up during the period. there was some issue about who
had rights to any possible backup tapes (if there happened to be
backup tapes)

Amusing acronym

From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: 8 Jan 2005 14:05:12 -0800
Subject: Re: Amusing acronym

Lee Witten wrote:

Anyhow, I was an IBM employee back in 1990 or so, and I was bemused
at the celebration in the KGN cafeteria. Linen tablecloths, prime
rib being served for free, a live ragtime band in the corner. I
wondered what the big fuss was all about. I was told that it had to
do with two instructions being added to the mainframe instruction
set, something to do with block move of data to/from extended store
using a single instruction. Thus were the joys of an IBM employee,
before the first ever IBM layoff!

Also, in an earlier incarnation, I met both Lynn and Anne Wheeler!

extended store move would be early 80s for trout/3090.

what was explained to me was that given the packaging ... and the
amount of electronic memory ... that the physically distance from the
processor exceeded some lactency limitation. so the memory was
repackaged as near memory with expected processor memory bus .... and
far memory (called extended store) on a special, wide bus. they
analyzed that they could do a synchronous bus move from far memory to
near memory in much fewer cycles that any asynchronous i/o paradigm
would take (say using any sort of electronic device I/O paradigm). you
could either look at it as sort of a software managed cache mechanism
.... or an electronic paging device using synchronous transfer
operation.

later the extended store bus was used to bolt HiPPI support on to the
side of 3090. 800mbytes/sec was to high instantaneous transfer for
regular i/o interface. HiPPI commands were done by moving stuff to
custom address on the extended store bus (sort of a poke paradigm).

note that regular i/o could only be done to/from regular memory. if
there was something in extended store that needed to be used in
regular i/o ... it first had to be moved to regular memory.

... for some topic drift ... one of the big annual corp. conferences
was once held at some place in peachtree plaza in atlanta (shortly
after it was built). there was big dinner in ballroom .... very large
number of big round tables (seating for 10-12/table, white table
cloths, etc). Only drink on the tables were water glasses. At least
one table slipped a waiter some money and had the their water glasses
filled with vodka.

... ok, and for some even more drift. At one of the Asilomar SIGOPS
meetings, one of the dinners had a special treat ... provided by the
people doing Ridge(?) wineries ... their first year of wine
production.  Also round tables with 8-10 people/table (also big white
table cloths).  The waiters were instructed(?) to bring a bottle to
each table and then bring another bottle when that bottle was empty
... and keep it up until the table had three empty bottles. One table
figured out the algorithm and kept putting the empty bottles (except
the 1st) under the table. Apparently when dinner was over and people
had left ... there were a dozen empty bottles under that table.

IBM, UNIVAC/SPERRY, BURROUGHS, and friends. Compare?

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 8 Jan 2005 17:25:55 -0800
Subject: Re: IBM, UNIVAC/SPERRY, BURROUGHS, and friends. Compare?

John Savard wrote:

JCL is absolutely appalling, from what I've heard.

Basically, the problem is that to run a program takes multiple
command lines; what, in UNIX, would be

program < file1 > file2

takes one line for the "< file1", another line for the "> file2",
and then another line for "program" - in which you state how much
memory you wish to reserve for the program. This can be mitigated
through something called "compiled procedures"; basically, a batch
file can be set up for each program one wishes to make it not
insanely inconvenient to use.

The environment I am accustomed to in the mainframe world is IBM
hardware with the *Michigan Terminal System* running on it.

some of the JCL issue has to do w/interactive vis-a-vis batch
... where the batch assumptions for the executable package was that
there was no human/knowledgable resource available during the
(extremely expensive) actual execution. lots of upfront resource
specification in some detail (somewhat less simple guessing and what
the heck, if its wrong ... no problem, ju st run it
again). Furthermore, individual executable packages could be expected
to use nearly all available resources on regular basis (real stroage,
cpu, disk space, etc).

some production shell scripts get quite complex trying to address some
of the issues about problems that might show up at runtime ...in. and
little expectation that the possible humans actually present aren't
likely to provide much help.

schell scripts can get quite verbose and wordy trying to address some
of the automated handling of various possible anticipated problems.

another part of JCL issue could be considered trying toal pack a whole
lot of specification into relatively compact form (preferably less
than 72 chars)

Changing the design point to interactive, responsible human present,
executable is inexpensive and typically small precentage of available
resources .... then there is a lot more latitude in letting the human
handle issues in real time (if they come up at all; rather than trying
to anticipate all possible issues).

Both CP67/CMS and MTS were built in the 60s for, and ran on mainframe
360/67. Both had human interactive design point. Both heavily utilized
major software packages from the os/360 batch infrastructure and both
provided os360-emulation software to enable execution of these
packages. Both provided wrapper software that defaulted lots of
expected os360 batch oriented-options ... to avoid forcing the
end-user to repeatedly specify such default information.

one possible batch design point was that weekly payroll had to
complete succesffully week-after-week.

in the early 90s, I had a weekly application running in an unix
environment (which was similar to many business &/or payroll
applications ... but w/o nearly the business critical
requirements). it did sort on people database, did some process on
each person, and then output some information on per person basis.

one week, the sort working file filled the available disk space. but
the disk-full condition didn't preculate up to the sort application.
when sort was completed, it spit out about 15percent of the total
people ... again with no error indication. Processing continued and
eventually the final per-person report was completed ... again with
absolutely no error indication.

if you have tens (or possibly hundreds) of thousand of people
expecting their check every week ... and such problems frequently
happened and went undetected (at least until the irate calls started
coming in) ....  there would start to be some higher level
expectations.

The Soul of Barb's New Machine (was Re: creat)

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 8 Jan 2005 17:36:43 -0800
Subject: Re: The Soul of Barb's New Machine (was Re: creat)

Walter Bushell wrote:

Isn't that exactly one of the innovations in the new Intel chips,
multiple simultaneous threads on one cpu?

technology innovations ... or change for new Intel chips.

in the mid-70s (30+ years ago), there was dual i-stream project, taking
a single processor 370/195 adding just the hardware for a second
instruction-stream and a second-set of registers (w/o adding any
additional executable units).

past dual i-stream 370/195 posts:
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns

I told you ... everybody is going to Dalian,China

From: lynn@garlic.com
Newsgroups: alt.politics.org.cia, sci.crypt, alt.2600, alt.security, alt.folklore.computers
Date: 9 Jan 2005 11:16:51 -0800
Subject: Re: I told you ... everybody is going to Dalian,China ....

SecQrilious wrote:

I told you ... everybody is going to Dalian,China ....
....
High costs threaten valley's competitive edge
The state budget crisis could make Silicon Valley an even more
expensive place to do business as taxes rise and services are cut --
jeopardizing any economic recovery -- according to members of a
business and government regional group.
By David A. Sylvester / Mercury News

some ten plus years we were making a number of visits to far east,
marketing ha/cmp ... and I remember reading an article in hong kong
paper about india being much more competitive at high tech outsourcing
(compared to what was aggressively being pushed in the province across
from hong kong). supposedly the skill base and price/wage were
competitive .... but that india had much more reliable and dependable
services infrastructure (phones, communication, water, electricity,
etc) ... also in indian comparison, it didn't require months &
months delay and numerous payments to get even basic new services
installed.

all the outsourcing stuff was far advanced over ten years ago. towards
the end of the 90s the pace of outsourcing picked up because of huge
demands created by the internet bubble coupled with significant
resources needed to address y2k remediation efforts .... a lot of
people may not have payed much attention at the time ... possibly
because of the total amount of churn going on.

the completion of the y2k remediation efforts happened about the same
time as the bursting of the internet bubble ... however, all the
business relationships and connections that had been built up during
the 90s weren't going to simply then evaporate.

about the same time as the mentioned hong kong article (ten-plus years
ago), cal. papers were carrying articles that at least half of the
high-tech advanced degree graduates from cal. univ were foreigners.
There was some speculation that the long term, huge influx of
foreigners in the high-tech industries was what help kept them going.
There was some speculation tho about what conditions might result in
the heavy foreign makeup of the US hightech workforce returning to
their home countries (aka not just limited to straighforward
outsourcing, but acutally shifting where fundamental hightech work
went on). again, this is all from over ten years ago.

The Soul of Barb's New Machine (was Re: creat)

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 10 Jan 2005 13:06:01 -0800
Subject: Re: The Soul of Barb's New Machine (was Re: creat)

Bernd Felsche wrote:

And it still requires arbitration of some sort to resolve contention
in case of coincident requests to attach a particular resource to
two or more threads. The easiest way to do that is via a hardware
"test-and-set" instruction operating on memory; with cache-coherence
ensuring that all processors have an identical view of the
arbitration space. The cache-coherence hardware must directly
support test-and-set (or similar) as a special case because it has
to happen in a single machine cycle.
--

oops, not exactly.

360/67 had test&set instruction and no caches.

charlie, while working on fine-grain locking in cp/67 smp kernel at the
science center, invented compare&swap. The selection of the
compare&swap mnemonic was a slight issue ... because the objective was
coming up with something that was charlie's initials, CAS. neither
test&set nor compare&swap are likely to ever be a single machine cycle
operation since it involves a fetch followed by (at least) a
(conditional) store operation. what it does have to do is serialize all
proceessors so that the instruction is atomic (given the combined fetch
and store characteristic, it is likely to be multiple machine cycles
... during which all processors may be serialized).

compare&swap was added to 370 ... with a little work. The 370
architecture owners (padegs & smith) came batch that it was unlikely
to be able to justify an SMP-only instruction. in order to get it
justified for 370, a non-SMP justification was (also) needed. This was
where the use description for multithreaded of (enabled for
interrupts) application code originated. Multithreaded application
code that was enabled for interrupts could safely update certain kinds
of structures (whether running in uniprocessor or multiprocessor
environment) because the instruction was atomic (would be interrupted
in the middle with interrupt and possibly resume execution of the
application in a different thread). As part of the inclusion of
compare&swap instruction in 370, it was expanded to be both
single-word and double-word compare&swap instruction.

originally, the description of the possible uses appeared as
"programming notes" in the 370 principle of operation ... packaged as
part of the instruction description. In some later version of
principle of operation, the description was moved to the appendix.

misc. science center, 545 tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech
misc. smp, compare&swap, etc
http://www.garlic.com/~lynn/subtopic.html#smp

comapre&swap instruction from esa/390 principle of operation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.22?SHELF=EZ2HW125&DT=19970613131822

compare double and swap instruction from esa/390 princole of operation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.23?SHELF=EZ2HW125&DT=19970613131822

appendix a.6 from esa/390 principle of operation; multiprogramming (aka
multithreading) and multiprocessor examples:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.6?SHELF=EZ2HW125&DT=19970613131822

The Soul of Barb's New Machine (was Re: creat)

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 10 Jan 2005 17:04:01 -0800
Subject: Re: The Soul of Barb's New Machine (was Re: creat)

glen herrmannsfeldt wrote:

And, since CAS runs on systems with cache it has to properly account
for them.  When CAS finishes with CC=1, it is defined as having
loaded the memory operand into the appropriate register.

There is a story of someone using CAS in a loop, and when CC=1
reloading the appropriate register before reexecuting CAS. It seems
that it can load the wrong value on a machine with a cache in that
case.  Maybe it loads from cache where CAS loads from memory? I am
not sure on that one, but it seems that it fails.

original cas, 370 cache machines were very strong memory model and
store-thru cache. stores invalidated all other caches in the complex.
fetch for the compare basically did the invalidate and serialization
until store completed (or compare failed).

other memory model implementations and store in/thru caches issues were
suppose to still preserve the CAS semantics.

two processo r370 smp cache machine would slow the uniprocessor machine
cycle down by 10 percent to allow the cache processing time associated
with sending out the invalidates .... the base hardware of two
processor smp was 2x0.9=1.8 times hardware performance of a
uniprocessor (as a starting point; machine cycles for actually
processing invalidates and any cache thrashing would further degrade
hardware thruput).

3081 was announced as a "dyadic" ... two-processor smp ... but not in
the sense of 360s & 370s sense where machine could be partitioned and
be operated as multiple independent uniprocessor. 3081 was never
intended to have uniprocessor version.

there was some issue with ACP/TPF (operating system for airline res
systems and some number of high-performance financial transactions)
which had cluster support (for scalability and availability) but
didn't have SMP support. Upgrading TPF to newer 3081 processor
resulted in the 2nd processor being idle (other than a large number of
installations that ran vm/370 on 3081s and two copies of TPF ... each
one with affinity to one of the 3081 processors). A lot of the TPF
customers were looking for flat-out raw performance ... and since TPF
didn't have SMP support ... eventually a uniprocessor 3083 was
announced (which was never planned for in the original 308x
products). The 3083 processor ran almost 15percent faster machine
cycle (compared to 3081 processor machine cycle) because it didn't
need the 10% cross-cache invalidate slow-down.

Later mainframes (especially with higher number of processors) ...
started to run the cache machine cycle at much higher rate than the
processor cycles (to help mask the cross-machine invalidate overhead).

Other processor architectures might weaker memory consistency models
and other cache consistency protocols .... but the hardware
implementations for CAS should still support the CAS semantics.

Network databases

From: lynn@garlic.com
Newsgroups: comp.databases.theory
Date: 11 Jan 2005 08:14:14 -0800
Subject: Re: Network databases

Mark D Powell wrote:

If my memory is correct a networked database could only follow
predefined paths to the data. Nodes (chunk of data) were chained to
other nodes using pointers and these prebuilt pointer chains were
the only paths through the data.

A relational database on the other hand supports accessing data in a
more flexible manner and does not use predefined pointers to the
data elements. In theory any column can be used to join to any other
column in another table. Obviously you would only do this when the
data in question was actually the same data values and for
performance reasons you would probably add indexes on these
columns. But the point being a user can declare any relation that
makes business sense at run time rather than at object definition
time.

I hope this is clean enough. I believe that CA still supports a
legacy > network database product. The methods being discussed in
the OO world > may include "fixes" for some of the problems on
network db designs of > the past. For certain types of applications
a network design would be > very fast as only one IO would be
required for each node.

as i've mentioned before ... the hierarchical/network side (bldg. 90)
during the 70s against the relational (bldg.28) original relational
http://www.garlic.com/~lynn/subtopic.html#systemr

wasn't so much about the information organization ... but about the
physical implementation. the hierarchical/network implementations from
the 50/60s used direct physical pointers ... while relational used
indexes. The direct physical pointers increased human administrative
workload ... but was faster for the standard case ... being able to go
directly to the desired data. relational reduced the human
administrative effort but increased the overhead to get to the desired
data and typically doubled the physical storage requirements (both
space and processing overhead introduced by the indexes).

the physical pointer implementation vis-a-vis indexes can be
independent of the information organization (aka it is possible to do
physical implementation using indexes for both hierarchical and
network information organizations).

so for NLM at the NIH ... they did card catelogue using BDAM. The
"card" was identified by its BDAM pointer (implementation from the
60s). They built indexes of cards by listing the BDAM pointer. So for
a specific author .... there was a list of all BDAM pointers (that
corresponded to papers/books/etc they had authored). a specific
keyword had a list of all the corresponding BDAM pointers. They have
80-some categories that entries were indexed by (author name, keyword,
address, subject, etc) ... aka categories of things for which lists of
BDAM pointers are built for.

The claim was that sometime in the early '80s they hit the query
problem .... a query response involving 5-8 qualifiers could be quite
bi-model ... trivial change making the difference between 100,000
responses or zero responses.

Query strategy became returning the number of responses .... rather
than the actual responses ... and experimentally trying queries until
responses were reasonable number (greater than zero ... but less than
thousand)

Basically the various BDAM pointer lists were treated as sets of
pointers ... and queries with ANDs, ORs, NOT, ... became and'ing,
or'ing, etc the BDAM pointer sets, and then counting the members of
the resulting set.

Arriving at a set-size of reasonable number ... then could retrieve
the list of set members (and eventually the corresponding "cards").

In this case, the BDAM pointers are both the physical pointer as well
as analogous to globally unique primary key in relational. So the
information organization might be considered relational? Are the
various lists of BDAM pointers correspond to normalization? It would
appear that the implementation would also work where the globally
unique identifier was something other than a direct physical pointer.

Network databases

From: lynn@garlic.com
Newsgroups: comp.databases.theory
Date: 12 Jan 2005 08:42:44 -0800
Subject: Re: Network databases

Alfredo Novoa wrote:

And it is possible to do physical implementation using pointers with
relational databases.

In a short: with relational databases we can get the same or better
performance but working a lot less.

the argument from the 70s was that the original relational database
used indexes to effectively automate some amount of system
administrative overhead (associated with physical pointers) at cost in
disk space, real memory space, and processing time (trading off
computer & processing resource against people time) ... this was
somewhat independent of information organizational issue ... but
physical implementation.

the original relational database work was somewhat targeted at bank
accounts ... single table, bank account number is primary index, and
rest of information was associated with bank account number. there was
a very good match between the information organization and use with
relational row/column organization.

there are other types of information where relatively trivial
normalization can result in several hundred tables and there is little
difference in the query complexity facing a user with respect to
complex joins vis-a-vis network navigation (very low information
uniformity, very large information uniqueness).

Network databases

From: lynn@garlic.com
Newsgroups: comp.databases.theory
Date: 13 Jan 2005 08:23:43 -0800
Subject: Re: Network databases

Alfredo Novoa wrote:

I can't disagree more!

It is exactly the contrary. There is little difference if you have two
tables or less, but the difference increases exponentially when the
number of tables grows.

It is very easy to manage many tables at the same time using
updateable views. And you might create views that use views.

hum, yes, well; there was this bldg. in san jose referred to as sjr or
bldg. 28. I had an office on the 1st floor, backus had an office down
the hall and codd had an office above on the second floor. there was
this project going on in sjr to implement something called system/r
and sequel, random system/r past posts
http://www.garlic.com/~lynn/subtopic.html#systemr

i've joked that SQL was part of competition between san jose research
and yorktown research (where query-by-example was going on) for best
TLA .. aka QBE vis-a-vis SQL. some random qbe past posts
http://www.garlic.com/~lynn/2002e.html#44 SQL wildcard origins?
http://www.garlic.com/~lynn/2002o.html#70 Pismronunciation
http://www.garlic.com/~lynn/2003n.html#11 Dreaming About Redesigning SQL
http://www.garlic.com/~lynn/2003n.html#18 Dreaming About Redesigning SQL
http://www.garlic.com/~lynn/2004l.html#44 Shipwrecks

about 10 miles south there was this other bldg ... santa teresa lab or
bldg. 90. It had opened the same week as the Smithsonian air & space
museum. it had access methods, databases, and language products. I
would work some number of days in bldg. 90 ... riding my bike. south
silicon valley/coyote valley has this interesting weather pattern
where I would have a strong head wind riding south in the morning and
a strong head wind riding north in the late afternoon.

so the physical databases of the 50 and 60s were developed when there
was limited real disk space and limited real memory. direct physical
pointers conserved the limited amount of scarce resources. they even
had structures like isam ... where you could write I/O programs that
could pickup physical pointers and follow them outboard in the i/o
subsystem w/o bothering the processor. some amount of past postings
about changing constrained physical resources in the 70s:
http://www.garlic.com/~lynn/subtopic.html#dasd

I had started writting some stuff that over a 10-15 year period that
the relative disk system performance had declined by an order of
magnitude (memory, disk capacity, processor had increased by factors
of 50, disk access thruput had only increased by 3-5 times). this
annoyed the disk division and the disk division performance group was
assigned to refute my statements. after a couple months and came back
and said that i had slightly understated the issue.

in any case, during the 70s, real storage, disk space and processor
were increasing dramatically, the cost of hardware was declining and
the cost of people was increasing. also with the increase in disk
space sizes, the amount of data that had to be manually managed was
increasing significantly.

the arguments about system/r doubling the disk space and having
layered index between ... was becoming less of an issue because the
hardware costs were dropping and the relative amount of disk space was
increasing. it was also now possible to start caching lots of the
index structure in the increasing amounts of real storage available
(instead of incrementally threading thru the index structure because
there was no excess real storage to keep any cached information
around).

All of this was being traded off against savings in people time
(becoming scarcer and more expensive) which were having to deal with
increasing size of data to be managed (by the relative increase in
disk space sizes).

So with some amount of resistance continuing from bldg.90 and database
product organization ... the system/r tech transfer went from bldg28
to endicott to become sql/ds. later there was sort of tech transfer
from endicott to bldg.90 to become db2.

so somewhat in parallel with some of this ... there was small
contingent in blg. 90 looking at doing a "modern" network database
implementation ... doing a lot of abstracting so that the database
users are separated from a lot of low-level physical database gorp
... in much the same way that system/r had abstracted a lot of those
details in relational. Some amount of the higher level abstraction
work was also influenced by Sowa. So they came up with a query
language paradigm that removed the physical pointer and lots of the
network navigation characteristics from the interface (anologous to
what SQL accomplished). eventually they came to wanted to do a
side-by-side comparison with db2 on a level playing field.

somewhat west of bldg. 28 about 10 miles was bldg. 29 or the los gatos
lab.  I'm not sure all of its history, it was built in the 60s and
housed ASDD for a time (possibly even advanced system development
division hdqtrs). It seemed that ASDD sort of evaporated with the
death of FS ... random FS past postings
http://www.garlic.com/~lynn/subtopic.html#futuresys

They had done AM1/AM0 there ... which had eventually morphed into VSAM
and became responsibility of product group in bldg. 90.

At the time of the side-by-side comparison, most of bldg. 29 was
occupied by VSLI chip design group. For the comparison they choose an
extremely network oriented structure, large CPU chip ... all the
circuits that goes into the chip (and pretty non-uniform ... not like
what you might find in something like a memory chip). On the same
machine with the same system and operations ... load the chip
specification into the database. The comparison would be elapsed time
from start of initial query until chip was drawn on screen ... no
tuning and no optimization.

The SQL query statements were on the order of 3-5 times larger and
more complex ... and it quickly became clear that with level playing
field, a side-by-side comparison of untuned and unoptimized, DB2 was
ten times slower. So to make it a little more fair to DB2, the whole
thing was given to some DB2 performance gurus for a couple weeks
... they were allowed to use every DB2 trick in the book, trace the
query to death and re-org it every way possible. There were eventually
able to get totally optimized DB2 so that it was only three times
slower than the untuned and unoptimzed comparison.

Now, it was easy to show that DB2 was possibly ten times faster than
this "modern" network implementation for single large bank account
oriented table .... however for anything that was large, complex, and
non-uniform ... DB2 couldn't touch it .... either in the (lack of)
complexity of the query statements or in thruput/performance. The
abstraction of how the paradigm was presented also made it much
simpler to change and update the organization (in addition to simple
adding/deleting data) for complex organizations.

Along the way, I got to write code for both implementations ... help
with things like tech transfer of system/r from blg. 28 to endicott
for sql/ds, etc.

for some topic drift ... "sequel"
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-System.html#Index111
... from above ...

Don Chamberlin: So what this language group wanted to do when we first
got organized: we had started from this background of SQUARE, but we
weren't very satisfied with it for several reasons. First of all, you
couldn't type it on a keyboard because it had a lot of funny subscripts
in it. So we began saying we'll adapt the SQUARE ideas to a more
English keyword approach which is easier to type, because it was based
on English structures. We called it Structured English Query Language
and used the acronym SEQUEL for it. And we got to working on building a
SEQUEL prototype on top of Raymond Lorie's access method called XRM.

... snip ...

Lorie and I (and a couple others) transferred from scientific center
to the west coast about the same time
http://www.garlic.com/~lynn/subtopic.html#545tech

now there is this other stuff out there that goes somewhat
GML->SGML->HTML->XML, etc (somewhat analogous to the transition from
SEQUEL->SQL) where GML was invented at the science center and the
letters "G", "M", and "L" stand for initials of the people that
invented it ... and the same Lorie (in the above) is the "L" in all
those ML things floating around out there.
http://www.garlic.com/~lynn/subtopic.html#sgml

Network databases

From: lynn@garlic.com
Newsgroups: comp.databases.theory
Date: 13 Jan 2005 10:23:17 -0800
Subject: Re: Network databases

frosty wrote:

So you are saying that "HTML" is _not_ an acronym for
HyperText Markup Language?

so gml was invented at the science center ... misc. past references
http://www.garlic.com/~lynn/subtopic.html#sgml

by "G", "M", and "L" ... and the objective was come up with name that
corresponded to their initials ... aka GML ... and eventually came up
with Generalized Markup Language (where the "l" in "language"
corresponds to the first initial of the last name of one of the
inventors).

this was eventually standardized in iso as SGML ... standard
generalized markup language ... where the "l" in language still
corresponds with the initial of the last name of one of the inventors.

HTML then was outgrowth of SGML ... and XML is outgrowth of
combination of HTML and SGML ... where the "l" in language still
corresponds to the initial of the last name of one of the inventors.

this is somewhat akin to compare&swap instruction, also invented by
one of the people at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

however, there was only one inventor in this case whose initials are
CAS. The task was coming up with mnemonic that corresponded to the
initials of his name .... and eventually came up with
compare&swap.  random posts about compare&swap (and other
multiprocessor related stuff)
http://www.garlic.com/~lynn/subtopic.html#smp

some slightly more specific sgml, html, science center, etc posts:
http://www.garlic.com/~lynn/2002b.html#46 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2003o.html#32 who invented the "popup" ?
http://www.garlic.com/~lynn/2004l.html#72 Specifying all biz rules in relational data

Network databases

From: lynn@garlic.com
Newsgroups: comp.databases.theory
Date: 13 Jan 2005 12:24:54 -0800
Subject: Re: Network databases

a html history page
http://infomesh.net/html/history/early/

mentioned in thread that ran last year in this newsgroup.

a couple of references from the "G" in gml/sgml
http://www.sgmlsource.com/history/roots.htm
http://www.sgmlsource.com/index.htm

minor comment on xml history from w3c
http://www.w3.org/XML/

a couple other xml history pages
http://www.users.cloud9.net/~bradmcc/xmlstuff.html
http://www.icaen.uiowa.edu/~bli/xml_proj/final-1.html

misc. postings on the subject from threads in this newsgroup last year
http://www.garlic.com/~lynn/2004l.html#51 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004l.html#52 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004l.html#53 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004l.html#58 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004l.html#72 Specifying all biz rules in relational data