2006 Newsgroup postings (06/15 - 07/07) Lynn Wheeler

2006 Newsgroup Postings (06/15 - 07/07)

Mainframe Linux Mythbusting
Large Computer Rescue
An Out-of-the-Main Activity
The Power of the NORC
The Power of the NORC
Track capacity?
Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Why I use a Mac, anno 2006
Track capacity?
An Out-of-the-Main Activity
An Out-of-the-Main Activity
An Out-of-the-Main Activity
DEC's Hudson fab
Track capacity?
The AN/FSQ-31 Did Exist?!
OpenSSL Hacks
Why I use a Mac, anno 2006
Why I use a Mac, anno 2006
Pick a pin
Mainframe Linux Mythbusting
Why I use a Mac, anno 2006
The very first text editor
Patent #6886160
Why I use a Mac, anno 2006
OT - J B Hunt
Mainframe Limericks
Mainframe Limericks
Old Hashing Routine
Mainframe Limericks
Mainframe Limericks
Old Hashing Routine
Mainframe Limericks
Old Hashing Routine
Why Did No Core Machines Have Cache ???
PDP-1
Draft Command Script Processing Manual
English (was Mainframe Limericks
Curiosity
Computers in the movies
Using different storage key's
Microcomputers As A Space Spinoff
Why Didn't The Cent Sign or the Exclamation Mark Print?
Why Didn't The Cent Sign or the Exclamation Mark Print?
Google Architecture
Musings on a holiday weekend
Musings on a holiday weekend
Musings on a holiday weekend
The System/360 Model 20 Wasn't As Bad As All That
The System/360 Model 20 Wasn't As Bad As All That
The Pankian Metaphor (redux)
The System/360 Model 20 Wasn't As Bad As All That
The System/360 Model 20 Wasn't As Bad As All That
TCP/IP and connecting z to alternate platforms
DCSS
DCSS
The System/360 Model 20 Wasn't As Bad As All That
DCSS

Mainframe Linux Mythbusting

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Linux Mythbusting
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 15 Jun 2006 18:18:08 -0600

ted.macneil writes:
Not according to the traces.

If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how long we've had the TN3270 client we use), and it always happens under TCP/IP. We have MACROS (scripts) coded for call centres to screen scrape an old CICS application and answer customers' questions. They have never failed under SNA. The only change we make (and I know it's the only change because I am co-ordinating it and controlling it), is we make the TN3270 client talk to TCP/IP. Invoke the MACRO and BOOM!. Corrupted (incomplete) data sent to the host, the application session gets terminated and the user is blown to a blank sign-on screen.

Doesn't even have the logo and sign-on crap we display when the PC first connects to the mainframe.

Every time. Not intermittent. No re-transmission requests. No session. No data.

since I've rarely heard of similar problems under tcp/ip implemenations on other platforms, it is possibly bugs in the vendor's tcp/ip implementation ... check with your tcp/ip vendor about possible bugs in their tcp/ip implementation.

at more basic implementation and protocol level ... sna tends to require an enormous amount more code and much longer pathlength (as well as significantly more buffer copies) ... as per earlier post:
https://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting

from a protocol aspect, sna has tended to be much more half-duplex oriented vis-a-vis tcp/ip ... which should simplify the management of possible states.

for some topic drift ... from a post earlier this year
https://www.garlic.com/~lynn/2006h.html#56 The Pankian Metaphor

the following email extract about implementing SNA on a unix platform ....
Date: 05/06/85 16:52:04
From: wheeler

re: sna; interesting note in this month's sigops. Somebody at CMU implemented LU6.2 under UNIX4.2 ...

Rosenberg reported on an implementation of an SNA node consisting of LU 6.2 and PU T2.1 protocols. (These protocols cover approximately OSI layers 2 through 6.) The implementation was made on UNIX 4.2. About 85% of the code was generated automatically from the FAPL meta-description of SNA. The following problems were reported:
...
1. The protocol code is large, and thus cannot run in the kernel space. Consequently, communication between user program and the node (processor executing the SNA code) is more complex and slower than if the node were part of the kernel. In addition, error recovery proved tricky.

2. The SNA node must simulate the UNIX sockets, which are full duplex and place no restriction on the states of the two conversants. The SNA node uses a half-duplex, flip-flop protocol, where the states of the two conversants must remain synchronized. To match the two required an extension to SNA.

The implementation is now complete and is actually used to drive a 3820 printer, which is a SNA device

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

Large Computer Rescue

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Large Computer Rescue
Newsgroups: alt.folklore.computers,comp.sys.dec,rec.games.video.arcade.collecting
Date: Thu, 15 Jun 2006 19:57:30 -0600

ArarghMail606NOSPAM writes:
IBM for one. Model 1419, IIRC. I used to run one, once upon a time.

old posting mentioning check sorting
https://www.garlic.com/~lynn/2002.html#18 Infiniband's impact was Re: Intel's 64-bit strategy

which then had earlier reference
https://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)

An Out-of-the-Main Activity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: An Out-of-the-Main Activity
Newsgroups: alt.folklore.computers
Date: Thu, 15 Jun 2006 20:32:13 -0600

kaplow_r@encompasserve.org.mars (Bob Kaplow) writes:
Between 1975 and whenever Zenith pulled the plug on Heathkit. When you first had to solder the thing together before booting it up.

at the university in the late 60s, we had 2702 telecommunication controller with type-I line-scanner (2741) and type-III line-scanner (1052). the university got was TTY-33 machines and had to get a type-II line-scanner (TTY). The type-II line-scanner upgrade for the 2702 arrived in a box that said Heathkit (obviously they were building other things).

the 2702 had "SAD" command that you specified for each line ... which associated a specific line-scanner with a specific line/port.

original cp67 delivered to the university had 2741 (type-1 line-scanner) and 1052 (type-III line scanner) terminal support. It had some magic code that would do a sequence of operations with different line-scanner combinations in order to dynamically determine the terminal type.

with the addition of type-II line-scanner and TTYs ... I had to add TTY support to cp67. I tried to emulate the same magic code as had been done for 2741 & 1052. It work ok with fixed line terminals ... however, I wanted to also do it for dialed terminals. The support seemed to almost work ... i.e. use the same (common phone number) dialed port/line for all terminals. the gotcha was that the line speed oscillator was hard wired to each line ... while it was possible to dynamically change the line-scanner on a port/line basis ... it wasn't actually possible to dynamically change the line/port baud rate (defeating the ability to actually use a common phone number for all terminal types).

this was sort of the motivation for the university to start a project to build our own telecommunication controller. somebody wrote an article blaming four of use for spawning the plug-compatible (clone) controller business.

project involved reverse engineering the mainframe channel interface and building a channel interface card for an interdata/3 ... and progrmaming the interdata/3 to emulate the mainframe telecommunication controller. one of the features added/programmed for the interdata/3 was to dynamically determine port/line/terminal baud rate.

misc. other posts mentioning clone controller:
https://www.garlic.com/~lynn/submain.html#360pcm

The Power of the NORC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Power of the NORC
Newsgroups: alt.folklore.computers
Date: Fri, 16 Jun 2006 09:12:31 -0600

eugene@cse.ucsc.edu (Eugene Miya) writes:
The AEC then ERDA then DOE attempted a cute rating system for supercomputers from the 60s into the early 80s. The Cray-1/Cray-X/MP was a Class 6 machine, with earlier machines rated 5 (7600), 4 (6600), etc.

from long ago and far away ... mentions class VII supercomputer
Date: Wed, 25 Mar 87 20:02 EST
From: BRIAN JAY GOULD <GOULD@JVNC>
Subject: JVNC search for VP
To: s-comput@tcsvm

Vice-President for Computing

John von Neumann National Supercomputer Center

Applications and nominations are invited for the position of Vice- President for Computing of the John von Neumann National Supercomputer Center (JVNC) in Princeton, New Jersey. The Vice-President reports to the President of the Consortium for Scientific Computing, Inc. The Consortium consists of thirteen leading research and teaching institutions and operates JVNC for NSF's national research community.

The goal of JVNC is to be at the cutting edge of computational science. This Center will be the first to make a Class VII supercomputer available to the NSF-supported researchers. An ETA-10 will be available in spring, 1987 with several doublings in capacity through 1988. JVNC is connected to the national scientific community by a network including T1 lines and satellites.

... snip ...

The Power of the NORC

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Power of the NORC
Newsgroups: alt.folklore.computers
Date: Fri, 16 Jun 2006 09:27:57 -0600

and even more drift:


Date:         Tue, 2 Sep 1986 09:33 EDT
Reply-to:     SuperComputers list <S-COMPUT@TCSVM>
Sender:       SuperComputers list <S-COMPUT@TCSVM>
From:         Henry Nussbacher <HJNCU@CUNYVM>
Subject:      List of SuperComputers in Bitnet
To:           Lynn H. Wheeler <WHEELER@ALMVMA>

        List of Supercomputers on Bitnet/Netnorth/Earn
==============================================

Bitnet        Center               1985-1986          1987
Nodename        name                                (tentative)
== ========  ===================== ================ ================
1            JVNC - Princeton      Cyber 205        ETA-10
2  ASUACAD   Arizona State                          IBM 3090-200/VF
3  BOSTONU   Boston University     IBM 3090-200/VF  Same
4  CORNELLD/ Theory - Cornell      IBM 3084/QX128,  IBM 3090/400,
   CORNELLF                        FPS 264's        FPS 264's
5  CPWPSCA/  Pittsburgh            Cray X-MP/??     Same
   CPWPSCB
6  CSU205    Colorado State        Cyber 205        Same
7  DB0ZIB21  Berlin - Germany      Cray 1M          Same
8  DFVLROP1  German Aerospace      Cray 1S          Same
9  DGAIPP1S  Max Planck - Germany  Cray X-MP/14     Cray X-MP/24
10 DJUKFA11  Juelich - Germany     Cray X-MP/22     Same
11 DKAUNI46  Karlsruhe - Germany   Cyber 205        Same
12 DS0RUS1I  Stuttgart - Germany   Cray 1M          Cray 2
13 FSUSUP    Florida State         Cyber 205        ETA-10
14 HASARA5   Amsterdam U - Neth.   Cyber 205        Same
15 ISUMVS    Iowa State            NAS/AS 9160VPF   Same
16 NCSAVMSA/ NCSA - Illinois       Cray X-MP/24     Cray X-MP/48
   NCSAVMSB
17 SDSC      San Diego             Cray X-MP/48     Same
18 UCBLYNX   U C Berkeley          Cray X-MP/12     Cray X-MP/14
19 UCBCMSA   U C Berkeley          IBM 3090-200/VF  same
20 UCLAMVS   UCLA                  IBM 3090-200/VF  Same
21 UGA205    Univ of Georgia       Cyber 205        Same
22 UNCACDC   Univ of Calgary, CAN  Cyber 205        Same
23 UTORONTO  U of Toronto          Cray X-MP/22     Same
24 VSP1      Boeing Data Services  Cray X-MP/24     Same
25 VTVM1     Virginia Polytech     IBM 3090-200/VF  Same

... snip ...

Track capacity?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Track capacity?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 16 Jun 2006 12:48:47 -0600

Charles Mills wrote:
"all disks since dinosaurs roamed the Earth." Heck, it's got the 2311 and 2305. (That should be enough start up another one of those darned mainframe nostalgia threads.)

i've done q&d conversion of the old gcard ios3270 to html.
https://www.garlic.com/~lynn/gcard.html

it has record size calculations ... but it predated 3390 ... so only has up thru 3380
https://www.garlic.com/~lynn/gcard.html#26.3

from above


Track             Record Size
Device  Capacity    Without key        With key
3375     36000      224+#(D+191)       224+#(K+191)+#(D+191)
3380     47968      480+#(D+12)        704+#(K+12)+#(D+12)
Device  Capacity    Without key        With key

Notes:  D is data length, K is key length
        # means round up to multiple of 32

from somewhere else 3390 track capacity is listed as 56,664

Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Newsgroups: bit.listserv.ibm-main
Date: Fri, 16 Jun 2006 17:27:29 -0600

Tom Schmidt wrote:
Read a little about John Nagle's observations on network performance here:
http://www.port80software.com/200ok/archive/2005/01/31/317.aspx

That particular link hyperlinks to a Microsoft page that gives you a clue how to change your registery settings to alter the PC's settle time. Perhaps that will help you?

(If not, RFC896 is Mr. Nagle's original RFC on the subject. Use 'RFC896' as a search argument in your TCPIP terminal emulator documentation to see if they offer help there.)

my ietf RFC index (frames mode)
https://www.garlic.com/~lynn/rfcietff.htm

normally RFC summaries load in the lower frame.

clicking on the ".txt=nnn" field in the summaries retrieves the actual RFC.

RFC 896
https://www.garlic.com/~lynn/rfcidx2.htm#896
896 Congestion control in IP/TCP internetworks, Nagle J., 1984/01/06 (9pp) (.txt=26782) (Ref'ed By 985, 1016, 1072, 1122, 1254, 1323, 1812, 2126, 2309, 2525, 2556, 2914, 3539, 3714, 4138, 4172, 4413)

however, see several implementation discussions in 1122 related to Nagle.
https://www.garlic.com/~lynn/rfcidx3.htm#1122
1122 S
Requirements for Internet hosts - communication layers, Braden R., 1989/10/01 (116pp) (.txt=289148) (STD-3) (Updated by 4379) (See Also 1123) (Refs 768, 791, 792, 793, 813, 814, 815, 816, 817, 826, 879, 893, 894, 896, 922, 950, 963, 964, 980, 994, 995, 1009, 1010, 1011, 1016, 1042, 1071, 1072, 1108, 1112) (Ref'ed By 1127, 1180, 1190, 1191, 1207, 1219, 1254, 1256, 1329, 1349, 1370, 1379, 1385, 1403, 1433, 1455, 1517, 1531, 1533, 1541, 1561, 1577, 1620, 1626, 1644, 1716, 1745, 1755, 1770, 1812, 1819, 1885, 1933, 1937, 1970, 2001, 2131, 2132, 2176, 2225, 2309, 2331, 2353, 2360, 2391, 2414, 2461, 2463, 2474, 2481, 2488, 2498, 2521, 2525, 2581, 2663, 2678, 2694, 2757, 2760, 2784, 2822, 2834, 2835, 2893, 2914, 2923, 2988, 3021, 3022, 3081, 3135, 3154, 3155, 3168, 3175, 3259, 3260, 3360, 3366, 3390, 3435, 3449, 3465, 3481, 3490, 3522, 3684, 3720, 3821, 3884, 3948, 4035, 4172, 4302, 4367, 4379, 4391, 4413, 4443, 4459, 4460)

Why I use a Mac, anno 2006

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why I use a Mac, anno 2006
Newsgroups: alt.folklore.computers
Date: Fri, 16 Jun 2006 20:05:50 -0600

lawrence writes:
But the big failure is: Peaking the RF requires actually reading and understanding the instructions (or the underlying technology). If you just grip the edge of the reflector and jiggle it until you have a viewable signal, you might be right at the hairy edge of the threshold. The signal is corrected to perfection, so you think "I must have it pointed in the right direction." If you had taken the time to accurately position the system, you would have plenty of fade margin for all but the *strongest* storm cell.

old post about difficulty getting permits for 4.5meter dish
https://www.garlic.com/~lynn/94.html#25

local residents were objecting possibly under the mistaken assumption that (large) 4.5meter dish met large watts ... even tho transmitter was 25watt max and typically ran around 7watts (except during rain fade ... uplink power budget).

turns out that they were catching significantly more radition from nearby 50,000 watt FM transmitter.

Track capacity?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Track capacity?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 17 Jun 2006 07:40:01 -0600

James F Smith wrote:
That doesn't look right, but please consider my bad memory. But wasn't the track capacity for a 3380 - 47476???

you are talking about the largest formated record w/o key.

if you look at the calculation, a keyless record required adding 12 bytes and rounded up to multiple of 32bytes and then adding 480 to calculate how much of raw track capacity a (keyless) formated record took.

so single formated record 47476 and adding 12 = 47488 by chance is multiple of 32

and 47488+480 = 47968

47968 is the raw, unformated track capacity.

each formated record has overhead, as per the calculation.

re:
https://www.garlic.com/~lynn/2006m.html#5 track capacity

i've done q&d conversion of the old gcard ios3270 to html.
https://www.garlic.com/~lynn/gcard.html

it has record size calculations ... but it predated 3390 ... so only has up thru 3380
https://www.garlic.com/~lynn/gcard.html#26.3

from above


Track             Record Size
Device  Capacity    Without key        With key
3375     36000      224+#(D+191)       224+#(K+191)+#(D+191)
3380     47968      480+#(D+12)        704+#(K+12)+#(D+12)
Device  Capacity    Without key        With key

Notes:  D is data length, K is key length
         # means round up to multiple of 32

An Out-of-the-Main Activity

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: An Out-of-the-Main Activity
Newsgroups: alt.folklore.computers
Date: Sat, 17 Jun 2006 09:52:56 -0600

Michael Widerkrantz writes:
Personally, I only had access to the previous incarnation of SUNET through long distance terminal servers and the guest accounts that, at the time, were ubiquitous. People logged in through the guest accounts were sometimes frowned upon, but the sysadmin's of the time kept the

a fair number of EU educational institutions in the mid to late 80s were on EARN and interconnected to BITNET in the states.

old email from person setting up EARN
https://www.garlic.com/~lynn/2001h.html#65

earn and bitnet
https://www.garlic.com/~lynn/subnetwork.html#bitnet

used similar technology that was used in the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

i believe for a time in the early 80s towards the mid-80s, not only did the internal network have more nodes than the arpanet/internet ... but bitnet also had more nodes than the arpanet/internet.

An Out-of-the-Main Activity

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: An Out-of-the-Main Activity
Newsgroups: alt.folklore.computers
Date: Sat, 17 Jun 2006 10:02:39 -0600

re:
https://www.garlic.com/~lynn/2006m.html#9 An Out-of-the-Main Activity

when the corporation formed acis in the early 80s, it started out with $300m that it was suppose to pump into educational institutions.

project athena (at mit) got $25m (which dec matched). cmu got $50m that went into various of the "andrew" things as well as mach, camelot, etc.

a lot was also pumped into paying for the bitnet (and earn) network infrastructure and operations.
https://www.garlic.com/~lynn/subnetwork.html#bitnet

i've claimed that the nfsnet backbone was the operational precursor to the modern internet.
https://www.garlic.com/~lynn/subnetwork.html#internet

the nsfnet backbone rfp award was for something like $11.2m ... however rumor and folklore make claims that the actual resources pumped into the nsfnet backbone (by corporations) was 4-5 times what was actually paid for by NSF. reference to the original nsfnet RFP and mention of the RFP being awarded
https://www.garlic.com/~lynn/internet.htm#nsfnet

An Out-of-the-Main Activity

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: An Out-of-the-Main Activity
Newsgroups: alt.folklore.computers
Date: Sat, 17 Jun 2006 12:41:40 -0600

Michael Widerkrantz writes:
This state of affairs in the BBS world declined severly in the 1990s, though, and suddenly BBSes only seemed to be teenage chat areas without the technological ingredients I had loved so much. I don't know where budding hackers could find source at the time, since Internet access was not available if you weren't a faculty brat or already a student.

ref:
https://www.garlic.com/~lynn/2006m.html#9 An Out-of-the-Main Activity
https://www.garlic.com/~lynn/2006m.html#10 An Out-of-the-Main Activity

in the early 90s I got a .8m pagesat r/o dish ... it had a full usenet feed. they let me keep it, in part for doing a unix driver for their modem and co-authoring an article for boardwatch magazine (it had a picture of me in the backyard with my dish). i had "waffle" (bbs program) running on a windows machine tied to a unix machine handling the usenet feed. not too long later they upgraded with 18in dish (with .75m option) and doubled the bandwidth.

this was different than the 4.5meter dishes that I got to play with at work as part of hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

at one location we had to go to a 7meter dish (signal quality issues). we even got to attend the bird launch ... it was interesting event; some number of people were in the stands ... several places over sat one of the people that had walked on the moon.

recent posting mentioning bird flying on 41-d
https://www.garlic.com/~lynn/2006k.html#55

couple past posts menting the pagesat boardwatch magazine article
https://www.garlic.com/~lynn/2000.html#38 Vanishing Posts...
https://www.garlic.com/~lynn/2000e.html#39 I'll Be! Al Gore DID Invent the Internet After All ! NOT
https://www.garlic.com/~lynn/2001h.html#66 UUCP email
https://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration

... for a little drift ... on old post (by somebody else) about the system:
Newsgroups: comp.bbs.waffle,alt.bbs,rec.video.satellite,biz.pagesat,comp.bbs.misc
Subject: Receiving News via Satellite -- The PageSat System
Date: Mon, 28 Jun 93 19:20:35 GMT

Several weeks ago, I mentioned having ordered the PageSat system for receiving news via satellite downlink. There was some interest expressed and I indicated at that time that I would be glad to post a summary of my experiences/impressions when it arrived. Well, this is it.

I installed the system two weeks ago. We had the antenna braced in a wooden backyard chair for a couple of days until we set up a permanent mounting. Norman Gillaspie, President of PageSat, recommended that I get the .75m dish rather than the smaller 18-incher commonly used in the more southern climes (I live in Maine). Although a little bigger than unobtrusive, the dish ended up in a convenient, out-of-the-way corner of the back yard on about 4 feet of 2.25in aluminum EMT (with an additional 3 feet extending underground into 2 bags of concrete). The hardware performs well and seems quite reliable. And the blisters on my hands from the post-hole digger have finally healed.

I am grateful for the advice to install the larger antenna. I doubt the 18-inch dish would have had the ability to pick up a sufficiently strong signal through dense clouds this far North. Although we lost signal briefly during a heavy thunderstorm a week ago, it did return even while the clouds were thick and the downpour continued. I'm guessing that we will lose signal only when the thickest of storm clouds sweep between us and the satellite.

My setup requires the DOS version of the software which is new and running fairly well now. There were some problems with the software early on (extra characters were occasionally inserted -- which corrupted the binaries and the pix). The folks at PageSat were very responsive, however, and the problems were solved rather quickly. By the way, I have written a small utility which looks for completed news files, as received via PageSat, and invokes Waffle's (or other) RNEWS on each. When sitting idle, this utility gives back CPU cycles to DESQview. It's FREE, so if you need it, you need only ask via e-mail.

Assembly of the PageSat system went very smoothly. The written docs were excellent. I was fully expecting the instructions to be in Japanese, as mentioned in the review of the PageSat system appearing in the June, 1993 issue of Boardwatch Magazine. But that trial happily was not visited upon me. Except for a few hours trying to find the K2 satellite (the compass headings given were slightly off -- and I only had a narrow slot between two large trees to "shoot through"), I'd say the installation went off without a hitch.

If you need a sizeable news feed, but must cope with long distance costs to get it, I heartily recommend the PageSat system. My long distance costs for obtaining a medium-sized newsfeed for callers to the Northern Lights were running more than $200 per month. I figure the PageSat system will pay for itself in less than 9 months.

Now I'm looking to add a 1-2 gig SCSI drive so there will be space to keep more of the full news feed that's "tumbling out of the sky". I suppose I am not REALLY going to SAVE money after having purchased the PageSat system. But I WILL have more fun spending it. :)

... snip ...

DEC's Hudson fab

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DEC's Hudson fab
Newsgroups: alt.folklore.computers
Date: Sat, 17 Jun 2006 13:23:02 -0600

kkt wrote:
Our schools get only part of their money from property tax. The rest depends on the state general fund, which is not keeping up with inflation.

re:
https://www.garlic.com/~lynn/2006l.html#61 DEC's Hudson fab
https://www.garlic.com/~lynn/2006l.html#63 DEC's Hudson fab

the large mid-western state univ. that mentioned that they had "dumbed down" entering freshman text books three times in the 20 yrs between 1970 and 1990 also mentioned that the percent of univ. funding that came from the state legislature had dropped from something like 80percent to something around 10percent in the same period.

Track capacity?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Track capacity?
Newsgroups: bit.listserv.ibm-main
Date: Sat, 17 Jun 2006 21:59:57 -0600

DASDBill2 writes:
For a 3390, the largest possible user record (R1 data field) with no key is 56664 bytes ( I think).

if you look at it the other way, on 3380 ... a "keyed" one byte data record would take something like 704+32+32 ... 768bytes of track capacity ... in fact, whether it was one byte or 20 bytes ... it would still take 768bytes of track capacity. 21 byte record would take 800bytes of track capacity


record size with                           no. on 47968
nominal key          actual track bytes     byte track
1                         768                  62
..                        768                  62
20                        768                  62
21                        800                  59
..                        800                  59
52                        800                  59
53                        832                  57
..                        832                  57
84                        832                  57
85                        864                  55
..                        864                  55
116                       864                  55
117                       896                  53
..                        896                  53
148                       896                  53

---------------------------------------------------

ref:
https://www.garlic.com/~lynn/2006m.html#5 Track capacity
https://www.garlic.com/~lynn/2006m.html#8 Track capacity

as previously mentioned from q&d conversion of gcard ios3270
https://www.garlic.com/~lynn/gcard.html#26.3


Track             Record Size
Device  Capacity    Without key        With key
3375     36000      224+#(D+191)       224+#(K+191)+#(D+191)
3380     47968      480+#(D+12)        704+#(K+12)+#(D+12)
Device  Capacity    Without key        With key

Notes:  D is data length, K is key length
# means round up to multiple of 32

The AN/FSQ-31 Did Exist?!

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The AN/FSQ-31 Did Exist?!
Newsgroups: alt.folklore.computers
Date: Sat, 17 Jun 2006 22:03:48 -0600

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
Or the resource fork of files on a Macintosh... well, at least a Classic Mac. Unix doesn't do that, and BSD doesn't either, so I expect Apple is doing this another way now.

remember that apple is now a mach platform ... recent post mentioning mach
https://www.garlic.com/~lynn/2006m.html#9 An Out-of-the-Main Activity

OpenSSL Hacks

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OpenSSL Hacks
Newsgroups: sci.crypt
Date: Sun, 18 Jun 2006 08:43:48 -0600

pgut001@cs.auckland.ac.nz (Peter Gutmann) writes:
It's definitely a vulnerability. One of the requirements for security is availability (if you read material on real-world cryptosystems failures such as the report on the activities of the Walker spy ring you'll see that availability rated *above* cryptographic security in the Navy's requirements, while it rated at close to zero in the NSA's requirements, which made the system so vulnerable to compromise).

this is sort of the security PAIN acronym
P - privacy (sometimes CAIN and confidentiality)
A - availability
I - integrity
N - non-repudiation

long winded old post touching on whether all infrastructures require all security PAIN characteristics be at equivalent strength
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense

and a more recent posting about trade-off between end-to-end business (financial) process involving "naked" transactions which then implies heavily armoring all aspects of the end-to-end business operation ... vis-a-vis armoring the transactions which may significantly mitigate the armoring requirements of the end-to-end business process.
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transaction on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV

we had been brought in to consult with this small client/server startup that had this technology called SSL and they wanted to do payment transactions on their server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

which has since come to be called electronic commerce

we then got involved in the financial standards x9a10 working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (ALL, not just point-of-sale, not just internet, not just credit, ... ALL). as part of that we looked at the huge number of vulnerability points in the infrastructure .... somewhat related post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

before coming up with x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

part of the issue was that an unarmored, naked transaction was vulnerable at huge number of different places in the infrastructure. the SSL session encryption for transaction transit thru parts of the internet provided countermeasure for only a small amount of the vulnerabilities.

the assertion was that a x9.59 transaction could even be transmitted thru the internet w/o SSL or other session protection mechanism and the crooks could not use evesdropping or other techniques that would then lead to performing fraudulent transactions (replay attacks) ... aka SSL is currently used for transaction hiding because current transaction infrastructure is vulnerable to evesdropping and replay attacks. x9.59 standard eliminated the evesdropping, replay, skimming, and harvesting vulnerabilities.
https://www.garlic.com/~lynn/subintegrity.html#harvest

SSL might still be used for privacy/confidentiality ... but it would no longer be required as countermeasure to (financial fraud) replay attacks.

Why I use a Mac, anno 2006

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why I use a Mac, anno 2006
Newsgroups: alt.folklore.computers
Date: Sun, 18 Jun 2006 09:40:27 -0600

krw wrote:
IBM's internal telephone network was half-duplex and over geosync satellite; horrible! They're just now replacing the horrid ROLM half-duplex speaker phones in conference rooms. Gack!

SBS had originally been formed equal partners with IBM, Comsat, and Aetna ... for doing computer-to-computer data transmissions. A big issue was that the communication group had stranglehold on computer-to-computer data transmission with SNA ... and SNA had extremely low tolerance for satellite delay transmission (as well as scale-up in bandwidth that satellites frequently brought).

Because of the heavy influence that the communication group had blocking anything but straight sna for computer-to-computer transmission ... SBS was effectively forced into migrating to other markets ... and eventually got into voice transmission. They were in the public long-distance market (as well as heavily installed internally within the corporation).

major plant sites had these big 10meter dishes that were c-band running T3 (44mbits/sec) transmission. because of corporate security standards the data aggregator (or data aggravator), full bandwidth T3 encryptor as developed and deployed. voice channels were then suballocated out of the T3 channel. couple posts mentioning data aggravator
https://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006k.html#55 5963 (computer grade dual triode) production dates?

early in the deployment there is this story where they tried to do double-hop 56kbit circuit between STL and Hursley (STL to satellite, down to the east coast, up to atlantic satellite and down to the UK). They put up standard VNET on both ends and everything flowed fine. They then switched to a JES2/SNA at both ends and no traffic flowed at all. The person in charge was severely SNA indoctrinated ... and explained that obviously that there must be significant transmission errors which the advanced SNA error detection was able to recognize ... and that the primitive VNET handling just wasn't detecting. Geosync satellite are about 22000 miles, double hop round trip then is 8*22000 ... 176,000 miles with signal traveling at 186,000mps ... plus a little processing delay at the remote site works out to about one second elapsed time. recent post mentioning JES2 networking
https://www.garlic.com/~lynn/2006l.html#46 Mainframe Linux Mythbusting

Eventually SBS was dissolved, the phone/long-distance stuff sold off to MCI and the birds sold off to Hughes.

part of my hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

involved custom designed tdma earth stations using transponder on SBS-4 (Ku band) for doing (non-sna) computer-to-computer transmissions. Part of this involved gracefully doing compensation for satellite propagation delay and bandwidth scale-up. recent post mentioning sbs-4 flying on 41-d
https://www.garlic.com/~lynn/2006m.html#11 Out-of-the-Main Activity

Why I use a Mac, anno 2006

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why I use a Mac, anno 2006
Newsgroups: alt.folklore.computers
Date: Sun, 18 Jun 2006 12:13:40 -0600

Anne & Lynn Wheeler writes:
SBS had originally been formed equal partners with IBM, Comsat, and Aetna ... for doing computer-to-computer data transmissions. A big issue was that the communication group had stranglehold on computer-to-computer data transmission with SNA ... and SNA had extremely low tolerance for satellite delay transmission (as well as scale-up in bandwidth that satellites frequently brought).

re:
https://www.garlic.com/~lynn/2006m.html#16 Why I use a Mac, anno 2006

they also acquired a lot of middle-management from the communication group ... possibly why they were so willing to bow to pressure that all computer-to-computer communication was mandated to be SNA.

another issue was that they had come out of an organization that had 14 levels of management ... which they managed to duplicate. however the organization that they were coming from had 14 levels of management for an organization with approx. 400,000 people ... it was a little extravagant replicating a 14 level management infrastructure for an organization with only 2000 people (there were some claims that resulted in half the organization having title of director level or above).

Pick a pin

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pick a pin
Newsgroups: sci.crypt
Date: Sun, 18 Jun 2006 12:19:05 -0600

"Hakvinius" writes:
When picking a 4 digit pin for your ATM, what are the guidelines to pick a "safe" number and which numbers to avoid?

here are some rules that result in coming up with the absolutely best (and only approved) password
https://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.

a subset of the rules could be applied to picking the one and only one, absolutely perfect 4 digit pin

Mainframe Linux Mythbusting

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Linux Mythbusting
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 19 Jun 2006 11:10:41 -0600

Mark Zelden wrote:
Also, 90% of other TSM workloads are on AIX. One particular workload (TSM to backup AIX SAP servers) was on AIX but moved to the mainframe when we consolidated our mainframes out to LA. The SAP AIX servers moved along with the mainframe (because of how "tightly coupled" they were with the MF) but the AIX TSM servers remained in the Chicago area since they were still being used with all the other AIX servers that were staying. TSM was already in use on the MF for LPARs that already existed in the LA data center, so we just implemented it on an additional LPAR to backup SAP AIX.

ADSM got renamed TSM ... ADSM was repackaged (and capatible with) workstation datasave.

workstation datasave was reworked internal backup/archive system (with a number of clients added for non-MF platforms) that I had originally written and deployed at some number of locations in the bay area; research, engineering labs, hone, etc. ...

misc. past postings mentioning the HONE system (not just in the bay area) providing world-wide support for field, marketing and sales:
https://www.garlic.com/~lynn/subtopic.html#hone

misc. past postings mentioning internal backup/archive, workstation datasave, adsm & tsm
https://www.garlic.com/~lynn/submain.html#backup

Why I use a Mac, anno 2006

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why I use a Mac, anno 2006
Newsgroups: alt.folklore.computers
Date: Mon, 19 Jun 2006 11:42:13 -0600

Brian Inglis writes:
ISTR 3174R remote SNA 3270 terminal controller packet window options being 7 for terrestrial and 128 for a satellite link: no other numbers were selectable.

when I started on hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

one of the things that I soon realized that a lot of the protocols were in need of rate-based pacing NOT windowing. windowing had originally been a link-layer thing to provide a little bit of asynchronous overlap but avoid overring the receiving links buffer allocation. however, it soon got contorted into addressing all sorts of asynchronous behavior associated with other forms of congestion ... frequently totally unrelated to the number of pre-allocated buffers at the receiving link.

having done a whole lot with resource management and scheduling as an undergraduate ... and prone to translating things into rates ... it seemed trivially obvious that rate-based pacing was a requirement and that windowing was a very contorting and ill-suited construct for the tast.

the issue can come up in almost any environment with a "large" bandwidth*delay product (where "large" can be quite relative). I encountered it with satellites in the early 80s when the bandwidth was frequently 20-30 times that of a lot of terrestrial links ... and the delay was significantly larger. however, it cropped also in very high bandwidth fiber terrestrial connections as well as multi-hop networks.

some number of papers in the late 80s demonstrated that windowing was particularly ill-suited to large multi-hop networks. the actual objective is to be able to transmit packets w/o having to wait for full round-trip delay ... but possibly not transmit them continuously that they overwhelm the intermediate and end nodes. windows sort of have an assumption that there is a uniform distribution between transmissions. However, there is actually nothing in basic windowing operations that create intervals between transmissions ... other than once you have fully transmitted up to the max. window size, you then have to wait until ACKs come back.

The actual problem is rate of transmission arrivals ... or another way of thinking about it is multiple back-to-back transmission arrivals. There are slow-start strategies that attempt to address spreading out the back-to-back transmissions. The problem is that windowing is a mismatched paradigm for the actual problem. For one thing, they found in large multi-hop networks ... there was frequently bursty traffic, asynchronous traffic flows, ACK batching, and ACK piggybacking. All of these tending to create long delays between the transmitting after the time that the last transmission occurred "filling" the window ... and the arrival of ACKs that started to empty the window full condition. However, lots of things contributed to emptying a large number of windows in a burst ... which allows a large number of back-to-back transmissions to occur in a burst ... which then saturates intermediate and/or end nodes.

One way of doing rate-based pacing is to adjust the interval between transmissions. You are no longer directly concerned with the number of outstanding packets and/or the actual total end-to-end round-trip delay. The transmissions completely fill the path ... regardless of the round-trip delay and/or the bandwidth*delay product ... to the limit that the transmissions can be handled by intermediate and/or end nodes. In rate-based pacing there is no direct issue with the size of the channel or delay ... purely with how fast that the receivers can process the transmission.

At one point, I realized that a large number of platforms weren't using window strategy ... as a really poor substitute for rate-based pacing ... not because it was thot to be a better approach ... but because many of the platforms had such dismall timer facilities where it was impossible to implement any reasonable resource pacing strategy.

The very first text editor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The very first text editor
Newsgroups: alt.folklore.computers
Date: Thu, 22 Jun 2006 07:59:01 -0600

Elliott Roper writes:
Speaking of DECnet, some of the code I nicked from early DECnet was clearly something that was written first and 'designed' afterward. (Stu Wecker's table look up CRC algorithm. It was so fast that it outperformed the KG11 hardware CRC option by a country mile). It was so good that my boss thought I was brilliant just for nicking it. How's that for reflected glory? And typical pointy-haired critic behaviour too.

speaking of Wecker, I remember him from CP67 meetings at SHARE ... he was still with some univ (Brown?) at the time.

Melinda's paper at
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist

footnote in above:
108 For example, see S. Wecker, ''OS/360 as a Preferred Machine Under CP-67'', Proceedings of SHARE XXXVII, August, 1971, pp. 48-57.

... snip ...

and totally unrelated to Wecker, even more drift from Melinda's paper:
By the end of 1976, sixteen percent of the former Burlington personnel were working for DEC

... snip ...

Cambridge Science Center had spawned CP67 on 4th flr, 545 tech sq.
https://www.garlic.com/~lynn/subtopic.html#545tech

tbe CP67 group was split off from the science center and as it expanded, moved to the 3rd flr, absorbing what had been the Boston Programming Center (among other people at the Boston Programming Center on the 3rd flr was Jean Sammet). The group continued to grew quickly with the morphing of cp67 into vm370 and eventual moved out to Burlington Mall into what had been the old Service Bureau Corporation bldg (which had been spun off to CDC as part of some litigation).

Patent #6886160

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Patent #6886160
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 22 Jun 2006 08:10:34 -0600

howard.brazee@cusys.edu wrote:
There are different ways to reward.

And it is possible to reward an environment that produces innovation, instead of individuals.

There are a lot of patentable ideas that don't get support to be implemented. Does unused innovation count?

there was this processor engineer in pok in the 70s that had pencils made up ...spoof on who got promoted to pok lab manager; something to the effect "elect xxxx lab director, raises or promotions, but not both" (... i.e. "xxxx" was his name; i may have one or two somewhere in some box). he also use to fly a kite from the roof of the 705 bldg. on april 1st.

Why I use a Mac, anno 2006

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why I use a Mac, anno 2006
Newsgroups: comp.sys.mac.advocacy,alt.folklore.computers
Date: Thu, 22 Jun 2006 12:20:05 -0600

GreyCloud writes:
Lets put it this way... I never worked for DEC but was a DEC customer. So, is JMF Barbs husband then? And what does JMF stand for?

search engine is your friend ... random sample
http://www.interesting-people.org/archives/interesting-people/199308/msg00125.html
http://compilers.iecc.com/comparch/article/93-08-095
http://www.inwap.com/pdp10/paper-smp.txt
http://www.ultimate.com/phil/pdp10/
http://www.ultimate.com/phil/pdp10/cc341/names.html
http://www.inwap.com/pdp10/usenet/smp2

OT - J B Hunt

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - J B Hunt
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 22 Jun 2006 12:52:58 -0600

Elardus Engelbrecht wrote:

http://www.microsoft.com/athome/security/email/spear_phishing.mspx
https://en.wikipedia.org/wiki/Spear_phishing
http://www.eweek.com/c/a/Mobile-and-Wireless/HP-TouchPad-Needs-68-Weeks-for-Additional-Shipments-142584/
http://news.millersmiles.co.uk/article/0056
http://www.detnews.com/2005/technology/0510/27/A14-362453.htm

etc...

Use Google to search the web with these word 'phishing' and again with 'spear phishing'.

for a little more drift, a few recent postings on "static data", replay attacks and "naked transactions":
https://www.garlic.com/~lynn/aadsm24.htm#5
https://www.garlic.com/~lynn/aadsm24.htm#6
https://www.garlic.com/~lynn/aadsm24.htm#7
https://www.garlic.com/~lynn/aadsm24.htm#8
https://www.garlic.com/~lynn/aadsm24.htm#9
https://www.garlic.com/~lynn/aadsm24.htm#10

lots of past posts related to general account number harvesting (skimming, phishing, etc for replay attacks and fraudulent transactions)
https://www.garlic.com/~lynn/subintegrity.html#harvest

and even more postings on generalized subject of fraud, vulnerabilities, threats, and exploits
https://www.garlic.com/~lynn/subintegrity.html#fraud

... so a little mainframe tie-in from this related post
https://www.garlic.com/~lynn/aadsm24.htm#8

at one point the head of the mainframe division ... got moved over to be the head of the ibm/pc group during the OS2, PS2, & microchannel days. later he left and had a couple of other jobs. at one point he was doing a stint as ceo of company that specialized in kerberos
https://www.garlic.com/~lynn/subpubkey.html#kerberos

and got a contract to do the initial kerberos implementation for windows ... which is now the basic authentication infrastructure for their platforms.

Mainframe Limericks

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Limericks...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 23 Jun 2006 07:51:19 -0600

Hunkeler Peter , KIUB 34 wrote:
Depends on what "release" and corresponding name you talk about. If you go the roots, both OSs were born in the mid 60s: OS/360 came out in 1964. MULTICS came out around 1965, which then became UNICS, then UNIX.

multics started about then. lots of early 545 tech sq folklore ... mostly about cp67 and vm370 ... in melinda's history paper
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist

but when multics (5th flr, 545 tech sq) didn't choose 360/67, but instead GE machine ... the science center; 4th flr, 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech

started their own virtual memory project (which happened to also included virtual machines) for 360/67. some of the (mit) ctss people went to work on the 5th flr ... and some went to work on the 4th flr (so both activities have some common heritage w/ctss).

since 360/67 hardware was not going to be immediately available, the science center had a 360/40 modified with virtual memory hardware and produced cp40 in 1966. when 360/67 became available in 1967, they ported cp40 from custom modified 360/40 to 360/67 and renamed it cp/67.

cp67 was somewhat ahead of multics ... possibly because the implementation was not as large or as complex.

multics web page
https://www.multicians.org/

there are even some cp67 stories by one of the people that worked on multics
https://www.multicians.org/thvv/360-67.html

and some ibm 7094/ctss stories
https://www.multicians.org/thvv/7094.html

some people from cambridge came out and installed cp67 at the univ the last week in jan68 (third cp67 installation after cambridge and lincoln labs). I did a bunch of work on cp67, especially mft and mvt running under cp67 in virtual machine ... and was invited to spring SHARE in houston where cp67 was announced. I then gave a talk on some of the work at the fall68 SHARE meeting in Atlantic City. some old posts giving part of that presentation
https://www.garlic.com/~lynn/93.html#1 360/67, was Re: IBM's Project F/S
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14

Another item that I got to do for cp67 was adding TTY/ascii terminal support (which plays in one of the cp67 stories from the multics site). As part of that work, I tried to make the 2702 terminal controller do something that it could actually do. Somewhat as a result, the univ. started a project to build our own terminal controller; reverse engineer ibm channel interface and build our own channel board for Interdata/3 ... programmed to emulate 2702 (with some additional stuff the 2702 couldn't do). somewhere there was an article blaming four of us for spawning the plug compatible controller business
https://www.garlic.com/~lynn/submain.html#360pcm

later in POK ... getting ready for virtual memory announcement for 370, there was an effort to basically integrate virtual memory (some of the components from cp67) into mvt for os/vs2 SVS (instead of running mvt in virtual machine ... ccwtrans and some other stuff from cp67 was hacked into the side of a mvt kernel). basically mvt kernel where most of the infrastructure thot it was running in a real 16mbyte address space ... but was using virtual memory hardware to map the (single) 16mbyte address space to the real machine memory.

then SVS (single virtual storage) was enhanced with multiple virtual address space support and morped into os/vs2 mvs (multiple virtual storage) which eventually was shortened to just mvs.

in the mid-70s, as part of getting ready for 370/xa that would come out in the early 80s with 3081 ... work on mvs/xa was begun. up in cambridge. the vm370 development group had grown out of the space in 545 tech sq and had moved out to the old service bureau corp. building in burlington mall. POK convinced the corporation to shutdown burlington mall location, kill vm370 product, and that all the vm370 development people had to be moved to POK to support mvs/xa development (in order to meet the mvs/xa product schedule).

some people didn't want to move ... and instead stayed in boston area, many going to work for DEC (on things like vms). recent post referencing 16percent of vm370 group going to work for DEC (extracted from melinda's paper)
https://www.garlic.com/~lynn/2006m.html#21

endicott managed to stave off vm370 product actually being killed and got a few of the original development people moved to endicott ... there is more detail in melinda's paper (however, large number of people did move to POK as part of supporting mvs/xa development).

in some of the threads about the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

being larger than the arpanet/internet from just about the beginning until possibly mid-85 ... i also slightly dig multics.

in the mid-70s, the number of vs2 and vs1 customer "batch" installations were larger than the number of customer vm370 installations. the number of customer vm370 installations was larger than the number of internal, corporate vm370 installations (although in places like the internal network ... the number of vm370 internal installations far outnumbered any other operating system internal installations, mvs, jes2, jes3).

for a short period, while i was at the science center ... i also personally built, distributed and supported highly modified vm370 for small number of internal locations. however, that number was more than the total number of all multics systems ever deployed.

also some past postings about the number of vax systems sold (by year, us/non-us, model, etc) ... and that the number of vm 4331/4341 systems were larger than the total number of vax systems
https://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#5 Blade architectures
https://www.garlic.com/~lynn/2005f.html#37 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005n.html#10 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
https://www.garlic.com/~lynn/2006k.html#31 PDP-1
https://www.garlic.com/~lynn/2006l.html#17 virtual memory

Mainframe Limericks

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Limericks...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 23 Jun 2006 11:53:09 -0600

Shmuel Metz , Seymour J. wrote:
What did they use for a test machine before the 3081 was available? There was a micro-order on the 3168 that was highly suggestive.

re:
https://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks

refers to posting
https://www.garlic.com/~lynn/2006m.html#21 The very first text editor

refers to abbreviated quote from Melinda's history paper at:
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist

the following is a little more detail from that referenced extract (regarding 16 percent went to work for DEC):
Boston and its suburbs provided other opportunities that didn't require the VM developers to move away from the bright lights and disrupt the lives of their families. By the end of 1976, sixteen percent of the former Burlington personnel were working for DEC. Forty-seven percent had found IBM positions that didn't require them to move to Poughkeepsie. To make matters worse, several of the most knowledgeable CP people who did go to Poughkeepsie, including Dick Newson and Per Jonas, were put into a separate group whose purpose was to build a tool that could be used for the development of MVS/XA. Pete Tallman, of VMA fame, also joined what came to be known as the ''VM Tool'' project as soon as it moved to Poughkeepsie. Starting with VM/370 Release 3, PLC 06, the VM Tool group began building a fast, stripped-down CP that would create XA virtual machines on a real 370 so that the MVS developers could test MVS/XA.

... snip ...

something similar happened with os/360 operating system virtual memory development ... the earlier os2/vs2 svs prototype work with MVT incorporating some of the cp67 virtual address space support was done on 360/67 ... and then moved to "virtual 370s" and much later "real 370s".

370 was originally announced w/o virtual memory support and 360 operating systems ran with very little changes.

however, one of the early uses of the internal network technology
https://www.garlic.com/~lynn/subnetwork.html#internalnet

was joint development project between the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

and endicott to modify cp67 (running on 360/67) to provide 370 virtual machines (including support for 370 virtual memory architecture that had hardware tables different than what was defined for 360/67).

the initial set of updates were the "cp67-h" changes to a standard cp67 kernel that added 370 virtual machine option (to existing 360 & 360/67 virtual machine options). then there were a set of "cp67-i" changes (on top of the "cp67-h" changes) that change the kernel to run on 370 hardware.

now because 370 virtual memory support hadn't been announced, it was being treated as super corporate secret. complicated the matters was that the science center cp67 system was also providing service to various non-employee students (and others) at various educational institutions in the boston area. so typical operation was


360/67 hardware
standard "cp67-l" system running on 360/67 hardware providing 360 VMs
"cp67-h" running in 360 virtual machine providing 360 & 370 VMs
"cp67-i" running in 370 virtual machine providing 370 VMs
      CMS running in 370 virtual machine

as a countermeasure to accidental leakage about 370 virtual memory to the public.

cp67-h & cp67-i were in regular use a year before the very first engineering 370 with hardware virtual memory was reading for testing (a engineering 370/145 in endicott). in fact, booting cp67-i on the engineering 370/145 was one of the first tests of the virtual memory hardware support. as it turned out, the first boot failed. a little more examination showed that the hardware had reversed the op-codes in a couple of the new B2xx instructions ... while cp67-i had it correct. the cp67-i kernel was patched to correspond to the (wrong) hardware implementation and then booted successfully.

there was a different problem leading up to 370 virtual memory announcement. pok engineers had to design virtual memory hardware retro-fit for 370/155 and 370/165 machines. they were falling something like six months behind. finally there was an escalation meeting in POK, where the 165 engineers said that if they could eliminate some of the new features defined for 370 virtual memory they could pickup six months ... and allow 370 virtual memory to be announced six months earlier. there was a decision to drop the additional features ... and other models that had already done their implementations had to drop the features.

one of the features dropped was shared segment protection (different than the 360 storage key protection). cms had been reworked to take advantage of the feature (i.e. different virtual address spaces could share the same physical pages in real memory and enforce storage alteration protection). as a result, cms had to revert to a real gludge using 360 storage key protect for different virtual address spaces sharing the same physical pages.

Old Hashing Routine

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Hashing Routine
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 23 Jun 2006 12:11:54 -0600

Shmuel Metz , Seymour J. wrote:
I don't know, but it certainly shocked me, given that there were already machines with a million words of memory. It didn't take a crystal ball to forsee growing memory demand.

I wouldn't call that the biggest mistake, however. When the S/360 came out virtually all of the major players had some sort of hardware address relocation, whether block relocation, paging or segmentation. Even IBM had paging in the laboratory. The use of absolute addresses shocked me more than the address size.

360/67 shipped with virtual memory supporting both 24-bit addressing and 32-bit addressing options (i.e. you could have 4gbyte virtual address space and used 32bit virtual addressing).

360/67 smp support also had channel director ... where all processors could address all channels.

it wasn't until 3081 that you saw greater than 24-bit virtual addressing and provision for all processors in smp configuration to address all channels.

360/67 functional characteristics:
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A27-2719-0_360-67_funcChar.pdf

before 3081, there was a real storage scenario with 3033 being approx. 4.5mips and limited to 16mbyte real storage (and 16 channels). having 3033smp (two 4.5mip processors) still limited the configuration to 16mbyte real storage. in comparison you could setup a cluster of six 4341s, approx. 1mip (six mips aggregate), each 16mbytes real storage (96mbytes aggregate), and each six channels (36 channels aggregate) for about the same money as a single 3033 processor configuration. the 16mbyte real limitation was starting represent a real system bottleneck for mvs systems

so 3033 came up with a hack for supporting 32mbyte real storage. the 370 page table entry was 16bits with a 12bit page number field (for specifying a real 4k page ... 12+12 gives 24bit addressing or 16mbytes), two defined bits, and two undefined bits. the gimmick scavenged one of the undefined PTE bits to be used in real page numbers. you could now address 2**13 4k real pages ... or 32mbytes. CCW IDAL was 31bits ... show you had bits to read/write pages into/out-of >16mbytes. the problem was that all instructions were still limited to 24bit addressing (both real and virtual). you could stick virtual pages above the 16mbyte line ... but there was periodic requirement that some kernel code running in "real mode" had to address virtual page contents about the 16mbyte line. So there was this gimmick with a dummy virtual address space ... that you stuffed an real page number below the 16mbyte line and the desired real page number above the 16mbyte line, entered virtual address space mode and copied the virtual page above the line to the virtual page location (that was below the 16mbyte real line).

Mainframe Limericks

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Limericks...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 23 Jun 2006 12:43:07 -0600

Van Dalsen, Herbie wrote:
I was mere referring to the PDP-11 that was a few years before the S/360..

This piece is from the DEC archives... Instead they started building small digital "modules" (each effectively a single component from the TX-2 design) that could be combined together to be used in a lab setting. In 1961 the company was making a profit, and started construction of their first computer, the PDP-1 (PDP being an acronym for Programmable Data Processor).

This piece is from the IBM archives...

On April 7, 1964, IBM introduced the System/360, the first large "family" of computers to use interchangeable software and peripheral equipment. It was a bold departure from the monolithic, one-size-fits-all mainframe. Fortune magazine dubbed it "IBM's $5 billion gamble."

minor ref:
http://www.sun.com/emrkt/innercircle/newsletter/0905howard.html

from above:
The seeds of a minicomputer revolution were planted as early as 1960, with the introduction by Digital Equipment Corporation of the transistor-based PDP1 for technical computing by engineers and scientists. The PDP1 was succeeded by the PDP5, then the highly successful PDP8 in 1965 and the PDP11 in 1969.

... snip ...

a pdp1 page (as opposed to pdp11):
http://www.dbit.com/~greeng3/pdp1/
https://web.archive.org/web/20050330083323/http://www.dbit.com/~greeng3/pdp1/
http://www.accreditedonlinecolleges.net/history-of-the-digital-equipment-corporation-dec/

a history of computers
http://www.sskrplaw.com/publications/cyber3.pdf

from above:
1/48 IBM makes it first computer
1952 IBM produces 701, designed by Nathaniel Rochester, first production
line electronic stored program computer
1954 IBM's John Backus creates Fortran
1954 Gene Amdahl develops first operating system used on IBM 704
1957 Harlan Anderson and Ken Olson form DEC
1960 DEC builds PDP1, producing 50 machines

... snip ...

so based on earlier reference, they may have started building PDP1s in 1960 but possibly didn't begin shipping the 50 machines until 1961?

so a little more topic drift about the boston programming center on the 3rd flr of 545tech sq.

the cp67 group split off from the science center and took over the boston programming center on the 3rd floor (and subsequent growth and morphing into the vm370 group, they moved to old service bureau corp. building in burlington mall).

as previously mentioned
https://www.garlic.com/~lynn/2006m.html#21 The very first text editor

Jean Sammet was at the Boston Programming Center on the 3rd flr at the time ... but so was Nat Rochester.

Mainframe Limericks

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Limericks...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 23 Jun 2006 15:46:36 -0600

David.W.Neylon@ibm-main.lst wrote:
UNIX was officially named in 1970. MVS was released in 1974. However MVS was preceded by MVT which was released in 1964.

os/360 ... pcp. i don't remember that you could "sysgen" mvt until release 12.

boeing huntsville had custom modified mvt version 13 with virtual memory support running on two processor 360/67. the system didn't support paging ... but workload was a lot of long running 2250 (graphics) "jobs". mvt had a tendency to fragment storage ... and mvt applications tended to require contiguous storage allocation. use of virtual memory hardware allowed emulation of contiguous storage (even when real storage was severely fragmented).

at the univ. we didn't "sysgen" mvt until release 15/16 (i.e. there had been problems with release 15 which delayed ship ... and they eventually shipped it as combined with release 16).

some historical references:
http://www.os390-mvs.freesurf.fr/mvshist1.htm
http://mcraeclan.com/Links/Computers/IBMMainframeHistory/mvshist1.htm

the above references "sysgen" process which was typically done using the "starter" system.

at the univ, starting with release 11, I had done a lot of work for doing "sysgens" in production job stream. apart of this was that as an undergraduate, I would get the datacenter to myself on the weekends (8am sat. until 8am monday). however, related to release 9.5 sysgen, a couple of univ. employees and local ibm SEs would take a couple weekend shifts to boot starter system and do release 9.5 sysgen. i got curious and duplicated their stage1 sysgen deck ... and then started looking at what was involved in the process. basically would assemble stage1 sysgen deck ... which would "punch" a bunch about a box of cards ... that represented the "stage2" sysgen ... that actually built the new system (50-80 job steps, lots of iebcopy and iehmove steps, along with smattering of other stuff).

part of the activity was to redo sysgen so i could run it in production job stream. the other was so that i could carefully control the placement of datasets and pds members for optimal disk arm movement (in the resulting generated system).

later boeing was putting together bcs (boeing computer services) and they hired me for summer job to help set things up. i was given an management badge (that allowed me to park in "management" parking lot at boeing hdqtrs bldg at boeing field). they had installed a new 360/67 uniprocessor for running cp67 and were in the process of acquiring the 360/67s that were at boeing huntsville.

misc. past posts mentioning modifying stage1/stage2 sysgen to run in production job stream ... note previous mention about presentation made at fall68 share meeting in Atlantic City regarding running os/360 in cp67 virtual machine ... also mentions getting around 300percent increase in thrput for some typical univ. workload with the careful disk arm motion optimization.
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
https://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
https://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
https://www.garlic.com/~lynn/2003c.html#51 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
https://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
https://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005h.html#6 Software for IBM 360/30 (was Re: DOS/360: Forty years)
https://www.garlic.com/~lynn/2005n.html#40 You might be a mainframer if... :-) V3.8
https://www.garlic.com/~lynn/2005o.html#12 30 Years and still counting
https://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloads
https://www.garlic.com/~lynn/2005t.html#18 Various kinds of System reloads
https://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s

Old Hashing Routine

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Hashing Routine
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 23 Jun 2006 18:59:04 -0600

Shmuel Metz , Seymour J. wrote:
Indeed, but they forgot the need to adjust address constants and variables when moving things around. They should have given the software types more say in the design.

os/360 relocatable address constants are a real pain.

tss/360 (the "real" operating system that was suppose to be for 360/67) had a different mechanism ... moving address constants out of the program image ... so they could do "memory mapped" program execution ... w/o having to preload the program image and run thru all the various address constants (in the image) and swizzling them to the appropriate value (required by the os/360 genre).

part of the issue was that the executable paged mapped (out of the filesystem on disk) object could occupy a read-only shared segment ... that might possibly be at different address locations in different virtual address spaces. As a result, it wasn't just having to preload the executable image pages to swizzle the address constants ... but also the executable image was r/o and might not have a constant fixed location in every virtual address space (i.e. there would be no single value for address constants that were acceptable across all possible address spaces).

note that multics had similar issues and addressed them in similar manner. recent post with some multics pointers
https://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks

in any case, tss/360 had a hard time achieving market acceptance ... partially because the code implementation was significantly slowwwwwww ... and after i had a couple months as an undergraduate rewriting cp67 kernel code ... cp67 was running rings around tss/360 ... and could also offer virtual machine capability (on the same 360/67 hardware). a morph of tss/360 to tss/370 and then to ssup ... did find some deployment inside at&t. ssup was stripped down to its basic kernel functions with higher level unix functions layered on top of the lower level tss/370 functions.

now when i did paged mapped filesystem for cp67/cms ... later ported to vm370/cms ... with similar capability
https://www.garlic.com/~lynn/submain.html#mmap

I was placed in a real bind. cms had picked up a lot of its environment by adapting many os/360 assemblers, compilers, and applications (and therefor inheriting the os/360 address constant convention). i had to play all sorts of games to create page mapped executable objects that could occupy shared segments in multiple different virtual address spaces, potentially simultaneously at different virtual addresses ... a few posts mentioning some of the hoops i had to go thru dealing with os/360 address constants in a virtual address space, paged mapped filesystem paradigm
https://www.garlic.com/~lynn/submain.html#adcon

Mainframe Limericks

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe Limericks...
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 24 Jun 2006 09:18:26 -0600

Joe Morris wrote:
Anne & Lynn Wheeler writes:

> os/360 ... pcp. i don't remember that you could "sysgen" mvt until
> release 12.

That agrees with my recollections. And one other event at release 12 was that the sources were all resequenced...which wasn't really that much of an additional problem since so much of the code was reworked for MVT.

Side question: "MVT" stood for "Multiprogramming with a Variable number of Tasks." There was another name for MVT that appeared occasionally in the self-documentation comments at the front of some source modules; IIRC it was a 3-character term ending in "2" but I can't recall it. Does this ring a bell with anyone? And where did it come from, and why did it drop out of use?

> at the univ. we didn't "sysgen" mvt until release 15/16 (i.e. there had > been problems with release 15 which delayed ship ... and they eventually > shipped it as combined with release 16).

Pity that someone didn't put release 17 out of its misery prior to FCS and combine it with 18.

At the SHARE meeting following the release of 17 (Boston maybe?) there was a session in which the IBM reps were being "sorely beaten upon" by users because of the errors in the code; one of the IBMers finally responded with "Do you expect us to always get it right the first time?"

The user who had been airing his gripes shot back "No, but we do expect it to work the 17th time."

Everyone (including, although somewhat nervously, the IBMers) laughed.

> part of the activity was to redo sysgen so i could run it in production > job stream. the other was so that i could carefully control the > placement of datasets and pds members for optimal disk arm movement (in > the resulting generated system).

Was this work the origin of the "JCAMOD" utility?

Joe Morris

re:
https://www.garlic.com/~lynn/2006m.html#29 Mainframe Limericks

not directly that i know of ... but it may have help contribute to being able to specify cylinder location of disk VTOC that appeared in release 15/16. now i could place VTOC in the middle of the volume and somewhat array files and PDS members radiating out from the center (instead from cylinder zero) ... although PDS members was straight forward on the increasing cylinder side of the VTOC ... but was less straight forward on the decreasing cylinder side of the VTOC.

Old Hashing Routine

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Hashing Routine
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 24 Jun 2006 12:00:35 -0600

Jim Mulder wrote:
The architecture scavenged two PTE bits to allow for 64mbytes of real storage. I don't think the 3033 ever supported more than 32mbytes, and I am not sure about the 3081, but there were customers running MVS/370 on the 3090 with 64mbytes of real storage.

re:
https://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine

in past posts i've told the story both ways ... both of the unused bits by architecture allowing PTEs to address up to 2**14 4k real pages (64mbyte) or one unused bit by 3033 to support 2**13 4k real pages. I remember lots of 32mbyte 3081s but don't remember any 64mbyte 3081s.

part of this is my scenario about dasd had declined in relative system performance by a factor of ten times over 10-15 yr period i.e. rest of the system resources/thruput increased by 40-50 times while dasd increased by only 4-5 times.

at least by the time i release the resource manager ... 11may76, you were starting to see real storage used to compensate for system thruput being constrained by dasd performance. i had done much of the work as an undergraduate in the 60s for cp67 ... which then got dropped in the morph from cp67 to vm370 ... but then was allowed to rerelease it as the resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

i had a comparison of cp67 360/67 configuraiton and a vm370 3081 configuration ... and observed if overall system thruput had kept pace with the cpu, the typical number of users would have gone from 80 on 360/67 to over 2000 on 30831 ... but in fact, typical 3081 configurations tended to be more like 300-400 users ... which represented the change in dasd thruput between 360/67 and 3081.

this is the story about initially the san jose disk division assigned their performance group to refute the claims ... but they came back a couple weeks later and explained that i had actually understated the problem.

the other issue is that ckd dasd from the 60s ... traded off i/o thruput with extended (& multi-track) searches for real memory use ... i.e. more real memory intensive tended to cache indexes to specific disk location ... while vtoc & pds multi-track search spun the disk to find location. Some of the IMS ccw programs took this to the extreme with long ccw programs searching and finding fields in disk-based index structures ... which then were read and used for further searching ... all in a single channel program.

i've often repeated story about being called into a large national retailer with a large complex of vs2 processor complex ... basically loosely-coupled with processors dedicated to each region. they were experience sever performance degradation. turns out they had a large application program library shared across all processors in the complex with a three (3330) cylinder PDS index. aggregate number of I/Os to (across all processors in the complex) avg. about 6.5/sec ... because they were doing avg 1.5 cylinder search of the PDS index. the multi-track search of the first cylinder at 3600rpm/19cylinders was about .3secs elapsed time (i.e. being limited to approx three application program member loads per second aggregate across all the processors in the complex).
https://www.garlic.com/~lynn/submain.html#dasd

the other place that you saw real memory compensating for dasd performance was with the emergance of rdbms in the 80s. there were arguments between STL (60s physical database) and SJR ... original relational/sql database implementation
https://www.garlic.com/~lynn/submain.html#systemr

the 60s paradigm had direct record pointers imbedded as part of the database infrastructure and exposed to application programmers. this allowed going directly from one record to the next relatively efficiently. however, there was heavy people and skill resource overhead for management of the structure.

system/r abstracted away the direct pointers with the relational paradigm ... substituting internal index tree structure managed by the dbms (no longer requiring direct administrative and application support). this significantly decreased the people and skill resources needed to manage the infrastructure. however, it might take 5-6 disk reads of index structure to find the disk record pointer to the actual record needed. the other argument was that the on-disk index structure could double the physical disk space required for relational implementation vis-a-vis a "60s" physical dbms implementation.

what happened in the 80s was that disk space became increasingly less expensive ($$/mbyte which has now shifted $$/gbyte) and the explosion in real memory sizes allowed much of the relational index to be cached in real memory (eliminating a lot of the additional disk reads to get to the actual record).

various past posts discussing the STL/SJR argument over "60s" physical databases (with direct record pointers) and relational which created a dbms metaphor that eliminated the direct record pointers from the database abstraction:
https://www.garlic.com/~lynn/2000c.html#13 Gif images: Database or filesystem?
https://www.garlic.com/~lynn/2004e.html#23 Relational Model and Search Engines?
https://www.garlic.com/~lynn/2004e.html#25 Relational Model and Search Engines?
https://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
https://www.garlic.com/~lynn/2004p.html#1 Relational vs network vs hierarchic databases
https://www.garlic.com/~lynn/2004q.html#23 1GB Tables as Classes, or Tables as Types, and all that
https://www.garlic.com/~lynn/2005.html#25 Network databases

various past posts about the two unused bits in the 370 PTE and using them to increase the number of real pages that could be specified (greater than 2**12 4k real pages past 16mbytes):
https://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
https://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?
https://www.garlic.com/~lynn/2004.html#17 Holee shit! 30 years ago!
https://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2006b.html#34 Multiple address spaces
https://www.garlic.com/~lynn/2006l.html#2 virtual memory

Why Did No Core Machines Have Cache ???

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why Did No Core Machines Have Cache ???
Newsgroups: comp.arch
Date: Sun, 25 Jun 2006 09:07:46 -0600

glen herrmannsfeldt writes:
As far as I know, the first machine with cache was the 360/85. It was at that time that the idea of locality and potential advantage of cache was discovered. I believe it was core, but I would have to look it up to be sure. IBM did have some fast cores for small memories so it is possible. Core speed depends on core size, and faster, smaller cores are harder to work with.

As I understand it, the first use of semiconductor memory for a processor, maybe excluding registers, was the protection keys for the 360/91.

The result was that the 360/85 performance was close to that of the 360/91, which didn't have cache, but had 16 way interleaved 750ns core for a 60ns cycle processor.

a little search engine use
https://people.computing.clemson.edu/~mark/admired_designs.html

and some more
Model Announced First Shipped Withdrawn 85 January 30, 1968 December 1969 June 24, 1971

Structural aspects of the System/360 Model 85, Part I: General organization
http://domino.research.ibm.com/tchjr/journalindex.nsf/495f80c9d0f539778525681e00724804/a846ccbbdfe8f77a85256bfa00685a32?OpenDocument

abstract:

A basic design objective for the Model 85 was to add a computer to the SYSTEM/360 line that offers high performance over a wide range of job types. Simulation studies indicate that the Model 85 will provide an average three- to five-fold increase in internal performance with main storage capacities of up to four million bytes. This part of the paper discusses the major elements of the Model 85 within the architectural context of SYSTEM/360, including the addition of a high-speed buffer, called a cache. Also summarized are the simulation studies that led to use of the cache, selection of its parameters, and verification of internal performance of the system.

... snip ...

http://www.research.ibm.com/journal/sj/071/ibmsj0701B.pdf

PDP-1

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Sun, 25 Jun 2006 09:56:18 -0600

Anne & Lynn Wheeler writes:
re:
https://www.garlic.com/~lynn/2006k.html#29 PDP-1

from keykos history, here is account of Tymshare offering vm370 based timesharing starting in the early 70s
http://www.cap-lore.com/CapTheory/KK/History.html

re:
https://www.garlic.com/~lynn/2006k.html#37 PDP-1

for some additional (recent) drift on this old post
FC++3 - Advances in Financial Cryptography, Number Three
https://financialcryptography.com/mt/archives/000757.html
FC++3 - Dr Mark Miller - Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control
https://financialcryptography.com/mt/archives/000702.html

I'm program co-chair of security and virtualization track at IEEE TC Computer Elements, Vail 2006 starting later today. One of the talks is
5.1 Virtualization/Security- Prog Lang Design Mark Miller

ref:
https://www.garlic.com/~lynn/aadsm24.htm#11 FC++3 - Advances in Financial Cryptography, Number Three

some of the co-authors here were involved with Tymshare, gnosis, keykos, etc
http://www.erights.org/talks/index.html

Draft Command Script Processing Manual

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

From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Subject: Re: Draft Command Script Processing Manual
Date: Sun, 25 Jun 2006 15:11:52 -0700

Brian Westerman wrote:
I have the draft manual for the command script processing program ready for those that are interested in taking a look at it before I finalize it. If you would like to take a look at it for me it can be downloaded from:

for some drift, here are old posts reference parasite/story from the late 70s.
https://www.garlic.com/~lynn/2001k.html#35
https://www.garlic.com/~lynn/2001k.html#36

parasite did 3270 terminal emulation. it was less than 8k bytes executable (written in assembler). story was the scripting processor ... also less than 8k bytes executable (written in assembler). the reference includes story syntax and has example of some number of story "scripts". story processing included support for REX variables ... aka still internal software ... before it was renamed to REXX and released as a product.

there is even an example story in the above to automatically retrieve put bucket from retain.

English (was Mainframe Limericks

From: lynn@garlic.com
Subject: Re: English (was Mainframe Limericks
Newsgroups: bit.listserv.ibm-main
Date: 28 Jun 2006 08:36:41 -0700

and to bend it even again ...

Mother tongue may determine maths skills
http://www.newscientistspace.com/article.ns?id=dn9422&feedId=online-news_rss20

from above ...
The native language you speak may determine how your brain solves mathematical puzzles, according to a new study. Brain scans have revealed that Chinese speakers rely more on visual regions than English speakers when comparing numbers and doing sums.

... snip ...

this somewhat reminds me of a description of analog vis-a-vis digital clocks. the analog hands ... not only give the current time but can spatially represent how long since or how long to some time.

Curiosity

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Curiosity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 29 Jun 2006 18:10:54 -0600

Jim Mulder wrote:
O(n) - searching a list of n elements O(n ** 2) - bubble sort of n elements O(n * log(n)) - heap sort of n elements

there are many cases of searching list of n elements ... which can result in non-linear overhead increases. this typically happens when the frequency of searching is possibly related to load, but the length of the list can increase much faster than increase in processing (say a queue).

early implementations of TCP "FINWAIT" were linear lists. as part of closing TCP session, in part, because IP packets arrive out-of-order ... a list of sessions in the process of being closed and recently closed sessions were kept. in early implementations, assuming the number of items on the FINWAIT list were relatively few (in part because of assumptions that TCP sessions were relatively long lived), they used linear list. In any case, when packet arrives, there is (quick?) search of FINWAIT list to see if it is related to such a session.

HTTP came along and used TCP for transaction operations (TCP session requires a minimum of 7 packet exchange; by comparison VMTP/RFC1045, more oriented towards reliable transaction, has minimum 5 packet exchange; and XTP for reliable transaction has minimum 3 packet exchange). This violated various assumptions about TCP sessions being long lived, frequency of TCP session termination and probable number of items on lists.

As some web servers became popular, they started running into horrible processing bottlenecks with 99percent of the processor devoted to searching the FINWAIT list (in some cases with over 10,000 items). Each search of the list was linear, but the total time-spent searching the list, increased non-linear ... since the length of the list increased dramatically (because of the humongous number of closing short-lived HTTP TCP sessions).

in any case, overhead of O(n) implementations can increase non-linearly when the number of "n" shows large increases (because of load and/or the frequency of the searching also increases).

RFC763 talks about FIN processing ...

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

RFC793 summary:
https://www.garlic.com/~lynn/rfcidx2.htm#793

from above:
793 S
Transmission Control Protocol, Postel J., 1981/09/01 (85pp) (.txt=172710) (STD-7) (Updated by 3168) (Obsoletes 761) (Ref'ed By 788, 821, 879, 882, 883, 915, 916, 959, 964, 977, 983, 1001, 1006, 1034, 1035, 1050, 1057, 1063, 1072, 1085, 1086, 1095, 1105, 1106, 1122, 1163, 1177, 1185, 1189, 1190, 1201, 1206, 1241, 1244, 1254, 1267, 1270, 1301, 1323, 1325, 1349, 1379, 1475, 1538, 1561, 1594, 1626, 1644, 1654, 1693, 1700, 1705, 1707, 1726, 1770, 1771, 1812, 1831, 1858, 1859, 1936, 1948, 1953, 1982, 2012, 2018, 2074, 2126, 2140, 2219, 2246, 2326, 2391, 2428, 2481, 2488, 2507, 2525, 2577, 2581, 2637, 2663, 2675, 2747, 2760, 2775, 2780, 2795, 2821, 2828, 2873, 2885, 2896, 2914, 2960, 2975, 2988, 2993, 3015, 3018, 3022, 3033, 3042, 3080, 3081, 3093, 3094, 3117, 3124, 3135, 3142, 3148, 3155, 3168, 3196, 3237, 3242, 3252, 3322, 3360, 3366, 3430, 3436, 3449, 3481, 3511, 3517, 3522, 3525, 3530, 3539, 3588, 3639, 3708, 3715, 3720, 3723, 3724, 3730, 3734, 3748, 3783, 3819, 3821, 3828, 3836, 3920, 3955, 4138, 4145, 4163, 4180, 4294, 4297, 4340, 4341, 4347, 4362, 4413, 4497) (TCP)

... snip ...

clicking on the ".txt=nnn" field in an RFC summary, retrieves the actual RFC.

so here is random reference from the web on how long something is kept on lists (i.e. particular session kept in particular state)
http://mail-index.netbsd.org/tech-net/2002/11/07/0000.html

from above:
The first FIN from either side (after passing sequence number checks, of course) puts the state entry into tcp.closing, and a subsequent ACK from the other side puts the state into tcp.finwait.

The state will be removed after no packet has been associated with it for a number of seconds, the default timeout values are 900 seconds for tcp.closing and 45 seconds for tcp.finwait. If subsequent packets like retransmissions or parts of a simultanous close match the state entry, the timer is reset again (to tcp.closing or tcp.finwait, respectively).

Timeouts can be set globally and overriden per rule for tcp.first, .opening, .established, .closing, .finwait and .closed.

... snip ...

Computers in the movies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computers in the movies
Newsgroups: alt.folklore.computers
Date: Thu, 29 Jun 2006 22:01:38 -0600

"Derek Simmons" writes:
On the Internet Movie Database website (www.imdb.com) in the trivia section for Wargames it says the following about the mainframe computer, WOPR:

past trivia posting mention wargames movie and reference its imdb.com entry
https://www.garlic.com/~lynn/2003g.html#56 OT What movies have taught us about Computers

other past trivia postings about wargames movie
https://www.garlic.com/~lynn/2000d.html#39 Future hacks [was Re: RS/6000 ]
https://www.garlic.com/~lynn/2001m.html#52 Author seeks help - net in 1981
https://www.garlic.com/~lynn/2002b.html#38 "war-dialing" etymology?
https://www.garlic.com/~lynn/2003m.html#14 Seven of Nine
https://www.garlic.com/~lynn/2004p.html#40 Computers in movies
https://www.garlic.com/~lynn/2006f.html#7 The Pankian Metaphor

Using different storage key's

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Using different storage key's
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 30 Jun 2006 13:06:17 -0600

Tom Marchant wrote:
The Amdahl 580 series had the same sort of thing, but they called it macrocode. It made it easy to implement new instructions. An interrupt would cause a switch to "System state" and macrocode would decide what to do with it. Macrocode, combined with increased addressability and some novel channel architecture made it relatively simple to implement XA.

MDF was implemented with a lot of special registers and macrocode to perform the necessary setup.

Too bad I didn't keep my copy of the ALTA POO when I left the company...

It was also used to implement the original hypervisor ... which IBM eventually had to respond to with PR/SM in 3090.

We used to talk about it at the monthly meetings at SLAC ... possibly even talked about it before it was even announced. I also had discussed some of my experiences having worked on ECPS for 138/148 ... a couple of old ECPS postings
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

I have some vague recollection of one of the people who had done the hypervisor implementation saying that they had hoped for better thruput improvement based on my comments regarding ECPS.

various collecting postings discussing various microcode aspects (mostly 360 or 370)
https://www.garlic.com/~lynn/submain.html#360mcode

Microcomputers As A Space Spinoff

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcomputers As A Space Spinoff
Newsgroups: alt.folklore.computers
Date: Sat, 01 Jul 2006 19:09:23 -0600

Larry Elmore writes:
I read this post to my wife, and she thought she knew what two types you were speaking of even before your washroom hint, but she wasn't sure because she certainly didn't fit into "her" group. Then she thought about it and decided that made a lot of sense. Other than a love for shopping and shoes, she has little in common with most women's attitudes and thought patterns.

recent post slightly related to thot patterns ... referencing myers-briggs personality types
https://www.garlic.com/~lynn/aadsm24.htm#13 On Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes

in a blog entry discussing leadership,
https://financialcryptography.com/mt/archives/000767.html

and so also had to throw in a reference to Boyd's talk on organic design for command and control
http://www.belisarius.com/

Why Didn't The Cent Sign or the Exclamation Mark Print?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why Didn't The Cent Sign or the Exclamation Mark Print?
Newsgroups: alt.folklore.computers
Date: Sun, 02 Jul 2006 12:46:28 -0600

so most of the early cp67/cms work was all done with 2741 terminal keyboards

reference can be found here
http://www.quadibloc.com/comp/kybint.htm

so one of the conventions used was that "@" was used as "character delete" .... lower case key to the right of the "P" key (found at the above) and cent-sign was used as "line delete" (or rather all characters to the left of the cent-sign) ... the upper case of the same "@" key, just to the right ot the "P" key.

so the univ. was the first cp67 installation with tty33/ascii terminals ... and so among all the other changes I made to cp67 (as an undergraduate in the 60s) was to redo the terminal support to add tty33/ascii support. One of the issues was what to map for the character-delete and line-delete ... but as you can see in the "Typewriter-pairing ASCII (original form)" keyboard layout (same URL and just above the 2741 keyboard layout) ... what is the lower/upper case characters of the key to the right of the "P" key???

i was trying to do tricks with automatic terminal recognition and found that the standard ibm telecommunication controller couldn't quite do everything that i wanted. That somewhat was what led to the univ. starting the project to build our own telecommunication controller ... that could do everything that I wanted ... which in turn led to somebody writing an article blaming four of us for the ibm plug compatible controller business ... misc. past posts
https://www.garlic.com/~lynn/submain.html#360pcm

Why Didn't The Cent Sign or the Exclamation Mark Print?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why Didn't The Cent Sign or the Exclamation Mark Print?
Newsgroups: alt.folklore.computers
Date: Sun, 02 Jul 2006 20:38:40 -0600

seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
My university, which used MTS, used a PDP-11 as a front-end communications processor, but I have no idea if there was any politics behind it. I figured it was just cheaper than whatever IBM had... or, more importantly, it was being used to connect standard cheap non-IBM terminals like LA36 Decwriters and Tektronix 4010s to the computer.

re:
https://www.garlic.com/~lynn/2006m.html#41 Why Didn't The Cent Sign or the Exclamation Mark Print?

a couple past posts mentioning the MTS and PDP stuff
https://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
https://www.garlic.com/~lynn/2006k.html#41 PDP-1
https://www.garlic.com/~lynn/2006k.html#42 Arpa address

this has a picture of the 67 running MTS ...
http://www.eecis.udel.edu/~mills/gallery/gallery8.html

although the comment is a little off since cp40 (on 360/40 with custom hardware virtual memory) was operational before either mts or multics. and the port of cp40 from 360/40 to 360/67 for cp67 was about the same time-frame as MTS ... mentioned here as May, 1967:
http://www.clock.org/~jss/work/mts/30years.html

here is the picture of the PDP8 as a front-end communication processor for MTS
http://www.eecis.udel.edu/~mills/gallery/gallery7.html

so what is the tie-in between network time protocol and MTS? this is my RFC summary entry for NTP standard (clicking on the "txt=nnn" field retrieves the actual RFC:
https://www.garlic.com/~lynn/rfcidx4.htm#1305

here is some reference to additional MTS information (the pages look like what were at umich ... but those URLs have gone 404)
http://www.clock.org/~jss/work/mts/index.html
http://www.clock.org/~jss/work/mts/summary.html

this also tells some more of the story of MTS starting out with LLMPS as its basis
http://www.clock.org/~jss/work/mts/30years.html

LLMPS done at lincoln labs ... which installed cp67 on their 360/67 in 67. then the univ. i was at what become the 3rd cp67 installation when some people from the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

came out the last week in jan68 to install it.

"multics" home page (which was on the 5th flr, 545 tech sq, while the science center doing cp67 was on the 4th flr)
https://www.multicians.org/

multics cronology
https://www.multicians.org/chrono.html

has reference to the 5/67 date for MTS
http://www.clock.org/~jss/work/mts/

and multics phase 1 milestone with single process boot, 12/67
https://www.multicians.org/phase-one.html

and the "official" release of cp67 on 5/68. other dates from the multics cronology has 9/67 as PDP-10 being announced and BBN starting work on TENEX.

demonstrable initial multics milestone w/8 users, 10/68.

other early history about ctss, multics, cp40, cp67, virtual machine, etc from Melinda's history paper
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist

totally unrelated postings mentioning umich
https://www.garlic.com/~lynn/99.html#15 Glass Rooms (was Re: drum memory (was: Re: IBM S/360))
https://www.garlic.com/~lynn/2002l.html#22 Computer Architectures

Google Architecture

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Google Architecture
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 03 Jul 2006 08:37:12 -0600

Anne & Lynn Wheeler writes:
so last fall, i was at a conference and there was a talk about "google as a supercomputer". the basic thesis was that google was managing to aggregate large collection of processing power and data storage well into the supercomputer range ... and doing it for 1/3rd the cost of the next closest implementation (in terms of cost).

re:
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
Google Moves From Search to Inventor
http://slashdot.org/story/06/07/03/0645207/google-moves-from-search-to-inventor

... from above:
The New York Times reports that Google continues to expand its scope from search engine to inventor. Google assembles the majority of the hardware it uses and deploys at such a large scale, that Google may be 'the world's fourth-largest maker of computer servers, after Dell, Hewlett-Packard and I.B.M.'. The article also states that Google may be entering the chip design market with new employees who were ex-Alpha Chip engineers.

... snip ...

Musings on a holiday weekend

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Musings on a holiday weekend
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 03 Jul 2006 09:52:46 -0600

McKown, John wrote:
From what I've been told, that compatability "problem" is why FS (Future System) did not take off as a replacement for the S/370. It eventually, again from what I am told, became the AS/400 (iSeries). The i5/OS that runs on the iSeries is simply amazing to me. We looked at it as a possible replacement for z/OS. The z/OS "conversion" has been aborted by the new CIO (nice man!). Not that we will necessarily stay on z/OS "forever". But if we every get off of it, the plan now is because all the functionality on it has been replaced with new systems on new platform(s).

...

While FS was incompatible ... there were lots of other issues. It was extremely ambitious with seemingly every blue-sky concept that ever existed being thrown into the pot. At the time, I somewhat ungraciously compared it to a cult film that had been playing continuously down in central sq for over a decade (as the inmates being in charge of the institution). I also claimed that what I had running at the time was "better" than what was described for resource management in the FS architecture documents.

I believe the "nail" in the FS coffin was a study by the Houston Science Center ... applications run on a FS machine built out of the same level technology as used in 370/195 ... would have thruput approximately that of 370/145 (FS hardware complexity reduced thruput by over an order of magnitude).

After the death of FS ... some number of people went off to Rochester and created the s/38 that implemented some of the concepts from FS ... as/400 cisc was the follow-on to s/38. later as/400 was ported from cisc technology to power/pc technology. misc. collected posts on 801, romp, rios, power/ps, etc
https://www.garlic.com/~lynn/subtopic.html#801

old post (in this n.g./mailing list) that has some quotes from another source
https://www.garlic.com/~lynn/2000f.html#16 FS - IBM Future System

as mentioned in the above ... a lot of FS was reaction to appearance of plug-compatible controllers. recent posts mentioning working on plug-compatible controller as undergraduate ... and subsequent article that blamed that project for the plug-compatible controller business
https://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
https://www.garlic.com/~lynn/2006m.html#40 Microcomputers As A Space Spinoff
https://www.garlic.com/~lynn/2006m.html#41 Why Didn't The Cent Sign or the Exlamation Mark Print?

past collected posts mentioning plug compatible controllers
https://www.garlic.com/~lynn/submain.html#360pcm

there is some folklore that the FS mantra/direction may have contributed to Amdahl leaving to do (plug-compatible) high-performance 370 (processors)

past collected posts mentioning FS
https://www.garlic.com/~lynn/submain.html#futuresys

Musings on a holiday weekend

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Musings on a holiday weekend
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 03 Jul 2006 10:44:34 -0600

Ted Macneil wrote:

https://www.garlic.com/~lynn/submain.html#futuresys

With all due respect!

Is there anything you don't have a web link on/about?

I have seen other people make comments, and I agree.

I have written articles (though not as many as you), but aside from mentioning them once, I let it go.

Could you do so too, please?

...

re:
https://www.garlic.com/~lynn/2006m.html#44 Musings on a holiday weekend

this was step up from complaints about including all the URLs in the body of each post ...

Musings on a holiday weekend

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Musings on a holiday weekend
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
CC: ibmmain <ibm-main@bama.ua.edu>
Date: Mon, 03 Jul 2006 10:51:16 -0600

Anne & Lynn Wheeler wrote:
After the death of FS ... some number of people went off to Rochester and created the s/38 that implemented some of the concepts from FS ... as/400 cisc was the follow-on to s/38. later as/400 was ported from cisc technology to power/pc technology. misc. collected posts on 801, romp, rios, power/ps, etc
https://www.garlic.com/~lynn/subtopic.html#801

...

re:
https://www.garlic.com/~lynn/2006m.html#44 Musings on a holiday weekend

one could look back and claim that 801/risc activity was significantly motivated by FS and to do the exact opposite of FS with regard to hardware complexity. the other aspect, is to define a hardware architecture that had possibility of being implemented in a single chip (of the period). However, much of the 801/risc hardware mantra was KISS ... nearly the exact opposite of the FS hardware mantra.

So it was somewhat interesting to see the s/38 descendant (as/400) eventually move to 801/risc hardware platform.

for a little topic drift ... recent post discussing some of the KISS issue
https://www.garlic.com/~lynn/aadsm24.htm#15 Apple to help Microsoft with "security neutrality"?
https://www.garlic.com/~lynn/aadsm24.htm#16 Apple to help Microsoft with "security neutrality"?

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Tue, 04 Jul 2006 10:05:37 -0600

seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
The popularity of the IBM 360 inspired imitations... and near-imitations.

The closest of the near-imitations were the RCA Spectra 70 computers. Only those portions of the instruction set that required privileged mode to use were different. Presumably, this was intended to ensure they didn't need to fear a lawsuit by encouraging people to pirate IBM's operating system software.

Usually not even counted as an imitation at all were the Sigma computers. These computers had instructions that were all 32 bits in length; register-to-register operations were provided by means of assigning memory addresses to the registers. But the features offered were intentionally matched to those of the System/360, and the data formats were the same - with the exception of floating-point numbers, if they were negative.

In data formats, the PDP-6 had the same sort of relation to the IBM 7090 and its relatives, but even the fact that the KA-10 version of the PDP-10 had a front panel with a sloped front, and a near-horizontal extension with the rows of rocker switches on it doesn't really lead me to think of the PDP-6 and PDP-10 as imitations of the 7090. Had it not used two's complement arithmetic for integers, I might have reconsidered that.

Then there were the minis from Interdata.

I've frequently mentioned story about when I was adding tty/ascii terminal support to cp67, i couldn't quite get the ibm 2702 telecommunication controller to do what i wanted. this somewhat prompted the univ. to start a project to build our own controller. initially a reverse-engineered channel board was added to a interdata/3 programmed to emulate 2702 (but do things like automatic buad rate recognition). later it was enhanced with an interdata/4 programmed to emulate 2702 with multiple interdata/3 as dedicated linescanners.

recent post on the subject in FS thread:
https://www.garlic.com/~lynn/2006m.html#44 Musings on a holiday weekend

something similar by Umich using PDP1 in conjunction w/MTS
https://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?

collected posts mentioning the effort and plug compatible controllers
https://www.garlic.com/~lynn/submain.html#360pcm

interdata simulator reference
http://simh.trailing-edge.com/interdata.html

The System/360 Model 20 Wasn't As Bad As All That

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Tue, 04 Jul 2006 10:08:39 -0600

seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
The initial announcement comprised models 30, 40, 50, 60, 62, and 70.

The last three models were replaced by models 65 and 75 prior to delivery; the front panels looked pretty much the same, but the performance was improved over what had been announced originally.

60 and 70 were with 1mic memory ... before machines were shipped the memory was upgraded to 750ns and the models renamed 65 and 75.
note/update:

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

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

instruction timings in the functional specification ... i.e.
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/

for the machines based on 750ns memory, It was 8byte-wide (interleaved) fetch. part of the instruction timings were the prorated instruction fetch times i.e. two-byte instructions included 1/4 750ns, four-byte instructions included 1/2 750ns, and six-byte instructions included 3/4 750ns (prorated double word instruction fetch).

gory details for 360/65 timings start on page 20
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A22-6884-3_360-65_funcChar.pdf

The Pankian Metaphor (redux)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: The Pankian Metaphor (redux)
Newsgroups: alt.folklore.computers
Date: Tue, 04 Jul 2006 13:39:57 -0600

US automakers' June sales sag
http://today.reuters.com/news/newsArticle.aspx?type=businessNews&storyID=2006-07-03T214950Z_01_N03421774_RTRUKOC_0_US-AUTO-SALES.xml

from above:
U.S. sales fell for all three big American automakers in June, led by a 26 percent drop at General Motors Corp., while Japan's Toyota Motor Corp. surged.

... snip ...

Toyota poised to become top car seller in U.S.:
https://www.garlic.com/~lynn/2003l.html#29 Offshore IT

mention old 100% unearned profit tax article from the late 70s (related to auto import quotas) and automotive C4 project circa 1990
https://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Tue, 04 Jul 2006 14:26:03 -0600

seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
No! No! The 60 was with 2 microsecond memory, the 62 was the one with 1 microsecond memory!

I happened to just be reading the original version of the System Summary to try to find out the identity of a mystery front panel, one side of which I saw in an old DATAMATION ad, and which also appeared in the front of the following photo:

http://archive.computerhistory.org/resources/still-image/IBM/IBM_360/IBM.360.19xx.102657020.lg.jpg

mea culpa ... i just remember being told as undergraduate that the 360/65 as an (750ns memory) "upgrade" of an earlier announced model with 1mic memory that didn't ship.

when somebody referenced that there was a 360/62, i jumped to the conclusion that it might have also been 360/67 with one mic. memory ... in part because I have some vague recollection of reading an early overview pub on machine with virtual memory that was being offered in single (uniprocessor), two processing and four processor models (i.e. smp, multiprocessor) ... and some vague impression that it might have been a different model number.

later when 360/67 showed up there was no longer a four processor model.

there was a custom three procesor model version built for MOL (manned orbital laboratory) project delivered to lockheed ... whiched then seem to disappear. i stumbled across some reference to it showing up again (or at least part of it) at ncss ...

ncss reference here at computer history museum
http://www.computerhistory.org/corphist/view.php?s=select&cid=4

here is the reference:
http://www.computerhistory.org/corphist/view.php?s=events&id=330

from above:
Installation of first operational duplex 67 (actually 2/3's of the MOL triplex system). The team came up with a simplifying algorithm that increased perfomance over the initial algorithm very significantly.

... snip ...

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Tue, 04 Jul 2006 19:45:36 -0600

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

http://archive.computerhistory.org/resources/still-image/IBM/IBM_360/IBM.360.19xx.102657020.lg.jpg

It could also be another type of remote control panel, one of those being in the middle.

Incidentally, the *person* in the photograph is Dr. Frederic P. Brooks, Jr., author of "The Mythical Man-Month", deriving from his experiences in leading the development of OS/360.

...

i thot for a moment that it might be 2914 ... but they are typically only found in multiple machine environment
http://www.labx.com/v2/spiderdealer2/vistaSearchDetails.cfm?LVid=3017353

this has picture of multiple control consoles for 360/91 ....
http://www.columbia.edu/cu/computinghistory/36091.html

but the one "control console" is shown from the rear
http://www.columbia.edu/cu/computinghistory/36091-ibm.jpg

360 system summary
http://www.bitsavers.org/pdf/ibm/360/systemSummary/A22-6810-0_360sysSummary64.pdf

figure 6 has poor image of 360/40 and 360/70 with a 2150 console on pg. 12

pg. 20 mentions 2150 console duplicating operators' controls

pg. 21 has figure 11 with another poor imageof 2150

......

for some drift, from 360/195 functional characteristics
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A22-6943-0_360-195_funChar.pdf

pg.23 shows control panel with space for 2nd cpu control.

TCP/IP and connecting z to alternate platforms

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TCP/IP and connecting z to alternate platforms
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 05 Jul 2006 18:04:55 -0600

Roy Hewitt wrote:
Prob not if you've got Gbit OSA. Escon CTC type connections existed before OSA. In the days of 10Mb Ethernet, Escon was a lot faster, even with 100Mb it was a viable choice, but can't see why you'd want to these days..

...

escon technology had been laying around pok since the 70s ... but never actually released (for quite some period). one of the austin engineers took the spec, increased the bit rate by approx. 10percent, went to significantly cheaper optical drivers (order of magnitude cheaper). it was released as SLA (serial link adapter) with initial rs/6000. He then wanted to start on 800mbit (full-duplex) version of SLA.

we had been attending various standards meetings in that period ... HiPPI ... 100mbyte/sec parallel copper being pushed by LANL ... effectively standard version of cray channel; SCI pushed by SLAC ... high-speed full-duplex fiber optic for a number of things ... including memory bus (you saw it show up in the sequent 256 processor machine); and FCS pushed by LLNL ... basically a fiber-optic version of some serial copper stuff they had installed.

We convinced the SLA engineer instead of starting work on 800mbit SLA (as upgrade from his 220mbit enhanced escon operation) ... it would be better to devote his effort to FCS standard version ... full-duplex 1gbit fiber. After some discussion, he switched and eventually become the editor for the FCS standards document.

for even more topic drift related to that activity when we were working on cluster scale-up
https://www.garlic.com/~lynn/95.html#13

in conjunction with ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

i.e. in the half-duplex escon 200mbit/sec time-frame there were early installations of full duplex 1gbit fcs (i.e. 2gbit/sec aggregate ... targeted use both processor-to-device and processor-to-processor including tcp/ip)

Later some POK channel engineers started participating ... and I have a huge pile of archived FCS mailing list discussions where the mainframe channel engineers were attempting to layer the half-duplex copper channel paradigm on top of FCS full duplex operation (similar to what had been done for escon) .... cutting aggregate thruput as well as compromising a lot of the latency compensation that comes with full-duplex operation (big issue in various FCS configurations as well as various SCI operations). with enuf latency in half-duplex operation, the latency can start to dominate over raw bit transfer (starting to minimize the thruput difference between 200mbit/sec and 1gbit/sec).

with respect to enet ... machine i bought last year for home use came standard with 10mb/100mb/1gbit enet ... and the next machine looks like it will likely have 10gbit enet.

DCSS

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: DCSS
Newsgroups: bit.listserv.vmesa-l
Date: Thu, 06 Jul 2006 00:36:29 -0600

kris_buelens wrote:
Subject: Re: New IBM Linux redbook. Sorry Rob, DCSS stood (and still stands) for discontiguous saved segments The term "shared segment" is what people in the street talk about, but it doesn't exist as object in the VM books. What is a valid sentence: a saved segment can contain a shared segment and an exclusive segment, for shared and exclusive pages respectively.

...

I had originally done page mapped filesystem for CMS (that I called PAM for Page Access Method) on cp67
https://www.garlic.com/~lynn/submain.html#mmap

and then redone for VM370. memory mapped objects (from the filesystem) could be mapped inside the virtual address space, "outside" the virtual address space ... and either as shared segments or non-shared segments ... or just plan page images.

I had done a lot of work on location independent code images ... lots of past postings discussing the difficulty collected here
https://www.garlic.com/~lynn/submain.html#adcon

The standard vm370 system only handled memory mapped objects via named systems ... defined by the NAMESYS macro assembled in DMKSYS. With the appropriate privileges, the current range of pages (defined by NAMESYS) could be "saved". Then contents of a named system could be loaded by an extension to the IPL command.

Some of the work was described in Cambridge Science Center
https://www.garlic.com/~lynn/subtopic.html#545tech
Technical Report No. ZZ20-6002, July 1974, C.S.C VM/370 Extended II, Virtual Memory Management

... extract from the above
The scope of the modifications to VM/370 currently being implemented will support both the Named System interface and an PAM interface to a virtual machine. Recognizing that PAM support is dependent on extensive CMS filesystem changes, simple extensions to the Named System interface are being made to make some facilities immediately available.

The user interface will consist of two new commands (and/or diagnose instruction codes) to equate/connect and disconnect a virtual address space span to/from a 'Named System'. No change need be made in the method of defining named systems, although virtual device address and some other fields may be ignored. The starting virtual page address may be any legitimate address, inside or outside of a virtual machine address limit. Page address assignment is sequential as defined by the NamedSystem, proceeding from the initial starting page (which may be supplied either via the command or the named system definition as the default). Page assignment is terminated after assigning the last page in the definition, or on encountering a shared segment in the virtual memory, or after assigning the highest possible page address (end of virtual memory, 16M). For named systems which contain as part of their definition shared segment(s), the relative starting page number within a segment must be the same as the default in the Named System definition.

... snip ...

The CMS page mapped filesystem and the shared segment changes were eventually widely released internally on a VM370 release 2 PLC 15 base. One of the locations that made extensive use of the PAM support w2.15 system was HONE
https://www.garlic.com/~lynn/subtopic.html#hone

... the internal world-wide, vm370-based online system for all sales, marketing and field people.

For HONE, the issue had been that nearly all of the service was delivered as various kinds of APL applications (originally CMS/APL but then upgraded to APL/CMS ... and then VS/APL). In the pre-PAM scenario they had defined a "IPL" named system that included both CMS and APL (with several shared segments defined for APL in addition to the one CMS shared segment and misc. non-shared pages)

The issue (for HONE) was that APL was extremely compute intensive and some of the larger CPU hog applications had been redone in Fortran. The issue was how to invoke the FORTRAN application from the APL environment (called SEQUOIA) and then return to SEQUOIA automagically.

The PAM solution was to define the APL executable on a page mapped filesystem. Normal "CMS" could be IPL'ed (with the single shared segment) ...
well almost normal, still need paged mapped filesystem support

. The APL image was loaded from CMS page mapped filesystem (with all the appropriate shared segments defined and setup, I added some additional control information to a CMS executable specifying the segments to be shared). It was now possible to switch back and forth between APL environment (with shared segments) and Fortran applications, transparently to the end-user.

PAM offered a huge number of operational and performance advantages ... but the eventual decision was to only release the relative familiar "NAMESYS" CP kernel changes (minor subset of the full page mapped facility) as DCSS ... which (I) originally called DisContiguous Shared Segments ... since the standard product was only going to support definitions outside the standard virtual machine address space ... and the primary justificiation for providing the facility was to support definition of additional shared segment objects.

For VM370 release 3 "DCSS", because the CP kernel changes supporting page mapped filesystem were not picked up, the CMS changes for page mapped filesystem were also not picked up. However, a lot of the other CMS changes that I had done for putting various pieces of CMS into shared segments was picked up ... i.e. the CMS editor and misc. other stuff.

DCSS

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCSS
Newsgroups: bit.listserv.vmesa-l
CC: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
Date: Thu, 06 Jul 2006 11:34:18 -0600

misc. more about vm370 release 3 ... from Melinda's history
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist

from her history:
Also in February, 1976, Release 3 of VM/370 became available, including VMCF and support for 3350s and the new ECPS microcode. Edgar (the ''Display Editing System''), a program product full-screen editor written by Bob Carroll, also came out in 1976. Edgar was the first full-screen editor IBM made available to customers, although customers had previously written and distributed full-screen editors themselves, and Lynn Wheeler and Ed Hendricks had both written full-screen editors for 2250s under CMS-67.

... snip ...

it doesn't mention DCSS being part of release 3.

... but it does mention ECPS which I worked on in conjunction with Endicott. some old detail on studies deciding what to make part of ECPS
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode asssit

except, my quick & dirty recollection was that ECPS support wasn't shipped until Release 3 PLC4

and then, of course, my resource manager release was 11May76. misc. collected past posts on various aspects of some of the stuff that shipped in the resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

The same person responsible for VMCF had also redone how shared segments were protected ... which was also part of VM370 release 3. The issue was that the decision to ship the alternative shared segment protection was based on pre-release 3 CMS with only single shared segment with 16 shared pages.

part of the stuff that was included with the DCSS extreme subset of my virtual memory management
https://www.garlic.com/~lynn/2006m.html#53 DCSS

was additional CMS code for a second shared CMS segment (and 16 more shared pages). The release 3 change for shared segment/page protection drastically increased the overhead per shared page which was offset by enabling the use of VMA for CMS execution. However, the trade-off decision had been based on a single CMS shared segment (and only 16 shared pages). The new shared segment protection (and enabling VMA use for CMS virtual machines) shipped at the same time the additional shared segment facilities shipped (typically doubling the number of shared pages) ... invalidating the original trade-off analysis.

and repeat (from previous post) of collected posts on cms page mapped filesystem
https://www.garlic.com/~lynn/submain.html#mmap

and other collected posts about effort to make cms executable code location independent (as part of virtual memory management work)
https://www.garlic.com/~lynn/submain.html#adcon

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Fri, 07 Jul 2006 11:23:11 -0600

eugene@cse.ucsc.edu (Eugene Miya) writes:
Getting physicists to use computers is worse than pulling teeth. Tim Berners-Lee learned that. Computers and computer people are merely pawns to them.

Some physics problems even with computers are just hard. Where DEC excelled was in biology, neurology, real-time process control (we could have had a Data General future [one 80s DG ad was almost as good as the Apple 1984 ad in my view, except lost to some older generation managers]).

we had some success at slac ... we use to have monthly meetings there ... slac & cern are sister organizations ... and the first webserver in the US was at SLAC on a vm system
https://ahro.slac.stanford.edu/wwwslac-exhibit

and http traces its history back thru a copy of waterloo's cms script clone supporting sgml/gml (which was in heavy use at cern)
http://infomesh.net/html/history/early/

which had originally been invented at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

misc. gml, sgml, etc posts
https://www.garlic.com/~lynn/submain.html#sgml

Series/1 saw some large deployment in sensor markets. There is joke about the "standard" operating system for Series/1, RPS ... being a bunch of old os/360 "MFT" developers moving to boca and attempting to re-invent MFT on series/1.

Some physicists at san jose research ... attempting to use Series/1 for various physics applications ... eventually came up with "EDX" as a replacement for RPS (mid-70s?).

DCSS

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DCSS
Newsgroups: bit.listserv.vmesa-l
CC: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
Date: Fri, 07 Jul 2006 12:52:54 -0600

Jim Bohnsack wrote:
I had an XT/370 PC sometime in the mid-late 80's. It used PAM as it's native or default CMS file system if I remember correctly.
Jim

... re:
https://www.garlic.com/~lynn/2006m.html#53 DCSS
https://www.garlic.com/~lynn/2006m.html#54 DCSS

part of the issue was that even tho xt/370 hard disk was single user, it used the xt hard disk which had 110ms access with block at a time ... (plus the latency communicating back&forth between the 370 processor and cp/88 running on the pc processor). The combination of the significantly slower disk (vis-a-vis mainframe) and CMS being quite a bit more disk intensive (vis-a-vis applications developed for the PC environment) ... there was noticeable perception about poor performance.

PAM offers a much better matchup between filesystem operations and virtual memory paradigm ... resulting in significant efficiencies (most ibm mainframe operating systems inherited filesystems that had a significant real memory and real i/o paradigm orientation).
https://www.garlic.com/~lynn/submain.html#mmap

CMS filesystem operations had "diagnose I/O" for pathlength reduction but continued to retain channel program (a "real" memory) orientation. I had done the precursor to CMS "diagnose I/O" as an undergraduate ... demonstrating significant pathlength reduction for CMS I/O intensive operation (which was sort of continuation of a lot of cp67 kernel pathlength operations I was already doing).

The other place that PAM helped was minimizing real storage requirements for filesystem operations ... especially evident in environments with limited real storage configurations. Actually the CP kernel PAM infrastructure could dynamically adapt filesystem operations to the level of real storage contention and/or amount of real storage available. In one high-end (real mainframe) filesystem intensive benchmark, PAM demonstrated something like 300percent increased efficiency in filesystem operations (compared to highly optimized standard CMS EDF filesystem).

XT/370 was significantly real memory contrained for lots of cms operations. I had done various performance analysis on pre-announce XT/370 "washington" boxes and found significant page thrashing. When the information was distributed, I got blamed for delay in XT/370 announce and ship while they retrofitted the hardware with larger real storage.

However, XT/370, being a single user system, saw no benefit from the extensive segment/page sharing capability available via PAM (especially compared to the limited capability offered thru the namesys/dcss method).
https://www.garlic.com/~lynn/submain.html#adcon

previous, next, index - home