2002 Newsgroup postings (04/06 - 04/27) Lynn Wheeler

2002 Newsgroup Postings (04/06 - 04/27)

Computers in Science Fiction
Blade architectures
Increased Paging in 64-bit
Increased Paging in 64-bit
Blade architectures
Blade architectures
Blade architectures
Blade architectures
Is AMD doing an Intel?
PKI / CA -- Public Key & Private Key
Least folklorish period in computing (was Re: IBM Mainframe at home)
Blade architectures
looking for information on the IBM 7090 instruction set
Hardware glitches, designed in and otherwise
Mail system scalability (Was: Re: Itanium troubles)
Mail system scalability (Was: Re: Itanium troubles)
Blade architectures
Blade architectures
Mail system scalability (Was: Re: Itanium troubles)
When will IBM buy Sun?
Blade architectures
When will IBM buy Sun?
Biometric Encryption: the solution for network intruders?
Computers in Science Fiction
Computers in Science Fiction
When will IBM buy Sun?
Blade architectures
Security Issues of using Internet Banking
Security Issues of using Internet Banking
Computers in Science Fiction
Computers in Science Fiction
Security and e-commerce
Biometric Encryption: the solution for network intruders?
Security and e-commerce
Security and e-commerce
Security and e-commerce
Blade architectures
Playing Cards was Re: looking for information on the IBM 7090
Playing Cards was Re: looking for information on the IBM
Playing Cards was Re: looking for information on the IBM
e-commerce future
Blade architectures
Blade architectures
Foreign Cars (was: Computers in Science Fiction)
Blade architectures
Biometric Encryption: the solution for network intruders?
Security Issues of using Internet Banking
How Long have you worked with MF's ? (poll)
How Long have you worked with MF's ? (poll)
Blade architectures
Blade architectures
markup vs wysiwyg (was: Re: learning how to use a computer)
Mainframes and "mini-computers"
WATFOR's Silver Anniversary
WATFOR's Silver Anniversary
Security Issues of using Internet Banking
crypto processor activity
IBM competes with Sun w/new Chips
Security Issues of using Internet Banking
Blade architectures
Mainframes and "mini-computers"

Computers in Science Fiction

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers
Date: Sun, 07 Apr 2002 06:38:45 GMT

jmfbahciv writes:
Sure. They didn't need to buy five systems to service 10,000 accounts. And don't underestimate one mainframe on site. In the late 70s or early 80s, a study was done at DEC. I

more drift ... from a 1988 IDC report:


              VAX INVENTORY
              -------------
SYSTEM       US       NON-US    TOTAL
--------- --------- --------- ---------
11/725         950       550     1,500
11/730       4,100     2,950     7,050
11/750      12,230     9,370    21,600
11/780      14,280     9,660    23,940
11/782         190       120       310
11/785       2,460     1,590     4,050
MVI          1,840       960     2,800
MVII        41,000    23,900    64,900
82XX         2,800     1,870     4,670
83XX           900       600     1,500
85XX         1,200       905     2,105
86XX         2,360     1,240     3,600
8700           400       270       670
8800           300       200       500
--------  --------  --------
TOTAL       85,010    54,185   139,195

              VAX SHIPMENTS
              -------------
                                           NO. OF VAX
YEAR         US       NON-US    TOTAL    MODELS SHIPPED
--------- --------- --------- ---------  --------------
1978          312        78       390          1
1979          627       313       940          1
1980        1,512     1,038     2,550          2
1981        1,979     1,726     3,705          2
1982        4,129     2,794     6,923          4
1983        6,178     4,384    10,562          5
1984       11,703     8,227    19,930          7
1985       17,600     7,300    24,900          8
1986       19,190    12,840    32,030         12
1987       21,780    15,485    37,265         12
--------  --------  --------
TOTAL       85,010    54,185   139,195

                        VAX SHIPMENTS - NON US
                        ----------------------
             1978-
SYSTEM       1984      1985      1986      1987     TOTAL
--------   --------  --------  --------  --------  --------
11/725         450       100         0         0       550
11/730       2,350       600         0         0     2,950
11/750       7,040     1,700       430       200     9,370
11/780       7,700     1,500       270       190     9,660
11/782         120         0         0         0       190
11/785          40     1,100       350       100     1,590
MVI            860       100         0         0       960
MVII             0     1,900    10,000    12,000    23,900
82XX             0         0       725     1,145     1,870
83XX             0         0       200       400       600
85XX             0         0       305       600       905
86XX             0       300       470       470     1,240
8700             0         0        60       210       270
8800             0         0        30       170       200
--------  --------  --------  --------  --------
TOTAL       18,560     7,300    12,840    15,485    54,185

                        VAX SHIPMENTS - US
                        ------------------
             1978-
SYSTEM       1984      1985      1986      1987     TOTAL
--------   --------  --------  --------  --------  --------
11/725         650       300         0         0       950
11/730       3,200       900         0         0     4,100
11/750       9,300     2,200       560       170    12,230
11/780      11,500     2,200       400       180    14,280
11/782         190         0         0         0       190
11/785         260     1,600       500       100     2,460
MVI          1,340       500         0         0     1,840
MVII             0     9,000    15,000    17,000    41,000
82XX             0         0     1,150     1,650     2,800
83XX             0         0       300       600       900
85XX             0         0       420       780     1,200
86XX             0       900       730       730     2,360
8700             0         0        80       320       400
8800             0         0        50       250       300
--------  --------  --------  --------  --------
TOTAL       26,440    17,600    19,190    21,780    85,010

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

... also 1988
6,500 clusters installed, From 14,000 DEC VAX sites:

Percentage of VAX processors clustered

15% - 1985
21% - 1986
26% - 1987

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Sun, 07 Apr 2002 19:42:22 GMT

Anne & Lynn Wheeler writes:
The DBMS vendors that used/supported the HA/CMP DLM had description and it was fairly straight-forward stuff. I believe that these same DBMS vendors had been making the same suggestions for a number of years to the original makers.

slightly related from 80s (vax thread drift in a.f.c.):
https://www.garlic.com/~lynn/2002e.html#74 Computers in Science Fiction
https://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

various quotes/pieces from dec professional 1/88, pg 44, "OLTP on the VAXcluster" (i started work on HA/CMP DLM prototype not too long later):

Digital offers the VAXcluster as an easily managed computing environment that gives incremental expandability, extensive and flexible resource sharing, highly available resources, extensive data storage flexible configurations and support for balanced interactive workloads. However, the cluster's Distributed Lock Manager introduces overhead that can make this environment unsuitable for high-volume transaction processing. It is possible for application software (and I assume that Sybase incorporated these ideas into their database) to eliminate this overhead penalty and permit the successful implementation of OLTP applications on the VAXcluster.

1. The benefit of expandability, however, is offset substantially by the overhead imposed by the cluster itself.

2. Lock management may be as much as 20% for each processor in the cluster, reducing the actual throughput achieved to approximately 80% for each additional cluster member.

3. One RDBMS vendor (Sybase?) estimates that the VAXCLUSTER software, using the Lock Manager for all remote locks in a two-CPU cluster, might achieve a throughput gain of 1.8 for a select (READ?) trans- action and only 1.3 for a short update transaction over that of a single CPU.

4. Lock management also makes recovery unacceptably lengthy for ap- plications requiring high system availability.

When a cluster node fails, processors on all nodes stop until the VMS connection manager re-establishes a quorum. Then, the Dis- tributed Lock Manager must release all locks held by the failed process, re-establish the Resource Manager for all resources held by the failed processor, and re-establish the local and remote lock databases for each resource in use at the time of the fail- ure. While this activity is in progress, all nodes in the cluster are unavailable

Recovery time for the cluster is proportional to the number of locks in use and may take 5 to 8 minutes or longer.

Because the Lock Manager is responsible for these drawbacks, application software that reduces its overhead is required to provide an environment for OLTP.

A DBMS that can run as a efficient database machine on one processor in a cluster can eliminate a great deal of overhead. This requires a requester/server architecture:

The server must run as a single process on a dedicated processor with its own memory management and memory resident locking mech- anism,

The server must manage data for all users with one dedicated image and one shared data cache so hundreds of users can be handled in 4-6 Mbytes of storage,

The applications would run on other processors.

The requester/server architecture in a VAX cluster has the following benefits:

A server running as a single process doesn't require context switching,

Its own memory management eliminates page faults,

A shared data cache minimizes disk I/O

Because all data is managed by a single server on one processor, locking can be handled simply by reading and updating a memory resident table. Memory resident lock management eliminates the VMS locks that the Lock Manager establishes for concurrent users.

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

Increased Paging in 64-bit

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Increased Paging in 64-bit
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 08 Apr 2002 04:06:43 GMT

aw288@OSFN.ORG (William Donzelli) writes:
"Junk? JUNK!?"

I have to get in touch with these people to catch some of these old boxes they are replacing. You would not want to go to the computer museums, loaded with DEC stuff, and walk away with the idea that a KL10 was the ultimate big computer...now would you?

random online refs:
http://www.geocities.com/SiliconValley/Lakes/5705/1401.html
http://www.beagle-ears.com/lars/engineer/comphist/ Computer History
http://www.beagle-ears.com/lars/engineer/comphist/ibmmodel.txt
https://web.archive.org/web/20030813135723/http://www.cbi.umn.edu/collections/inv/corpman.htm

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

Increased Paging in 64-bit

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Increased Paging in 64-bit
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 08 Apr 2002 15:18:38 GMT

Rick.Fochtman@BOTCC.COM (Rick Fochtman) writes:
If you'd ever seen one working, you'd immediately understand how it got that name. I don't think that even Rube Goldberg could have dreamed it up. <G>

(I suspect that the tape in the 3851 cartridges was the same as that used for the 'noodles' in the 2321.)

there was also the aspect of a washing machine as the drum rotated and placed different cartridges under the picker. there was also the crumbling problem if the gap didn't open correctly trying to stuff a strip back into the cartridge it sort of did a fan-fold crumple.

note also that the 2321 was responsible for the BB in BBCCHHR seek/search argument ... i.e. the BB rotated the 2321 washing machine to place the correct bin/cartridge under the picker.

random refs:
https://www.garlic.com/~lynn/2000.html#9 Computer of the century
https://www.garlic.com/~lynn/2000b.html#41 How to learn assembler language for OS/390 ?
https://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
https://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?
https://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
https://www.garlic.com/~lynn/2002.html#16 index searching
https://www.garlic.com/~lynn/2002.html#22 index searching

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Mon, 08 Apr 2002 22:23:31 GMT

KeithParris_NOSPAM@yahoo.com (Keith Parris) writes:
But of course such an approach runs the risk of poor scalability when the "single server on one processor" becomes a bottleneck for the entire cluster, and its node-dependent approach falls short when it comes to dealing gracefully with a node failure.

Interestingly, starting with VMS version 7.3, a system manager has the option of running the VMS Lock Manager on a dedicated CPU within an SMP system if they wish.

as mentioned (and one of the reasons a.f.c. was added) was this was from dec professional 1/88 ... circa about VMS version 5.0. It was respect to earlier thread about original input from some of the DBMS vendors regarding "what was wrong" in VMS DLM ... and requirements for HA/CMP DLM as to what needed to be different. As referenced in earlier threads, it was assumed that VMS got better over the last 15 years.

as part of the HA/CMP effort we coined the term disaster survivability to distinguish from disaster/recovery and ability to survive local problems (aka as hardware & software reliability got better, larger percentage of outages were from 1) various kinds of local disasters and 2) human mistakes).

at the time we were doing HA/CMP ... we also got a chance to author part of the corporate continuous availability strategy document ... but the section got pulled because of non-concurrance by POK and Rochester.

one of the earlier (mainframe) efforts to expand from local clusters was an internal online service that supported all the sales and field service people located in silicon valley ... it was eventually replicated in Dallas and Boulder in the late '70s (in part because of seismic event concerns).
https://www.garlic.com/~lynn/98.html#23 Fear of Multiprocessing?
https://www.garlic.com/~lynn/2000c.html#30 internal corporate network, misc.
https://www.garlic.com/~lynn/2000g.html#27 Could CDR-coding be on the way back?
https://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001.html#36 Where do the filesystem and RAID system belong?
https://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
https://www.garlic.com/~lynn/2001i.html#43 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2002c.html#30 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
https://www.garlic.com/~lynn/subtopic.html#hone

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Mon, 08 Apr 2002 22:58:28 GMT

Anne & Lynn Wheeler writes:
as mentioned (and one of the reasons a.f.c. was added) was this was from dec professional 1/88 ... circa about VMS version 5.0. It was

another '88 vax/vms tidbit ... the previous were
https://www.garlic.com/~lynn/2002f.html#0 ... vax machines shipped thru '88
https://www.garlic.com/~lynn/2002f.html#1 ... vms cluster DLM discussion


VMS SOFTWARE DEVELOPMENT
________________________

DEC description so that customers could understand the operating
system software development process inside Digital Equipment.

The planning function provides focus for:

 Strategy - defined with development and management and accepted by
the corporation after assigned "consultants" concur that is meshes
  with overall corporate strategy
Vision - as defined by programs (see below)
Requirements - as segmented into programs (see below)

Programs are defined as:

 an  area  of focus that may cross organizational boundaries
includes requirements that look 2 to 5 years ahead
VMS has 8 programs and 5 engineering groups, including:
-   production systems (OLTP)
  -   desktop systems
each driven by a team that includes:
  -   product management to look after  customer  requirements
-   VMS  engineering to look at feasibility and internal requirements
reviewed by planning and management of the 5 engineering groups
a vision is developed by upper management (addresses why a program
  is selected)

If a program is approved, it becomes a project.  Line development
managers develop a project plan based on the program requirements.
The 5 VMS development line managers involved are:

 network and clusters
system resources (RMS, etc.)
 low end systems
high end systems
system management.

Project plans are reviewed and a functional specification is written.
The first pass of release planning is also done by the project
managers.  Milestones and end dates for 30 to 50 project plans are
prioritized.  When the functional specification is completed the
content of a release of VMS is defined.

There are multiple versions (threads) of VMS in existence at any point
in time. VMS, as a project, includes:

400 engineers that are geographically split
8 concurrent development threads in parallel, including:
- maintenance release
  - functional release
- hardware support (for newly developed hardware)
  - layered software support
9000 modules
400 MB of source code, including:
- a 2 volume RA81 Shadow Set
  - 36% BLISS
- 31% Macro
  - 20% other (mostly C and Fortran)
- 13% procedural and build files
- 6 million lines of code (not including DECwindows)

DEC is using a DEC layered product, Code Management System (CMS), to
control the development process.  They feel that this has helped CMS
to evolve by feeding requirements back into the CMS development group.
A few additional tools were built to allow coordination between
physical locations.  Called CHARON (the gate-keeper of hell, a
creature of Greek mythology), is provides a shell over CMS to control
release classes and variants.

There exists only one "master pack" that is accessed across the
network within the DEC worldwide development community.

A system build is done in 9 sequential phases.  As VMS has grown over
time the rule of thumb is that it should run overnight on the fastest
processor available and the resultant code should reside on a single
disk.  Some examples provided were:

V1.0 - 12.5 hours on VAX 11/780 (2,356 files)
V2.0 - 17 hours on a VAX 11/780
   V3.0 - 12 hours on a VAX 11/782
V4.0 - 7.5 hours on a large cluster
   V5.0 - 12 hours on a  cluster  with  VAX  8840s  (18,022 files)

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Blade architectures

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Tue, 09 Apr 2002 03:50:19 GMT

KeithParris_NOSPAM@yahoo.com (Keith Parris) writes:
But IBM was so scared of DLM overhead that they chose a hardware-centric approach to locking (Coupling Facility) that is now complicating things for them when they try to geographically distribute a cluster for disaster tolerance. Geographically-dispersed Parallel Sysplex clusters stretch to what, 10 km? VMS clusters have stretched to more than 200 km.

the escon technology for mainframe was knocking around since the '70s. in the '80s it was used to increase the data-rate (to about 17mbytes/sec) and the distance for the bus&tag (400ft). the 10km was the escon distance in the '80s ... in part because it was still being used with half-duplex device i/o protocol.

SJR had done a cluster locking protocol over trotter/3088 in 1980 that syncronised in few seconds (effectively a simulated broadcast full-duplex logic). They were convinced to remap the protocol on top of LU6.2 (which has half-duplex semantics) ... and the same synchronization over the same hardware that had been a few seconds became several minutes running with LU6.2 semantics.

the issue going past 10km with any sort of performance is asynchronous for both disk/file operations as well as low-level locking support.

i believe the coupling facility is actually a stripped down operating system for pathlength reasons as well as a dedicated processor (real &/or LPAR).

my wife did the precursor work (for parallel sysplex) in the '70s when she did her stint in POK and was responsible for loosely-coupled architecture (POK'ese for cluster) ... and authored/invented Peer-Coupled Shared Data ...

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Tue, 09 Apr 2002 18:00:53 GMT

"Bill Todd" writes:
Distance adds about 10 us/mile (each way) to comm latency. For actual disk operations, anything much under 100 mile separation is measurable but not noticeable. Lock activity can be more sensitive to distance depending on how intense it is, which to a significant degree depends on how suavely both DLM implementors and application designers avoid the need for it.

problem with original bus&tag at 200ft was that it was half-duplex synchronous per byte, in the 70s, data streaming channels (still big thick bus&tag) raised the transfer rate from 1.5mbyte to 3mbyte, the distance to 400ft and effectively relaxed the syncronicity to 8bytes. escon raised the distance limit by further relaxing the syncronicity but still half-duplex and syncronicity is much lower unit than full disk record ... and so there would be multiple round-trip latencies per disk record transfer (aka are you assuming comm latency per byte or per disk record?).

getting escon out into product (after 10+ years) was something of a matter of the load bearing weight of the bus&tag cables (for large configurations) as well as some customers having to address problems with positioning all devices within a circular 400ft radius by migrating to a 400ft radius sphere (i.e. device spread across multiple floors) ... it wasn't really targeted as a disaster backup scenario.

I think capability for disaster backup scenario was demonstrated with full-duplex terrestrial T3s & HYPERchannel at the 1989 (1990?) Supercomputer conference held that year in austin. In the mid-80s, we did some T2 disaster/backup work ... but had round-trip latencies on the order of 88,000 miles.
https://www.garlic.com/~lynn/subnetwork.html#hsdt

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Is AMD doing an Intel?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is AMD doing an Intel?
Newsgroups: comp.arch
Date: Tue, 09 Apr 2002 22:30:51 GMT

"Fred Kleinsorge" writes:
In any case, I can show you devices, drivers and applications that can easily saturate the busses they are on - we can get high utilization. Of course, you can explain to me why a typical UNIX TCPIP stack ends up doing 1-2 buffer copies - it's not like this has only just been noticed as something stupid.

I'm a little to young to be able to detail 1960's mainframes (although my first computer job was as a 360 operator), but I'll wager that they had very complex I/O subsystems that offloaded much of the processing from the CPU, I'd guess that a PDA has more CPU horsepower than a 1960s mainframe. Where you do the processing very much would seem to be where the last bottleneck was - the old wheel of reincarnation. CPUs are slow, offload to the I/O subsystem, CPUs get faster and the complicated I/O is too slow, use the CPU resources to make it faster. Right now, CPUs are fast, but not cheap. Make CPUs so cheap that a 256 CPU system does't beak the bank - then dedicating CPUs for I/O becomes reasonable in a general computing environment.

old mainframes didn't have much real storage ... so that possibly was at least part of not doing buffer copies ... doing i/o directly into/outof application address space.

old mainframes also didn't have much real storage ... so there was at least some paradigm that traded off outboard processing for memory tables. rather than having memory tables ... like btrees of record locations ... 1960s mainframe count-key-data architecture had simple parameter in real storage ... and the disk controller would continually scan until it found matching record i.e. multi-track search. furthermore, since old mainframes didn't have much real storage ... the i/o subsystem didn't cache the argument outboard of the mainframe memory ... every time a record spun under the head ... it would (re)fetch the matching data. This had the effect of dedicating the complete I/O path to the operation until it found the matching record.

An instance of this in the '70s was a 3330 drive, with 19 platters spinning at 3600rpm, 60rps, or a (multi-track) search/scan took about 1/3rd of a second real time. In this particular instance at a large customer, two or three such scans could be needed before the correct record was found.

now, many of the mainframes had "integrated i/o" ... the processor engine had two different microcode programs that it time-shared ... one microcode program provided for the CPU architecture ... i.e. 360/370 ... while the other microcode program implemented the channel I/O operation (aka the native processor engine would split its time between executing the processor microcode and the I/O microcode).

A simple example can be seen in the 370 to 303x migration during the later '70s. The 370/158 had two sets of microcode running on the same processor engine ... one set was the 370 processor implementation ... the other microcode was the integrated channel i/o implementation ... with the native 158 microcode engine time-shared between the two sets of microcode.

The next generation 303x series introduced the "channel director" which was a dedicated I/O processor. The "channel director" was actually a 370/158 native processor that only had the channel i/o processor microcode. The 3031 was a 370/158 repackaged with only the 370 microcode and configured to use a separate 158 processor engine as a dedicated channel director. The 3032 was a 370/168 repackaged to work with a channel director. Only the 3033 was a "new" processor.

158 & 3031 (& 4341) benchmark number
https://www.garlic.com/~lynn/2002b.html#0 Microcode?

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

PKI / CA -- Public Key & Private Key

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI / CA -- Public Key & Private Key
Newsgroups: comp.security.misc
Date: Wed, 10 Apr 2002 02:03:46 GMT

"Ingmar" <w i z a r d _ o z @ g m x . n e t> writes:
This is what I think is going on:
) The public key is contained in the certificate
) The private key is only available to the user
) The CA does not have any private keys (except for it's own)

business processes can use (the same) PKI (technology) for two distinctly different business purposes:

1) authentication
2) confidentiality

in general, digital signatures can be created by using a private key to sign a message hash/mac ... and then use the corresponding public key to verify the digital signature ... verifying that a message originated from a particularly entity.

for confidentiality ... the public key can be used for either directly encrypting a message ... or using a random symmetric key to encrypt the message and encrypting the symmetric key with the public key. then only the entity with the corresponding private key can decrypt the message. the issue (especially for data at rest) is what happens if the private key becomes unavailable (say because of some sort of hardware failure), is all the corresponding encrypted data lost? Frequently, for business continuity purposes (no single point of failure, etc) ... private keys related to confidentially encrypted data may be escrowed and/or archived.

The business requirements for authentication ... is that you really would like to be assured that something originated only from a very specific purpose. In this scenario, the private key is strongly protected and may only exist in a single place.

The business requirements for confidentiality ... may require that valuable corporate assets (data & information) is not lost because of any sort of failure (including a single token housing a private key).

Business requirements associated with authentication may preclude a private key ever existing outside a very specific hardware token. Business requirements associated with confidentiality and business continuity may require multiple copies of a private key be kept.

basically, PKI is technology that can be used to address two different kinds of business requirements (confidentiality and authentication) which can result in the rules regarding the treatment of a private key be different based on the different business requirements.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Least folklorish period in computing (was Re: IBM Mainframe at home)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Least folklorish period in computing (was Re: IBM Mainframe at home)
Newsgroups: alt.folklore.computers
Date: Wed, 10 Apr 2002 15:49:22 GMT

Charles Shannon Hendrix writes:
I worked for a large bank and the stats said that most fraud came from the national chains and local merchants, somewhat behind the straight-up ID thieves which don't need to see your transactions at all. Online ordering wasn't really even in the noise yet. Part of the reason is that once they have your credit card information, it isn't transmitted again. By contrast, every single time you use a gas pump or go to a local merchant, there is a new transmission of the data. Also, your card is viewed and the number recorded by an army of underpaid clerks everywhere you go.

slightly related:
https://www.garlic.com/~lynn/2001h.html#61 re: net banking, is it safe?? (or security proportional to risk)

x9.59 standard for all payments:
https://www.garlic.com/~lynn/x959.html#x959

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Wed, 10 Apr 2002 16:02:43 GMT

Anne & Lynn Wheeler writes:
getting escon out into product (after 10+ years) was something of a matter of the load bearing weight of the bus&tag cables (for large configurations) as well as some customers having to address problems with positioning all devices within a circular 400ft radius by migrating to a 400ft radius sphere (i.e. device spread across multiple floors) ... it wasn't really targeted as a disaster backup scenario.

an analysis is vaguely coming back to me about the bus&tag channel connector space for the 3090 (nearly 20 some years ago & justification for escon). standard bus&tag connector needed something like a minimum of a sq. ft of panel space. nearly a hundred channels for the 3090 would have needed 100 sq ft. of panel space. Also the bus&tag cables are rather bulky, being able to even manually get your hands around a pair of bus&tag cables when there are a hundred pair in a small area is not practical ... more realistic is to spread it horizontally so there isn't more than 3-4 pairs veritically with maybe foot clearance on each side ... needing maybe 50-100 feet horizonal ... say four foot high by 50-100 feet wide for a connection panel.

escon/fiber connecter space was more on the order of 3270 cable connector space (or say CAT4).

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

looking for information on the IBM 7090 instruction set

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: looking for information on the IBM 7090 instruction set
Newsgroups: alt.folklore.computers
Date: Thu, 11 Apr 2002 15:00:27 GMT

haynes@alumni.uark.edu (Jim Haynes) writes:
Well of course if you drop a roll of paper tape it doesn't get out of sequence :-). But the numbers are sorta both part of the language and

but it was a pain inserting or replacing a record.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Hardware glitches, designed in and otherwise

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hardware glitches, designed in and otherwise
Newsgroups: alt.folklore.computers
Date: Fri, 12 Apr 2002 14:08:31 GMT

jdallen2000@yahoo.com (James Dow Allen) writes:
Here's a URL to three interesting IBM 370 bugs I posted 14 years ago:

http://groups.google.com/groups?selm=52277%40sun.uucp

These are more design bugs than glitches. I hope they're interesting enough to warrant comment....

360s instructions would check both start & end bounds for storage locations before starting an instructions. if start &/or end bounds failed address, fetch or store protection ... the instruction wouldn't be executed (protection exception or address exception). also, on 360/67 in virtual memory mode, if either start &/or end bounds precheck for page available failed, an instruction wouldn't execute (page fault).

370 introduced the "long" instructions. The "long" instructions were defined to execute incrementally and be interruptable. The storage bounds were only check for increment of execution (one byte) .. for instance a "long" instruction could execute one byte at a time right up to the boundary of a missing page ... and then interrupt with a page fault. At the interrupt, the parameter registers of the "long" instruction would be updated to reflect the current address(es) & residual length(s). In the case of a page fault, the instruction would be restarted when the page was available and the updated register contents.

The 370/125 had a microcode bug where it prechecked the bounds and wouldn't execute the instruction ... for all instructions and wouldn't execute the instructions if the bounds precheck failed. The machine was in customer shops for a year or two before it was realized and fixed.

The 360/67 had a bug that never got fixed. The 360/67 hardware translate utilized an 8-entry fully associated array of entries that mapped virtual to real page numbers. In relocate mode, there was an extra 150ns per address (normal address on 360/67 in non-relocate was same as 360/65, 750ns ... however in relocate mode, there was an extra 150ns added to every address operation for translating virtual->real ... or a total of 900ns ... instead of 750ns). Anytime there was a change in address space (by loading CR0 with a segment table address), the associative array would have all its entries invalidated and values reset to all zeros. The machine had been out several years before it was discovered that on a page fault interrupt, all the entries were being reset to zero but not flagged as invalidated. The problem was masked because normal kernel page fault handling always reloaded CR0 ... even if the virtual address didn't change. Charlie (as in the person behind the compare and swap instruction ... the mnemonic compare and swap was chosen specifically because CAS are charlie's initials) was doing some kernel optimization and removing redundant loading of CR0 when the virtual address had not changed (trying to scavenge associative array entries). It took him (all of us) awhile to realize that programs were failing after his modifications ... because of a hardware bug.

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

Mail system scalability (Was: Re: Itanium troubles)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mail system scalability (Was: Re: Itanium troubles)
Newsgroups: comp.arch
Date: Fri, 12 Apr 2002 14:22:05 GMT

"del cecchi" writes:
Profs on a 36? I don't remember that, and we designed and programmed the S/36. None of the IBM systems of that era were wysiwyg, pretty hard to do on a 3277.

You wanted pretty you put in bookmaster or gml tags like god meant you to do. :p. how else would you do it

del cecchi (crosspost trimmed)

later when color 3279 came along ... you could do some pretty amazing things with font loading (there was all the lightning flashes you had to put up with the font loading). somebody (possibly cowlishaw) was able to get the color monkey picture (from cover of scientiifc american) on a 3729.

from an email scalability ... possibly AOL ... 16 million (and increasing) on one (maybe more than one) tandem machine (although these may be the 1024 processor model).

the original core of PROFs had as its basis a pre-released, limited feature version of VMSG that the PROFs group had scarfed up someplace. When they possibility was raised that they had scarfed VMSG ... they denied it ... but it was hard to refute when it was pointed out that every PROFs message that ever existed in the world had the string "H.S.L." in a non-displayed control field (aka the initials of the VMSG author).

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

Mail system scalability (Was: Re: Itanium troubles)

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mail system scalability (Was: Re: Itanium troubles)
Newsgroups: comp.arch
Date: Fri, 12 Apr 2002 15:02:30 GMT

"Tarjei T. Jensen" writes:
Are you sure that this is not SGI Origin 2000 servers?

sure? ... i heard 3rd hand that the "100ton" demo going in at tandem/cupertino was duplicate of the aol installation. this was some time ago at a meeting (on completely different topic) that happened to be hosted by tandem.
https://www.garlic.com/~lynn/aepay3.htm#riskm

also some time ago i heard that tandem was using some flavor of MIPs processor ... so possibly there is some simalarity between a tandem config and an SGI config.

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

Blade architectures

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Fri, 12 Apr 2002 17:00:30 GMT

"Russell P. Holsclaw" writes:
I never meant to imply that magnetic media (or some form of persistent storage) were not needed. They will always be with us for obvious reasons. I was just suggesting that we would see the disappearance of the use of such media for data that doesn't require long-term persistence. Someday the big "swap file" full of non-persistent data will be seen as an anachronism. It only exists today because once it was prohibitively expensive to have a lot of RAM, and much cheaper to have the same capacity in disk.

note that various persistent storage virtual memory mapping has been done also (aka mmap) which includes both executable as well as data.

the technique has been used for transient snap-shots as well as mechanism implementing process migration (between processes not sharing memory).

A form of the transient snap-shots is effectively what is going on today when a machine boots up and loads and initializes a large number of applications ... frequently, in aggregate requiring more real memory than available ... but never executing simultaneously.

there is a trade-off between utilizing traditional paging infrastructure for this fast pre-initializing operation ... vis-a-vis rewriting applications to be "fast-start". Of course, having to single-page-fault such a fast-start application can offset the benefits from using the page mapping system ... so something more efficient than single (small, 4k) page fault operation is needed.

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Fri, 12 Apr 2002 17:11:15 GMT

Anne & Lynn Wheeler writes:
the technique has been used for transient snap-shots as well as mechanism implementing process migration (between processes not sharing memory).

CP/67-based & VM/370-based service bureaus starting (at least) in the early '70s used the technique to implement process migration between different processors in the same data center/cluster (that had shared disks) as well between waltham and san francisco data centers (aka the pages were transferred as a file from one page system in waltham to a page system in san francisco). Initially this technique was for scheduled maintenance scenario in 7x24 oepration with online customers world-wide.

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

Mail system scalability (Was: Re: Itanium troubles)

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mail system scalability (Was: Re: Itanium troubles)
Newsgroups: comp.arch
Date: Sat, 13 Apr 2002 01:11:45 GMT

johng@idiom.com (John A. Gregor) writes:
While it may still not be the case, at one point AOL email was definitely done on SGIs. Perhaps the Tandem stuff was for something other than email or was part of a bid to replace the O2K servers.

my limited understanding is that it is a big database application that leaves a single copy of the mail in place ... and keeps track of all sorts of things ... like copy list, who has &/or has not read the email, etc.

doing some web searching trying to find reference, didn't find any sgi, but tripped over a tandem reference dated May 2001:
https://web.archive.org/web/20021219083337/http://webserver.cpg.com/news/6.5/n4.shtml

from above
The Himalaya does figure prominently in one messaging environment: as a component in Dulles, VA-based America Online Inc.'s messaging infrastructure. The Himalaya plays an important role in delivering 150 million e-mail messages daily to and from AOL's 29 million users using a proprietary messaging platform that runs under UNIX as well as on "one of the largest Himalaya systems in existence," says Pauline Nist, vice president and general manager for Compaq's Tandem Business Unit.

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

When will IBM buy Sun?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: When will IBM buy Sun?
Newsgroups: alt.folklore.computers
Date: Sat, 13 Apr 2002 01:30:09 GMT

ref:
https://web.archive.org/web/20060831000514/http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2860393,00.html

note when it was originally offered to ibm ... ibm declined (at least in part because several internal organizations all claiming that they would be producing something better) ref:
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
https://www.garlic.com/~lynn/2000g.html#40 No more innovation? Get Serious

also in the above references ... is project that was designed and funded by IBM (DataHub) and then ibm decided to walk away from ... leaving the organization that had been funded to do the development with all the technology ... which lead to a new PC server-related company.

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

Blade architectures

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Sat, 13 Apr 2002 19:08:32 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
We have one with 128 GB of memory and a total of 1 TB of disk; we really DON'T want to allow swapping :-)

a "no-dup" page/swap allocation ... would only have page slots on disk for pages that weren't resident in real storage. if there were sufficient real storage to always contain all virtual pages ... then there need not ever be any disk space allocated.

that is (somewhat) separate issue with regard to whether or not any movement that might occur should be in units of 4kbytes at a time.

recent virtual memory semantics postings (in this thread):
https://www.garlic.com/~lynn/2002f.html#16 Blade architectures
https://www.garlic.com/~lynn/2002f.html#17 Blade architectures

misc. big pages refs:
https://www.garlic.com/~lynn/2001k.html#60 Defrag in linux? - Newbie question
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
https://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?

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

When will IBM buy Sun?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When will IBM buy Sun?
Newsgroups: alt.folklore.computers
Date: Sun, 14 Apr 2002 15:02:05 GMT

Taso Hatzi writes:
I think Sun and IBM have a lot more overlap in corporate philosophy these days. My guess is that neither Sun's people nor their customers would find the change too shocking.

just like AT&T, apple & others got some dose of former ibm executives ... so has sun.

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

Biometric Encryption: the solution for network intruders?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric Encryption: the solution for network intruders?
Newsgroups: comp.security.misc
Date: Sun, 14 Apr 2002 15:21:30 GMT

lajavakom@yahoo.com.au (Leela) writes:
From my opinion, I think we can't stop hijacking but we can protect more secured. Encryption is using a key derived from biometric parameters in traditional encryption algorithms. It is a mathematical process helping to disguise the information contained in messages that is either transmitted or stored in a database.

the problem with biometric derived keys is that almost all the biometric authentication processes are essentially fuzzy ... that in part is why there is all the stuff in biometrics about false positives and false negatives. thresholds for a fuzzy match ... between some biometric reference reading and a current reading can be down in the 30 percent area (even trying to match two succesive biometric readings). try and imagine a encryption technology where it was expected that only a random 30 percent of the bits matched between the encryption key and the decryption key.

biometrics works somewhat better in a 2-factor authentication scheme than it does in identification.
• something you have (like a hardware token)
• something you know (like a pin or password)
• something you are (i.e. a biometric reading)

a hardware token woulc make a claim as to the entity and then the biometric reading would be taken and attempt a close match for the claimed entity. The thresholds for percent match may be chosen differently from a scenario where there are biometric readings from millions of entities and there needs to be a search for a good match. A positive still may be possible with only a 50 or 60 percent match ... just because there are nothing closer. However, (again) imagine an encryption scheme where there only needs to be an approximate correlation between the encryption key and the decryption key.

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

Computers in Science Fiction

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers,alt.history.future,rec.arts.sf.science,rec.arts.sf.written
Date: Sun, 14 Apr 2002 16:05:49 GMT

Charles R Martin writes:
Certainly that's not the way it really happens. What _does_ happen is that bug rates go down _immensely_ -- not to zero, but near statistical zero in every example I've got the data for. Including things like misunderstanding of the API calls' real semantics, I have seen < 0.2 defects per 1,000 SLOC, as compared with something in the neighborhood of 3 per 1,000 SLOC that you'd normally expect in reasonably clean industrial-strength code. Given the variances involved and the size of experiments I can point to, that's so small as to make the defect rate statistically insignificant --- which is not to say it goes away, just that attempts to measure it are inherently very inaccurate.

three random drifts

1) for the resource manager, we defined an "envelope" of possible configurations, types of workloads, and workload levels (n-dimensional space). then something like 1000 benchmarks were defined that covered the surface and the interior of the n-dimenisonal space along with some outlyers that were possibly 10 times out. Some sample runs with the 10 times stressing would fairly reliably result in system failures. As a result, I redesigned and rewrote the whole system serialization code ... which not only eliminated all the system failures under the stress condistions but had the side-effect of also eliminating all zombie/hung processes. Finally there was an APL system model that took the all the benchmarking information and results and started generating parameters for new benchmarks (attempting to find anomolous operating regions). The could also wasn't suppose to fail but the resource manager was suppose to work as advertised ... exactly controlling resource allocation under all possible configurations, types of workloads and levels of workloads. Eventually over 2000 benchmarks were run taking three months elapsed time. As the rest of the system "drifted" (i.e. non-resource-manager poritions of the system were changed), a selected subset of the benchmarks were repeated every three months after initial product release.

2) for the disk engineering lab ... the standard operating system had a MTBF of 15 minutes with a single test cell (i.e. device under development). I redesigned and rewrote the input/output supervisor so that multiple test cells could be operated concurrently w/o any operating system failure. A lot of the earlier failure modes were people making assumptions about things always operating correctly ... as opposed to doing a detailed analysis of all possible assumptions about correctness and then implementing code to handle all the situtions where things didn't work correctly

random refs:
https://www.garlic.com/~lynn/subtopic.html#disk

3) for this thing called electronic commerce ... it needed a method of executing payments.
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aadsm5.htm#asrn2

the initial implementation/code was traditional straight line operation implementing the function. however, moving into a "service" environment involving large number of transactions and people all over the world ... the environment is more like telco operation ... the trouble desk has requirements on the order of being able pro-actively recognize that there is some failure and be able to do 1st level problem determination within five minutes. Traditional "straight line" industrial strength code frequently doesn't take into account service operation. My observation has been that there is on the order of four to ten times as much code written to covert a "straight line" application into a "service" application (as is in the original application) ... and this code is frequently a lot more complex.

part of the assurance for this ... was after all the stress & correctness testing of the base application ... a failure mode grid was created of the possible states and failures that could occur in a electronic commerce transaction ... and it was then necessary to show that either that situation could be recovered from and/or that it could be diagnosed within a very short period of time. The bare-bones, straight line application can be proven to be correct ... and it still wouldn't be satisfactory for real-life environment.

slightly related security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?

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

Computers in Science Fiction

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers,alt.history.future,rec.arts.sf.science,rec.arts.sf.written
Date: Sun, 14 Apr 2002 18:11:52 GMT

Anne & Lynn Wheeler writes:
the initial implementation/code was traditional straight line operation implementing the function. however, moving into a "service" environment involving large number of transactions and people all over

the end-to-end transport of a payment message was one thing ... having an environment with lots of diagnostics oriented around end-to-end circuit based paradigm, telco provisioning and even service level agreements (SLA) and trying to translate that to a packet-based internet anarchy was something totally different. the technology of the bits on the wire was trivial ... compared to trying to translate the whole telco provisioned end-to-end ciruit operation to the internet anarchy.

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

When will IBM buy Sun?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When will IBM buy Sun?
Newsgroups: alt.folklore.computers
Date: Sun, 14 Apr 2002 18:19:51 GMT

cjt writes:
And for that matter, I think Dell is largely populated with former I've Been Moved-ers.

we were in austin (for a while my wife was a manager of 6000 engineering architecture) in the late '80s and saw some significant migration from the austin group to dell.

at least some number of the austin ha/cmp people went to the austin/tandem/compaq group (may be still there).

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.arch
Date: Sun, 14 Apr 2002 21:22:46 GMT

JF Mezei writes:
Swap and page space should accommodate all of your virtual memory. If you want your 16 meg RAM system to have 100 meg of virtual memory, then you would need at least 100 meg of page/swap file space.

Consider the scenario where your hardware RAM is much smaller than the virtual address space you need. In such a scenario, the "primary" storage is actually the disk page files, and only the pages actually needed at the moment are brought to RAM.

that is a "dup" or duplicate algorithm/implementation. It is possible to have a no-dup implementation ... that a virtual page either resides in real storage or on disk ... but never both. Since there is a trade-off with write operations between a "dup" and "no-dup" implementation ... you can actually have an implementation that dynamically switches when disk space becomes constrained aka a dup algorihtm can save write operations for pages brought in ... selected for replacement ... but not changed during their most recent stay in storage. However other considerations having to do with disk arm locality can justify an always write-out implementation ... further tilting things towards a "no-dup" implementation.

recent refs on this thread in a.f.c.
https://www.garlic.com/~lynn/2002f.html#20 Blade architectures

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

Security Issues of using Internet Banking

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Mon, 15 Apr 2002 03:34:41 GMT

ccsim@bigpond.net.au (Jasmine) writes:
Hi!

I wish to get some views and expertise on the security issues of using Internet Banking.

As a user, I see the benefits of having the convenience of being able to see my transactions online and paying my monthly bills without physically leaving my home.

However, I know alot of people is still not be able to accept this concept. And I do understand their concerns on the security issue that is involved. I can roughly visualise how many people would be involved in the process. Many people would be able to view my transactions such as employees from the bank and IT personnels. They would also have access to my account. In fact, anybody just by calling the bank on the phone, with my personal details would be able to access my account over the phone. The idea of banking over the Internet is scary.

One would like to think that it is safe to do my banking on the Internet. However, is it? Is it safe for one to do banking over the Internet? What are the security issues involved? What are the measurements can one take in order to improve the security while doing internet banking?

I would like to hear views or comments on the idea of using Internet Banking.

internet technology has gotten something of a reputation for being insecure. however a lot of internet banking is just a internet spigot that interfaces to some backend processor someplace, in some implementations the internet spigot uses much the same interface to the backends that a customer call center uses for implementing telephone banking (or for that matter the same interface that an ATM network uses for doing ATM banking).

The issue then is it is similar to ATM banking but the end-point is your PC (instead of an ATM machine) and the transport is the internet (instead of an encrypted private network). Well it is possible using things like SSL to achieve similar encryption security for the data being transported as an encrypted private network.

That leaves a couple of vulnerabilities:

1) your pc (compared to an ATM machine) 2) the internet gateway

An ATM machine pretty well restricts which buttons you can push and what functions that might happen. A poorly implemented internet gateway might allow "virtual buttons" to be pushed that wouldn't be allowed if it was a real ATM machine (or internet viruses to be introduced that capture transaction information). A poorly secured personal PC might have viruses that capture keystrokes and contribute to fraudulent transactions.

However, the number of types of people that can view transactions (occurring at the back-end processor) would be approx. the same whether it was internet, ATM, physical check, etc.

cross-posted to a.f.c where there has been a programming assurance thread going on (aka what is the assurance of the internet gateway that implements internet banking ... is it equivalent to the assurance required for ATM software? ... also what is the assurance of a personal PC?).

much of europe is using or moving towards hardware tokens of various kinds (for financial transactions) because of issues with trust and assurance of personal PCs ... i.e. it isn't sufficient for fraudulent transactions to just capture keystrokes ... but access to the specific hardware token is also required.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Security Issues of using Internet Banking

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Mon, 15 Apr 2002 03:50:24 GMT

Jim Watt writes:
I'm quite happy to use it. I do ask retailers whether they retain my credit card details online and don't like it if they do. Retailers are not as security aware as banks.

The internet itself is of course NOT secure, however there is more chance that someone who wants to find out data about you will steal your PC than anything else.

Its all a matter of balance, standing in queues at the bank costs money and tasks like settling credit cards takes longer done over the counter incurring interest charges when they could be done quicker online.

A computer transaction is cheaper than a teller transaction so in the end the majority will be done online.

with respect to credit cards there is another issue ... the amount of security a merchant can afford:
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Computers in Science Fiction

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers,alt.history.future,rec.arts.sf.science,rec.arts.sf.written
Date: Mon, 15 Apr 2002 15:45:33 GMT

Lee DeRaud writes:
Why am I even saying this? Because (in my experience) the concept of "J. Random Programmer" just doesn't fit in the same sentence with "IBM FSD": there really is such a thing as a corporate culture and FSD's is not typical.

a large percentage of FSD people were GML programmers (aka the precursor to SGML, HTML, XML, etc) ... who wrote documents that met various federal criteria (aka their job was to word smith). another large group was contract managers ... who managed contracts that were then subcontracted out to a lot of other people.

they were also good at billing .. we once had a project review by FSD .... and they eventually sent something like 20-30 people to a one week meeting ... and the project got the bill for all of the peoples' time ... but then a lot of the project was transferred to FSD and they had to foot the bill. slightly related refs:
https://www.garlic.com/~lynn/2000c.html#6 TF-1
https://www.garlic.com/~lynn/2000d.html#27 Superduper computers--why RISC not 390?

there were some really good system design people as well as programmers. For instance the guy that headed up the original FAA air traffic control system ... who then went on to be president of FSD (as well as many of his team). The next couple rounds in the late '80s & 90s for the new & ever improved FAA air traffic control system didn't do quite as well (although there were some excellent people working on it also). slightly related refs:
https://www.garlic.com/~lynn/2001.html#3 First video terminal?
https://www.garlic.com/~lynn/2001d.html#77 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2002b.html#6 Microcode?
https://www.garlic.com/~lynn/98.html#23 Fear of Multiprocessing?

side note ... GML was original chosen because it is the first letters of the late names of the three people that worked on it, random refs:
https://www.garlic.com/~lynn/94.html#11 REXX
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/96.html#24 old manuals
https://www.garlic.com/~lynn/97.html#9 HELP! Chronology of word-processing
https://www.garlic.com/~lynn/97.html#26 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#16 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/99.html#42 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#43 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#91 Documentation query
https://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2000.html#8 Computer of the century
https://www.garlic.com/~lynn/2000.html#34 IBM 360 Manuals on line ?
https://www.garlic.com/~lynn/2000.html#82 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#32 20th March 2000
https://www.garlic.com/~lynn/2000c.html#30 internal corporate network, misc.
https://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems
https://www.garlic.com/~lynn/2000e.html#0 What good and old text formatter are there ?
https://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ?
https://www.garlic.com/~lynn/2000e.html#23 Is Tim Berners-Lee the inventor of the web?
https://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
https://www.garlic.com/~lynn/2001c.html#88 Unix hard links
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2001g.html#54 DSRunoff; was Re: TECO Critique
https://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#34 D
https://www.garlic.com/~lynn/2001h.html#46 Whom Do Programmers Admire Now???
https://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#16 Disappointed
https://www.garlic.com/~lynn/2001l.html#20 mainframe question
https://www.garlic.com/~lynn/2001l.html#24 mainframe question
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
https://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#36 Movies with source code (was Re: Movies with DEC minis)
https://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2002.html#53 School Help
https://www.garlic.com/~lynn/2002b.html#35 bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
https://www.garlic.com/~lynn/2002b.html#46 ... the need for a Museum of Computer Software
https://www.garlic.com/~lynn/2002b.html#48 ... the need for a Museum of Computer Software
https://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
https://www.garlic.com/~lynn/2002f.html#14 Mail system scalability (Was: Re: Itanium troubles)

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Computers in Science Fiction

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in Science Fiction
Newsgroups: alt.folklore.computers,alt.history.future,rec.arts.sf.science,rec.arts.sf.written
Date: Tue, 16 Apr 2002 00:27:36 GMT

Lee DeRaud writes:
[snip of dozens of FSD-related references] Aside from the fact that almost everything you talk about came well after the time period I was referring to, I think you've actually reinforced the point I made above.

not sure when you are referring to ... the GML stuff would have been early '70s. The original air traffic control system was mid-60s (i.e. cambridge wanted 360/50 for special relocation hardware project for the precursor to cp/67 ... but couldn't get them because all the spare ones were going to the FAA project ... so cambridge had to settle for 360/40 ... and so the precursor to cp/67 was called cp/40).

BCS (boeing computer services) was originally formed around CP/67 systems (360/67) in the late '60s. GML was an enhancement to the standard CMS document formater (script) in the very early '70s. BCS also used it ... including some amount of formating documents for gov. projects in the '70s. I believe one pitch that BCS made at SHARE in the '70s was (at least the first and possibly all of the) USPS stamp price increases in the '70s included a contract where BCS did all the financial modeling work using CMS/APL (justifying the price increases) as well as a lot of the documents needed to be presented to various gov. organizations.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Security and e-commerce

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security and e-commerce
Newsgroups: alt.computer.security
Date: Tue, 16 Apr 2002 13:44:19 GMT

sabrinaong2002@yahoo.com.au (Sabrina) writes:
My view is that security is the foundation of e-commerce. Without it, there can be no spontaneous formation of trust relationships among the consumers and e-commerce company. Do you agree? Or do you have different view?

possibly assurance (and trust) is the foundation of e-commerce (actually almost any kind of service offering) ... a customer also won't come back if things are unreliable and don't work ... and wouldn't really care whether things aren't working because of DOS or just poor workmanship. consumers can get upset if somebody steals a credit card master file ... but they can also be upset if a credit card master file is sold for various marketing or business reasons.

random refs:
https://www.garlic.com/~lynn/subintegrity.html#assurance
https://www.garlic.com/~lynn/subintegrity.html#fraud

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Biometric Encryption: the solution for network intruders?

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric Encryption: the solution for network intruders?
Newsgroups: comp.security.misc
Date: Tue, 16 Apr 2002 13:53:37 GMT

lajavakom@yahoo.com.au (Leela) writes:
I'd like to thank you again for your contributions on this topic.

Moreover, I'm questioning about Biometrics and the Internet. The Internet represents an interesting area as regards personal privacy and identity authentication.

as an aside ... while it may not be the case here ... several of the computer design related newsgroups tend to get a number of people asking homework questions ... usually a new flurry at the start of a fall semester ... then drops off as they are advised to do their own homework ... picks up slightly again with the start of new semester and then drops off until the next fall semester.

some other threads on privacy
https://www.garlic.com/~lynn/subpubkey.html#privacy

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Security and e-commerce

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security and e-commerce
Newsgroups: alt.computer.security
Date: Tue, 16 Apr 2002 14:01:52 GMT

sabrinaong2002@yahoo.com.au (Sabrina) writes:
Firstly, I would like to introduce myself. I'm currently doing Masters of Information Management and Systems. The course provide knowledge and skills in the management of information and the development of information systems. I find that participating and interacting in a chat group can enchance my knowledge in this area. I hope we can exchange views on the issue below.

also in case this might apply:
https://www.garlic.com/~lynn/2001l.html#0 Disappointed

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Security and e-commerce

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security and e-commerce
Newsgroups: alt.computer.security
Date: Wed, 17 Apr 2002 03:05:44 GMT

"Joe Fitzsimons" writes:
Encryption is the key for ecommerce. Then you don't need to be to worried about people sniffing passwords and credit card numbers being passed over the internet. At the moment, too many sites just POST sensitive data without encryption. Public cryptography allows people to transfer sensitive data without ever having to agree on a secret key. This allows secure communication between people who may never have met. Using a proven scheme, such as RSA640 or higher, or El Gamal, you can be sure that noone, even most governments, could access the data in transit.

x9.59 is finance industry standard (using financial standards body x9) and has been promoted to iso (aka internation) ... at this point at least iso8583 having new field to carry the x9.59 data.

the requirements & charter given the x9a10 working for the x9.59 standard was to preserve the integrity of the financial infrastructure for all electronic retail payments (debit, credit, stored-value, atm, e-check, etc in all environments, internet, pos, non-internet, etc) w/o the use of encryption (aka even if there is absolutely no encryption of an x9.59 transaction ... including any account number ... there would not be information necessary for a fraudulent transaction from any evesdropping).

misc. x9.59 refs:
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

random refs:
https://www.garlic.com/~lynn/subintegrity.html#assurance
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/subintegrity.html#fraud

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Security and e-commerce

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security and e-commerce
Newsgroups: alt.computer.security
Date: Wed, 17 Apr 2002 14:56:11 GMT

sabrinaong2002@yahoo.com.au (Sabrina) writes:
Futhermore, when consumer lack of confident in their credit card information being protected, it will then, loss trust in e-commerce transaction. Again, security take place before trust can be build between the consumer and e-commerce company. Without security, there can be no formation of trust relationship between previously unknown parties, nor can there be guarantees of non-repudiation of e-transactions.

current e-commerce use of SSL only protects data in-flight between consumer and merchant. the stories in the press about credit card information is frequently about the compromise of the merchant's credit card master file either by insiders or outsiders (the incident of credit card problems where SSL wasn't used and there was an evesdropping compromise is insignificant compared to the other exploits).

a couple refs about the current system:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

x9.59 was intended to provide end-to-end security w/o encryption to all electronic payments regardless of type (credit, debit, stored-value, e-check, atm, etc) and method (internet, point-of-sale, etc). the advantage of x9.59 is that it protects the integrity of the financial infrastructure in the complete end-to-end processes (including data at rest in merchant credit card master files that might be subject to access by insiders or outsiders). misc. x9.59 refs:
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

furthermore, it is unlikely that many of the existing points of failure will ever be reasonably addressed w/o something like x9.59
https://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
https://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror4 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#rhose17 [Fwd: Re: when a fraud is a sale, Re: Rubber hose attack]
https://www.garlic.com/~lynn/aadsm10.htm#cfppki13 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
https://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
https://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
https://www.garlic.com/~lynn/aepay7.htm#netsecure some recent threads on netbanking & e-commerce security
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure3 financial payment standards ... finger slip
https://www.garlic.com/~lynn/aepay10.htm#20 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card help online shopper to feel more secure?
https://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001k.html#55 I-net banking security
https://www.garlic.com/~lynn/2001l.html#2 Why is UNIX semi-immune to viral infection?
https://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002e.html#5 What goes into a 3090?
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002e.html#37 Would the value of knowledge and information be transferred or shared accurately across the different culture??????
https://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#28 Security Issues of using Internet Banking

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: alt.folklore.computers
Date: Wed, 17 Apr 2002 23:48:18 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Isn't this in effect what Multics was doing in the '60s? Different implementation, but AFAICT "files" were just treated as mappable memory segments with names.

it was also what tss/360 was doing back in the '60s (course tss/360 sort of lost out to cp/67) random refs:
https://www.garlic.com/~lynn/2001i.html#32 IBM OS Timeline
https://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline

melinda's paper goes into some of the stuff that when ibm lossing the project mac (multics) bid, tss/360, ctss, cp/40, cp/67, etc
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist

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

Playing Cards was Re: looking for information on the IBM 7090

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Playing Cards was Re: looking for information on the IBM 7090
instruction set
Newsgroups: alt.folklore.computers
Date: Thu, 18 Apr 2002 00:13:52 GMT

haynes@alumni.uark.edu (Jim Haynes) writes:
The minicomputer companies wrote operating systems that were terminal oriented from the ground up. I once saw some notes by George Mealy comparing OS/360 with what was then the PDP-10 operating system. Does anybody have a copy of that? He had a lot of interesting things to say, but one point that came through was that the PDP-10 was a terminal-oriented system through and through, and OS/360 was batch card-oriented.

pdp/10 was machine ... os/360 was an (number of) operating system. system/360 were machines. terminal oriented system for 360 were tss/360, cms, mts, varios other. there were also a number of os/360 system add-ons that were class of CRJE ... conversational remote job entry .... aka terminal interactive operations around card oriented environment.

as an undergraduate i had replaced some of the RJE code in HASP (circa 1968) with TTY & 2741 support with syntax from CMS editor ... for preping "cards" for os/360. The ibm terminals were half-duplex ... either send or receive ... but not both. The TTYs were full-duplex and were more of a challenge to map into 360 world.

I was involved in project that took a Interdata/3 and used it to emulate an IBM control unit (reverse engineering ibm channel protocol and building our own channel card). this supposedly originated the ibm pcm controller business. We had some additional agility to supporting full-duplex TTY operation using the Interdata/3.
https://www.garlic.com/~lynn/submain.html#360pcm

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

Playing Cards was Re: looking for information on the IBM

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Playing Cards was Re: looking for information on the IBM
7090instruction set
Newsgroups: alt.folklore.computers
Date: Thu, 18 Apr 2002 15:34:56 GMT

jchausler writes:
At CMU in the late 60's running OS/MFT on a 67, along with HASP, the TTY's although set up for full duplex, the attached modems IIRC had a full/half switch which when set to half worked fine with the supported CRJE system. Not being an "IBM person" I don't know the details but I thought the CRJE system was supported by HASP, not the basic OS/MFT but again, I could be wrong. There were different dial in lines for the 2741's as I recall the baud rate was frozen for specific lines. I designed and built a set of rack mount 8 channel 103A modems for this system (as well as the PDP-10) and I recall there were two different "rotaries" for the 360, one for the 110 BPS TTY's and one for the 150 BPS 2741's.

at the time I modified hasp ... hasp only had RJE support ... and didn't support interactive terminals.

one of the reasons that we started our own terminal controller project was specifically the standard ibm controller had hardwired the oscillator (fixed the baud rate) ... even tho the rest of the controller you could reset the line-scanner associated with each line.

CP/67 had some dynamic code to recognize 1050 or 2741 (and different kinds of 2741) ... as a result they could all share the same modem pool. When I first got CP/67, there was no TTY support .... so I had to implement it. I originally implemented it so that CP/67 could dynamically recognize 1050, 2741, & TTY and in theory allow all to share the same modem pool. During testing everything worked ... until ibm told me about the "short-cut" done with the oscillator (2741/1050s were 134.? baud).

It was at that time that we started our own terminal controll project:
https://www.garlic.com/~lynn/submain.html#360pcm

there was a buffer-length design flaw in my TTY implementation. I had done one byte arithmetic to determine amount of data coming in on a TTY line ... since there were no TTYs with lines longer than 72 (or 80) characters. It was possible to change max. line length for different kinds of devices ... but doing that simple change ... didn't catch the problem with one byte arithmetic. MIT system crashing 27 times in one day (I think it was for either an ascii plotter or a ascii vector graphics terminal ... any something with much longer line length than standard tty):
https://www.multicians.org/thvv/360-67.html

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

Playing Cards was Re: looking for information on the IBM

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Playing Cards was Re: looking for information on the IBM
 7090instruction set
Newsgroups: alt.folklore.computers
Date: Thu, 18 Apr 2002 15:40:34 GMT

Anne & Lynn Wheeler writes:
CP/67 had some dynamic code to recognize 1050 or 2741 (and different kinds of 2741) ... as a result they could all share the same modem pool. When I first got CP/67, there was no TTY support .... so I had to implement it. I originally implemented it so that CP/67 could dynamically recognize 1050, 2741, & TTY and in theory allow all to share the same modem pool. During testing everything worked ... until ibm told me about the "short-cut" done with the oscillator (2741/1050s were 134.? baud).

more detailed secription of 2741, 1050, teletype 33, & teletype 35.
https://www.garlic.com/~lynn/2001.html#15

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

e-commerce future

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: e-commerce future
Newsgroups: comp.society.futures
Date: Thu, 18 Apr 2002 19:57:22 GMT

thugloves@hotmail.com (Martin) writes:
hi, my name is Martin i've been reading books about e-commerce and i actually have studied the subject in my course however, i have many issues about e-commerce that i want to talk about first is the exact definition of e-commerce? many books including sources from the web has not clear in defining e-commerce so, another question is arise: what is the different between e-commerce and EDI ( electronic data interchange ) if e-commerce is the commerce through the net then it should be called internet commerce if e-commerce stands for electronic commerce than we can say that edi is also e-commerce because when we use edi for example in supermarket we actually transfering money electronically through electronic interface

please give me your oppinion about this issues thanks

is this a homework assignment?
https://www.garlic.com/~lynn/2002f.html#32

they started calling internet credit card transactions "e-commerce" ... but it has been expanded into all sorts of other stuff. i think i saw something about western union claiming to be the original e-commerce company ... starting electronic money transfers something like 100 years ago.

x9a10 working group was given the charter/requirement for the x9.59 financial standards work to preserve the integrity of the financial infrastructure for all electronic retail payments (debit, credit, e-check, ach, atm, stored-value, etc) in all environments (point-of-sale, internet, non-internet, etc).

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Fri, 19 Apr 2002 14:20:43 GMT

"John Homes" writes:
It's impossible to do it if the executable needs massaging in some way to be loaded.

E.g. relocations on S/360 and its sucessors. As I recall, VM enabled you to build executables (called something else, but I recall not what) that could be used in that way but the price was that the (virtual) load address was fixed at build time.

There is a lot of other stuff within an MVS executable that the loader needs to play with as part of the load. So the virtual memory subsystem cannot do it.

RLD entries ... relocatable load directory ... basically locations in the program that have addresses that are related to an ESD ... external symbol directory. The loader resolves the ESD addresses then goes after all the RLD entries.

MVS didn't originate as a virtual memory system ... it originated as a real storage system ... that eventually got everything laid out in a virtual address space ... even to the paradigm that the kernel code and the application code co-exists in the same address space (although that has slowly mitigated over the years). For years, MVS struggled with various kernel &/or services code getting larger & larger ... impinging on the remaining address space left to applications (especially with 24bit/16mbyte area).

CMS was a single user interactive monitor that ran in virtual address spaces provided by CP/67 ... but used a lot of OS/360 applications (most of the compilers, applications, etc). For both CP/67 and VM/370, CMS had certain high use code that was "shared" ... i.e. same page occurred in multiple different address spaces (aka reduces real storage & paging requirements) ... however these originally were single fixed definition.

I wrote some enhancements to CMS & VM/370 that supported effectively shared libraries ... additional shared code/pages that could be introduced in virtual address space "on the fly". I even sanitized some amount of CMS & CMS application code to live in shared pages ... and did it in such a way that it eliminated all RLD entries (i.e. the same shared code could live at different addresses simultaneously in different virtual address spaces). The CMS code was eventually shipped as original designed/written. However, only a subset of the VM/370 kernel support eventually shipped ... which didn't include the ability to position shared pages at arbritrary locations in different address spaces.

The scenario is that in 24bit/16megabyte address space ... it wasn't that frequent that any single process needed a combination of (different) shared library code that exceeded the process's virtual address space. However, it was the case with global fixed address per shared library ... that an installation would find that it couldn't choose a unique virtual address range for every shared library that their user community might want. The result was that installations had to eventually assign duplicate addresses to some shared libraries ... meaning that there were certain combinations of applications (at least in shared library format) that weren't possible.

past postings giving RLD & ESD format details:
https://www.garlic.com/~lynn/2001.html#8 finding object decks with multiple entry points
https://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)
https://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
https://www.garlic.com/~lynn/2001c.html#87 "Bootstrap"
https://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)

general virtual memory references:
https://www.garlic.com/~lynn/subtopic.html#wsclock

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: alt.folklore.computers
Date: Fri, 19 Apr 2002 14:30:58 GMT

Charles Shannon Hendrix writes:
I know quite a few older machines did this, but a lot of that was simply that they didn't have drives and things like filesystems were too computationally expensive.

But what I'm talking about is a move to memory only in the presence of cheap and expansive alternate storage, or maybe just integrating drives fully into the memory map. No swapping, the data on them, floppies, anything has an address.

tss/360 implemented single level store paradigm (for 360/67) ... but it was not a real rousing commercial success and eventually died out (it did see some renewed life inside AT&T as TSS/370 as base kernel for a mainframe unix). In the '70s, FS (future system) project invested heavily in single level store architecture ... but it was canceled after huge resources but before it ever became reality or shipped to customers.

The "lore" is that some of the FS die-hards went off to rochester and implemented FS as the S/38 (including single level store). AS/400 is follow-on to S/38.

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

Foreign Cars (was: Computers in Science Fiction)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Foreign Cars (was: Computers in Science Fiction)
Newsgroups: alt.folklore.computers
Date: Fri, 19 Apr 2002 13:47:05 GMT

jmfbahciv writes:
Japan was the best thing that happened to Detroit. There was a reason that there was a gas station on every corner. My Dad is still driving a truck that takes 7 miles to the gallon.

there was a reason that there was a "service" station on every corner. from past threads:
https://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
https://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
https://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: alt.folklore.computers
Date: Fri, 19 Apr 2002 14:54:58 GMT

Charles Shannon Hendrix writes:
I was thinking that someone might have put some work into always demand loading from an executable during a page fault, to save memory on systems which are code heavy.

The stuff that I had done for CMS ... previous ref:
https://www.garlic.com/~lynn/2002f.html#41

for shared libraries ... the full set of changes included CMS filesystem managed by the CP paging subsystem. CMS mapping changes (program load) including giving some hints when the mapping was initially performed (straight demand page, synchronous fetch all or some, asynchronously start fetch for some or all) which the system looked at and then also checked current system load and resources ... and then decided what to do (which might be nothing ... leaving it all to demand page ... or it might be starting some asynchronous fetch for some or all and immediately starting program execution).

These additional set of changes weren't released in the standard CMS & VM/370 ... however they were incorporated into version of XT/AT/370. The problem was that the real storage for XT/AT/370 was severaly constrained ... some CMS executables were larger than the available real storage ... and the disks were slow (especially the XT disks with 100ms avg. access) so that complete module fetch by traditional I/O caused a lot of reading the portions of the program into virtual memory, filling up all of real storage, paging out, reading in more of the program, paging it out, maybe minute or so go by before the program was initialized and ready to start.

The page mapping eliminated all the reading in ... paging out, reading in, paging out ... and then when everything had been finally loading into virtual memory, going back and starting page fault for portions of the program (typically was stuff that was all not in the page file). The mapping just allowed the page fault to start. The issue is that should be adaptive ... given some amount of additional real storage and a program of any size ... it was more efficient to batch in program in larger than simple demand page chunks. Making it dynamic adaptive so the system could optimally adopt agilely to different configuration and load was the trick.

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

Biometric Encryption: the solution for network intruders?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric Encryption: the solution for network intruders?
Newsgroups: comp.security.misc
Date: Fri, 19 Apr 2002 18:03:53 GMT

Valdis Kletnieks writes:
Revoking a password is inconvenient, but can be done multiple times.

Revoking a thumbprint is painful, and you have limited options.

This needs to be kept in mind for any biometric security.

issue is whether it is used as a shared-secret or just a secret.

A "secret" (but not shared-secret) whether PIN or biometric can be used in conjunction with a hardware token ... where the correct operation of the hardware token is dependent on supplying the correct PIN/password/biometric.

A "secret" implementation can be far less onerous than a shared-secret implementation where (in the case of biometrics) may imply providing people with new thumbs when a compromise occurs.

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

Security Issues of using Internet Banking

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.folklore.computers
Date: Sat, 20 Apr 2002 04:38:45 GMT

lemonpillows writes:
The most vulnerable part of the internet banking service is the end users pc. Banking organisations can put in whatever security and encryption they like, but without securing your own pc from hacks/etc, that means nothing. I have found internet banking fine as long as you keep your anti virus files up to date and run an efficient firewall. (I would recommend zone alarm, which is free for home users). Any attempts to enter you pc are logged, and small boxes appear on ur desktop if anyone tries to enter ur pc. Vigilance is best, but it's no less safe than an ATM, or using your card in a store.

one of the reasons for the finread standard .... external certified device that had pin-pad cut-out for pin-entry (aka pins go directly from pinpad to card ... bypassing anything in the pc) and trusted display (what is being operated on is what is displayed).

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

How Long have you worked with MF's ? (poll)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How Long have you worked with MF's ? (poll)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 22 Apr 2002 13:08:27 GMT

spring semester '66 "Introduction to Fortran" class on 709 ... still have mcracken's book someplace. summer job '66 was porting 1401 MPIO program (i.e. ur<->tape front end for 709) to 360/30. they could run MPIO on 360/30 in 1401 compatibility mode ... but I guess it was a make work thing to have a 360 version that could do the same thing. I assembled under os/360 (pcp, release 6) ... but could run 1) os/360 with get/put system services, 2) os/360 to load but took over the machine and wiped out supervisor and had own interrupt handler and device drivers, 3) bps loader. When assembled using os/360 system services, the five DCB macros took six minutes each to assemble (added 30 minutes to the elapsed assemble time).

later worked on univ project with couple others to replace the 2702 communication controller; reverse engineered ibm channel ... built our own 360 channel card for interdata/3 minicomputer. has been credited with originating the 360 pcm controller market ... misc refs:
https://www.garlic.com/~lynn/submain.html#360pcm

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

How Long have you worked with MF's ? (poll)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How Long have you worked with MF's ? (poll)
Newsgroups: alt.folklore.computers
Date: Mon, 22 Apr 2002 13:40:55 GMT

Anne & Lynn Wheeler writes:
spring semester '66 "Introduction to Fortran" class on 709 ... still have mcracken's book someplace. summer job '66 was porting 1401 MPIO

i was looking thru some old books and ran across:
BLISS-11 Programmer's Manual

copyright 1972, 1973, 1974 by Digital Equipment Corporation

Apperson, Geschke, Hobbs, Johnsson, Knueven, Leverett, Weinstock, While, Wulf, Department of COmputer Science, CMU, Pittsburgh, Penn.

Brender, Pellegrini, DEC, Maynard, Mass.

BLISS-11 is a programming language for the PDP-11. Is is specifically intended to be used for implementing "System Software". As such it differs from other languages in several significant ways.

Clearly BLISS-11 is a close relative of BLISS-10 for the DECsystem-10 and shares much of that language's philosophy toward treatment of identifiers, absence of GOTO statements, importance of structures, etc. The interested reader may find it useful to examine the differences between the two languages and how these are reflection of the differences in the machines.

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Mon, 22 Apr 2002 16:08:37 GMT

hack@watson.ibm.com (hack) writes:
This observation does indeed kill the idea of generic read-ahead in a memory-constrained system (which late-70's Multics certainly was). In the case of an executable file and a file system capable of good sequential allocation, there is a difference however: those N memory pages will be required anyway -- a substantial fraction thereof, at least, in most cases. (In those days programs didn't contain as much dead space as in today's monster blobs.)

Michel.

the stuff I did for cms & cp (originally in the early '70s) ... had the CMS side of the API as advisotry and left CP to decide how best to fulfill the request based on load and configuration .... aka in some instances it would effectively do block read for all or some subset ... and in other instances it would just go with individual page fault from the binary image in the CMS filesystem (much more representative of xt/at/370 configuration), random refs:
https://www.garlic.com/~lynn/submain.html#mmap

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

Blade architectures

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: comp.os.vms,comp.arch,alt.folklore.computers
Date: Wed, 24 Apr 2002 13:40:36 GMT

Anne & Lynn Wheeler writes:
the stuff I did for cms & cp (originally in the early '70s) ... had the CMS side of the API as advisotry and left CP to decide how best to fulfill the request based on load and configuration .... aka in some instances it would effectively do block read for all or some subset ... and in other instances it would just go with individual page fault from the binary image in the CMS filesystem (much more representative of xt/at/370 configuration), random refs:
https://www.garlic.com/~lynn/submain.html#mmap

The other thing that I did was to support shared segments as part of the CMS program creation and then loading ... which had to extend the module format to include optional shared segment specification. This got more complicated in the API ... since CMS knows about symbolic things ... but the CP part of an API effectively only knows about hardware resources (like disk record addresses) .. and the security boundary between is between the CMS and CP API. In any case, I used the original disk record home location as the global "name" for the shared segment (allowing use across multiple CMS processes). In order for that to be reliably unique ... the other pages in the segment had to also have a predictable home location ... the easiest was to have them sequential incrementing. That created a problem since CMS normally just did bit-mapped scatter allocation ... to get contiguous, sequential allocation, I had to add a new interface to record allocation that would allocate a contiguous segment worth of records.

Since a optional header had been added for shared segment specification, we also looked at doing finer grain pre-page advisery ... using information gathered from vs/repack ... something we never actually got around to doing ... so it was left to CP guessing ... within the context of load and configuration at the time the operation was initiated.

vs/repack was some technology that the science center developed in the early 70s and was used on a number of products (like ims, etc) for "migration" to virtual memory operation and finally released as a product in the mid-70s.

D. Hatfield & J. Gerald, Program Restructuring for Virtual Memory, IBM Systems Journal, v10n3, 1971

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

markup vs wysiwyg (was: Re: learning how to use a computer)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: markup vs wysiwyg (was: Re: learning how to use a computer)
Newsgroups: comp.sys.intel,comp.os.vms,comp.arch,alt.folklore.computers
Date: Thu, 25 Apr 2002 14:24:09 GMT

Jan Ingvoldstad <jani+news-comp@nntp.ifi.uio.no> writes:
I don't have any formal background in this particular material (though some minor background with the theoretical parts as a part of my education), but I've worked supporting students of computer science for a few years, both with studies and technical issues. Contrary to popular belief, there are quite a lot of computer science students who have barely touched a computer before, so a lot of interesting reactions could be had. (Some times, I was more frustrated than actually interested. :)

markup derivative happens to be that one of the guys that added it to script in the very early '70s had a last name that started with M. script had been developed in the mid-60s and was something of a "dot" command derivative (like runoff). G, M, & L then came up with this other structure and added it to script as an alternative to the dot command stuff. Generalized Markup Language ... came about because of their initials G, M, & L. GML evolved into ISO standard as SGML (standard) in the late '70s (and then later things like HTML, XML, etc) . Script, GML, SGML at the Cambrigdge Science Center, 4th floor, 545 tech sq.

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

Mainframes and "mini-computers"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframes and "mini-computers"
Newsgroups: comp.arch.storage
Date: Thu, 25 Apr 2002 14:36:48 GMT

"Maxim S. Shatskih" writes:
Sorry, what "mainframe" is? I mean the _technical and architectural details_ of the computer and the OS which makes it a mainframe, not a "just computer". Is AS/400 a mainframe?

Also - what is "mini-computer"? Is it VAX? Am I right that the term "mini-computer" is obsolete a bit, and, among modern machines, things like Sun Sparcs or RS/6000 can be called such?

This newsgroup seems to be a fine place to ask this, I hope there are people with experience in both areas.

terms originated in a different time and place when there tended to be a much clearer delineation between different products. It was fairly obvious that most IBM 360s were mainframes and an Interdata/3 was a minicomputer.

I had worked on 360s in school ... and as an undergraduate was involved in a project that reverse engineered the ibm channel architecture and built a board for the Interdata/3. The Interdata/3 then was programmed to emulate an IBM (mainframe) telecommunication control unit (2702) ... in fact many of the boxes that might have been seen in a data processing center surrounding the mainframe ... would have been considered some form of minicomputer if they had been programmed differently (rather than as support controller services in support of the mainframe).

since that time the differentiation has gotten less clear. In the mid-80s a board came out that fit in a PC that would run as a mainframe (aka xt/at/370). The single chip processors have gotten much more powerful ... finding nearly identical power/pc chips in AS/400, apples, and RS/6000 (with lower power versions showing up as embedded devices in some game toys).

misc refs to 360 plug compatable market (PCM)
https://www.garlic.com/~lynn/submain.html#360pcm

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

WATFOR's Silver Anniversary

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: WATFOR's Silver Anniversary
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 26 Apr 2002 01:42:25 GMT

efinnell@SEEBECK.UA.EDU (Edward J. Finnell, III) writes:
This was more like I remembered it. We ran WATFOR on a 360/50 back in the '60's.

https://web.archive.org/web/20040211203259/http://csgrs6k1.uwaterloo.ca/sdtp/watfor.html

i had the task of installing watfor on OS/360 MFT11 system sometime in '67(?) running on a 360/67 (running mostly in 360/65 mode ... with some sporadic testing of 0.xx versions of tss/360). This was before getting a copy of cp/67 in jan68 at the university.

Prior to watfor ... we were trying to run student fortrang compile, link-edit, & go ... and it was taking on the order of 30 seconds elapsed time per student job (this was up significantly from time on the 709 ibsys). almost all of it was job scheduler processing time.

watfor introduced single step monitor ... started watfor as a single job-step and fed it a whole tray of student jobs (at 20-30 cards per student job ... it was possibly 100 jobs per run). This got things finally (along with HASP) down to shorter elapsed processing than was taking on the 709.

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

WATFOR's Silver Anniversary

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: WATFOR's Silver Anniversary
Newsgroups: bit.listserv.ibm-main
Date: Fri, 26 Apr 2002 01:30:29 GMT

Lockwood.Lyon@MEIJER.COM (Lockwood Lyon) writes:
I remember lots of requests for microcode on the 360/67, especially implementations of 'neat' assembler instructions. Ex: Search List instruction. Had (reaalllly stretching ...) six assumed registers, something like: R1 = Pointer to Beginning of Linked List; R2 = Node Size; R3 = Offset of forward ponter; R4 = Condition for Termination of Search, etc. So, you set up the registers and executed the instruction . . . and it did a search of a singly-linked list. Wakka, wakka!

search list was original lincoln rpq ... but was on a lot of 360/67s ... and even on the 67 "blue card".
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)

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

Security Issues of using Internet Banking

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Fri, 26 Apr 2002 14:24:45 GMT

Giles Todd writes:
I use one of these tokens at least two or three times every week with a Dutch Internet Banking service. As far as I can tell, it is an S-KEY calculator into which I insert my PIN pass (left- and right-pondians may know a 'PIN pass' as a 'debit card'). Once the card is inserted, I am challenged by the calculator for my PIN (or PIN Number, for those unfamiliar with the fact that the letters 'P I N' form an acronym in this context).

was at finread conference in brussels last summer with the company that makes the "calculator" cardreader demonstrating a finread reader. this week had a booth at cardtech/securetech for an AADS chip that I've been working on for the past 4-5 years:
https://www.garlic.com/~lynn/x959.html#aads

the company that makes the calculator cardreader was also in the booth with their "secure" reader (including its own pinpad and display).

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

crypto processor activity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: crypto processor activity
Newsgroups: bit.listserv.ibm-main
Date: Fri, 26 Apr 2002 17:42:10 GMT

Rob.Schramm@53.COM (Schramm, Rob) writes:
It is/was my understanding (with no extra pci crypto cards) that the crypto chips could sustain 150 ssl cypto operations per second. (each chip will do about 75). The triple-des performance of the chips is much better... to the tune of 100,000 operations per second. If Michael Kelly is listening on the list.. he might be able to expand more. If you add (and this info might be a little dated .. a year or two) 8 pci crypto cards .. you can do 2000 ssl crypto operations a second. Don't forget that the session beginning is where all the ssl crypto slows (asymetrical keys) down... maintaining it is pretty light (des).

slow-down isn't just the pki crypto-opts at session initiation ... but also the protocol hand-shake chatter for key exchange and certificate processing. somewhat related:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

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

IBM competes with Sun w/new Chips

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM competes with Sun w/new Chips
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,comp.arch
Date: Fri, 26 Apr 2002 20:47:04 GMT

edgould@AMERITECH.NET (Edward Gould) writes:
Introducing the most important piece of hardware in IBM's renowned battle with Sun Microsystems for the $21 billion Unix server market, Big Blue will endow its Power5 and Power6 processors an ability called "Fast Path" to take over tasks that software currently handles more slowly.

when I redid FLIH, dispatch, and couple other things in the '60s as an undergraduate, I referred to it as fastpath, fast svc reflect, fast redispatch, etc.

the stuff for VM on 158 was referred to as VM Assist (basically control reg with flag indicating that certain supervisor instructions should be executed using virtual machine semantics when in problem/non-supervisor mode).

the stuff for VM on 138/148 which actually dropped critical portions of the VM supervisor was referred to as ECPS. original work for selection of stuff for ecps:
https://www.garlic.com/~lynn/94.html#21

a superset of all that is now available as LPAR on all current machines.

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

Security Issues of using Internet Banking

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Issues of using Internet Banking
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Sat, 27 Apr 2002 14:53:50 GMT

Steve O'Hara-Smith writes:
I note that ATMs are very careful to make handing the cash over the last part of the transaction and ISTR early ATMs sometimes leaving handing the card back to the end - I suppose the banks got fed up posting cards back when people failed to complete the transaction.

i use to have offices in the lab where they developed the first ATMs. they still had this large vault area where they had kept the paper money from all over the world for testing cash dispensing.

one of the stories was an early field test had been right across the street from a mcdonalds and retrofits to stop accepting ketchup packets in the plastic card slot.

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

Blade architectures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blade architectures
Newsgroups: alt.folklore.computers
Date: Sat, 27 Apr 2002 14:49:01 GMT

Kragen Sitaker writes:
And, of course, KeyKOS was a single-level-store OS for the 370 and SPARC, which I seem to recall was somewhat of a commercial success in the 1980s. It wasn't the case that everything had an address in KeyKOS, though; although you could map any data into your address space if you had the proper access to it (just as you can in Linux with mmap()), that wasn't the normal way of operating.

keykos was the gnosis spinoff when M/D bought tymshare. it originally had all sorts of stuff for supporting service bureau operation. I still have gnosis description document ...

misc keykos/gnosis refs:
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
https://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001n.html#10 TSS/360

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

Mainframes and "mini-computers"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframes and "mini-computers"
Newsgroups: comp.arch.storage,alt.folklore.computers
Date: Sat, 27 Apr 2002 15:22:41 GMT

Malcolm Weir writes:
Absolutely. Going back to the IBM controllers, they could do things like search for data and return only matching records (e.g. CKD files). They would manage inter-system locks, multi-pathing, etc.

In short, most things that we now get excited about and call SANs, and then some!

The HSC was the DEC implementation (and thus the first minicomputer implementation) of this sort of "processor independant" storage system.

the airline control program (then ACP, and now called TPF, transaction processing facility) supported clusters. The fine-grain locking (rather than the gross device level researve/release) was introduced in the 3830 disk controller in the early '70s originally for ACP clusters.

when the a510 remote device adapter was enhanced to a515 so that ibm CKD disk controllers could be hung off them ... would be considered some of the first SANs. It allowed a variety of (super)computers to transfer data directly from/to disk ... the ibm mainframe acting as access controller could put control information in the a515 memory that did access control for the original 3rd party transfers.

later when the standards work was being done for HiPPI switches and IPI controllers, one of the issues was to also support access control and 3rd party transfer done in the a515 deployed systems.

the a510 emulated an ibm channel in a network environment (both local loop and telco extended with a710/a715s) where there was a family of processor adapters ... a220 for ibm channel (aka also provided early channel extender support further than typical data center perimeters). The problem with a510 and CKD controllers was that there was timing requirement with the "K" (of CKD) search data ... which was enventually solved when the a515 supported downloading the "k" search data into the local memory of the a515.

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

next, previous, index - home