2002 Newsgroup postings (03/01 - 03/12) Lynn Wheeler

2002 Newsgroup Postings (03/01 - 03/12)

VAX, M68K complex instructions (was Re: Did Intel Bite Off MoreThan It Can Chew?)
OS Workloads : Interactive etc
OS Workloads : Interactive etc
Chip Emulators - was How does a chip get designed?
IBM Mainframe at home
IBM Mainframe at home
IBM Mainframe at home
IBM Mainframe at home
Security Proportional to Risk (was: IBM Mainframe at home)
Security Proportional to Risk (was: IBM Mainframe at home)
IBM Mainframe at home
Security Proportional to Risk (was: IBM Mainframe at home)
Mainframers: Take back the light (spotlight, that is)
IBM Mainframe at home
Mainframers: Take back the light (spotlight, that is)
RFC Online Project
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
DASD response times
Mainframers: Take back the light (spotlight, that is)
Security Proportional to Risk (was: IBM Mainframe at home)
Security Proportional to Risk (was: IBM Mainframe at home)
looking for information on the IBM 7090 instruction set
iAPX432 today?
Security Proportional to Risk (was: IBM Mainframe at home)
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
2 questions: diag 68 and calling convention
Farm kids
LISTSERV(r) on mainframes
Jeez, garlic.com -
PKI Implementation
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
PKI Implementation
Mainframers: Take back the light (spotlight, that is)
Why?
Farm kids
Mainframers: Take back the light (spotlight, that is)
Why?
RAS & 2x/18m (was Re: On-die memory controller pros/cons?)
IBM Mainframe at home
SSL MITM Attacks
Speaking of Gerstner years
Hardest Mistake in Comp Arch to Fix
SSL MITM Attacks
Hardest Mistake in Comp Arch to Fix
Hardest Mistake in Comp Arch to Fix
Mainframers: Take back the light (spotlight, that is)
Mainframers: Take back the light (spotlight, that is)
Storage Virtualization
Hardest Mistake in Comp Arch to Fix
Hardest Mistake in Comp Arch to Fix

VAX, M68K complex instructions (was Re: Did Intel Bite Off MoreThan It Can Chew?)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VAX, M68K complex instructions (was Re: Did Intel Bite Off   MoreThan   It Can Chew?)
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 01 Mar 2002 20:46:54 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Yes, you can :-(

That is exactly the sort of nightmare optimisation that I keep railing against. If you start with a mathematically precise finite state interrupt model, there is no problem, but Topsy-like systems (most definitely including Linux and Windows XXX) are almost unanalysable. There then is usually a path that leads to inconsistency "but cannot occur".

When first coded, that may even be true. But, as people add features, put in other optimisations, fix bugs and so on, paths that cannot occur often start to become possible. And then to occur in practice, so you put in a bug fix to block that one, which may then enable another path as a side-effect.

people later adding features is a problem regardless ... especially when they haven't been thuroughly indoctrinated with the original design assumptions, trade-offs, & implementation.

as part of releasing the resource manager product, we developed synthetic workloads and automated benchmarking process (for validating/calibrating the resource manager) ... with some APL model code that looked at results of previous benchmarks and selected new workloads/configurations to be benchmarked (more than 2000 benchmarks over three month elapsed time).

For testing both inside & outside normal performance envelopes, some "heavy" synthetic workloads were defined that were 10-100 times more stressful than any observed in the wild (say a synthetic benchmark where the page fault service queue was so long that the mean service time for a single page fault was over one second). Several of these would "reliably" precipitate kernel failures because of shortcomings in various kernel serialization functions. As a result, I totally rewrote the kernel serialization functions ... including touching every piece of code that was remotely involved with queuing, suspension, delays, etc. It turned out that not only did the serialization clean-up eliminate all such failures but as a side-effect it also eliminate all cases of zombie/hung processes.

A side effect of customers that installed the resource manager, they also got the serialization function rewrites. The problem was that within three years some person in kernel development was adding a new feature which also re-introduced hung/zombie processes.

for long-term stability, KISS is better.

As an aside, having a hostile environment that frequently/reliably precipitates failures is strong motivation for cleaning things up. I was involved in putting operating system into the disk engineering labs where disk development and test went on. A single disk test cell generated more anomolous and error conditions in a 15 minute period than most customer shops saw in a year (and standard operating system MTBF was 15 minutes running with single test cell). The objective was to be able to support 6-12 disk test cells operating concurrently under operating system control ... where all possible failure modes and hangs in the kernel I/O support were totally eliminated. Side effect was that the disk engineers could blame hardware operation anomolies on the "software" and then I was dragged into diagnosing disk engineering problems.

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

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

OS Workloads : Interactive etc

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS Workloads : Interactive etc.
Newsgroups: alt.folklore.computers
Date: Sat, 02 Mar 2002 15:31:48 GMT

Anne & Lynn Wheeler writes:
head of lightweight fighter plane development ... not just F-16, but F-15, F-18, others. F20/tigershark even more so.

I suspected boyd had a big hand in the f20/tigershark. He was big on KISS, less costly and things like flight/maintenance time ration. The f-15, f-16, f-18 are much higher maintenance, complicated & costly planes than the f20.

There have some recent articles that with all the homeland defense flights the f15/f16 infrastructures are being stretched to the limits. While these planes could out fight f20 head-to-head ... the f20 was targeted to be more reliable & simple with much less maintenance (& cost) ... something that would be more than adequate for the homeland defense mission profile.

misc. refs:
https://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
https://web.archive.org/web/20020217104036/http://www.wpafb.af.mil/museum/research/fighter/f20.htm
http://www.military.cz/usa/air/post_war/f5g/f5g_en.htm

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

OS Workloads : Interactive etc

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS Workloads : Interactive etc.
Newsgroups: alt.folklore.computers
Date: Sat, 02 Mar 2002 15:53:34 GMT

Anne & Lynn Wheeler writes:
There have some recent articles that with all the homeland defense flights the f15/f16 infrastructures are being stretched to the limits. While these planes could out fight f20 head-to-head ... the f20 was targeted to be more reliable & simple with much less maintenance (& cost) ... something that would be more than adequate for the homeland defense mission profile.

from really old reference I found someplace (with respect to wings program on f16):
It would be interesting if Wings would do one on the F20. They were less successful. The F20 was "almost a F16", but 1/3rd to 1/4th the cost, significantly less maintenance time and the F20 required significantly lower-skill levels for the maintenance (down-time was significantly lower and turn-around was significantly faster). Unfortunately the overseas customers got caught up because the funding for US plane purchases was actually being funneled thru US aid assistence ... so the F16 actually would cost other countries less than purchasing F20s outright.

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

Chip Emulators - was How does a chip get designed?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Chip Emulators - was How does a chip get designed?
Newsgroups: comp.arch
Date: Sun, 03 Mar 2002 05:36:21 GMT

"Tim" writes:
Could someone point me to the key papers/reviews/events in the development of these large-scale emulators. I get the impression that the stages were these:

Hard wired: huge racks of TTL, such as the Amdahl "wall of logic", lasting up to approximately 1985? Logic was wired up to match the target chip netlist.

Firmware: (smaller) racks of FPGAs, such as the early Quickturn boxes. Were these invented by Quickturn? Lasting up to approximately 1995? The target logic hookup was emulated by either per-net wiring in the FPGAs, or by some sort of virtual-circuit architecture.

Software: (smaller again) racks of processors, such as the IBM/Quickturn Cobalt boxes. These seem to be the current orthodoxy. I guess the (multi-)processors include a comms function to handle the logic hookup.

As a side issue, is enough known about the architecture of Cobalt-style systems to evaluate them for the "most powerful computer in the world" crown?

There was also the LSM (logic simulator machine, or losgatos state machine) ... in the los gatos lab (bldg. 29). it was wall of rack-sized boxes. Most emulators had fixed clock ... but the LSM had clock specification ... usable for asynchronous chips & digital chips with analog circuits (like disk read/write heads). It was still being used into the late '80s for RIOS. high speed (HSDT) link between austin and los gatos, large austin logic file to los gatos, loaded into the LSM, results sent back to austin ... depending on queue, turn around could be couple hrs.

A follow-on(?) box was EVE (endicott verification engine, unlike LSM, had fixed clock) ... several were built and used around the company, large, very heavy box. Most mainframe boxes were designed that they would fit in standard elevator ... but not an EVE. Some of the RIOS work was also done on the EVE in san jose bldg. 86 (austin via los gatos/bldg. 29 to bldg. 86).

Somewhere between the LSM & EVE was a YSE ... but I don't know of the YSE being actually used.

ref:
http://citeseer.nj.nec.com/context/259717/0

from above
....to the DPGA. These designs were generally motivated to reduce the area required to emulate complex designs and, consequently, took advantage of the fact that task descriptions are small compared to to their physical realizations in order to increase logic density. The Logic Simulation Machine [BLMR83] and later, the Yorktown Simulation Engine (YSE) Den82] were the earliest such hardware emulators. The YSE was built out of discrete TTL and MOS memories, requiring hundreds of components for each logic processor. Processors had an 8K deep instruction memory (c = 8192) 128 bit instructions (n ....

Ted Burggraff, Al Love, Richard Malm, and Ann Rudy. The IBM Los Gatos Logic Simulation Machine Hardware. In Proceedings of the International Conference on Computer Design, pages 584--587, October 1983.

refs:
http://citeseer.nj.nec.com/riepe94ravelxl.html

random hsdt:
https://www.garlic.com/~lynn/subnetwork.html#hsdt

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

IBM Mainframe at home

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Mainframe at home
Newsgroups: alt.folklore.computers
Date: Mon, 04 Mar 2002 10:34:49 GMT

zaitcev@yahoo.com (Pete Zaitcev) writes:
The thread unravels into the area of 360s, and has a good chance to reach 1401 becofore it dies off. However, I really cannot afford something "really real" even if I wanted one. So, I am thinking about something smaller.

This is information which I found so far about "reasonable" boxes:

7437
The oldest small mainframe. Was undeservedly unsuccessful, so there is no chance to find one. May have no internal disks, so assumes block mux and an array.

"Racetrack"
possibly an alias of 7437.

Amdahl something
A precise ripoff of that was made by IZOT, Bulgaria, and I saw it. It was a box of a size of an under desk filing cabinet. But it used block-mux, which is a problem. Needs console diagnostic CPU of the same size as the machine proper (with CPU, core and channels all together), booting from 8inch floppies (PITA to prevent from bitrot). Probably impossible to find.

P/370
Board for PS/2 Needs some binary software for OS/2 or AIX to run. (rejected because Hercules does the same job better and uncool in general).

9370
possibly an alias for P/370.

P/390 & P/390E
Same as P/370, but faster and Linux capable. May make some sense if a good deal is found.

s390 Multiprise 3000 H50
Linux capable. Size seems ok. Uses IBM channel I/O, but perhaps can be used with PCI. Unfortunately, it is not completely obsolete yet, so it takes a LOT of money to get one.
http://www-1.ibm.com/servers/s390/multiprise/

The last entry seems to fit the bill the best, if only I ignore the price. So, perhaps I'll get one in 7 or 9 years when they get a bit cheaper on the second hand market.

-- Pete

7437 was (IBM Fellow) Beausoleil's A74 machine (separate box with connection to PC).

P/370 & P/390 were/are microchannel cards ... effectively follow-on to xt/at/370 ("washington") cards. There is image of p/390 card at:
https://www.leeandmelindavarian.com/Melinda#VMHist

9370 was endicott low-end 370 (departmental) mainframe.

some a74 press


IBM's VM/SP Device Cuts Mainframe Load

InfoWorld, November 7, 1988

by Sharon Fisher and Alice LaPlante

IBM is now shipping, on a special-order basis, a PS/2-based device
that runs the VM/SP mainframe operting system.

     The IBM 7437 VM/SP Technical Workstation device offloads technically
oriented, processor-intensive mainframe applications, such as computer-
aided design, engineering software development, and geophysical mapping,
IBM said.  The separate processor reduces the load on the mainframe and
provides a more consistent response time.

      The device consists of two parts: the 7437 processor itself, which
is a floor-standing unit, and a PS/2 Model 60, 70, or 80 that provides I/O
support to the 7437 processor.  The 7437 uses IBM-proprietary 32-bit
technology, said Marty Ziskind, an advisery engineer in the IBM Fellow
department.

      Users can run the 7437 as a stand-alone VM system, a host-attached
VM workstation, a host terminal attached to a VM or MVS host, or a PS/2
running DOS 3.3 or 4.0, Ziskind said.  The system is "multiple-user,
single-seat," he said.  "It's like a 9370 with one terminal."  Users can
toggle between VM and DOS sessions.  OS/2 and IBM's AIX implementation of
UNIX are not supported.

Software and the VM operating system can be downloaded from a 370
mainframe by emulating a 3270 terminal or through a Token Ring link.

     Programs written for the 370 can run on the 7437, assuming they
aren't timing-dependent and don't require specific features of the
mainframe models of the 370, IBM said.

A 7437 VM/SP Technical Workstation Interface Adapter Card is
installed in the PS/2 used for I/O.  The PS/2 is connected to the main
7437 unit via a special cable.  The speed of the 7437 varies depending
on the speed of the PS/2 used for I/O.

Users who plan to use the 7437 as an engineering workstation may
want to use the IBM 5080 Graphics System, the company said.  This includes
an MCA bus master adapter card for the PS/2 and a choice of several models
of the 5085 Graphic Processor Unit.

     Required software includes DOS 3.3 plus one copy of VM/SP, Release 5
and the IBM 7437 VM/SP Technical Workstation Host Server for the IBM 370
host servicing the 7437s.

     The IBM 7437 costs $18,100, with a 25-unit minimum.  The 5080 Graphics
System Hardware costs an additional $1,300. <sic>


PC WEEK, October 31, 1988

IBM'S SYSTEM/370 WORKSTATION (A74)

IBM WORKSTATION BRINGS POWER OF MAINFRAME TO MICRO CHANNEL
By J. Cortino

  IBM is quietly offering a new System/370 workstation
that gives users the horsepower of a 9370 host system in a
much smaller unit and at a vastly lower cost.

  IBM, which has not officially announced the workstation,
will show it to selected customers at the Autofact '88 trade
show in Chicago this week, according to Martin Ziskind,
IBM Fellow Department, an advisery engineer in IBM Kingston, N.Y.

The System/370 Technical Workstation consists of an
IBM PS/2 Model 60 or 80 and a floor-standing machine about
the size of a PC AT that contains System/370 mainframe
circuitry, IBM officials confirmed last week.

The system allows users to locally process high-end
applications, such as computer-aided design and manufacturing
(CAD/CAM), without having to go up to the mainframe, they said.

  "The appeal of the System/370 is that is lets end users
work with CAD/CAM software on a workstation," said Daniel
Caldwell, IBM's product marketing administrator for computer-
augmented design and manipulation (CADAM).  "It takes the load
off the mainframe and gives users more autonomy at the same
time."

Another key to the system, observers said, is its use
of the PS/2 and its Micro Channel architecture.  "The PS/2
is the disk drive, the memory and the keyboard for the
System/370," said Ziskind.  "In order for this whole
arrangement to work, the System/370 must link to the PS/2
through the Micro Channel bus."

"One of the best things about this, is that it looks
like something is finally going to make use of the Micro
Channel," said Thomas Foth, senior developer at Relay
Communications Inc., a software developer in Danbury, Conn.

The System/370 Technical Workstation links to the PS/2
via a cable and an interface adapter card.  The card is
connected to the Micro Channel bus in the PS/2.

The workstation can run Virtual Machine/System
Product (VM/SP) release 5 applications written for
System/370 mainframe environments, such as CADAM and
circuit-board design applications.

  The System/370 workstation can be configured in
four ways as a stand-alone VM workstation running IBM
System/370 mainframe applications, as a host-attached
VM workstation sharing mainframe resources; as a host
terminal connected to a VM/SP or MVS host locally or
remotely, and as a PS/2 running DOS.

IBM is offering the system as a "special bid"
processor only to qualified customers, and has no plans
at this time to offer the system to its entire customer
base, according to Ziskind.  "We want to sell it to
people who understand the VM environment," he said.

The System/370 workstation is priced at $18,100
and $19,400 depending upon configuration.  A 9370 Model 20,
the low-end model of IBM's mainframe line, can cost from
$40,000 to $70,000.


PC WEEK, October 31, 1988

THE WEEK IN REVIEW

MICRO CHANNEL FINALLY FINDS A PURPOSE IN LIFE

At last, it appears that we have reached the point where rumored
benefits of IBM's Micro Channel architecture are beginning to emerge.
Our Page 1 story about the oh-so-quiet emergence of an MCA-based
System/370 workstation shows how the MCA is critical to allowing
PS/2 boxes take on many personalities.

With the Micro Channel, a PS/2 can provide local I/O services
to VM-oriented, mainframe circuits - just as it can for traditional
PC setups.  The value of mainframe hybrids such as the 370
workstation can be seen in the expansion of software systems that
require deep integration between desktops and data centers, as is
noted in our Project Management Focus On, Page 78.

Perhaps that is why a passel of the heretofore timid MCA cloners
have finally gotten the courage to go live with their products.
Between Comdex/Fall and the end of the year, we can expect to see
a half-dozen or so PS/2-alikes.

Another reason the clones may be coming is that the PS/2
may find some hidden, but shockingly large, markets.  On Page 5,
analyst Peter Coffee - who advises Aerospace Inc., the U.S.
Air Force's civilian think tank, about PC systems - points out
how neatly MCA fits into the biggest PC procurement order in
history.

That other alternative standard, Unix, gets a lot of ink
again, too.  The operating system whose time may have come is
featured in a 30-page Special Section.  It's also the subject
of our editorial on Page 72, where we note that so many people
seem to be trying to improve Unix, they may just kill it with
kindness.  Paul Schindler argues in his Management by Objection
column that Unix euphoria may be dangerous to micro managers'
health.

  Other points of note:  In Software, Jim Forbes reports that
the dishy descriptor, 'groupware,' may already be passe.  It's
teamwork that's critical today.  There's a nifty combination
in Networking, Page 31: Fax and Tax, the integration of fax
systems and E-mail and networks designed with tax departments
in mind.

And for a colorful, high-res display of wide-ranging
responses to product possibilities and satisfaction, check
out this week's PC Week Poll of third-party EGA and VGA
boards.


FROM MANAGEMENT INFORMATION SYSTEMS WEEK, 11/7/88:

IBM Quietly Sells a VM Workstation

Single-User System, by Matthew Cain

NEW YORK - For the past two months, International Business
Machines Corp. has been quietly selling a single-user 370
architecture workstation that runs applications based on
the VM operating system.

IBM classifies the machine as a "special product" which
is not available through normal marketing channels.  A
customer has to contact an IBM salesperson and then requests
a price on the workstation.  In standard IBMese, the computer
is an RPQ product, for Request for Price Quote.

"It's like a speakeasy," Gary Smith, IBM's manager of
market development for the workstation, "you have to knock
three times."  He said IBM was not marketing the machine because
it was uncertain if demand would warrant a full-scale campaign.

The workstation, officially known as the IBM 7437 VM/SP
Technical Workstation, is actually a 370 architecture co-processor
connected by cable to a high-end PS/2 microcomputer.  The cable
is hooked up to a card which is inserted into the microcomputer.
In this fashion, the PS/2 performs all I/O, provides all DASD
(direct-access storage device) and contains all disk drives,
Smith said.

  The 370 co-processor, which is the same size and shape as
a floor-standing PS/2 model 70, is priced at $18,100, which
includes 16 Mbytes of memory and the right to copy the VM needed
for the operating system transfer are included.  The price does
not include the microcomputer.

  For an additional $1,300, a card is available that enables
the user to hook up IBM's 5080 graphics display system, which
is primarily used for computer-aided design and computer-aided
engineering (CAD/CAE applications.

Applications

Smith said the workstation would find applications
primarily in these fields because of the existence of
sophisticated software which was not yet available in
singer-user versions.  For example, Smith said the popular
design engineering software made by Cadam, Inc., Burbank,
Calif., was not available in a single-user version, yet
demand existed for such a product.

In fact, at last week's Autofact in Chicago (see related
story, page 11) Cadam was showing the 7431 VM/SP workstation
in its booth.  The machine was also seen in a booth sponsored
by Valisys Corp. Sunnyvale, Calif., as well as in IBM's booth.

 In selling the workstation, IBM has to overcome customer
resistance caused by a similar offering the firm had previously
brought out.  The AT/370 was an attempt also to download VM
to a single-user machine, in this case to the PC/AT.  However,
the machine was not a success because of limited DASD and limited
processing power and because the machine ran only a subset of the
VM operating system.

Smith said that, when dealing with potential customers,
he sometimes has to answer questions about "the perceived
deficiencies with the AT/370."  He said the 7431 VM/SP
"overcomes a lot of that" because it has six times the
processing power of the PC/AT, 10 times the DASD, and a
full-function VM operating system, VM/SP Version 5.

IBM has been using the machine internally for some
time, according to Dan Caldwell, IBM's product marketing
administrator for computer-augmented design and manipulation
(CADAM).  "IBM's commitment is to use what we sell and sell
what we use," he said.

Competition with 9370

Thomas Foth, a developer at software house Relay
Communications Inc., Danbury, Conn., who is familiar with
the machine, said IBM was not aggressively marketing the
workstation because it might cannibalize IBM's primary VM
platform, the 9370 departmental mainframe.  Because the price
of the workstation was about one-half the price of a low-end
9370, it might take business away from the larger system.

He said the attitude of the 9370 people was "don't
compete with my 9370; get off my turf."

  However, IBM's Smith disagreed.  He said the workstation
had the blessing of the 9370 developers and expanded the range
of the line.  "The market is saying we need another entry point'
to the 9370 line, he said.  He also noted that all other 9370
machines were multi-user systems."

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

IBM Mainframe at home

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Mainframe at home
Newsgroups: alt.folklore.computers
Date: Mon, 04 Mar 2002 17:04:11 GMT

Luis Fernandes writes:
This is going to sound like a silly question, but how did mainframes fare when the power was cut in the middle of its operation? Did the OS boot OK when the power came back on and did it just continue running where it left off (it had core mem, right)?

most did not, part of the issue wasn't so much the consistency of the stuff in core/memory ... it was the consistency of all the possible ancillary options that might have been "in-flight" when the failure occurred.

with respect to filesystem consistency, depends on the "mainframe". There is discussion of multics ... with unix type file system checking on power-up ... taking two hrs.

there is also discussion of 360/370 mainframe disk infrastructure that if the power failure happened in the middle of a write operation, there was enough power for the disk to complete the write, but there was situtions where there was not enough power to maintain memory and transfer the contents of memory to disk ... as a result the disk would be getting all zeros for completeing the write. for that failure mode, there was no indication that the write had failed to complete correctly ... in fact there was no disk read error indication at all.

this particular failue mode was one of the reason for the CMS EDF (enhanced disk file system) in the '70s. The CMS filesystem from the mid-60s always did "shadow" writes involving any changed metadata (master file directory information) records, but when it went to commit the shadow writes, it would rewrite record 4 (that included indication of the new version rather than the old). EDF used paired record 4/5 and would ping-pong writing the record. On any resume/reboot situation, EDF would read both records 4 and 5 and determine which was to be used (i.e. simplest was having version number at the end of the record). The majority of write failues would be caught be disk hardware and there would be some error indication on read (except for the power-failue, zero propagation problem).

The zero propagation problem wasn't intrinsictly a filesystem inconsistency problem involving huge amounts of cached and possibly altered filesystem metadata in memory that would possibly trickle back to disk possibly resulting in inconsistent filesystem control information. All of the metadata on disk was kept maintained consistently across multiple records. There was, however, this hardware issue.

A similar issue has been discussed regarding modern disks, many of which will guarantee an atomic write of a single record, aka either it is not written or it is written completely & correctly (faced with a power failure in operation). Even with modern disks guaranteeing atomic single record writes ... there are some number of situations where the filesystem is using a logical record size that is a multiple of a physical record ... potentially giving rise to a similar filesystem issue with incomplete or incorrect filesystem single "record" write in the face of a power failure ... where there is not a corresponding read error indication (one resume/reboot).

Note that the hardware disk failure issue could also have some impact on DBMS that maintain ACID properties (transaction either commits complete and consistent or doesn't happen at all) if such an incorrect writing of a DBMS log record resulted in improper handling on resume/restart.

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

IBM Mainframe at home

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Mainframe at home
Newsgroups: alt.folklore.computers
Date: Mon, 04 Mar 2002 17:09:27 GMT

John A. Stovall writes:
Did mainframes ever need UPS'?

The early CDC Cyber were very sensitive to power lose and you could end up having to reload all the files and users restarting jobs. Oh, the joys of the Cyber 72 and 6600 at SMU in the '70's during thunderstorm season. Conoco in Ponca City Oklahoma was even more fun with the 885 disk drives in a shared file system configuration between multiple mainframes (860's) which required the mainframes to be take down in a specific sequences or you would have major file problems.

Yes, Mainframes used UPS. This may be urban legend but I heard at China Lake there was a UPS there which was the power unit out of an old diesel electric Sub.

there is the one about the 6600 at berkeley and its shutdown from the '60s ... not because of power ... but because of thermal. the story as i remember was every tuesday morning about 10am the 6600 would (thermal) shutdown.

they eventually traced it to a loss of water pressure; a combination of the lawn being watered ... at the same time as a class break (and resulting nearly simultaneous large number of flushes).

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

IBM Mainframe at home

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Mainframe at home
Newsgroups: alt.folklore.computers
Date: Mon, 04 Mar 2002 17:33:33 GMT

lwinson@bbs.cpcn.com (lwin) writes:
The S/360 had a reasonably long lifespan before the S/370 was announced to replace (I think 6-7 years betwen announcements). But once S/370 hit, the changes became fast and furious--the S/370-xx5 models soon became the S/370-xx8 (ie 135 -> 138) models, and then the 4300 and 30xx series came out. I'm not sure where S/370 stops and S/390 begins. (The machine we're using today is a 96xx which I forget what. In contrast to the old days, almost everyone doesn't even know what specific model it is nor cares.)

things started out with the "mid-life kickers" (incremental modifications to existing machines) ... but effectively both the automobile industry and the mainframe industry were on similar seven year product design cycles.

The 303x were somewhere inbetween. The big thing in 303x was the channel director. Basically a 155/158 had integrated channels (handled six channels) ... effectively the processor engine was time-shared between the integrated channel microcode function and the 370 instruction set execution microcode function. A 303x channel director handled six channels (for >six channels, needed multiple directors) and was basically a repackaged 158 engine w/o the 370 instruction set microcode (aka dedicated to the channel function).

A 3031 was a 158 w/o the integrated channel microcode and reconfigured to work with a channel director (sort of a asymmetric two processor configuration). A 3032 was a 168 reconfigured to work with channel director. A 3033 started out as 168 wiring diagram mapped to newer chip technology that was about 20percent faster and had about ten times the circuit density/chip. The first pass at 3033 would have been about 1/5th faster than 168-3 but then there was some specific tuning of the logic to take some advantage of more on-chip operations ... which eventually pushed the 3033 to about 50percent faster than 168-3 by the time of first customer ship.

After that, things still continued on the seven year cycle ... but there were two teams, working in parallel producing products offset. The 3081 was the "158" team ... the 3090 was the "168" team.

The post "xx8" modules had less of a well defined continuum. The 4341 and the 3031 significantly overlapped:

slightly related automobile seven year cycle:
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/2001d.html#43 Economic Factors on Automation

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

Security Proportional to Risk (was: IBM Mainframe at home)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Security Proportional to Risk (was: IBM Mainframe at home)
Newsgroups: alt.folklore.computers,comp.security.misc,comp.security,comp.security.unix
Date: Mon, 04 Mar 2002 20:27:24 GMT

Anne & Lynn Wheeler writes:
After that, things still continued on the seven year cycle ... but there were two teams, working in parallel producing products offset. The 3081 was the "158" team ... the 3090 was the "168" team.

above from "ibm mainframe at home" thread in a.f.c
https://www.garlic.com/~lynn/2002d.html#7

with OT thread drift to security proportional to risk thread (somewhat e-commerce):
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???

in the early 70s there was a trade-secret document theft case regarding disk technology. The assertions was that the "disk clone" business took 12 to 18 months to reverse engineer, duplicate and bring product to market (after initial introduction of new product). The assertion was that the document thefts would potentially allow a clone manufactur to bring a product to market six months earlier ... representing possibly several tens of billions of dollars in revenue.

somewhere along the way, the judge supposedly raised the "swimming pool attractive hazard" issue (aka pool owner is responsible for bad things that happen in their pool unless they can demonstrate fences and other security measures proportional to determination of trespassers that might find the pool attractive); aka for legal remedy, have to demonstrate security measures proportional to the value of the trade-secret.

For actual disk hardware this was a secure compound with perimeter fence and guards at the gates, patrols inside the compound, secure building with door badge readers, enforced & audited policies about tail-gating, 2nd floor (above ground) machine room with even more restricted badge reader acces. Within the machine room, devices were housed in a "test cell" ... basically a small heavy steel wire mesh cage (maybe 5x5x7, reinforce steel floor, heavy steel wire mesh sides & top). Door to cage had combination lock and each cage had unique combination. Lots of audit procedures and patrols to assure that security was being followed. This is somewhat analogous to safe deposit boxes but with more layers of security and constant auditing procedures.

Documents were "candy-stripe" covers with registered confidential classification. Each copy of a document was numbered. Each page of a candy-stripe document had the document copy number embossed in large print on every page (basically faint background but the number was large print essentially filling the whole page) with legend "registered confidential, do not copy/reproduce" on every page (either 3800 background flash or special paper from secure printer).

Each copy was signed out to specific person and that person had to follow a lot of processes protecting the document which were also audited on regular basis. A person having registered confidential documents also had special secure file cabinat for storing the documents, their offices had sporadic audits after hours and there were periodic audits to verify that the person still had possesion of the document. Registered confidential document copies tended to number in the tens or at most few hundres.

For the 3081 there were a whole file drawer of "811" documents (from the date nov. 1978) that were registered confidential and had to demonstrate that every copy of every 811 document was managed with the highest/appropriate security processes. Even at that, there was some leakage and a fairly well publiciszed industrial espionage case related to 811 documents.

bringing back to merchant e-commerce sites thread ... would an attractive hazard be a defense with regard to hacking e-commerce servers that had insufficient security?

random registered confidential refs:
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
https://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)

random attractive hazard refs:
https://www.garlic.com/~lynn/aadsmore.htm#2527a RFC 2527 Physical Security Controls Question
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...

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

Security Proportional to Risk (was: IBM Mainframe at home)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Proportional to Risk (was: IBM Mainframe at home)
Newsgroups: alt.folklore.computers,comp.security.misc,comp.security,comp.security.unix
Date: Mon, 04 Mar 2002 20:41:12 GMT

Anne & Lynn Wheeler writes:
For the 3081 there were a whole file drawer of "811" documents (from the date nov. 1978) that were registered confidential and had to demonstrate that every copy of every 811 document was managed with the highest/appropriate security processes. Even at that, there was some leakage and a fairly well publiciszed industrial espionage case related to 811 documents.

another aspect was network & evesdroping security. While the internal network was larger than the arpanet/internet until sometime in the mid-80s, corporate guidelines required that all links that left physical site had to have link encryptors. At one time I heard somebody claim that the internal network had over half the link encryptors in existance in the world.

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

IBM Mainframe at home

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Mainframe at home
Newsgroups: alt.folklore.computers
Date: Mon, 04 Mar 2002 20:43:48 GMT

jata@jata-mj.net (Julian Thomas) writes:
Lynn, I think you have that backwards, to the extent that there were still 158 and 168 teams in that timeframe. Remember that FS and the 303x caused a great deal of team realignment. The project mgr for the 158 ended up on 3090 and ISTR that the 3081 had a lot of 168/3033 folks.

sorry, brain check ... i believe you've corrected me on that in the past.

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

Security Proportional to Risk (was: IBM Mainframe at home)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Proportional to Risk (was: IBM Mainframe at home)
Newsgroups: alt.folklore.computers,comp.security.misc,comp.security,comp.security.unix
Date: Mon, 04 Mar 2002 21:30:50 GMT

Anne & Lynn Wheeler writes:
another aspect was network & evesdroping security. While the internal network was larger than the arpanet/internet until sometime in the mid-80s, corporate guidelines required that all links that left physical site had to have link encryptors. At one time I heard somebody claim that the internal network had over half the link encryptors in existance in the world.

and the home/travel terminal/PC program had a special internal corporate encrypting modems. 1200 & 2400 baud modems & PC modem cards that would do session key generaion/exchange if it was talking to a corporate modem pool site (would act as normal modem otherwise).

one of the issues was that in the '70s, there was analysis highlighting hotel/motel phone switches as extremely high security risk (never allowed to do corporate email and/or other corporate internal network access from hotel w/o encryption).

there was joke/story about the initial modem that was demo/provided to high level corporate executive (who had been an old EE graduate). The story goes that it didn't seem to be working so he used his tongue to test for current in the modem's rj receptical ... just as it rang back (part of the home access security program also included "call-back" security). After that it was decreed that all modems manufactured by the company (whether for internal use or external sales) had to have the rj receptical recessed far enuf so that a corporate executive tongue was unable to touch the contacts.

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370
Date: Mon, 04 Mar 2002 23:40:26 GMT

rfcommsys@aol.com (RFCOMMSYS) writes:
Meanwhile, our Big Iron just keeps chugging away without breaking into a sweat. Mainframe security, reliability, and ability to handle massive amounts of data continues to be excellent, making the PCs look like mere toys.

almost anything can be used as a toy in the wrong(?) hands.

long ago, and far way there was a period where some number of mainframes had something like 30 percent of the workload coming from people playing adventure game.

random adventure refs:
https://www.garlic.com/~lynn/98.html#56 Earliest memories of "Adventure" & "Trek"
https://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#83 "Adventure" (early '80s) who wrote it?
https://www.garlic.com/~lynn/99.html#84 "Adventure" (early '80s) who wrote it?
https://www.garlic.com/~lynn/99.html#169 Crowther (pre-Woods) "Colossal Cave"
https://www.garlic.com/~lynn/2000b.html#72 Microsoft boss warns breakup could worsen virus problem
https://www.garlic.com/~lynn/2001m.html#14 adventure ... nearly 20 years
https://www.garlic.com/~lynn/2001m.html#17 3270 protocol
https://www.garlic.com/~lynn/2001m.html#44 Call for folklore - was Re: So it's cyclical.

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

IBM Mainframe at home

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Mainframe at home
Newsgroups: alt.folklore.computers
Date: Tue, 05 Mar 2002 06:20:42 GMT

Dennis Ritchie writes:
There is another story, heard from a Cray employee and a bit closer to contemporary, about a Cray 1 whose Freon cooling system failed and the temperature sensor wasn't working. Reportedly quite a few chips unsoldered themselves from their boards; the machine melted.

there was mainframe TCM machine that had internal coolant, heat exchange and external fluid coolent ... with a thermal sensor. There was interruption in the external fluid flow ... which started temperature rise and tripped the thermal ... but there wasn't enuf mass in the internal coolant to contain the heat before TCMs fried (and had to be replaced).

after that, flow sensors were installed on the external cooling system.

random tcm refs:
https://www.garlic.com/~lynn/2000b.html#36 How to learn assembler language for OS/390 ?
https://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
https://www.garlic.com/~lynn/2001k.html#4 hot chips and nuclear reactors
https://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
https://www.garlic.com/~lynn/2002b.html#3 Microcode? (& index searching)

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Tue, 05 Mar 2002 18:45:04 GMT

scomstock@aol.com (S Comstock) writes:
I've been thinking about the perennial cry of "the mainframe is dead" and what it means to us. Although we may laugh or pooh-pooh it, as insiders, I am afraid there is a very real danger of us mainframe oriented folks getting so insular we don't see the reality until it is too late.

The reality is, simply, we are allowing ourselves to be marginalized. In a company, everyone knows about the PCs around; when people talk about "the computer" they mean the PC. When management talks about spending money for IT, it's for PCs, JAVA, and the Web. When kids go to college / university to learn computer science, it's UNIX or Windows products.

Meanwhile, mainframes are quietly running the bread and butter applications of the business. Telephone companies are not going to email 10,000,000 customer bills each month, nor print them on 1,000 PCs lashed together.

a lot of the mainframe is trial & error experience learned over 30-40 year period of commerical business critical operation; some of it incorporated into base technology, other of it is just part of cultural experience of the staff.

part of the educational issue was new job growth ... aka unix & pc was growing market segment ... which generated lots of new job openings, which education filled. the other was in 70s and 80s cost of equiipment for educational instituations (some of the mainframe really deep educational discounts in the 50s & 60s were no longer available).

some observation in past postings regarding difficulty of finding experienced people needed for care & feeding of mainframe operations. Also correlary at some large organizations identifying that critical mainframe staff were nearing and/or had reached retirement age and difficulty of keeping them on the job was rated as one of the top (even #1) risks facing their business.

some past postings:
https://www.garlic.com/~lynn/2000.html#28 Homework: Negative side of MVS?
https://www.garlic.com/~lynn/2000.html#32 Homework: Negative side of MVS?
https://www.garlic.com/~lynn/2000f.html#11 Amdahl Exits Mainframe Market
https://www.garlic.com/~lynn/2001n.html#22 Hercules, OCO, and IBM missing a great opportunity
https://www.garlic.com/~lynn/2001n.html#50 The demise of compaq
https://www.garlic.com/~lynn/2001n.html#85 The demise of compaq

some of the personal 370s could have possibly been better positioned and priced for the educational market. slightly related ref:
https://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home

slightly related discussion (some with regard to the mini-computer market segment instead of mainframe; some similarities & some differences):
https://www.garlic.com/~lynn/2002c.html#0 Did Intel Bite Off More Than It Can Chew
https://www.garlic.com/~lynn/2002c.html#1 Re: Gerstner moves over as planned
https://www.garlic.com/~lynn/2002c.html#4 Did Intel Bite Off More Than It Can Chew
https://www.garlic.com/~lynn/2002c.html#19 Did Intel Bite Off More Than It Can Chew

there was actually an internal presentation in the '80s by the disk division claiming that its demise would be the responsibility of the communication division. some amount of the distributed/PC world started out with terminal emulation and screen-scraping. That worked well for emerging applications ... but as it started to mature it became a critical bottleneck for integrated PC/mainframe operation. As a result, more an more implementations started to copy & host critical business data at the PC ... rather than attempting to operate thru the narrow spigot provided by the communication division products. There was lots of internal in-fighting where the disk division wanted to provide significantly enhanced bandwidth capability to the desktop ... which would have bypassed the communcation division products (communication division had evolved large install base associated with terminal emulation and screenscraping that would have started to evaporate and been replaced with high performance disk division products). random refs:
https://www.garlic.com/~lynn/96.html#16 middle layer
https://www.garlic.com/~lynn/96.html#17 middle layer
https://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
https://www.garlic.com/~lynn/2000.html#6 Computer of the century
https://www.garlic.com/~lynn/2000b.html#35 VMS vs. Unix (was: Why are Suns so slow?)
https://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
https://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2000g.html#13 IBM's mess (was: Re: What the hell is an MSX?)
https://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
https://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
https://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#19 HP Compaq merger, here we go again.
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001l.html#17 mainframe question
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic: facts vs. FUD
https://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
https://www.garlic.com/~lynn/2002.html#2 The demise of compaq
https://www.garlic.com/~lynn/2002.html#7 The demise of compaq
https://www.garlic.com/~lynn/2002.html#11 The demise of compaq
https://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
https://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home

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

RFC Online Project

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: RFC Online Project
Newsgroups: alt.folklore.computers
Date: Tue, 05 Mar 2002 21:53:15 GMT

http://www.rfc-editor.org/rfc-online.html

also index:
https://www.garlic.com/~lynn/rfcietff.htm

misc. (old) rfc that recently went online:

7 -
Host-IMP interface, Deloche G., 1969/05/01 (4pp) (.txt=13408)

83 -
Language-machine for data reconfiguration, Anderson R., Harslem E., Heafner J., 1970/12/18 (12pp) (.txt=22253)

135 -
Response to NWG/RFC 110, Hathaway W., 1971/04/29 (2pp) (.txt=5784) (Updates 110)

137 -
Telnet Protocol - a proposed document, O'Sullivan T., 1971/04/30 (6pp) (.txt=19725) (Updated by 139)

186 -
Network graphics loader, Michener J., 1971/07/12 (21pp) (.txt=30557)

190 -
DEC PDP-10-IMLAC communications system, Deutsch L., 1971/07/13 (15pp) (.txt=24389)

192 -
Some factors which a Network Graphics Protocol must consider, Watson R., 1971/07/12 (21pp) (.txt=48540)

205 -
NETCRT - a character display protocol, Braden R., 1971/08/06 (14pp) (.txt=28272)

566 -
Traffic statistics August 1973, McKenzie A., 1973/09/04 (4pp) (.txt=6674)

582 -
Comments on RFC 580: Machine readable protocols, Clements R., 1973 -/11/05 (1pp) (.txt=1635) (Updates 580)

590 -
MULTICS address change, Padlipsky M., 1973/11/19 (1pp) (.txt=1436)

659 -
Announcing additional Telnet options, Postel J., 1974/10/18 (1pp) (.txt=2044)

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Wed, 06 Mar 2002 16:10:16 GMT

"Russell P. Holsclaw" writes:
I don't know... most of the bad programming habits I've seen in C appear to be the accepted idiom of the language. But that would be the subject of a whole separate thread that I probably don't have time for right now.

there has been numerous threads over the years that implicit string length convention in C has been the cause of a significant percentage of security and exploits in systems over the years (90+ percent at least up until the appearance of the automatic scripting viruses/trojans).

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

Mainframers: Take back the light (spotlight, that is)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: alt.folklore.computers
Date: Wed, 06 Mar 2002 16:13:32 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
"Russell P. Holsclaw" (russ@holsclaw.nyet) writes: >Lynn, >I remember hearing your name many times during my career at IBM ('66 to >'93). I hired into IBM when the System/360 was still new and remained for 26 >years, mostly working in connection with the RETAIN system and other IBM >internal systems.

Care to tell us about RETAIN ?

another system akin to RETAIN was HONE ... random stuff about HONE
https://www.garlic.com/~lynn/subtopic.html#hone

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Wed, 06 Mar 2002 16:42:04 GMT

CBFalconer writes:
Whats the skip-list algorithm?

dr. dobbs had a sequence of articles on it a couple years ago, you might even be able to find it on their site. The code is (at least) on their algorithm cdrom
http://www.ddj.com/

although I don't see it listed in online algorithm articles
https://web.archive.org/web/20020211235326/http://ddj.com/topics/algorithms/articles/

but it is listed under 1994 articles (by author of applied cryptography)
SKIP LISTS

by Bruce Schneier

Skip-list algorithms are generally faster, simpler to implement, require less memory, and are more versatile than balanced-tree algorithms. Bruce examines skip lists and shows how you can squeeze even more performance out of them.

==================================================================

There was a vs/pascal library for red/black trees (I believe from somebody in rochester) in the early '80s ... that I used in a project migrating code from cp kernel assembler into virtual address space pascal (and making it run up to ten times faster):
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)

there is luther woodrums radix partition tree stuff and his sort/list hardware instructions:
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7

there has been a lot of sci.crypt n.g. (and other places) discussions/posting recently with regard to Bernstein's paper on numeric field sieve, radix sorting, and finding RSA private keys:
http://slashdot.org/articles/02/02/26/179206.shtml?tid=93 more on factoring breakthrough

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Wed, 06 Mar 2002 16:59:29 GMT

Brian Inglis writes:
OTOH there was CKD. ;^> Even small and medium range disk controllers and drives nowadays have equivalent functionality to 3880/3990 and 3380/3390, and multiple I/O busses in some architectures remove the biggest bottleneck, besides lousy code.

some old refs to 360 PCM controller market
https://www.garlic.com/~lynn/submain.html#360pcm

misc. mainframe disk discussion:
https://www.garlic.com/~lynn/subtopic.html#disk

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

Mainframers: Take back the light (spotlight, that is)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Wed, 06 Mar 2002 17:44:18 GMT

nospam writes:
If by "multiple volumes" you mean more than 1 physical drive, IBM AIX has been able to have a single file "span multiple volumes" for many years.

NetBSD has been able to do this for many years as well, at least since 1995.

aix3 with rs/6000 came out with it in the logical volume (LVM) support in late '80s allowing a volume/filesystem to span multiple physical disks ... it also was the earliest(?) unix journaling filesystem ... again in the late '80s. LVM support could be configured for mirroring.

it was one of the things that my wife and I built HA/CMP off of
https://www.garlic.com/~lynn/subtopic.html#hacmp

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Wed, 06 Mar 2002 20:10:50 GMT

hancock4@bbs.cpcn.com (Lisa nor Jeff) writes:
If a large IBM shop, which can employ up to 1,000 application and system programmers (as well as operators) were to convert to Unix, what would be required to convert the thousands of COBOL, Fortran, PL/I and even old RPG programs it has in service? How about all the JCL?

when i was in school ... we had a 360 cobol program that had been converted from 709 cobol which emulated a 407 "plug board" program ... the 360 cobol program even printed out the 407 "sense" settings at the end of execution.

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

DASD response times

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DASD response times
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 06 Mar 2002 20:33:33 GMT

kburrow@CSC.COM (Ken Burrow) writes:
A client is concerned that some of his DASD, which is not currently being used, has rather long I/O times (108ms, most of which is connect time). He's getting the response time stats from Omegamon, and an analysis of the volume shows 0 open DCBs, 0% device busy, yet these long I/Os. Does anyone know what could be causing these seemingly paradoxical statistics?

And, yes, I realize that elongated I/O times on unused DASD is going to have 0 effect on throughput -- he just wants this explained.

lets say that there is concatenated PDS program/load library ... which is causing search of PDS on the otherwise "unused" disk (aka does unused mean nothing on the drive, or just nothing that is known to be used on the drive?) for program that is in some PDS that is later in the search ... and on a different volume.

lets say that PDS directory is a full cylinder and the PDS member search is doing a multi-track operation ... the elapsed time for each I/O is the number of tracks on the cylinder times the track rotation speed.

note that in olden days, multi-track search not only tied up the disk drive, but the controller & channel path also (not just a disk resource issue, but also controller and channel contention). The other issue might be the elongated time to actually find the program for loading.

something analogous might be happening if something was causing a vtoc search on the drive.

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Thu, 07 Mar 2002 05:49:20 GMT

Randy Hudson writes:
Absolutely. Brooks's _The Mythical Man-Month_ documents how the scaling problem nearly defeated a phenomenally good group of programmers, almost exactly 35 years ago. And while the mainframe world has fought hard, I wouldn't claim the problem has been "solved."

One converse is the claims by the tss/370 people. Brooks' paradigm (aka 9 inexperienced, non-pregnant people can produce a baby in one month, while it takes a pregnant woman 9 months) definitly applied to tss/360 when there were supposedly something like 1200 people working on it (in mohansic?). The claim has been when tss/360 was decommuted and the group reduced to only 30 or so people that tss/370 got significantly better fast (sort of inversely proportional to the number of people, or the amount of work expands to keep all the people busy).

aka ... they fell on their sword with a large group ... but re-emerged with a pretty good product when the size of the group got cut by a factor of 40 times (unfortunately the "product" wasn't able to really recover from earlier history).

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

Security Proportional to Risk (was: IBM Mainframe at home)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Proportional to Risk (was: IBM Mainframe at home)
Newsgroups: alt.folklore.computers
Date: Thu, 07 Mar 2002 06:02:05 GMT

Lars Poulsen writes:
I'm sure there were regional differences to this. In Texas, I'm told, it is traditional to used barbed wire. In my native Denmark, it was a 16-gauge galvanized steel wire. The pulse generator would send a 3 KV pulse about once a second. We'd walk the fence periodically and trim any weeds that reached up near the wire. Often you could hear them buzz as you approached.

in montana as a kid i strung both barb wire and 16-gauge(?, seems about right, but it has been a long time) galv. steel wire for electric fences (course, strung barb wire for non-electric also).

remember fence pliers? how 'bout fence stretcher? The one thing I remember about was being very careful not to get a kink in the wire when laying it out. If there was knick or kink in the wire when you were streching it, it could break under the tension of pulling it really tight ... and then you better look out.

simple repairs on barb wire ... typically just grabed it with the fence pliers and sort of leaveraged it around corner post to pull it tight ... didn't use the fence stretcher (kind I used looked a little like a pully with a rachet handle).

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

Security Proportional to Risk (was: IBM Mainframe at home)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Proportional to Risk (was: IBM Mainframe at home)
Newsgroups: alt.folklore.computers
Date: Thu, 07 Mar 2002 16:09:51 GMT

jmfbahciv writes:
I never did the work but I got to watch the male adults do a lot of it. I got to dig the postholes. Remember posthole diggers? There was one style that even a little kid could use.

corner posts you dig, steel posts you use a pile driver, basically a heavy 2in or so diameter pipe about 4 feet long that is welded shut at one end and extended with a 2 foot or so handle. The weld at the end has maybe a plate welded to add some weight. You stand up the steel posts and place the pile driver over the end and proceed to ram the post into the ground. For electric fence, you use insulator to attach the wire to the post.

when i was 11, my parents buddled me off to spend the summer with my grandmother and uncles on small farm in eastern montana (I had done this a couple times before).

they also had a couple trucks, a couple telephone poles for timbers, surplus jacks from the railroad and misc other stuff and moved houses as a side-line.

typical might be picking up a farm house way out in nowhere and moving it into town. you have a house driving down some back road and comes to a line of telephone wires. this is eastern montana and the roofs are pretty steep because of the heavy winter snows ... and the peak of the roof is higher than the wires. So my uncles send the kid up to the peak, he lays over the edge of the house and collects the wires in his bare hands as the house edges forward and lifts them above the peak. When he has all the wires (possibly dozen or so) in his hand, he walks the wires across the peak as the house moves under the wires and then drops them when he gets to the back of the house. this can be dangerous (and not just because one of the lines getting a ring); several years later one of my uncles fell off a peak of a house he was moving and was killed.

baling and other things, your hands get pretty insensitive/calloused. come 4th of july (kids don't try this at home, it is only for professional nuts) one test is lay firecracker in palm of your hand and light them (and you don't drop them).

--
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, 07 Mar 2002 16:12:16 GMT

Peter Flass writes:
It certainly impacted COBOL on the 1401 and PL/I on 360's. I came in at the beginning of the 360 era, but heard lots of war stories of long COBOL compiles on the 1401, which is why most 1401 stuff was written in autocoder. As for selling more memory of CPU, there usually wasn't any to cell. Memories came in one or two sizes, and CPU's in one speed. Upgrading usually meant moving to another incompatible architecture.

which was the point of 360s and a compatible hardware ...

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

iAPX432 today?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: iAPX432 today?
Newsgroups: alt.folklore.computers
Date: Thu, 07 Mar 2002 19:08:47 GMT

Enrico Badella writes:
In these days I was reading some olf iAPX432 docs I had around and other found on the net. I was wondering if with nowadays silicon and compiler technology the iAPX432 could have been more successfull? Just think about W2K on iAPX432... maybe there would have been less viruses...

there was a presentation at sigops ('79? ... last one that was held consecutively at asilomar) on i432. one of the issues they highlighted was that there was so much really high-level (effectively operating system) function in silicon that a major issue was being able to recast the silicon already in the field as bugs and enhancements were developed.

there is some similar between i432 and s38 ... now as400, s38 somewhat having regroupd with stuff from the canceled fs project). as400 had a high enuf machine abstraction (and actually quite a bit of programming between the application level and the bare silicon ... that it was able to make the transition to power/pc silicon (I believe somewhat easier transition than that of mac).

random past i432 refs:
https://www.garlic.com/~lynn/2000e.html#6 Ridiculous
https://www.garlic.com/~lynn/2000f.html#48 Famous Machines and Software that didn't
https://www.garlic.com/~lynn/2001g.html#36 What was object oriented in iAPX432?
https://www.garlic.com/~lynn/2001k.html#2 Minimalist design (was Re: Parity - why even or odd)

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

Security Proportional to Risk (was: IBM Mainframe at home)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Proportional to Risk (was: IBM Mainframe at home)
Newsgroups: alt.folklore.computers
Date: Thu, 07 Mar 2002 19:21:02 GMT

Anne & Lynn Wheeler writes:
corner posts you dig, steel posts you use a pile driver, basically a heavy 2in or so diameter pipe about 4 feet long that is welded shut at one end and extended with a 2 foot or so handle. The weld at the end has maybe a plate welded to add some weight. You stand up the steel posts and place the pile driver over the end and proceed to ram the post into the ground. For electric fence, you use insulator to attach the wire to the post.

the other pierce of hardware was a wrecking bar ... 1.5in to 2in diameter, 6foot long steel round steel bar, was pointed at one end and the other end had a 4in round disk wielded to the end.

for post hole digging ... you could use the pointed end for breaking up really hard ground ... and after the post was in, you used the disk end for tamping the dirt.

we also used it for jack handle. back when i was 11, i weighed less than half of what my uncles weighed ... so with three jacks on one side of the house ... I typically had to hang out on the end of the (wrecking bar) jack handle to get my jack to lift and keep up with my uncles.

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

Mainframers: Take back the light (spotlight, that is)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Thu, 07 Mar 2002 23:33:26 GMT

Charles Richmond writes:
This reminds me of T.J. Watson, Jr.'s "including the janitor" memo. He lamented that IBM could not produce a great super- computer despite all the people and resources thrown at it... and he wanted to know why.

random ref:
https://www.garlic.com/~lynn/95.html#13

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Thu, 07 Mar 2002 23:51:34 GMT

"Charlie Gibbs" writes:
I always wished that there was a "sense device type" command. That would have greatly simplified sysgens.

aka x'E4'

as an aside the thing that precipitated the 360 pcm stuff:
https://www.garlic.com/~lynn/submain.html#360pcm

was I had done a lot of doing dynamic terminal type identification. When I got CP/67 at the university jan68, it already could do 2741/1052 identification. I needed to add TTY/ascii support and added a bunch of magic with SAD command and some other stuff ... so theoretically CP/67 would do TTY/2471/1052 dynamic terminal type identification (on both dial and non-dialed lines).

It worked fine in all the tests ... until one of the CEs informed me that it wasn't going to be reliable (at least allowing any terminal to dial into common modem pool and connect on any modem). When they were doing 2702 ... they allowed the line-scanner to be dynamically associated with any line with the SAD command ... but they did a short-cut with the oscillators ... and hardwired specific speed oscillators to each line (aka dynamic terminal type recognition would only work reliably when specific speed terminal was coming in on port that was wired for that specific terminal speed).

that started four of us on the project to build our own controller clone. Started with a minicomputer and built our own channel attach card. Included in the software "linescanner" to strobe the incoming signal rise/lower to dynamically determine terminal line speed; aka get both dynamic speed and terminal type determination. then some articles blamed us for originating the 360 pcm controller business.

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

2 questions: diag 68 and calling convention

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 2 questions: diag 68 and calling convention
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Fri, 08 Mar 2002 03:13:09 GMT

"John Roth" writes:
Actually, the "diagnose" instruction is a general purpose escape to VM - it is not specific to Linux at all. Unless IBM completely reengineered the interface into VM for linux, which I doubt, my response stands. There may very well be specific codes within the instruction that were added to make Linux work better, but that's a different condition.

when i was an undergraduate ... I did a speed-up for CMS involving x'ff' ccw op-code. after all the other speed-ups ... both general cp kernel and stuff specific for mft & mft ... there was still things that I found i could do for cms.

my observation was that all of cms filesystem i/o was single threaded ... always did sio, went into wait, took interrupt, and resumed (never did anything while waiting for disk i/o). furthermore, cms filesystem effectively used logical fixed block disk architecture ... even simulating it from start ... even back to 2311 days.

my implementation of x'ff' ccw op-code effectively bypassed all the ccwtrans overhead ... and was "immediate" ... always returning CC=1, csw stored (aka scheduled the i/o and waited until completion).

ok, so a lot of the code i did as an undergraduate ... ibm incorporated and released as part of the standard product.

however, the guys at cambridge took exception with the x'ff' ccw op-code implementation ... even though it resulted in significant processor reduction for cms workload.

their position was that the cp kernel had to faithly reproduce the principle of ops ... (and the document that it was extracted from the architecture manual) ... and that a x'ff' ccw op-code for disk operated differently under cp and on the bare iron (and the principle of ops made no provisions for that).

so the issue was to come up with a solution that retained the pathlength advantage of the "synchronous" disk operations while at the same time conforming to the 360 architecture;

their solution was that architecture manual defined the x'83' diagnose instruction to be model/processor specific ... and cambridge they would define a kind of 360 processor model that was the virtual machine processor model ... and define a set of instruction semantics for the 360 virtual machine model specific x'83'. the semantics were somewhat like the (later) 370 'b2' extended instruction ... but rather than placing the extended op-code in the byte following the 'b2', the extended op-code was placed in the 360 instruction displacement field for the virtual machine model dependent x'83' instruction implementation (and any necessary parameters were passed in the register pair specification).

cms (cambridge monitor system) would still retain dual path, at boot time it would test if it was running in a cp/67 virtual machine and set a flag that the x'83' diagnose instruction would be used for filesystem i/o ... if it wasn't running in a virtual machine, it would used the existing sio/ccw path.

in the change-over to vm/370, cms was renamed the conversational monitor system and the ability to run on a real machine was eliminated (i.e. the disk driver support for bare iron sio/ccw path), leaving only the diagnose x'83' path.

course all of this got somewhat muddled when lots of CP function was dropped into the underlying machine for things like LPAR support.

past discussion of linux/390/vm use of diagnose
https://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again

random refs:
https://www.garlic.com/~lynn/96.html#23 Old IBM's
https://www.garlic.com/~lynn/99.html#95 Early interupts on mainframes
https://www.garlic.com/~lynn/99.html#149 OS/360 (and descendants) VM system?
https://www.garlic.com/~lynn/2001b.html#32 z900 and Virtual Machine Theory
https://www.garlic.com/~lynn/2001f.html#21 Theo Alkema
https://www.garlic.com/~lynn/2001m.html#22 When did full-screen come to VM/370
https://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)

CP had previoulsy been modified for virtual unix support in the early '80s (fork "diagnose", misc. other stuff) ... actually a number of times, including mid-80s support for aix/370 ... a locus port.

... from a feb82 paper
CP/370 CHANGES

The "UNIX" modifications to the CP/370 system, provide a "UNIX (virtual) machine" which is similar to a virtual S/370 except:

1. FORK command

A new CP/370 DIAGNOSE will create a copy of the calling 'UNIX machine' (as restricted by these changes). The state (i.e. GPRs, Instruction location counter, I/O address space and its contents (devices), and storage address space and its contents) of the new 'UNIX machine' is identical to the originator in all respects except the condition-code returned to the two 'UNIX machines'. The calling 'UNIX machine' will receive a CC=0 ; the created 'UNIX machine' will receive a CC=1. The DIAG instruction will return in a register the processor id (a 16-bit quantity) of the newly created machine. Thus, both the creator and the created machines will have the processor id of the new machine.

A complementary TERMINATE command will destroy the calling 'UNIX machine'.

2. READ/WRITE shared segments.

The 'UNIX machine' and its parent will share selected segments of its address space on a so called 'unprotected' or 'read/write' basis. (see section 'implementation details', for discussion of how the shared segments are selected/spedified)

3. SYNCHRONOUS I/O

A 'UNIX machine' has a synchronous I/O instruction (similar to CP's DIAGNOSE 20).

The I/O address space of the 'UNIX machine' is exactly the same (i.e. same devices at the same addresses) as that of the machine that created it by a FORK command.
S/370 channel commands make up channel program,
A synchronous instruction (DIAGNOSE) will cause CP/370 to perform the I/O, handle (retry and log) any errors, and when the I/O is complete, continue processing at the instruction following the DIAGNOSE.
A Channel Status Word describes errors encountered in performing the I/O
the 'UNIX machine' will be in instruction wait until the I/O is complete, (i.e. no overlap of 'UNIX machine' processing and I/O).

4. NO ASYNCHRONOUS I/O - a 'UNIX machine' does not have a S/370 I/O structure:

all S/370 I/O instructions cause program check,
There is no I/O interrupt, no new or old I/O PSW, and no CAW. The CSW will be retained (as in CPs DIAG 20 ).

5. A SIGNAL PROCESSOR INSTRUCTION (SIGP).

Its format is the same as the S/370 instruction. It will send a signal and one byte of information to another 'UNIX machine'.

6. NO CONSOLE FUNCTIONS -

A 'UNIX machine' has neither console nor console functions and it can not issue or receive CP/370 special messages.

7. MISC. CHANGES -

LOGOFF and FORCE commands extended.

=======================

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

Farm kids

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Farm kids ...
Newsgroups: alt.folklore.computers
Date: Fri, 08 Mar 2002 18:04:34 GMT

Lars Poulsen writes:
The truth is, I realized early on that farming was hard and dirty work, and I went looking for something easier and more fun to do. I was 12 when a second cousin, who was an electronics engineer, dropped in to visit my parents on a Sunday, and left me with an introductory electronics textbook, anno 1931. That night, I decided I wanted to be an engineer. Two years later, I knew I wanted to work with computers. Never looked back.

where i was in eastern montana ... nearest town was one of those small farming towns ... mainstreet had post office, farmers co-op gas station & grocery store, conoco gas station, drugstore and seven bars.

my uncles would frequently stop at one of the bars at the end of the day. when we got home, my grandmother would be mad, it wasn't that bad that grown men spend there evenings in a bar ... but for a 11 year old kid to spend a couple hrs each evening in a bar was another thing (my parents wouldn't have been happy either if they had known).

I had discovered math. at the end of 5th grade they gave achievement tests and there was this problem that I had no idea:
2x + y = 5 x + y = 3

afterwards, I ask what it was and somebody said algebra.

that summer when the county bookmobile came through (twice a month), i checked out every algebra book they had.

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

LISTSERV(r) on mainframes

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: LISTSERV(r) on mainframes
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 08 Mar 2002 18:12:59 GMT

gabe@GABEGOLD.COM (Gabe Goldberg) writes:
Here are some notes from a senior person at L-Soft, LISTSERV(r) vendor.

the precursor to listserv was toolsrun on the internal network starting circa '82; it provided both listserv and usenet type function. it leaked onto bitnet at some point.

in part there was this computer conferencing, email distribution stuff that I was doing in the 80/81 time-frame that was semi-automated ... which created quite a flap ... in part it was a "new" idea that there could be a wide-spread corporate information distribution chennel that the executives didn't know anything about. One of the results of the investigation was that a more formal mechanism be put in place.

random refs:
https://www.garlic.com/~lynn/2001c.html#5 what makes a cpu fast
https://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
https://www.garlic.com/~lynn/2001j.html#31 Title Inflation

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

Jeez, garlic.com -

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Jeez, garlic.com -
Newsgroups: alt.folklore.computers
Date: Fri, 08 Mar 2002 19:04:55 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
wouldn't it save massive scabs on the fingertips if you'd just burn some CDs? At a reasonable price, the Eye Be Emmers may anty up for the collection.

my fingertips or yours? when I was 12, I ran across this really old, junked black 20s/30s typerwriter and taught myself to type. modern keyboards are a breeze compared to what i learned on.

the ng postings is only small part.

the ietf RFC stuff gets updated every time a new RFC is released (as well a lot of consistency checking stuff with regard to standards process). When Postel (RIP) was doing STD1, some of the consistency checking stuff would be included in what was section 6.10 of STD1
https://www.garlic.com/~lynn/rfcietff.htm

the glossaries/taxonomies are possibly the most static
https://www.garlic.com/~lynn/index.html#glossary

even old ng/list postings have their headers updated with URL pointers to subsequent posts that reference them (sort of this thing about bidirectional links). exps:
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aadsm5.htm#asrn2

given the server log of hits ... there are periodic whacker/robot batch retrieval by various organizations (they could already burn CDs if they wanted).

https://www.garlic.com/~lynn/index.html

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

PKI Implementation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI Implementation
Newsgroups: sci.crypt
Date: Sat, 09 Mar 2002 01:11:19 GMT

uzma271170@hotmail.com (Uzma) writes:
I am doing my research on: Why organisations have failed to implement PKI and can PKI be a suitable e-commerce solution.

Can anybody suggest a methodolgy for carrying out such research. You may suggest a research design focusing more on the organisational issues of PKI implemtation rather than the technical issues.

past postings ... several dealing with the business process issues
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/subpubkey.html#privacy
https://www.garlic.com/~lynn/subpubkey.html#radius

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sat, 09 Mar 2002 16:55:23 GMT

"Charlie Gibbs" writes:
It is part of a discussion of how adding more people to a task is effective only if the task can be partitioned. And even then, the book points out, communication overhead can eat up the savings. Anyone who has spent time in interminable meetings when he could have been doing real work will attest to this.

there is lore about the tss/360 group going from 1200 to 30 or so people (i believe 30 would be considered significantly smaller than nominally expected on many large projects) ... and the (single) person responsible for the scheduler now realized that just about every module in the system was calling the scheduler. before there were multiple people on every (partitioned) module and the "specification" called for the scheduler needing to be called when anything happened.

the realization was that a kernel call threaded its way thru possibly a couple dozen modules before returning control to the application address space ... and every module was calling the scheduler ... which needed possibly at most one call to the scheduler per kernel call.

in any case, the lore has it that epiphony (and corresponding changes) drop a million inustructions from (some specific?) kernel call pathlength ... by eliminating the duplicate scheduler calls.

this was the inverse of the mythical man month subject ... the starting base was the "normal" state of affairs and instead of adding more people when the project got in trouble ... they eliminated 99 percent of the people when the project got into trouble (and found that they could produce a better baby, faster).

the boyd example from WW-II was Guderian and the blitzkrieg ... the strategic objectives were layed out and because everyone(?) was well-trained, professional soldier, that they could rely on the individual on the spot to execute the correct tactical solution. in fact, Guderian told them verbal orders only .... that the individual on the spot would be responsible for making the best decision they possibly could ... w/o any worry that any post-blitzkrieg audits would assign blame that somebody was responsible for this or that not going correctly. The amount of communication goes up significantly (especially up and down the chain) and effectiveness decreases significantly if you really are dealing with green troops & officiers.

someplace there is the definition of the auditors as the people who go around the battlefield after the war, stabbing the wounded.

the 360 period saw an explosive headcount growth in the company ... there seemed to be almost stereotype of hiring BAs in liberal arts (english, history, etc) putting them through six week programming school and then out to the front lines. Six months later they all were possibly promoted to managers to handle large new croup coming in.

The issue was as much the experience level as the fact that you could turn around in six months and find 10 people assigned to do something that previously only had a single person assigned previously. If you took a narrow snapshot of a year period from six months before the additional people were assigned until six months later ... there would be a conclusion that adding more people didn't help things much. However a longer period study would possibly conclude that it was as much to do with the experience level as with the numbers.

ref:
https://www.garlic.com/~lynn/99.html#120 atomic History
https://www.garlic.com/~lynn/2001.html#29 Review of Steve McConnell's AFTER THE GOLD RUSH
https://www.garlic.com/~lynn/2001m.html#16 mainframe question
https://www.garlic.com/~lynn/subboyd.html#boyd

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

Mainframers: Take back the light (spotlight, that is)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sat, 09 Mar 2002 17:11:57 GMT

Jim Thomas writes:
Probably a 084 if it was IBM - 2000 cpm, i.e., one box per minute, 5 minutes per case, 50 minutes per pass of your 100,000 cards. Or looking at it the more likely way, 1 minute and 40 seconds per tray ...

If you were good :-) you could flop a tray's worth of cards into the input hopper at a time - going from a fairly flat tray to kind of vertical to the ~30 degree hopper in a nice clean sweep. If you weren't good it took a long time to pick of 3300 cards :-( The output hoppers held about 1500 cards each, and the sorter would stop when any of them filled up.

If one had the right layout, up to about 30,000 cards at a time worked fairly well, depending on how even the distribution was. Two carts in front of you and the sorter behind you. 10 full trays on the left cart, transferred one at a time to the input hopper. Regular output hopper unloads into the 10 empty trays on the right. Move the column sense (optical on the 084), switch the carts, and repeat :-)

tell me i'm not having a senior moment. I never saw anybody do the cardtray trick, but heard about it; however I remember picking up a gaggle of cards from the tray, top of the cards facing my palm & 9-edge "out" and placing it into the feed ... which means the 9-edge would be against the feed and the top of the card faced out (or am i forgetting that I had to move the cards into the other hand before loading so that the 9-edge would be facing out ... and top of the cards against the feed).

unless i'm having a real senior moment here (and forgetting the hand switch before loading), that means the cards in the trays for the first pass ... should have been first inverted into an empty tray before doing a cardtray load trick (so 9-edge would be against the feed, rather than facing out). During processing the cards could be moved from the hoppers and placed upside down in the trays already setup for the cardtray load trick & then on the final pass, cards moved from the hoppers and placed right side up in the trays.

so remind me ... was 9-edge facing in (against the feed) or out?

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sat, 09 Mar 2002 23:05:20 GMT

Anne & Lynn Wheeler writes:
the boyd example from WW-II was Guderian and the blitzkrieg ... the strategic objectives were layed out and because everyone(?) was well-trained, professional soldier, that they could rely on the individual on the spot to execute the correct tactical solution. in fact, Guderian told them verbal orders only .... that the individual on the spot would be responsible for making the best decision they possibly could ... w/o any worry that any post-blitzkrieg audits would assign blame that somebody was responsible for this or that not going correctly. The amount of communication goes up significantly (especially up and down the chain) and effectiveness decreases significantly if you really are dealing with green troops & officiers.

the other point that boyd made was lots of corporate america during 60s, 70s, 80s, was suffering from a lot of managers and executives that got their training in how to manage large numbers of people as officers in us army during WW-II.

the problem facing the army at entry to WW-II was handling huge influx of mostly, totally inexperienced soldiers; the strategy was a heavy structured, top-down tightly controlled organization that presumed interchangeable, quite inexperienced masses at the bottom (corollary was non-agile and frequently relatively brittle).

later in corporate life, even with an extremely skilled people at all positions in the organization ... the style that they adopted still reflected their earlier training on how organizations needed to be run.

random refs:
https://www.garlic.com/~lynn/99.html#120 atomic History
https://www.garlic.com/~lynn/2001.html#29 Review of Steve McConnell's AFTER THE GOLD RUSH
https://www.garlic.com/~lynn/2001d.html#45 A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001m.html#16 mainframe question

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

PKI Implementation

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI Implementation
Newsgroups: sci.crypt
Date: Sat, 09 Mar 2002 22:51:43 GMT

"James Cole" writes:
I have asked that question and I think it has to due with a common lack of the technology. Some managers and execs don't care about encryption.

Then there are technical aspects that have to be addressed.

1. CA location (In or out house?) 2. Key Escrow

This is a serious issue and it has kept organizations from moving forward with PKI in the enterprise.

observations was that a relying-party-only certificate (whether gernated in-house or outsourced) frequently is totally redundant ... the certificate encapsulates a subset of information that is part of some in-house repository ... a repository that frequently has to be accessed as part of any security/transaction event ... making the duplication of the information in any certificate redundant and superfluous.

the issue of key escrow is dependant on whether the PKI purpose is authentication or encryption. key escrow is not an issue for a straight authentication application.

however key escrow becomes a significant corporate issue anytime encryption is being used for long term protection of data at rest that represents significant corporate assets (i.e. not just an issue of encryption of short-term protection of purely data in flight).

random refs:
https://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12c A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/2000g.html#25 SSL as model of security

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

Mainframers: Take back the light (spotlight, that is)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sun, 10 Mar 2002 05:13:10 GMT

Charles Richmond writes:
You have to remember the old riddle:

Question: "How was Thomas J. Watson, Sr. buried???"

Answer: "Face down, nine edge first..."

right ... so to pop a whole cardtray into feed ... it would be face down, top first, 9-edge facing out; so either they inverted the contents of the cardtray into an empty one first ... or they played a game with sorting the cards backwards.

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

Why?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why?
Newsgroups: alt.technology.smartcards
Date: Sun, 10 Mar 2002 05:42:03 GMT

"Joe Sensible" writes:
The reason smart cards were implemented in Europe was because local phone calls cost money, merchants wouldn't go to the expense of accepting credit cards, which necessitated a local call for each transaction. So the French invented a chip card that would authenticate a PIN number that the purchaser punched into a smart card reader. In this country, local calls are free, and the merchants (and card issuers) are generally satisfied with the magnetic stripe. Nobody wants to go to the expense of buying and installing new card readers everywhere. In September of 1999, Amex released the first smart cards in the U.S. They were a big success because they looked cool. Some of the visa issuers tried to follow with some unsuccessful launches that were known as "me too blue" in 2000. All of those launches bore one common feature. Nobody installed card readers, and nobody actually uses the pretty little chip on the card.

aka the euro PTT/telco costs were higher than chip costs (or in some cases not available) ... so there was much some number of offline stored-value capability developed in europe.

in the us the telco costs have, been cheaper than chipcard costs. there is wide-spread stored-value cards in the us ... but they are nearly all magstripe, "online" implementations (aka they use the same magstripe machines as debit/credit ... and much of the same networks) .... you see them all over the place ... frequently at check-out counters in much the same way as phone cards (aka walmart, sears, nordstrom, barnes & noble, blockbuster, etc ... just about everywhere ... although frequently they are advertised as "gift" cards or some other characterization, either predetermined values or arbritrary values that can be specified at time of purchase).

... aka stored-value is a customer/business product ... 7816-based chipcards with offline transactions is a technology method of deliverying that product; however there is possibly much larger number of magstripe online stored-value cards out there.

a pending issue is the advances in technology making it easier to counterfeit magstripe cards (aka fraud costs might at some point start to tip the equation further in favor of chipcards, not a telco cost/availability issue).

note that nacha did an internet debit network trial using both "soft" tokens (aka software running on customer PC effectively emulating hardware tokens) as well as real hardware tokens:
https://www.garlic.com/~lynn/x959.html#aads

basically x9.59 is a financial industry standard targetd at all electronic payment transactions ... aka debit, credit, stored-value, etc ... effectively instrument neutral ... and can make effective use of hardware token:
https://www.garlic.com/~lynn/x959.html#x959

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

Farm kids

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Farm kids ...
Newsgroups: alt.folklore.computers
Date: Sun, 10 Mar 2002 05:55:06 GMT

Anne & Lynn Wheeler writes:
where i was in eastern montana ... nearest town was one of those small farming towns ... mainstreet had post office, farmers co-op gas station & grocery store, conoco gas station, drugstore and seven bars.

farmer's co-op had file of receipts for each member family ... instead of paying at check-out, it went on your bill. Settlement was whenever (it wasn't too clear to me whether that was monthly, quarterly or after harvest or when).

main drag ran parallel to the railroad ... and possibly four blocks over. there was also farmer's co-op grain elevator at the railroad.

much of the area was either open range or dry land wheat. I think a good year was 4-5 bushels to an acre ... and the contract combines that came through the region at harvest took something like 2 bushels (and some percentage of amount over 2 bushels?). It wasn't unusual some years to get 2-3 bushels per acre.

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

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sun, 10 Mar 2002 21:47:07 GMT

Anne & Lynn Wheeler writes:
later in corporate life, even with an extremely skilled people at all positions in the organization ... the style that they adopted still reflected their earlier training on how organizations needed to be run.

the other characterization of this style (assumption of no skill and interchangeable) was the "mushroom farm" style of management, the executives keeping (all the little) mushrooms in the dark and feeding them lots of ----.

a slight defense for interchangeable was disaster recovery and no single point of failure (which never did imply totally interchangeable ... just having some level of backup/redundancy in the skilled people that you do have ... as opposed to assuming that nobody has any skills at all). random backup/redundancy refs:
https://www.garlic.com/~lynn/subtopic.html#hacmp

one of my experiences in this area was in the early '80s ... somebody in HONE made a presentation to a new DP (sales & marketing) division executive ... he apparently realized that a significant portion of HONE technology I was providing personally. His first question was what if he gets hit by a bus? The next question was where is the inter-divisional MOU (memo of understanding) from an executive?

The first part is the straight skill backup question (aka worldwide DP sales & marketing operation was dependent on HONE systems so the idea that it had cricital dependency on single person was unthinkable).

However, the 2nd question implies that nothing is suppose to happen unless directed by an executive. The possibility that I would be personally providing HONE system with significant portions of technology for going on 15 years ... and there had never been an executive commitment for that work was totally unimaginable. Not only wasn't there any MOUs ... probably for most of the time, none of my management organization even realized that it was going on.

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

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

Why?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why?
Newsgroups: alt.technology.smartcards
Date: Mon, 11 Mar 2002 01:23:08 GMT

"Webmetrix" writes:
Airlines are looking at them too for faster processing of "preferred" customers.

note that some airlines have tried iso 7816 contact cards in the past and find that there is a reliability problem common to high-traffic transit applications. from a chip standpoint ... high-traffic transit applications have implemented and/or are looking at one of the iso 14443 contactless standards ... even some of the high traffic financial & point-of-sale are also.

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

RAS & 2x/18m (was Re: On-die memory controller pros/cons?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RAS & 2x/18m (was Re: On-die memory controller pros/cons?)
Newsgroups: comp.arch
Date: Mon, 11 Mar 2002 14:22:37 GMT

at150bogomips@aol.com (At150bogomips) writes:
10Khr. might be reasonable for a PC; given 40hr/week, that is over 48 months, by which time one could purchase a new system that has 8x better performance (possibly at lower cost because of increased volume). :-)

Servers and most embedded systems require reliability/longer lifetimes, but does 'Moore's Law' make reliability of only moderate importance for desktop systems (and fad toys :-)? Even some appliances might be suited to planned obsolence or modular part replacement (e.g., a TV's signal processing subsystem might be a reasonable 'obsoletable' part while the display seems 'durable').

Might computing nodes approach the reliability of disk drives (sacrificing some of the solid-state reliability advantage for additional performance or lower cost)? This might mean older systems (those in greater danger of failure) would be moved to less critical (and less compute intensive) tasks or components might be made more easily hot-swappable. Some HPC systems might not suffer much from node failures and could use the extra performance (low R, good AS, excellent MFLOp/month/$).

the other problem with avg. expected life is the distribution ... with significant number of failures still posisble in period less that 48 months. Lots of work went into disk drive 800Khr ... I believe as much because for early life failure warranty costs as anything (given a 800Khr what is the distribution of disk failures per thousand over the first two years compared to 10Khr). Given very high volumes and thin profit margins, there would be trade-offs with some up-front (reliability) engineering against expected number of warranty claims.

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

IBM Mainframe at home

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Mainframe at home
Newsgroups: alt.folklore.computers
Date: Mon, 11 Mar 2002 14:37:45 GMT

jcmorris@mitre.org (Joe Morris) writes:
The original IBM PC was announced in August 1981 with first customer shipment (FCS) later that year. I can't pin down the AT release date exactly, but the latest date shown in the BIOS source listings I have is 1/12/84 (diskette BIOS interface) although I'm not sure that it represents the BIOS at FCS.

from v10n5 acm can ... fall '82
In the last issue of CAN we published a performance comparison of the Intel iAPX-432, Intel 8086, Motorola 68000, and DEC VAX-11/780. We mentioned that Intel had announced a successor to the 8086, called the 80286. Intel is sampling parts now and will ship 8MHz and 10MHz versions next winter. In addition to new instructions that support 32-bit data, the 286 has a spohisticated protection mechnaism reminiscent of MULTICS. The 286 also has a compativility mode to run existing 8086 programs.

...
The bottom performance line as measured by these four small programs is that the newest version of the 432 (8MHz with 4 wait states) is almost as fast as a 5MHz 8086, while the 80286 leads the 432 by almost an order of magnitude. Furthermoe, this fast machine (in 8086 compatibility mode) outperforms a 16MHz 68000.

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

SSL MITM Attacks

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL MITM Attacks
Newsgroups: sci.crypt
Date: Mon, 11 Mar 2002 15:41:14 GMT

Colin Andrew Percival writes:
This would work, provided that the MITM can supply a certificate which Alice will trust. This is why we have certificate authorities -- we assume if Verisign tells us "this is Bob's public key" that the MITM will not be able to decrypt anything we enrypt using that public key. If the MITM is a TLA (which presumably will have no trouble obtaining forged certificates from a US-based company) then SSL will indeed be insecure. (But, of course, in most cases the tradtional Burglary/Bribery/Blackmail approach is more likely.)

one of the points of having certificates for SSL is because of integrity issues with domain name infrastructure ... if there was a domain name infrastructure exploit ... the client could be directed to a different site (i.e. the domain name to ip-address mapping got corrupted ... so the client was directed to a incorrect ip-address).

The SSL certificate contains the domain name ... and the client checks that the domain name in the SSL certificate is the same was the client was expecting (aka had typed in).

However, who do the TTP certification authorities check with when they are validating a request for a SSL domain name certificate ... TTP certification authoritaties have to check with the authoritative agency responsible for the information that the TTP/CA is certifying. In the case of SSL domain name certificates, involving domain names, the authoritative agency for domain names is the domain name infrastructure.

Now this is the domain name infrastructure that has possibly integrity issues that justified the SSL domain name certificates in the first place (aka it isn't necessary to obtain a forged certificate, necessary subvert the domain name infrastructure and then apply for a valid SSL domain name certificate ... which is then properly certified).

Somewhat as a result (of TTP CA concerns), there are a number of things being looked at to improve the integirty issues with domain name infrastructure.

The catch-22 ... is that improving the integrity issues with domain name infrastructure ... for the purpose of trusting the certified authenticated information in SSL domain name certificates (for TTP CAs) ... can also absolete the original justification for having SSL domain name certificates.

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

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

Speaking of Gerstner years

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Speaking of Gerstner years...
Newsgroups: bit.listserv.ibm-main
Date: Mon, 11 Mar 2002 16:41:32 GMT

bjohnson@RUSSELLMELLON.COM (Johnson, Bill , Pittsburgh) writes:
That's 2 questions. The mainframe is not better off, but IBM is a stronger company having gotten in the services area which is/was growing much faster than the shrinking mainframe market.

services area has always been a big opportunity ... it is just that the gov. legal stuff threw a big monkey wrench into it in the past (including SBC ... service bureau corporation spun off to CDC).

there were pros & cons to the mainframe breakup. the communication division would have been cut loose to sink or swim on its own.

in the following reference:
https://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the ligh (spotlight, that is)

not only was communication division stranglehold having downside effect on mainframe disk market ... but mainframes in general.

SAA was an attempt to directly move a lot of applications (and data repositories) back to the mainframe (and still retained the communication division in the middle)

the disk division's alternative high speed interface for distributed computing ... leveraging what was best about PCs and human interface improvements ... while continuing to provide necessary management for information and other corporate assets (both a mainframe and mainframe disk play) lost out to communication division products that were starting to rpresent a significant choke point for accessing mainframe services and contributed significantly to migration of whole infrastructures to outboard platforms.

numerous times the bare-bones cost issue should have been offset by the significant increase in risk to corporate assets ... all other things being equal; however terrible performance inhibiting a viable application deployment frequently tipped the scales (not just the gui interface but all other components of the application move outboard).

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

Hardest Mistake in Comp Arch to Fix

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hardest Mistake in Comp Arch to Fix
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 11 Mar 2002 18:34:36 GMT

prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:
The IBM S/360 instruction set provided for 24-bit (16MB) virtual addresses. The big stumbling block to extending this was the design of the subroutine call instructions Branch and Link (BAL) and Branch and Link Register (BALR). BAL stores two pieces of information: the return address for the subroutine call and some state bits (2 bits of condition code and a 4-bit "program mask" indicating which exceptions (arithmetic overflow/underflow, etc.) are enabled). BAL/BALR put the return address in the low 24 bits of one of the general-purpose registers and the state bits in the high 8 bits of the same register. Hence, you couldn't expand the virtual address range beyond 24 bits without killing any program that does subroutine calls. The 360/67, which supported 32-bit virtual addresses, added Branch and Store instructions (BAS/BASR) that put the state information elsewhere, thus allowing the full 32 bits of the return register to be used for the return address. S/370 left enough bits all over the privileged parts of the architecture to support 32-bit addressing, but it took IBM a long time to write all of the 24-bit dependencies out of their code, and it wasn't until years after S/370's first release that we saw XA support.

slight note while 360/67 supported 32bit addressing (virtual memory, and hardware addressing relocation, etc) ... XA/811 introduced w/3081 was 31bit addressing (not 32bit). If i remember correctly, one of the (32/31) issues was the operation of BXLE/BXH instructions ... which did arithmetic operations ... but register contents were typically used for addressing.

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

SSL MITM Attacks

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL MITM Attacks
Newsgroups: sci.crypt
Date: Mon, 11 Mar 2002 21:10:57 GMT

cryptofish@hotmail.com (Korbin Meiser) writes:
But what if Bob doesn't have a certificate, and has a publc key instead? I guess SSL might not be the solution to my problem. Here's the problem: Bob has Alice's public key (or certificate). Alice doesn't have Bob's public key (NOT a certificate). Is there any way that Bob can securely send his key to Alive without a successful MITM attack?

In SSL, Bob generates a random secret key and sends it to Alice encrypted with Alice's public key. Alice returns some stuff encrypted with Bob's secret key. Bob know that he is talking securely to only Alice. Alice knows she is talking securely to somebody ... but doesn't really know who.

Anybody can securely send a key to Alice (whether a symmetrical secret key or a asymmetric public key) and the two can establish secure communication. The originator will know that they are talking securely to Alice. Alice will know that she is talking securely to somebody but won't know if it is Fred or Bob.

If originators happen to send a public key securely (and uses the same public key consistently for all subsequent communication) ... then Alice will be able to consistently distinguish originator1 from originator2 across multiple communications. For Alice to reliably associate originator1 with Bob and originator2 with Fred ... she needs either some out-of-band communication or some indication within the body of the secure communication that reliably establishes identity.

The owner of public key can reliably transmit it to Alice ... and Alice can uniquely use that public key for secure and reliable communication with the owner of that public key ... Alice just can't reliably associate a specific public key with a specific identity w/o additional process.

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

Hardest Mistake in Comp Arch to Fix

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hardest Mistake in Comp Arch to Fix
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 11 Mar 2002 22:46:47 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
There was a 16-bit line still present in MVS/370, which was removed in MVS/XA. That was a relic of a MUCH older era and, by then, affected only the location of device entries and similar stuff.

... aka UCB ... unit control block ... basically device descriptor was addressed with 16bit values ... so all UCBs (device definitions) had to reside in the first 64k bytes of address space. This also represented a limitation on the total number of devices that could be defined. This was an operating system convention ... not a hardware convention.

370 hardware I/O architecture introduced an addition to the 360 CCWs (channel command word, aka methodology to define I/O operations) called IDALs.

In standard 360 hardware I/O, CCWs were
8 bit operation indicator (thoe IO "op-code") 24 bit address 8 bit misc. flags reserved 16 bit count

The 8 bit operation indicator specified things like read, write, control, etc. operations.

The 24 bit address specified the target for read/write operations, control information, etc. The CCWs and the target of the CCWs had to be within 16mbyte.

IDALs were one or more full-word (32bit) InDirect Address Lists. In 370, the address for read/write operations could be moved into IDALs, a flag set in the "misc flags" indicating use of IDALs, and the CCW would point to an IDAL (rather than directly to target address). The CCWs and IDALs had to reside within the first 16mbytes of memory, but the IDALs could be used for I/O transfers addressing 2gbytes (31bits). IDALs were part of 370 w/o 31bit address, but used to improve scatter/gather non-contiguous (real) memory I/O transfers.

IDALs were used for 3033 32mbyte real memory option (late in the 370 life-cycle but pre XA/811 31-bit addressing). Instructions were still 24bit, but a unused bit in the page table entry was used to extend the "real page number value" (instead of 12bit value for up to 4096 4kbyte real pages, it could specify a 13bit real page number, for up to 8192 4kbyte real pages, TLB and cache also needed adjusting) and IDALs were used to perform I/O operations involving addresses above the 16mbyte real storage line. Also introduced in 3033 was something called dual address space ... two separate 16mbyte virtual address spaces that could be accessed sort-of simultaneously. The "problem" was that the MVS kernel and much of system services were co-located in the application virtual (16mbyte) address space, as kernel functions grew & expanded, the portion of virtual address space available to application shrunk. Daul address space was a gimmick of getting part of the kernel out of the application address space ... but still allowed kernel services that were implemented based on directly addressing data in the application address space to still work.

31bit addressing came along with the 3081 and XA/811 (aka 370-XA ... the internal code name was 811; 11/78). CCWs and IDALs were still constrained to be in the first 16mbyte of real storage.

ccw format
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IESHBE01/2.17.2.3?SHELF=&DT=19970319164503

comparison of 370 & 370-xa
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/F.0?DT=19970613131822#HDRAF1H1

there is 390 IO overview in following document:
http://www.linuxhq.com/kernel/v2.2/patch/pre-patch-2.2.15-19/linux.15p19_Documentation_Debugging390.txt.html

discussion of 390 "addresses"
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.12.2

random ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/CONTENTS?SHELF=
http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/DZ9ZR000/CONTENTS?SHELF=&DT=20020212195453

Now to get really confusing, dual address space then sort-of evolved into access registers and multiple address spaces (up to 16) where program call kinds of operations (w/o going thru kernel call overhead) can result in a controlled address space switch:

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.8?DT=19970613131822

from above:
3.8.1 Changing to Different Address Spaces

A program can cause different address spaces to be addressable by using the semiprivileged SET ADDRESS SPACE CONTROL instruction to change the translation mode to the primary-space mode, secondary-space mode, access-register mode, or home-space mode. However, SET ADDRESS SPACE CONTROL can set the home-space mode only in the supervisor state. The program can cause still other address spaces to be addressable by using other semiprivileged instructions to change the segment-table designations in control registers 1 and 7 and by using unprivileged instructions to change the contents of the access registers. Only the privileged LOAD CONTROL instruction is available for changing the home segment-table designation in control register 13.

=====================================================

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/2.3.5?DT=19970613131822
2.3.5 Access Registers

The CPU has 16 access registers numbered 0-15. An access register consists of 32 bit positions containing an indirect specification (not described here in detail) of a segment-table designation. A segment-table designation is a parameter used by the dynamic-address-translation (DAT) mechanism to translate references to a corresponding address space. When the CPU is in a mode called the access-register mode (controlled by bits in the PSW), an instruction B field, used to specify a logical address for a storage-operand reference, designates an access register, and the segment-table designation specified by the access register is used by DAT for the reference being made. For some instructions, an R field is used instead of a B field. Instructions are provided for loading and storing the contents of the access registers and for moving the contents of one access register to another.

Each of access registers 1-15 can designate any address space, including the current instruction space (the primary address space). Access register 0 always designates the current instruction space. When one of access registers 1-15 is used to designate an address space, the CPU determines which address space is designated by translating the contents of the access register. When access register 0 is used to designate an address space, the CPU treats the access register as designating the current instruction space, and it does not examine the actual contents of the access register. Therefore, the 16 access registers can designate, at any one time, the current instruction space and a maximum of 15 other spaces.

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

Hardest Mistake in Comp Arch to Fix

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hardest Mistake in Comp Arch to Fix
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 12 Mar 2002 01:02:35 GMT

prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:
Since the dynamic address translation hardware was part of the CPU and not necessarily accessible by the I/O channels, the mapping of virtual address to physical address had to be done via some other means, and that is where the IDAL came in. The IDAL told the I/O channel what physical memory address corresponded to the virtual address in the CCW. It had to be a list to perform page scatter/gather.

both CCWs and IDALs were real addresses. The CCW pointed to the IDAL.

In pre-31bit 370, IDAL was used for scatter-gather I/O efficiency.

there were all these pre-virtual memory applications that generated CCWs thinking they were running in real memory. The supervisor received control and had to copy the CCWs to kernel memory and replace all the virtual addresses with real addresses. The original (virtual) CCW may have specified a contiguous transfer virtual address range that was actually mapped to discontiguous real pages. The IDALs were used to list the discontiguous real addresses (mostly when I/O transfer specified a range of bytes that crossed one or more page boundaries).

So for (application) CCWs that had specified a virtual address with I/O transfer that crossed one or more page boundaries ... instead of mapping into a single real address ... mapped into multiple (typically) discontiguous real addresses (which were listed in an IDAL) with the real, translated pointing to the IDAL (instead of the real data address).

There are previsions in standard 360 & 370 CCWs for scatter/gather using a sequence of multiple data-chained CCWs (this is the method that CP/67 used for translating virtual machine CCWs to real CCWS), however there could be some timing sensitive situations involving changing a single CCW into a sequence of two or more data-chained CCWs (which was addressed by the 370 IDAL feature).

This goes into the deep dark reaches of I/O and CCW architecture. The I/O architecture defines CCW operation as synchronous ... the current CCW is completely executed before the next CCW is fetched (even if it involved data-chaining CCWs). This synchronous CCW fetch & execution of multiple CCWs in place of a single CCW would introduce latencies that could result in anomolous results (possibly even data transfer overruns) in various timing sensitive situations. (pre)Fetching multiple IDAW in an IDAL had no such limitation. The "synchronous" specification, in part allowed for any value in subsequent CCW to modified ... even while the current CCW was in the process of execution (the I/O programming equivalent of self-modifying code).

Mainframers: Take back the light (spotlight, that is)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Tue, 12 Mar 2002 01:16:08 GMT

Jim Thomas writes:
I get the idea that we're about even for the senior moment race, but I don't see the problem. The cards are in the tray, 12-edge up, first card at the front. A handful of them are grabbed from the front of the tray and plopped onto the hopper. The 9-edge is towards the hopper, the first card is first to go through the throat, 9-edge first. There was no rotation of cards for the 188/084/1402/2540. ISTR that the 557 fed them 12-edge first. Maybe the 407 also? But for sure anything with a tray-sized hopper was set up for picking up a bunch of cards from a box or a tray and dropping them onto the hopper.

I believe that 9-edge first when grabbing by handfuls and putting them into feed, the question was about the full cardtray "dump" ... o device (sorter) where

many people would operate by grabbing handfuls and putting them into the feed (9-edge first) ...

but some could perfect the full cardtray careful "dump" (i.e. carefully tipping the contents 3300? some-odd full card tray into the feed) ... which would result in the cards being 12-edge first.

In the 2nd case (cardtray dump 12-edge first) ,,, did they just recognize that the 12-edge feed put the cards into the hopper in reverse order ... or did they first invert the cards into a empty cardtray before dumping them in (in which case they would go in 9-edge first).

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

Mainframers: Take back the light (spotlight, that is)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframers: Take back the light (spotlight, that is)
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Tue, 12 Mar 2002 16:48:37 GMT

hack@watson.ibm.com (hack) writes:
With a well-designed I/O subsystem, and an appropriate software structure to record the information, it need not take much time. This requires two things: (a) That the address space to be explored be reasonably dense and bounded, and (b) that sensing the absence of a device does not require a timeout. In large systems, an additional requirement is (c) that parallel exploration (on independent channels, busses or whatever) be possible.

slightly related ... taking 12 seconds for palmtop to reboot?

http://www.newscientist.com/news/print.jsp?id=ns99992005

Military palmtop to cut collateral damage

....
12 second reboot

In recent US Army tests, JEDI target messages were sent and received in as little as 3 seconds. Its simple, icon-based software also reduces the risk of inaccurate information being called in, cutting the chances of attacks on the wrong target.

If the Windows-based machine crashes, says Batcheller, it can be rebooted within 12 seconds. But can a Pocket P - -more at home in a Starbucks coffee bar than on the battlefield - handle combat conditions?

JEDI is a lot more robust, he says. To test quite how much the gadget can take, the Army had a game of football using a JEDI as the ball - and it worked just fine afterwards.

Storage Virtualization

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Storage Virtualization
Newsgroups: comp.arch.storage,alt.folklore.computers
Date: Tue, 12 Mar 2002 17:23:15 GMT

an earlier virtual disk (1974) was 3850 Mass Storage System and all those honeycomb tape cartridges that virtualized 3330 disk drives from the early '70s if i remember correctly, 3850 had two staging option/mode ... one was full-tape ... aka half (50mbyte) a 3330-I (100mbyte) drive ... and the other was six(?) 3330-track increments. The following mentions supporting 3350s (317mbyte), but I don't remember if there was also any support for (full) 3330-II (200mbyte drive). 3850 had tape robot ... but it wasn't an automated tape library, it was a virtual disk system.

There was lore about speed of the tape robot and situation where somebody entered the 3850 interior and the robot going into motion. After that there was in interlock placed on robot operation whenever the access door was opened.

there was ironwood, 3880-11 disk controller cache in the very early '80s (4k block though) ... and then '83 sheriff, 3880-13 full-track disk controller cache.

from:
http://www.beagle-ears.com/lars/engineer/comphist/ibm_nos.htm
3850 Mass Storage System (1974 to 1990)

A robotic tape storage system, featuring tape cartridges about the size and shape of a 12- ounce soda drink can, containing a wide strip of tape wound on a spool.

The cartridges were stored in two facing walls of honeycomb-arranged slots. Mechanical pickers (one or two, depending on the 3850 model) went back and forth between the storage walls, moved vertically and pivoted to reach the desired slot, then pulled a cartridge and carried it to one of multiple tape drive stations. At the drive, the cartridge cover was removed and the tape was read or written using helical-scan heads like those on a 4mm or 8mm digital tape drive. Each cartridge held about 50MB, a 3330 drive image filled two cartridges.

There were dedicated 3330 disk drives onto which data was staged from cartridges. Once staged, the data was accessed from the 370 mainframe like ordinary disk data. The entry- level 3850 had a total storage capacity of 35GB, but a fully-expanded system could hold much more (up to 472 GB). After the 3330 DASD went out of fashion, 3830 MSS systems were fitted with 3350 drives, but the 3830 code was never updated to use the additional capacity of the newer drives.

Pictures at
http://www.columbia.edu/cu/computinghistory/mss.htm

.......

"Jean Dion" writes:
You forgot the inventor of Virtual disk storage and disk Virtual Snapshot back in 1994...StorageTek code name Iceberg and now V960. They were sold as IBM RVA (Ramac Virtual Array) for few years (1995-1999).

Here is some StorageTek industry first to storage:

- 1978 Solid State Disk (SSD). Memory emulating disk.
- 1986 Disk controller cache
- 1987 Automated tape library with more than 96000 cells.
- 1994 Virtual Disk and world first disk Snapshot without twice the storage requirement.
- 1998 Virtual Tape (IBM mainframe)
- 2001 Virtual SAN with SN6000

You have also Compaq (HG80 controller), HP (V7400) and Xiotech also have true virtual storage subsystems.

To get more on virtual take a look at www.infostor.com

Jean Dion Tools & Programs
http://pages.infinit.net/dbtek/

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

Hardest Mistake in Comp Arch to Fix

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hardest Mistake in Comp Arch to Fix
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 12 Mar 2002 19:42:35 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
That seems very likely, but it is probably now more legacy applications code, rather than system services. I can't tell you for sure, as it is a long time since I was involved with MVS.

I/O in 31bit ... CCWs pointers to IDALs are 24bit pointers (which means the IDALs have to be within first 16mbyte). This is a hardware issue. There are all sorts of random software issues that may still represent residual 24bit code.

.. i don't know what the 64bit effects have on all this

Hardest Mistake in Comp Arch to Fix

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hardest Mistake in Comp Arch to Fix
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 12 Mar 2002 20:18:14 GMT

Anne & Lynn Wheeler writes:
.. i don't know what the 64bit effects have on all this

all from z/64bit POP
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/DZ9ZR000/CONTENTS?SHELF=&DT=20020212195453

The ORB
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/DZ9ZR000/15.6.2?DT=20020212195453

specifies the (start of) channel program as a 31bit address (CCWs can be anywhere in first 2gbyte).

it specifies whether a channel program is (consistently) format-0 or format-1 CCWs and (consistently) format-1 IDALs (consistently) or format-2 IDALs

presumably format-0 CCWs could reside above the 16mbyte line (aka 31bit), but could only specify tranfers betlow 16mbyte line or point to IDALs within the first 16mbyte.

CCWs:
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/DZ9ZR000/15.6.3?DT=20020212195453

have format-0 CCW (old 24-bit address pointers ... either directly to data or to IDAL)

and format-1 CCW (31-bit address pointers ... either directly to data or to IDAL).

IDAW:
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/DZ9ZR000/1.1.7?DT=20020212195453

they now have doubleword "format-2" (64bit) IDAW (as well as "format-1" (31bit) IDAW.

next, previous, index - home