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 -0600ted.macneil writes:
at more basic implementation and protocol level ... sna tends to
require an enormous amount more code and much longer pathlength (as
well as significantly more buffer copies) ... as per earlier post:
https://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting
from a protocol aspect, sna has tended to be much more half-duplex oriented vis-a-vis tcp/ip ... which should simplify the management of possible states.
for some topic drift ... from a post earlier this year
https://www.garlic.com/~lynn/2006h.html#56 The Pankian Metaphor
the following email extract about implementing SNA on a
unix platform ....
Date: 05/06/85 16:52:04
From: wheeler
re: sna; interesting note in this month's sigops. Somebody at CMU
implemented LU6.2 under UNIX4.2 ...
Rosenberg reported on an implementation of an SNA node consisting
of LU 6.2 and PU T2.1 protocols. (These protocols cover approximately
OSI layers 2 through 6.) The implementation was made on UNIX
4.2. About 85% of the code was generated automatically from the FAPL
meta-description of SNA. The following problems were reported:
...
1. The protocol code is large, and thus cannot run in the kernel
space. Consequently, communication between user program and the node
(processor executing the SNA code) is more complex and slower than if
the node were part of the kernel. In addition, error recovery proved
tricky.
2. The SNA node must simulate the UNIX sockets, which are full duplex
and place no restriction on the states of the two conversants. The SNA
node uses a half-duplex, flip-flop protocol, where the states of the
two conversants must remain synchronized. To match the two required an
extension to SNA.
The implementation is now complete and is actually used to drive a
3820 printer, which is a SNA device
... snip ... top of post, old email index
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 -0600ArarghMail606NOSPAM writes:
which then had earlier reference
https://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
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 -0600kaplow_r@encompasserve.org.mars (Bob Kaplow) writes:
the 2702 had "SAD" command that you specified for each line ... which associated a specific line-scanner with a specific line/port.
original cp67 delivered to the university had 2741 (type-1 line-scanner) and 1052 (type-III line scanner) terminal support. It had some magic code that would do a sequence of operations with different line-scanner combinations in order to dynamically determine the terminal type.
with the addition of type-II line-scanner and TTYs ... I had to add TTY support to cp67. I tried to emulate the same magic code as had been done for 2741 & 1052. It work ok with fixed line terminals ... however, I wanted to also do it for dialed terminals. The support seemed to almost work ... i.e. use the same (common phone number) dialed port/line for all terminals. the gotcha was that the line speed oscillator was hard wired to each line ... while it was possible to dynamically change the line-scanner on a port/line basis ... it wasn't actually possible to dynamically change the line/port baud rate (defeating the ability to actually use a common phone number for all terminal types).
this was sort of the motivation for the university to start a project to build our own telecommunication controller. somebody wrote an article blaming four of use for spawning the plug-compatible (clone) controller business.
project involved reverse engineering the mainframe channel interface and building a channel interface card for an interdata/3 ... and progrmaming the interdata/3 to emulate the mainframe telecommunication controller. one of the features added/programmed for the interdata/3 was to dynamically determine port/line/terminal baud rate.
misc. other posts mentioning clone controller:
https://www.garlic.com/~lynn/submain.html#360pcm
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 -0600eugene@cse.ucsc.edu (Eugene Miya) writes:
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 -0600and 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 ...
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 -0600Charles Mills wrote:
it has record size calculations ... but it predated 3390 ... so only has
up thru 3380
https://www.garlic.com/~lynn/gcard.html#26.3
from above
Track Record Size Device Capacity Without key With key 3375 36000 224+#(D+191) 224+#(K+191)+#(D+191) 3380 47968 480+#(D+12) 704+#(K+12)+#(D+12) Device Capacity Without key With key Notes: D is data length, K is key length # means round up to multiple of 32from somewhere else 3390 track capacity is listed as 56,664
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 -0600Tom Schmidt wrote:
normally RFC summaries load in the lower frame.
clicking on the ".txt=nnn" field in the summaries retrieves the actual RFC.
RFC 896
https://www.garlic.com/~lynn/rfcidx2.htm#896
896
Congestion control in IP/TCP internetworks, Nagle J., 1984/01/06
(9pp) (.txt=26782) (Ref'ed By 985, 1016, 1072, 1122, 1254, 1323, 1812,
2126, 2309, 2525, 2556, 2914, 3539, 3714, 4138, 4172, 4413)
however, see several implementation discussions in 1122 related to Nagle.
https://www.garlic.com/~lynn/rfcidx3.htm#1122
1122 S
Requirements for Internet hosts - communication layers, Braden R.,
1989/10/01 (116pp) (.txt=289148) (STD-3) (Updated by 4379) (See Also
1123) (Refs 768, 791, 792, 793, 813, 814, 815, 816, 817, 826, 879, 893,
894, 896, 922, 950, 963, 964, 980, 994, 995, 1009, 1010, 1011, 1016,
1042, 1071, 1072, 1108, 1112) (Ref'ed By 1127, 1180, 1190, 1191, 1207,
1219, 1254, 1256, 1329, 1349, 1370, 1379, 1385, 1403, 1433, 1455, 1517,
1531, 1533, 1541, 1561, 1577, 1620, 1626, 1644, 1716, 1745, 1755, 1770,
1812, 1819, 1885, 1933, 1937, 1970, 2001, 2131, 2132, 2176, 2225, 2309,
2331, 2353, 2360, 2391, 2414, 2461, 2463, 2474, 2481, 2488, 2498, 2521,
2525, 2581, 2663, 2678, 2694, 2757, 2760, 2784, 2822, 2834, 2835, 2893,
2914, 2923, 2988, 3021, 3022, 3081, 3135, 3154, 3155, 3168, 3175, 3259,
3260, 3360, 3366, 3390, 3435, 3449, 3465, 3481, 3490, 3522, 3684, 3720,
3821, 3884, 3948, 4035, 4172, 4302, 4367, 4379, 4391, 4413, 4443, 4459,
4460)
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 -0600lawrence writes:
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.
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 -0600James F Smith wrote:
if you look at the calculation, a keyless record required adding 12 bytes and rounded up to multiple of 32bytes and then adding 480 to calculate how much of raw track capacity a (keyless) formated record took.
so single formated record 47476 and adding 12 = 47488 by chance is multiple of 32
and 47488+480 = 47968
47968 is the raw, unformated track capacity.
each formated record has overhead, as per the calculation.
re:
https://www.garlic.com/~lynn/2006m.html#5 track capacity
i've done q&d conversion of the old gcard ios3270 to html.
https://www.garlic.com/~lynn/gcard.html
it has record size calculations ... but it predated 3390 ... so only has
up thru 3380
https://www.garlic.com/~lynn/gcard.html#26.3
from above
Track Record Size Device Capacity Without key With key 3375 36000 224+#(D+191) 224+#(K+191)+#(D+191) 3380 47968 480+#(D+12) 704+#(K+12)+#(D+12) Device Capacity Without key With key Notes: D is data length, K is key length # means round up to multiple of 32
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 -0600Michael Widerkrantz writes:
old email from person setting up EARN
https://www.garlic.com/~lynn/2001h.html#65
earn and bitnet
https://www.garlic.com/~lynn/subnetwork.html#bitnet
used similar technology that was used in the internal
network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
i believe for a time in the early 80s towards the mid-80s, not only did the internal network have more nodes than the arpanet/internet ... but bitnet also had more nodes than the arpanet/internet.
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 -0600re:
when the corporation formed acis in the early 80s, it started out with $300m that it was suppose to pump into educational institutions.
project athena (at mit) got $25m (which dec matched). cmu got $50m that went into various of the "andrew" things as well as mach, camelot, etc.
a lot was also pumped into paying for the bitnet (and earn) network
infrastructure and operations.
https://www.garlic.com/~lynn/subnetwork.html#bitnet
i've claimed that the nfsnet backbone was the operational precursor to
the modern internet.
https://www.garlic.com/~lynn/subnetwork.html#internet
the nsfnet backbone rfp award was for something like $11.2m
... however rumor and folklore make claims that the actual resources
pumped into the nsfnet backbone (by corporations) was 4-5 times what
was actually paid for by NSF. reference to the original nsfnet RFP
and mention of the RFP being awarded
https://www.garlic.com/~lynn/internet.htm#nsfnet
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 -0600Michael Widerkrantz writes:
in the early 90s I got a .8m pagesat r/o dish ... it had a full usenet feed. they let me keep it, in part for doing a unix driver for their modem and co-authoring an article for boardwatch magazine (it had a picture of me in the backyard with my dish). i had "waffle" (bbs program) running on a windows machine tied to a unix machine handling the usenet feed. not too long later they upgraded with 18in dish (with .75m option) and doubled the bandwidth.
this was different than the 4.5meter dishes that I got to
play with at work as part of hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
at one location we had to go to a 7meter dish (signal quality issues). we even got to attend the bird launch ... it was interesting event; some number of people were in the stands ... several places over sat one of the people that had walked on the moon.
recent posting mentioning bird flying on 41-d
https://www.garlic.com/~lynn/2006k.html#55
couple past posts menting the pagesat boardwatch magazine article
https://www.garlic.com/~lynn/2000.html#38 Vanishing Posts...
https://www.garlic.com/~lynn/2000e.html#39 I'll Be! Al Gore DID Invent the Internet After All ! NOT
https://www.garlic.com/~lynn/2001h.html#66 UUCP email
https://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration
... for a little drift ... on old post (by somebody else) about the
system:
Newsgroups: comp.bbs.waffle,alt.bbs,rec.video.satellite,biz.pagesat,comp.bbs.misc
Subject: Receiving News via Satellite -- The PageSat System
Date: Mon, 28 Jun 93 19:20:35 GMT
Several weeks ago, I mentioned having ordered the PageSat system for
receiving news via satellite downlink. There was some interest expressed
and I indicated at that time that I would be glad to post a summary
of my experiences/impressions when it arrived. Well, this is it.
I installed the system two weeks ago. We had the antenna braced in a
wooden backyard chair for a couple of days until we set up a permanent
mounting. Norman Gillaspie, President of PageSat, recommended that I
get the .75m dish rather than the smaller 18-incher commonly used in
the more southern climes (I live in Maine). Although a little bigger
than unobtrusive, the dish ended up in a convenient, out-of-the-way
corner of the back yard on about 4 feet of 2.25in aluminum EMT (with an
additional 3 feet extending underground into 2 bags of concrete). The
hardware performs well and seems quite reliable. And the blisters on
my hands from the post-hole digger have finally healed.
I am grateful for the advice to install the larger antenna. I doubt
the 18-inch dish would have had the ability to pick up a sufficiently
strong signal through dense clouds this far North. Although we lost
signal briefly during a heavy thunderstorm a week ago, it did return
even while the clouds were thick and the downpour continued. I'm
guessing that we will lose signal only when the thickest of storm
clouds sweep between us and the satellite.
My setup requires the DOS version of the software which is new and
running fairly well now. There were some problems with the software
early on (extra characters were occasionally inserted -- which
corrupted the binaries and the pix). The folks at PageSat were very
responsive, however, and the problems were solved rather quickly. By
the way, I have written a small utility which looks for completed news
files, as received via PageSat, and invokes Waffle's (or other) RNEWS
on each. When sitting idle, this utility gives back CPU cycles to
DESQview. It's FREE, so if you need it, you need only ask via e-mail.
Assembly of the PageSat system went very smoothly. The written docs
were excellent. I was fully expecting the instructions to be in
Japanese, as mentioned in the review of the PageSat system appearing
in the June, 1993 issue of Boardwatch Magazine. But that trial
happily was not visited upon me. Except for a few hours trying to
find the K2 satellite (the compass headings given were slightly off --
and I only had a narrow slot between two large trees to "shoot
through"), I'd say the installation went off without a hitch.
If you need a sizeable news feed, but must cope with long distance
costs to get it, I heartily recommend the PageSat system. My long
distance costs for obtaining a medium-sized newsfeed for callers to
the Northern Lights were running more than $200 per month. I figure
the PageSat system will pay for itself in less than 9 months.
Now I'm looking to add a 1-2 gig SCSI drive so there will be space to
keep more of the full news feed that's "tumbling out of the sky". I
suppose I am not REALLY going to SAVE money after having purchased the
PageSat system. But I WILL have more fun spending it. :)
... snip ...
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 -0600kkt wrote:
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.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Track capacity? Newsgroups: bit.listserv.ibm-main Date: Sat, 17 Jun 2006 21:59:57 -0600DASDBill2 writes:
record size with no. on 47968 nominal key actual track bytes byte track 1 768 62 .. 768 62 20 768 62 21 800 59 .. 800 59 52 800 59 53 832 57 .. 832 57 84 832 57 85 864 55 .. 864 55 116 864 55 117 896 53 .. 896 53 148 896 53---------------------------------------------------
ref:
https://www.garlic.com/~lynn/2006m.html#5 Track capacity
https://www.garlic.com/~lynn/2006m.html#8 Track capacity
as previously mentioned from q&d conversion of gcard ios3270
https://www.garlic.com/~lynn/gcard.html#26.3
Track Record Size Device Capacity Without key With key 3375 36000 224+#(D+191) 224+#(K+191)+#(D+191) 3380 47968 480+#(D+12) 704+#(K+12)+#(D+12) Device Capacity Without key With key Notes: D is data length, K is key length # means round up to multiple of 32
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 -0600jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: OpenSSL Hacks Newsgroups: sci.crypt Date: Sun, 18 Jun 2006 08:43:48 -0600pgut001@cs.auckland.ac.nz (Peter Gutmann) writes:
and a more recent posting about trade-off between end-to-end business
(financial) process involving "naked" transactions which then implies
heavily armoring all aspects of the end-to-end business operation
... vis-a-vis armoring the transactions which may significantly
mitigate the armoring requirements of the end-to-end business process.
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transaction on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV
we had been brought in to consult with this small client/server
startup that had this technology called SSL and they wanted to do
payment transactions on their server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
which has since come to be called electronic commerce
we then got involved in the financial standards x9a10 working group
which had been given the requirement to preserve the integrity of
the financial infrastructure for all retail payments (ALL, not
just point-of-sale, not just internet, not just credit, ... ALL). as
part of that we looked at the huge number of vulnerability points in
the infrastructure .... somewhat related post on security
proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
before coming up with x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
part of the issue was that an unarmored, naked transaction was vulnerable at huge number of different places in the infrastructure. the SSL session encryption for transaction transit thru parts of the internet provided countermeasure for only a small amount of the vulnerabilities.
the assertion was that a x9.59 transaction could even be transmitted
thru the internet w/o SSL or other session protection mechanism and
the crooks could not use evesdropping or other techniques that would
then lead to performing fraudulent transactions (replay
attacks) ... aka SSL is currently used for transaction hiding
because current transaction infrastructure is vulnerable to
evesdropping and replay attacks. x9.59 standard eliminated the
evesdropping, replay, skimming, and harvesting vulnerabilities.
https://www.garlic.com/~lynn/subintegrity.html#harvest
SSL might still be used for privacy/confidentiality ... but it would no longer be required as countermeasure to (financial fraud) replay attacks.
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 -0600krw wrote:
Because of the heavy influence that the communication group had blocking anything but straight sna for computer-to-computer transmission ... SBS was effectively forced into migrating to other markets ... and eventually got into voice transmission. They were in the public long-distance market (as well as heavily installed internally within the corporation).
major plant sites had these big 10meter dishes that were c-band running
T3 (44mbits/sec) transmission. because of corporate security standards
the data aggregator (or data aggravator), full bandwidth T3 encryptor as
developed and deployed. voice channels were then suballocated out of the
T3 channel. couple posts mentioning data aggravator
https://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006k.html#55 5963 (computer grade dual triode) production dates?
early in the deployment there is this story where they tried to do
double-hop 56kbit circuit between STL and Hursley (STL to satellite,
down to the east coast, up to atlantic satellite and down to the UK).
They put up standard VNET on both ends and everything flowed
fine. They then switched to a JES2/SNA at both ends and no traffic
flowed at all. The person in charge was severely SNA indoctrinated
... and explained that obviously that there must be significant
transmission errors which the advanced SNA error detection was able to
recognize ... and that the primitive VNET handling just wasn't
detecting. Geosync satellite are about 22000 miles, double hop round
trip then is 8*22000 ... 176,000 miles with signal traveling at
186,000mps ... plus a little processing delay at the remote site works
out to about one second elapsed time. recent post mentioning JES2
networking
https://www.garlic.com/~lynn/2006l.html#46 Mainframe Linux Mythbusting
Eventually SBS was dissolved, the phone/long-distance stuff sold off to MCI and the birds sold off to Hughes.
part of my hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
involved custom designed tdma earth stations using transponder on SBS-4
(Ku band) for doing (non-sna) computer-to-computer transmissions. Part
of this involved gracefully doing compensation for satellite propagation
delay and bandwidth scale-up. recent post mentioning sbs-4 flying on 41-d
https://www.garlic.com/~lynn/2006m.html#11 Out-of-the-Main Activity
other recent posts making mention of SNA and the communication group
https://www.garlic.com/~lynn/2006e.html#15 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
https://www.garlic.com/~lynn/2006f.html#12 Barbaras (mini-)rant
https://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
https://www.garlic.com/~lynn/2006h.html#56 The Pankian Metaphor
https://www.garlic.com/~lynn/2006j.html#0 virtual memory
https://www.garlic.com/~lynn/2006j.html#31 virtual memory
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#10 Arpa address
https://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006l.html#50 Mainframe Linux Mythbusting (Was: Using Java in batch on
https://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006m.html#0 Mainframe Linux Mythbusting
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 -0600Anne & Lynn Wheeler writes:
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).
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:
a subset of the rules could be applied to picking the one and only one, absolutely perfect 4 digit pin
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 -0600Mark Zelden wrote:
workstation datasave was reworked internal backup/archive system (with a number of clients added for non-MF platforms) that I had originally written and deployed at some number of locations in the bay area; research, engineering labs, hone, etc. ...
misc. past postings mentioning the HONE system (not just in the bay
area) providing world-wide support for field, marketing and sales:
https://www.garlic.com/~lynn/subtopic.html#hone
misc. past postings mentioning internal backup/archive, workstation
datasave, adsm & tsm
https://www.garlic.com/~lynn/submain.html#backup
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 -0600Brian Inglis writes:
one of the things that I soon realized that a lot of the protocols were in need of rate-based pacing NOT windowing. windowing had originally been a link-layer thing to provide a little bit of asynchronous overlap but avoid overring the receiving links buffer allocation. however, it soon got contorted into addressing all sorts of asynchronous behavior associated with other forms of congestion ... frequently totally unrelated to the number of pre-allocated buffers at the receiving link.
having done a whole lot with resource management and scheduling as an undergraduate ... and prone to translating things into rates ... it seemed trivially obvious that rate-based pacing was a requirement and that windowing was a very contorting and ill-suited construct for the tast.
the issue can come up in almost any environment with a "large" bandwidth*delay product (where "large" can be quite relative). I encountered it with satellites in the early 80s when the bandwidth was frequently 20-30 times that of a lot of terrestrial links ... and the delay was significantly larger. however, it cropped also in very high bandwidth fiber terrestrial connections as well as multi-hop networks.
some number of papers in the late 80s demonstrated that windowing was particularly ill-suited to large multi-hop networks. the actual objective is to be able to transmit packets w/o having to wait for full round-trip delay ... but possibly not transmit them continuously that they overwhelm the intermediate and end nodes. windows sort of have an assumption that there is a uniform distribution between transmissions. However, there is actually nothing in basic windowing operations that create intervals between transmissions ... other than once you have fully transmitted up to the max. window size, you then have to wait until ACKs come back.
The actual problem is rate of transmission arrivals ... or another way of thinking about it is multiple back-to-back transmission arrivals. There are slow-start strategies that attempt to address spreading out the back-to-back transmissions. The problem is that windowing is a mismatched paradigm for the actual problem. For one thing, they found in large multi-hop networks ... there was frequently bursty traffic, asynchronous traffic flows, ACK batching, and ACK piggybacking. All of these tending to create long delays between the transmitting after the time that the last transmission occurred "filling" the window ... and the arrival of ACKs that started to empty the window full condition. However, lots of things contributed to emptying a large number of windows in a burst ... which allows a large number of back-to-back transmissions to occur in a burst ... which then saturates intermediate and/or end nodes.
One way of doing rate-based pacing is to adjust the interval between transmissions. You are no longer directly concerned with the number of outstanding packets and/or the actual total end-to-end round-trip delay. The transmissions completely fill the path ... regardless of the round-trip delay and/or the bandwidth*delay product ... to the limit that the transmissions can be handled by intermediate and/or end nodes. In rate-based pacing there is no direct issue with the size of the channel or delay ... purely with how fast that the receivers can process the transmission.
At one point, I realized that a large number of platforms weren't using window strategy ... as a really poor substitute for rate-based pacing ... not because it was thot to be a better approach ... but because many of the platforms had such dismall timer facilities where it was impossible to implement any reasonable resource pacing strategy.
misc. past rate-based pacing postings:
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002k.html#56 Moore law
https://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
https://www.garlic.com/~lynn/2002p.html#31 Western Union data communications?
https://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
https://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
https://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
https://www.garlic.com/~lynn/2003j.html#46 Fast TCP
https://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
https://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
https://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004q.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
https://www.garlic.com/~lynn/2005q.html#37 Callable Wait State
https://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
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 -0600Elliott Roper writes:
Melinda's paper at
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist
footnote in above:
108 For example, see S. Wecker, ''OS/360 as a Preferred Machine Under
CP-67'', Proceedings of SHARE XXXVII, August, 1971, pp. 48-57.
... snip ...
and totally unrelated to Wecker, even more drift from Melinda's paper:
By the end of 1976, sixteen percent of the former Burlington
personnel were working for DEC
... snip ...
Cambridge Science Center had spawned CP67 on 4th flr, 545 tech sq.
https://www.garlic.com/~lynn/subtopic.html#545tech
tbe CP67 group was split off from the science center and as it expanded, moved to the 3rd flr, absorbing what had been the Boston Programming Center (among other people at the Boston Programming Center on the 3rd flr was Jean Sammet). The group continued to grew quickly with the morphing of cp67 into vm370 and eventual moved out to Burlington Mall into what had been the old Service Bureau Corporation bldg (which had been spun off to CDC as part of some litigation).
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 -0600howard.brazee@cusys.edu wrote:
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 -0600GreyCloud writes:
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 -0600Elardus Engelbrecht wrote:
lots of past posts related to general account number harvesting
(skimming, phishing, etc for replay attacks and fraudulent transactions)
https://www.garlic.com/~lynn/subintegrity.html#harvest
and even more postings on generalized subject of fraud, vulnerabilities,
threats, and exploits
https://www.garlic.com/~lynn/subintegrity.html#fraud
... so a little mainframe tie-in from this related post
https://www.garlic.com/~lynn/aadsm24.htm#8
at one point the head of the mainframe division ... got moved over to be
the head of the ibm/pc group during the OS2, PS2, & microchannel days.
later he left and had a couple of other jobs. at one point he was doing a
stint as ceo of company that specialized in kerberos
https://www.garlic.com/~lynn/subpubkey.html#kerberos
and got a contract to do the initial kerberos implementation for windows ... which is now the basic authentication infrastructure for their platforms.
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 -0600Hunkeler Peter , KIUB 34 wrote:
but when multics (5th flr, 545 tech sq) didn't choose 360/67, but
instead GE machine ... the science center; 4th flr, 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech
started their own virtual memory project (which happened to also included virtual machines) for 360/67. some of the (mit) ctss people went to work on the 5th flr ... and some went to work on the 4th flr (so both activities have some common heritage w/ctss).
since 360/67 hardware was not going to be immediately available, the science center had a 360/40 modified with virtual memory hardware and produced cp40 in 1966. when 360/67 became available in 1967, they ported cp40 from custom modified 360/40 to 360/67 and renamed it cp/67.
cp67 was somewhat ahead of multics ... possibly because the implementation was not as large or as complex.
multics web page
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 Atlantic City. some old posts giving part of
that presentation
https://www.garlic.com/~lynn/93.html#1 360/67, was Re: IBM's Project F/S
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
Another item that I got to do for cp67 was adding TTY/ascii terminal
support (which plays in one of the cp67 stories from the multics site).
As part of that work, I tried to make the 2702 terminal controller do
something that it could actually do. Somewhat as a result, the univ.
started a project to build our own terminal controller; reverse engineer
ibm channel interface and build our own channel board for Interdata/3
... programmed to emulate 2702 (with some additional stuff the 2702
couldn't do). somewhere there was an article blaming four of us for
spawning the plug compatible controller business
https://www.garlic.com/~lynn/submain.html#360pcm
later in POK ... getting ready for virtual memory announcement for 370, there was an effort to basically integrate virtual memory (some of the components from cp67) into mvt for os/vs2 SVS (instead of running mvt in virtual machine ... ccwtrans and some other stuff from cp67 was hacked into the side of a mvt kernel). basically mvt kernel where most of the infrastructure thot it was running in a real 16mbyte address space ... but was using virtual memory hardware to map the (single) 16mbyte address space to the real machine memory.
then SVS (single virtual storage) was enhanced with multiple virtual address space support and morped into os/vs2 mvs (multiple virtual storage) which eventually was shortened to just mvs.
in the mid-70s, as part of getting ready for 370/xa that would come out in the early 80s with 3081 ... work on mvs/xa was begun. up in cambridge. the vm370 development group had grown out of the space in 545 tech sq and had moved out to the old service bureau corp. building in burlington mall. POK convinced the corporation to shutdown burlington mall location, kill vm370 product, and that all the vm370 development people had to be moved to POK to support mvs/xa development (in order to meet the mvs/xa product schedule).
some people didn't want to move ... and instead stayed in boston area,
many going to work for DEC (on things like vms). recent post referencing
16percent of vm370 group going to work for DEC (extracted from melinda's
paper)
https://www.garlic.com/~lynn/2006m.html#21
endicott managed to stave off vm370 product actually being killed and got a few of the original development people moved to endicott ... there is more detail in melinda's paper (however, large number of people did move to POK as part of supporting mvs/xa development).
in some of the threads about the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
being larger than the arpanet/internet from just about the beginning until possibly mid-85 ... i also slightly dig multics.
in the mid-70s, the number of vs2 and vs1 customer "batch" installations were larger than the number of customer vm370 installations. the number of customer vm370 installations was larger than the number of internal, corporate vm370 installations (although in places like the internal network ... the number of vm370 internal installations far outnumbered any other operating system internal installations, mvs, jes2, jes3).
for a short period, while i was at the science center ... i also personally built, distributed and supported highly modified vm370 for small number of internal locations. however, that number was more than the total number of all multics systems ever deployed.
also some past postings about the number of vax systems sold (by year,
us/non-us, model, etc) ... and that the number of vm 4331/4341 systems
were larger than the total number of vax systems
https://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#5 Blade architectures
https://www.garlic.com/~lynn/2005f.html#37 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005n.html#10 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
https://www.garlic.com/~lynn/2006k.html#31 PDP-1
https://www.garlic.com/~lynn/2006l.html#17 virtual memory
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 -0600Shmuel Metz , Seymour J. wrote:
refers to posting
https://www.garlic.com/~lynn/2006m.html#21 The very first text editor
refers to abbreviated quote from Melinda's history paper at:
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist
the following is a little more detail from that referenced extract
(regarding 16 percent went to work for DEC):
Boston and its suburbs provided other opportunities that didn't require
the VM developers to move away from the bright lights and disrupt the
lives of their families. By the end of 1976, sixteen percent of the
former Burlington personnel were working for DEC. Forty-seven percent
had found IBM positions that didn't require them to move to
Poughkeepsie. To make matters worse, several of the most knowledgeable
CP people who did go to Poughkeepsie, including Dick Newson and Per
Jonas, were put into a separate group whose purpose was to build a tool
that could be used for the development of MVS/XA. Pete Tallman, of
VMA fame, also joined what came to be known as the ''VM Tool'' project
as soon as it moved to Poughkeepsie. Starting with VM/370 Release 3,
PLC 06, the VM Tool group began building a fast, stripped-down CP that
would create XA virtual machines on a real 370 so that the MVS
developers could test MVS/XA.
... snip ...
something similar happened with os/360 operating system virtual memory development ... the earlier os2/vs2 svs prototype work with MVT incorporating some of the cp67 virtual address space support was done on 360/67 ... and then moved to "virtual 370s" and much later "real 370s".
370 was originally announced w/o virtual memory support and 360 operating systems ran with very little changes.
however, one of the early uses of the internal network technology
https://www.garlic.com/~lynn/subnetwork.html#internalnet
was joint development project between the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
and endicott to modify cp67 (running on 360/67) to provide 370 virtual machines (including support for 370 virtual memory architecture that had hardware tables different than what was defined for 360/67).
the initial set of updates were the "cp67-h" changes to a standard cp67 kernel that added 370 virtual machine option (to existing 360 & 360/67 virtual machine options). then there were a set of "cp67-i" changes (on top of the "cp67-h" changes) that change the kernel to run on 370 hardware.
now because 370 virtual memory support hadn't been announced, it was being treated as super corporate secret. complicated the matters was that the science center cp67 system was also providing service to various non-employee students (and others) at various educational institutions in the boston area. so typical operation was
360/67 hardware standard "cp67-l" system running on 360/67 hardware providing 360 VMs "cp67-h" running in 360 virtual machine providing 360 & 370 VMs "cp67-i" running in 370 virtual machine providing 370 VMs CMS running in 370 virtual machineas a countermeasure to accidental leakage about 370 virtual memory to the public.
cp67-h & cp67-i were in regular use a year before the very first engineering 370 with hardware virtual memory was reading for testing (a engineering 370/145 in endicott). in fact, booting cp67-i on the engineering 370/145 was one of the first tests of the virtual memory hardware support. as it turned out, the first boot failed. a little more examination showed that the hardware had reversed the op-codes in a couple of the new B2xx instructions ... while cp67-i had it correct. the cp67-i kernel was patched to correspond to the (wrong) hardware implementation and then booted successfully.
there was a different problem leading up to 370 virtual memory announcement. pok engineers had to design virtual memory hardware retro-fit for 370/155 and 370/165 machines. they were falling something like six months behind. finally there was an escalation meeting in POK, where the 165 engineers said that if they could eliminate some of the new features defined for 370 virtual memory they could pickup six months ... and allow 370 virtual memory to be announced six months earlier. there was a decision to drop the additional features ... and other models that had already done their implementations had to drop the features.
one of the features dropped was shared segment protection (different than the 360 storage key protection). cms had been reworked to take advantage of the feature (i.e. different virtual address spaces could share the same physical pages in real memory and enforce storage alteration protection). as a result, cms had to revert to a real gludge using 360 storage key protect for different virtual address spaces sharing the same physical pages.
a few old posts mentioning cp67-h and cp67-i work supporting 370 virtual
memory.
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
https://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://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.
https://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing not 32 bit?
https://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
https://www.garlic.com/~lynn/2002m.html#2 Handling variable page sizes?
https://www.garlic.com/~lynn/2002m.html#68 Tweaking old computers?
https://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs
https://www.garlic.com/~lynn/2002n.html#23 Tweaking old computers?
https://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
https://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??
https://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
https://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#62 The mid-seventies SHARE survey
https://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005e.html#59 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#1 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2006.html#13 VM maclib reference
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#5 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006i.html#4 Mainframe vs. xSeries
https://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean?
https://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370
https://www.garlic.com/~lynn/2006j.html#5 virtual memory
https://www.garlic.com/~lynn/2006j.html#41 virtual memory
https://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers
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 -0600Shmuel Metz , Seymour J. wrote:
360/67 smp support also had channel director ... where all processors could address all channels.
it wasn't until 3081 that you saw greater than 24-bit virtual addressing and provision for all processors in smp configuration to address all channels.
360/67 functional characteristics:
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A27-2719-0_360-67_funcChar.pdf
before 3081, there was a real storage scenario with 3033 being approx. 4.5mips and limited to 16mbyte real storage (and 16 channels). having 3033smp (two 4.5mip processors) still limited the configuration to 16mbyte real storage. in comparison you could setup a cluster of six 4341s, approx. 1mip (six mips aggregate), each 16mbytes real storage (96mbytes aggregate), and each six channels (36 channels aggregate) for about the same money as a single 3033 processor configuration. the 16mbyte real limitation was starting represent a real system bottleneck for mvs systems
so 3033 came up with a hack for supporting 32mbyte real storage. the 370 page table entry was 16bits with a 12bit page number field (for specifying a real 4k page ... 12+12 gives 24bit addressing or 16mbytes), two defined bits, and two undefined bits. the gimmick scavenged one of the undefined PTE bits to be used in real page numbers. you could now address 2**13 4k real pages ... or 32mbytes. CCW IDAL was 31bits ... show you had bits to read/write pages into/out-of >16mbytes. the problem was that all instructions were still limited to 24bit addressing (both real and virtual). you could stick virtual pages above the 16mbyte line ... but there was periodic requirement that some kernel code running in "real mode" had to address virtual page contents about the 16mbyte line. So there was this gimmick with a dummy virtual address space ... that you stuffed an real page number below the 16mbyte line and the desired real page number above the 16mbyte line, entered virtual address space mode and copied the virtual page above the line to the virtual page location (that was below the 16mbyte real line).
misc. past posts mentioning 4341s in one way or another
https://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
https://www.garlic.com/~lynn/96.html#1 360/370
https://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#7 IBM S/360
https://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
https://www.garlic.com/~lynn/2000.html#90 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
https://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#20 S/360 development burnout?
https://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#9 MIP rating on old S/370s
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001l.html#32 mainframe question
https://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2002.html#11 The demise of compaq
https://www.garlic.com/~lynn/2002b.html#0 Microcode?
https://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
https://www.garlic.com/~lynn/2002g.html#44 ibm icecube -- return of watercooling?
https://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
https://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#27 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#29 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
https://www.garlic.com/~lynn/2002j.html#7 HONE, ****, misc
https://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
https://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750)
https://www.garlic.com/~lynn/2002k.html#3 misc. old benchmarks (4331 & 11/750)
https://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
https://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
https://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
https://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2002p.html#48 Linux paging
https://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
https://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?
https://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003c.html#17 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#19 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#23 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#71 Tubes in IBM 1620?
https://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003d.html#0 big buys was: Tubes in IBM 1620?
https://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
https://www.garlic.com/~lynn/2003d.html#35 Why only 24 bits on S/360?
https://www.garlic.com/~lynn/2003d.html#61 Another light on the map going out
https://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix
https://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
https://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
https://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#50 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
https://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
https://www.garlic.com/~lynn/2003i.html#9 IBM system 370
https://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
https://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003l.html#31 IBM Manuals from the 1940's and 1950's
https://www.garlic.com/~lynn/2003n.html#40 Cray to commercialize Red Storm
https://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
https://www.garlic.com/~lynn/2004.html#46 DE-skilling was Re: ServerPak Install via QuickLoad Product
https://www.garlic.com/~lynn/2004d.html#64 System/360 40 years old today
https://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
https://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
https://www.garlic.com/~lynn/2004f.html#29 [Meta] Marketplace argument
https://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
https://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
https://www.garlic.com/~lynn/2004j.html#25 Wars against bad things
https://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Re: Vintage computers are better
https://www.garlic.com/~lynn/2004k.html#33 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
https://www.garlic.com/~lynn/2004l.html#10 Complex Instructions
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
https://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004m.html#62 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004m.html#63 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#14 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#29 Is Fast Path headed nowhere?
https://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#44 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#34 IBM 3705 and UC.5
https://www.garlic.com/~lynn/2004p.html#48 History of C
https://www.garlic.com/~lynn/2004p.html#58 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#62 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
https://www.garlic.com/~lynn/2004q.html#71 will there every be another commerically signficant new ISA?
https://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
https://www.garlic.com/~lynn/2005.html#51 something like a CTC on a PC
https://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#63 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2005d.html#30 The Mainframe and its future.. or furniture
https://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005e.html#13 Device and channel
https://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#30 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#36 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005h.html#11 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
https://www.garlic.com/~lynn/2005h.html#43 Systems Programming for 8 Year-olds
https://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005m.html#8 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2005n.html#10 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#12 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#16 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#29 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
https://www.garlic.com/~lynn/2005o.html#16 ISA-independent programming language
https://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005p.html#19 address space
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#2 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
https://www.garlic.com/~lynn/2005s.html#35 Filemode 7-9?
https://www.garlic.com/~lynn/2005s.html#36 Filemode 7-9?
https://www.garlic.com/~lynn/2005s.html#39 Filemode 7-9?
https://www.garlic.com/~lynn/2005t.html#45 FULIST
https://www.garlic.com/~lynn/2005t.html#48 FULIST
https://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
https://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
https://www.garlic.com/~lynn/2005u.html#45 IBM's POWER6
https://www.garlic.com/~lynn/2005u.html#46 Channel Distances
https://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
https://www.garlic.com/~lynn/2005u.html#49 Channel Distances
https://www.garlic.com/~lynn/2006.html#47 "VAX" Tradename reused !
https://www.garlic.com/~lynn/2006b.html#19 IBM 3090/VM Humor
https://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
https://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces
https://www.garlic.com/~lynn/2006b.html#34 Multiple address spaces
https://www.garlic.com/~lynn/2006b.html#39 another blast from the past
https://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006e.html#39 The Pankian Metaphor
https://www.garlic.com/~lynn/2006f.html#12 Barbaras (mini-)rant
https://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
https://www.garlic.com/~lynn/2006i.html#33 virtual memory
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006j.html#23 virtual memory
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/2006k.html#8 Arpa address
https://www.garlic.com/~lynn/2006k.html#31 PDP-1
https://www.garlic.com/~lynn/2006k.html#32 PDP-1
https://www.garlic.com/~lynn/2006l.html#2 virtual memory
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006l.html#17 virtual memory
https://www.garlic.com/~lynn/2006l.html#18 virtual memory
https://www.garlic.com/~lynn/2006l.html#19 virtual memory
https://www.garlic.com/~lynn/2006l.html#25 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006l.html#40 virtual memory
https://www.garlic.com/~lynn/2006l.html#44 The very first text editor
https://www.garlic.com/~lynn/2006l.html#48 virtual memory
https://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006l.html#55 virtual memory
https://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
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 -0600Van Dalsen, Herbie wrote:
from above:
The seeds of a minicomputer revolution were planted as early as 1960,
with the introduction by Digital Equipment Corporation of the
transistor-based PDP1 for technical computing by engineers and
scientists. The PDP1 was succeeded by the PDP5, then the highly
successful PDP8 in 1965 and the PDP11 in 1969.
... snip ...
a pdp1 page (as opposed to pdp11):
http://www.dbit.com/~greeng3/pdp1/
https://web.archive.org/web/20050330083323/http://www.dbit.com/~greeng3/pdp1/
http://www.accreditedonlinecolleges.net/history-of-the-digital-equipment-corporation-dec/
a history of computers
http://www.sskrplaw.com/publications/cyber3.pdf
from above:
1/48 IBM makes it first computer
1952 IBM produces 701, designed by Nathaniel Rochester, first production
line electronic stored program computer
1954 IBM's John Backus creates Fortran
1954 Gene Amdahl develops first operating system used on IBM 704
1957 Harlan Anderson and Ken Olson form DEC
1960 DEC builds PDP1, producing 50 machines
... snip ...
so based on earlier reference, they may have started building PDP1s in 1960 but possibly didn't begin shipping the 50 machines until 1961?
so a little more topic drift about the boston programming center on the 3rd flr of 545tech sq.
the cp67 group split off from the science center and took over the boston programming center on the 3rd floor (and subsequent growth and morphing into the vm370 group, they moved to old service bureau corp. building in burlington mall).
as previously mentioned
https://www.garlic.com/~lynn/2006m.html#21 The very first text editor
Jean Sammet was at the Boston Programming Center on the 3rd flr at the time ... but so was Nat Rochester.
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 -0600David.W.Neylon@ibm-main.lst wrote:
boeing huntsville had custom modified mvt version 13 with virtual memory support running on two processor 360/67. the system didn't support paging ... but workload was a lot of long running 2250 (graphics) "jobs". mvt had a tendency to fragment storage ... and mvt applications tended to require contiguous storage allocation. use of virtual memory hardware allowed emulation of contiguous storage (even when real storage was severely fragmented).
at the univ. we didn't "sysgen" mvt until release 15/16 (i.e. there had been problems with release 15 which delayed ship ... and they eventually shipped it as combined with release 16).
some historical references:
http://www.os390-mvs.freesurf.fr/mvshist1.htm
http://mcraeclan.com/Links/Computers/IBMMainframeHistory/mvshist1.htm
the above references "sysgen" process which was typically done using the "starter" system.
at the univ, starting with release 11, I had done a lot of work for doing "sysgens" in production job stream. apart of this was that as an undergraduate, I would get the datacenter to myself on the weekends (8am sat. until 8am monday). however, related to release 9.5 sysgen, a couple of univ. employees and local ibm SEs would take a couple weekend shifts to boot starter system and do release 9.5 sysgen. i got curious and duplicated their stage1 sysgen deck ... and then started looking at what was involved in the process. basically would assemble stage1 sysgen deck ... which would "punch" a bunch about a box of cards ... that represented the "stage2" sysgen ... that actually built the new system (50-80 job steps, lots of iebcopy and iehmove steps, along with smattering of other stuff).
part of the activity was to redo sysgen so i could run it in production job stream. the other was so that i could carefully control the placement of datasets and pds members for optimal disk arm movement (in the resulting generated system).
later boeing was putting together bcs (boeing computer services) and they hired me for summer job to help set things up. i was given an management badge (that allowed me to park in "management" parking lot at boeing hdqtrs bldg at boeing field). they had installed a new 360/67 uniprocessor for running cp67 and were in the process of acquiring the 360/67s that were at boeing huntsville.
misc. past posts mentioning modifying stage1/stage2 sysgen to run in
production job stream ... note previous mention about presentation made
at fall68 share meeting in Atlantic City regarding running os/360 in cp67
virtual machine ... also mentions getting around 300percent increase in
thrput for some typical univ. workload with the careful disk arm motion
optimization.
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
https://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
https://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
https://www.garlic.com/~lynn/2003c.html#51 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
https://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
https://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005h.html#6 Software for IBM 360/30 (was Re: DOS/360: Forty years)
https://www.garlic.com/~lynn/2005n.html#40 You might be a mainframer if... :-) V3.8
https://www.garlic.com/~lynn/2005o.html#12 30 Years and still counting
https://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloads
https://www.garlic.com/~lynn/2005t.html#18 Various kinds of System reloads
https://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
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 -0600Shmuel Metz , Seymour J. wrote:
tss/360 (the "real" operating system that was suppose to be for 360/67) had a different mechanism ... moving address constants out of the program image ... so they could do "memory mapped" program execution ... w/o having to preload the program image and run thru all the various address constants (in the image) and swizzling them to the appropriate value (required by the os/360 genre).
part of the issue was that the executable paged mapped (out of the filesystem on disk) object could occupy a read-only shared segment ... that might possibly be at different address locations in different virtual address spaces. As a result, it wasn't just having to preload the executable image pages to swizzle the address constants ... but also the executable image was r/o and might not have a constant fixed location in every virtual address space (i.e. there would be no single value for address constants that were acceptable across all possible address spaces).
note that multics had similar issues and addressed them in similar
manner. recent post with some multics pointers
https://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
in any case, tss/360 had a hard time achieving market acceptance ... partially because the code implementation was significantly slowwwwwww ... and after i had a couple months as an undergraduate rewriting cp67 kernel code ... cp67 was running rings around tss/360 ... and could also offer virtual machine capability (on the same 360/67 hardware). a morph of tss/360 to tss/370 and then to ssup ... did find some deployment inside at&t. ssup was stripped down to its basic kernel functions with higher level unix functions layered on top of the lower level tss/370 functions.
now when i did paged mapped filesystem for cp67/cms ... later ported to
vm370/cms ... with similar capability
https://www.garlic.com/~lynn/submain.html#mmap
I was placed in a real bind. cms had picked up a lot of its environment
by adapting many os/360 assemblers, compilers, and applications (and
therefor inheriting the os/360 address constant convention). i had to
play all sorts of games to create page mapped executable objects that
could occupy shared segments in multiple different virtual address
spaces, potentially simultaneously at different virtual addresses ... a
few posts mentioning some of the hoops i had to go thru dealing with
os/360 address constants in a virtual address space, paged mapped
filesystem paradigm
https://www.garlic.com/~lynn/submain.html#adcon
misc. past posts mentioning tss/360, tss/370 and/or ssup (unix layered
on top of tss/370 for at&t)
https://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
https://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
https://www.garlic.com/~lynn/95.html#1 pathlengths
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
https://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
https://www.garlic.com/~lynn/99.html#2 IBM S/360
https://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
https://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
https://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
https://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000c.html#8 IBM Linux
https://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
https://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems
https://www.garlic.com/~lynn/2000f.html#18 OT?
https://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
https://www.garlic.com/~lynn/2001e.html#19 SIMTICS
https://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
https://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
https://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001f.html#48 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001h.html#26 TECO Critique
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
https://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
https://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#5 mainframe question
https://www.garlic.com/~lynn/2001l.html#6 mainframe question
https://www.garlic.com/~lynn/2001l.html#7 mainframe question
https://www.garlic.com/~lynn/2001l.html#8 mainframe question
https://www.garlic.com/~lynn/2001l.html#9 mainframe question
https://www.garlic.com/~lynn/2001l.html#11 mainframe question
https://www.garlic.com/~lynn/2001l.html#17 mainframe question
https://www.garlic.com/~lynn/2001l.html#18 mainframe question
https://www.garlic.com/~lynn/2001l.html#20 mainframe question
https://www.garlic.com/~lynn/2001m.html#47 TSS/360
https://www.garlic.com/~lynn/2001m.html#49 TSS/360
https://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
https://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
https://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
https://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002d.html#23 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002f.html#36 Blade architectures
https://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
https://www.garlic.com/~lynn/2002f.html#42 Blade architectures
https://www.garlic.com/~lynn/2002f.html#53 WATFOR's Silver Anniversary
https://www.garlic.com/~lynn/2002j.html#27 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
https://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
https://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
https://www.garlic.com/~lynn/2002n.html#57 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2002n.html#62 PLX
https://www.garlic.com/~lynn/2002n.html#64 PLX
https://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2003d.html#54 Filesystems
https://www.garlic.com/~lynn/2003d.html#58 POWER hashes vs tree
https://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
https://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
https://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
https://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
https://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
https://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
https://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
https://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#41 Secure OS Thoughts
https://www.garlic.com/~lynn/2003m.html#16 OSI not quite dead yet
https://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
https://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
https://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
https://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
https://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
https://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
https://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
https://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
https://www.garlic.com/~lynn/2004c.html#60 IBM 360 memory
https://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#9 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#20 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
https://www.garlic.com/~lynn/2004f.html#55 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#14 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#15 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#16 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004m.html#5 Tera
https://www.garlic.com/~lynn/2004n.html#3 Shipwrecks
https://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#5 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#25 Shipwrecks
https://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#2 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#5 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
https://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#2 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#4 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#5 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#9 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#11 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#27 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#44 The mid-seventies SHARE survey
https://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005j.html#16 Performance and Capacity Planning
https://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005k.html#8 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2005m.html#4 [newbie] Ancient version of Unix under vm/370
https://www.garlic.com/~lynn/2005n.html#31 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#35 PART 3. Why it seems difficult to make an OOO VAX competitive
https://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
https://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#17 winscape?
https://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D
https://www.garlic.com/~lynn/2006.html#13 VM maclib reference
https://www.garlic.com/~lynn/2006.html#41 Is VIO mandatory?
https://www.garlic.com/~lynn/2006b.html#4 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
https://www.garlic.com/~lynn/2006d.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006e.html#31 MCTS
https://www.garlic.com/~lynn/2006e.html#33 MCTS
https://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit
https://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
https://www.garlic.com/~lynn/2006g.html#3 The Pankian Metaphor
https://www.garlic.com/~lynn/2006i.html#22 virtual memory
https://www.garlic.com/~lynn/2006i.html#30 virtual memory
https://www.garlic.com/~lynn/2006j.html#17 virtual memory
https://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#14 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#41 PDP-1
https://www.garlic.com/~lynn/2006l.html#34 Dual Core CPUs are slower than Dual Single core CPUs ??
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Mainframe Limericks... Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 24 Jun 2006 09:18:26 -0600Joe Morris wrote:
not directly that i know of ... but it may have help contribute to being able to specify cylinder location of disk VTOC that appeared in release 15/16. now i could place VTOC in the middle of the volume and somewhat array files and PDS members radiating out from the center (instead from cylinder zero) ... although PDS members was straight forward on the increasing cylinder side of the VTOC ... but was less straight forward on the decreasing cylinder side of the VTOC.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Old Hashing Routine Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 24 Jun 2006 12:00:35 -0600Jim Mulder wrote:
in past posts i've told the story both ways ... both of the unused bits by architecture allowing PTEs to address up to 2**14 4k real pages (64mbyte) or one unused bit by 3033 to support 2**13 4k real pages. I remember lots of 32mbyte 3081s but don't remember any 64mbyte 3081s.
part of this is my scenario about dasd had declined in relative system performance by a factor of ten times over 10-15 yr period i.e. rest of the system resources/thruput increased by 40-50 times while dasd increased by only 4-5 times.
at least by the time i release the resource manager ... 11may76, you
were starting to see real storage used to compensate for system thruput
being constrained by dasd performance. i had done much of the work as an
undergraduate in the 60s for cp67 ... which then got dropped in the
morph from cp67 to vm370 ... but then was allowed to rerelease it as the
resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
i had a comparison of cp67 360/67 configuraiton and a vm370 3081 configuration ... and observed if overall system thruput had kept pace with the cpu, the typical number of users would have gone from 80 on 360/67 to over 2000 on 30831 ... but in fact, typical 3081 configurations tended to be more like 300-400 users ... which represented the change in dasd thruput between 360/67 and 3081.
this is the story about initially the san jose disk division assigned their performance group to refute the claims ... but they came back a couple weeks later and explained that i had actually understated the problem.
the other issue is that ckd dasd from the 60s ... traded off i/o thruput with extended (& multi-track) searches for real memory use ... i.e. more real memory intensive tended to cache indexes to specific disk location ... while vtoc & pds multi-track search spun the disk to find location. Some of the IMS ccw programs took this to the extreme with long ccw programs searching and finding fields in disk-based index structures ... which then were read and used for further searching ... all in a single channel program.
i've often repeated story about being called into a large national
retailer with a large complex of vs2 processor complex ... basically
loosely-coupled with processors dedicated to each region. they were
experience sever performance degradation. turns out they had a large
application program library shared across all processors in the complex
with a three (3330) cylinder PDS index. aggregate number of I/Os to
(across all processors in the complex) avg. about 6.5/sec ... because
they were doing avg 1.5 cylinder search of the PDS index. the
multi-track search of the first cylinder at 3600rpm/19cylinders was
about .3secs elapsed time (i.e. being limited to approx three
application program member loads per second aggregate across all the
processors in the complex).
https://www.garlic.com/~lynn/submain.html#dasd
the other place that you saw real memory compensating for dasd
performance was with the emergance of rdbms in the 80s. there were
arguments between STL (60s physical database) and SJR ... original
relational/sql database implementation
https://www.garlic.com/~lynn/submain.html#systemr
the 60s paradigm had direct record pointers imbedded as part of the database infrastructure and exposed to application programmers. this allowed going directly from one record to the next relatively efficiently. however, there was heavy people and skill resource overhead for management of the structure.
system/r abstracted away the direct pointers with the relational paradigm ... substituting internal index tree structure managed by the dbms (no longer requiring direct administrative and application support). this significantly decreased the people and skill resources needed to manage the infrastructure. however, it might take 5-6 disk reads of index structure to find the disk record pointer to the actual record needed. the other argument was that the on-disk index structure could double the physical disk space required for relational implementation vis-a-vis a "60s" physical dbms implementation.
what happened in the 80s was that disk space became increasingly less expensive ($$/mbyte which has now shifted $$/gbyte) and the explosion in real memory sizes allowed much of the relational index to be cached in real memory (eliminating a lot of the additional disk reads to get to the actual record).
various past posts discussing the STL/SJR argument over "60s" physical
databases (with direct record pointers) and relational which created a
dbms metaphor that eliminated the direct record pointers from the
database abstraction:
https://www.garlic.com/~lynn/2000c.html#13 Gif images: Database or filesystem?
https://www.garlic.com/~lynn/2004e.html#23 Relational Model and Search Engines?
https://www.garlic.com/~lynn/2004e.html#25 Relational Model and Search Engines?
https://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
https://www.garlic.com/~lynn/2004p.html#1 Relational vs network vs hierarchic databases
https://www.garlic.com/~lynn/2004q.html#23 1GB Tables as Classes, or Tables as Types, and all that
https://www.garlic.com/~lynn/2005.html#25 Network databases
various past posts about the two unused bits in the 370 PTE and using
them to increase the number of real pages that could be specified
(greater than 2**12 4k real pages past 16mbytes):
https://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
https://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?
https://www.garlic.com/~lynn/2004.html#17 Holee shit! 30 years ago!
https://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2006b.html#34 Multiple address spaces
https://www.garlic.com/~lynn/2006l.html#2 virtual memory
various posts describing the cp67 360/67 with vm370 3081 comparison and
the increasing disk system thruput constraint:
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
https://www.garlic.com/~lynn/98.html#46 The god old days(???)
https://www.garlic.com/~lynn/99.html#4 IBM S/360
https://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
https://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
https://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
https://www.garlic.com/~lynn/2002.html#5 index searching
https://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
https://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
https://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
https://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why Did No Core Machines Have Cache ??? Newsgroups: comp.arch Date: Sun, 25 Jun 2006 09:07:46 -0600glen herrmannsfeldt writes:
and some more
Model Announced First Shipped Withdrawn
85 January 30, 1968 December 1969 June 24, 1971
Structural aspects of the System/360 Model 85, Part I: General organization
http://domino.research.ibm.com/tchjr/journalindex.nsf/495f80c9d0f539778525681e00724804/a846ccbbdfe8f77a85256bfa00685a32?OpenDocument
abstract:
A basic design objective for the Model 85 was to add a computer to the
SYSTEM/360 line that offers high performance over a wide range of job
types. Simulation studies indicate that the Model 85 will provide an
average three- to five-fold increase in internal performance with main
storage capacities of up to four million bytes. This part of the paper
discusses the major elements of the Model 85 within the architectural
context of SYSTEM/360, including the addition of a high-speed buffer,
called a cache. Also summarized are the simulation studies that led to
use of the cache, selection of its parameters, and verification of
internal performance of the system.
... snip ...
http://www.research.ibm.com/journal/sj/071/ibmsj0701B.pdf
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PDP-1 Newsgroups: alt.folklore.computers Date: Sun, 25 Jun 2006 09:56:18 -0600Anne & Lynn Wheeler writes:
for some additional (recent) drift on this old post
FC++3 - Advances in Financial Cryptography, Number Three
https://financialcryptography.com/mt/archives/000757.html
FC++3 - Dr Mark Miller - Robust Composition: Towards a Unified
Approach to Access Control and Concurrency Control
https://financialcryptography.com/mt/archives/000702.html
I'm program co-chair of security and virtualization track at IEEE TC
Computer Elements, Vail 2006 starting later today. One of the talks
is
5.1 Virtualization/Security- Prog Lang Design Mark Miller
ref:
https://www.garlic.com/~lynn/aadsm24.htm#11 FC++3 - Advances in Financial Cryptography, Number Three
some of the co-authors here were involved with Tymshare, gnosis, keykos, etc
http://www.erights.org/talks/index.html
From: lynn@garlic.com Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l Subject: Re: Draft Command Script Processing Manual Date: Sun, 25 Jun 2006 15:11:52 -0700Brian Westerman wrote:
parasite did 3270 terminal emulation. it was less than 8k bytes executable (written in assembler). story was the scripting processor ... also less than 8k bytes executable (written in assembler). the reference includes story syntax and has example of some number of story "scripts". story processing included support for REX variables ... aka still internal software ... before it was renamed to REXX and released as a product.
there is even an example story in the above to automatically retrieve put bucket from retain.
From: lynn@garlic.com Subject: Re: English (was Mainframe Limericks Newsgroups: bit.listserv.ibm-main Date: 28 Jun 2006 08:36:41 -0700and to bend it even again ...
Mother tongue may determine maths skills
http://www.newscientistspace.com/article.ns?id=dn9422&feedId=online-news_rss20
from above ...
The native language you speak may determine how your brain solves
mathematical puzzles, according to a new study. Brain scans have
revealed that Chinese speakers rely more on visual regions than English
speakers when comparing numbers and doing sums.
... snip ...
this somewhat reminds me of a description of analog vis-a-vis digital clocks. the analog hands ... not only give the current time but can spatially represent how long since or how long to some time.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Curiosity Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 29 Jun 2006 18:10:54 -0600Jim Mulder wrote:
early implementations of TCP "FINWAIT" were linear lists. as part of closing TCP session, in part, because IP packets arrive out-of-order ... a list of sessions in the process of being closed and recently closed sessions were kept. in early implementations, assuming the number of items on the FINWAIT list were relatively few (in part because of assumptions that TCP sessions were relatively long lived), they used linear list. In any case, when packet arrives, there is (quick?) search of FINWAIT list to see if it is related to such a session.
HTTP came along and used TCP for transaction operations (TCP session requires a minimum of 7 packet exchange; by comparison VMTP/RFC1045, more oriented towards reliable transaction, has minimum 5 packet exchange; and XTP for reliable transaction has minimum 3 packet exchange). This violated various assumptions about TCP sessions being long lived, frequency of TCP session termination and probable number of items on lists.
As some web servers became popular, they started running into horrible processing bottlenecks with 99percent of the processor devoted to searching the FINWAIT list (in some cases with over 10,000 items). Each search of the list was linear, but the total time-spent searching the list, increased non-linear ... since the length of the list increased dramatically (because of the humongous number of closing short-lived HTTP TCP sessions).
in any case, overhead of O(n) implementations can increase non-linearly when the number of "n" shows large increases (because of load and/or the frequency of the searching also increases).
RFC763 talks about FIN processing ...
my RFC index
https://www.garlic.com/~lynn/rfcietff.htm
RFC793 summary:
https://www.garlic.com/~lynn/rfcidx2.htm#793
from above:
793 S
Transmission Control Protocol, Postel J., 1981/09/01 (85pp)
(.txt=172710) (STD-7) (Updated by 3168) (Obsoletes 761) (Ref'ed By 788,
821, 879, 882, 883, 915, 916, 959, 964, 977, 983, 1001, 1006, 1034,
1035, 1050, 1057, 1063, 1072, 1085, 1086, 1095, 1105, 1106, 1122, 1163,
1177, 1185, 1189, 1190, 1201, 1206, 1241, 1244, 1254, 1267, 1270, 1301,
1323, 1325, 1349, 1379, 1475, 1538, 1561, 1594, 1626, 1644, 1654, 1693,
1700, 1705, 1707, 1726, 1770, 1771, 1812, 1831, 1858, 1859, 1936, 1948,
1953, 1982, 2012, 2018, 2074, 2126, 2140, 2219, 2246, 2326, 2391, 2428,
2481, 2488, 2507, 2525, 2577, 2581, 2637, 2663, 2675, 2747, 2760, 2775,
2780, 2795, 2821, 2828, 2873, 2885, 2896, 2914, 2960, 2975, 2988, 2993,
3015, 3018, 3022, 3033, 3042, 3080, 3081, 3093, 3094, 3117, 3124, 3135,
3142, 3148, 3155, 3168, 3196, 3237, 3242, 3252, 3322, 3360, 3366, 3430,
3436, 3449, 3481, 3511, 3517, 3522, 3525, 3530, 3539, 3588, 3639, 3708,
3715, 3720, 3723, 3724, 3730, 3734, 3748, 3783, 3819, 3821, 3828, 3836,
3920, 3955, 4138, 4145, 4163, 4180, 4294, 4297, 4340, 4341, 4347, 4362,
4413, 4497) (TCP)
... snip ...
clicking on the ".txt=nnn" field in an RFC summary, retrieves the actual RFC.
so here is random reference from the web on how long something is kept
on lists (i.e. particular session kept in particular state)
http://mail-index.netbsd.org/tech-net/2002/11/07/0000.html
from above:
The first FIN from either side (after passing sequence number checks, of
course) puts the state entry into tcp.closing, and a subsequent ACK
from the other side puts the state into tcp.finwait.
The state will be removed after no packet has been associated with it
for a number of seconds, the default timeout values are 900 seconds for
tcp.closing and 45 seconds for tcp.finwait. If subsequent packets like
retransmissions or parts of a simultanous close match the state entry,
the timer is reset again (to tcp.closing or tcp.finwait, respectively).
Timeouts can be set globally and overriden per rule for tcp.first,
.opening, .established, .closing, .finwait and .closed.
... snip ...
random past postings retelling the HTTP/FINWAIT story:
https://www.garlic.com/~lynn/99.html#1 Early tcp development?
https://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/2002.html#3 The demise of compaq
https://www.garlic.com/~lynn/2002.html#14 index searching
https://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
https://www.garlic.com/~lynn/2005g.html#42 TCP channel half closed
https://www.garlic.com/~lynn/aadsm23.htm#21 Reliable Connections Are Not
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
https://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Computers in the movies Newsgroups: alt.folklore.computers Date: Thu, 29 Jun 2006 22:01:38 -0600"Derek Simmons" writes:
other past trivia postings about wargames movie
https://www.garlic.com/~lynn/2000d.html#39 Future hacks [was Re: RS/6000 ]
https://www.garlic.com/~lynn/2001m.html#52 Author seeks help - net in 1981
https://www.garlic.com/~lynn/2002b.html#38 "war-dialing" etymology?
https://www.garlic.com/~lynn/2003m.html#14 Seven of Nine
https://www.garlic.com/~lynn/2004p.html#40 Computers in movies
https://www.garlic.com/~lynn/2006f.html#7 The Pankian Metaphor
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Using different storage key's Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 30 Jun 2006 13:06:17 -0600Tom Marchant wrote:
We used to talk about it at the monthly meetings at SLAC ... possibly
even talked about it before it was even announced. I also had discussed
some of my experiences having worked on ECPS for 138/148 ... a couple of
old ECPS postings
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
I have some vague recollection of one of the people who had done the hypervisor implementation saying that they had hoped for better thruput improvement based on my comments regarding ECPS.
various collecting postings discussing various microcode aspects (mostly
360 or 370)
https://www.garlic.com/~lynn/submain.html#360mcode
random past posts mentioning macrocode
https://www.garlic.com/~lynn/2002p.html#44 Linux paging
https://www.garlic.com/~lynn/2002p.html#48 Linux paging
https://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
https://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
https://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
https://www.garlic.com/~lynn/2005d.html#60 Misuse of word "microcode"
https://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
https://www.garlic.com/~lynn/2005p.html#14 Multicores
https://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
https://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
https://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries?
https://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
https://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
https://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
https://www.garlic.com/~lynn/2006j.html#32 Code density and performance?
https://www.garlic.com/~lynn/2006j.html#35 Code density and performance?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Microcomputers As A Space Spinoff Newsgroups: alt.folklore.computers Date: Sat, 01 Jul 2006 19:09:23 -0600Larry Elmore writes:
in a blog entry discussing leadership,
https://financialcryptography.com/mt/archives/000767.html
and so also had to throw in a reference to Boyd's talk on organic
design for command and control
http://www.belisarius.com/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why Didn't The Cent Sign or the Exclamation Mark Print? Newsgroups: alt.folklore.computers Date: Sun, 02 Jul 2006 12:46:28 -0600so most of the early cp67/cms work was all done with 2741 terminal keyboards
reference can be found here
http://www.quadibloc.com/comp/kybint.htm
so one of the conventions used was that "@" was used as "character delete" .... lower case key to the right of the "P" key (found at the above) and cent-sign was used as "line delete" (or rather all characters to the left of the cent-sign) ... the upper case of the same "@" key, just to the right ot the "P" key.
so the univ. was the first cp67 installation with tty33/ascii terminals ... and so among all the other changes I made to cp67 (as an undergraduate in the 60s) was to redo the terminal support to add tty33/ascii support. One of the issues was what to map for the character-delete and line-delete ... but as you can see in the "Typewriter-pairing ASCII (original form)" keyboard layout (same URL and just above the 2741 keyboard layout) ... what is the lower/upper case characters of the key to the right of the "P" key???
i was trying to do tricks with automatic terminal recognition and
found that the standard ibm telecommunication controller couldn't
quite do everything that i wanted. That somewhat was what led to the
univ. starting the project to build our own telecommunication
controller ... that could do everything that I wanted ... which in
turn led to somebody writing an article blaming four of us for the
ibm plug compatible controller business ... misc. past posts
https://www.garlic.com/~lynn/submain.html#360pcm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why Didn't The Cent Sign or the Exclamation Mark Print? Newsgroups: alt.folklore.computers Date: Sun, 02 Jul 2006 20:38:40 -0600seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
a couple past posts mentioning the MTS and PDP stuff
https://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
https://www.garlic.com/~lynn/2006k.html#41 PDP-1
https://www.garlic.com/~lynn/2006k.html#42 Arpa address
this has a picture of the 67 running MTS ...
http://www.eecis.udel.edu/~mills/gallery/gallery8.html
although the comment is a little off since cp40 (on 360/40 with custom
hardware virtual memory) was operational before either mts or multics.
and the port of cp40 from 360/40 to 360/67 for cp67 was about the same
time-frame as MTS ... mentioned here as May, 1967:
http://www.clock.org/~jss/work/mts/30years.html
here is the picture of the PDP8 as a front-end communication
processor for MTS
http://www.eecis.udel.edu/~mills/gallery/gallery7.html
so what is the tie-in between network time protocol and MTS?
this is my RFC summary entry for NTP standard (clicking on
the "txt=nnn" field retrieves the actual RFC:
https://www.garlic.com/~lynn/rfcidx4.htm#1305
here is some reference to additional MTS information (the pages look
like what were at umich ... but those URLs have gone 404)
http://www.clock.org/~jss/work/mts/index.html
http://www.clock.org/~jss/work/mts/summary.html
this also tells some more of the story of MTS starting out
with LLMPS as its basis
http://www.clock.org/~jss/work/mts/30years.html
LLMPS done at lincoln labs ... which installed cp67 on their
360/67 in 67. then the univ. i was at what become the 3rd cp67 installation
when some people from the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
came out the last week in jan68 to install it.
"multics" home page (which was on the 5th flr, 545 tech sq,
while the science center doing cp67 was on the 4th flr)
http://www.multicians.org/
multics cronology
http://www.multicians.org/chrono.html
has reference to the 5/67 date for MTS
http://www.clock.org/~jss/work/mts/
and multics phase 1 milestone with single process boot, 12/67
http://www.multicians.org/phase-one.html
and the "official" release of cp67 on 5/68. other dates from the multics cronology has 9/67 as PDP-10 being announced and BBN starting work on TENEX.
demonstrable initial multics milestone w/8 users, 10/68.
other early history about ctss, multics, cp40, cp67, virtual machine,
etc from Melinda's history paper
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist
totally unrelated postings mentioning umich
https://www.garlic.com/~lynn/99.html#15 Glass Rooms (was Re: drum memory (was: Re: IBM S/360))
https://www.garlic.com/~lynn/2002l.html#22 Computer Architectures
LLMPS was a contributed program ... I still have the LLMPS manual (but
no software); Misc. past postings mentioning LLMPS
https://www.garlic.com/~lynn/93.html#15 unit record & other controllers
https://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
https://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
https://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
https://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
https://www.garlic.com/~lynn/2000.html#89 Ux's good points.
https://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001m.html#55 TSS/360
https://www.garlic.com/~lynn/2001n.html#45 Valid reference on lunar mission data being unreadable?
https://www.garlic.com/~lynn/2001n.html#89 TSS/360
https://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2002n.html#64 PLX
https://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
https://www.garlic.com/~lynn/2004d.html#31 someone looking to donate IBM magazines and stuff
https://www.garlic.com/~lynn/2004l.html#16 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
https://www.garlic.com/~lynn/2005g.html#56 Software for IBM 360/30
https://www.garlic.com/~lynn/2006k.html#41 PDP-1
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Google Architecture Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 03 Jul 2006 08:37:12 -0600Anne & Lynn Wheeler writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Musings on a holiday weekend Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 03 Jul 2006 09:52:46 -0600McKown, John wrote:
While FS was incompatible ... there were lots of other issues. It was extremely ambitious with seemingly every blue-sky concept that ever existed being thrown into the pot. At the time, I somewhat ungraciously compared it to a cult film that had been playing continuously down in central sq for over a decade (as the inmates being in charge of the institution). I also claimed that what I had running at the time was "better" than what was described for resource management in the FS architecture documents.
I believe the "nail" in the FS coffin was a study by the Houston Science Center ... applications run on a FS machine built out of the same level technology as used in 370/195 ... would have thruput approximately that of 370/145 (FS hardware complexity reduced thruput by over an order of magnitude).
After the death of FS ... some number of people went off to Rochester
and created the s/38 that implemented some of the concepts from FS ...
as/400 cisc was the follow-on to s/38. later as/400 was ported from cisc
technology to power/pc technology. misc. collected posts on 801, romp,
rios, power/ps, etc
https://www.garlic.com/~lynn/subtopic.html#801
old post (in this n.g./mailing list) that has some quotes from another
source
https://www.garlic.com/~lynn/2000f.html#16 FS - IBM Future System
as mentioned in the above ... a lot of FS was reaction to appearance of
plug-compatible controllers. recent posts mentioning working on
plug-compatible controller as undergraduate ... and subsequent article
that blamed that project for the plug-compatible controller business
https://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
https://www.garlic.com/~lynn/2006m.html#40 Microcomputers As A Space Spinoff
https://www.garlic.com/~lynn/2006m.html#41 Why Didn't The Cent Sign or the Exlamation Mark Print?
past collected posts mentioning plug compatible controllers
https://www.garlic.com/~lynn/submain.html#360pcm
there is some folklore that the FS mantra/direction may have contributed to Amdahl leaving to do (plug-compatible) high-performance 370 (processors)
past collected posts mentioning FS
https://www.garlic.com/~lynn/submain.html#futuresys
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Musings on a holiday weekend Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 03 Jul 2006 10:44:34 -0600Ted Macneil wrote:
re:
https://www.garlic.com/~lynn/2006m.html#44 Musings on a holiday weekend
this was step up from complaints about including all the URLs in the body of each post ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Musings on a holiday weekend Newsgroups: bit.listserv.ibm-main,alt.folklore.computers CC: ibmmain <ibm-main@bama.ua.edu> Date: Mon, 03 Jul 2006 10:51:16 -0600Anne & Lynn Wheeler wrote:
re:
https://www.garlic.com/~lynn/2006m.html#44 Musings on a holiday weekend
one could look back and claim that 801/risc activity was significantly motivated by FS and to do the exact opposite of FS with regard to hardware complexity. the other aspect, is to define a hardware architecture that had possibility of being implemented in a single chip (of the period). However, much of the 801/risc hardware mantra was KISS ... nearly the exact opposite of the FS hardware mantra.
So it was somewhat interesting to see the s/38 descendant (as/400) eventually move to 801/risc hardware platform.
for a little topic drift ... recent post discussing some of the KISS issue
https://www.garlic.com/~lynn/aadsm24.htm#15 Apple to help Microsoft with "security neutrality"?
https://www.garlic.com/~lynn/aadsm24.htm#16 Apple to help Microsoft with "security neutrality"?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The System/360 Model 20 Wasn't As Bad As All That Newsgroups: alt.folklore.computers Date: Tue, 04 Jul 2006 10:05:37 -0600seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
recent post on the subject in FS thread:
https://www.garlic.com/~lynn/2006m.html#44 Musings on a holiday weekend
something similar by Umich using PDP1 in conjunction w/MTS
https://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?
collected posts mentioning the effort and plug compatible controllers
https://www.garlic.com/~lynn/submain.html#360pcm
interdata simulator reference
http://simh.trailing-edge.com/interdata.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The System/360 Model 20 Wasn't As Bad As All That Newsgroups: alt.folklore.computers Date: Tue, 04 Jul 2006 10:08:39 -0600seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
for the machines based on 750ns memory, It was 8byte-wide (interleaved) fetch. part of the instruction timings were the prorated instruction fetch times i.e. two-byte instructions included 1/4 750ns, four-byte instructions included 1/2 750ns, and six-byte instructions included 3/4 750ns (prorated double word instruction fetch).
gory details for 360/65 timings start on page 20
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A22-6884-3_360-65_funcChar.pdf
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: The Pankian Metaphor (redux) Newsgroups: alt.folklore.computers Date: Tue, 04 Jul 2006 13:39:57 -0600US automakers' June sales sag
from above:
U.S. sales fell for all three big American automakers in June, led by
a 26 percent drop at General Motors Corp., while Japan's
Toyota Motor Corp. surged.
... snip ...
Toyota poised to become top car seller in U.S.:
https://www.garlic.com/~lynn/2003l.html#29 Offshore IT
mention old 100% unearned profit tax article from the late 70s (related to
auto import quotas) and automotive C4 project circa 1990
https://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The System/360 Model 20 Wasn't As Bad As All That Newsgroups: alt.folklore.computers Date: Tue, 04 Jul 2006 14:26:03 -0600seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
when somebody referenced that there was a 360/62, i jumped to the conclusion that it might have also been 360/67 with one mic. memory ... in part because I have some vague recollection of reading an early overview pub on machine with virtual memory that was being offered in single (uniprocessor), two processing and four processor models (i.e. smp, multiprocessor) ... and some vague impression that it might have been a different model number.
later when 360/67 showed up there was no longer a four processor model.
there was a custom three procesor model version built for MOL (manned orbital laboratory) project delivered to lockheed ... whiched then seem to disappear. i stumbled across some reference to it showing up again (or at least part of it) at ncss ...
ncss reference here at computer history museum
http://www.computerhistory.org/corphist/view.php?s=select&cid=4
here is the reference:
http://www.computerhistory.org/corphist/view.php?s=events&id=330
from above:
Installation of first operational duplex 67 (actually 2/3's of the MOL
triplex system). The team came up with a simplifying algorithm that
increased perfomance over the initial algorithm very significantly.
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The System/360 Model 20 Wasn't As Bad As All That Newsgroups: alt.folklore.computers Date: Tue, 04 Jul 2006 19:45:36 -0600seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
i thot for a moment that it might be 2914 ... but they are typically
only found in multiple machine environment
http://www.labx.com/v2/spiderdealer2/vistaSearchDetails.cfm?LVid=3017353
this has picture of multiple control consoles for 360/91 ....
http://www.columbia.edu/cu/computinghistory/36091.html
but the one "control console" is shown from the rear
http://www.columbia.edu/cu/computinghistory/36091-ibm.jpg
360 system summary
http://www.bitsavers.org/pdf/ibm/360/systemSummary/A22-6810-0_360sysSummary64.pdf
figure 6 has poor image of 360/40 and 360/70 with a 2150 console on pg. 12
pg. 20 mentions 2150 console duplicating operators' controls
pg. 21 has figure 11 with another poor imageof 2150
......
for some drift, from 360/195 functional characteristics
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A22-6943-0_360-195_funChar.pdf
pg.23 shows control panel with space for 2nd cpu control.
past posts that mention dual i-stream (hardware threading) project for
370/195 (which never shipped) which looked like 2nd cpu to software
https://www.garlic.com/~lynn/94.html#38 IBM 370/195
https://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
https://www.garlic.com/~lynn/99.html#73 The Chronology
https://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
https://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
https://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
https://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
https://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
https://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?
https://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2005.html#19 The Soul of Barb's New Machine (was Re: creat)
https://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005p.html#14 Multicores
https://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#29 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#10 IBM 610 workstation computer
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: TCP/IP and connecting z to alternate platforms Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 05 Jul 2006 18:04:55 -0600Roy Hewitt wrote:
escon technology had been laying around pok since the 70s ... but never actually released (for quite some period). one of the austin engineers took the spec, increased the bit rate by approx. 10percent, went to significantly cheaper optical drivers (order of magnitude cheaper). it was released as SLA (serial link adapter) with initial rs/6000. He then wanted to start on 800mbit (full-duplex) version of SLA.
we had been attending various standards meetings in that period ... HiPPI ... 100mbyte/sec parallel copper being pushed by LANL ... effectively standard version of cray channel; SCI pushed by SLAC ... high-speed full-duplex fiber optic for a number of things ... including memory bus (you saw it show up in the sequent 256 processor machine); and FCS pushed by LLNL ... basically a fiber-optic version of some serial copper stuff they had installed.
We convinced the SLA engineer instead of starting work on 800mbit SLA (as upgrade from his 220mbit enhanced escon operation) ... it would be better to devote his effort to FCS standard version ... full-duplex 1gbit fiber. After some discussion, he switched and eventually become the editor for the FCS standards document.
for even more topic drift related to that activity when we were working
on cluster scale-up
https://www.garlic.com/~lynn/95.html#13
in conjunction with ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
i.e. in the half-duplex escon 200mbit/sec time-frame there were early installations of full duplex 1gbit fcs (i.e. 2gbit/sec aggregate ... targeted use both processor-to-device and processor-to-processor including tcp/ip)
Later some POK channel engineers started participating ... and I have a huge pile of archived FCS mailing list discussions where the mainframe channel engineers were attempting to layer the half-duplex copper channel paradigm on top of FCS full duplex operation (similar to what had been done for escon) .... cutting aggregate thruput as well as compromising a lot of the latency compensation that comes with full-duplex operation (big issue in various FCS configurations as well as various SCI operations). with enuf latency in half-duplex operation, the latency can start to dominate over raw bit transfer (starting to minimize the thruput difference between 200mbit/sec and 1gbit/sec).
with respect to enet ... machine i bought last year for home use came standard with 10mb/100mb/1gbit enet ... and the next machine looks like it will likely have 10gbit enet.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: DCSS Newsgroups: bit.listserv.vmesa-l Date: Thu, 06 Jul 2006 00:36:29 -0600kris_buelens wrote:
I had originally done page mapped filesystem for CMS (that I
called PAM for Page Access Method) on cp67
https://www.garlic.com/~lynn/submain.html#mmap
and then redone for VM370. memory mapped objects (from the filesystem) could be mapped inside the virtual address space, "outside" the virtual address space ... and either as shared segments or non-shared segments ... or just plan page images.
I had done a lot of work on location independent code images ... lots
of past postings discussing the difficulty collected here
https://www.garlic.com/~lynn/submain.html#adcon
The standard vm370 system only handled memory mapped objects via named systems ... defined by the NAMESYS macro assembled in DMKSYS. With the appropriate privileges, the current range of pages (defined by NAMESYS) could be "saved". Then contents of a named system could be loaded by an extension to the IPL command.
Some of the work was described in Cambridge Science Center
https://www.garlic.com/~lynn/subtopic.html#545tech
Technical Report No. ZZ20-6002, July 1974, C.S.C VM/370 Extended II,
Virtual Memory Management
... extract from the above
The scope of the modifications to VM/370 currently being implemented
will support both the Named System interface and an PAM interface to a
virtual machine. Recognizing that PAM support is dependent on
extensive CMS filesystem changes, simple extensions to the Named
System interface are being made to make some facilities immediately
available.
The user interface will consist of two new commands (and/or diagnose
instruction codes) to equate/connect and disconnect a virtual address
space span to/from a 'Named System'. No change need be made in the
method of defining named systems, although virtual device address and
some other fields may be ignored. The starting virtual page address
may be any legitimate address, inside or outside of a virtual machine
address limit. Page address assignment is sequential as defined by the
NamedSystem, proceeding from the initial starting page (which may be
supplied either via the command or the named system definition as the
default). Page assignment is terminated after assigning the last page
in the definition, or on encountering a shared segment in the virtual
memory, or after assigning the highest possible page address (end of
virtual memory, 16M). For named systems which contain as part of their
definition shared segment(s), the relative starting page number within
a segment must be the same as the default in the Named System
definition.
... snip ...
The CMS page mapped filesystem and the shared segment changes were
eventually widely released internally on a VM370 release 2 PLC 15
base. One of the locations that made extensive use of the PAM support
w2.15 system was HONE
https://www.garlic.com/~lynn/subtopic.html#hone
... the internal world-wide, vm370-based online system for all sales, marketing and field people.
For HONE, the issue had been that nearly all of the service was delivered as various kinds of APL applications (originally CMS/APL but then upgraded to APL/CMS ... and then VS/APL). In the pre-PAM scenario they had defined a "IPL" named system that included both CMS and APL (with several shared segments defined for APL in addition to the one CMS shared segment and misc. non-shared pages)
The issue (for HONE) was that APL was extremely compute intensive and some of the larger CPU hog applications had been redone in Fortran. The issue was how to invoke the FORTRAN application from the APL environment (called SEQUOIA) and then return to SEQUOIA automagically.
The PAM solution was to define the APL executable on a page mapped
filesystem. Normal "CMS" could be IPL'ed (with the single shared
segment) ...
well almost normal, still need paged mapped filesystem support
. The APL image was loaded from CMS page
mapped filesystem (with all the appropriate shared segments defined
and setup, I added some additional control information to a CMS
executable specifying the segments to be shared). It was now possible
to switch back and forth between APL environment (with shared
segments) and Fortran applications, transparently to the end-user.
PAM offered a huge number of operational and performance advantages ... but the eventual decision was to only release the relative familiar "NAMESYS" CP kernel changes (minor subset of the full page mapped facility) as DCSS ... which (I) originally called DisContiguous Shared Segments ... since the standard product was only going to support definitions outside the standard virtual machine address space ... and the primary justificiation for providing the facility was to support definition of additional shared segment objects.
For VM370 release 3 "DCSS", because the CP kernel changes supporting page mapped filesystem were not picked up, the CMS changes for page mapped filesystem were also not picked up. However, a lot of the other CMS changes that I had done for putting various pieces of CMS into shared segments was picked up ... i.e. the CMS editor and misc. other stuff.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: DCSS Newsgroups: bit.listserv.vmesa-l CC: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> Date: Thu, 06 Jul 2006 11:34:18 -0600misc. more about vm370 release 3 ... from Melinda's history
from her history:
Also in February, 1976, Release 3 of VM/370 became available, including
VMCF and support for 3350s and the new ECPS microcode. Edgar (the
''Display Editing System''), a program product full-screen editor
written by Bob Carroll, also came out in 1976. Edgar was the first
full-screen editor IBM made available to customers, although customers
had previously written and distributed full-screen editors themselves,
and Lynn Wheeler and Ed Hendricks had both written full-screen editors
for 2250s under CMS-67.
... snip ...
it doesn't mention DCSS being part of release 3.
... but it does mention ECPS which I worked on in conjunction with
Endicott. some old detail on studies deciding what to make part of ECPS
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode asssit
except, my quick & dirty recollection was that ECPS support wasn't shipped until Release 3 PLC4
and then, of course, my resource manager release was 11May76. misc.
collected past posts on various aspects of some of the stuff that
shipped in the resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
The same person responsible for VMCF had also redone how shared segments were protected ... which was also part of VM370 release 3. The issue was that the decision to ship the alternative shared segment protection was based on pre-release 3 CMS with only single shared segment with 16 shared pages.
part of the stuff that was included with the DCSS extreme subset of my
virtual memory management
https://www.garlic.com/~lynn/2006m.html#53 DCSS
was additional CMS code for a second shared CMS segment (and 16 more shared pages). The release 3 change for shared segment/page protection drastically increased the overhead per shared page which was offset by enabling the use of VMA for CMS execution. However, the trade-off decision had been based on a single CMS shared segment (and only 16 shared pages). The new shared segment protection (and enabling VMA use for CMS virtual machines) shipped at the same time the additional shared segment facilities shipped (typically doubling the number of shared pages) ... invalidating the original trade-off analysis.
and repeat (from previous post) of collected posts on cms page mapped
filesystem
https://www.garlic.com/~lynn/submain.html#mmap
and other collected posts about effort to make cms executable code
location independent (as part of virtual memory management work)
https://www.garlic.com/~lynn/submain.html#adcon
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The System/360 Model 20 Wasn't As Bad As All That Newsgroups: alt.folklore.computers Date: Fri, 07 Jul 2006 11:23:11 -0600eugene@cse.ucsc.edu (Eugene Miya) writes:
and http traces its history back thru a copy of waterloo's cms script
clone supporting sgml/gml (which was in heavy use at cern)
http://infomesh.net/html/history/early/
which had originally been invented at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
misc. gml, sgml, etc posts
https://www.garlic.com/~lynn/submain.html#sgml
Series/1 saw some large deployment in sensor markets. There is joke about the "standard" operating system for Series/1, RPS ... being a bunch of old os/360 "MFT" developers moving to boca and attempting to re-invent MFT on series/1.
Some physicists at san jose research ... attempting to use Series/1 for various physics applications ... eventually came up with "EDX" as a replacement for RPS (mid-70s?).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: DCSS Newsgroups: bit.listserv.vmesa-l CC: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> Date: Fri, 07 Jul 2006 12:52:54 -0600Jim Bohnsack wrote:
part of the issue was that even tho xt/370 hard disk was single user, it used the xt hard disk which had 110ms access with block at a time ... (plus the latency communicating back&forth between the 370 processor and cp/88 running on the pc processor). The combination of the significantly slower disk (vis-a-vis mainframe) and CMS being quite a bit more disk intensive (vis-a-vis applications developed for the PC environment) ... there was noticeable perception about poor performance.
PAM offers a much better matchup between filesystem operations and
virtual memory paradigm ... resulting in significant efficiencies
(most ibm mainframe operating systems inherited filesystems that had a
significant real memory and real i/o paradigm orientation).
https://www.garlic.com/~lynn/submain.html#mmap
CMS filesystem operations had "diagnose I/O" for pathlength reduction but continued to retain channel program (a "real" memory) orientation. I had done the precursor to CMS "diagnose I/O" as an undergraduate ... demonstrating significant pathlength reduction for CMS I/O intensive operation (which was sort of continuation of a lot of cp67 kernel pathlength operations I was already doing).
The other place that PAM helped was minimizing real storage requirements for filesystem operations ... especially evident in environments with limited real storage configurations. Actually the CP kernel PAM infrastructure could dynamically adapt filesystem operations to the level of real storage contention and/or amount of real storage available. In one high-end (real mainframe) filesystem intensive benchmark, PAM demonstrated something like 300percent increased efficiency in filesystem operations (compared to highly optimized standard CMS EDF filesystem).
XT/370 was significantly real memory contrained for lots of cms operations. I had done various performance analysis on pre-announce XT/370 "washington" boxes and found significant page thrashing. When the information was distributed, I got blamed for delay in XT/370 announce and ship while they retrofitted the hardware with larger real storage.
However, XT/370, being a single user system, saw no benefit from the
extensive segment/page sharing capability available via PAM (especially
compared to the limited capability offered thru the namesys/dcss method).
https://www.garlic.com/~lynn/submain.html#adcon
misc. past washington, xt/at/370 postings:
https://www.garlic.com/~lynn/94.html#42 bloat
https://www.garlic.com/~lynn/96.html#23 Old IBM's
https://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
https://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
https://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2001c.html#89 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001f.html#28 IBM's "VM for the PC" c.1984??
https://www.garlic.com/~lynn/2001i.html#19 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001k.html#24 HP Compaq merger, here we go again.
https://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
https://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
https://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
https://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2003f.html#8 Alpha performance, why?
https://www.garlic.com/~lynn/2003h.html#40 IBM system 370
https://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
https://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004m.html#13 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2005f.html#6 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1
https://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s
https://www.garlic.com/~lynn/2006j.html#36 The Pankian Metaphor