List of Archived Posts
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:
http://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
http://www.garlic.com/~lynn/2006h.html#56 The Pankian Metaphor
the following email extract about implementing SNA on a
unix platform ....
From: wheeler
Date: 05/06/85 16:52:04
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 kernal
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
http://www.garlic.com/~lynn/2002.html#18 Infiniband's impact was Re: Intel's 64-bit strategy
which then had earlier reference
http://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
http://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:
http://www.garlic.com/~lynn/subtopic.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
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.
http://www.garlic.com/~lynn/gcard.html
it has record size calculations ... but it predated 3390 ... so only has
up thru 3380
http://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)
http://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
http://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.
http://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
http://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:
http://www.garlic.com/~lynn/2006m.html#5 track capacity
i've done q&d conversion of the old gcard ios3270 to html.
http://www.garlic.com/~lynn/gcard.html
it has record size calculations ... but it predated 3390 ... so only has
up thru 3380
http://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
http://www.garlic.com/~lynn/2001h.html#65
earn and bitnet
http://www.garlic.com/~lynn/subnetwork.html#bitnet
used similar technology that was used in the internal
network
http://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:
http://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.
http://www.garlic.com/~lynn/subnetwork.html#bitnet
i've claimed that the nfsnet backbone was the operational precursor to
the modern internet.
http://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
http://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:
http://www.garlic.com/~lynn/2006m.html#9 An Out-of-the-Main Activity
http://www.garlic.com/~lynn/2006m.html#10 An Out-of-the-Main Activity
in the early 90s I got a .8m pagsat 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
http://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
http://www.garlic.com/~lynn/2006k.html#55
couple past posts menting the pagsat boardwatch magazine article
http://www.garlic.com/~lynn/2000.html#38 Vanishing Posts...
http://www.garlic.com/~lynn/2000e.html#39 I'll Be! Al Gore DID Invent the Internet After All ! NOT
http://www.garlic.com/~lynn/2001h.html#66 UUCP email
http://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:
http://www.garlic.com/~lynn/2006l.html#61 DEC's Hudson fab
http://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:
http://www.garlic.com/~lynn/2006m.html#5 Track capacity
http://www.garlic.com/~lynn/2006m.html#8 Track capacity
as previously mentioned from q&d conversion of gcard ios3270
http://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
http://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
http://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.
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transaction on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://www.garlic.com/~lynn/2001h.html#61
before coming up with x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://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.
http://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 strangle hold on
computer-to-computer data transmission with SNA ... and SNA had
extremely low tolerance for satellite delay transmission (as well as
scaleup 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
http://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
http://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
http://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
http://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 scaleup. recent post mentioning sbs-4 flying on 41-d
http://www.garlic.com/~lynn/2006m.html#11 Out-of-the-Main Activity
other recent posts making mention of SNA and the communication group
http://www.garlic.com/~lynn/2006e.html#15 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#12 Barbaras (mini-)rant
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
http://www.garlic.com/~lynn/2006h.html#56 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#0 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006l.html#50 Mainframe Linux Mythbusting (Was: Using Java in batch on
http://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006m.html#0 Mainframe Linux Mythbusting
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 strangle hold on
computer-to-computer data transmission with SNA ... and SNA had
extremely low tolerance for satellite delay transmission (as well as
scaleup in bandwidth that satellites frequently brought).
re:
http://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
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://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:
http://www.garlic.com/~lynn/subtopic.html#hone
misc. past postings mentioning internal backup/archive, workstation
datasave, adsm & tsm
http://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
http://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 occured "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.
misc. past rate-based pacing postings:
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technologyhttp://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#56 Moore law
http://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
http://www.garlic.com/~lynn/2002p.html#31 Western Union data communications?
http://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
http://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
http://www.garlic.com/~lynn/2005q.html#37 Callable Wait State
http://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
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
http://www.princeton.edu/~melinda
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.
http://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
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
http://en.wikipedia.org/wiki/Spear_phishing
http://www.eweek.com/article2/0,1895,1902896,00.asp
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":
http://www.garlic.com/~lynn/aadsm24.htm#5
http://www.garlic.com/~lynn/aadsm24.htm#6
http://www.garlic.com/~lynn/aadsm24.htm#7
http://www.garlic.com/~lynn/aadsm24.htm#8
http://www.garlic.com/~lynn/aadsm24.htm#9
http://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)
http://www.garlic.com/~lynn/subintegrity.html#harvest
and even more postings on generalized subject of fraud, vulnerabilities,
threats, and exploits
http://www.garlic.com/~lynn/subintegrity.html#fraud
... so a little mainframe tie-in from this related post
http://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
http://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 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
http://www.princeton.edu/~melinda
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
http://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
http://www.multicians.org/
there are even some cp67 stories by one of the people that worked on multics
http://www.multicians.org/thvv/360-67.html
and some ibm 7094/ctss stories
http://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 boston. some old posts giving part of
that presentation
http://www.garlic.com/~lynn/93.html#1 360/67, was Re: IBM's Project F/S
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://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
http://www.garlic.com/~lynn/subtopic.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)
http://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
http://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
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#5 Blade architectures
http://www.garlic.com/~lynn/2005f.html#37 Where should the type
information be: in tags and descriptors
http://www.garlic.com/~lynn/2005n.html#10 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
http://www.garlic.com/~lynn/2006k.html#31 PDP-1
http://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:
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
refers to posting
http://www.garlic.com/~lynn/2006m.html#21 The very first text editor
refers to abbreviated quote from Melinda's history paper at:
http://www.princeton.edu/~melinda
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
http://www.garlic.com/~lynn/subnetwork.html#internalnet
was joint development project between the science center
http://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 succesfully.
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.
a few old posts mentioning cp67-h and cp67-i work supporting 370 virtual
memory.
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
a few old posts mentioning the 165 schedule delays resulting in dropping
370 virtual memory features in order to catchup.
http://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing not 32 bit?
http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002m.html#2 Handling variable page sizes?
http://www.garlic.com/~lynn/2002m.html#68 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs
http://www.garlic.com/~lynn/2002n.html#23 Tweaking old computers?
http://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#62 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005e.html#59 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#1 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#5 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006i.html#4 Mainframe vs. xSeries
http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean?
http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#41 virtual memory
http://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers
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://bitsavers.trailing-edge.com/pdf/ibm/360/funcChar/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 comparision 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).
misc. past posts mentioning 4341s in one way or another
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#1 360/370
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#20 S/360 development burnout?
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#9 MIP rating on old S/370s
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#44 ibm icecube -- return of watercooling?
http://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#27 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#29 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#7 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#3 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
http://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#17 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#19 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#23 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#71 Tubes in IBM 1620?
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#0 big buys was: Tubes in IBM 1620?
http://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#35 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#61 Another light on the map going out
http://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix
http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
http://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#50 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
http://www.garlic.com/~lynn/2003i.html#9 IBM system 370
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003l.html#31 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003n.html#40 Cray to commercialize Red Storm
http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004.html#46 DE-skilling was Re: ServerPak Install via QuickLoad Product
http://www.garlic.com/~lynn/2004d.html#64 System/360 40 years old today
http://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
http://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
http://www.garlic.com/~lynn/2004f.html#29 [Meta] Marketplace argument
http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004j.html#25 Wars against bad things
http://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Re: Vintage computers are better
http://www.garlic.com/~lynn/2004k.html#33 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
http://www.garlic.com/~lynn/2004l.html#10 Complex Instructions
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
http://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004m.html#62 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004m.html#63 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#14 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#29 Is Fast Path headed nowhere?
http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#44 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#34 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2004p.html#48 History of C
http://www.garlic.com/~lynn/2004p.html#58 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#62 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2004q.html#71 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005.html#51 something like a CTC on a PC
http://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#63 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005d.html#30 The Mainframe and its future.. or furniture
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#30 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#36 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005h.html#11 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
http://www.garlic.com/~lynn/2005h.html#43 Systems Programming for 8 Year-olds
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005m.html#8 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#10 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#12 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#16 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#29 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
http://www.garlic.com/~lynn/2005o.html#16 ISA-independent programming language
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#2 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#35 Filemode 7-9?
http://www.garlic.com/~lynn/2005s.html#36 Filemode 7-9?
http://www.garlic.com/~lynn/2005s.html#39 Filemode 7-9?
http://www.garlic.com/~lynn/2005t.html#45 FULIST
http://www.garlic.com/~lynn/2005t.html#48 FULIST
http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#45 IBM's POWER6
http://www.garlic.com/~lynn/2005u.html#46 Channel Distances
http://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#49 Channel Distances
http://www.garlic.com/~lynn/2006.html#47 "VAX" Tradename reused !
http://www.garlic.com/~lynn/2006b.html#19 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#34 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006e.html#39 The Pankian Metaphor
http://www.garlic.com/~lynn/2006f.html#12 Barbaras (mini-)rant
http://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#23 virtual memory
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#31 PDP-1
http://www.garlic.com/~lynn/2006k.html#32 PDP-1
http://www.garlic.com/~lynn/2006l.html#2 virtual memory
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#17 virtual memory
http://www.garlic.com/~lynn/2006l.html#18 virtual memory
http://www.garlic.com/~lynn/2006l.html#19 virtual memory
http://www.garlic.com/~lynn/2006l.html#25 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006l.html#40 virtual memory
http://www.garlic.com/~lynn/2006l.html#44 The very first text editor
http://www.garlic.com/~lynn/2006l.html#48 virtual memory
http://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006l.html#55 virtual memory
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
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/
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
http://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 boston 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.
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2003c.html#51 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005h.html#6 Software for IBM 360/30 (was Re: DOS/360: Forty years)
http://www.garlic.com/~lynn/2005n.html#40 You might be a mainframer if... :-) V3.8
http://www.garlic.com/~lynn/2005o.html#12 30 Years and still counting
http://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloads
http://www.garlic.com/~lynn/2005t.html#18 Various kinds of System reloads
http://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
http://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 rewritting 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
http://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
http://www.garlic.com/~lynn/submain.html#adcon
misc. past posts mentioning tss/360, tss/370 and/or ssup (unix layered
on top of tss/370 for at&t)
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#1 pathlengths
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#48 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#6 mainframe question
http://www.garlic.com/~lynn/2001l.html#7 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#9 mainframe question
http://www.garlic.com/~lynn/2001l.html#11 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#18 mainframe question
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002d.html#23 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#36 Blade architectures
http://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
http://www.garlic.com/~lynn/2002f.html#42 Blade architectures
http://www.garlic.com/~lynn/2002f.html#53 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002j.html#27 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
http://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#57 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003d.html#58 POWER hashes vs tree
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#41 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#16 OSI not quite dead yet
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
http://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2004c.html#60 IBM 360 memory
http://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#9 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#20 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
http://www.garlic.com/~lynn/2004f.html#55 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#14 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#15 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#16 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004n.html#3 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#5 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#25 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#2 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#5 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#2 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#4 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#5 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#9 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#11 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#27 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#44 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005j.html#16 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005k.html#8 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005m.h