From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Thu, 02 Nov 2006 08:48:28 -0700so just for the fun of it ... here is the thread from 2002 (with correction for finger slip from previous post)
and the thread from last spring:
https://www.garlic.com/~lynn/2006j.html#34 Arpa address
https://www.garlic.com/~lynn/2006j.html#43 virtual memory
https://www.garlic.com/~lynn/2006j.html#45 Arpa address
https://www.garlic.com/~lynn/2006j.html#46 Arpa address
https://www.garlic.com/~lynn/2006j.html#49 Arpa address
https://www.garlic.com/~lynn/2006j.html#50 Arpa address
https://www.garlic.com/~lynn/2006j.html#53 Arpa address
https://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#8 Arpa address
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#31 PDP-1
https://www.garlic.com/~lynn/2006k.html#32 PDP-1
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
https://www.garlic.com/~lynn/2006k.html#42 Arpa address
https://www.garlic.com/~lynn/2006k.html#43 Arpa address
https://www.garlic.com/~lynn/2006k.html#53 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#56 Hey! Keep Your Hands Out Of My Abstraction Layer!
and the current thread:
https://www.garlic.com/~lynn/2006t.html#27 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#31 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#49 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers,comp.lang.fortran Date: Thu, 02 Nov 2006 09:33:12 -0700jmfbahciv writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers Date: Thu, 02 Nov 2006 10:12:38 -0700jmfbahciv writes:
in rapidly changing information/knowledge economy ... skills and knowledge can quickly get stale and/or even obsolete. you now need people that are continually adaptable/adapting.
in some scenarios this means justifying constant/continuing education for participants. this does provide opening for the bean counters to start treating the knowledge/skills analogous to capital equipment. and in turn, they may start to treat people (with the knowledge/skills) as equivalent to their knowledge/skills.
you can then fall into the trap that experience hardly counts at all ... and only the latest and greatest new model is worth anything.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ssh - password control or key control? Newsgroups: comp.os.linux.security Date: Thu, 02 Nov 2006 13:56:55 -0700Ertugrul Soeylemez <never@drwxr-xr-x.org> writes:
standard shared-secret/password requires use of a unique password for every unique/different security domain. another scenario for s/key is that a common pass phrase could be used for all security domains ... if different servers used different salts. however any single server that you deal with could evesdrop and impersonate other servers, acquire salts used by other servers and then use a much lower number of rounds in a s/key impersonation (but that invalidates the assumption that different security domains are secure from each other using s/key ... but still being able to use the same passphrase). countermeasure is that the client retain a lot more state information about previous s/key operations and who they are dealing with. again that invalidates scenario justifications for using s/key.
by the time you have finished with all the countermeasures ... you have pretty much invalidated the scenario justifications for s/key (as opposed to other solutions).
past posts discussion s/key, s/key attacks, and countermeasures
https://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication
https://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ssh - password control or key control? Newsgroups: comp.os.linux.security Date: Thu, 02 Nov 2006 18:11:43 -0700Ertugrul Soeylemez <never@drwxr-xr-x.org> writes:
so instead the host gives you a salt and some registration iteration count ... say 1000. you take you pass phrase and the host specific salt ... and you repeatedly hash it the number of iteration. that gets registered (in lieu of shared-secret).
next time you are at some random place ... you contact the host ... the send back their salt and one less than the current on-file iteration count ... you repeat the process used for registration ... except one less this time. the host gets the iterated hash value and hash it one more time and compare it to the registered value. if it matches ... it is you, they store the latest value you calculated and decrement the iteration count.
this is countermeasure to replay attack ... since the same value is never used twice ... and an evesdropping can't predict the next value ... since hashes don't work (easily) in reverse.
now is s/key supposed to be resistant to both man-in-the-middle attacks as well as replay attacks?
however, i'm playing man-in-the-middle, i intercept the host's transmission of the salt aned the interation count and replace the count with ONE (instead of 999). you iterate only once, and transmit the single iteration. i intercept the response and repeat the iteration the original number of times and send it on. i now leave you alone.
later i impersonate you ... the host is going to transmit the salt and some iteration count ... typically some value much larger than one. I don't have your original pass phrase ... but I can still impersonate you. All i need is the repeated hash iteration value for some iteration much less than what the host is currently using. effectively i have an intermediate hash value interaction ... and all I have to do it resume the hash iteration at the iteration count I intercepted to generate the iterated hash value specified by the host.
the original claim for s/key justification was that it was resistant
to both passive evesdropping (and replay attacks) as well as
(non-passive) man-in-the-middle attacks. however, a (non-passive)
man-in-the-middle attack can substituted a lower iteration count
... as decribed in the previous post
https://www.garlic.com/~lynn/2006u.html#3 ssh - password control or key control?
and the other posts:
https://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication
https://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication
so the countermeasure is to carry around a lot more than memory of single passphrase ... some sort of hardware dongle that keeps track of various state ... like the last iteration count that I saw ... and the next iteration count I'm expecting.
however, that invalidates the original justification assumptions for s/key. futhermore, if i'm going to be carrying around a hardware dongle ... why can't it include more than simple memory ... but actually some processing ... like being able to do a digital signature w/o exposing the private key.
then you could do ssh digital signature authentication ... w/o needing
digital certificates. misc. past post mentioning certificate-less
operation.
https://www.garlic.com/~lynn/subpubkey.html#certless
you could also have radius authentication environment upgraded to do
digital signature authentication. you register a public key (in place
of an iterated hash) ... and then do digital signature verification
(instead of iterated hash verification). again w/o needing digital
certificates. misc. past posts mentioning radius
https://www.garlic.com/~lynn/subpubkey.html#radius
you could also do certificate-less kerberos digital signature
authentication. the original kerberos pk-init draft for digital
signature started out being certificate-less ... just recording puhlic
key (in lieu of password) and doing public key authentication very
much like ssh does its operation. it was only later that certificate
mode of operation was added to the kerberos pk-init draft. misc. past
posts mentioning kerberos and/or pk-init
https://www.garlic.com/~lynn/subpubkey.html#kerberos
as mentioned in some of the original referenced posts on s/key
attacks, my rfc index:
https://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#) in the RFCs listed by section. then
select "OTP" in the Acronym Fastpath section. this brings up
one-time password (OTP)
see also password
4226 2444 2289 2243 1938 1760
selecting any one of the RFC numbers, brings up that RFC's summary
in the lower frame. exp:
2289 S
A One-Time Password System, Haller N., Metz C., Nesser P., Straw M.,
1998/02/26 (25pp) (.txt=56495) (STD-61) (Obsoletes 1938) (Refs 1320,
1321, 1704, 1760, 1825, 1826, 1827) (Ref'ed By 2444, 2808, 3552,
3631, 3748, 3888) (ONE-PASS)
clicking on the ".txt=nnn" field in the RFC summary retrieves that
actual RFC.
See 1.0 Abstract, 2.0 Overview, and 3.0 Introduction in the above RFC for a more detailed description of the operation. However, the overview does say that it protects against external passive attacks and eavesdropper (i.e. replay attacks) ... but does not protect against "active attacks" (i.e. the man-in-the-middle attack I described)
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Are there more stupid people in IT than there used to be? Newsgroups: alt.folklore.computers Date: Thu, 02 Nov 2006 19:44:03 -0700krw <krw@att.bizzzz> writes:
then you have complex rules about password characteristics to make them hard to guess ... which also contributes to making them impossible to remember.
recent post on some aspects of password issues (and mechanism for
being able to use a single, common passphrase for everything)
https://www.garlic.com/~lynn/2006u.html#3 ssh - password control or key control?
https://www.garlic.com/~lynn/2006u.html#4 ssh - password control or key control?
and old bulletin on changing passwords every month and what can or can't
be a password
https://www.garlic.com/~lynn/2001d.html#51 A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#52 A beautiful morning in AFM.
supposedly PIN-debit cards are more secure because they represent
two-factor authentication (card as something you have and pin as
something you know) .... i.e. from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
multi-factor authentication is supposedly more secure assuming that
the different factors have different vulnerabilities .... aka pin is
countermeasure to lost/stolen card. however some study claimed that
something like 30percent of debit cards have PINs written on them.
the issue presumably is the massive use of shared-secret paradigm
... that it becomes impossible for people to remember them all.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Fri, 03 Nov 2006 09:29:03 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
possibly just slight historical interest at where the arpanet scalling limits were. somebody had made satirical comments about arpanet in the late 70s about IMPs requiring 56kbit interconnect because majority of the bandwidth could be taken up by inter-IMP administrative chatter (including all the stuff about figuring out what would be the optimal path for each packet). reaching 100 nodes by jan83 ... would imply that scalling limit was starting to be reached with a lot less than 100 nodes in the late 70s.
later the comment was that part of the transition off of IMPs and arpanet protocol (with the switch-over to internetworking protocol on 1/1/83) was being able to get out from under various of the scalling limitations.
it probably doesn't a whole lot of difference some 25-30 years later whether the arpanet scalling limits were 100 nodes or 250 hosts.
past threads where the load of the inter-IMP administrative chatter
was mentioned
https://www.garlic.com/~lynn/2003c.html#42 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#47 difference between itanium and alpha
https://www.garlic.com/~lynn/2003d.html#60 Bitnet again was: unix
https://www.garlic.com/~lynn/2003d.html#62 ARPAnet again: Bitnet again was: unix
https://www.garlic.com/~lynn/2003h.html#17 Why did TCP become popular ?
https://www.garlic.com/~lynn/2004o.html#53 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2006e.html#35 The Pankian Metaphor
https://www.garlic.com/~lynn/2006j.html#45 Arpa address
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Fri, 03 Nov 2006 10:29:08 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
"IBM" ... especially SNA organization poo-poo'ed all sorts of stuff.
as i've mentioned before we constantly battled with them.
and as i mentioned before ... one of the first "internal network" activities
https://www.garlic.com/~lynn/subnetwork.html#internalnet
was between the science center, on the 4th flr, 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech
and endicott. this was software development activity to add "370" virtual machine support to the cp67 kernel (running on 360/67). this was before 370s were available ... and their were numerous architecture differences between virtual memory hardware on 360/67 and 370 virtual memory architecture. the project required putting a lot of code into the cp67 kernel to recognize the 370 virtual machine operation and a whole lot of simulating 370 hardware characteristics that were different than 360/67.
and there were people that cambridge was working with that were doing arpanet support. for something a little bit different, my rfc index
https://www.garlic.com/~lynn/rfcietff.htm
and select Author in the RFCs listed by section and use browser
find function to get "Winett J." Joel worked on cp67 out at Lincoln
... after cambridge got cp67 up and working, they installed cp67 out
at Lincoln in 1967 (the third cp67 installation was at the university
in jan68, where i was undergraduate).
Winett J.
466 393 183 167 147 110 109
clicking on any RFC number, brings up the RFC summary in the lower frame,
i.e.
109
Level III Server Protocol for the Lincoln Laboratory NIC 360/67
Host, Winett J., 1971/03/24 (12pp)
normally, clicking on the ".txt=nnn" field in the RFC summary will
retrieve the actual RFCs. However, for (old) RFCs that haven't yet
been brought online, there won't be a ".txt=nnn" field.
however, there is also
466
Telnet logger/server for host LL-67, Winett J., 1973/02/27 (8pp) (.txt=17595)
which does have a ".txt=nnn" field.
for misc. old posts about joint cambridge/endicott project adding
370 virtual machine support to cp67 kernel.
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/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/2005d.html#66 Virtual Machine Hardware
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
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Fri, 03 Nov 2006 10:51:41 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
circa 76-78? ... and inexpensive enuf that they were starting to appear on everybody's desk. at the start of this period, there was requirement that to get 3270 on person's desk required vice-president sign-off. we put together a business analysis that the 3yr amortized/depreciated cost of a 3270 terminal was about the same as a business phone (which was available on everybody's desk as matter of course).
are we talking stuff that was ubiquitously available that everybody in a corporation of several hundred thousand people could have one?
and i've frequently contended
https://www.garlic.com/~lynn/subnetwork.html#emulation
it was later that the ibm/pc and 3270 terminal was about the same cost ... so it was a relatively straight-forward transaction to justify an ibm/pc as a 3270 terminal replacement ... where it was possible to have both 3270 terminal emulation and some local desktop computing in a single physical footprint (and same cost) ... that significant market segment uptake contributed to enormously to wide proliferation of the ibm/pc.
as you mentioned in your other post ... are we talking 70s or 80s?
https://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
and is it a commodity thing that can be ubiquitously deployed world-wide that is generally available for nearly everybody in a large corporation.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Fri, 03 Nov 2006 11:42:27 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
part of old "decnews" email (clipped after mention of evans and sutherland) ...
also notice DEC going full steam ahead with federal gov's OSI
replacement for internet
Date: 31 Mar 88 21:43:52 GMT
To: wheeler
Digital Information March 88
The quote of the month comes from Shaku Atre, president of Atre Interna-
tional Consultants, Inc. in Rye, N.Y. In discussing how DEC is trying to
make headway into the "mainframe" market; "People shouldn't be trying to
get into the mainframe market right now. What DEC should be doing is
looking to its micros since there hasn't been anything OVER THE RAINBOW".
DEC - SPECIFIC
______________
y Since DEC continues to have problems with their RA70 disk drive,
they are now offering another option to perspective MicroVAX 3500
customers. Now a customer can buy a MicroVAX 3500 with two RD-54
disk drives instead of the RA-70s. DEC previously offered the option
of RA-81 drives, but those big drives are not practical in many of-
fice environments (Digital Review 3/21/88).
y The number of DEC-compatible manufacturers has dropped from 36 three
years ago to about 6 today. Fewer new firms are getting DEC cpu and
microprocessor chips. Three of the remaining six sell ruggedized
versions of MicroPDPs, MicroVAX I & 2 and PDP-11s primarily to the
military (Digital Review 1/25/88).
y DEC's "announced" DESKTOP STRATEGY is to connect "MS-DOS, VAX-based
UNIX and Macintosh systems to DEC VAX/VMS systems, and to extend
services of Decnet/OSI to IBM OS/2 desktops" (Notice the use of the
words "Decnet/OSI". Is there any doubt about DEC's committed resolve
to OSI?) (Computerworld 1/25/88).
y DEC's NAS (Network Application Support) strategy is designed to sup-
port connectivity of different systems in one environment, in effect
creating a common interface across then (i.e., positioning DEC as
being the central control point for the entire network). NAS will
support the following protocols; DAP (the Data Access Protocol in
Decnet); Microsoft's SMB (Server Messgae Block), Sun's NFS (Network
File System); Apple's AFP file sharing Protocol; Adobe Systems'
Postscript for desktop publishing; DDIF (Digital Document Inter-
change Format), DEC's document processing internal standard; and SQL
for DB use
y DEC now includes DECnet/PCSA (Personal Computer System Architecture)
client licenses with VAXmates free of charge while at the same time
reducing VAXmate prices as much as 37%. The VAXmate originally sold
for $4,250.00 with an additional $500.00 charge for DECnet/PCSA
(Digital Review 3/7/88).
DEC - GENERAL
_____________
y Evans & Sutherland now markets an option for the newly-announced
VAXStation 8000 workstations that make it possible to view 3-D im-
ages on the screen "in stereo". The technology includes a time-
multiplexed liquid crystal shutter fitting over the display,
polarizing the display for both the left and right eye. To see the
effect, one must wear a pair of (you guessed it) glasses with
polarized lenses. The option costs $11,500.00 (Digital Review
3/21/88).
... snip ... top of post, old email index
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Fri, 03 Nov 2006 12:22:42 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
so the (real) flight simulator are probably a couple million? ... mentioned on the e&s wiki page
with respect to the following, i got some followup emails commenting about the "400MIP" number, the actual workstation being only 4-5mips ... and the 400MIP comes from aggregating all the special purpose graphic chips. I would guess that the $100k is on the low-end of prices for E&S machines?
the original email goes on quite a bit more about lots more details
from the original announcement.
Date: 05 Feb 88 18:12:41 GMT
To: wheeler
DEC formally announced the VAXstation 8000. Based on their VAX 8250
and MicroVAX II chip sets and the PS390 from Evans & Sutherland, DEC
has developed one of the fastest workstations (over 400 million 32-bit
arithmetic operations per second) with the highest vector drawing
speed (over 500,000 3D vectors/sec) and highest "apparent" resolution
(8192 x 6912) in the industry. This is DEC's first workstation to
offer hi-performance graphics with full 3D functions. In spite of
this, it is still a single-user workstation which lists at almost
$100,000.00, and is limited to 3 RD54 disk drives (total of 477 MB),
obviously expecting customers to use the VAXstation 8000 as a node in
a VAX Local-Area VAXCluster. I was asked why DEC would use 8250 chips
when the new CMOS MicroVAX 3600 chips are available. From a design
standpoint, the 8250 chip was already complete. From a manufacturing
standpoint, the 8250 chips were already manufactured and probably
sitting in a warehouse somewhere, since sales of 8250s have not been
setting the world on fire. And bottom line: I can see the DEC salesman
now - "We already have a 400 MIP workstation, we certainly do not need
any more horsepower at this point".
The following information was downline loaded from the Digital
Electronic Store about the announcement.
DESCRIPTION
High-Performance, 3D, Realtime Graphics Workstation
The VAXstation 8000 is the newest and most powerful member of
Digital's VAXstation family of high-performance graphic workstations.
Developed jointly by Digital Equipment Corporation and Evans &
Sutherland Corporation, the VAXstation 8000 is a high-performance,
full color workstation that can manipulate complex three-dimensional
graphic objects in realtime.
Evans & Sutherland is widely recognized as a leader in computer
graphics technology. The combination of their expertise in computer
graphics with Digital's system and workstation expertise has resulted
in an industry-leading product -- the VAXstation 8000.
The VAXstation 8000 is designed for applications requiring the highest
levels of computer graphics speed and clarity, such as molecular
modeling, fluid dynamics, mechanical computer-aided engineering and
design, manufacturing engineering, command and control, and computer
animation.
With the VAXstation 8000, Digital now extends the range of the
VAXstation family even further, from the low-cost desktop VAXstation
2000, through the VAXstation II/GPX and VAXstation 3200 and 3500, to
the state-of-the-art VAXstation 8000.
HIGH PERFORMANCE GRAPHICS WITH FULL 3D FEATURES
The VAXstation 8000 is a single-user VAXstation based on the VAX 8250
CPU and a high performance graphics subsystem. It is housed in an
compact, desk-side system enclosure. Digital's first system to offer
high-performance graphics hardware with full 3D functions, the
VAXstation 8000 offers the fastest vector drawing speed in the
industry -- over 500,000 3D vectors per second.
By using unique anti-aliasing technologies, the VAXstation 8000
provides an apparent resolution exceeding 8000 by 6000 pixels.
Unlike other very high performance workstations, which require special
programming and application interfaces, the VAXstation 8000 supports
the X Window System version 11 (on both the VMS and ULTRIX operating
systems) and PHIGS standards. These high-level interfaces are
standards in the workstation market and provide a fully compatible
link to the other members of Digital's VAXstation family. VAXstation
8000 workstation windowing software also includes an extensive 3D
graphics library in addition to the X Window System.
VAX PHIGS, Digital's new hierarchically-oriented 3D and 2D graphics
software language, enables application programmers to take advantage
of the power and speed of the VAXstation 8000 by using this standard
high-level graphics programming language.
... snip ... and resume ...
VAXSTATION FAMILY COMPARISON CHART --------------------------------------------------------------------------- | |VAXstation| VAXstation | VAXstation|VAXstation|VAXstation| | |2000 | II/GPX | 3200 |3500 |8000 | --------------------------------------------------------------------------- | CPU/FPU | MicroVAX | MicroVAX | CVAX | CVAX | VAX 8250 | | | | | | | | | # Planes | 1 or 4 | 4 or 8 | 4 or 8 | 4 or 8 | 58 | | | | | | | | | Monitors | 15 & 19in| 19in | 19in | 19in | 19in | | | Mono & | Mono & | Mono & | Mono & |Color Only| | | Color | Color | Color | Color | | | | | | | | | | Resolution | 1024x864 | 1024x864 | 1024x864 | 1024x864 | 1024x864 | | | | | | |Effective | | | | | | 8192 x 6912| | | | | | | | | Backplane | None | Q-bus | Q-bus | Q-bus | BI bus | | # slots | | 8/12 | 8 | 12 | 6 | | | | | | | | |Expansion slots| None | 2/6 | 0/1 | 4/6 | 1 | | (min/max) | | | | | | | Ethernet | Thinwire | thick wire | thick wire|thick wire|thick wire| | Controller | Standard | Standard | Standard |Standard |Standard | | | | | | | | | Max Memory | 6 MB | 16 MB | 16 MB | 32 MB | 32 MB | | | | | | | | | Disk Cavities | 2 | 1 or 3 | 1 | 2 | 3 | | | | | | | | | Min/Max Hard | 42 Mb/ | 71Mb/ | 71Mb/ | 159Mb/ | 159Mb/ | | Disk Support | 318 Mb | 477 Mb | 318 Mb | 560 Mb | 477Mb | | | | | | | | | System | One year | One year | One year | One year | One year | | Warranty | | | | | | | | | | | | | ---------------------------------------------------------------------------... snip ... top of post, old email index
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SHA-1 code for IBM Mainframe Newsgroups: sci.crypt Date: Fri, 03 Nov 2006 14:57:46 -0700"z" principles of operation
had relatively little to say about the crypto instructions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/2.3.7?SHELF=DZ9ZBK03&DT=20040504121320
other than minor footnote about virtualization of the facility
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/1.3?SHELF=DZ9ZBK03&DT=20040504121320#SPTCRYBLB
in the section about relationship between "z" and esa/390
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/1.3?SHELF=DZ9ZBK03&DT=20040504121320
here is document describing crypto function (performance) on Z machines
http://www-03.ibm.com/systems/z/security/pdf/Web_z9_Crypto_Rel_01202006_X.pdf
and mentions (System z9 message security assist instructions) KLMD-SHA-1 and KLMD-SHA-256
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Are there more stupid people in IT than there used to be? Newsgroups: alt.folklore.computers Date: Fri, 03 Nov 2006 15:55:52 -0700greymaus writes:
there has been some issues with the change over to debit cards that can be used both with or w/o a pin ... where even if you always used the debit card w/pin ... if it is lost/stolen ... others would be able to use it w/o pin.
there is separate issue with chip&pin deployments ... where attacker
could skim the chip authentication information ... potentially using
some nearly identical processes that had been used to skim magstripe
information. the chip authentication information is then injected into
a counterfeit card. in the chip&pin deployments, after the chip had
authenticated to the terminal, the terminal then asked the chip if the
correct pin had been entered. the counterfeit cards were programmed to
always repond YES (regardless of the pin entered). this gave rise to
the label yes card ... some number of past posts discussing yes
card vulnerability:
https://www.garlic.com/~lynn/subintegrity.html#yescard
aka once the chip authentication information had been skimmed ... it wasn't even necessary to find out the correct pin for use with a yes card
From: lynn@garlic.com Subject: Year-end computer bug could ground Shuttle Date: Tue, 07 Nov 2006 05:18:59 -0800 Newsgroups: alt.folklore.computersYear-end computer bug could ground Shuttle
you may have read it first here ... postings that include email from
1984
https://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
https://www.garlic.com/~lynn/2003p.html#21 Sun researchers: Computers do bad math ;)
https://www.garlic.com/~lynn/2006r.html#16 Was FORTRAN buggy?
From: lynn@garlic.com Subject: Re: Year-end computer bug could ground Shuttle Date: Tue, 07 Nov 2006 16:17:55 -0800 Newsgroups: alt.folklore.computersre:
Al Balmer wrote:
Ah - here's a better article:
http://www.newscientistspace.com/article/dn10459-y2klike-fears-create-shuttle-scheduling-crunch.html
my reference email from
1984
is about custom implementation where one
box rolls over on day 399 and the other box rolls over on day
400. there have been some articles about pieces of shuttle program
have (re)done various stuff with COTS ... which one would expect to roll
over on jan. 1st. the articles seem to imply if they are flying at the
closest in roll over date (which ever components that may be) ... they
would have to temporary "reboot" all boxes ... as if a brand new
mission had started.
From: lynn@garlic.com Subject: Re: To RISC or not to RISC Date: Wed, 08 Nov 2006 08:18:49 -0800 Newsgroups: alt.lang.asm,comp.archRostyslaw J. Lewyckyj wrote:
given constrained skills and resources ... recoding much more complex logic in assembler represents relatively marginal (performance) improvement than recoding much more complex logic in HLL ... but at a significant increase in effort (in some cases HLL providing off-the-shelf library functions that just aren't found in the assembler environment)
one could even make the case that the theoritical recoding in assembler (of the examples given) would never happen because of the significant additional of resources required (the old standby ... theoretically there is no difference between theory and practice ... but in practice there is).
long ago and far away (spring 76) i released the kernel resource manager that was all written in assembler. for some operations i needed triple word integer math precision (96bit) and it was enormous pain to code it from scratch using 32bit assembler instructions.
part of pl.8 stuff from the mid-70s with the original 801/risc activity
https://www.garlic.com/~lynn/subtopic.html#801
had an underlying theme that doing operating system stuff in higher
level language made a lot of stuff practical that just wouldn't have
happened if done in assembler. I think that the multics
implementation in pli had a similar theme ... i was at the science
center doing a lot of kernel stuff in assembler ... which was on 4th
flr of 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech
while multics was on the 5th flr (of the same bldg).
https://www.multicians.org/multics.html
a lot of the items stated as benefits for HLL ... can be turned around and the lack of those benefits in assembler can contribute to making various assembler activities "practrically" impossible.
by analogy, this can be extended to the lack of appropriate
methodologies and paradigms in any language ... can make various
efforts "practically" impossible ... i.e. this could be applicable to
the thread about why so little parallelism. i've written quite a bit
of "parallel" code in the form of modifying kernel to support
multiprocessor operation
https://www.garlic.com/~lynn/subtopic.html#smp
and
https://www.garlic.com/~lynn/submain.html#bounce
it is not theoretically impossible to write parallel code in assembler ... but it apparently is practically impossible to write lots of parallel code in nearly all of the current, commoningly used languages
From: lynn@garlic.com Subject: Re: IA64 and emulator performance Date: Wed, 08 Nov 2006 09:07:58 -0800 Newsgroups: comp.archranjit_mathews@yahoo.com wrote:
which is available on a number of platforms. in some sense, there are some similarities between the current generations of mainframe emulators and the majority of the ("real") mainframe implementations in the 60s, 70s, and thru the 80s ... i.e. microcode engines where the 360/370/390/etc. implementation was microcode running on the microcode engines.
in fact, one of the early targets for 801/risc processors was a
project to try and consolidate the large variety of internal
microprocessors.
https://www.garlic.com/~lynn/subtopic.html#801
collected past posts mentioning the large variety of internal
microproprocessors and low-level microcoding
https://www.garlic.com/~lynn/submain.html#mcode
misc. past posts mentioning hercules
https://www.garlic.com/~lynn/2001n.html#22 Hercules, OCO, and IBM missing a great opportunity
https://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
https://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
https://www.garlic.com/~lynn/2002i.html#31 : Re: AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004g.html#19 HERCULES
https://www.garlic.com/~lynn/2004g.html#29 [IBM-MAIN] HERCULES
https://www.garlic.com/~lynn/2004g.html#48 Hercules
https://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#1 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#19 Hercules 3.04 announcement
From: lynn@garlic.com Subject: Re: Why so little parallelism? Date: Wed, 08 Nov 2006 12:43:09 -0800 Newsgroups: comp.archEugene Miya wrote:
minor note ... except finishing off rfc 1044 support in mainframe
product (18 years ago),
https://www.garlic.com/~lynn/subnetwork.html#1044
i haven't done any mainframe work in 20 yrs.
the following reference was a long ways from any mainframe world and
this was started nearly 20 years ago and this particular reference is
to nearly 15 yrs ago related to scale-up work for ha/cmp project
https://www.garlic.com/~lynn/95.html#13
enormous amounts of the high-speed data transport project
done in the early and mid-80s ...
https://www.garlic.com/~lynn/subnetwork.html#hsdt
referenced here .... had little to do with mainframes
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders
a lot of it was heavily oriented towards 801/risc
https://www.garlic.com/~lynn/subtopic.html#801
part of the early issue in the ha/cmp cluster scale-up
https://www.garlic.com/~lynn/subtopic.html#hacmp
was that rios had no provisions for cache coherency used in smp parallel environment ... as a result we had to make design trade-offs for message passing parallelism in cluster scale-up environments ... while not precluding being able to also support cache consistent parallelism.
since none of this was remotely mainframe oriented ... i guess you must be referring to the mainframe trench created with the invention of the compare&swap instruction and its deployment on 370 machines in the early 70s ... which would then place all subsequent hardware designs that implemented instruction and cache coherency semantics similar to that of compare&swap semantics ... in the same trench???
From: lynn@garlic.com Subject: Re: Why so little parallelism? Date: Thu, 09 Nov 2006 12:08:18 -0800 Newsgroups: comp.archDel Cecchi wrote:
and for even more fun ... random postings from this year mentioning
misc disk history, disk design, disk enginneering, modeling air-bearing
effect for design of original thin-film floating heads, etc
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006i.html#27 Really BIG disk platters?
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#57 virtual memory
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#18 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#21 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#30 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#31 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#33 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006s.html#23 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#45 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
From: lynn@garlic.com Date: Thurs, Nov 9 2006 7:13 pm Subject: Re: Why so little parallelism? Newsgroups: comp.archJan Vorbrüggen wrote:
And the following for a lot more drift (although also mentioning datavault) ....
some background on the Almaden reference can be found here:
http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml
which traces its history to CMSBACK which i had originally done more
than ten years earlier:
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
https://www.garlic.com/~lynn/2006t.html#24 CMSBACK
we had funded part of the Unitree product work from our ha/cmp project
(aka reference to rft/lcmp):
https://www.garlic.com/~lynn/subtopic.html#hacmp
Date: Fri, 8 Mar 91 17:55:16 EST
From: wheeler
Subject: LANL Unitree meeting
We just got back from a joint LANL/LLNL/Discos/IBM meeting at Los
Alamos (we also had an earlier Unitree/IBM/ACSC meeting on Tuesday in
LA).
Partly purely as coincidence, on the flight down, I ran into xxxxxx
with two of his people on their way to Tucson to discuss the Almaden
workstation/pc backup/archive facility. It seems to be a coincidence
since one of the things brought up at the LANL meeting was a vendor
that has had a similar product (with a MVS backend) on the market. The
******* comment was that this vendor now has the product ported to an
Unitree (server) backend. Functions appear to be identical, providing
client registration with archive/backup policy requests that are then
scheduled (potentially offshift on a regular basis) ... with the
server "pulling" the files ... not the client pushing the files.
We discussed the RFT/LCMP enhancements for concurrent Unitree
operation on multiple server platforms (sharing same physical disk
drives). Also repeated some of the discussion that we had a couple
weeks ago with ******* research about some possible near-term
technology enhancements. Also has some discussion about the ANT stuff
that ****** did for Univ. of Mich. IFS system and the discussions that
have occurred regarding all of their stuff on Unitree/RFTLCMP platform.
Including the advantages of having NFS, AFS3, AFS4 (and possibly other
protocols) all pointing to the SAME IEEE MSS-2 bitmap files. This
(along with automatic Unitree archiving facility) is also what many of
the other major customers are asking for with respect to Andrew/OSF.
We were able to come away pretty much addressing all of their
requirements except for a near-term tape backup for their connection
machine. The HIPPI D2 & tape-array products aren't yet on the
market ... so they have an interim solution that would utilize four
3490s driven in parallel as a logical tape array. Because of the
interim nature of the requirement, it didn't seem to be worthwhile to
address it with software in the RS/6000 (either via a RS/6000 adapter
card emulating 370 control unit or by one of the NSC A51x remote
device adapters ... its been going on eight years since I've done much
NSC A51x remote device programming).
The connection machine is writing data to the data vault (a box with
32-drive disk data array, 7 ECC drives, and 3 spare drives that are
electronically switchable into the configuration). The requirement is
to periodically back data from the data vault (out over the HIPPI
interface) to tape (files that are currently on the order of 10s of
gigabytes, but growing eventually to potentially terabytes).
The proposed solution is that LANL go ahead and write a 3490 parallel
tape driver for MVS that is a Unitree agent. Unitree (running on
rs/6000) would control all standard operations ... but there would be
a new feature added allowing data & control paths to be separated
... with a modified "high-performance" Unitree FTP program running on
the CM's SUN machine (CM external interfaces are controlled thru Sun
machines). It would talk to the Unitree RS/6000 server code, but
requesting parallel tape migration. The RS/6000 would notify the MVS
parallel tape agent ... and there would be a direct HIPPI data path
set up between the data vault to the MVS/3090 for actually moving the
data. In effect, the 3090/MVS system would be operating as a tape
controller for the Unitree/RS6000 system.
As another aside, ********* commented that Convex has given all of
their Unitree high-performance enhancements back to ******* for
incorporation into the standard product.
And for one of my favorite subjects ... that I also brought up when we
were dealing with the NCAR/Mesa possibilities ... was the significant
advantages of using a Semantic Net in the Unitree Nameserver (i.e.
effectively the function that implements the file directory).
******** and some of the other people wanted to specifically follow-up
on that. I related one of the things that we had looked at in the
NCAR/Mesa timeframe regarding all the NASA tapes containing images of
the back side of the moon ... and the difficulty in being able to find
any specific image &/or images that fit specific criteria.
... snip ... top of post, old email index
From: lynn@garlic.com Subject: Re: Why so little parallelism? Date: Thu, 09 Nov 2006 17:31:10 -0800 Newsgroups: comp.archEugene Miya wrote:
it wasn't a "camp" thing ... there was proposal from several of the NSF funded supercomputing centers (CNSF, NCSA, PSC, SDSC) for NSF funding for evaluation and selection of a common mass storage archive solution .... which strongly leaned towards Unitree on Convex platform. Just another one of those things that was happening in the transition from strictly proprietary software to more open environment.
We got pulled into situation to push unitree on rs6000 as an alternative solution.
From: lynn@garlic.com Subject: Re: Why so little parallelism? Date: Thu, 09 Nov 2006 17:43:10 -0800 Newsgroups: comp.archEugene Miya wrote:
I did some of the original implementation (some 10+ years earlier than
the referenced email) ... about the same time that i also worked on
some of the original relational/sql implementation.
https://www.garlic.com/~lynn/submain.html#systemr
i've since gone thru a couple complete rewrites from scratch.
https://www.garlic.com/~lynn/index.html
it is what i use for my rfc index
https://www.garlic.com/~lynn/rfcietff.htm
and the merged taxonomies and glossaries
https://www.garlic.com/~lynn/index.html#glosnote
From: lynn@garlic.com Subject: Re: AOS: The next big thing in data storage Date: Fri, 10 Nov 2006 04:54:44 -0800 Newsgroups: alt.folklore.computersTina wrote:
Former Federal Reserve head riffs on Sarbanes-Oxley
http://www.infoworld.com/article/06/11/09/HNfrbripssarbox_1.html
Alan Greenspan riffs on Sarbanes-Oxley
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9004942&intsrc=hm_list
Sarbanes-Oxley Compliance
http://www.eweek.com/category2/0,1874,1573753,00.asp
and i've been doing my own riff on sox for over a year.
https://www.garlic.com/~lynn/2006.html#12a sox, auditing, finding improprieties
https://www.garlic.com/~lynn/aadsm25.htm#43 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
and then there is basel II and being able to do quantitative (in the
original draft also significant qualitative) documentation .... for
setting risk adjusted capital. misc. refs
https://www.garlic.com/~lynn/aadsm10.htm#smallpay3 Small/Secure Payment Business Models
https://www.garlic.com/~lynn/aadsm10.htm#cfppki19 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm14.htm#50 E-banking is board-level Issue, Says Basel Committee
https://www.garlic.com/~lynn/aadsm14.htm#52 Committee calls for better e-banking security management
https://www.garlic.com/~lynn/aadsm16.htm#7 The Digital Insider: Backdoor Trojans ... fyi
https://www.garlic.com/~lynn/aadsm21.htm#3 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you get when you don't do FC
From: lynn@garlic.com Subject: Re: AOS: The next big thing in data storage Date: Fri, 10 Nov 2006 06:21:53 -0800 Newsgroups: alt.folklore.computersBrian Inglis wrote:
... and as mentioned in the above ... aos actually started out as the palo alto acis group doing a port of bsd to 370 ... i helped them find a 370 C compiler for the port. when the port was retarged from 370 to romp ... they kept the same C compiler (but had a different backend implemented)
From: lynn@garlic.com Subject: Re: When did computers start being EVIL??? Date: Fri, 10 Nov 2006 07:09:24 -0800 Newsgroups: alt.folklore.computers,alt.evil,alt.recipes.babiesTim Shoppa wrote:
a couple past posts mentioning wargames
https://www.garlic.com/~lynn/2003g.html#56 OT What movies have taught us about Computers
https://www.garlic.com/~lynn/2003g.html#57 OT What movies have taught us about Computers
https://www.garlic.com/~lynn/2006m.html#38 Computers in the movies
including mention of the scene where they were taking ferry out to some island ... and what that ferry is doing now.
in the past, we worked with some of the people that were responsible
for pulling off the FAA 60's atc system. misc. past posts mentioning
atc and/or 9020 systems
https://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001i.html#14 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
https://www.garlic.com/~lynn/2003m.html#4 IBM Manuals from the 1940's and 1950's
https://www.garlic.com/~lynn/2004.html#7 Dyadic
https://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
https://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005m.html#9 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2006q.html#54 Was FORTRAN buggy?
From: lynn@garlic.com Subject: Re: Universal constants: world wars Date: Fri, 10 Nov 2006 07:26:46 -0800 Newsgroups: alt.folklore.computersEugene Miya wrote:
Collapsible business lessons
http://www.issurvivor.com/
from above:
Collapse: How Societies Choose to Fail or Succeed analyzes five ancient
societies that imploded horribly, attempting to find insights useful
for the modern, increasingly interconnected world.
....
Businesses being societies too, I thought it would be worthwhile trying
to apply Diamond's conclusions to the world of business (did you wonder
how I was going to justify the tax write-off for this book?
... snip ...
note that Boyd touched on similar parallels in his briefings
https://www.garlic.com/~lynn/subboyd.html#boyd
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Assembler question Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 11 Nov 2006 16:07:58 -0700Alan_Altmark@ibm-main.lst (Alan Altmark) writes:
some email exchange with the RED author when i was trying to get
Endicott to release RED (in lieu of XEDIT). Later the Endicott
position was that it was the RED author's fault that he had
implemented RED before XEDIT and had put more features in RED than
were eventually implemented in XEDIT ... and therefore it was the
fault of the RED author that he had done something so bad ... it was
his duty to fixup XEDIT with the additional features that he had put
in RED.
Date: 03/11/80 08:52:58
From: wheeler
To: red author
I have a feeling that I may have done you a disservice. When I was in
Endicott last May I told them they ought to be putting out RED instead
of XEDIT. I went into a lot of detail about how it was faster, more
function, better, etc. (although other people may have also) and left
them with documentation. XEDIT is now announced and is going
out. Since last May they have gone over the RED documents and have
added several of the items to XEDIT but it still isn't as good (except
maybe in the feature of being able to use EXEC2 which would be common
between edit environment and others).
When I talked to several people from Endicott at the internal meeting
and Share, they sort of acknowledged the above. My suggestion that
they scrap XEDIT and put out RED was received very lightly. (ignoring
the fact that they should have put out RED instead of XEDIT) their
feeling is that it is the duty of the RED author to enhance XEDIT to
include all RED features. That really floored me, Endicott seems to
have some perverted view of reality. It isn't their fault they put out
XEDIT instead of RED, but it is your fault that you put in more
features in RED than were in XEDIT.
... snip ... top of post, old email index
Date: 03/12/80 09:26:53
From: wheeler
To: red author
well, it is obviously your fault that RED has more function than
XEDIT. Since you are responsible for the problem then you should be
the one to rectify it.
... snip ... top of post, old email index
... and then from earlier, not functional, just performance numbers
*EDIT* is the old, cms standby; the first cp67/cms implementation was
strictly disk-to-disk work files ... but fairly quickly was enhanced
to take advantage of virtual memory for its operation.
Date: 06/06/79 10:25:14
From: wheeler
Those are interesting figures on editors ... but I figured that a
better measure of "internal peformance" would involve something more
strenuous than "bottom". So I did a "bottom" by doing a "c / / / * *"
with all seven editors, with the following results:
EDIT CMSLIB MACLIB S 2.53/2.81 RED CMSLIB MACLIB S (NODEF) 2.91/3.12 ZED CMSLIB MACLIB S 5.83/6.52 EDGAR CMSLIB MACLIB S 5.96/6.45 SPF CMSLIB MACLIB S ( WHOLE ) 6.66/7.52 XEDIT CMSLIB MACLIB S 14.05/14.88 NED CMSLIB MACLIB S 15.70/16.52... snip ... top of post, old email index
recent post mentioning RED and another email
https://www.garlic.com/~lynn/2006n.html#55 The very first text editor
i use to do my own internal system release/distribution with lots of
fixes and enhancements ... bldgs 14&15 refers to the disk engineering
lab and disk product test lab ... misc. postings here
https://www.garlic.com/~lynn/subtopic.html#disk
Date: 04/29/80 14:03:23
From: wheeler
To: world-wide distribution list
current schedule is to ship PLC/LTR 8 CP system next Monday. All (new)
bugs have been identified and fixed. System is currently running in
building 14&15. It is scheduled to be brought up here either tomorrow
or the next day. CP changes includes some conversion to CSL20 & a
number of updates from the current STL release 6 updates. CMS will
include RED 3.4 & XEDIT.
It would be helpful if all locations outside of the San Jose area ship
me a tape and mailing label if possible.
... snip ... top of post, old email index
and one of the internal locations responding to request for forwarding
tape for SJR/VM distribution
Date: 05/01/80 12:13:41
From: RCHVM1 (somebody in rochester)
To: wheeler
Lynn - I just sent you a scratch tape today for CP6 - Thanks
... snip ... top of post, old email index
and for some total different drift on the subject of CMSBACK
https://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
https://www.garlic.com/~lynn/2006u.html#21 Why so little parallelism?
... and
https://www.garlic.com/~lynn/2006t.html#24 CMSBACK
which then brings up this recent thread x-posted to alt.lang.asm & comp.arch
https://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#48 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#15 To RISC or not to RISC
The following is part of an exchange with the author of RED regarding
creation of a RED shared module (read-only protected shared segment
executable image) on "PAM" disk.
Date: 11/03/78 13:25:59
To: wheeler
From: red author
Lynn,
I got your script file (i haven't read it yet). I couldn't follow
your msg about 64K blocks & what I could do with them. Please
amplify. I have done nothing toward making RED sharable, as it seems
to be a big job.
... snip ... top of post, old email index
I had original started on CMS paged mapped filesystem and shared segment
support with cp67/cms.
https://www.garlic.com/~lynn/submain.html#mmap
A very small subset of this function was picked up and released in
vm370 release 3 called DCSS. a few recent posts mentioning DCSS
https://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006m.html#53 DCSS
https://www.garlic.com/~lynn/2006m.html#54 DCSS
https://www.garlic.com/~lynn/2006m.html#56 DCSS
https://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
I had made small extension to control information generated by the cms
"GENMOD" command to include shared segment specifications. This was
automatically used by the cms "LOADMOD" function (when loading a cms
executable image) to map any specified shared segments. Aa part of the
original CMS shared segment changes, I had modified the standard cms
editor and several other routines to be able to execute in read-only
protected shared segment (this changes were included in some of those
picked up as part of DCSS release). This particular exchange with the
author of the RED editor was concerning modifying the RED executable
image to reside in a read-only protected shared segment. old discussion
changes to genmod/loadmod:
https://www.garlic.com/~lynn/2006o.html#53 The Fate of VM - was: Re: Baby MVS???
various collected posts about modifying and/or creating code for
residing in shared segments ... including issues with os/360
convention relocatable address constants creating difficulty for
allowing the same shared segment image to reside concurrently at
different virtual addresses in different virtual address spaces
(i.e. when i was modifying code to reside in read-only protected
shared segment, i also attempted to removed the execution location
dependencies ... most freqently involving os/360 convention
relocatable address constants)
https://www.garlic.com/~lynn/submain.html#adcon
A feature that RED editor added early was support for automatically generating sources changes as CMS update files. When I was an undergraduate starting out working on cp67/cms, i was making an large number of source code changes as CMS update files. The CMS update command convention was similar to IEBUPDATE, "./" replace, insert, delete, etc, functions ... based on sequence numbers in the original source file. However, the "new" source had to have the sequence numbers manually keyed in cols. 73-80. This became quite tedious, so i created the preprocessor convetion with $ field on the update "./" control statements. I wrote a preprocessor to the CMS update command that preprocessed a source update, stripped off the $ and generated a temporary update working file with all the new source statements with the sequence numbers automatically added.
The $ convention was later adopted by the multi-level source
update process that was created during the l/h/i effort ... joint
effort between science center and endicott to had 370 virtual
machine support co cp67 kernel (running on real 360/67). recent
posting about that effort:
https://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
eventually the $ field support was merged into the standard CMS
update command (rather than being done separately by pre-processing
function) ... and still later, CMS editors provided direct support for
both applying multi-level updates as part of edit invokation and
generating update files from source changes. misc. past posts discussing
the $ field convention:
https://www.garlic.com/~lynn/2002n.html#39 CMS update
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
https://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2006n.html#45 sorting
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why so little parallelism? Newsgroups: comp.arch Date: Sun, 12 Nov 2006 00:27:30 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
i didn't mean to imply that there weren't a number of solutions and that
customers might be choosing particular solutions ... and then the
customers might be have preferrences for one solution or another
("camp" if you will) ... aka
https://www.garlic.com/~lynn/2006u.html#20 Why so little parallelism?
where:
Eugene Miya wrote:
This implies Convex was in UniTree's camp. Convex had their very
storage manager CSM which was not a bad system but never caught on.
Too bad it never got along past 2.0.
i was trying to distinguish between the customers may have wanted
something on a convex platform ... vis-a-vis convex taking a position
possibly with respect to what their customers should want. i wouldn't
view convex cooperating with their customers as to a particular
solution necessarily meaning that it was a "camp"/membership thing for
convex (and didn't mean to imply anything at all about whether or
not it might or might not be a "camp" thing for the customers).
for other drift from
https://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
....
Date: Thu Apr 16 11:11:41 1992
From: wheeler
Subject: Re: Archiving on large systems
Unitree(/lincs) is basically one of the four that all evolved around
the same time. The other three being CFS(LLNL), Mesa(NCAR), and
NAStore .... reference:
Newsgroups: comp.unix.large
Date: 15 Apr 92 19:18:07 GMT
As it was mentioned in an earlier posting, let me add a couple of
words on NAStore.
NAStore is a system to provide a Unix based, network connected file
system with the appearence of unlimited storage capacity. The system
was designed and developed at NASA Ames Research Center for the
Numerical Aerodynamic Simulation program. The goal was to provide
seemingly unlimited file space via transparent archival (or migration)
of files to removable media (3480 tapes) in both robotic and manual
handlers. Supported files sizes exceed the 2 gigabyte limit on most
systems. Archived data is restored when accessed by the user with
each byte being available as soon as it is restored rather than having
to wait for the whole file as is the case with other archival systems.
The NAStore system has been used here for 3 years and is under ongoing
development. It is based upon Amdahl's UTS and runs upon an Amdahl
5880. We have 200 gigabytes of on-line disk and 6 terabytes of
robotic tape.
If your care for more information, let me suggest the following reading:
1989 Winter Usenix Conference Proceedings, see the article on RASH
the last IEEE Mass Storage Symposium proceedings
If you are still interested, contact Dave Tweten, e-mail tweten@nas.nasa.gov
... snip ... top of post, old email index
past posts mentioning one or more of the four
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/2001f.html#66 commodity storage servers
https://www.garlic.com/~lynn/2002.html#10 index searching
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
https://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003i.html#53 A Dark Day
https://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
https://www.garlic.com/~lynn/2004g.html#26 network history
https://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
https://www.garlic.com/~lynn/2005e.html#12 Device and channel
https://www.garlic.com/~lynn/2005e.html#15 Device and channel
https://www.garlic.com/~lynn/2005e.html#16 Device and channel
https://www.garlic.com/~lynn/2005e.html#19 Device and channel
https://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
https://www.garlic.com/~lynn/2006t.html#37 Are there more stupid people in IT than there used to be?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Assembler question Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 12 Nov 2006 09:14:11 -0700Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
one might conjecture that it might have something to do with internal wars that frequently verged on the religious and being able of all parties to escalate to a higher authority.
EDGAR was the first cms fullscreen editor (that made it out as a product) ... other than the minor enhancements to the original cms (line) editor. there then were/came a whole slew of internal editors that had all sorts of fullscreen features and scripting/macro capabilities. then came the wars to see which one would be announced as the (corporate) product ... with the EDGAR faction attempting to protect their initial position ... and many of the others all jockying for permission to be announced. Once one had achieved that permission ... then there was constant ongoing battles to stifle any competition.
To some extent, similar wars went on with regard to communication and
networking activity ... as mentioned in various of my comments about
the later days of terminal emulation
https://www.garlic.com/~lynn/subnetwork.html#emulation
and the SAA related activity ... with us on the other end with 3-tier
architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier
and hsdt activity
https://www.garlic.com/~lynn/subnetwork.html#hsdt
and even my wife's much earlier efforts with AWP39 and her other
peer-to-peer stuff when she was in POK in charge of loosely-coupled
architecture
https://www.garlic.com/~lynn/submain.html#shareddata
there was also quite a bit of it between the established ("60s")
databases and the original relational/sql effort ... getting it out
and announced as a product
https://www.garlic.com/~lynn/submain.html#systemr
even the virtual machine effort, cp67 and vm370 (including cms), had a nearly constant cloud hanging over them of being terminated because of being declared "non-strategic" (and competitive) by the "mainstream" operating system. i've mentioned before the vm370 development group being periodically told they had made their last product shipment and their last release. At one point, the whole vm370 product group location (in burlington mall) was shutdown, and everybody told that they had to move to POK where everybody would be supporting mvs/xa development (and one more time, there would be no more virtual machine operating system).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch Date: Sun, 12 Nov 2006 09:26:14 -0700"Dunny" <paul.dunn4@ntlworld.com> writes:
we had done something earlier in 1975 with ecps ... were major
pathlengths in the (virtual machine) kernel (6000 bytes of code
accounting for something like 70percent of kernel pathlength) was
(statically) recoded in native microcode getting a 10:1 performance
improvement. a few old posts mentioning ecps
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
https://www.garlic.com/~lynn/2003f.html#43 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003f.html#47 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003f.html#52 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003f.html#54 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why so little parallelism? Newsgroups: comp.arch Date: Sun, 12 Nov 2006 09:55:16 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
the many times descendent of CMSBACK that i originally implemented and
deployed in the late 70s ... also referenced here
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006t.html#24 CMSBACK
http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml
has multiple levels that don't need to touch tape at all.
some general collected posts mentioning that activity
https://www.garlic.com/~lynn/submain.html#backup
and product page
http://www-306.ibm.com/software/tivoli/products/storage-mgr/
part of the tape issue is packaging/density/convenience/cost ... for some things datacenter and transmission costs have been reduced to the point where it is cost effective to have a hot remote/redundant sites ... as opposed to disaster/recovery dependent on offsite backup tapes.
when we were doing our ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
we coined the term disaster survivability and geographic survivability
for concurrent operation of remote/redundant sites.
https://www.garlic.com/~lynn/submain.html#available
part of this had been outlined by my wife when she had done
Peer-Coupled Shared Data architecture when she served her stint in pok
in charge of loosely-coupled architecture.
https://www.garlic.com/~lynn/submain.html#shareddata
at that time, she saw very little uptake ... except for the IMS (database) group for IMS hot standby. not that long ago, we were talking to one of the major financial transaction operations and they attributed their 100percent availability over a span of years to
• automated operator
• ims hot standby
where they had triple redundant/remote dataprocessing sites.
misc. past posts mentioning ims hot standby
https://www.garlic.com/~lynn/98.html#35a Drive letters
https://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
https://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
https://www.garlic.com/~lynn/99.html#77 Are mainframes relevant ??
https://www.garlic.com/~lynn/99.html#92 MVS vs HASP vs JES (was 2821)
https://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
https://www.garlic.com/~lynn/2000.html#13 Computer of the century
https://www.garlic.com/~lynn/2000f.html#54 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2002o.html#14 Home mainframes
https://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
https://www.garlic.com/~lynn/2003l.html#11 how long does (or did) it take to boot a timesharing system?
https://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
https://www.garlic.com/~lynn/2004q.html#75 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#9 intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
https://www.garlic.com/~lynn/2005n.html#7 54 Processors?
https://www.garlic.com/~lynn/2006q.html#26 garlic.com
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch Date: Sun, 12 Nov 2006 13:30:18 -0700"mike" <mike@mike.net> writes:
it was topic drift ... i didn't claim that the final move of as/400 from cisc to risc was like jit ... i claimed jit was like some of the stuff that went on for fort knox in the 1980 time-frame ... and that parenthetically, the (much later) conversion of as/400 from cisc to risc met some of the original objectives of fort knox ... i.e. moving to risc based processor (but I didn't claim that the movement of as/400 from cisc to risc used any of the earlier jit-like stuff that went on in the 1980 fort knox time-frame ... which were much more specifically related to 360/370).
however, in the 1980 time-frame for fort knox, the rochester microprocessor was one of the targets for switch-over to 801 (even if none of the jit-related activity may have been involved in any of the possible conversion of rochester microprocessor to 801).
it wouldn't have been directly applicable to as/400 in any case,
since as/400 wasn't introduced until 1988, long after fort knox
effort had been killed ... wiki entry for as/400
https://en.wikipedia.org/wiki/AS/400
references mentioning that fort knox eventually at least partially
succeeded with the as/400 risc
http://www.itjungle.com/tfh/tfh120709-story08.html
and more detail here about fort knox objectives (including more
than rochester microprocessors)
http://www.riteapproach.com/book/ibm.html
for misc. other background ... i had been doing some work with the los gatos vlsi lab (bldg. 29) in the fort knox time-frame. they were doing a 32-bit 801 (blue iliad) design (that never shipped). they also had two people doing a 370 pascal compiler for use in developing various chip design tools (and which eventually shipped first as the pascal iup ... and then as the vs/pascal compiler).
i had also written a pli program in the early 70s that analyzed (360/370) assembler program listings ... creating high level abstractions of the instructions, recreating control flow, register usage ... looking for use before set type scenarios ... and generated a high level psuedo code representation of the assembler program.
some of the people looking at possibly jit-type operations applied to
370 code (using 801 for the follow-on for 4331/4341) contacted me about
my program ... possibly enabling them to use some of it for what they
were doing (at the time, the primary 801 programming language was
pl.8, a subset of pli). recent posts discussing some of this with
regard to 360/370
https://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written?
https://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
and for the other drift about the 370 pascal compiler, one of the people in bldg. 29 doing the 370 pascal compiler left and became head of software at MIPs. after MIPs was bought by SGI, he shows up as general manager of the SUN business unit that includes JAVA.
the article here
http://www.riteapproach.com/book/ibm.html
even makes reference to 370 emulation on intel platforms ... raised
in this thread:
https://www.garlic.com/~lynn/2006u.html#16 IA64 and emulator performance
... some of which, I believe may have also implemented JIT technology.
for other drift ... doing search engine for as/400 and fort knox also
turns up this article
http://www.cbronline.com/article_cbr.asp?guid=2C99DD1B-6812-46AF-AF95-B6D7E728376A
from above:
The failed Fort Knox project of the early 1980s, meanwhile,
attempted to merge IBM's low-end mainframe and midrange minicomputer
lines into a single family that ran on a variant of IBM's first RISC
processor, the 801.
Many of the architectural ideas behind Fort Knox ended up in the S/38
and AS/400 lines, and those ideas - such as a high-level machine
interface that separates hardware from the operating system (OS) -
have allowed the IBM midrange to be extended for two decades while
providing application software compatibility.
... snip ...
the second paragraph appears to confuse Future System
https://www.garlic.com/~lynn/submain.html#futuresys
from the early to mid 70s ... with Fort Knox from 1980 period. There is lots of folklore that concepts from the failed/canceled Future System project did show up in S/38 (which predates Fort Knox).
wiki s/38 (introduced in 1978) article
https://en.wikipedia.org/wiki/System/38
For other topic drift, when we were doing ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
the executive we reported to, left to head up somerset ... the effort to take power/801 and do the power/pc (he later left that to become president of MIPs).
predating somerset/powerpc effort was design for 64bit 801/power ... that went on in conjunction with rochester. however, there was quite a bit of argument with rochester over the 65th bit ... a tag-line that they wanted to use for implementing s38/as400 storage access feature.
and collection of posts mentioning 801, romp, rios, power, power/ps,
somerset, fort knox, etc.
https://www.garlic.com/~lynn/subtopic.html#801
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch Date: Sun, 12 Nov 2006 14:24:18 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
for even more drift ... recent post
https://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
includes some old email from fort knox days
https://www.garlic.com/~lynn/2006p.html#email801121
above email makes mention to one of the people working on various 801 projects, who then left and went on to work on risc at HP and was later one of the itanium architects.
and these posts
https://www.garlic.com/~lynn/2003e.html#64 801 (was Re: Reviving Multics)
https://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
has copies of some number of old 801 related email ... including email
asking about my PLI program for analyzing assembler listings
https://www.garlic.com/~lynn/2006t.html#email811104
and they were looking at both static translation to 801 .. akin to the previously mentioned ECPS ... and doing the course of discussion, JIT-like activity was raised.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Assembler question Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 13 Nov 2006 08:29:20 -0700Steve_Thompson_TW@STERCOMM.COM (Thompson, Steve , SCI TW) writes:
for a little different drift, thread that drifts into a program that I
wrote in the early 70s for analyzing 360/370 assembler listings
(creating abstract representation of the instructions, instruction
flow, doing used-before-set analysis on registers, etc) ...
https://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
this came up in connection with project that was going to migrate the plethora of internal microprocessors to 801/risc (including ones used in low & mid range 370s) ... and the possibility that they might use some JIT technology ... a dynamic alternative to things like were done for ECPS (statically migrate high-use kernel pathlength into microcode).
for other drift ... past posts (& even some really old email)
mentioning Amdahl 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?
https://www.garlic.com/~lynn/2006m.html#39 Using different storage key's
https://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Assembler question Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 13 Nov 2006 09:27:16 -0700m42tom-ibmmain@ibm-main.lst (Tom Marchant) writes:
old email from somebody that I worked with on ecps ... discussing
macrocode (he mentions that he had wanted to do something similar for
quite a while)
https://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
more old email discussing 5880 announcement
https://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Friday fun - Discovery on the pad and the software's not done Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 13 Nov 2006 11:45:38 -0700lists@AKPHS.COM (Phil Smith III) writes:
this is part of (somebody's) old
email from 1984
(discussing a number
of calender roll-over problems):
3. We have an interesting calendar problem in Houston. The Shuttle
Orbiter carries a box called an MTU (Master Timing Unit). The MTU
gives yyyyddd for the date. That's ok, but it runs out to ddd=400
before it rolls over. Mainly to keep the ongoing orbit calculations
smooth. Our simulator (hardware part) handles a date out to ddd=999.
Our simulator (software part) handles a date out to ddd=399. What we
need to do, I guess, is not ever have any 5-week long missions that
start on New Year's Eve. I wrote a requirements change once to try to
straighten this out, but chickened out when I started getting odd
looks and snickers (and enormous cost estimates).
... snip ...
where they anticipated roll-over ... but original equipment extended days in the year out past the end of the year (however, inconsistently as mentioned to 399, 400, and 999 days).
the issue now appears to be that since 1984, some of the equipment may have been upgraded to more COTS products ... and which just does standard roll-over at the end of the year.
the complete copy of the old email was posted in an old y2k thread:
https://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
https://www.garlic.com/~lynn/2003p.html#21 Sun researchers: Computers do bad math ;)
https://www.garlic.com/~lynn/2006r.html#16 Was FORTRAN buggy?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: remote support questions - curiousity Newsgroups: bit.listserv.ibm-main Date: Mon, 13 Nov 2006 13:15:34 -0700the other viewpoint was that the software was designed as dedicated, disconnected tabletop operation ... and allowed numerous applications (games, etc) to take over the whole machine. a little later the software was extended to support desktop operations with some local area business network (non-hostile and non-adversary). it was designed very well to do what it was intended to do (and in fact a great deal of countermeasures to machine take-over would have been counter productive to its original target market).
it was when those pesky users started attaching the product (originally designed for totally stand-alone operation) to open (and potentially extremely hostile) networks, that you started having problems. it is somewhat like taking a Model T and asking why it doesn't have crush zones, safety belts, airbags, rollbars, safety glass, padded dashes, headrests, etc.
for slight drift ... in the mid to late 90s, a lot of the threats were
buffer overflow related to the use C language programming conventions
... lots of past posts discussing buffer overflow issues
https://www.garlic.com/~lynn/subintegrity.html#overflow
then automatic scripting (much of which had been originally targeted at closed, non-hostile, cooperative environments) exploits started to drastically increase until buffer overflow exploits and automatic scripting exploits were about equal. the potential for automatic scripting vulnerabilities was something that had been identified on the internal network in the 70s.
a couple years ago, there was an estimate that 1/3rd of the exploits were buffer overflow related, 1/3rd automatic scripting related, and 1/3rd social engineering related.
for other drift ... recent lengthy discussion on open networks and
SSL related vulnerabilities
https://www.garlic.com/~lynn/aadsm26.htm#1
the latest seems to be a big upswing in phishing ... which can be considered a form of *social engineering* ... i.e. convincing victim to do something for the attacker (frequently involves divulging sensitive information).
lots of past posts related to fraud, exploits, vulnerabilities, and
threats
https://www.garlic.com/~lynn/subintegrity.html#fraud
and as a complement ... some number of past postings related to
assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance
a major objective of phishing attacks is to obtain sensitive information that is frequently used in something you know authentication (that can be turned around and used by the attacker in replay and/or impersonation exploits).
from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
this is particularly applicable to pins, passwords something you know
shared-secret authentication
https://www.garlic.com/~lynn/subintegrity.html#secrets
or account numbers ... where attackers can turn around and use the
account numbers in transactions requiring little or no additional
information ... misc. posts mentioning account number harvesting for
fraudulent transactions
https://www.garlic.com/~lynn/subintegrity.html#harvest
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch Date: Mon, 13 Nov 2006 22:00:57 -0700"Del Cecchi" <delcecchiofthenorth@gmail.com> writes:
also endicott started work with some 801 that predated Iliad ...
this post
https://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
has copy of old endicott email from 11/4/81 mentioning working with Atlantic (801 processor from yorktown)
here is some old email that implied that Fort Knox was over and well
buried by 1988 (topic was specifically about rochester part of fort
knox ... i.e. moving rochester systems on to 801).
Date: 16 March 1988, 10:39:41 CST
To: wheeler
HI,
In Fort Knox we went round and round about what layers should
be outboard and which should be inboard. The real answer was
flexability to do both such as the gain in our IOPs.
... snip ... top of post, old email index
So in previous post
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
references this article
http://www.cbronline.com/article_cbr.asp?guid=2C99DD1B-6812-46AF-AF95-B6D7E728376A
where the as/400 came out in 1988 after *fort knox* was killed/canceled.
the previous post also cites this article "IBM: Fort Knox Fails, but
Silverlake Shines"
http://www.riteapproach.com/book/ibm.html
from above:
The goal of Fort Knox was to unify the hodgepodge of smaller IBM
computers then on the market and put DEC and its imitators on the
run. Following IBM's then rigid development process, the
specifications for creating this computer grew more complex as each
day passed. By 1985 it became obvious that the development team was
years away from a workable product, and the project was canceled.
... snip ...
as an aside, Endicott had abandoned the strategy to use 801 for the
follow-on to 4341 even earlier.
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4381.html
so in your statement "Fort Knox was more like 1990" ... are you referring to that by 1985 (when it was killed), it was realized that the scope creep(?) in Fort Knox met that nothing would be available before 1990?
my references was to stuff going on in the early days of when the project started (circa 1980) ... and not to when it was eventually might be expected to ship (and, in fact, i don't make any claims as to knowing when it might have shipped).
the other references imply that Fort Knox was more than just Rochester ... and that it started in the early 80s. Endicott use of 801 for follow-on to 4341 was abandoned at least by the time 4381 was announced in 1983. I contributed to white paper that helped Endicott decide to abandoned the 801 for the 4341 follow-on.
so i don't see what in your post refers to contridicting something in my post?
previous post
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
also cited the wiki pages for s/38 and as/400
https://en.wikipedia.org/wiki/System/38
https://en.wikipedia.org/wiki/AS/400
here is also the wiki page for silverlake
http://wiki.midrange.com/index.php/Silverlake
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch Date: Mon, 13 Nov 2006 22:20:22 -0700"Del Cecchi" <delcecchiofthenorth@gmail.com> writes:
oh, and from somewhere else long ago and far away ...
Date: 04/22/81 13:55:03
To: wheeler
Re: processors in small spaces...
Iliad goes to mfg feb 82 for 1st pass parts. Level of confidence in parts
being good is about 95%.
... snip ... top of post, old email index
but as per lots of references, the design/scope kept getting more and more complex ... and the rochester effort was finally killed in 85.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: P390 Newsgroups: bit.listserv.ibm-main Date: Wed, 15 Nov 2006 06:53:43 -0700timothy.sipples@US.IBM.COM (Timothy Sipples) writes:
and a slightly earlier thread also in comp.arch
https://www.garlic.com/~lynn/2006u.html#16 IA64 and emulator performance
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New attacks on the financial PIN processing Newsgroups: sci.crypt Date: Wed, 15 Nov 2006 07:25:40 -0700uri writes:
supposedly PINs represent two-factor authentication ... from 3-factor
authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
where a PIN represents something you "know authentication. supposedly
multi-factor authentication is considered more secure because the
different factors are selected to have independent
vulnerabilities/expoits i.e. a PIN is countermeasure to lost/stolen
card. ignore for a moment that, in part, because of the proliferation
of something you know authentication ... supposedly something like
30percent of debit cards have the PIN written on them ... lots of past
posts about shared-secret based something you know authentication
https://www.garlic.com/~lynn/subintegrity.html#secrets
for a couple decades there have been exploits/attacks on terminals that
skim authentication information. this collects both the (static data)
magstripe information (that represents something you have
authentication) and pin at the same time (something you know). this
represents a common vulnerability to debit card multi-factor authentication
... negating any assumption about multi-factor authentication being more
secure. compromise of terminals can be either insider or outsider exploit,
although outsider exploits seem to be what makes the news. lots of
past posts about harvesting static, authentication information:
https://www.garlic.com/~lynn/subintegrity.html#harvest
recent post earlier this year in this news group on related
topic
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards Hacked now
https://www.garlic.com/~lynn/2006e.html#22 Debit Cards Hacked now
https://www.garlic.com/~lynn/2006e.html#23 Debit Cards Hacked now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards Hacked now
https://www.garlic.com/~lynn/2006e.html#30 Debit Cards Hacked now
a whole lot of posts (from last spring and summer) regarding yes
card skimming attack on chip&pin payment cards ... dating back to
nearly their original introduction in the 90s:
https://www.garlic.com/~lynn/subintegrity.html#yescard
the following has some discussion of PINs and 2984 atm machine done at
the los gatos lab (where for a time i had a nearly one wing of
offices) and the demolition of the los gatos lab
https://www.garlic.com/~lynn/2006q.html#5
as well as 3624 and the introduction of PIN block format ... and the
referenced wiki article
https://en.wikipedia.org/wiki/Personal_identification_number
which also mentions a vulnerability discovered in the 3624 pin block format in 2002.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is this true? (Were gotos really *that* bad?) Newsgroups: alt.folklore.computers Date: Wed, 15 Nov 2006 08:29:27 -0700"John Coleman" <jcoleman@franciscan.edu> writes:
in failure analysis and postmortem dumps part of the issue is reconstructing sequence of events that resulted in the failure. convoluted/complex spaghetti code ... with lots of GOTOs that converge on the same place ... could make it difficult to reconstruct the execution path that resulted in arriving at failure point.
as i've posted a lot in the past ... for assembler code ... frequent failure mode was unusual code thread that resulted in register use that hadn't been correctly initialized.
misc. past posts about failure analysis program that i had implemented
and was used widely inside the corporation
https://www.garlic.com/~lynn/submain.html#dumprx
and some recent posts about a PLI program that I wrote to analyse
(360/370) assembler listings, attempting to create an abstract
representation of the execution, reconstruct all possible code paths
... and also look for things like possible register use before set.
https://www.garlic.com/~lynn/2000c.html#41 Domainatrix - the final word
https://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2005u.html#45 IBM's POWER6
https://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
https://www.garlic.com/~lynn/2006s.html#53 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
for totally other drift ... one of the first conferences that i attended
after graduating and joining a science center
https://www.garlic.com/~lynn/subtopic.html#545tech
included a talk by Harlen Mills ... misc. past references
https://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#24 How many Megaflops and when?
https://www.garlic.com/~lynn/2003k.html#20 What is timesharing, anyway?
https://www.garlic.com/~lynn/2004k.html#36 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2005b.html#16 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#51 Thou shalt have no other gods before the ANSI C standard
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New attacks on the financial PIN processing Newsgroups: sci.crypt Date: Wed, 15 Nov 2006 08:31:47 -0700Sebastian Gottschalk <seppi@seppig.de> writes:
sorry, finger slip ... hopefully was evident in subsequent discussion about pin being something you know
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New attacks on the financial PIN processing Newsgroups: sci.crypt Date: Wed, 15 Nov 2006 08:59:24 -0700re:
in approx. the same timeframe as the on the inception of the work for what
led to the yes card
https://www.garlic.com/~lynn/subintegrity.html#yescard
the x9a10 financial standard working group was formed and given the requirement
to preserve the integrity of the financial infrastructure for all retail
payments
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
part of the threat analysis was the extensive occurance of skimming exploits and/or data breaches ... and attackers (either insiders or outsiders) being able to utilize the acquired static information in a form of replay attacks.
so part of x9.59 was to eliminate replay attacks .... using
skimmed/acquired/harvested for replay attacks
https://www.garlic.com/~lynn/subintegrity.html#harvest
part of this effort was recognizing that transaction and account information is used in dozens of business processes ... and even if the planet was buried under miles of encryption ... it still wouldn't be able to prevent transaction/account leakage (whether it involved insiders or outsiders).
so part of the x9.59 financial standard was to eliminate the usefullness of transaction/account information to the attackers ... i.e. even with all the transaction/account information they couldn't use it directly for (replay attack) fraudulent transactions that go on today; aka x9.59 didn't do anything to eliminate data breaches (or skimming) ... it just eliminated the usefullness of the data breaches (and skimming) to the attackers.
several postings in thread on "naked transactions" ... that were
somewhat the outgrowth of the extended discussion on yes card
vulnerability
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: waiting for acknowledgments Newsgroups: comp.protocols.tcp-ip Date: Wed, 15 Nov 2006 12:11:41 -0700"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
the original vm/mvs tcp/ip product was implememted in vs/pascal and
got something like 44kbytes/sec aggregate thruput and consumed a 3090
processor doing it. i had added rfc 1044 support to the product .. and
in testing at cray research between a cray and a 4341-clone ... was
getting 1mbyte/sec aggregate thruput using only a portion of the
(4341-clone) processor.
https://www.garlic.com/~lynn/subnetwork.html#1044
one of the protocols used was NAK and selective-resend for missing packets and/or packets in error.
for high-speed local area network .. it might not be much of an
issue ... but one of the things we did as part of the hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
was a high-speed backbone for the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
that included some number of full-duplex T1 satellite links ... full-duplex asynchronous operation could easily have twenty 4k-byte packets outstanding simultaneously in both directions on a link. with approx. 22k miles to orbit ... or 4*22k miles for complete round-trip ... comes out to approx. half-second round-trip latency. half-duplex synchronous operation would have been two packets/sec thruput ... while the rate-based pacing and selective resend that was implemented could drive a full duplex T1 at nearly media speed (about 300kbytes/sec or 75 4k-byte packets/sec).
for additional data integrity ... the outboard satellite link also included 15/16 reed-solomon forward error correcting.
a few recent posts discussing various aspects of hsdt effort
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: waiting for acknowledgments Newsgroups: comp.protocols.tcp-ip Date: Wed, 15 Nov 2006 12:36:53 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
actually the selective resend didn't do a lot of good early on. all the links that left corporate facilities (including satellite links) had to be encrypted (at one point somebody claimed that the internal network had over half of all the link encryptors in the world).
in any case, early on, we had to settle for some (essentially) off-the-shelf T1 link encryptors ... when things got too garbled the link encryptors retrenched to initial synchronization mode ... which could last long enuf (especially on sat. link) that the software would think the link had dropped and would automatically recycle it. fortunately the 15/16 reed-solomon forward error correcting helped minimize the number of times that happened.
later i was involved in designing an inexpensive crypto board that minimized the crypto resynchronization problem (that was also targeted at being able to handle a couple megabytes/sec ... bytes not bits).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: waiting for acknowledgments Newsgroups: comp.protocols.tcp-ip Date: Wed, 15 Nov 2006 12:58:16 -0700"Skybuck Flying" <spam@hotmail.com> writes:
note that the possibility would still exist that an application could fail to pickup a packet even in a half-duplex synchronous scenario ...
if you are looking to deal with that fault scenario ... the application would need some higher level logic regardless of which scenario that tcp/ip used (synchronous 1 block at a time, or some N-blocks outstanding asynchronous). if tcp/ip acks a packet before the application signals that it has completely processed the packet ... there is still all sorts of opportunities for things to go wrong ... whether it is a single packet outstanding or 100 packets outstanding.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New attacks on the financial PIN processing Newsgroups: sci.crypt Date: Wed, 15 Nov 2006 20:13:55 -0700"Joseph Ashwood" <ashwood@msn.com> writes:
ATMs hacked using MP3 player
http://news.com.com/2061-10789_3-6135905.html
from above:
The gang targeted freestanding cash dispensers and would tap the phone
line between the ATM and a wall socket by placing a two-way adapter on
it and connecting an MP3 player, according to the newspaper.
... snip ...
and some other comments here:
https://www.garlic.com/~lynn/aadsm26.htm#5 ATMs hacked using MP3 player
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New attacks on the financial PIN processing Newsgroups: sci.crypt Date: Thu, 16 Nov 2006 06:31:03 -0700uri writes:
a few past posts mentioning signature-debit
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/2005u.html#14 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where can you get a Minor in Mainframe? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 17 Nov 2006 08:24:54 -0700Daniel_McLaughlin writes:
various of his biographies mention that he ran NKP in Thailand.
for the summer of '69 (between semesters), I was con'ed into being full-time employee at Boeing, helping setup new dataprocessing for recently formed BCS (earlier in the spring, I had been con'ed into teaching a 40hr computer class to BCS technical staff during spring break).
For a long time, I thought that the Renton datacenter was one of the largest in the world ... however there was some rumor that NKP may have been larger (one of the biographies mentions that NKP represented a $2.5B windfall to IBM).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where can you get a Minor in Mainframe? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 17 Nov 2006 12:01:57 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
what i remember was that renton datacenter was several hundred million ... which would have made NKP possibly 5-6 times larger?
i do have a slight caveat and thread drift with respect to this post
(from comp.arch thread)
https://www.garlic.com/~lynn/2006u.html#17 Why so little parallelism?
while i haven't worked on a mainframe in a long time ... this post mentions
analysing the performance of a mainframe 450k line cobol program.
https://www.garlic.com/~lynn/2006s.html#24 Curiosity: CPU % for COBOL program
where i did all the multiple regression analysis of the COBOL application activity counters using a PC-based application.
the 14percent wasn't trivial since the application ran in datacenter across $1.5B of mainframe equipment (primarily sized for this one application). However, it was 2000 dollars instead of the 1970s dollars quoted for renton and NKP.
again, collected past posts mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
misc. past posts mentioning NKP
https://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
https://www.garlic.com/~lynn/2005t.html#2 Dangerous Hardware
https://www.garlic.com/~lynn/2005t.html#5 Dangerous Hardware
misc. past posts mentioning BCS:
https://www.garlic.com/~lynn/99.html#32 Roads as Runways Was: Re: BA Solve
https://www.garlic.com/~lynn/99.html#130 early hardware
https://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001b.html#8 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001b.html#9 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001g.html#56 YKYBHTLW....
https://www.garlic.com/~lynn/2001l.html#32 mainframe question
https://www.garlic.com/~lynn/2001m.html#55 TSS/360
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
https://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction
https://www.garlic.com/~lynn/2002j.html#22 Computer Terminal Design Over the Years
https://www.garlic.com/~lynn/2002j.html#43 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2002l.html#64 10 choices that were critical to the Net's success
https://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
https://www.garlic.com/~lynn/2002n.html#72 bps loader, was PLX
https://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
https://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2003l.html#34 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2003l.html#37 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2004.html#53 Mainframe not a good architecture for interactive workloads
https://www.garlic.com/~lynn/2004d.html#55 If there had been no MS-DOS
https://www.garlic.com/~lynn/2004f.html#46 Finites State Machine (OT?)
https://www.garlic.com/~lynn/2004o.html#58 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005e.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#19 Device and channel
https://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005s.html#47 Gartner: Stop Outsourcing Now
https://www.garlic.com/~lynn/2006.html#40 All Good Things
https://www.garlic.com/~lynn/2006.html#43 Sprint backs out of IBM outsourcing deal
https://www.garlic.com/~lynn/2006k.html#29 PDP-1
https://www.garlic.com/~lynn/2006k.html#30 PDP-1
https://www.garlic.com/~lynn/2006m.html#29 Mainframe Limericks
https://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006o.html#13 The SEL 840 computer
https://www.garlic.com/~lynn/2006q.html#44 The not-so-little shop of 747s
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where can you get a Minor in Mainframe? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 17 Nov 2006 12:42:25 -0700Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
doesn't even mention the datacenter w/$2.5B in ibm mainframes
in this biography: BOYD The Fighter Pilot Who Changed the Art of War
https://www.amazon.com/Boyd-Fighter-Pilot-Who-Changed/dp/0316796883/
the chapter on Boyd running NKP is "Spook Base".
re:
https://www.garlic.com/~lynn/2006u.html#49 Where can you get a Minor in Mainframe?
https://www.garlic.com/~lynn/2006u.html#50 Where can you get a Minor in Mainframe?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where can you get a Minor in Mainframe? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 17 Nov 2006 17:10:24 -0700sarn756@ibm-main.lst (Steve Arnett) writes:
the programming announcement OS/VU
http://www.cbttape.org/funny/ttosvu.pdf
also discussed here
http://mcraeclan.com/Links/Computers/IBMMainframeHistory/mvsosvu.htm
for slight drift, here is old posting of "Gen A Sys" from july '79
https://www.garlic.com/~lynn/2001f.html#38 Ancient computer humor - Gen A Sys
there is this ...
THE CONDEMNED * WHEN THE EARTH WAS CREATED, THE POWERS ABOVE GAVE EACH MAN A JOB TO WORK AT AND LOVE. HE MADE DOCTORS AND LAWYERS AND PLUMBERS AND THEN - HE MADE CARPENTERS, SINGERS, AND CONFIDENCE MEN. AND WHEN EACH HAD A JOB TO WORK AS HE SHOULD, HE LOOKED THEM ALL OVER AND SAW IT WAS GOOD. * HE THEN SAT DOWN TO REST FOR A DAY, WHEN A HORRIBLE GROAN CHANCED TO COME IN HIS WAY. THE LORD THEN LOOKED DOWN, AND HIS EYES OPENED WIDE - FOR A MOTLEY COLLECTION OF BUMS STOOD OUTSIDE. "OH! WHAT CAN THEY WANT?" THE CREATOR ASKED THEN "HELP US," THEY CRIED OUT, "A JOB FOR US MEN." "WE HAVE NO PROFESSION," THEY CRIED IN DISMAY, "AND EVEN THE JAILS HAVE TURNED US AWAY." SAID THE LORD, "I'VE SEEN MANY THINGS WITHOUT WORTH - BUT HERE I FIND GATHERED THE SCUM OF THE EARTH!" * THE LORD WAS PERPLEXED - THEN HE WAS MAD. FOR ALL THE JOBS, THERE WAS NONE TO BE HAD! THEN HE SPAKE ALOUD IN A DEEP, ANGRY TONE --- "FOR EVER AND EVER YE MONGRELS SHALL ROAM. YE SHALL FREEZE IN THE SUMMER AND SWEAT WHEN ITS COLD - YE SHALL WORK ON EQUIPMENT THATS DIRTY AND OLD. YE SHALL CRAWL UNDER RAISED FLOORS, AND THERE CABLES LAY - YE SHALL BE CALLED OUT AT MIDNIGHT AND WORK THROUGH THE DAY. YE SHALL WORK ON ALL HOLIDAYS, AND NOT MAKE YOUR WORTH - YE SHALL BE BLAMED FOR ALL DOWNTIME THAT OCCURS ON THE EARTH. YE SHALL WATCH ALL THE GLORY GO TO SOFTWARE AND SALES - YE SHALL BE BLAMED BY THEM BOTH IF THE SYSTEM THEN FAILS. YE SHALL BE PAID NOTHING OUT OF SORROW AND TEARS - YE SHALL BE FOREVER CURSED, AND CALLED FIELD ENGINEERS!" *.... snip ...
and then there is this ...
In the first few months of the year that System 360 Operating System
came to a full stop, all signs appeared normal and there was no
indication of an impending disaster. The SDD Manager of Programming
Systems stated at the spring SHARE meeting that the F Level of FORTRAN
V would definitely be implemented and would at least equal the speed
of the E Level FORTRAN V subset, provided it was run on a Model 75 or
greater. There was no truth, he asserted, to the rumor that IBM was
dropping FORTRAN in favor of PL/3. Option 89, or MVC
(multiprogramming with a variable number of CPU's), which had been
released in System Release 101.8 was hailed by a large number of users
as the ultimate in operating systems. Representatives of a major
government agency which had been running a Model 91 with 8 million
bytes using a modified BPS supervisor, lodged a mild protest, but were
shouted down by the majority.
On April 1, an announcement by the Management Information Department
of DPD caused quite a stir. Their Management Action Optimization
(MAO) program would be written using the new Linear Interpretation
Nucleus (LIN), part of DOS extended. This occurred, it was rumored,
in spite of persistent efforts by the Marketing Verification
Department (MVD) to persuade them to use OS. This department is
charged with the "purification" of TYPE II programming standards.
There were indications, however, that something was in the air. The
OS Internals Workshop was extended from 13 weeks to 26 weeks. A
resident psychiatrist was installed to try to cut down on nervous
breakdowns, defections, and AWOL's. A blue letter advised salesmen
that "throughput" and "turnaround time" were not to be used. The
byword was to be "full utilization of system resources." At all
costs, customers were to be discouraged from asking, "But when will my
job be completed?"
Release 91.0 contained a module of the nucleus that stopped the
software clock during system overhead time. Murmurs about the
difference between meter time and time accounted for led to the
removal of all meters and a shift from a 176 hour base to 264 hours
per month. Dissatisfaction was increasing, however; one large
scientific/engineering/commercial customer announced his intention to
switch to a competitor, but after two years was unable to do so
because he was unable to discover exactly what his system was doing.
The end finally came in mid-October. System Release 110.7 was
distributed, which converted everyone to MPSS (Multiple Priority
Scheduling System), which combined the following control program
options:
Multiprogramming with a Valuable Number of Tasks
Multijob Initiation
Multiple Priority Secection
Multiprocessing with a Variable Number of CPU's
SYSGEN was accomplished with little difficulty in 504 system hours.
Expectantly, customers IPLed and initiated their job streams.
OS IS NOT TO REASON WHY . . .
(To the dune of "Everglades" and "The MTA", and with apologies to the
Kingston Trio, which does not necessarily include IBM.)
(sparkling guitar intro)
I. I was born and raised around Poughkeepsie, A programmer is what I had
to be; But IBM and its programming team Have turned me into a
debugging machine.
Running all my jobs under MVT.
CHORUS: Where a job can run and never be found, And all you see are
discs goin' 'round; And when you get your output the results are nil:
If the JCL don't get you then the systems will.
II. I put my job in the input queue. And watched in awe as the system
blew. When I reran the job, I felt really crushed; I saw on my
listing: INPUT STREAM DATA FLUSHED.
Running all my jobs under MVT.
CHORUS
III. I reran the job and ran out of space;
I reran the job with a step out of place;
I reran the job with priority 10 ... (pause)
"Will it ever return, no, it'll never return, And its fate is still
unlearned, It may hide forever in SYS1.LINKLIB..."
(pause)
Running all my jobs under MVT.
CHORUS
IV. Well, I couldn't get a job past the JCL hump,
So I never got a chance to read an ABEND dump,
If I could get one through, I'd have debugging fun,
'Cause the job was in the language known as PL/I.
CHORUS
Getting lots of grief from this MVT.
Running line a thief 'way from MVT.
Getting round this mess via DOS.
(rousing guitar finale)
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What's a mainframe? Newsgroups: bit.listserv.ibm-main Date: Sat, 18 Nov 2006 07:09:21 -0700phil@ISHAM-RESEARCH.FREESERVE.CO.UK (Phil Payne) writes:
e) if its used to hack a ATM machine ... its an MP3 player
https://www.garlic.com/~lynn/aadsm26.htm#5 ATMs hacked using MP3 player
slightly related
https://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers,comp.lang.fortran Date: Mon, 20 Nov 2006 09:09:57 -0700"Terence" <tbwright@cantv.net> writes:
the issue in the os/360 paradigm (which has been carried on thru today) is that the relocatable objects are called *relocatable address constants* which tend to be liberally distributed thru the executable image. the loader/linker function requires fetching the executable image into the address space and then running thru that image, swizzling the relocatable address constants to correspond to the address the image was loaded.
this is one of the big issues that i faced doing paged map filesystem
enhancements for cms in the early 70s ... misc. past posts
https://www.garlic.com/~lynn/submain.html#mmap
... all the pages mapped to virtual address space that contained relocatable address constants first had to be prefetched and modified before execution could even begin ... then the operating system then had the additional overhead of dealing with the modified pages ... even tho the executable image was nominally otherwise unchange.
the next issue was attempting to treat page mapped executable images as shared, read-only code ... the same (physical) copy appearing simulataneously in different address space ... possibly at unique address in each address space. unless there is some quantum effects where a relocable address constant can simultaneously take on a large number of different values ... and the appropriate value is automagically provided for the address space that is currently executing ... then it broke down.
lots of past posts about dealing with problem of relocatable address
constants in a shared segment (same physical copy in different address
space ... at potentially different addresses) paradigm.
https://www.garlic.com/~lynn/submain.html#adcon
basically, i had to rewrite the code to remove use of relocatable address constant in programs targeted for such shared segments. other infrastructures that supported such operations out of the box, would have collected all the relocable address constants in a different control structure ... not part of the executable image. each address space would have its own unique instruction address and set of registers. one of the registers would be used to address the control structure containing the appropriately adjusted relocable address constants.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What's a mainframe? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 20 Nov 2006 09:33:13 -0700m42tom-ibmmain@YAHOO.COM (Tom Marchant) writes:
previous ref:
https://www.garlic.com/~lynn/2006u.html#53 What's a mainframe?
my wife had co-authored AWP39 peer-to-peer networking in the early days of SNA ... which was oriented towards managing huge numbers of dumb terminals. she took a lot of grief .. and in fact, in most of the world, peer-to-peer is implicit in the term networking. SNA had co-opted networking to mean massive terminal communication environment ... so it became a requirement that when dealing with SNA oriented operations ... to prefix networking with peer-to-peer when talking about regular networking (as opposed to SNA).
later she was con'ed into going to POK to be in charge of
loosely-coupled (mainframe) architecture. while there she originated
Peer-Coupled Shared Data architecture (again notice the requirement
for the term peer-to-peer when dealing with an SNA entrenched
environment ... where in the rest of the world, peer-to-peer would be
implicit).
https://www.garlic.com/~lynn/submain.html#shareddata
she didn't last long and left ... Peer-Coupled Shared Data not getting a lot of uptake (except for IMS hot-standby) until parallel sysplex came along.
i do claim that one of the reasons behind relatively rapid ibm/pc
uptake was business customers being able to get dumb (3270) terminal
emulation on ibm/pc. for about same cost as a 3270, an ibm/pc provided
a single desk footprint with both dumb terminal emulation and some
amount of local computing capability.
https://www.garlic.com/~lynn/subnetwork.html#emulation
however, in the later 80s, real client/server with PCs was starting to
emerge. and we had come up with 3-tier architecture and were out
making customer executive presentations. the mainstream was pushing
something called SAA ... which could be construed as trying to cram
the client/server genie back into the bottle (and return to dumb
terminal emulation). we took a lot of grief from the SAA crowd for
being out there pushing 3-tier architecture.
https://www.garlic.com/~lynn/subnetwork.html#3tier
we also took some grief for hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
recent posting with some old EMAILs trying to do some stuff for
NSFNET backbone (the operational precursor to the modern internet)
https://www.garlic.com/~lynn/2006t.html#6
6may85,
30sep85,
7apr86
https://www.garlic.com/~lynn/2006s.html#50
17apr86,
15may87
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Ranking of non-IBM mainframe builders? Newsgroups: alt.folklore.computers Date: Mon, 20 Nov 2006 10:32:17 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
past post with email from 1may86 discussing some of the same information
https://www.garlic.com/~lynn/2005d.html#13
more from long ago and far away
Date: 05/05/86 07:19:20
From: wheeler
re: hsdt; For the past year, we have been working with Bob Shahan &
NSF to define joint-study with NSF for backbone on the
super-computers. There have been several meetings in Milford with ACIS
general manager (xxxxx) and the director of development (xxxxx). We
have also had a couple of meetings with the director of NSF.
Just recently we had a meeting with Ken King (from Cornell) and xxxxx
(from ACIS) to go over the details of who writes the joint study. ACIS
has also just brought on a new person to be assigned to this activity
(xxxxx). After reviewing some of the project details, King asked for a
meeting with 15-20 universities and labs. around the country to
discuss various joint-studies and the application of the technology to
several high-speed data transport related projects. That meeting is
scheduled to be held in June to discuss numerous university &/or NSF
related communication projects and the applicability of joint studies
with the IBM HSDT project.
I'm a little afraid that the June meeting might turn into a 3-ring
circus with so many people & different potential applications in one
meeting (who are also possibly being exposed to the technology &
concepts for the 1st time). I'm going to try and have some smaller
meetings with specific universities (prior to the big get together in
June) and attempt to iron out some details beforehand (to minimize the
confusion in the June meeting).
... snip ... top of post, old email index, NSFNET email
part of the visibility thing was that not too long after the above ...
we found that somebody in the company was calling up and canceling
meetings that we had scheduled with outside parties. somewhat related
https://www.garlic.com/~lynn/2006u.html#55 What's a mainframe
with such concerted opposition mounting inside the company, there wasn't a whole lot left we could do to continue with HSDT project.
one of the last HSDT gasps ... I figure they were planning on showing
us .. we were asked to be the red team for the NSFNET2 backbone
(upgrade from T1 to T3) and the blue team was something like 20-30
people from seven labs around the world. at the final review in
corporate hdqtrs, it possibly didn't go exactly as they planned
... and resulted in what could be called the garbage truck manifesto
for NSFNET2. a few previous posts mentioning the NSFNET2 garbage
truck
https://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
https://www.garlic.com/~lynn/2006e.html#38 The Pankian Metaphor
we then got diverted into doing ha/cmp product and cluster scale-up
... one of the results
https://www.garlic.com/~lynn/95.html#13
the next time we were doing much internet stuff was when we were asked
to do some consulting with a small client/server startup that wanted
to do payment transactions on their server ... and two of the people
from the meeting mentioned in the above post ... were now responsible
for something called commerce server at the startup.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
other posts in this thread
https://www.garlic.com/~lynn/2006s.html#40 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#43 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#51 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#11 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#12 Ranking of non-IBM mainframe builders?
From: lynn@garlic.com Subject: Re: Pedantry (was RE: Shane's antipodes) Newsgroups: bit.listserv.ibm-main Date: 20 Nov 2006 14:00:19 -0800Zani, Alaimo , Bruno wrote:
Shortly before the visit, we had bought a BBC DVD on the history of Great Britian. The BBC show supposedly wasn't very popular in England because it supposedly told much of the history as it actually was ... rather than how it was rewritten to make England look better. they listed some number of the slaughters that England did on the scotts ... wiping out whole areas (similar stuff in Ireland).
the Edinburgh castle military museums seem to have taken the cleaned up English history.
the BBC show had the English wiping out whole areas, taking all the land and leaving most of the remaining people w/o property ... and about the only occupation left for males was various branches of the military or immigration. the military museum didn't mention any of that ... just that all the young men signed up for the military because they were so patriotic and brave.
the Edinburgh castle military museum listed the men killed at Gillipoli but not much else. the BBC show made much about how the English commanders were so incompetent and managed to kill huge numbers of irish, scotts, australians, etc. there was some mention that possibly one reason that Ireland tried to stay neutral in ww2 was the slaughters perpetrated on the Irish by British commanders in ww1 at places like gillipoli
after we got back, I was watching an old (ww1 flavor) Black Adder show ... one of (Mr Beans) lines was ... when we see an man in a skirt, we run him through and nik his land.
and for some other scottish drift
https://www.garlic.com/~lynn/2006r.html#47
https://www.garlic.com/~lynn/2006b.html#30
https://www.garlic.com/~lynn/2005n.html#14
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What's The Best Computer and Why Newsgroups: alt.folklore.computers Date: Wed, 22 Nov 2006 11:25:13 -0700Roland Hutchinson <my.spamtrap@verizon.net> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What's The Best Computer and Why Newsgroups: alt.folklore.computers Date: Wed, 22 Nov 2006 15:58:42 -0700"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers,comp.lang.fortran Date: Wed, 22 Nov 2006 18:44:41 -0700jmfbahciv writes:
my complaints with the os/360 convention wasn't particularly the
resolving ... it was that the convention had the relocation address
constants distributed thruout the executable image. that caused
problems when i did paged mapped filesystem for cms in the early 70s,
it wasn't possible to just page map the executable image and then
start execution ... the executable image had to be page mapped and
then the linker/loader had to run thru (essentially) random locations
in the executable image .... swizzling the relocatable address
constants. this requires that some (nearly random) number of pages
have to be prefetched by the link/loader and modified (before
application execution can be begin). misc. past posts about
doing page mapped filesystem support for cms
https://www.garlic.com/~lynn/submain.html#mmap
furthermore, it made impossible the page mapping of the same
executable image into different virtual address spaces at different
virtual addresses. misc. past post about trying to support page
mapping the same executable image into different virtual address
spaces at potentially different virtual addresses
https://www.garlic.com/~lynn/submain.html#adcon
other aspects of os/360 was that physical disk storage tended to be pre-allocated before the application started execution. on the other hand, from the start, the cms filesystem would dynamically each physical disk record as it was required. os/360 filesystem tended to get very good file locality ... while the cms mechanism could result in nearly random location for a file's physical records. when i did the cms filesystem enhancement for page mapping, i also added some semantics for supporting a degree of contiguous allocation.
for lots of other drift .... old email discussing r/o protection of shared images ... in the following "BNR" refers to Bell Northern Research
This is discussing "new" method for "protecting" shared segments introduced with release 3 of vm370. Originally, CMS had been reorganized to take advantage of the 370 "segment protect" feature. when that feature was dropped from 370 (as part of helping 370/165 meet schedule for retrofitting virtual memory), vm370 had to revert to the key-protect games used by cp67 for shared page protection.
The vm370 release 3 changes allowed, eliminated protection. instead, there was a page scan whenever there was task switch ... to check if the previous task had modified any shared pages. if a shared page had been found to be modified, it was discarded (and any subsequent reference would cause a page fault and retrieve of an unmodified copy from disk).
with multiprocessor support, they then had to add a unique copy of shared pages for every running processor.
the email also mentions performance enhancement to not bother with
protection ... allowing any application in one address space to
corrupt (shared) executable images potentially in use by large number
of other applications.
Date: 04/05/79 20:40:23
From: wheeler
FYI; BNR has done some testing on what the release 3 changed page
checking is costing them. A 4-5 segment program moved into a
discontiquous shared system was requiring about 10% more CPU to
complete than running as a module (the changed page checking more than
offset any reduction in CPU gained by not doing as much paging and not
doing the I/O to load the module). The release 6 not checking code
appears to worse than useless for most users (who ever thot of it in
the 1st place). Most of the people who are in the tightest CPU bind
also have the most users (possibly 200+ plus), it wouldn't take very
many incidents of accidental, unpredictable segment modification to
completely blow away all possible thru-put gains of using it. Maybe
that could be minimized by having a timer driven routine which would
run around once every 2-3 minutes checking for any changed pages
(which were not be checked for) and abend CP (SVC 0). That would bring
the system down and back-up again clean with a minimum of service
disruption to the users. The other alternative is for 15-30 minutes to
elapsed where everybody got the fealing that something was wrong, but
nobody could quite fiqure out what. Hopefully a system programmer
would be along to get them out of the mess (also PTR could even abend
faster if a shared, changed page was ever selected). This also
eliminates all the nasty buGs associated with DMKVMA and
unsharing. You get a nice, clean abend that nobody has to worry about
fixing (could even change CP so that it even bypasses taking a dump).
I haven't heard of anybody yet who is planning on using the release 6
feature to save the overhead of checking for changed pages in
CMS. Maybe some installation that doesn't have very many people
dependent on CMS (Of course in that case why are they worrying about
the performance?).
... snip ... top of post, old email index
past posts about the vm370 release 3 change for "protecting" shared
pages
https://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2006.html#13 VM maclib reference
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006m.html#54 DCSS
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers,comp.lang.fortran Date: Wed, 22 Nov 2006 23:10:18 -0700The first problem with taking an existing application and setting it up for common, shared executable across multiple virtual address spaces involved making sure that the executable image would work in read-only, protected storage. A lot of the applications from the period tended to have a lot of temporary working storage spread through-out the program. Portions of the code typically had to be rewritten to convert it for use in read-only, protected execution.
I had originally done the CMS paged mapped filesystem support and the shared execution support in the early 70s. A very small subset of that support was included in release 3 under the label "DCSS" (or discontiguous shared segments).
I had support that could take shared executable image directly from
the CMS (paged mapped) filesystem. However, not only was there
the relocatable address constant issue ... discussed in the
previous posts
https://www.garlic.com/~lynn/2006u.html#54 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006u.html#60 Why these original FORTRAN quirks?
but also modifying existing application code that made used of
internal working storage. Recent post that has quite a bit
of RED editor discussion
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
included an email from
3nov78
that makes a passing reference to
modifying RED editor for execution in shared, protected storage.
this refers to RED having the necessary modifications between 3nov78 and 23may79. the "re-genmoding" (in the following email) refers to the CMS command with the modifications that supports automatically invoking the shared execution invokation from paged mapped filesystem.
NED is another (internal) editor from the period. APL is the APL
interpreter. DSM is the "script" document format application ... i.e.
supporting both script "dot" formating commands as well as GML
(generalized markup language) format commands ... misc. past posts
mentioning GML, SGML, HTML, XML, etc
https://www.garlic.com/~lynn/submain.html#sgml
Date: 05/23/79 19:14:12
From: wheeler
I've setup up the following and checked for storage alterations
RED
NED
APL
and DSM
just by loading and re-genmoding them. RED and NED have been regen'ed
with just segment 2 shared (RED has another 5-6 pages and NED has
another 2-3 pages). APL was gen'ed with segments 2, 3, and 4 shared
(it has another 1 or 2 pages). DSM was gen'ed with segments 2 and 3
shared (it has another 14-15 pages, it would be worthwhile to obtain
the original DSM text decks and dummy the ending module location up to
the next segment boundary so that segment 4 could also be shared).
EDGAR is just slightly under 16 pages. It will also be necessary to
obtain the original text for it so that its ending address is rounded
up to a segment boundary so that it will have a shared segment. That
takes care of the immediate modules that I know about that can be
shared.
--
also re: APL; the APL we are running is 2.1 from PID. Talking to the
science centers it was suggested that we obtain LA's APL for our
production system. Among its other enhancements, their comment was
that at least with LA's APL we would receive support as compared to
the PID version (I assume they mean to imply PID version isn't
answering and/or correcting any bug reports).
... snip ... top of post, old email index
misc. past posts mentiong DCSS:
https://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
https://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2002o.html#25 Early computer games
https://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
https://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2003o.html#42 misc. dmksnt
https://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
https://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
https://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#11 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
https://www.garlic.com/~lynn/2005b.html#8 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005e.html#53 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#30 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005t.html#39 FULIST
https://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1
https://www.garlic.com/~lynn/2006.html#13 VM maclib reference
https://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s
https://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370
https://www.garlic.com/~lynn/2006i.html#43 virtual memory
https://www.garlic.com/~lynn/2006j.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006m.html#53 DCSS
https://www.garlic.com/~lynn/2006m.html#54 DCSS
https://www.garlic.com/~lynn/2006m.html#56 DCSS
https://www.garlic.com/~lynn/2006o.html#53 The Fate of VM - was: Re: Baby MVS???
https://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
https://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core)
https://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?