From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Microsoft to design its own CPUs - Next Xbox In Development Newsgroups: comp.arch Date: Mon, 23 Oct 2006 09:48:03 -0600torbenm@app-3.diku.dk (Torben Ægidius Mogensen) writes:
some of this is matching the semantics and the overall infrastructure that needs to concurrently manage a large number of different processes/operations in highly parallelized environment ... in several cases, extremely fine-grain parallel, concurrent operations. this has something of the flavor of the oldtime high performance processors that needed highly tuned and highly specialized horizontal microcoding (and the execution/work units may span a number of different chips).
re:
https://www.garlic.com/~lynn/2006s.html#62 Microsoft to design its own CPUs - Next Xbox In Development
https://www.garlic.com/~lynn/2006s.html#63 Microsoft to design its own CPUs - Next Xbox In Development
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever Newsgroups: bit.listserv.ibm-main,bit.listserv.vmesa-l,alt.folklore.computers Date: Mon, 23 Oct 2006 11:27:34 -0600gilmap writes:
it used to be that storage key based protection mechanism was 2k ... but with 3081 and 370-xa ... 2k storage keys were dropped in favor of 4k storage keys.
and as mentioned ... cms had shared pages in cp67 ... which was oriented around r/o protection on page basis (using a hack involving 2k storage key protection). in the morph of cms for vm370, some amount of cms was reworked to align with the segment sharing (across address spaces) and segment protection facility in the original 370 virtual memory architecture. the segment protection (and other) features of the original 370 virtual memory architecture got dropped as part of buying six months schedule time for 370/165 hardware implementation (and while the cms programing model retained the shared-segment alignment orientation ... the underlying protection mechanism used by vm370 reverted to the storage key based protection mechenism used by cp67),
and then, of course, there is the whole os/360 heritage of relocatable adcons ... not only do all the relocable adcons need to be swizzled as part of program loading ... but it is further aggravated by relocatable adcons being intermixed with program code and data (as aside, cms leverages uses of the os/360 derived assemblers, compilers, conventions, etc ... however, tss/360 had a much better convention for the handling of program address constants in a virtual memory environment).
various recent postings mentioning the relocatable adcon issue
https://www.garlic.com/~lynn/2006s.html#17 bandwidth of the swallaw (was Real core)
https://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?
and lots of past posts mentioning relocatable adcon issue
https://www.garlic.com/~lynn/submain.html#adcon
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 23 Oct 2006 13:34:09 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
the meeting was primarily to focus on cluster scale-up for our (ibm) ha/cmp
product (and possible relationship between cluster scale-up and parallel
oracle)
https://www.garlic.com/~lynn/subtopic.html#hacmp
for completely other triva ... two of the other people mentioned in
the same meeting later showed up in a small client/server startup
and responsible for something they called the "commerce server". at that time,
we were called in as consultants on something called payment gateway
... because they wanted to process financial transactions on servers
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
the small client/server startup had this technology called https (or ssl) and the payment stuff is frequently now referred to as electronic commerce.
a couple other recent posts on some (even older) networking activity
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#51 Ranking of non-IBM mainframe builders?
and then there are these two
https://www.garlic.com/~lynn/internet.htm#0
https://www.garlic.com/~lynn/internet.htm#31
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Universal constants Newsgroups: alt.folklore.computers Date: Mon, 23 Oct 2006 18:11:13 -0600for completely other drift .... 30 min. program on Legends of Airpower just started on the Military (cable) channel ... this program on John Boyd.
misc. Boyd URLs from around the web
https://www.garlic.com/~lynn/subboyd.html#boyd2
and misc. of my past posts mentioning John Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Turbo C 1.5 (1987) Newsgroups: alt.folklore.computers Date: Mon, 23 Oct 2006 18:51:16 -0600Al Kossow <aek@spies.com> writes:
i put a 1.2m 5.25in teac drive in an old pentium pro machine who's scsi hard disk had long since died ... however, the floppy cable did have edge connector for the teac drive ... along with 3.5in floppy reader. i've got a number dos4 and dos6 3.5in bootable diskettes and was able to read numerous 360kbyte diskettes on the B: drive.
however, i haven't been able to read/process any of the 80trk 10sector diskettes as well as half dozen 360kbyte diskettes. i was hoping that imagedisk would be able to do the trick ... but imagedisk apparently can't find the floppy controller to directly access.
the dos systems haven't had a problem and i've also been boot and run knoppix (from the scsi cdrom drive).
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: Mon, 23 Oct 2006 21:23:41 -0600winston19842005 writes:
i found it quite remarkable the number of operations allowing offsite/remote access in the 90s up thru the present day that don't use even the simplest security measures. if so many organizations weren't even encrypting offsite/remote communication ... why would you expect that they would provide protection for data actually on the laptops????
for other drift ... there is my old posting on security proportional
to risk
https://www.garlic.com/~lynn/2001h.html#61
and post with quite a few references to data breaches and other data loss
scenarios
https://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address UK Chip&Pin woes
and collection of posts on various associated vulnerabilities and exploits
https://www.garlic.com/~lynn/subintegrity.html#yescard
note that the x9a10 financail standard working group had been given the
requirement to preserve the integrity of the financial infrastructure
for all related payments in conjunction with the work on the x9.59
financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
part of the work eliminated risk associated with account numbers
for x9.59 transactions ... i.e. x9.59 didn't do anything
about prevent data breaches associated with account numbers
https://www.garlic.com/~lynn/subintegrity.html#harvest
https://www.garlic.com/~lynn/subintegrity.html#secrets
however, it eliminated any risks associated with attackers obtaining (x9.59 related) account numbers ... and since the risks were eliminated ... then based on security proportional to risks ... the security issues were significantly mitigated.
misc. past posts mentioning corporate encrypting modems for offline/remote
access
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm22.htm#16 serious threat models
https://www.garlic.com/~lynn/aadsm25.htm#34 Mozilla moves on security
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2003i.html#62 Wireless security
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2006p.html#35 Metroliner telephone article
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Ranking of non-IBM mainframe builders? Newsgroups: alt.folklore.computers Date: Tue, 24 Oct 2006 11:41:04 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
some other background ... part of the history leading up to the letter
from NSF being sent to corporate hdqtrs (mentioned in the referenced
4/17/86 email in the previous post) events had significant overtones
involving corporate political infighting
Date: 05/06/85 16:41:57
From: wheeler
I noticed in this months sigops a quicky synopsis of Project Admiral
... I've been making presentations on HSDT recently (it has been
pitched to NSF as a backbone to tie together all the super computer
sites). Last week in Boulder at the National Center for Atmospheric
Research, one of the people mentioned that Project Admiral and HSDT
will be managing the satellite channel simarily ... do you have more
detailed info?
BTW ... I'll probably be over in Europe during July. People at NSF ask
that HSDT also be pitched to the european network (EARN).
... snip ... top of post, old email index, NSFNET email
Date: 09/30/85 15:34:06
From: wheeler
I'm meeting with NSF on weds. to discuss the implementation for tieing
together the super-computer centers. I'll be back in Milford next week
to present the NSF project status. I've been asked to get together
with Univ. of Cal. by the end of the month to discuss their use for
tieing together the UofC campuses.
... snip ... top of post, old email index, NSFNET email
Erich Bloch was director of the National Science Foundation for much of
the 80s.
Date: 04/07/86 10:06:34
From: wheeler
re: hsdt; I'm responsible for an advanced technology project called
High Speed Data Transport. One of the things it supports is a 6mbit
TDMA satellite channel (and can be configured with up to 4-6 such
channels). Several satellite earth stations can share the same
channel using a pre-slot allocated scheme (i.e. TDMA). The design is
fully meshed ... somewhat like a LAN but with 3000 mile diameter
(i.e. satellite foot-print).
We have a new interface to the earth station internal bus that allows
us to emulate a LAN interface to all other earth stations on the same
channel. Almost all other implementations support emulated
point-to-point copper wires ... for 20 node network, each earth
station requires 19 terrestrial interface ports ... i.e. (20*19)/2
links. We use a single interface that fits in an IBM/PC. A version is
also available that supports standard terrestrial T1 copper wires.
It has been presented to a number of IBM customers, Berkeley, NCAR,
Erich Bloch and Dick Jennings at NSF and a couple of others. NSF finds
it interesting since 6-36 megabits is >100* faster than the "fast"
56kbit links that a number of other people are talking about. Some
other government agencies find it interesting since the programmable
(full bandwidth) encryption interface allows crypto-key to be changed
on a packet basis. We have a design that supports data-stream (or
virtual circuit) specific encryption keys and multi-cast protocols.
We also have normal HYPERChannel support ... and in fact have done our
own RSCS & PVM line drivers to directly support NSC's A220. Ed
Hendricks is under contract to the project doing a lot of the software
enhancements. We've also uncovered and are enhancing several spool
file performance bottlenecks. NSF is asking that we interface to
TCP/IP networks.
... snip ... top of post, old email index, NSFNET email
lots of other posts mentioning HSDT
https://www.garlic.com/~lynn/subnetwork.html#hsdt
misc. posts mentioning bitnet/earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet
post referencing old email about setting up earn:
https://www.garlic.com/~lynn/2001h.html#65 UUCP email
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 32 or even 64 registers for x86-64? Newsgroups: comp.arch,alt.folklore.computers Date: Wed, 25 Oct 2006 09:54:50 -0600"ranjit_mathews@yahoo.com" <ranjit_mathews@yahoo.com> writes:
a couple previous posts with copy of the above email
https://www.garlic.com/~lynn/2006p.html#15 25th Anniversary of the Personal Computer
https://www.garlic.com/~lynn/2006p.html#19 Wat part of z/OS is the OS?
and nearly a year earlier
Date: 12/08/81 21:53:49
To: wheeler
Re: Complexity
Agreed, decomposition is ONE solution to solving complex problems.
Another widely accepted solution is sucessive approximation. The
principle there is that you attempt a cheap solution as an
approximation, observe the results and interate to produce a better
solution. This method has been used in the creation of the S/370
architecture, among other things. It is already an established
mathematical and engineering procedure for establishing optimality.
In the 801, quite a bit has been pushed onto the
code/compiler/operating system. As a first approximation, that's not
a bad idea, since it is relatively cheaper to change the operating
system than it is to change the machine. I claim that after iterating
on the operating system a while, the proper concepts can be reasonably
put into silicon. It is just too damn expensive to go out and try to
do it right the first time. I believe that the iapx432 will fail for
that reason. I can't believe that they are going to get it right so
that they can get into mass production until after the development
budget has completely blown any profits they may make.
Whatever Yorktown's reasons, a simple computer isn't a bad idea.
Seymore Cray has made one hell of a lot of hay on that idea. Guys at
Berkeley have ripped off the basic 801 idea(simple computer) and built
RISC(Reduced Instruction Set Computer) in FET which they claim will
outrun most mini's in the world. Complexity in a machine architecture
SLOWS IT DOWN. Let's find the complexity in the software, and then
move it to the hardware as necessary on further iterations.
... snip ... top of post, old email index
wikipedia reference to berkeley risc
https://en.wikipedia.org/wiki/Berkeley_RISC
lots of past postings mentioning 801, romp, rios, fort knox, power,
somerset, etc
https://www.garlic.com/~lynn/subtopic.html#801
as an aside, i've previously mentioned being at an (internal) advanced technology conference early 77 doing presentation on 16-way smp design ... where the 801 group was presenting 801 (and getting into argument about how to handle shared segments in virtual memory architecture). as much as the hardware design was the compiler (pl.8) and operating system (cp.r) ... since, in effect, a lot of hardware stuff was being moved into software.
my view was that some amount of the motivation for 801 was in reaction
to the failed future system effort
https://www.garlic.com/~lynn/submain.html#futuresys
and to try and do as nearly as possible, the exact opposite, in terms of hardware complexity.
and as to the mentioned subthread on complexity (and moving complex software into hardware) ... my somewhat counter argument from the period ... was that at lot of software complexity (especially kernel) was spaghetti patched mess that possibly had evolved over a decade (or more). the original people that understood the purpose for the code are no longer around and what is left is a lot of incremental patching activity.
benefits of redoing in hardware comes as much from just the redoing (and figuring out what is really going on) as comes from moving anything into hardware.
what you did find was that some of the people that had worked on early 801, going to both amd (29k?) and hp (snake?)
there is some folklore that one of the people that gave notice that they were leaving for HP ... then spent their remaining 2weeks in the los gatos lab doing some final work on blue iliad (early 32bit 801 chip).
the aix unix workstation, pc/rt ... with (an 801) ROMP chip ... originally started at as an OPD project for a follow-on to the displaywriter. when that project was killed, there was some looking around and eventual decision to retarget the machine to the unix workstation market. the company that had done the at&t unix port to the ibm/pc for pc/ix was hired to do a similar port to what was going to "aix". cp.r had to be scrapped ... however the group writing the pl.8 displaywriter software was retargeted to implement a virtual machine abstraction (VRM) in pl.8. the company doing the unix port, was directed to do it to the VRM interface (rather than the bare hardware).
recent post mentioning vrm:
https://www.garlic.com/~lynn/2006r.html#49 Seeking info on HP FOCUS (HP 9000 Series 500) and IBM ROMP CPUs from early 80's
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Root CA CRLs Newsgroups: microsoft.public.security Date: Wed, 25 Oct 2006 11:56:30 -0600Seeker <newsgroups@minusthespam.michaelstarks.com> writes:
the original kerberos pk-init ... misc. past posts
https://www.garlic.com/~lynn/subpubkey.html#kerberos
started out with a certificate-less public key infrastructure ... the
registration authority (which is common to lots of business processes)
just registered the public key in lieu of a password ... w/o having to
issue a certificate ... misc. past posts
https://www.garlic.com/~lynn/subpubkey.html#certless
so entities can connect/login just thru kerberos digital signature authentication protocol ... where the digital signature is directly verified by doing real-time access to the registered public key.
note there was also a similar certificate-less done for radius ...
again, w/o having to resort to any of the PKI, certification
authority, and/or certificate revocation list stuff.
https://www.garlic.com/~lynn/subpubkey.html#radius
for the SSL, server authentication/encryption scenario ... misc.
past posts
https://www.garlic.com/~lynn/subpubkey.html#sslcert
the scenario involved registering public keys with the domain name infrastructure ... and doing real-time retrieval of public keys as part of the existing domain name infrastructure protocols (even piggyback in existing transmission).
the issue here was that the PKI/CA business operations were already somewhat advocating registration of public keys with the domain name infrastructure ... as a countermeasure to some integrity issues that the SSL domain name certificate operations have ... aka as part of a ceritification authority certifying a SSL domain name certificate operations ... they have to validate that they are dealing with the true domain name owner. they currently require a lot of "identification" information ... which then they cross check with the registered identification for the domain name owner on file with the domain name infrastructure. having the domain name owner register a public key helps eliminate some vulnerabilities associated with who the domain name owner is.
this does represent something of a catch-22 for the SSL domain name certificate operation. With a public key on file for the domain name owner, they can now require that all SSL domain name certificate applications be digitally signed. They can then do a real-time (certificate-less) retrieval of the public key from the domain name infrastructure for validating the digital signature. This turns an expensive, error-prone, and time-consuming identification process into a much simpler, less-expensive, and more reliable authentication process (as part of due diligence related to the SSL domain name certificate application).
the catch-22 issues are:
1) SSL domain name certificates were originally justified (in part) based on integrity issues with the domain name infrastructure. improving the overall integrity of the domain name infrastructure reduces some of the originally justification for having SSL domain name certificates
2) if the SSL domain name certificate operations can do real-time retrieval of public keys for their purposes (basically it becomes the trust root for the certification process) ... then it is possible that the rest of the world could also start doing real-time retrieval of public keys from the domain name infrastructure ... eliminating the need for SSL domain name certificates at all (aka directly using the same trust root that is the foundation for the SSL domain name certificates)
misc. past posts mentioning the catch-22 issue for the SSL domain name
certificate business related to their desire to have public keys
registered with the domain name infrastructure ... and being able to
do real-time, certificate-less, public key retrievals.
https://www.garlic.com/~lynn/subpubkey.html#catch22
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 32 or even 64 registers for x86-64? Newsgroups: comp.arch,alt.folklore.computers Date: Wed, 25 Oct 2006 16:10:17 -0600re:
in the following, "MLS" refers to the 16-way SMP mentioned in the
previous post. VAMPS was a 5-way smp project that preceded MLS
... misc. collected posts mentioning VAMPS
https://www.garlic.com/~lynn/submain.html#bounce
Date: 11/28/78 14:45:51
From: wheeler
I can wait. Remember the '801' cpu from Yorktown? There was a a
presentation on it at that ad-tech meeting in POK when we presented
MLS. Well it is being fabricated in Los Gatos and they are looking for
applications for it. They are interested in programming 370
instruction set and running VM on it. There is a GPD ad-tech group
located here in bldg. 28 looking at system support. A lot of things in
VAMPS and MLS look like possibilities.
... snip ... top of post, old email index
Date: 06/07/79 07:48:11
From: wheeler
The 801 seems to be the only game in town. The hardware architecture
is much closer to vertical microcode than machine language (there has
even been suggestion that 370 be programmed on it, which would make
the 801 microcoded).
... snip ... top of post, old email index
one of the suggested purposes for 801s was to replace the myriad of
internal microprocessors ... including some number of microprocessors
used in 370 implementations. misc. posts mentioning microprocessor
microprogramming
https://www.garlic.com/~lynn/submain.html#mcode
old email that i've posted before mentioning 801:
Date: 79/07/11 11:00:03
To: wheeler
i heard a funny story: seems the MIT LISP machine people proposed that
IBM furnish them with an 801 to be the engine for their prototype.
B.O. Evans considered their request, and turned them down.. offered
them an 8100 instead! (I hope they told him properly what they
thought of that)
... snip ... top of post, old email index
note: 8100 system used a totally different microprocessor (I believe uc.5) that was in no way related to 801.
and for something completely different, 801's pl.8 compiler (using
pascal language front end and both 68k and 370 backend code
generation)
Date: 8 August 1981, 16:47:28 EDT
To: wheeler
the 801 group here has run a program under several different PASCAL
"systems". The program was about 350 statements and basically
"solved" SOMA (block puzzle..). Although this is only one test, and
all of the usual caveats apply, I thought the numbers were
interesting... The numbers given in each case are EXECUTION TIME ONLY
(Virtual on 3033).
6m 30 secs PERQ (with PERQ's Pascal compiler, of course) 4m 55 secs 68000 with PASCAL/PL.8 compiler at OPT 2 0m 21.5 secs 3033 PASCAL/VS with Optimization 0m 10.5 secs 3033 with PASCAL/PL.8 at OPT 0 0m 5.9 secs 3033 with PASCAL/PL.8 at OPT 3... snip ... top of post, old email index
aka Endicott was looking at using an "801" as the microprocessor in the follow-on to the 4341. I had done a program that analyzed 370 assembler listings, register usage, code flow, and instructions ... and then generated a program representation in pli-like psuedo code. the reference in the above to "PL1-like" is, of course pl.8. the idea behind this email, was not only use the 801 as the microprocessor for emulating 370s ... but to also take the whole vm370 virtual machine kernel and drop it into native 801 code.
this would have been somewhat analogous to the current generation of 370 virtual machine supervisors implemented on i86 platforms.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers Date: Wed, 25 Oct 2006 16:15:28 -0600Joe Morris <jcmorris@mitre.org> writes:
i had a format command where you could point at a starting location in a dump image and a "DSECT" library member ... and it would interpret the DSECT source on the fly and format the storage according to the specified DSECT.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Ranking of non-IBM mainframe builders? Newsgroups: alt.folklore.computers Date: Wed, 25 Oct 2006 16:51:22 -0600re:
other HSDT email from long ago and far away
Date: 04/18/84 11:27:41
To: wheeler
There is a T1 circuit currently scheduled by NY TEl for installation
12/84 from Yorktown to West 1. This was the missing link in the t1 circuit
from IBM Kingston to Yorktown. NY Tel now indicates that they believe they
can improve the installation date to 9/1/84. INET's interest in doing that,
and in fact, installing the circuit at all at this time may depend
on HSDT requirements.
... snip ... top of post, old email index, HSDT email
the April email is concerning an on order T1 link between Yorktown (NY) and IBM Kingston (NY) and informing that the installation date might possibly be improved from December to September.
misc. past posts mentioning HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Ranking of non-IBM mainframe builders? Newsgroups: alt.folklore.computers Date: Wed, 25 Oct 2006 21:00:22 -0600re:
and another old email related to hsdt
Date: 11/21/84 08:55:26
From: wheeler
re: hsdt; oh, almost forgot. I'm having another meeting with the
Berekely ten meter telescope people (this time just the IBMers working
with them). They want to set-up for remote observing (observatory will
be about 14,000 foot level in Hawaii) from both "local" sea level and
eventually the mainland. Current estimates are that the digitized
image represents about 800kbits of data during the evening hours (data
flow is asymetrical with telescope control commands going in the
opposite direction only about 1200 baud).
Because of numerous reasons (staffing, support, etc.), they would like
to limit the hardware at the site to PC/AT scale machine (customer
field replacable units ... service call would be extremely time
consuming and loose valuable observing time).
... snip ... top of post, old email index, NSFNET email
a couple other posts on the subject (including copies of old email)
https://www.garlic.com/~lynn/2004h.html#7 CCD technology
https://www.garlic.com/~lynn/2004h.html#8 CCD technology
and recent news article about there being some damage in the recent
earthquake:
http://www.keckobservatory.org W. M. Keck Observatory
http://www.keckobservatory.org/news.php W. M. Keck Observatory News W. M. Keck Observatory News
http://www.keckobservatory.org/article.php?id=95
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VM SPOOL question Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l Date: Wed, 25 Oct 2006 22:29:42 -0600lynn writes:
for additional drift ... another old email mentioning page replacement
work:
Date: 6/22/92 19:57:09
From: wheeler
Last year there was some sort of announcement from Amdahl regarding
Huron ... describing it as a hierarchical database system ... part of
something look like it was targeted along the same lines as ad/cycle.
at a meeting in boston on friday, i ran into consultant/professor (who
i had known from the early '70s) that mentioned he had designed the
Huron database system and was working with Amdahl on the
implementation.
the actual context of the discussion started out on LRU replacement
algorithms and a paper he and two other professors were writing on
the subject. I had been responsible for possible the original
implementation of "clock" algorithm in the late '60s (which he had
known). the point of the discussion was that i had also developed a
different class of LRU replacement algorithms during the early 70s
that had some interesting advantages over clock. specifically both
"clock" and this hybrid are approximations to a "true" LRU replacement
(i.e. the time of the most recent reference to every object in memory
could be exactly determined ... and all the objects could be exactly
ordered by the exact/true reference information).
Doing detailed trace-driven simulation studies, "clock" would be
measured as coming within X% (where X is typically in the 2-10 range)
of the performance of true LRU (i.e. almost as good as). The
interesting thing about the hybrid was that it was possible to find a
version of the hybrid that was 5-10% better than true LRU.
In any case, he had thought that his work on LRU "clock" like
replacement algorithms could significantly improve the performance of
the Huron buffer cache manager. He had forgotten about this other work
I had done on hybrid replacement algorithm. In any case, he became
interested in whether I would review and/or even possibly contribute
to the paper.
As to Huron database, he said that it was NOT a hiearchicial
implementation and had asked Amdahl to not describe it as such. Some
of the details sounds something like what Atherton went thru starting
with a RDBMS and then evolving to a RYO for unstructured real-world
data. Claim is that Huron can handle relational queries but also
maintains order (w/o having to sort on sequence field ... especially
evolving mega-entries) and can do direct links (w/o join overhead), as
well as not having to recompile apps when schemas change.
In any case, is there anybody out there that already has detailed
description of Huron database implementation?
... snip ... top of post, old email index
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 32 or even 64 registers for x86-64? Newsgroups: alt.folklore.computers Date: Thu, 26 Oct 2006 17:05:45 -0600Peter Flass <Peter_Flass@Yahoo.com> writes:
in my previous post
https://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
i had referenced my original post in the thread:
https://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?
which included email from 1981
https://www.garlic.com/~lynn/2006t.html#email810812
and 1982
https://www.garlic.com/~lynn/2006t.html#email820929
where the term "risc" was used ... somewhat in conjunction with 801. I
had also added alt.folklore.computers ... in part because of the
included references from the early 80s.
the referenced 1981 email included somebody's comment that possibly Berkeley had "ripped" off the basic idea for risc from 801.
in the previous post that you referenced
https://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
I followed up with additional email from 1978,
https://www.garlic.com/~lynn/2006t.html#email781128
1979,
https://www.garlic.com/~lynn/2006t.html#email790607
https://www.garlic.com/~lynn/2006t.html#email790711
and 1981
https://www.garlic.com/~lynn/2006t.html#email811104
that also included 801 references.
... aka RISC dates back to earlier than HP circa 1989 ... or Berkeley in
the early 80s ... but to original 801 from the mid-70s.
https://www.garlic.com/~lynn/subtopic.html#801
which I've frequently commented was possibly a reaction to the
failed future system project
https://www.garlic.com/~lynn/submain.html#futuresys
where 801 appeared to take nearly the opposite tack from that of the future system project with regard to hardware complexity.
and just for the fun of it, other posts that include early emails that
mention 801
https://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
https://www.garlic.com/~lynn/2003j.html#42 Flash 10208
https://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
https://www.garlic.com/~lynn/2006c.html#3 Architectural support for programming languages
https://www.garlic.com/~lynn/2006o.html#45 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#15 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#39 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: more than 16mbyte support for 370 Newsgroups: alt.folklore.computers Date: Fri, 27 Oct 2006 09:06:29 -0600for another old email ... here is comment on proposal for adding >16mbyte real storage to 370 (originally 3033, but also used with 3081s and 3090s in 370 mode)
this also was somewhat intertwined with comparisons of clusters of
4341 that had aggregate greater thruput and less cost than 3033. part
of this was that 4.5mips 3033 could only be configured with 16mbytes
real storage ... while six 4341s (easily aggregate six mips) could
have an aggregate of 96mbytes real storage (@16mbytes each) ... for
about the same cost. this was in the era when real storage was
increasingly being used to compensate for the lack of disk relative
system thruput (i.e. systems were getting faster and disks were
getting faster, but the rate that disks were getting faster was much
less than the rate that cpus and memories were getting faster).
misc. posts from this year mentioning 370 >16mbyte real storage:
https://www.garlic.com/~lynn/2006b.html#34 Multiple address spaces
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
https://www.garlic.com/~lynn/2006l.html#2 virtual memory
https://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine
https://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
https://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?)
https://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
misc posts from this year mentioning 4341 clusters:
https://www.garlic.com/~lynn/2006b.html#39 another blast from the past
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006l.html#2 virtual memory
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
https://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
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?
misc. posts from this year mentioning the declining relative system thruput
of disks:
https://www.garlic.com/~lynn/2006.html#4 Average Seek times are pretty confusing
https://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
https://www.garlic.com/~lynn/2006f.html#1 using 3390 mod-9s
https://www.garlic.com/~lynn/2006j.html#2 virtual memory
https://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
https://www.garlic.com/~lynn/2006o.html#65 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?)
https://www.garlic.com/~lynn/2006r.html#31 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/2006r.html#37 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
misc. posts from this year moving nearly all of vm370 spool file support
itno virtual address space:
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby MVS???
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006p.html#28 Greatest Software Ever Written?
https://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
https://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
https://www.garlic.com/~lynn/2006s.html#25 VM SPOOL question
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? Newsgroups: alt.folklore.computers Date: Fri, 27 Oct 2006 10:00:22 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
... in the following old email, DWSS was part of the original
technology transfer of system/r to endicott for sql/ds (vm370 support
for r/w, "unprotected" shared segments)
Date: 02/27/80 08:37:42
From: wheeler
To: numerous people in Endicott
re: yesterday's protect bit discussion.
It does make a difference whether the protect bit is in the page table
entry or segment table entry (page table entry bit , I think may have
originated MVS 811 hardware to provide them selective storage
protection in addition to don't trash/stomp on page zero for system
protection).
Segment table entry protect bit provides selective protection for some
users and the possibility of no protection for others, i.e. some
virtual address space have R/W shared segments (DWSS) and others only
have R/O access. Segment table protect bit was also defined in the
original 370 architecture.
... snip ... top of post, old email index
other refs in this thread
https://www.garlic.com/~lynn/2006s.html#64 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2006t.html#1 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2006t.html#2 Is the teaching of non-reentrant HLASM coding practices ever defensible?
collected posts mentioning original relational/sql implementation,
https://www.garlic.com/~lynn/submain.html#systemr
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: old Gold/UTS reference Newsgroups: alt.folklore.computers Date: Fri, 27 Oct 2006 10:38:32 -0600so the old trivia about why Amdahl Unix was referred to as "gold" before it was announced as UTS?
note that ibm was doing tss/370 rpq for bell ... ssup. this was all of
the tss/370 ui/api stripped away and unix interfaced to low-level
tss/370 kernel.
Date: 03/17/80 08:42:26
From: wheeler
Talked to people from Amdahl for two hours about UNIX. They now have a
PHD who started working on putting up UNIX under VM while at
Princton. It is now up and running at Amdahl production. Claim is
that it represents more of a load on the VM system than either SCPs or
CMS.
Somewhat simpler than CMS. By convention and/or design system tends to
two and three letter commands w/o arguments. There might be 20 or 30
versions of a program like copyfile and since the possible two letter
commands starting with 'C' is limited there would be a tendency to use
any available two letter combination rather than go to 3 or 4
letters.
Comment is that it has become something a 'cult' among computer
science graduates (at least one of the people had used UNIX for 4-5
years in college) and fealing was that the high use of UNIX at Amdahl
(over CMS) wasn't really justified. However from Bell's stand point,
it's availability across the line of computers is very attractive.
... snip ... top of post, old email index
previous post mentioning ssup/unix and uts ... including email from
'84 talking about benchmark comparing ssup/unix and uts
https://www.garlic.com/~lynn/2006e.html#31 MCTS
other posts mentioning ssup/unix and/or uts:
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
https://www.garlic.com/~lynn/99.html#2 IBM S/360
https://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000c.html#8 IBM Linux
https://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001e.html#19 SIMTICS
https://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
https://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
https://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001l.html#8 mainframe question
https://www.garlic.com/~lynn/2001l.html#17 mainframe question
https://www.garlic.com/~lynn/2001l.html#18 mainframe question
https://www.garlic.com/~lynn/2001l.html#20 mainframe question
https://www.garlic.com/~lynn/2002f.html#42 Blade architectures
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
https://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
https://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
https://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2003d.html#54 Filesystems
https://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
https://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
https://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
https://www.garlic.com/~lynn/2003i.html#53 A Dark Day
https://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#16 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
https://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005m.html#4 [newbie] Ancient version of Unix under vm/370
https://www.garlic.com/~lynn/2005m.html#7 [newbie] Ancient version of Unix under vm/370
https://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
https://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D
https://www.garlic.com/~lynn/2006b.html#24 Seeking Info on XDS Sigma 7 APL
https://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
https://www.garlic.com/~lynn/2006e.html#33 MCTS
https://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
https://www.garlic.com/~lynn/2006f.html#27 Old PCs--environmental hazard
https://www.garlic.com/~lynn/2006f.html#28 Old PCs--environmental hazard
https://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
https://www.garlic.com/~lynn/2006p.html#22 Admired designs / designs to study
https://www.garlic.com/~lynn/2006p.html#26 Admired designs / designs to study
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why magnetic drums was/are worse than disks ? Newsgroups: alt.folklore.computers Date: Fri, 27 Oct 2006 12:41:17 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
some old email discussing page allocation rework ... somewhat motivated
by the 3350 fixed-head feature
Date: 01/19/80 10:45:54
From: wheeler
To: several people in POK
re: design for contiguous allocation of paging backing store.
ref: SYSPAG script file.
New entry point can be defined in DMKPGT to allocate contiguous blocks
(similar to the current 2305 code, possible to enhance that code so
that it would serve both purposes). DMKPGM will be responsible for
determining if continguous allocation areas are required. It will
call PGT to allocate the contiguous space. A SYSPAG block will be
built which is chained off of the VMBLOK & points to an ALOCBLOK for
the contiguous storage. The SYSPAG block will also point back into the
normal SYSPAG chain allocation. Normal PGT allocation on reaching the
end of preferred , non-drum SYSPAG (at the smae place a test is made
to determine if the preferred paging area 'full' flag is to be set), a
check will be made for the existance of a VMBLOK's SYSPAG block. If
one is found, the SYSPAG register pointer will be switched to the
VMBLOK's SYSPAG block (the VMBLOK, SYSPAG block will point back into
the SYSPAG chain if no room is found in the VMBLOK area). DMKUSO will
be responsible for releasing all the control blocks and allocate
areas.
... snip ... top of post, old email index
now in the following, the reference to DMKPGM was to page migration
function that I had introduced as part of my resource manager
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
which included a lot of stuff i had done as an undergraduate for cp67 and then was subsequently dropped in the morph to vm370 ...
.... in new syspag, since there was a different structure for chain
structure for allocation and deallocation ... just by removing all the
relavent blocks from the allocation structure ... and then invoking
page migration to move everything off a specific device ... there was
no problem interlocking new pages getting allocated on the device
(while page migration was running). the separate allocation and
deallocation structures ... also made it possible to allow for a
user-specific contiguous page allocation ... as mentioned in the above
email.
Date: 02/27/80 18:58:19
From: wheeler
To: several people in POK
A couple of additional points showed up today. SYSPAG allocation
blocks are alwas constructed whether anything was specified at all or
not. Attach/CPI subroutine will build default structure/ordering
if no SYSPAG specifications have been made. Benefit is that PGT code
is small, simple, short , and fast and the same alwas. Complex
desisions are made when blocks are built (and or merged).
This is of a lot of benefit because of frequent use of PGT compared
to DMKCPI.
Another point came up. Requirment was to take volumes off line. Turns
out SYSPAG structure easily supports implementation. All allocation
blocks are double threaded. One way for allocation search and a
different chain for de-allocation. Take about 75% of existing code in
DMKPGM, put in another 300 or so lines of code and you have vary off
support of paging packs. New module would unchain all blocks for
specific device from allocation chain, but leave on de-allocation
chain. Then PGM code would be turned loose for pages on the specific
device. When finished allocation blocks could be unchained from
de-allocation chain and FRET'ed. I said in the document that design
was open ended to allow dynamic re-organization of chains.
... snip ... top of post, old email index
a past post also mentioning syspag work:
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
another past post mentioning syspag work ... as well as subsequent
work on "big pages" (originally for 3380s) which somewhat subsumed
much of the earlier demand page-at-a-time optimization:
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: old vm370 mitre benchmark Newsgroups: alt.folklore.computers Date: Fri, 27 Oct 2006 13:21:18 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
Problem with benchmarking Mitre paging changes is that they included "BU" (boston univ) 3330 paging performance enhancements. The problem was that only able to do 3330 multi-page transfer in single revolution on 145/148/4341 and 168 ... attempting it on 158 and any 303x could result in severe performance degradation ... because there would be additional full revolution for each page transfer ... which not only tied up the device ... but the disk controller (locking out all other disks on the same controller) and the channel.
the "2880" is the external channel box used by 370/168. 145/148/4341
had integrated channels ... as did the 370/158. as mentioned before,
the 370/158 integrated channels was basis for the external 303x
channel director box used by all 303x models.
Date: 02/28/80 12:12:17
From: wheeler
To: numerous vm370 product support people
re: benchmark Mitre paging changes;
somebody got a little 'took' on those changes. They include head
switch 3330 changes from BU off the Waterloo tape. I sent out detailed
info to at least some of you over a year ago.
Specs for 3330 don't allow enuf time to head switch between records
with less than a 110 dummy record gap between pages. 3330 track is
only spec'ed at about 100-101 bytes available for dummy record. BU
went ahead an put in changes for head switching on their 145 system
using 101 byte gaps (and optional code to count the number of
successful head switches). I got same code benchmarked on 145, 158,
168, 3031, 3033; with ISCs, with 3830s, with&w/o string switching. Also
got 168 benchmark with IBM drives, CDC drives, and Memorex drives.
145&168 on all combinations of IBM drives and CDC drives were able to
successfully switch almost 100% of the time (Memorex drives could do
head switch with 50 byte gaps 100% of the time).
158 at its best would only be successful about 20% of the time, the
rest of the time requiring additional revolutions.
Turns out 145 channels are the best of the 370 line (rated around 2.7
megabyte capacity according to the engineers), then the 2880 and then
the 158 channels. The 158 channels are by far the slowest of the
three. It also turns out the 303x share the same hardware channel
directors and all have performance numbers in this area comparable to
the 158. It turns out that the channel directors are substantially 158
boxes. 148 are substantially 145 channels and I believe the 4341
channels are somewhat better.
I also 'warned' several IBM'ers to be wary of upgrading 168s with BU
mods. and heavy 3330 paging to same configuration on any 303x because
they may experience a degradation of thru-put.
I can somewhat understand the questionable benchmark results that was
obtained by IBM running the Mitre mods. on 158 with 3330 paging.
... snip ... top of post, old email index
other posts in the referenced thread:
https://www.garlic.com/~lynn/2006r.html#34 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006r.html#42 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006r.html#43 REAL memory column in SDSF
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks?; Now : Programming practices Newsgroups: alt.folklore.computers,comp.lang.fortran Date: Fri, 27 Oct 2006 14:14:19 -0600glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> writes:
here is more discussion (from quicky use of search engine) for "VOL1"
and "HDR1"
http://it-dep-fio-ds.web.cern.ch/it-dep-fio-ds/Documentation/tapedrive/labels.html
above also discusses ansi x3.27 standard and dec systems use.
some of the current tape library software managing later generations of large capacity tapes do volume stacking ... where a single physical tape will contain images of multiple logical tape volumes.
search engine reference included volume stacking
http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/topic/com.ibm.filemanager5.doc/base/fmnu1e02233.htm
misc. other search engine URLs mentioning VOL1 and HDR1
http://www.vsoftsys.com/doc/doc42/vtape/vtap4006.htm
http://operations.rutgers.edu/tapes/tape_formats.html
http://www-03.ibm.com/servers/eserver/zseries/zvse/downloads/tools.html
http://groups.google.com/group/alt.sys.pdp11/browse_thread/thread/d043a37616ff4e19/ac76930d628ef0fa
http://www.decus.org/libcatalog/document_html/vs0097_8.html
http://cnlart.web.cern.ch/cnlart/234/art_tlab.html
http://www.cbttape.org/awstape.htm
http://mitvma.mit.edu/cmshelp.cgi?CMS%20TAPEMAC%20
http://mitvma.mit.edu/cmshelp.cgi?CMS%20TAPPDS%20
http://pcmap.unizar.es/softlinux/VMS-to-Linux-HOWTO.txt
search engine even turns up one of my old pasts mentioning VOL1 and
HDR1:
https://www.garlic.com/~lynn/2004q.html#20 Systems software versus applications software definitions
which discusses an old backup/archive system that i had written for
internal use ... which then went thru several iterations and
eventually released as workstation datasave facility, morphed into
ADSM and is now known as TSM
https://www.garlic.com/~lynn/submain.html#backup
in Melinda's section on CMSBACK in her history
https://www.leeandmelindavarian.com/Melinda/25paper.pdf
her history starts with what would be considered "version 3" (or maybe version 4) of CMSBACK. I had done the implementation and deployment for the initial version; then another person and I did quite a bit of enhancements. The other person that I worked with, left IBM and went on to do development for some number of other (non-ibm) vm archive/backup systems (and I started work on other projects). It was in this period, that it was turned over to the two people mentioned in Melinda's history related to CMSBACK.
Between the start of that phase in CMSBACK development and the release of workstation datasave facility (precursor to ADSM), there was an effort (not mentioned in Melinda's history) to get Endicott to make it available as a product. Endicott evaluated marketing one of the non-IBM products or releasing the internal CMSBACK. At that time, Endicott chose to market one of the non-IBM products (much of that development had been done by the same person that I had worked with on the earlier CMSBACK version).
from Melinda's paper
ADSM had its origins in about 1983 as a program called CMSBACK,
written by two VM support people at IBM's Almaden Research, Rob Rees
and Michael Penner. CMSBACK allowed CMS users to back up and restore
their own files. It quite naturally became the basis a few years later
for a program to allow workstation users to back up and restore their
files, which was announced as the WDSF/VM product in 1990. By that
time, VM Development in Endicott had gotten involved, doing much of
the work required to bring the new product to market.
... snip ...
CMSBACK actually dates back a number of years earlier, before Almaden was built and/or the two mentioned individuals had even been hired.
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, 27 Oct 2006 14:58:22 -0600"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
min(iq1, iq2, ... iqN)
but then instead of the avg
sum(iq1, iq2, ..., iqN)/N
it may be more like
sum(iq1, iq2, ..., iqN)/(N**2)
sum of the inidividual IQs divided by the square of the number of individuals ... instead of tending to the lowest IQ in the group ...it quickly tends to zero as the size of the group grows (avg group IQ divided by the number of members) ... possible
min(iq1, iq2, ..., iqN)/N
or the minimum IQ divided by the number of members.
there has been this constant thread about not enuf trained resources dating back to at least the mid-70s ... and probably long before.
in the mid-70s ... the 370/148 project wanted to go after a greatly increased market ... but they recognized that there wasn't enuf traditional skilled resources. they needed to dumb down the skill requirements for supporting systems (although they didn't express it in those terms) ... which in turn required layer of software that automatically did lots of the stuff that had previously been done by skill support person.
the two analogies that were frequently used in the mid-70s were
1) Ford trying to figure out how to drastically expand market for the Model T ... up until then automobiles required a chauffeur that was also a fairly skilled mechanic. over time, automobile use was drastically simplified so that they could be operated by people that may not have the slightest idea of how they worked.
2) phone company project that to expand telephone use would require hiring at least half of the adults in the country as operators. the phone paradigm was changed with each user becoming their own operator ... aka they did their own dialing ... which was then handled by automatic switching equipment.
part of expanding the market was making the computer product significantly less expensive and more of a commodity. at some point, the market inhibitor became not the expense of the product ... but the cost of the highly trained talent needed to support the product. at some point the necessary highly trained talent could be several times more expensive than the product itself. so attempts are made to lower skill level necessary for operating computer products comparable to that necessary for operating an automobile (or a telephone).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: threads versus task Newsgroups: comp.arch Date: Sat, 28 Oct 2006 10:09:34 -0600anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
For a lot of things, TCB was fairly heavyweight system construct ... especially for some of the evolving online applications. So you saw "subsystems" like CICS showing up in the late 60s that supported their own (lightweight) tasks (very much akin to the later lightweight threads some 20 years later) ... where the "subsystem" providing its own (lightweight) process creation and serialization operations. In the later 70s, you might find a CICS regions controlling tens of thousand and then hundreds of thousands of ATM machines ... even later there would be CICS regions that handled millions of (cable) settop boxes.
in any case, tasks were system (or subsystem) control and resournce management construct. multiprogramming could be done with system tasks or cooperating operations within a single task (and single address space). this got more complicated when os/360 morphed into virtual address space operation for each "task" in the mid-70s as "MVS" (default was that "task" and "address space" was somewhat equivalent ... but then you could use system tasking facilities to invoke multiple tasks in the same address space).
at the science center in the late 60s and early 70s, Charlie was doing a lot of work on multiprocessor fine-grain locking in the cp67 kernel and invented the compare&swap instruction (compare&swap mnemonic chosen because CAS are Charlie's initials). The initial attempt to try and get compare&swap included as part of (the new) 370 architecture was rejected on the grounds that test-and-set (left over from 360) was sufficient for multiprocessing control.
The challenge was that in order to get compare&swap justified in 370 ... a non-multiprocessor specific use was needed. Thus was born the use examples for atomic instruction for multiprogramming operations ... that aren't necessarily multiprocessor related. In the early 70s, the multiprogramming use examples were originally part of the instruction programming notes in the 370 principle of operations. later principles of operation moved the use examples to the appendix.
a couple recent posts mentioning comapre&swap
https://www.garlic.com/~lynn/2006s.html#21 Very slow booting and running and brain-dead OS's?
https://www.garlic.com/~lynn/2006s.html#53 Is the teaching of non-reentrant HLASM coding practices ever defensible?
while multiprogramming and system TASKs are somewhat loosely related ... TASKs can be in different address spaces ... and multiple execution in the same address space can be done w/o (heavyweight) system TASKS.
recent principles of operation appendix reference
A.6 Multiprogramming and Multiprocessing Examples
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320
from above:
When two or more programs sharing common storage locations are being
executed concurrently in a multiprogramming or multiprocessing
environment, one program may, for example, set a flag bit in the
common-storage area for testing by another program. It should be noted
that the instructions AND (NI or NC), EXCLUSIVE OR (XI or XC), and OR
(OI or OC) could be used to set flag bits in a multiprogramming
environment; but the same instructions may cause program logic errors
in a multiprocessing configuration where two or more CPUs can fetch,
modify, and store data in the same storage locations simultaneously.
Subtopics:
• A.6.1 Example of a Program Failure Using OR Immediate
• A.6.2 Conditional Swapping Instructions (CS, CDS)
• A.6.3 Bypassing Post and Wait
• A.6.4 Lock/Unlock
• A.6.5 Free-Pool Manipulation
• A.6.6 PERFORM LOCKED OPERATION (PLO)
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: threads versus task Newsgroups: comp.arch Date: Sat, 28 Oct 2006 13:07:19 -0600nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
the mid-60s os/360 philosophy heavily revolved around *scarce* real storage assumptions. the apis were all pointer passing and the i/o model involved direct transfers involving application buffers. the physical i/o commands were built directly by applications pointing to their real buffer addresses (and/or library routines directly called by applications).
the i/o library routines provided a number of asynchronous and synchronous abstractions. the asynchronous abstractions for i/o provided a natural multiprogramming environment ... where application logic might possibly be dealing with multiple i/o buffers and overlapping execution with i/o transfer ... requiring various amounts of WAIT operations for serialization.
one might assert that the posix activity from the late 80s and early 90s for async i/o and threading was to translate this mid-60s paradigm into unix environment (some number of dbms applications would take advantage of such features ... somewhat emulating operation of online os/360 dbms activity dating back to the 60s).
the os/360 transition to virtual address spaces in the mid-70s carried with it a number of problems.
the application convention of building the physical i/o commands no longer used real addresses ... but were virtual (buffer) addresses. the low level kernel function supporting application i/o had to be enhanced to scan/interpret the application i/o command operations, create *shadow* copy of the application i/o command sequence, translating all the virtual addresses into real addresses (as well as fetching and pinning the associated virtual pages until the real i/o sequence had completed).
the prevalent use of pointer passing in APIs resulted in the kernel code sharing the application address space. Initially in mvs/370 with 16mbyte virtual address spaces, one per application ... the kernel occupied half of the 16mbytes, in theory leaving 8mbytes for each application.
however, the os/360 heritage also had a lot of "subsystem" services that weren't part of the kernel, each were now in their own unique virtual address space ... but still "called" by applications with pointer passing api. Initially this was addressed by a "common segment" that appeared in every virtual address space where parameters could be stashed and then directly accessed by subsystems using the passed (parameter address) pointers. However, for large operations with a large number of possible different subsystems, it wasn't uncommon to find that the "common segment" had to be expanded to five mbytes. With the kernel taking 8mbytes out of each address space and "common segment" taking 5mbytes (and potentially still growing), it would only leave 3mbytes for applications use.
to help address this problem, 3033 (introduced in the late 70s) provided "dual-address" space support. A new addressing mode was provided to semi-privileged subsystems (running in their own address space) that allowed them to "reach" across into application virtual address space and access the parameters that needed to be referenced in the pointer-passing API. A subsystem implementation, running in its own virtual address space could be multiprogrammed with each invokation having its own state consisting of registers and instruction address ... as well as control register pointing to the invoking application virtual address.
Later (mvs/xa) 370 virtual addressing was increased from 24bit to
31bit and dual-address space support was generalized with access
registers and multiple address space operation. Not only could
subsystems reside in their own address space ... but a lot of the
former system library software that was loaded and executed as part of
an application could be moved into unique semi-privileged address
space. A new hardware call instruction was defined that referenced a
system defined table which controlled switching address space pointers
and some number of other access control features. The operation could
appear still as if it was direction executing under the application
task control block (and resource control) ... but instead of execution
continuing in a library routine in the application address space
... execution was continuing in a library routine that resided in a
totally different address space. more detailed discussion of
access registers and multiple address space operation
https://www.garlic.com/~lynn/2006r.html#32 MIPS architecture question - Supervisor mode & who is using it?
Sort of the original default was a single TCB (for resource control) mapping to a single application (and later a single address space). However, various options and features allowed this to get potentially extremely complicated with possibly multiprogramming under a single TCB (providing something akin to multi-threading in single process), multiple TCBs operating in the same address space, a single TCB with multiple address spaces, and/or multiple TCBs and multiple address spaces.
in unix environments ... w/o posix async i/o and threading ... you had DBMS translated (to unix) where there were multiple different processes and address spaces ... with the address spaces setup to share a lot of common storage (in order to simulate lightweight threading in a single address space). early on, the DBMS would implement "raw" I/O to the physical device ... in order to achieve the effect of asynchronous operation and direct transfers to/from application memory/buffers.
somewhat in parallel with os/360 with real storage later morphing into
virtual memory MVS system ... there was the original cp67 virtual
machine system ... started originally in 1966 as cp40 with a custom
modified 360/40 with virtual memory. In 1967, cp40 morphed into cp67
when standard virtual memory 360/67 machines became available. cp67
made extensive use of the virtual memory hardware in its virtual
machine implementations. later cp67 morphed into vm370 when virtual
memory became available on 370s. melinda's vm370 history, mentioning
ctss, multics, cp40, cp67, etc
https://www.leeandmelindavarian.com/Melinda/25paper.pdf
the original relational/sql implementation was system/r done in
the 70s on vm370 platform
https://www.garlic.com/~lynn/submain.html#systemr
this made use of multiple virtual address spaces with some amount of
the virtual address space shared across independent cooperating
processes (virtual machines) recent post mentioning some of the
technology transfer for system/r from san jose to endicott for sql/ds
product
https://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
it is somewhat this model in the mid to late 80s, that you saw some DBMS vendors translating into unix environment with multiple processes each with their different address spaces ... where the different address spaces shared some amount of common storage (and DBMS was using unix "raw i/o" for accessing disks for futher asynchronous operation)
some other recent posts mentioning dual-address space and/or access
register operation
https://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
https://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
https://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
https://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006i.html#33 virtual memory
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006r.html#26 A Day For Surprises (Astounding Itanium Tricks)
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: CMSBACK Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l Date: Sat, 28 Oct 2006 14:17:47 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
old email from the other person working on CMSBACK version 2. this is on enhancing the pattern matching capability in the user interface file retrieval process (from the backup/archive repository).
as noted in the above reference, Melinda's history starts with what
would be CMSBACK version 3 (or possibly 4 ... depending on how you
classify all the work done between my initial CMSBACK deployments and
start of work by the people mentioned in Melinda's history).
https://www.leeandmelindavarian.com/Melinda/25paper.pdf
Date: 10/25/79 02:11:58
To: wheeler
I had to make one change to OSPATM to make it work. The macro SREGS is
a bit too much for me tonite so I replaced the one to set up
addressability to the work area using R5 with the L R5,8(,R1) and
USING PATSPC,R5. AND...... it works like a super star!!!! Try issuing
the CMSBACK exec, ask for a report, and enter whatever patterns you
like.. Disk load the returned RPT file and see what you get.. I've
been playing with it now for a while and it really works great. (I
will make the matching available on date and time tommorrow.. why
stop with just the filename and filetype).
... snip ... top of post, old email index
for the original low-level CMSBACK interface to tape, I used a highly
modified version of VMFPLC (mentioned in the old email below) that I
had renamed VMXPLC. Not mentioned in the below ... but it was also
enhanced to provide optimal processing for the paged mapped filesystem
implementation that I had done
https://www.garlic.com/~lynn/submain.html#mmap
start of buffers were page aligned ... and 15 800 byte data blocks
could be three 4096 byte blocks. For small files, the minimum size
data block on tape could be 800 bytes. With separate FST record and
data block, a tape with a lot of small files would have half (or more)
of the length could be taken up with interrecord gaps. Merging the FST
record and the first data record into the same physical tape record,
would cut the tape devoted to interrecord gaps in half (when lots of
small files was involved).
Date: 03/21/80 13:41:39
From: wheeler
To: somebody in endicott
The original VMFPLC was an update to release 2 DMSTPE. The code took
the FST record which is placed in a trailing 800 byte record following
the file dumped and placed it in a 59 byte record in front of the file
dumped. It also blocked up to 5 800 byte data blocks per physical tape
block. I captured the update early and maintained it (I heard that the
development lost it and didn't have a copy) against the current
release & plc level. I also enhanced the update to block up to 15 800
byte data blocks, to merge the FST record into the 1st physical data
block dumped and to avoid rewriting the MFD after each file loaded.
VMFPLC2 appears to have several new features which would indicate that
it is not a modification of the original VMFPLC (since as far as I
know, I'm the only one with the source) but it still maintains the
original tape format. I must confess that I've not looked at the new
release 6/bsepp tape source (although I've heard that it has grown
substantially and has been split into several files).
... snip ... top of post, old email index
and for an even earlier CMSBACK related email. standard CMS could
"share" various filesystem areas across multiple virtual
machines. However, the filesystem status information would be
duplicated in every virtual address space. A hack was done to place a
copy of some shared CMS filesystem information in shared (r/o
protected) memory ... so there only need to be a single physical copy
of the filesystem metadata (shared across everybody). The "problem"
for DMSDSK, DMSTPE, VMFPLC and VMXPLC was that there was a hack where
they temporarily modified the file metadata that forced the logical
record size to match the physical disk record ... and then restore it
when they were done. This hack would fail if the file metadata
information was located in shared (r/o protected) memory.
Date: 04/02/79 19:22:35
From: wheeler
Yorktown has done an update for DMSDSK (DISK DUMP) to handle the
problem of dumping from a disk with FST in shared memory
(DMSDSK YK187DMS). Can you merge with what you have been doing to
DMSTPE for TAPE, VMFPLC, & VMXPLC??????
... snip ... top of post, old email index
and a related reference from Almaden Research
http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml
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: Sun, 29 Oct 2006 00:33:33 -0600Charlton Wilbur <cwilbur@mithril.chromatico.net> writes:
and some other recent posts discussing some related threat issues:
https://www.garlic.com/~lynn/2006s.html#10 Why not 2048 or 4096 bit RSA key issuance?
https://www.garlic.com/~lynn/2006s.html#11 Why not 2048 or 4096 bit RSA key issuance?
https://www.garlic.com/~lynn/2006t.html#2 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2006t.html#8 Root CA CRLs
various past collected posts related to assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance
as opposed to various past collected posts related to threats,
vulnerabilities, fraud, and/or exploits:
https://www.garlic.com/~lynn/subintegrity.html#fraud
and a post from today about possibly new exploit
https://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Universal constants Newsgroups: alt.folklore.computers Date: Sun, 29 Oct 2006 00:53:01 -0600Steve O'Hara-Smith <steveo@eircom.net> writes:
GAO Chief Warns Economic Disaster Looms, GAO Chief Takes to Road,
Warns Economic Disaster Looms Even As Many Candidates Avoid Issue
http://www.cbsnews.com/stories/2006/10/28/ap/business/mainD8L1OC5G0.shtml
GAO Chief Warns Economic Disaster Looms
http://www.washingtonpost.com/wp-dyn/content/article/2006/10/28/AR2006102800420.html
GAO Chief Warns Economic Disaster Looms
http://news.moneycentral.msn.com/provider/providerarticle.asp?feed=AP&Date=20061028&ID=6145849
GAO Chief Warns Economic Disaster Looms
http://abcnews.go.com/Politics/wireStory?id=2613135
GAO Chief Warns Economic Disaster Looms
http://www.latimes.com/news/nationworld/politics/wire/sns-ap-america-the-bankrupt,1,515499.story?coll=sns-ap-politics-headlines
GAO Chief Warns Economic Disaster Looms
http://hosted.ap.org/dynamic/stories/A/AMERICA_THE_BANKRUPT?SITE=DCUSN&SECTION=TOP_STORIES&TEMPLATE=DEFAULT
GAO Chief Warns Economic Disaster Looms
http://apnews.myway.com/article/20061028/D8L1OC5G0.html
GAO chief warns economic disaster looms
http://seattlepi.nwsource.com/national/1155AP_America_the_Bankrupt.html
posts from last spring about his talk
https://www.garlic.com/~lynn/2006g.html#9
https://www.garlic.com/~lynn/2006g.html#14
https://www.garlic.com/~lynn/2006g.html#27
https://www.garlic.com/~lynn/2006h.html#2
https://www.garlic.com/~lynn/2006h.html#3
https://www.garlic.com/~lynn/2006h.html#4
https://www.garlic.com/~lynn/2006h.html#17
https://www.garlic.com/~lynn/2006h.html#19
https://www.garlic.com/~lynn/2006h.html#33
and post from late summer with some excerpts from his talk
https://www.garlic.com/~lynn/2006o.html#61
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Sun, 29 Oct 2006 08:51:58 -0700The Future of CPUs: What's After Multi-Core?
from above (the new, 40yr old thing)
This rule was driven home to me when I attended a talk by an IBM
engineer about his company's new virtualization technology. He
commented that his company had an advantage over other people working
in the area: Whenever they were stuck, they could go along the hall to
the mainframe division and ask how they solved the same problem a
couple of decades ago.
... snip ...
semi-related thread from comp.arch
https://www.garlic.com/~lynn/2006t.html#23 threads versus task
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers,comp.lang.fortran Date: Sun, 29 Oct 2006 09:11:20 -0700Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
I was using a free package off the web that had various limits on the number of variables that it could handle ... which would have been pretty much eliminated using SAS.
the original reference to performance analysis work in the early and
mid-70s at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
that eventually evolved into things like capacity planning
https://www.garlic.com/~lynn/submain.html#bench
had used multiple regression analysis from the fortran scientific subroutine package. i have some vague memory that when the scientific subroutine package was discontinued ... all of that stuff was possibly picked up by SAS(?).
the other language that was used extensively in that period was APL
... including significant amount of performance and system modeling.
One such (APL) application from the science center eventually evolved into
the performance predictor available on the internal HONE system
providing worldwide support to field, sales, and marketing people
https://www.garlic.com/~lynn/subtopic.html#hone
customer profile information could be input (workload, configuration, performance, etc) and "what-if" questions could be asked regarding what happens if there were changes in workload and/or configuration.
in the 70s and 80s there was quite a bit of use of APL for modeling and "what-if" scenarios ... a lot of which subsequently migrated to various spreadsheet technologies.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Storage Philosophy Question Newsgroups: bit.listserv.ibm-main Date: Sun, 29 Oct 2006 09:47:50 -0700rfochtman@ibm-main.lst (Rick Fochtman) writes:
i remember places like Chicago Board of Trade also being affected
wasn't it construction or some other event that resulted in a break in subsurface dam/barrier that was designed to keep the lake out?
note that even if the computer rooms aren't there ... lots of the related utilities, power backup, etc ... frequently are.
this is akin to the multitude of backhoe vulnerabilities; possibly one of the most famous was the isolating the new england internet several years ago. supposedly the original infrastructure had carefully laid out diverse routing for nine different circuits running over nine different physical trunks. over the years, while nobody was paying attention, all the circuits were eventually consolidated into one physical trunk ... which one day was attacked by a backhoe and taken out.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers,comp.lang.fortran Date: Sun, 29 Oct 2006 10:37:39 -0700jmfbahciv writes:
os/360 compilers and assemblers generated 80byte cards with 12-2-9 (0x02 hex) in column followed by ESD, TXT, RLD, etc.
ESD cards gave the "external" symbol information ... the names of entry
points into the program and names of external applications.
https://www.garlic.com/~lynn/2001.html#8 finding object decks with multiple entry points
https://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)
TXT cards contained up to 56 bytes of actual program instructions and
data
https://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
RLD cards contained the location (displacement in the program) of
"relocatable" address constants.
https://www.garlic.com/~lynn/2002o.html#26 Relocation, was Re: Early computer games
once the linker/loader had decided on the address for loading the program image ... it then had to run thru all the RLD information, finding the associated "relocatable" address constants and swizzling their values to correspond to actual memory address. that is in addition to "resolving" addresses (swizzling them also) of external program entry points.
recent posting discussing issues with os/360 convention of relocatable
address constants
https://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
https://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
https://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?
lots of posts about difficulty of translating os/360 (real memory)
relocatable address constant convention into page mapped filesystem
environment attempting to invoke program images that were r/o shared
across multiple address spaces (and not being able to modify/alter
the program image)
https://www.garlic.com/~lynn/submain.html#adcon
misc. others posts discussing format of 12-2-9 cards
https://www.garlic.com/~lynn/93.html#17 unit record & other controllers
https://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
https://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)
https://www.garlic.com/~lynn/2002f.html#41 Blade architectures
https://www.garlic.com/~lynn/2002h.html#1 DISK PL/I Program
https://www.garlic.com/~lynn/2002n.html#62 PLX
https://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
https://www.garlic.com/~lynn/2002o.html#25 Early computer games
https://www.garlic.com/~lynn/2004h.html#17 Google loves "e"
https://www.garlic.com/~lynn/2004p.html#24 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005c.html#54 12-2-9 REP & 47F0
https://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005t.html#47 What is written on the keys of an ICL Hand Card Punch?
https://www.garlic.com/~lynn/2006b.html#1 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#17 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006g.html#43 Binder REP Cards (Was: What's the linkage editor really wants?)
https://www.garlic.com/~lynn/2006g.html#58 REP cards
https://www.garlic.com/~lynn/2006n.html#1 The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Sun, 29 Oct 2006 12:50:32 -0700jsavard writes:
my frequent theme has been that one of big PC market penetrations was
into commercial ... where a PC was about the same price as a 3270 ...
could provide both 1) 3270 terminal emulation and 2) some local
desktop computing in a single screen/keyboard footprint.
https://www.garlic.com/~lynn/subnetwork.html#emulation
once that enormous market penetration had been obtained ... it was difficult for anything else to compete (something of a snowball effect, large install base attracted a lot of application programmers, a lot of applications attracted bigger market). clones and plug-compatible was one of the few remaining approaches.
and for other drift related to cluster scale-up
https://www.garlic.com/~lynn/95.html#13
and ha/cmp work
https://www.garlic.com/~lynn/subtopic.html#hacmp
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Mon, 30 Oct 2006 12:56:05 -0700jsavard writes:
and for other drift than the previous mention related to working on
cluster scale-up while we were doing ibm's HA/CMP product
https://www.garlic.com/~lynn/subtopic.html#hacmp
sort of part of the earlier HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
... a recent HSDT post or two
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?
... the original ibm mainframe tcp/ip product had been implemented in vs/pascal ... however because of various issues ... it would consume nearly a whole 3090 processor getting 44kbytes/sec sustained thruput.
i did a rfc 1044 driver implementation (that was eventually shipped in
the product) ... which in some tuning at cray research got 1mbyte/sec
sustained between a cray and 4341-clone ... using only a modest amount
of the 4341-clone.
https://www.garlic.com/~lynn/subnetwork.html#1044
trivia item was we were to leave on flight from sfo to Minneapolis for dong some testing ... and was 20 mins or so late getting off the ground. part way thru the flight, i noticed a lot of whispering back in the galley and wandered back to see what it was all about. apparently something like five minutes after leaving the ground the earthquake had hit.
before the previously mentioned incident that drastically
changed their direction
https://www.garlic.com/~lynn/95.html#13
kingston had been providing some assistance to chen ... as well as
working on their own machine of somewhat similar design. for other
recent drift along this line.
https://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: threads versus task Newsgroups: comp.arch Date: Mon, 30 Oct 2006 23:52:25 -0700glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
reference overview
http://www-03.ibm.com/servers/eserver/zseries/library/refguides/pdf/gm130117.pdf
from above:
64-bit Real Storage Support
...
These z/OS functions are enhanced to exploit 64-bit real storage
above 2 GB:
• Traditional access Methods (BSAM, QSAM, and others)
... snip ...
or try this assembler example program of highly asynchronous processing
with BSAM
http://www.xephon.com/arcinframe.php//m033a08
then there is IBM Tivoli Storage Manager Performance Tuning Guide
http://publib.boulder.ibm.com/tividd/td/TSMM/SC32-9101-01/en_US/HTML/SC32-9101-01.htm
from above:
To use the BSAM overlap I/O buffering methods, a new server option is
available:
TAPEIOBUFS number of buffers
The number of buffers specifies a number from 1 to 9. If 1 is
specified, then Tivoli Storage Manager does not use the overlapping
I/O for 3590 tape media. If a number greater than 1 is specified,
Tivoli Storage Manager allocates the buffers based on the above
formula.
The use of this option may increase the I/O throughput with the 3590
tape media, but it requires more memory allocation for the address
space. An optimized throughput scenario is using this option set to 9,
with the UNIX System Service Socket and a Gigabit Ethernet.
... snip ...
a couple recent posts mentioning TSM history
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
Measuring I/O
http://as400bks.rochester.ibm.com/tividd/td/TDS390/SH19-6818-08/en_US/HTML/DRLM9mst60.htm
the above has a short description of "access methods" (i.e. library routines like bsam, qsam, etc, that build i/o channel program and then invoke "EXCP/SVC0" to pass the built i/o channel programs to the kernel for processing. QSAM library routines does the handling for buffer management and the WAIT serializations operations. BSAM library routines places that responsibility on the applications.
this is old research report describing os/360 data management
and mentioning bsam
http://www.research.ibm.com/journal/sj/051/ibmsj0501D.pdf
this is lengthy z/OS concepts with bits and pieces overview of
nearly everything
http://publib.boulder.ibm.com/infocenter/zoslnctr/v1r7/topic/com.ibm.zconcepts.doc/zconcepts.pdf
this is (vol2) z/OS assembler sevices macro manual ... that includes WAIT macro,
which has some new forms like if you are in cross memory mode.
http://publibz.boulder.ibm.com/epubs/pdf/iea2a920.pdf
and this is "vol1" ... which includes the ATTACH/ATTACHX macro for
creating new task:
http://publibz.boulder.ibm.com/epubs/pdf/iea2a760.pdf
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Tue, 31 Oct 2006 09:02:32 -0700jsavard writes:
3277 keyboard layout (from your web page)
http://www.quadibloc.com/comp/kyb01.htm
the 3277 had a lot of electronics in the head and keyboard of the terminal (and not all back in the 3272 controller). to cut down on manufacturing costs ... for the 3278 ... a lot of the electronics were moved back into 3274 controller (as well as cutting down on keys). this contributed to the increased response time ... and it also made it impossible to do some of the local hardware fixes on the terminal.
recent post that includes timing comparison of 3272/3277 against
3274/3278 (both channel attach):
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
we also had a "FIFO" box that could be placed inline between the 3277
keyboard cable and where it plugged into 3277 display head ... that
handled the half-duplex tendency to sporadically lock the keyboard and
block keystrokes. also were able to add resister inside the 3277
keyboard that adjusted the typamatic delay and typamatic repeat rate .. to
some reasonable value ... past post discussing both timing comparison
as well as being to do local fixes to 3277 terminal:
https://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
the original 3278 keyboard took the program function key position for
numeric keypad ... and made program function keys alternates ...
past post mentioning this
https://www.garlic.com/~lynn/2005e.html#33 Stop Me If You've Heard This One Before
when we started arguing about with the 3278 product group about program function keys (and slow 3274 controller and other stuff) ... they came back and said that the 3278 terminal wasn't designed for programmers and interactive computer use ... but for data entry applications.
you later got 3278 keyboard option with the pf1-pf12 across the top and pf13-pf24 on the right.
another of your web pages
http://www.quadibloc.com/comp/scan.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Universal constants Newsgroups: alt.folklore.computers Date: Tue, 31 Oct 2006 09:24:19 -0700jmfbahciv writes:
note that in several of the Boyd articles about desert storm and the Military Channel Legends of Air Power program on boyd ... they mentioned conflict between schwarzkopf and boyd over the battle plan ... boyd calling schwarzkopf plan something like "hey diddle, diddle, up the middle" (with tanks slugging it out until the winner is the last one standing).
using search engine for: desert storm schwarzkopf boyd hey diddle
Boyd's tactics and Operation Iraqi Freedom (illuminating background on
Iraq strategy)
http://www.freerepublic.com/focus/f-news/899525/posts
from above:
Coram: When Cheney became secretary of defense, he was rare in that he
knew more about strategy than most of his generals did. He called Boyd
out of retirement in the early days of the Gulf war, and from him got
an updating, if you will. And it was Boyd's strategy, not
[Gen. Norman] Schwarzkopf's, that led to our swift and decisive
victory in the Gulf war.
According to Bob Woodward's book, "The Commanders," Schwarzkopf was
"playing" the DC warplanners when he gave them his initial battle plan
(Hey-diddle-diddle, Up-the-middle). He expected that it would be
rejected and that he would therefore get the extra troops he was
asking for.
... snip ...
The Legends of Air Power boyd program mentions the Coram version (above), but not Woodward's
... misc. past posts mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
misc. URLs from around the web mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Tue, 31 Oct 2006 12:48:47 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
and somewhat afterwards ... defined hierarchical communication architecture for big terminal networks ... pretty much wrapped around vtam/sscp and 3705/ncp (or actually vtam/sscp and 3705/ncp wrapped around the sna architecture ... there were some number of people that complained that it didn't matter what sna architecture specified ... if you were to interoperate with vtam/3705, it had to conform to whatever vtam/3705 did ... and the two weren't always kept in total sync).
in that same time-frame ... my wife worked on a competing peer-to-peer
architecture (AWP39) that lost out to SNA. she then did a stint in the
JES2 group and then was con'ed into taking a job in pok in charge
of loosely-coupled architecture (mainframe for cluster) ... where
she origianted Peer-Coupled Shared Data architecture
https://www.garlic.com/~lynn/submain.html#shareddata
and had quite a few battles with the sna organization ... sort of resulting in a truce ... where non-SNA was allowed within the datacenter walls, but SNA was required whenever the wall of the datacenter was crossed.
this also gave us lots of headache in our high-speed data transport
project (HSDT) starting circa 1980s
https://www.garlic.com/~lynn/subnetwork.html#hsdt
and also contributed to the terminal emulation
https://www.garlic.com/~lynn/subnetwork.html#emulation
and 3-tier architecture (and SAA) wars
https://www.garlic.com/~lynn/subnetwork.html#3tier
also in approx. the same time that arpa was starting up ... the
internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
was originating at the cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech
which was non-hierarchical, non-sna, non-vtam, and frequently non-3705 (much more akin to the peer-to-peer network architecture, AWP39, that my wife worked on in the mid-70s).
recent posts mentioning size of internal network passing 1000
nodes in 1983 (year that arpanet switched over to internetworking
operation) ... also includes reference that there were approx. 250
hosts on the arpanet that required major changes as part of the 1/1/83
upgrade to internetworking
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/2006k.html#8 Arpa address
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
note while the previous reference indicated that there approximately 250
hosts on the arpanet that required major changes as part of the 1/1/83
upgrade to internetworking ... this ARPANET newsletter article was
predicting that there might be 100 arpanet nodes by sometime in 1983
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
it is possible that the difference between 100 arpanet nodes and 250 hosts ... was that on arpanet, the actual networking was handled by the outboard IMPs ... with hosts then running host-to-host protocol and connecting to the IMPs for the actual networking support (potentially allowing greater than one-to-one relationship between hosts and nodes).
by comparison, the internal networking implementation ... all of the networking support executed directly on each host (and had nothing to do with vtam ... which was the incarnation of hierarchical sna). any outboard telecommunication control unit ... purely provided the physical line point-to-point support (i.e. things like line scanner operation, translating between line signal rise/lower and bit or no-bit).
reference to computer history museum item on the more than 300
nodes/hosts on internal network in the 70s being instrumental in the
development and evolution of rexx
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?
i.e. (gone 404, but lives on at wayback machine)
https://web.archive.org/web/20050309184016/http://www.computinghistorymuseum.org/ieee/af_forum/read.cfm?forum=10&id=21&thread=7
from above:
By far the most important influence on the development of Rexx was the
availability of the IBM electronic network, called VNET. In 1979,
more than three hundred of IBM's mainframe computers, mostly
running the Virtual Machine/370 (VM) operating system, were linked by
VNET. This store-and-forward network allowed very rapid exchange of
messages (chat) and e-mail, and reliable distribution of software. It
made it possible to design, develop, and distribute Rexx and its first
implementation from one country (the UK) even though most of its users
were five to eight time zones distant, in the USA.
... snip ...
and recent posts about nsfnet backbone (operational precursor to modern
internet):
https://www.garlic.com/~lynn/2006s.html#20 real core
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#51 Ranking of non-IBM mainframe builders?
other posts this year mentioning AWP39 peer-to-peer networking architecture
effort:
https://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
https://www.garlic.com/~lynn/2006j.html#31 virtual memory
https://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
https://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
other posts this year mentioning internal network:
https://www.garlic.com/~lynn/2006.html#11 Some credible documented evidence that a MVS or later op sys has ever been hacked
https://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
https://www.garlic.com/~lynn/2006b.html#9 Is there a workaround for Thunderbird in a corporate environment?
https://www.garlic.com/~lynn/2006b.html#12 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006b.html#35 Seeking Info on XDS Sigma 7 APL
https://www.garlic.com/~lynn/2006c.html#14 Program execution speed
https://www.garlic.com/~lynn/2006e.html#25 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#27 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#35 The Pankian Metaphor
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit
https://www.garlic.com/~lynn/2006j.html#8 ALternatives to EMail
https://www.garlic.com/~lynn/2006j.html#23 virtual memory
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#49 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#42 Arpa address
https://www.garlic.com/~lynn/2006k.html#43 Arpa address
https://www.garlic.com/~lynn/2006k.html#56 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
https://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006l.html#46 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006m.html#9 An Out-of-the-Main Activity
https://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006n.html#5 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#26 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006n.html#36 The very first text editor
https://www.garlic.com/~lynn/2006o.html#34 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006o.html#60 Greatest Software?
https://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby MVS???
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006q.html#7 Linux More Secure on System z?
https://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#5 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core)
https://www.garlic.com/~lynn/2006s.html#20 real core
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: Tue, 31 Oct 2006 16:44:02 -0700for a little more drift
part of visits to various institutions the summer of 1981, reference
to Bell Labs visit
https://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs R&D History
in the above reference there was some comparison about Bell Labs
approach to personal computing and departmental servers vis-a-vis
Xerox ... and a later post touching on the same subject:
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
.....
'Xerox SDD' Xerox Systems Development Division (Palo Alto CA)
Visit to Xerox Systems Development Division
General Impressions
They have more machines than people. There are 300 machines for 200
employees. At least five of the machines are DORADOs (3 mips); the
rest are a mixture of ALTOs, D machines, and Stars. Everyone has at
least an ALTO in his office. All the machines are tied together with
a 10 megabit Ethernet. On the net there are at least two file servers
and various xerographic printers including a color printer.
The ALTO in Allen Brown's office had 28 megabytes of local storage.
It gave off a low but definite fan noise. The Dorados are a bit
smaller than a 2 by 3 file cabinet and are noisy (they are called
APCs, *Armored Personal Computers*). The Stars seemed a bit quieter
than Altos.
The Dorados were built because the Altos were felt to be too small.
In particular they did not have enough power to do the processing
required for preparing a color display with the response time they
felt necessary. The Dorado's are also part of a very conscious effort
to build in today's technology machines which Xerox thinks can be
built inexpensively by the end of the decade. They are not (within
reason) concerned about the manufacturing cost today. This philosophy
is a continuation of the one which developed the Star. The Star which
is now being developed is the commercial version of the Altos which
have been in use for several years at internal Xerox locations.
Most of the programming is done in Mesa, an extended version of
Pascal. The extensions are mainly in those areas where Pascal is weak
for system programming.
The Stars were impressive with a good flicker-free display. The
software is carefully thought out, and I think a lot can be learned
from looking at the design decisions it embodies. In particular, the
software shows immense restraint, simplicity, and consistency.
... snip ...
a couple other references:
http://www.parc.xerox.com/about/history/default.html
http://www.computerhistory.org/events/lectures/alto_06042001/
http://www.digibarn.com/friends/alanfreier/index.html
http://www.physorg.com/news110781861.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Vulnerability Assessment of a EAL 4 system Newsgroups: comp.os.linux.security,comp.os.linux.misc,comp.os.linux.setup,comp.security.misc,comp.security.unix Date: Tue, 31 Oct 2006 17:11:33 -0700Neil Jones <castellan2004-email@yahoo.com> writes:
i've somewhat characterized the change over to common criteria ... as recognizing that not everything is a general purpuse computer (including multi-user sharing) ... and so there are all sorts of provisions in common criteria for specifying the "protection profile" against which something will be evaluated.
there are some general stuff about what kinds of things that need to be in a "protection profile" for different evaluation levels ... but without the specific protection profile ... you have no real idea what specific evaluation has been performed.
it is also possible that there could be security things that you might be interested in doing ... that just weren't considered or included in the protection profile used for the evaluation.
obstensibly one of the purposes of evaluation was so you could compare the evaluation levels of two similar products and use the evaluation to help in the choice ... under the assumption that using the same protection profile would result in comparable evaluations. However, a couple years ago, there was a statement that of the 64 some evaluations that had been performed at that time, something like sixty of the evaluations had non-public deviations from published protection profile (making it difficult to use evaluations as part of comparing similar products)
National Information Assurance Partnership (NIAP) home page
http://www.nsa.gov/ia/industry/niap.cfm
http://www.nsa.gov/ia/business_research/partnerships_with_industry/niap_and_cots_product_evaluations.shtml
The Common Criteria Evaluation and Validation Scheme
http://niap.bahialab.com/cc-scheme/
Common Criteria Portal
http://www.commoncriteriaportal.org/
List of Protection Profiles (against which evaluation are performed)
http://www.commoncriteriaportal.org/public/consumer/index.php?menu=5
under operating systems in the above ... there is
"Multi-level Operating Systems in Medium Robustness Environments PP" protection
profile (at EAL4+)
http://www.commoncriteriaportal.org/public/files/ppfiles/PP_SLOSPP-MR_V1.22.pdf
"Multi-level Operating Systems in Medium Robustness Environments" certification
report (at EAL4+)
http://www.commoncriteriaportal.org/public/files/ppfiles/PP_VID204-VR.pdf
then there is
"Single-level Operating Systems in Medium Robustness PP" protection profile
(at EAL4+)
http://www.commoncriteriaportal.org/public/files/ppfiles/PP_SLOSPP-MR_V1.22.pdf
"Single-level Operating Systems in Medium Robustness PP" certification report
(at EAL4+)
http://www.commoncriteriaportal.org/public/files/ppfiles/PP_VID203-VR
whole lot of past posts mentioning risk, fraud, exploits, and vulnerabilities
https://www.garlic.com/~lynn/subintegrity.html#fraud
and some number of past posts mentioning assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why these original FORTRAN quirks? Newsgroups: alt.folklore.computers,comp.lang.fortran Date: Wed, 01 Nov 2006 12:08:41 -0700pa@see.signature.invalid (Pierre Asselin) writes:
other systems have had conventions for doing shareable code/libraries such that location specific details were in separate process control structures and that execution convention accessed their location specific information with register-based operations (i.e. registers were part of process and address space specific operation ... as well as the associated process control structures).
I fiddled with this a lot for the original shared segment stuff that I
built on top of the paged mapped filesystem that I did for cms in the
early 70s (originally on cp67 platform).
https://www.garlic.com/~lynn/submain.html#mmap
most of cms used os/360 derived assemblers, compilers, and
linker/loader ... so about the only place you could fiddle all the
default relocable address constant conventions was in assembler
implemented applications:
https://www.garlic.com/~lynn/submain.html#adcon
vm370/cms picked up a trivially small subset of the implementation for product release as something they called DCSS (discontiguous shared segments) ... the vm370 kernel changes to allow new way of specify shared code ... but at a fixed/common address location .. and cms changes were for code to execute in r/o protected shared storage (but confirming to vm370 kernel changes at fixed location).
Note that DWSS was different than DCSS. DWSS was part of the original
technology transfer of system/r from sjr to endicott for sql/ds.
https://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
system/r was the original relational/sql implementation, done on
vm370 platform
https://www.garlic.com/~lynn/submain.html#systemr
various recent posts this year mentioning DCSS
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/2006.html#31 Is VIO mandatory?
https://www.garlic.com/~lynn/2006.html#35 Charging Time
https://www.garlic.com/~lynn/2006b.html#4 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006b.html#7 Mount a tape
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#24 Virtual memory implementation in S/370
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/2006n.html#5 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#14 RCA Spectra 70/25: Another Mystery Computer?
https://www.garlic.com/~lynn/2006n.html#45 sorting
https://www.garlic.com/~lynn/2006o.html#27 oops
https://www.garlic.com/~lynn/2006o.html#53 The Fate of VM - was: Re: Baby MVS???
https://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
https://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
https://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core)
https://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Encryption and authentication Newsgroups: comp.security.firewalls Date: Wed, 01 Nov 2006 12:49:40 -0700mhostettler writes:
P - privacy (sometimes as CAIN ... confidentiality)
A - authentication
I - integrity
N - non-repudiation
so encryption technology can be used for hiding information, achieving security "privacy" (or "confidentiality").
given that you know that only specific entities have access to a specific encryption keys ... then it can be possible for encryption to also imply authentication (because part of the encryption business process requires that only specific entities have access to the associated encryption key).
so as part of a cryptographic business process, a secure hash of information can be taken and also encrypted. if the recomputed hash of a decrypted message is the same as the decrypted original hash ... then the implication is that the message has not been modified ... providing for integrity.
and example is asymmetric key cryptography technology.
using asymmetric key cryptography technology, a public/private key business process is defined ... where the public key is widely publicized and the corresponding private key is kept confidential and never divulged.
it is possible to take an entity's public key and encode a message. privacy/confidentiality is presumed because the decoding of the message can only be done by the entity with access to the corresponding private key.
a digital signature business process is defined utilizing the public/private key business process.
the secure hash of some information is calculated and encoding with the entity's private key.
a relying party processing the information can recalculate the secure hash and compare it with the original secure hash decoded with the corresponding public key.
from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
xs
the relying party, on matching the two secure hash (in the digital
signature business process), can infer that
1) the information has not changed (integrity)
2) something you have authentication, aka the original digital signature was done by an entity with exclusive and unique access to the corresponding private key, which has been kept confidential and never divulged.
if you combine digital signature (for integirty and authentication) with public key encryption of the information (for privacy/confidentiality) ... you can achieve three of the four PAIN characteristics.
note that "N" in PAIN is a lot harder. there is some unfortunate
semantic confusion that the term "digital signature" and the term
"human signature" both contain the word "signature". there has
sometimes been the misbelief that the "digital signature" business
process (integrity and authentication) can assume to be equivalent to
the "human signature" process which implies that the person had read,
understood, agrees, approves, and/or authorizes the information.
however there is actually a vast chasm between "digital signature" and
"human signature". misc. posts discussing various signature
characteristics
https://www.garlic.com/~lynn/subpubkey.html#signature
for other drift ... we were called in to consult with a small
client/server startup that wanted to do payments on their server.
they had this technology called SSL (or sometimes HTTPS). the
resulting payment processing implementation is sometimes now
referred to as electronic commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
SSL encryption has been used to hide the credit card account number, preserving its privacy and confidentiality.
the risk is that just divulging the account number can result in
fraudulent transactions ... various posts regarding shared-secret
based business processes
https://www.garlic.com/~lynn/subintegrity.html#secret
and account number harvesting vulnerabilities
https://www.garlic.com/~lynn/subintegrity.html#harvest
... and a little more context from a post about security proportional
to risk
https://www.garlic.com/~lynn/2001h.html#61
a little later in the x9a10 financial standards working group, the
reguirement for the x9.59 standards work was 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 standard eliminated the risk associated with divulging the account number (resulting in fraudulent transactions). digital signature business process was used to provide integrity and authentication. furthermore, part of the standard was a business rule that account numbers used in x9.59 retail financial transactions could not be used in non-authenticated transactions.
the account number scenario with SSL is that the planet needs to buried under miles of cryptography for hiding in order to prevent fraudulent transactions (aka enormous amounts of privacy/confidentiality).
in x9.59, the fraud risk related to divulging account numbers is eliminated ... and therefor it is no longer necessary to hide (x9.59) account numbers. In effect, x9.59 manages to substitute integrity and authentication for privacy/confidentiality as countermeasure to account number related fraud (to preserve the integrity of the financial infrastructure for all retail payments, it is no longer necessary to hide the account number).
lots of past posts mentioning threats, exploits, vulnerabilities, and
fraud
https://www.garlic.com/~lynn/subintegrity.html#fraud
and misc. posts mentioning assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance
recent discussion regarding "naked transactions" ... requirement
for enormous amounts of "hiding" (privacy/confidentiality) because
any trival leakage of account numbers lead to enormous fraud risk.
the alternative is to armor every transaction with digital
signature (integrity, authentication) ... eliminating the enormous
fraud risk related to even trivial account number leakage:
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#25 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#37 DDA cards may address the UK Chip&Pin woes
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?
https://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#9 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
https://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
https://www.garlic.com/~lynn/aadsm25.htm#38 How the Classical Scholars dropped security from the canon of Computer Science
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Wed, 01 Nov 2006 15:39:09 -0700Walter Bushell <proto@panix.com> writes:
sjr ran a 370/195 (os/360) mvt service thru the late 70s ... and there were jobs that sat in the work queue for several weeks waiting for execution. also because of its highly complicated hardware implementation ... it wasn't practical to add virtual address translation ... which eventually became available for all other 370s (and with the advent of virtual memory on all models of 370s, all the operating systems transitioned to virtual memory).
i got somewhat involved in project to add dual i-stream (multi-threading) to 195; replicate instruction address, registers, etc ... workload in the pipeline would have one-bit tag added indicating which i-stream it belong to. the idea was that if most convential code only kept the pipeline half-full ... then a pair of i-streams could keep the pipeline full and operating at aggregate thruput of 10mips. this never shipped (and it didn't address the issue of retrofitting virtual memory to the machine).
one of the applications that wasn't getting exactly great turn around on the sjr 195 was air-bearing simulation in support of designing the 3380 floating, thinfilm disk heads (possibly an hr every several weeks).
as i've mentioned before ... I got involved in hardening an operating
system so that it could be used in disk engineering and product test
labs (bldg. 14 & 15). they had a number of processors that were used
in dedicated stand-alone mode for doing disk regression testing.
because of the high rate of faults from prototype and engineering
hardware, they were unable to operate with conventional operating
systems
https://www.garlic.com/~lynn/subtopic.html#disk
the labs would get early processor models for dedicated regression testing (including early availability of 4341 and 3033 processors). with the availability of operating system on the labs machine ... we found that normal disk regression testing only required a few percent of processor capacity ... the rest of the processors became available for other types of application.
3033 was about 4.5mips (a little less than half 195 peak sustained). however, the air-bearing simulation work could get several hrs every day on the bldg. 15 3033 ... compared to maybe an hr every several weeks on the bldg. 28 195.
past posts mentioning the air-bearing simulation
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2002j.html#30 Weird
https://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
https://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
https://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
https://www.garlic.com/~lynn/2004b.html#15 harddisk in space
https://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#5 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#13 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#14 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006l.html#6 Google Architecture
https://www.garlic.com/~lynn/2006l.html#18 virtual memory
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Wed, 01 Nov 2006 16:23:49 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
so the "data entry" 3278 started out with PF keys as ALT across the top row.
3278 then introduced new row of PF1-PF12 across the top ... somewhat like PC keyboard.
then you could keyboard with row of PF1-PF12 across the top and PF13-PF24 on the right-hand side ... somewhat where the 3277 PF1-PF12 keypad was located.
so although the PF keys were software programmable ... a lot of applications from 3277 had created embedded assignments for specific PF keys. So with the availability of PF keys on the side of 3278 ... there were several requests for operating system layer to swap the scancodes between PF1-PF12 and PF13-PF24.
There was a separate issue that started earlier with software programmable 3277 PF keys with regard to application consistency. Given that applications could embed specific associations with specific keys. given that there was no controlled specification for the PF keys ... like the PC "page up" and "page down" keys ... different applications bound specific functions to specific keys (and for some reason it took quite a long time to add user configurable profiles to these applications).
in any case, w/o explicit, well established convention (like physical labels on the keys) ... there was extended period of application inconsistent specification for PF key use (aggravated by applications that failed to provide user profile configurability).
There was almost infamous arguments in the late 70s and early 80s about PF3 consistently being used for "END/QUIT/EXIT" function. There were a variety of emerging full-screen applications, application menu environments, email readers, editors, etc. There was some irritability when each environment assigned END/QUIT function to a different PF key (and user profile configurability was not generally available )
from somewhere long ago and far away
Date: 12/11/78 09:02:16
To: wheeler
how about a cp command that would reset pfkeys 13-24 to be the same as
pfkeys 1-12 ?????
then on my 3278 i could use the pfkeys in the normal position for any
application that used pfkeys 1-12
... snip ... top of post, old email index
Date: 08/11/82 12:44:20
To: wheeler
Hi there. I have had a bug reported to me concerning the assignment of
PF13-24 with my VMSG mods. Unfortunately, we don't have many terminals with
more than 12 PF keys around here, so that code wasn't tested very well. Sorry
'bout that! Hopefully, I'll have an updated version available soon and I'll
be re-distributing the package. I'll also be adding some other updates which
people have requested (6 EPILOG/PROLOG lines, for example). If you have any
other requests, let me know. It seems that there are various versions of VMSG
running around and I'm trying to get a hold of the other enhancements to
incorporate into my version. A bientot,
IBM Europe Technical Support
23 Allee Maillasson
92100 Boulogne, France
... 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: Wed, 01 Nov 2006 17:21:17 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
lots of past collected posts mentioning bitnet and/or earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet
... university based network using similar technology to
that used in the internal network.
https://www.garlic.com/~lynn/subnetwork.html#internalnet
while there the number of nodes on the internal network was larger than the number of arpanet/internet nodes ... from just about the beginning until possibly sometime mid-85 ... there have also been claims that the number of bitnet/earn nodes (independent of the internal network nodes) were larger than the number of arpanet/internet nodes for at least part of the early 80s.
post including old email referencing the creation of EARN
https://www.garlic.com/~lynn/2001h.html#65
note that while possibly all the nodes on the internal network were ibm mainframes ... there were some number of bitnet/earn network nodes that had vnet/rscs emulation running on other kinds of processors.
misc. posts from this year mentioning bitnet &/or earn:
https://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
https://www.garlic.com/~lynn/2006b.html#12 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#25 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#27 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#37 The Pankian Metaphor
https://www.garlic.com/~lynn/2006i.html#31 virtual memory
https://www.garlic.com/~lynn/2006j.html#8 ALternatives to EMail
https://www.garlic.com/~lynn/2006j.html#23 virtual memory
https://www.garlic.com/~lynn/2006j.html#43 virtual memory
https://www.garlic.com/~lynn/2006m.html#9 An Out-of-the-Main Activity
https://www.garlic.com/~lynn/2006m.html#10 An Out-of-the-Main Activity
https://www.garlic.com/~lynn/2006o.html#60 Greatest Software?
https://www.garlic.com/~lynn/2006r.html#5 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
heavily edited email ...
Date: 12/12/81 11:25
To: wheeler
.. is the guy that Fuchs (CUNY - BITNET) wrote to about connecting
BITNET to VNET.. XXXXX is driving the BITNET connection with YYYY and
Fuchs) but they need some resources.. Also, YYYY (works in ZZZZ) also
just recently initiated a contract with Univ. of Wisconsin for putting
Internet/TCP protocol on VM/370
... snip ... top of post, old email index, HSDT email
then there was also NSF funded CSNET in the early 80s (independent of
the heavily corporate funded bitnet and earn):
CSNET (Computer Science NETwork) is funded by NSF, and is an attempt
to connect all computer science research institutions in the U.S. It
does not have a physical network of its own, but rather is a set of
common protocols used on top of the ARPANET (Department of Defense),
TeleNet (GTE), and PhoneNet (the regular phone system). The
lowest-cost entry is through PhoneNet, which only requires the
addition of a modem to an existing computer system. PhoneNet offers
only message transfer (off-line, queued, files). TeleNet and ARPANET
allow higher-speed connections and on-line network capabilities such
as remote file lookup and transfer on-line, and remote login.
and misc. posts mentioning CSNET
https://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET?
https://www.garlic.com/~lynn/98.html#59 Ok Computer
https://www.garlic.com/~lynn/internet.htm#4 Internet (TM) and USPTO
https://www.garlic.com/~lynn/99.html#7 IBM S/360
https://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#38c Internet and/or ARPANET?
https://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
https://www.garlic.com/~lynn/2001m.html#54 Author seeks help - net in 1981
https://www.garlic.com/~lynn/2001n.html#5 Author seeks help - net in 1981
https://www.garlic.com/~lynn/2002e.html#6 LISTSERV(r) on mainframes
https://www.garlic.com/~lynn/2002h.html#82 Al Gore and the Internet
https://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet (fwd)
https://www.garlic.com/~lynn/2004l.html#0 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004o.html#47 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005e.html#46 Using the Cache to Change the Width of Memory
https://www.garlic.com/~lynn/2005n.html#16 Code density and performance?
https://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
https://www.garlic.com/~lynn/2006j.html#34 Arpa address
https://www.garlic.com/~lynn/2006j.html#49 Arpa address
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 1960s railroad data processing on L&N Newsgroups: misc.transport.rail.americas,alt.folklore.computers Date: Wed, 01 Nov 2006 19:42:25 -0700John McCoy <igopogo@ix.netcom.com> writes:
there were at least two commercial timesharing service bureaus
formed using cp67 in the 68/69 timeframe ... which somewhat
later moved to vm370 ... and in the early 70s, tymshare started
offering commercial vm370 service. misc. postings on commercial
timesharing
https://www.garlic.com/~lynn/submain.html#timeshare
a little more on one of the early cp67 timesharing service bureaus
https://www.garlic.com/~lynn/2006k.html#35
and also references here to series of URLs at the computer history site
https://www.garlic.com/~lynn/2006k.html#36
and pointer here to some tymshare history offering vm370 commercial
timesharing starting in the early 70s
https://www.garlic.com/~lynn/2006k.html#37
there is the multics web site
https://www.multicians.org/multics.html
cp67 had been done at the cambridge science center on the
4th flr of 545 tech. sq
https://www.garlic.com/~lynn/subtopic.html#545tech
while multics was on the 5th flr of the same building. both cp67 and multics trace some amount of history back to ctss.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch Date: Wed, 01 Nov 2006 19:57:32 -0700Joe Seigh <jseigh_01@xemaps.com> writes:
this was done in part for trying to speed up the thruput of vnet
nodes in HSDT (high-speed data transport)
https://www.garlic.com/~lynn/subnetwork.html#hsdt
vnet made heavy use of the vm spool file system ... and aggregate thruput could be limited to five 4k blocks per second (20kbytes/sec). as noted, HSDT need several hundred thousand to multiple million bytes/sec thruput.
... and for something completely different ... in the very early days
of rexx, i wanted to demonstrate that rexx wasn't just another command
scripting language (like exec and exec2). the dump/fault analysis
application (ipcs) was a large assembler implemented application. I
set out to demonstrate that I could re-implement the ipcs function
working half time over three months in (intepreted) rexx and it would
run ten times faster and have ten times as much function (as the
original application implemented in assembler). misc. past posts
referencing the activity
https://www.garlic.com/~lynn/submain.html#dumprx
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch Date: Wed, 01 Nov 2006 21:12:38 -0700Joe Seigh <jseigh_01@xemaps.com> writes:
how 'bout virtual appliances ... possibly not quite what they are
talking about in this news release ... instead of ease of deployment ...
talk about partitioning, security, isolation, ease of management,
etc.
http://triangle.dbusinessnews.com/shownews.php?newsid=96829&type_news=latest
similar but different post here mentioning padded cell
https://www.garlic.com/~lynn/2006s.html#65 Paranoia..Paranoia..Am I on the right track?.. any help please?
a virtual appliance home page ... again similar but different ... but
can be used and deployed akin to demons ... but using virtual machine
isolation and partitioning infrastructure
http://virtualappliances.net/
virtual appliances blog
http://virtualappliances.org/
a relatively recent article: Excited about virtual appliances
http://www.networkworld.com/columnists/2006/082806gearhead.html
Hundreds of Free Virtual Appliances
http://www.digitalmediaminute.com/article/2245/hundreds-of-virtual-appliances
... for all intents and purposes ... virtual appliances and service virtual machines are nearly identical concepts.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch,alt.folklore.computers Date: Wed, 01 Nov 2006 22:01:19 -0700re:
reference to old email about "special message" (SPM) ... which was a
superset of both vmcf and iucv ... and predates both having been
done originally on cp67:
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
misc. other posts mentioning vmcf
https://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
https://www.garlic.com/~lynn/2005k.html#59 Book on computer architecture for beginners
https://www.garlic.com/~lynn/2005n.html#45 Anyone know whether VM/370 EDGAR is still available anywhere?
https://www.garlic.com/~lynn/2006m.html#54 DCSS
and for the heck of it, from somewhere long ago and far away ... note
this email is somewhat discussing the same subject as the email from
1985 included in the referenced post "other cp/cms history":
Date: 10/16/78 08:35:03
From: wheeler
VMCF communication requires a program and the knowledge on the senders
part whether or not the receiver is a program and/or a person. The
simplest example is the use of the VNET facility to do CMDs on other
real machines (i.e. q system). I very often wish to know how does a
particular node route information. The information back from VNET will
in general by asychronous (unless you wish to wait possibly a very
long time for the response). There have been several people who have
written programs to do the same thing automatically in order to create
an up to date structure of the network. The only way to do that with
the product change is to have VNET determine (possibly by how fast the
original characters were typed) whether the originator is a person or
a program.
I re-iterate; untill IBM supplies it in a architecturly clean
implementation with all the facilities available, there will be a
demand for an interface which is allowed to capture all information in
a program which would be destined for a person (also Yorktown still
seems to think if they don't have the application then it either it
must not exist or 'who in the world would ever want to do that').
... snip ... top of post, old email index, HSDT email
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: To RISC or not to RISC Newsgroups: alt.lang.asm,comp.arch,alt.folklore.computers Date: Wed, 01 Nov 2006 22:42:23 -0700re:
note the old
1978
email reference to automated programs (that
does a lot of automated queries, and on the basis of the responses,
does new queries) to create an up-to-date structure of the
network is quite analogous to the process used by modern day web
crawlers.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Wed, 01 Nov 2006 23:11:27 -0700Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
aka "the internal version of RSCS" being eventually released as the VNET PRPQ.
at some point VNET was used to describe both the internal networking
software and the internal network itself
https://www.garlic.com/~lynn/subnetwork.html#internalnet
as in this post
https://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
that includes part of an email from
1981
that references a request
from CUNY to interface BITNET to VNET (where bitnet is the university
network running RSCS software and VNET is both the internal software
and the internal network)
in the
1985
email referencing the release of the VNET PRPQ in the
mid-70s, there was enormous objections to allowing the VNET PRPQ to be
announced and shipped. you would probably never believe the tortuous
process and logic that eventually led to the company allowing VNET
PRPQ to be shipped.
in any case, this subthread is something of a repeat of a very
similar thread/exchange in 2002
https://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
including references to bitnet/earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet
the referenced posting from 2002 contains a section from Melinda's vm history
about some of the early rscs/vnet (software) history
https://www.leeandmelindavarian.com/Melinda/25paper.pdf
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 00:04:05 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
re:
https://www.garlic.com/~lynn/2006t.html#49 The Future of CPUs: What's After Multi-Core?
and some other posts in the similar thread/exchange from 2002
https://www.garlic.com/~lynn/2002k.html#18 Unbelievable
https://www.garlic.com/~lynn/2002k.html#19 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#21 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#22 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#23 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#26 DEC eNet: was Vnet : Unbelievable
the above post references a (2002) post by morris that includes:
A listing I have from 1985 -- the accuracy of which I cannot guarantee -- shows the following node counts: BITNET 435 ARPAnet 1155 CSnet 104 (excluding ARPAnet overlap) VNET 1650 EasyNet 4200 UUCP 6000 USENET 1150 (excluding UUCP nodes)... snip ...
i believe the number of nodes on apranet/internet passed the number of vnet nodes sometime later in 1985.
majority of the following email went into lengthy detail about
encryption and DES ... but concludes with the ending sentence.
Date: 06/25/85 19:59:03
From: wheeler
re: hsdt des;
...
This encryption technique is attractive for the internal network with
the number of nodes approaching 2000 and the desirability of
end-to-end encryption.
... snip ... top of post, old email index, HSDT email
there was extensive use of link encryptors for lines that left corporate physical facilities (but not much use of end-to-end encryption). i have some memory of a claim in this period that the internal network had over half of all the link encryptors in the world.
the following is from (somebody's) old posting to info.nets from 18feb89
> Does anyone have a current table of size estimates for the academic > and research networks? > > Network as of count Description > -------- -------- ----- ----------------------------------------------- > BITNET 01/18/85 435 University/nonprofit/research network > Arpanet 01/22/85 1155 DoD related... snip ...
The December 1988 BITNET nodes file contains 2691 entries. This includes BITNET/NETNORTH/EARN nodes.
google net.mail posting from 11aug85 giving list of 694 BITNET nodes as of 12jul85
http://groups-beta.google.com/group/net.mail/browse_thread/thread/1d703f2904d9ace0/551c1d15a1ab71d4?lnk=st&q=&rnum=21&hl=en#551c1d15a1ab71d4