From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: c.d.theory glossary (repost) Newsgroups: comp.databases.theory Date: Sat, 15 May 2004 09:14:38 -0600mAsterdam writes:
this is sort of independent of having any definitions for the concepts, terms, and/or word. if you have a set of words that you might want to look for a article with ... umls gives other related words, terms, and/or concepts that might also be used to search for articles.
it is also used by the people cataloging the library ... lots of listed terms and word sequences have preferred relationships, i.e. if an article abstract contains certain set of terms and/or word sequences, there are guidelines about preferred terms to be used for indexing/cataloging. this structure of preferred/nonpreferred relationships can also be used for people looking up entries in the catalog
at this level, umls is effectively the structure used for understanding the cataloging of the articles (as opposed to understanding the articles themselves).
there was some statement that nlm reached the state of many current search engines possibly by the late '70s. a boolean term search would be quite bimodal, at six to seven terms there could still be hundred thousand hits ... but adding one more term dropped the number of hits to zero. the holy grail was finding magic combination of five to eight terms that resulted in 50-100 hits. in the early 80s, an online interface (grateful med) was developed that by default didn't ask for the hits but just the number of hits. then a 2-3 day task might be to discover the magic query combination that resulted in a reasonable hit result (say greater than zero but less than several hundred).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: c.d.theory glossary (repost) Newsgroups: comp.databases.theory Date: Sat, 15 May 2004 09:41:04 -0600at one point, i heard that there were something like 40,000 medical librarians around the world that specialized in assisting doctors and medical researchers in doing nlm lookups.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Quote of the Week Newsgroups: comp.databases.theory Date: Sat, 15 May 2004 13:55:18 -0600jcelko212@earthlink.net (--CELKO--) writes:
mentioning a long ago and far away article by date (1992) titled "An Explanation of why three-valued logic as a mistake" ... related to the handling of NULLS in SQL.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Sun, 16 May 2004 09:58:50 -0600Anne & Lynn Wheeler writes:
i was somewhat working on the resource manager, ecps (extensive microcode performance enhancements), and VAMPS all at the same time. the resource manager was big package of software that nominally improved the resource allocation algorithms. however it also had a bunch of structual changes to the kernel.
one of the things was that a infrastructure for automated benchmarks was create (as part of calibrating the resouce manager algorithms). in preparation for releasing the over 2000 benchmarks were run taking something like 3 months elapsed time. some of the benchmarks were extreme stress tests that were possibly a factor of ten times outside the normally observed operating situations. at the start these stress test were guaranteed to crash the kernel. eventually as part of the resource manager, the whole kernel serialization structure was completely rewritten ... which eliminated all observed crashes under heavy stress load and also all known situations that involved hung/zombie processes.
previously, in the cp/67 to vm/370 (port from 360/67 to 370) there had been some kernel restructuring; some of the cp/67 that had been done in support of multiprocessing was eliminated. for the resource manager, i re-introduced the dispatching and paging related structures that had been there from cp/67.
the other characteristic was that it was decided to make the resource manager the guinea pig for charged/priced kernel code ... under the revised guidelines that kernel code that wasn't directly required for using some hardware could be charged for.
So the resource manager and ecps ships ... and VAMPS is canceled. The decision is then made to turn out a real vm/370 multiprocessor kernel and to adopt the thin-layer multiprocessor design from VAMPS with bounce lock and extremely lightweight kernel requests (rather than the traditional kernel spin lock).
The only problem was that SMP support needed something like 80 percent of the code that was in the resource manager (involved in various restructuring). The issue was that they just couldn't just make the resource manager a prerequisite for SMP support ... since the resource manager was charged for ... and the business guidelines required that kernel software directly needed to support hardware (in this case multiprocessor operation) was still free (and free software with a prerequisite for priced software wasn't an option).
The solution was to remove the 80 percent or so of the code from the resource manager needed for SMP support and place it in the base (free) kernel. They then continued to charge for the five times smaller resource manager (in terms of lines of code) at the same price as the original resource manager.
all of this seems trivial now that it has evolved that all (mainframe) software is charged for (including all kernel software) .... but at the time it represented an enormous issue.
misc. past resource manager related posts
https://www.garlic.com/~lynn/subtopic.html#fairshare
and paging system posts
https://www.garlic.com/~lynn/subtopic.html#wsclock
and smp posts
https://www.garlic.com/~lynn/subtopic.html#smp
and microcode posts
https://www.garlic.com/~lynn/submain.html#mcode
and benchmarking (in support of resource manager)
posts
https://www.garlic.com/~lynn/submain.html#bench
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Sun, 16 May 2004 10:11:32 -0600Joe Seigh writes:
a) handling them in completely in the interrupt handler (and directly resuming application from the interrupt handler) or
b) recognizing them in the dispatcher and providing special path thru the dispatcher for application resume or
c) dispatcher recognizing that while it was longer kernel processing it was still resuming the same application and being able to still optimize some pathlength.
one of the remaining timing issues was just that the svc interrupt/call from application state to kernel state also changed the machine state from enabled for i/o & timer interrupts to disabled for i/o & timer interrupts. on resume, the state of the machine then changed back from disabled for interrupts to enabled for interrupts. The change in machine state between enabled/disabled for i/o & timer interrupts was an extremely expensive process by itself.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Sun, 16 May 2004 10:15:52 -0600Anne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Sun, 16 May 2004 10:50:31 -0600this is a report i gave at ibm user group meeting while undergraduate on operating system/kernel speed up.
MFT14 was the main batch operating system that was used at the university for the bulk of the work. a characteristic was that it was heavily disk bound ... design point that assumed everything was heavily real memory constrained and so everything had to be done using disks. I speeded up nominal university workload thruput by a factor of three times by carefully positioning data & files on disk to optimize disk arm.
CP/67 was virtual machine operating system from cambridge science
center:
https://www.garlic.com/~lynn/subtopic.html#545tech
some people from cambridge had installed it at the university january of 1968 ... and the above referenced presentation was made fall of '68.
when running MFT14 in virtual machine the main issues for CP/67 were in the
1) SVC interrupt handler.
MFT application were using SVC interrupts to call the MFT kernel; under CP/67 they interrupted into the CP/67 SVC interrupt handler and a SVC interrupt into the virtual machine had to be simulated, resuming the virtual machine at the virtual svc interrupt address.
2) program interupt handler
MFT kernel would execute a large number of "privileged" 360 instructions. CP/67 ran all virtual machines in non-privileged mode which resulted in privileged instructions interrupting into the CP/67 kernel. The CP/67 kernel then had to simulate the privilege instruction and resume virtual machine execution
3) dispatcher
standard process for resuming virtual machine execution was the dispatcher which all kernel processes would eventually converge on. the dispatcher in additional to actually activating the execution of virtual machine, also managed the selection of virtual machine to run as well as managing all the kernel thread infrastructure and misc. other tasks.
...
The fastpath work and misc. other kernel work that I did between january and fall of '68 ... reduced the kernel cpu utilization by nearly 80percent:
before: 534 cpu secs in the cp/67 kernel
after: 113 cpu secs in the cp/67 kernel.
the measurements were by running the MFT14 on the real machine and clocking real time and then repeating under CP/67 and clocking real time. The MFT14 workload was run in an virtual machine enivoronment where all of the virtual machines pages were resident in real memory and CP/67 performed no paging operations during the period.
The increase in real time between real machine operation and virtual machine operation is totally attributable to CPU utilization by the CP/67 kernel operation ... not necessarily solely instruction pathlength, since it would also include the overhead for things like the privilege instructions from the virtual machine interrupting into the CP/67 kernel.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Network Data Model, foundation for Relational Model Newsgroups: comp.databases.theory Date: Sun, 16 May 2004 14:58:09 -0600"Ken North" writes:
The "semantic network" DBMS done by the VLSI tools group drew a lot from Sowa's work on semantic networks. There has also been various efforts over the years to map semantic networks into RDBMS technology ... frequently the intermediate layer represents a 10:1 performance overhead handling the semantic network representation to relational representation. however, quicky use of search engine turns up some number of explicit implementations.
a random reference turned up by search engine that happens to also
mention medical informatics and UMLS semantic networks ... even tho
there has been significant effort mapping UMLS semantic networks to
rdbms over the years:
http://courses.mbl.edu/Medical_Informatics/2001/outlinesFall2001.html
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: racf Newsgroups: bit.listserv.ibm-main Date: Mon, 17 May 2004 13:36:21 -0600tom.schmidt@ibm-main.lst (Tom Schmidt) writes:
warning: long authentication topic drift.
typically a userid/password scenario is that you assert something ... aka: assert you are authorized for the "userid" and you prove the assertion by knowing the corresponding password. the "userid" is used for the authorization process, and the "password" is used for the authentication process.
in 3-factor authentication paradigm:
• something you know
• something you have
• something you are
a password is a single factor, shared-secret, something you know
authentication. some security infrastructures may also depend on the
"userid" (used for authorization) also be kept totally secret and
therefor also become part of something you know authentication
process.
asymmetric encryption has a pair of keys and uses different keys for encryption and decryption. business processes establish convention that a specific key is to be treated as public and the other half of the key pair is to be treated as private and never divulged.
In DES, the shared-secret key isn't private (in the sense of the asymmetric encryption business process of public/private keys) since both the encryptor and the decrypter have to share knowledge of the same key (although they may keep it secret from everybody else).
the use of "private" in the business application of asymmetric encryption is, in effect, intended to be more restrictive control of the key than just secret (aka public/private key systems don't represent technology, asymmetric encryption represents technology; public/private keys represent business process application of asymmetric encryption).
it is possible to have two factor authentcation:
• something you know
• something you have
where the something you know authentication can be private as
opposed to shared-secret.
the something you have can be some form of chip token that possibly contains a private key that can never (practically) be removed from the token. The private key in the token is used to "digitally sign" (aka encrypt a hash) which is trasnmitted. If the receiver can verify the digital signature with a recorded public key, then something you have authentication can be demonstrated (since only the person in possesion of the hardware token could have generated the correct digital signature). This is scenario where somebody walks in and says instead of recording a password for my userid ... record a public key ... and instead of the system doing password compare ... uses the public key to perform digital signature verification.
Now, if the hardware token has been certified to only operate in a specific way when the correct PIN has been entered ... the authentication of the digital signature then not also implies something you have authentication, but also something you know authentcation ... i.e. the recepient doesn't know the PIN ... but knows the correct PIN was entered since the token appears to be operating correctly.
In this way, something you know authentication can be demonstrated w/o having to use shared-secrets between the sender and the receipient.
There are horrendous problems with the shared-secret paradigm.
First off, since it is shared-secret, there is security requirement that every unique security domain use a unique shared-secret. Specific security domains, then in addition ask that the shared-secrets used be very hard to guess ... and many of these security domains seem to operate under the assumption that they are the only security operation in the whole world. However, the reality is that people may participate in scores of different security domains ... with the result they have large tens of very hard to guess and remember unique shared-secret passwords. Individuals then are forced to create repositories of all their shared-secrets which become attractive targets for criminals.
Second, institutions also tend to have repositories of significant
amounts of shared-secrets, which become attractive targets. In the
shared-secret scenario, criminals skimming/harvesting shared-secrets
repositories, are able to use the information to impersonate
people. small side drift on security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61
if passwords/shared-secrets were replaced in these repositories with
public keys .... criminals could harvest the repositories all they
wanted and still not be able to impersonate somebody by knowing
their public key (in the way they can impersonate individuals by
knowing their shared-secrets).
Finally, people have to know their shared-secrets and therefor are prone to phishing (con-artists convincing people to divulge their secrets in one way or another). hardware tokens using private keys (that can't be extracted from the token) help address the problem. If nobody can know the private key, then the owner of the hardware token also won't know the private key .... and a con artist can't get somebody to tell them something that they don't know.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: racf Newsgroups: bit.listserv.ibm-main Date: Mon, 17 May 2004 13:57:28 -0600tom.schmidt@ibm-main.lst (Tom Schmidt) writes:
this becomes a problem for using specific DES key for extended periods of time, especially over a large domain, which might involve lots of value.
so there are two countermeasures used in the financial world
1) dukpt ... derived unique key per transaction. basically things like ATM machines that continue to use existing DES hardware ... but wrapper it so every transaction over the ATM network uses a unique DES key. The individual transactions are valued in the tens to low hundreds of dollars and lifetime is typically measured in seconds to minutes. the lifetime of the key is much shorter than existing techniques to find a key ... and besides the value of the transactions are much less than the cost to find the unique key for each transaction.
2) triple DES ... basically an encrypt/decrypt/encrypt sequence using different keys ... achieving 112bit strength with two different DES keys. Each additional bit doubles the elapsed time for the brute force attack on specific key. so if specific 56bit DES key can be found in say ten hours ... then it takes either 2**56 times as long to find a 112bit DES value (and/or cost 2**56 times as much)
the following recent RFC has some discussion of various key strength
issues
https://www.garlic.com/~lynn/rfcidx12.htm#3766
3766 I
Determining Strengths For Public Keys Used For Exchanging
Symmetric Keys, Hoffman P., Orman H., 2004/04/26 (23pp)
(.txt=55939) (BCP-86) (was draft-orman-public-key-lengths-08.txt)
if you click on the above URL ... then clicking on the ".txt=55939" field retrieves the actual RFC.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: racf Newsgroups: bit.listserv.ibm-main Date: Mon, 17 May 2004 14:39:43 -0600Rick.Fochtman@ibm-main.lst (Rick Fochtman) writes:
based on the tables, you are starting to talk about RSA key sizes well over 2048 bits ... to give comparable strength to triple-DES (discussed also in previous post in this thread) or even minimum AES key size.
a thread from sci.crypt
https://www.garlic.com/~lynn/2004d.html#58 How secure is 2048 bit RSA?
for pure authentication, you might be much better off with one of the
FIPS186-2 implementations, dsa or ecdsa (see strengths from referenced
RFC or table extracted in above referenced URL on how secure is 2048
bit RSA):
http://csrc.nist.gov/cryptval/dss.htm
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: command line switches [Re: [REALLY OT!] Overuse of symbolic constants] Newsgroups: alt.folklore.computers Date: Mon, 17 May 2004 19:49:51 -0600jmfbahciv writes:
various past posts about os/360 object deck formats
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?)
https://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
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/2002o.html#26 Relocation, was Re: Early computer games
https://www.garlic.com/~lynn/2003d.html#47 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why?
the link-editor could take several object decks, combined them together resolve what was possible to resolve and emit it as series of disk records ... that had some amount of the object deck overhead eliminated (it still had entry points, any remaining unresolved external references and relocatable address constants). there was a some number of link-edit control commands that had control over things like which libraries to search for resolving external program references.
the information about internal program address constants had to be kept around until it was actually decided to run the program ... because address constants were absolute ... once the program image was loaded into specific address location at runtime ... one of the last things that had to be done (before starting program execution) was go thru the "loaded" memory image of the program and adjust all the absolute address constants.
this os/360 convention for absolute address constants gave me lots of
problems attempting to create shared executables ... where the same
object appeared simultaneously in multiple different address spaces at
potentially different virtual addresses. some past discussions of
loacation/address independent code
https://www.garlic.com/~lynn/submain.html#adcon
the os/360 loader and the os/360 link-edit had a lot of common features in terms of processing imput ... the loader targeted the results to a specific memory address/image ... and the linkage edit just wrote an image to disk that could be more efficiently loaded at a later time (than if it had to repeat a lot of the steps every time). the link-edit addressed the scenario where there was large number of repeated executions of an unchanged program.
this didn't do a whole lot for a university student environment where the same, unchanged program was very rarely executed more than once. to some extent the os/360 loader was introduced to address environments like student programs ... which would compile and then (maybe) run ... and never have a repeat execution w/o a compile.
and now there is the "binder" ... ibm FAQ ... what is the difference
between the binder and linkage editor ...
http://www.developer.ibm.com/tech/faq/individual?oid=2:22397
the following url
http://www-306.ibm.com/software/awdtools/hlasm/share.html
is "high level assembler and toolkit feature" ... it has a number
of descriptions ... including (pdf file) tutorial/overviews:
• how the linkage editor works: a tutorial on object/load modules; link editors, loaders, and what they do for (and to) you.
• the DFSMS/MVS binder and its "program ojbect" format: what the new program model will mean to you.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: 1.7rc2 & developer's build/install Newsgroups: netscape.public.mozilla.general Date: Mon, 17 May 2004 18:54:12 -0600yesterday (sunday, 5/16) developer's build would install and run ... wasn't too bad, but could crash under really heavy load.
today both 1.7rc2 and today's developer's build repeat the following three times:
nsNativeComponentLoader: SelfRegisterDll(libnegotiateauth.so) Load FAILED with error: libcom_err.so.3: cannot open shared object file: No such file or directory
and won't load/run
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: racf Newsgroups: bit.listserv.ibm-main Date: Tue, 18 May 2004 09:38:02 -0600wfarrell@ibm-main.lst (Walt Farrell) writes:
something you have
token to impersonate you.
The issue of using public/private key, asymmetric encryption, authentication is almost totally independent of whether or no a digital certificate exists.
the early x.509 identity digital certificaes were target at a totally unconnected environment ... and the x.509 identity digital certificate supposedly contained all the necessary information for the receiving/relying party to both authenticate as well as authorize you; aka these digital certificates were designed that the system receiving the digital certificates would not have to look up anything on any system to determine whether you were a valid user and/or what permissions you might have .... everything was carried in the certificate. there was also quite a bit of fud generated portraying public/private key authentication as equivalent to digital certificates.
so some of the problems with x.509 digital certificate take-up ... is that it has very little relationship to most real live business operations.
one of the first things that x.509 identity digital certificates encountered was that the overloading of the digital certificates with enormous amounts of identity information tended to create a severe privacy problem. so in the mid-90s you started to see appear something called a relying-party-only certificate.
In this case, you register your public key (in place of a password) in the receivers/relying account database (say the userid database). They then issue you a relying-party-only digital certificate that contains (two things) your userid and your public key (a drastic subset of the information that is contained in your userid database).
when you go to logon ...
1) you contact the server/relying party with your userid.
2) the server sends back some unique, random data.
3) you digital sign the random data with your private key
4) you transmit the digital signature and you certificate to the server
5) the server looks up the userid information using "1" and retrieves the userid record (giving your authentication and authorization information). It then uses the public key from the userid record to validate the digital signature.
The digital certificate is basically a stale, static subset, copy of information from your userid/account record. The only time that a relying/receiving party would ever need to resort to a stale, static subset of information contained in a digital certificate is when it otherwise doesn't have access to the real information (allowing a random user to logon to a system based purely on the contents of a digital certificate and there is no local definition for that user and there is no means of making online contact to a system that might have a definition for that user).
The usefullness of x.509 digtital digital certificates was severely reduced in the mid-90s when the amount when it was realized that overloading it with enormous amounts of identity and/or authorization detail created huge privacy problems for the individual and/or the corporation.
Furthermore, the original design point for digital certificates was something out of the early 80s ... that of offline email. In those days, email was handled by electronic post-offices. PCs would dail-up and create a temporary connection to their post-office, exchange email, and then hangup. This was long before the days of ubquituous internet online connectivity. The person then was sitting there with some amount of email, possibly from individuals that there had been no previous contact. The issue was how to perform any validation on the original sender of the email when there had not been any previous communication, and there was no recourse to an online environment.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: command line switches [Re: [REALLY OT!] Overuse of symbolic constants] Newsgroups: alt.folklore.computers Date: Tue, 18 May 2004 08:54:21 -0600jmfbahciv writes:
in the shared segment world .... if a shared thing (data or instructions) were to appear at different address in different virtual virtual address spaces ... it is obvious that absolute address constants isn't going to work. so the common solution is to use relative address constants. each virtual address space has some private dictionary area and/or carries some local absolute address in a general purpose register. for relative address constants a convention is established that the address constant is added to some base registerd, (where the base register is local to the specific address space and has the local address of the shared object. The convention is that the relative address constant is some offset from a base ... and the absolute value for the base in any specific address constant is in a known register.
a trivial analogy is the whole 360 base+displacement addressing convention. nearly all 360 instructions address storage with a base register plus 12bit displacement convention (or base register plus index register plus 12bit displacement). In the assembler world, all the symbolic locations are tracked by the assembler ... and the assembler generates instructions with the correct base register and appropriate 12bit displacement.
So a not uncommon 360 convention is:
BALR R15,0
USING *,R15
which is branch and link register ... i.e. used for branching to
subroutines and saving the return address of the next instruction;
except in the case of register zero for a branch-to address ... it
doesn't actually go anywhere ... just loads the address of the next
instruction into R15. The "using" statement doesn't generate any
instructions, it just tells the assembler to use the relative location
of what is in R15 as the base ... and generate subsequent storage
references with 12bit displacements off R15.
So a real standard calling sequence is something like:
L R15,=a(subroutine)
BALR R14,R15
which uses absolute adcon of the subroutine. as a replacement, I had
to use something like:
L R15,=a(subroutine-base)
AR R15,R12
BALR R14,R15
where "subroutine-base" becomes a relative or offset address ... and the
location of "base" for the specific virtual address space is known to
be in r12.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 18 May 2004 09:07:18 -0600Eric writes:
note however that for the cp/67 kernel most entries weren't exactly the virtual machine calling the kernel but a privilege instruction interrupt ... which the kernel then had to decode and simulate.
the program interrupt gave the starting address of the offending instruction; so the first thing that the cp/67 kernel had to do was a LRA of the instruction and access the first two bytes. the first two bits of the instruction gave the length of the instruction. instructions were half-word aligned so instructions longer than two bytes could cross page boundaries ... and therefor require the LRA to be repeated for every two bytes in the instruction.
there were interlocks in the cp/67 kernel which allowed it to reliable access virtual memory for the purpose of instruction retrieval and emulation. start i/o instruction got especially complex since all of the channel command words and many of the arguments were effectively part of the instruction execution that needed to be accessed for simulation.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 18 May 2004 11:44:38 -0600Terje Mathisen writes:
all of the GPD san jose people had mainframe background where async i/o with scatter/gather had been the norm for some time.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 7094 Emulator - An historic moment? Newsgroups: alt.folklore.computers Date: Tue, 18 May 2004 11:37:15 -0600Tom Van Vleck writes:
byte value 0-7 mm/dd/yy 8-15 hh.mm.ss 16-19 total kernel/supervisor CPU time since logon 20-23 total virtual CPU time since logon--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: layered approach Newsgroups: comp.protocols.tcp-ip Date: Tue, 18 May 2004 12:19:54 -0600Barry Margolin writes:
ISO international standards body had a rule that ISO and its national chartered bodies couldn't consider standards that violated OSI.
I was involved in HSP (high-speed protocol) attempt to work on it as standard in X3S3.3 (the us body chartered by ISO for working on level 3 & 4 standards in the OSI model ... aka network layer and transport layer).
HSP had a specification that would go directly from the level 4/5 interface directly to the LAN MAC interface. This violated the OSI model and therefor X3S3.3 couldn't work on it for standards.
The problem was (at least) two fold:
1) going directly from level 4/5 interface to the LAN MAC interface skipped the level 3/4 interface and therefor violated the OSI model
2) the LAN MAC interface sits logically somewhere in the middle of the OSI level 3 network layer (at least in part because it includes some network addressing function). by definition anything that interfaces to a LAN MAC interface is in violation of OSI model ... because LANs are in violation of the OSI model.
The Internet issue is that the Internet defines a "internetworking layer" (internetworking protocol layer or IP for short) that doesn't exist in the OSI model ... the osi model only has level 4, transport and level 3, network ... there is no such thing as an "internetworking layer". Therefor anything that involves IP and/or the internet is also in violation of the OSI model .. and by the ISO rules could not be considered.
basically the OSI model reflects somewhat a pre-70s communication state-of-the-art with point-to-point copper wires and disallows the invention of LANs, WANs, and the Internet (or at least the standards body for OSI disallowed inventions that violated the OSI model).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 18 May 2004 12:04:09 -0600glen herrmannsfeldt writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why does Windows allow Worms? Newsgroups: comp.os.ms-windows.misc,comp.os.ms-windows.networking.misc,comp.security.misc,comp.windows.misc Date: Tue, 18 May 2004 14:43:29 -0600Bruce Barnett <spamhater95+U040518143634@grymoire.com> writes:
detailed vulnerability analysis in the late 80s predicated that C language environment would have a factor of ten times to hundred times more buffer length related problems than other program environments with better length handling paradigms (because of the standard length handling paradigm that was part of the standard C environment).
something like 30 years ago, mid-70s, a situation was analysed and documented regarding vulernability allowing exectuable code of any kind to arrive over a network interface.
computing paradigm from the 60s was systems where all software and programs were relatively carefully vented and installed by experienced and trained stated. ordinary people might be able to use such systems, but didn't actually write code &/or install executables. the problem that started appearing with various time-sharing systems in the 70s that supported personal computing ... was that some of them actually allowed end-users to introduce executable code.
The other characteristic is that most of these time-sharing systems from the 70s (or earlier) at least started with the basic premise in their design that they had to protect different users from each other. That permeated the basic design through-out the system.
The stand-alone, dedicated personal computers from the 80s had none of these problems ... they didn't require partitioning that protected a very large number of different users from each other ... and they didn't have to worry about foreign and possibly hostile executables arriving over any network.
There are two somewhat different vulnerabilities:
1) huge number of compromises because of fundamental flaw in the length paradigm used in C language
2) partitioning and security features that needed to a) isolate different local users from each other and eventually b) isolate a user from a foreign and hostile network environment
so there is some analogy to automobiles. long ago and far away ... automobiles required drivers that were trained in all the quirks and mechanics of an automobile. the problem was eventually that somebody wanted to sell everybody a car ... but there wasn't enuf personal chauffer/mechanics for everybody to have a car. they had to come up cars that people could operate themselves w/o requiring a personal chauffer/mechanic.
so if everybody was going to operate their own car ... they eventually had to
1) require a minimum of expertise ... so there were mandated training and licensing programs
2) require a huge amount of mandated safety features
4) have institutonalized vehicle safety checks
3) have a bunch of laws that could charge people with a) reckless operation of a vehicle and/or b) operation of an unsafe vehicle. This could confiscate their vehicle and take away their driving rights. It didn't matter whether people knew anything about the mechanics of a car or not ... they were still liable for operating an unsafe vehicle.
now these are applicable for operation of a vehicle in a public environment. if you have a vehicle that you will only operate in your backyard and never bring into a public environment you aren't subject to most of the regulations.
recent post about looking at entries in CVE database:
https://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
collection of past posts about all kinds of vulnerabilities, exploits, and
fraud:
https://www.garlic.com/~lynn/subintegrity.html#fraud
collection of past posts related somewhat to the reverse ... assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance
all sort of random past threads mentioning the length issue and buffer overflow
exploits:
https://www.garlic.com/~lynn/99.html#219 Study says buffer overflow is most common security bug
https://www.garlic.com/~lynn/2000.html#30 Computer of the century
https://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
https://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
https://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
https://www.garlic.com/~lynn/2001n.html#72 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#76 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#84 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#90 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2002.html#4 Buffer overflow
https://www.garlic.com/~lynn/2002.html#19 Buffer overflow
https://www.garlic.com/~lynn/2002.html#20 Younger recruits versus experienced veterans ( was Re: The demise of compa
https://www.garlic.com/~lynn/2002.html#23 Buffer overflow
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow
https://www.garlic.com/~lynn/2002.html#26 Buffer overflow
https://www.garlic.com/~lynn/2002.html#27 Buffer overflow
https://www.garlic.com/~lynn/2002.html#28 Buffer overflow
https://www.garlic.com/~lynn/2002.html#29 Buffer overflow
https://www.garlic.com/~lynn/2002.html#32 Buffer overflow
https://www.garlic.com/~lynn/2002.html#33 Buffer overflow
https://www.garlic.com/~lynn/2002.html#34 Buffer overflow
https://www.garlic.com/~lynn/2002.html#35 Buffer overflow
https://www.garlic.com/~lynn/2002.html#37 Buffer overflow
https://www.garlic.com/~lynn/2002.html#38 Buffer overflow
https://www.garlic.com/~lynn/2002.html#39 Buffer overflow
https://www.garlic.com/~lynn/2002i.html#62 subjective Q. - what's the most secure OS?
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
https://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ?
https://www.garlic.com/~lynn/2002m.html#58 The next big things that weren't
https://www.garlic.com/~lynn/2002p.html#6 unix permissions
https://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
https://www.garlic.com/~lynn/2003j.html#4 A Dark Day
https://www.garlic.com/~lynn/2003j.html#8 A Dark Day
https://www.garlic.com/~lynn/2003j.html#20 A Dark Day
https://www.garlic.com/~lynn/2003k.html#64 C & reliability: Was "The Incredible Shrinking Legacy"
https://www.garlic.com/~lynn/2003l.html#2 S/360 Engineering Changes
https://www.garlic.com/~lynn/2003n.html#14 Poor people's OS?
https://www.garlic.com/~lynn/2003o.html#6 perfomance vs. key size
https://www.garlic.com/~lynn/2003o.html#20 IS CP/M an OS?
https://www.garlic.com/~lynn/2003o.html#25 Any experience with "The Last One"?
https://www.garlic.com/~lynn/2003o.html#50 Pub/priv key security
https://www.garlic.com/~lynn/2004.html#30 Threat of running a web server?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 18 May 2004 15:53:09 -0600Brian Inglis writes:
nominally most of the kernel ran disabled for external & i/o interrupts .. but all virtual machine execution was fully enabled for interrupts. the virtual machine was run with a time-slice ... and if nothing else interrupted the virtual machine ... there would at least be an external timer interrupt into the kernel. the kernel would then at least update some dispatching priority and possibly re-arrange things so a different virtual machine would be chosen to run.
there was two parts. the most frequently executed instructions were in
the dispatcher loading up all the stuff for dispatching a virtual
machine. you can see that in the CPU hotspot measurements we took as
part of the ECPS effort (looking to see where the kernel spent most of
its time):
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
so frequently, if it had been in the kernel for some time ... there was some queued I/O interrupts that had arrived and where queued up ... and would interrupt as soon as the virtual machine was dispatched. that wasted all of those instructions "dsp+8d2" to "dsp+c84" referenced in the above ECPS URL.
So, there is an instruction "SSM" ... set system mask that can change whether you are enabled or disabled for i/o interrupts. I placed a pair of such instructions effectively just before all the work to load up a virtual machine that opened an I/O interrupt window and then immediately shut it. If there was a queued interrupt(s), the processor would go off to the interrupt handling routine and not get to the 2nd SSM instruction in the dispatcher. There was still small possibility that an I/O interrupt would arrive during the load-up ... but that period was very short.
So the interrupt window effectively eliminated wasting loading up a virtual machine if there was already any queued i/o interrupts.
So the next piece was the dynamic adaptive stuff ... if you ran the virtual machine disabled for I/O interrupts ... and only took interrupts with the dispatch interrupt window ... it would increase the latency processing for handling the interrupt. The problem was that if the environment was a very high interrupt rate ... the constant switching back & forth between application/virtualmachine execution and interrupt handling could totally destroy any cache localty and system thruput. So the dynamic adaptive stuff had to make trade-off decision between interrupt latency processing and cache hit rate associated with interrupt rate. Furthermore, if you slightly delayed interrupts ... and processed multiple in a batch ... the improved cache hit rate of the i/o interrupt processing might actually not only improve thruput ... but actually reduce avg. latency.
So the default was run the virtual machine enabled for I/O interrupts which allowed for latency optimization. However, the i/o interrupt rate would be monitored and considered to be so low as to not have significant effect on cache hit ratio. It was at high i/o interrupte rates ... that the dynamic adaptive stuff would switch the system back & forth between free-for-all i/o interrupts and "structured" interrupts only thru the interrupt window in the dispatcher.
Part of the latency issue in a heavily loaded system was effective device utilization ... since the I/O interrupt routine was also responsible for redriving the device with any pending i/o requests. On 2305 fixed head disks ... this was compensated for by having "multiple exposure" feature. The basic channel infrastructure only supported a single request at a time for device. Multiple exposures created multiple logical devices for the purpose of the channel program structure ... which were all mapped to the same physical device. With a half-dozen requests constantly queued in the hardware for a device, any redrive latency in the i/o interrupt handler was less of an issue. I tried w/o much success to get multiple exposure feature added to other high utizalization devices.
Later working in the non-mainframe environment ... I did get some stuff done for multiple command queueing ... that helps address the device redrive latency.
The problem in the (370) SMP environment is somewhat more complicated with shared controllers being used to simulate shared channels ... and the original (370) SMP only had a very thin layer that had been SMP'ed ... and the rest was behind a global kernel lock (although a bounce lock with queueing rather than a spinlock). If you've turned off i/o interrupts while running in virtual machine mode ... and one processor monoplizes kernel execution (and the other is busily churning away with virtual machine execution) .... it is fantastic for cache hit ratio ... but terrible if there are queue I/O interrupts on channels dedicated to the processor not getting into the kernel. So you have to play some games about making sure that a processor always gets some window to drain pending i/o interrupts on dedicated channels (again you are trading off cache efficiency against i/o service latency).
For 370 158 & 168s ... IBM announced both SMP configurations and what they called "attached processor" configuration. An "attached processor" configuration was fully shared-memory SMP ... but one of the processors had no (dedicated or otherwise) channels at all. In this case, the dynamic adaptive code didn't have to worry about a processor getting i/o interrupt starved ... because one of the processors didn't have any channels. In this scenario the dynamic cache efficiency optimization wasn't to manage just the bad effects of i/o interrupts but also to optimize cache from the effects of cross processor migration (execution of same code constantly changing between processors and loosing cache locality).
Now, 370s, 303x, 3081s, etc ... in two processor configurations ran caches at .90 times that of a uniprocessor (to allow for all the cross-cache chatter); therefor a two-processor system was only 1.8 times a single processor system. A SMP kernel might throw in a lot of other overhead ... so a two-processor SMP system might have only 1.3-1.5 times the effecitvely thruput of the same workload on a uniprocessor.
With all sorts of tricks and magic in the SMP code ... and the dynamic adaptive stuff doing some more magic ... there were 370 "attached processors" configurations that were running at more than twice that of a uniprocessor ... the magic with cache locality more than offset the hardware only being 1.8 times (and whatever minimum magic additional kernel SMP pathlength there was).
For SP1 there was a rewrite to make it less magic and more elegent, traditional SMP implementation. It had the adverse downside that most of the cache locality optimization was lost and typical customers were finding that in a two processor system ... both processors were spending ten percent of elapsed time executing new SMP kernel overhead that it hadn't been executing before.
... oops, longer than i thot it was going to be, guess i got carried away again.
The 370/158 supported integrated channels ... the processor engine inside the 158 ran microcode that implemented both the channel function as well the 370 processor instructions. The 370/158 was also on the knee of the manufacturing cost/performance curve ... something like some automobile assembly lines.
For the 303x line of computers ... they decided to create a channel director ... which was actually a repackaged 370/158 engine running only the integrated channel microcode (supporting six chnannels). The 3031 was a 370/158 repackaged to only have the 370 microcode and to use external channels (in the channel director) rather than integrated channels (time-shared in the processor). The 3032 was a 370/168 repackaged to use the (erzats 370/158) channel director. The 3033 started out being the 370/168 wiring diagram remapped to newer technology chips that were 20% faster. Along the way, they decided that the 3033 needed to be more than 20% faster than the 370/168/3032. The newer chip technology had something like ten times the circuit density of the 168 chips ... but wasn't being utilized because of the simple remapping of the 168 wiring diagram. Some amount of the 3033 performance boost project was redoing the wiring so that it did a lot more on-chip operations. The resulting 3033 was more like 50% faster than the 168 instead of only 20% faster.
I had previously mentioned VAMPS, a 5-way shared-memory processor project where I sort of originally created the whole structure for bounce lock and really lightweight queued kernel requests. It didn't get announced. Somewhat in that timeframe there was also work on something called logical machines .... a 16-way 370/158 shared memory multiprocessor w/o cache consistency (which also didn't get announced). This was sort of the tail-end of the VAMPS effort and before the official product VM/370 SMP support gat underway.
For logical machines, the VM kernel would reliably use compare&swap ... which had cache specific semantics on everything it needed to in the kernel ... and there was feature for cache flush. So the CP kernel would understand about shared memory across the 16 processors ... and would dispatch different virtual machines on specific processors ... which were essentially all private, non-writeable shared virtual address spaces. R/O shared virtual memory was fine and non-shared virtual memory was fine. Anything that might want to operate in this machine with read/write shared memory had to faithfully use compare&swap for all such memory operations ... since not only did it do the compare&swap semantics ... but it was also the only instruction that had any cross-cache semantics.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 18 May 2004 17:35:04 -0600slight digression ... there was some other systems and kernels that had SMP support for these machines.
a specific one had really, really bad thuput and performance on both uniprocessor and two-processor. however, they went around highlighting the fact tha they had really, really great SMP support (support was carefully used in place of thruput) becuase their two-processor thruput was 3.8 times their single processor support. it was sort of met to confuse customers between the issue about really great SMP thruput and really great SMP support.
actually their claim to great SMP support was that their two-processor thruput was 3.8 times their single processor thruput.
what they didn't say was that the single processor benchmark was on a 1mbyte machine and their two-processor benchmark was on a two mbyte machine (if you have twice the machine ... then you double both the number of processors as well as the amount of memory).
so the real issue was that they also had a really bloated kernel with large fixed storage requirements and there was barely any storage left for applications with only one mbyte of real memory. on a two processor machine with only a single copy of the kernel and twice the real storage, they had nearly ten times the amount of real storage available for applications ... and that was the real reason the two processor benchmarks had 3.8 times the thruput of the single processor benchmarks.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: command line switches [Re: [REALLY OT!] Overuse of symbolic constants] Newsgroups: alt.folklore.computers Date: Tue, 18 May 2004 21:34:49 -0600Peter Flass writes:
the issue in 360 & 370 is you have a program
balr r12,r0
using *,r12
.....
l r3,=a(abcd)
tm 0(r3),x'ff"
...
...
bunch of instructions
...
...
abcd dc F'0"
ltorg
=a(abcd)
... now lets say that abcd is at location x'800' within the program
and the literal pool is at x'a00' in the program ... then the assembler
will generate something like
5830C9fe
i.e.
58 load opcode
3 into register 3 from storage
0 no index register
C base register 12
9fe displacement added to contents
of reg 12 to form address where
storage is to be loaded.
now the standard for os/370 and cms was that the storage location
=a(abcd)/a00 got stuck with a value something like
so if I had a program that occuped same r/o shared segment at different virtual addresses in different virtual address spaces ... all the (absolute) relocatable adcons ... could at best take on a single value ... which means it would be limited to working at one specific (virtual) address location. so it doesn't work ... at least not until we get quantum computing at the adcon will know what address it is supposed to be based on what address it is being used from.
So the issue is how to be address constants work in an address free environment ... more so than just the 12bit displacement paradigm supported by instruction storage address calculation.
so to make it work .... i take a page out of the instruction decoding and force address constants (which can be 24bits ... or later 31bits) and make them 24bit displacements ... rather than 24bit absolute addresses. first off, you have to turn off the whole relocation adcon directory infrastructure, if i specified something like:
now to get the real usable value for the second (displacement) form, there has to be some inline code at run time that
l r3,=a(abcd-base) ar r3,r12 tm 0(r3),x'ff'the issue is that the original 360 displacement addressing only allowed for 12bit displacements (that are physically part of the instruction) to be automatically handled by hardware address calculation.
So I went thru some amount of CMS kernel code, the original CMS editor, some number of other programs and converted them from traditional os/360 "relocatable adcons" to fixed displacements with inline, runtime code that calculate the real address. I also later did something similar to iso3270, browse and fulist package. Some amount of this code wasn't "read only" ... so I had to do various restructures for it to reside in a read/only shared segments.
The DWSS shared segment code was based on having captured a virtual memory snapshot of the code and putting away in a special VM/370 kernel structure. The original code included support from the CMS paged mapped filesystem ... instead of having to record the shared segments in special VM/370 control structures ... I just put virtual memory images out into the CMS filesystem ... and applications could load virtual memory images directly out of the page mapped filesystem ... and optionally specify whether they were shared or not shared.
So originally there was a bunch of VM/370 kernel code to support the "shared segment" extensions, the page mapped file system for cms. In addition, there was a bunch of cms kernel and application code converted to be "read only" and be address free ... as well as the support for the page mapped filesystem ... and the CMS support to load application images from the filesystem and specify whether they were "shared" or "not shared".
The CMS people wanted to pick up all the code for DWSS ... but the VM/370 kernel people only wanted to add a drastic subset of the changes to the VM kernel. So the VM/370 kernel people didn't pick up the page mapped filesystem support and only a very restricted subset of the shared segment changes ... and then they cribbed the DWSS diagnose instruction to interface to that drastic subset.
The CMS people picked up most of the shared segment code ... but left out all the page mapped filesystem support (since the necessary vm/370 kernel support had been dropped). Now, this did create something of an anomoly ... all of that initial CMS changes for DWSS shared segment had code changes for both read-only code as well as eliminating absolute adcons (allowing the same exact memory image to execute simultaneously in different virtual address spaces at different virtual addresses).
So one of the anomolies in the CMS DWSS code was the SVC$202 in page zero. Normal calls in CMS involved loading the address of a parameter list in register zero (which also specified the function) and doing executing SVC 202. This could be the form of:
SVC 202
instructions
or
SVC 202
DC AL4(*+4)
instructions
the cms kernel svc handler would look at the first byte after the svc
instruction and if it was zero (this is 24bit addressing ... so a
32bit adcon would always have the high byte zero) and for a normal
return skip the 4byte adcon. The address following the svc call was
for error returns. If there was an error in the processing, and there
was an adcon, the kernel would load the address in the adcon to return
to. If there was an error in the processing, and there was no adcon,
the kernel would go off to some standard kernel error handler and
never return to the program. I could go thru all the applications and
remove the DC AL4(*+4) which eliminates the relocatable address
problem ... but all application specific error handling and recovery
is lost. As an aside, while the interface allowed any address to go
into DC AL4(), common usage would have both error returns and
non-error returns come to the following instruction which would then
check the return code in the register for normal/error.
In any case, I did a hack ... I put a dummy svc in CMS kernel page zero ... in CMS NUCON and called it:
SVC$202 SVC 202 ERR$202 DC AL4(*+4) BR14$202 BR R14and then inline application code I changed from
SVC 202
DC AL4(*+4)
instructions
to
BAL R14,SVC$202
instructions
aka ... go off to the NUCON svc instruction ... which would return to
the branch on register 14 ... which had the value of the next
instruction from the branch and link operation.
that was part of the distributed CMS dwss ... which wasn't required for fixed address shared-segments ... but I had only invented to handle the case for "floating" shared segments.
Later, the SVC202 processing was redefined ... and allowed for
SVC 202 DC AL4(1) instructionsthe "1" is easily recognizable as not a valid address ... and the kernel should return to *+4 after the svc whether there is an error or not.
a couple past posts on shared sgements and some nucon SVC$202 hack
that I had done for address free code.
https://www.garlic.com/~lynn/2001f.html#9 Theo Alkema
https://www.garlic.com/~lynn/2002o.html#25 Early computer games
https://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
somebody want to see some general cms application assembler code
with the use of adcons, svc 202s, and other stuff ... this is
a version of Kermit for CMS dated 1982:
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/decus/rsx83b/356040/cmskermit.asm
over the years people have found other uses for svc$202; various old
postings in the vmshare archive referencing svc$202
http://vm.marist.edu/~vmshare/read.cgi?fn=INTRANS&ft=MEMO&line=116
http://vm.marist.edu/~vmshare/read.cgi?fn=STRANGE&ft=MEMO&line=125
http://vm.marist.edu/~vmshare/read.cgi?fn=STRANGE&ft=MEMO&line=171
http://vm.marist.edu/~vmshare/read.cgi?fn=STRANGE&ft=MEMO&line=236
http://vm.marist.edu/~vmshare/read.cgi?fn=TT&ft=NOTE&line=17
http://vm.marist.edu/~vmshare/read.cgi?fn=CMSSPR2&ft=MEMO&line=147
http://vm.marist.edu/~vmshare/read.cgi?fn=DVF&ft=MEMO&line=225
... how 'bout source for program originally written 1976 .. but
posted version in the archive has some changes dated in mid-80s.
http://vm.marist.edu/~vmshare/read.cgi?fn=PRTRCVR&ft=NOTE&line=1
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: command line switches [Re: [REALLY OT!] Overuse of symbolic constants] Newsgroups: alt.folklore.computers Date: Wed, 19 May 2004 09:54:39 -0600jmfbahciv writes:
a standard 360/370 address constant was typically a 32bit word containing a 24bit address ... absolute/fixed ... relative to "zero". if it was running real ... it was relative to real location zero. if it was running virtual, it was relative to virtual location zero.
these were called "relocatable adcons" ... in the sense they were stored as relative/displacement addresses ... and an administrative dictionary was kept for the loader. when the loader/binder/etc brought the image into memory ... it would access the administrative dictionary and run thru the program image converting all the displacements to absolute (relative to zero) before starting the program.
the 370/370 had convention in instructions for base+displacement that the hwrdware automatically resolved to absolute address at instruction decode. the standard form was
BDDD B ... 4bit/16 register DDD .. 12bit displacementthe contents of the register was combined with the displacement to form the effective address (relative to zero) at instruction decode time. each dynamic image of a program had its own private copy of registers ... so, from a instruction decode standpoint, (most of) the program image was not tied to specific address (relative to zero, whether virtual or real).
the thing that tied a program image to a specific absolute address (relative to zero, whether virtual or real) was the os/360 convention of relocatable adcons ... which in the executable program image was always converted from a displacement to an absolute address (relative to zero).
the issue that I was grappling with was that I wanted the program image to be completely location free ... not only all the address processing in instructions (which had convention of register plus 12bit displacement that was resolved dynamically to an absolute address at instruction execution) ... but also all the "relocatable adcons" (which were being converted to absolute by the standard os/360 loader process).
each program image (address space) had its own private copy of registers. the instructions in the program image were mostly location free because of the instruction convention of addresses being register contents plus 12bit displacement. the issue that prevented a program image from been truely location independent was that they tended to be sprinkled with these 32bit words containing absolute addresses (rather than displacements, they were relative to zero, whether virtual or real).
so i had to go thru code that i wanted to make totally location independent/free and fixup all uses of address constants ... by forcing them to be displacements and modifying the code to do some inline code sequence that added the contents of a register to the dispalcement value to form the absolute address value. From a programming point of view, absolute address is the same whether running virtual or real. When executing virtually, the hardware translation takes a virtual absolute address (relative to virtual zero) and converted to an absolute real address (relative to real zero).
so if i have a program image that is part of a read-only, shared, virtual memory segment ... then if the program image starts at x'100000' in one virtual address space and the same program image starts at x'200000' in a different virtual address space ... then all the instruction storage addresses will work correctly because there will be some register with x'100000' (or x'200000' depending on the address space) ... and all the 12bit displacements will be added to the register value and converted to the correct absolute address for the virtual address space that it is executing in.
however, the program image contains a number of different modules, say each 4kbytes in size or larger (larger than 12bit displacement). to branch between such modules the conventional instruction sequence picks up an absolute address contained in the program image and branches to that location. Since it is an absolute address ... it will need to be relative to zero ... and can either be address of the form x'1nnnnn' or x'2nnnnn' ... but it can't be both (at least w/o having something like quantum effects).
In conventional os/360, these are referred to as relocatable adcons ... supposedly giving the program-image location independence ... but they are only stored as a displacement with respect to some base before they have been loaded into memory. as part of the loader bringing the program-image into memory, the loader runs thru a dictionary of all adcons and converts them from relative to something within the program ... to absolute (relative to location zero). during normal execution, all of the relocatable adcons have become absolute.
For my purposes to have a read-only program image to occupy different (virtual) addresses in different virtual address spaces simultaneously ... the program image had to be totally location independent (even at run time). All the relocable adcons had to still be displacement form at runtime ... not absolute form.
One possible solution that some other technologies have used is totally separate instructions and data (not allowed intermixing of data and instructions that can occur in 360 programs). Address constants are placed in special part of the address space that is not-shared and private to the virtual address space. The programing convention has a process where the program can find the location of its address constants. These address constants can be absolute, but since they aren't part of the program image, they can have the value that is specific to that address space.
the problem that i was having in 360/370 with location independent read-only, shared program image was a combination of the convention of having absolute address constants (at least at runtime) and the address constants were part of the program image.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Wed, 19 May 2004 14:51:40 -0600hack@watson.ibm.com (hack) writes:
so for 360 SMP ... there are multiple real processors ,,, sharing the same flat real address space ... where there are multiple processors (each needing their own page zero) and there is only a single page zero.
the solution was a processor specific page zero "prefix register" ... where the processor loaded a specific (real) page address which was used to modify all absolute real addresses for page zero. of course processors in the same smp complex all agreed to choose different real page addresses for their page zero prefix registers.
On 360 SMP ... any real addresses that mapped to real page zero were rerouted to the page specified by the processor's page zero prefix register. Any real address that mapped to the value in the prefix register ... also went to that real address.
The operation of the SMP page zero prefix register was changed in 370. For real addresses that mapped to real page zero where rerouted to the page specified by the processor's page zero prefix register (just like 360) ... however 370 introduced reverse prefix register mapping. In 370, for a real address that mapped to the page specified in the page zero prefix register ... instead of going to that address ... in went to the "real, real" page zero ... aka the page zero that is the same for all processors in the complex.
In the 360 SMP scenario ... the real, real page zero was somewhat lost. The enhancement for 370 SMP ... was the real, real page zero could become a convenient place to store common, cross-complex information.
here is specific section in esa/390 principles of operation discussing
prefixing
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.7?SHELF=EZ2HW125&DT=19970613131822
here is the search page from esa/390 principles of operation for words
prefix register
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/SEARCH?Book=dz9ar004&searchRequest=prefix+register&SEARCH=Search&Type=FUZZY&SHELF=EZ2HW125&DT=19970613131822&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: command line switches [Re: [REALLY OT!] Overuse of symbolic constants] Newsgroups: alt.folklore.computers Date: Thu, 20 May 2004 09:39:00 -0600jmfbahciv writes:
the issue for cp/67 & vm/370 ... with using the virtual memory hardwware and segment sharing for share between different virtual address spaces. on 370, vm/370 used 64kbyte segments & in 24bit addressing that provided up to 255 segment "objects".
The problem with relocatable adcons ... and the subset of virtual memory management released in the product as DWSS ... was that at installation time, a fixed/absolute virtual address had to be chosen for a shareable program. Now any program image might be one or more 64kbyte shared segments ... and there were lots more program images to be defined as shared than there were unique virtual addresses. For a specific user, CMS tended to have all applications that person needed running in a single virtual address space.
The issue became when a person needed combinations of shared program images simultaneously in the same address space. For the first dozen or so ... the system installation process could fabricate unique virtual addresses for the desired combinations. However, passed a certain point there weren't sufficient system-wide unique virtual addresses (combination of one or more 64kbyte contiguous segments in 24bit address space) to satisfy all possible user requirements at the installation. No specific user might want more simultaneous shared objects than could in a single 24bit address space ... but for the aggregate of all users wanting some combination subset of all possible shared objects ... being able to assign unique system-wide virtual address for every possible shared object became impossible.
So the original virtual memory management addressed the limitation of having at most 255 possible shared objects were two fold:
1) shared-objects could be normal program images in the cms filesystem ... rather than in a global, system-wide kernel defined facility. subsets of the user community could have there own set of program images that were defined as shared ... and didn't need to follow a single, system-wide convention defined for all users at the original installation of the application
2) it was possible to go thru various applications and modify the relocatable adcon convention ... to use address constants that were displacements/offsets/relative to some value that would be in a register ... and have inline code to add the displacement value occupying the program image to some value in a register. the net result was that the program image became totally location independent ... and the same program image could occupy a read-only shared segment and that shared-segment could be defined as arbritrary different virtual addresses in different virtual address spaces.
The whole relocable adcon philosophy was invented in the days of os/360 and real memory ... where a single real memory was shared by all simultaneously running applications. The program image on disk could be loaded at an arbritrary location ... so any arbritrary combination of programs could occupy whatever (real) available addresses available. The installation didn't have to go thru every available installed program at installation time and assign a arbritrary unique address ... which could prevent some combinations of applications of running simultaneously if they were forced to pre-assign fixed, absolute address to every program.
However, the os/360 people hadn't yet considered virtual address spaces and shared segments ... where different virtual address spaces might want to have arbritrary different combinations of program images ... but still want to have the physical space taken up by such program image to shared across all simultaneous users. While the instruction architecture defined for program images that were location independent ... the os/360 designers made some sort cuts in defining convention for location related data (i.e. the relocatable adcons).
So, I spent a fair amount of time trying to overcome the short cut taken with the relocatable adcons convention actually being absolute addresses at execution time ... and being the chink in preventing executing program images from being totally location independent.
Note that also, the relocable adcon convention also prevented the
program image on disk being exactly the same as the executing program
image (since there was the little matter of doing the relocatable
adcon swizzle from offset to absolute at load time). This then
created opportunities with the page mapped filesystem and simply
pointing the paging system at a program image in the filesystem and
depending on the paging system to do all the work (not requiring the
loader to swizzle the adcons when the page was brought into storage
for execution):
other posts about page mapped filesystem
https://www.garlic.com/~lynn/submain.html#mmap
past post about location independent program immages
https://www.garlic.com/~lynn/submain.html#adcon
An sort of side story ... was somewhere along I was doing some work on logical machines (part of a recent thread in comp.arch on symmetric multiprocessing) ... and there was a corporate advanced technology conference ... where it was asked that logical machines be presented. Also on the agenda was presentation of 801 and cp.r.
so during the logical machine presentation, there was some heckling by somebody in the 801 group ... who stated that they had examined the product vm/370 code at the time and it contained no SMP support ... so they didn't believe that we could run a vm/370 system on a logical machine (a non-cache coherent, 16-way smp ... with 16 370/158 engines all tied together). the response was that the code in the vm/370 could be modified to support multiprocessor (the heckler from the 801 group was basically expressing the opinion that they didn't believe that somebody could write a couple thousand lines of code modifications to the vm/370 kernel).
so it came time for the 801 group to give their presentation ... and they said that the machine was 32bit virtual address and it had 16 256mbyte segments ... which were implemented as 16 segment registers (rather than a table of 16 segment table pointers). I returned the curtesy of heckling them about 1) the huge number of lines of code being proposed for cp.r ... sure seemed like a lot bigger effert than the rather modest amount of changes needed to enhance vm/370 to support 16-way multiprocessor (and which they sort of had implied disbelief that it could be done) and 2) having only the limited 16 possible segments .... seemed to severely restrict the total number of useful different shared objects that could defined in such an environment (which came from trying to grabble with the problem with trying to manage an environment with a maximum of 255 unique shared objects in the 370 world).
the reply was that there were no protection domains in 801 at runtime; that all application, runtime code could change the contents of segment registers as easily as it could change the contents of general registes. that the convention allowing free access to any location in a 32bit (virtual) address space by simplying changing the contents of a general register to address the location ... was extended to the segment registers to provide the application inline code to any of the possible system segments (i.e. applications could as easily do cross address space addressing as it could do intra-address space addressing).
this was somewhat the target for the office product division displaywriter follow-on product; 16bit 801 processor called ROMP running with cp.r ... written in pl.8. A problem did start to show up when the displaywriter project was canceled and the decision was to retarget the machine to the unix workstation environment. They would get the company that did the AT&T port for PC/IX to do one to what was to become called the PC/RT. An issue tho with unix there was something of assumption about having hardware protection domain between what applications could do and what the kernel could do ... and you didn't provide every arbritrary application free wheeling access to all privileged protected security features.
recent post in comp.arch mentioning logical machines
https://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
other posts about 801, romp, etc.
https://www.garlic.com/~lynn/subtopic.html#801
other posts about smp, compre&swap, etc
https://www.garlic.com/~lynn/subtopic.html#smp
misc. other posts in the recent comp.arch thread
https://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004e.html#42 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004e.html#44 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004e.html#51 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004e.html#52 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#3 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#4 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#5 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#15 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#19 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#22 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#25 Infiniband - practicalities for small clusters
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Meta] Marketplace argument Newsgroups: comp.arch Date: Fri, 21 May 2004 13:34:14 -0600Rick Jones writes:
there use to be a page on some hp.com url that described the work of somebody who done the dual address space 370 architecture (i.e. having software that needed to have addressing to multiple, different virtual address spaces), worked on 801 fort knox (replace all the micro-engines in various controllers, misc. general purpose computers as well as the low&mid-range 370s), and snake (and talked within past couple years recently about having done a lot of the ia-64 architecture).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Meta] Marketplace argument Newsgroups: comp.arch Date: Fri, 21 May 2004 21:18:07 -0600"del cecchi" writes:
... hint
http://www.hpl.hp.com/news/2001/apr-jun/2worley.html
some of the other hp.com references that went into more detail are now 404
lets see if the way-back machine works
https://web.archive.org/web/20000816002838/http://www.hpl.hp.com/features/bill_worley_interview.html
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Meta] Marketplace argument Newsgroups: comp.arch Date: Fri, 21 May 2004 22:17:17 -0600Anne & Lynn Wheeler writes:
that whole 801 thing in the very late 70s and early 80s was the large number of different micro-processors all over the corporation ... all requiring their unique programming. the low and mid-range 370s had all been microcode engines ... going back to 360 days. the issue going into the 4381 was that chip technology was starting to get to the point where you could consider actually doing a mid-range 370 directly in hardware. the advances in chip technology was happening at the same time the push for using 801 to replace the wide variety of micro-engines with a common 801 architecture. The 4381 issue wasn't so much that the idea for replacing all the micro-engines was bad ... but that 4381 could get much better price/performance by implementing directly in hardware (no longer using the micro-engine approach for mid-range 370).
by comparison, the 4381 predecessors; 4341 & before that 148 ... were heavily microcoded micro-processor engines ... avg. something like ten microcode instructions per 370 instructions i.e. the mip rate of the microprocessor engine had to be ten times faster than the 370 mip rate. this is akin to several of the current day 370/390 emulators running on intel platforms.
in fact, ecps for 148 ...
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
there was effectively a ten times speed up for straight kernel code dropped into microcode ... on nearly a byte-for-byte bases i.e. took 6k bytes of kernel 370 code and dropped it into 6k bytes of microcode for a 10:1 speedup. the issue here was that while overall the microcode engine was simpler than 370 ... the straightline kernel code made little use of any 370 complexities.
there were two categories of ECPS speed-up ... straight kernel code dropped into microcode on nearly 1:1 basis (giving 10times speedup) ... and modifying the virtual machine execution of privileged instructions. Enhancing privilege instructions operation in virtual machine mode could bring a 40-100 times speed up ... since the change was done directly in the native microcide instruction processing routine w/o having to interrupt at all into the kernel for instruction simulation.
I would have met bill when he was share chair of the hasp group (again see wayback reference) but can't remember ... since as an undergraduate I had done a lot of changes to hasp system and was given the opportunity to present at share a number of times.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vm Newsgroups: bit.listserv.ibm-main Date: Sun, 23 May 2004 13:48:12 -0600richgr writes:
at some point there were gateways established between the bitnet/earn mailing lists and the usenet news distribution facility. usenet which had been for the most part uucp ... over time, mostly migrated to tcp/ip and the internet.
many current ISPs don't carry all of the "bitnet" gatewayed mailing lists newsgroup ... and for the places i've run across bit.listserv.vmesa-l ... there has been almost no activity (i.e. little of the vmesa traffic is actually being gatewayed). I count over 400 newsgroups defined in the bit newsgroup hierarchy ... but the majority don't seem to be active &/or actually have a functioning gateway.
misc. past postings related to bitnet/earn:
https://www.garlic.com/~lynn/subnetwork.html#bitnet
the internal corporate network was almost totally vm-based (as well as all the networking related tools) and larger than the arpanet/internet from just about the beginning until about sometime mid-85.
a big issue for the arpanet came with the big switch-over from homogeneous networking to internetworking with technology like gateways on 1/1/83. one of the big issues for the vm-based internal corporate network was that it had effectively gateway function from its origins (and significantly contributed to the internal network ease of growth).
In various respects the JES & other mainframe family of networking shared numerous of the arpanet homogeneous limitations. The stereotype of problems with homogeneous networking was the requirement for synchronized conversion of all nodes. The internal corporate example was a mvs system being upgraded to the latest release of JES ... which was generating file-formats that was causing MVS systems in hursley to crash ... which was in turn blamed on the VM-network infrastructure. One of the tasks that had been given the corporate vm-based networking infrastructure was to maintain canonical JES header formats and the vm-gateways were given the responsibility for knowing which version JES might be on the other end of a wire and to appropriately convert JES headers to keep the MVS from crash and burn. The problem with polluted JES headers between different releases causing respective MVS systems to crash ... was just one of the features that restricted MVS systems to isolated end-nodes in the internal network.
Another common similarity between the JES networking support and arpanet was the use of a one byte field for node addressing. JES was slightly more restricted since the one byte field was also used to address all the local hasp psuedo-devices ... and JES has a nasty habit of trashing anything on the network that has an origin and/or a destination that wasn't in the local one-byte device table (which would have been a real disaster for the internal network to even consider using JES as any sort of intermediate node in the internal network; aka it would arbitrary trash traffic that had origin or destination that wasn't in its local node table .... and it could arbitrarily crash the whole machine if some traffic from a JES system at a different level happened to come by).
At the time of the 1/1/83 switchover from arpanet to internet, arpanet
had approx. 250 nodes (at the limit of its addressing infrastructure)
and the internal network had almost a thousand nodes. misc. related
posts on the subject:
https://www.garlic.com/~lynn/internet.htm
minor reference on the web: A Social History of Bitnet and Listserv
http://www.computer.org/annals/articles/bitnet.htm
in the above, it mentions that bitnet grew slowly in the early '80s,
having only 157 nodes at the beginning of 1984. The summer of 1983,
the internal network had passed 1000 nodes and was well on its way to
doubling that; specific reference:
https://www.garlic.com/~lynn/internet.htm#22
and here is a note from somewhere early 1984 sort of outlining earn
https://www.garlic.com/~lynn/2001h.html#65
the above somewhat refers to that fact that I took a lot of heat and
blame for computer conferencing in the 80/81 timeframe.
the corporation contributed heavily to all the bitnet links inside the US ... and possibly paid for nearly all the "earn" (i.e. non-US bitnet) links outside the US
in my desk i have a clear plastic ball (about same size of baseball) commemorating the 1000th node on the internal corporate network.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: MITM attacks Newsgroups: sci.crypt Date: Sun, 23 May 2004 16:44:52 -0600Guy Macon <http://www.guymacon.com> writes:
you walk into your bank and something is exchanged that can uniquely provide unique mutual authentication. from then on, you and the bank can exchange messages based on the mutual authentication technology.
somebody else walks into the bank and something else is exchanged that also enables unique mutual authentication. you then want to communicate to this other entity ... you can securely send the message to your bank and have them securely forward to the destination.
the security business process of trust effectively works the same if the two of you exchange messages directly and the bank acts just acts public key server (somewhat akin to the yahoo ietf draft submitted last week). a vulnerability is if you are using the same exact infrastructure to establish trust with the web-of-trust keyserver ... then MITM could be attacking that also. the countermeasure is again some out-of-band information that isn't vulnerable to the MITM attacker. sometimes web-of-trust assumes that it might be able to use a suspect communication channel (prone to MITM) in multiple different ways ... in the hopes that the MITM isn't your ISP and therefor constantly operating.
However, if it is possible to demonstrate trusted mutual authentication between two different parties and a trusted 3rd party ... then it is possible to leverage that to extend mutual authentication directly between the two parties. The level of business trust isn't directly affected by having the bank be the intermediate transmission or by just having them provide the authentication infrastructure.
now attacks on this infrastructure wouldn't be MITM ... but they might be insider. a lot of existing authentication infrastructure is based on various kinds of shared-secrets, aka something you know static data. a lot of current fraud is harvesting such static data and using it to impersonate other entities. a lot of phishing email is making the email sound official enuf that consumers are tricked into believing it w/o having actual proof. So is this a MITM attack? ... or social engineering? Are all insider attacks, MITM?
minor drift, reference to recent news note about a study that is
about to be published:
https://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Usenet invented 30 years ago by a Swede? Newsgroups: sci.archaeology,soc.culture.nordic,soc.history.medieval,soc.history.science,comp.protocols.tcp-ip,alt.folklore.computers Date: Sun, 23 May 2004 15:57:07 -0600Doug Weller writes:
old posting in alt.folklore.computers on the uucp subject:
https://www.garlic.com/~lynn/2001b.html#57
the above has reference to the UUCP web site:
http://www.uucp.org/
misc refs from search engine using: usenet, uucp, history
http://www.vrx.net/usenet/history/hardy/
http://www.uucp.org/history/index.shtml
http://www.cs.uu.nl/wais/html/na-dir/usenet/software/part1.html
http://www.tldp.org/LDP/nag/node256.html
http://livinginternet.com/u/ui_old.htm
usenet & uucp both predate the big switch-over of the arpanet to tcp/ip on 1/1/83. somewhat an aside, 5-6 years after the switch-over to tcp/ip, the federal gov. had gosip which was mandating the elimination of tcp/ip with total conversion to osi.
recent posting today touching on some early networking
https://www.garlic.com/~lynn/2004f.html#30
the internal network (mentioned above) started in somewhat the same way the description (in the usenet/uccp references) of the origins of usenet ... except it was quite a bit earlier and between cambridge and endicott. there were going to be this new mainframe generation, the 370s ... that hadn't been announced yet and had some differences from that of 360 ... especially the virtual memory hardware being different from the 360/67. cambridge had done the original virtual machine operating system ... which included simulation of quite a few instructions. the endicott proposal was to modify the cambridge virtual machine supervisor to provide simulation of 370 defined instructions & tables rather than the 360/67 defined instructions and tables. so there was this distributed development project between endicott and cambridge.
i believe an earlier version of the software had been used to communicate between a 2250mod4 and cambridge's mainframe. 2250s were large vector graphics display and keyboard ... most of them with hardware configuration to interface to mainframe. the 2250mod4 was somewhat different, rather than a special purpose dedicated controller box ... the 2250mod4 had an 1130 computer as a controller. for this particular 2250mod4 ... somebody also had ported the pdp1 spacewar game.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: MITM attacks Newsgroups: sci.crypt Date: Sun, 23 May 2004 22:47:57 -0600Tom St Denis writes:
or maybe greg was clean ... but some of the people that got their keys signed ... lied and weren't really there at all. you may have been able to vet greg ... but how well did greg vet the people for every key he signed ... those people may have had evil twins.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Usenet invented 30 years ago by a Swede? Newsgroups: comp.protocols.tcp-ip,alt.folklore.computers Date: Mon, 24 May 2004 07:27:10 -0600"Inger E Johansson" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Questions of IP Newsgroups: comp.protocols.tcp-ip Date: Mon, 24 May 2004 07:38:47 -0600"Aashish Manocha" writes:
there was the big switch-over in arpanet on 1/1/83 to ip protocol. a big feature of ip, or internetworking ... was gateways between networks .. or the inter-network protocol. prior to 1/1/83, arpanet had been packet-switched ... but a homogeneous network w/o gateways. one of the assertions about the internal network being so much larger than the arpanet from just about the start until sometime mid-85 ... was that the internal network effectively had a gateway-type facility in every node.
anyway in the internetworking sense, ip provides the routing between networks ... or the gateway function ... something that doesn't exist in the OSI model.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: MITM attacks Newsgroups: sci.crypt Date: Mon, 24 May 2004 07:22:04 -0600Lassi Hippeläinen writes:
1) is there anything absolutely sure at all in the world?
2) many insecurity issues are financially related, a significant
amount can be addressed with security proportional to risk ...
old post on the subject:
https://www.garlic.com/~lynn/2001h.html#61
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why doesn't Infiniband supports RDMA multicast Newsgroups: comp.arch Date: Mon, 24 May 2004 09:45:11 -0600Terje Mathisen writes:
a little before the xtp time-frame there was a FEC hack (back about the time kodak bought cyclotomics, which was company doing reed-solomon products; although we did have a guy that had been graduate student at jpl/caltech and had done a lot of work on reed-solomon) everything transmitted was sent reed-solomon encoded (aka 15/16ths reed-solomon encoding getting about six orders BER improvment; on link that typically ran 10**-9, 15/16ths reed-solomon encoding would give about 10**-15 effective).
if the received block couldn't be recovered and a NAK was transmitted, then rather than retransmitting the original block ... the half-rate viterbi of the original block was transmitted. in this scenario, it was possible to have errors on both the original and the retransmission and still obtain valid contents. if the unrecoverable errors exceeded some threshold, the protocol switched to transmitting the half-rate viterbi as part of the original transmission (cutting the effective transmission rate in half ... but eliminating the latency when there was high probability of needing it anyway).
misc. past posts on the subject
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
https://www.garlic.com/~lynn/2001.html#1 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2001k.html#71 Encryption + Error Correction
https://www.garlic.com/~lynn/2002p.html#53 Free Desktop Cyber emulation on PC before Christmas
various past posts on xtp (at one time, i was corporate rep to the xtp
TAB), intermixed with comments about hsp (high-speed protocol proposal
out of the xtp organization) and osi:
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Mon, 24 May 2004 09:18:47 -0600hack@watson.ibm.com (hack) writes:
there is still some 16mb stuff ... around ... a couple posts in the past couple days in bit.listserv.ibm-main on some qsam (file i/o) option.
there have been below the line (16mb) and above the line issues where CCWs were kept below the line because of the 24bit address field in CCWs. They could do above the line I/O ... by having the 24bit CCW address field point to IDAL (below the line) ... which supported 31bit address fields.
total aside ... 360/67 had both 24bit and 32bit virtual memory options. for 370, the 32bit virtual memory option was dropped and it only had 24bit. XA introduced 31bit virtual addressing.
while not impacting program correctness there was a problem with 2k/4k pages and the introduction of the 370/168-3 ... which doubled the cache of the 370/168-1 from 32kbytes to 64kbytes. with 32kbyte cache they had used bits in the page displacement part of the address ... allowing cache indexing in parallel with TLB virtual->real address lookup. For 168-3 they co-opted the 2kbit for cache line indexing ... as long as the machine was working in 4k page mode. If the machine was working in 2k page mode ... they disabled half of the cache (since the 2k bit might magically switch values in the virtual->real conversion). What was even worse was if you were running VM and had a mix of 4k page virtual machines and 2k page virtual machines ... the machine had to stop and wipe the cache any time there was transition between 2k & 4k page modes. There were some customers that had been running DOS/VS (2k page operating system) under VM on 370/168-1 that saw significant thruput degradation when they upgraded the 168-1 to a 168-3 (with double the cache).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Who said "The Mainframe is dead"? Newsgroups: bit.listserv.ibm-main Date: Mon, 24 May 2004 15:37:38 -0600jsullivan@ibm-main.lst (Sullivan, John) writes:
by the mid-80s, workstations and larger PCs were starting to takeover the mid-range marketplace. some assumptions about every 4341 being upgraded to 4381 ... and selling additional 4381s didn't materialize. i preceived there to have been similar circumstance for vax in pretty much the same market place.
going into the mid and late 90s, some IT management seeing what had happened to the mid-range .... looked at relatively large and expensive central IT staff and wondered about whether every person and department could become their own system administrator. some of the issues was that some of the glass house industry strength had become so institutionalized that it looked easy from the outside. some executives figured that it couldn't be that difficult when there weren't more disasters and problems ... so how hard could it be to let everybody perform their own sysadm duties.
with the appearance of Y2k remediation ... there were some mainframe operations that could fill their mainframe staffing positions. some of the high-end financial institutions were paying top dollar to lure away experienced mainframe staff to help with their remediation efforts. other experienced staff were retiring having been doing the nearly the same kind of job for 30 years or more. there wasn't any backfill from younger generations ... the universities had been turning out graduates for some time on non-mainframe platforms ... and they were getting significantly better offers from the internet boom (bubble).
some institutions put in strategic conversion off of mainframe because they had staff openings for five years or more that couldn't be filled. I've mentioned in the past one gov installation that turned off the mainframe when the last mainframe support person (they had) retired.
other significant facters in the late 80s thru early 90s was terminal emulation on IBM/PCs. in the early to mid 80s ... terminal emulation gave IBM/PCs a nearly instant major market. You could replace a 3270 with a ibm/pc ... and in the same desk footprint and price range ... have both a 3270 and some local computer capability. As applications on the PCs proliferated in the late 80s ... there was a larger and larger requirements for the PCs to have high-speed access to data ... which was no longer being met by the terminal emulation infrastructure.
There were some significant internal battles where the disk division wanted to offer a far superior infrastructure offering to allow PC & workstation applications to access glass house data. This would have had a severe downside effect on the communication divisions installed terminal emulation infrastructure. At one point there was a major presentation by the disk division claiming that the communication division's intransigent position would result in the death of the disk division. One of the results was that starting in the late 80s there was an enormous increase in demand for disk capacity outside of the glass house .... accompanied with a migration of data from the glass house to local & distributed environments. This also showed up in decline in mainframe processor and disk revenue. In 1992, IBM went into the red.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 25 May 2004 07:58:21 -0600Brian Inglis writes:
scheduling is basically calculating some sort of priority for a process and ordering the process into a list ... of of that time is charged to the process.
since the various lists are kept in order (and charged to specific process) ... selecting a kernel thread basically involves pulling the first off the list ... which gets charged to that kernel thread. selecting a virtual machine is basically pulling the first off the list ... which gets charged to that virtual machine.
the original cp/67 kernel that i worked with in '68 did have some dispatching structure that sporadically did all sorts of re-arranging things based on timer events ... that was independent of any requirement ... and was accounted for to "system overhead". It was basically proportional to the number of processes and independent of any work being done. For 30 virtual machines ... it was consuming ten percent of total elepased time. It was not attractive for two reasons 1) it was unrelated to any actual work going on in the system ... and i have a principle that activity should be proportional to the work and 2) it was extremely heavy handed amount of overhead. I made a joke at the time that I had an objective to be able to accomplish the same effect in zero instructions.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 25 May 2004 08:12:19 -0600Brian Inglis writes:
original 360 architecture for instructions went to some amount of trouble that nearly all instructions in a program image would operate regardless of the location of the program image.
the problem that i had in doing some read-only shared segment code involving program images ... was early 360 operating system convention of "relocatable adcons". these were address data carried in the program image that pointed to module entry points, data structures, etc. ... and were relative displacements in the image out on disk ... but as part of bringing the disk image into memory for execution, the loader swizzled the relative values into absolute values based on the address location that the program image was loaded.
I had done this enhancement to the cms filesystem to support paged mapped operation ... and also added a lot of bells & whistles to support allowing arbritrary objects to occupy read-only shared segments common to multiple different virtual address spaces. The problem was to eliminate the loading swizzle that occurred moving program image from disk to memory because 1) trivial page-mapping between a virtual address space and a program image in the filesystem, didn't want to have the page interrupt handler to have to worry about whether there was data in a page that had to be swizzled or not and 2) different processes might choose arbritrary virtual address space locations to load the program image ... and if it was loaded as a read-only shared segment ... the address constants couldn't manage to have arbitrary different values simultaneously.
lots of previous postings (some recent) on location independent
program images:
https://www.garlic.com/~lynn/submain.html#adcon
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 25 May 2004 08:21:24 -0600Terje Mathisen writes:
several years ago ... i had an assignment to port a 50,000 vs/pascal application to another vendors platform. there were a couple off issues
1) vs/pascal had some number of extensions ... that didn't exist in the other vendors platform,
2) i don't believe the other vendor's pascal ever had been used with reasonably sized application before
3) the vendor had outsourced their pascal work to an operation that was something like 12 time-zones away, i just couldn't drive by and drop in on them to discuss problems.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: can a program be run withour main memory ? Newsgroups: bit.listserv.ibm-main Date: Tue, 25 May 2004 08:40:31 -0600ibmlax@ibm-main.lst (Lax TS) writes:
i've read stories about some early computers having rotating drums as memory and that was where program were executed from ... so not only is it possible ... that was how some of the early computers worked.
however, the question sounds either like a really bad troll or homework ... since a little use of search engine should turn up the descriptions of early computers that had rotating drum memory.
however, there is another issue ... about relocatable adcons ... which i periodically rant about. i had done this page-mapped enhancement for the cms file system and support to have arbritrary objects loaded as read-only shared segments in different virtual address spaces ... potentially at different virtual addresses.
for the most part the 360 genre has gone to a great deal of trouble that program images are location independent ... i.e. the base+displacement convention has no dependency on program location for execution. the problem is that the convention with relocatable adcons is that they are relative in the program image out on disk ... but get swizzled into a location specific constant when the loader brings them off disk into memory.
the issue was actually two fold ...
1) with the page mapped filesystem it would be convenient to just set up the virtual memory tables and point to object in the filesystem ... and not have the paging supervisor have to worry about swizzling random locations in the pages when they are brought into memory
2) if the same program image happens to occupy a read-only shared segment ... and be mapped to arbritrary different locations in different address spaces ... it would require that the swizzled absolute address constants be able to take on multiple different values simultaneously (possibly requirement for a little quantum computing).
so to have program images that could be loaded from paged mapped filesystem by the paging supervisor (w/o requiring loader swizzle of relocatable adcons into absolute adcons) and to have the mapped program image be truely location independent (potentially mapped simultaneously to different locations in different address spaces) .. I had to hack the code to use relative adcons ... adcons that were used as displacements analogous to the base+displacement paradigm used in instructions.
random past postings about page mapped filesystem
https://www.garlic.com/~lynn/submain.html#mmap
random past postings about location free program images
https://www.garlic.com/~lynn/submain.html#adcon
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 25 May 2004 09:35:23 -0600"Stephen Fuld" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 25 May 2004 11:45:31 -0600"Stephen Fuld" writes:
the 360 instruction architecture allowed for displacement+register(s) for generating effective address ... and therefor had location independence. it is possible to have a convention on 360 where "addresses" that are in storage locations (rather than part of insturctions) are displacements rather than absolute. instead of having a convention were an address was loaded from storage location and used immediately as an effective address ... have a convention where the storage location value is treated as a displacement ... that needs to be combined with some register value to from an effective address (in a manner analogous to what instructions do).
then you can have an image on disk that is location independent and can be moved into memory w/o any swizzling of storage values. it is then also possible to have shared, r/o images occupy virtual memory segments ... where the same program image segment doesn't have to be bound to a fixed address location in every virtual memory address space.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Finites State Machine (OT?) Newsgroups: comp.arch,sci.electronics.basics,sci.electronics.design Date: Tue, 25 May 2004 14:42:40 -0600Casper H.S. Dik writes:
one of the pathlength things i did was go thru all of the kernel and identify all leaf routines. i identified these and modified the kernel call macro to recognize a leaf routine was being called and do a BALR in place of an svc8. i then defined a fixed (unused/reserved) location in page zero for temporary register save ... this then eventually came to be called "balrsave" (so the leaf routine saved caller's registers in page zero temporary area rather than in a passed save area).
the next thing was to go thru and identify all non-leaf routines that only made calls to leaf routines ... these then became sort of 2nd order leaf routines. these were also modified so that the caller used BALR in place of svc8. however, these routines instead of using "balrsave" for temporary save of the caller's registers used an adjacent area that became to be called "freesave".
For various reasons, the svc8/svc12 calling convention originally took approx 275microseconds on 360/67 (per call) ... it was possible to optimize that down to about 100microseconds by recoding some of the stuff used for debugging purposes. Several of the leaf routines were high frequency calls and performed operations on the order of hundred microseconds or less ... and therefor the svc8/svc12 calling convention was on the order of half that processing time.
The svc call to BALR change picked up something like 20-30 percent of
(remaining) kernel time ... on a kernel that I had already optimized
to pickup something like 80percent with fastpath changes described
in previous posts
https://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
the earlier 80percent kernel overhead optimization (presented at fall '68 Atlantic City share) had included various interrupt and dispatching fastpath as well as special case fastpath for various virtual machine simulation operations. It also included the reduction in the svc8/12 call/return overhead from 275mics to around 100mics ... but didn't include the BALR call changes for leaf routines.
The BALR call changes were done the following summer (of 69), when I got con'ed into going to Boeing (student summer employee with a fulltime management job classification level and a badge that let me park in the management parking lot at corporate hdqtrs next to boeing field) to help get BCS setup and operational. That summer, I also did the first version of dynamic adaptive fair share scheduler, the global LRU page replacement, and the hack that allowed portions of the cp kernel to be non-resident and pageable.
scheduler refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare
page replacement refs:
https://www.garlic.com/~lynn/subtopic.html#wsclock
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Tue, 25 May 2004 15:09:21 -0600"Stephen Fuld" writes:
basically for the past 15-20(?) years the mainframes have had a subset of the virtual machine facility built into the microcode of the hardware called logical partitions (LPARs, something is currently the rage for being duplicated on a lot of other hardware platforms). they are virtual machines ... except they aren't paged/swapped ... and the memory of these vritual machines are contiguously allocated with base/bound hardware specification (and all the special case virtual machine handling is done by the machine microcode).
however the "do-relocate" (or "do-interpretive"? ... DIL?) instruction (which provided base/bound) from the 360/370 days was used exclusively by emulator applications. It was supervisor diagnose x'83' opcode with parameter that selected the DIL(?) function (most of my information on this is 2nd or 3rd hand).
The only exception that i know of was an IBM system engineer (on the boeing account) got a highly modified version of CP/67 running on the 360/50 at the Seattle IBM datacenter (occupied the glass front room on the first floor that currently has ???? jeffory, jasper ... some company that starts with a J (at least the last time i drove by). His work was early 70s before virtual memory was announced on 370s.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Random signatures Newsgroups: gnu.emacs.gnus Date: Tue, 25 May 2004 16:05:10 -0600Max Quordlepleen writes:
example of past post with zippy signature
https://www.garlic.com/~lynn/93.html#5 360/67, was re: IBM's project F/S?
and post to gnu.emacs.gnus, 2001
https://www.garlic.com/~lynn/2001b.html#77 Inserting autom. random signature
https://www.garlic.com/~lynn/2001b.html#78 Inserting autom. random signature
yow had a problem that it used a 16bit random number to select a byte position in the file ... and then move to a saying boundary. this only worked for files that were 64kbytes or less ... it had to be patched if you had more than 64kbytes of random sayings.
could also check other postings to the thread in this n.g. from 2001
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: can a program be run withour main memory? Newsgroups: bit.listserv.ibm-main Date: Tue, 25 May 2004 23:14:50 -0600Efinnell15 writes:
1401 mpio did unit record<->tape front end for the 709 which was primarily used to compile/execute student fortran jobs under ibsys (running tape-to-tape).
they moved the unit record and seven track tapes to 360/30 .. and ran it in 1401 emulation ... when I wasn't trying to get the 360/30 version of mpio running. I got to invent my own interrupt handler, device drivers, task handler, storage management, console interface, etc. I eventually had approximately a box of cards (2000) program; maybe 1500 instructions or around 5k bytes.
on 360/30, the 2400 tape control CCW op-code (this reading off my handy gx20-1703-7 green card, not from memory):
DDMMM011
DD density
00 200
01 556
10 800
11 ---
MMM mode modifer
000 no-op
001 not used
010 reset condition, set density, set odd parity, data converter on,
translater off
011 ... 9track only ...
100 density, even parity, data converter off, translater off
101 density, even paritiy, data converter off, translater on
110 reset condition, density, odd parity, data converter off, translater off
111 density, odd parity, data converter off, translater on.
typically if you couldn't read a seven track tape ... it was issue of
trying different combinations of density (200, 556, 800 bits per
inch), parity (even/odd), and possibly data converter and translater
options.
in straight bcd mode, 80 byte "card" images, the six bits of each byte (7 tracks, one parity track) basically was straight character ... with bcd a subset of of ebcdic. for binary, there were 160 byte "card" images on tape.
reading cards (for card->tape) was a little harder ... basically, the 2540 reader on the 360 read cards in ebcdic mode, never getting more than 8bits out of a column with 12rows (and bcd wouldn't punch more than 6bits out of a column with 12rows).
instead of doing a read, feed, select stacker ccw op-code ... you did a read ebcdic (11000010/C2 ccw opcode). 2540 ebcdic reads all 12 rows of each column but then has rules for mapping between 8bit ebcdic and 12 rows ... basically no more than six rows are punched in any one column (and the rules for mapping of six out of twelve rows provides for 256 possible values).
If there are punch hole combinations that violate the ebcdic mapping, then an error is generated. I then reread the card with column binary ccw (11100010/D2 ccw opcode). For this there are two six bit values mapped to each 12row column and are read into 160 bytes of 360 memory. I've talked to some people since then who wrote programs that read all cards as binary ... and then looked at the resulting 160 bytes in memory to see if it was really bcd or binary ... and could program reconstruct an 80byte bcd image from a 160 column binary image.
Then I did a separate feed/select stacker once the card was successfully read.
Then the card record was written tape ... either 80byte bcd record or 160byte binary record.
tapes coming off the 709 could have a mixture of card output (both binary and bcd), but mostly printer (bcd) character output.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Blinkenlights? Newsgroups: alt.folklore.computers Date: Wed, 26 May 2004 07:18:27 -0600"Charlie Gibbs" writes:
this was before virtual memory had been announced for 370 ... but all the 370/145 rollers at customers had a roller which carried the legend "xlate" for one of the PSW bits.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: before execution does it require whole program 2 b loaded in memory Newsgroups: bit.listserv.ibm-main Date: Wed, 26 May 2004 07:43:09 -0600ibmlax@ibm-main.lst (Lax TS) writes:
there are several different aspects to the question.
to load a program requires sufficient available contiguous address space. back before os supported virtual memory ... that required congiguous real storage. with initial vs2/svs ... they used virtual memory with a single 16mbyte real machine ... with the kernel laid out in the first 8mbytes and the remaining 8mbytes of the (only) virtual address space supposedly available to all concurrent executing applications.
in the transition to vs2/mvs ... each program got its own 16mbyte virtual address space ... however the os convention has always been that the kernel and various other support services occupy the application's address space. that still required the kernel taking up 8mbytes of the 16mbyte address space available to the application. However, there were these other support services that still needed addressability. For this they defined a common area (in addition to the 8mbyte kernel) that occupied each address space that was needed by various support services. for many installations this could be 4mbytes ... leaving only 4mbytes in each 16mbyte address space for application. application might consists have lots of different independently loaded programs ... and there could be situation where an application totally filled the available 4mbyte area ... and additional programs couldn't be loaded.
this has gotten to be less of a problem with introduction of 31bit (and then 64bit) virtual address spaces (although there may still be application situations that have limitations to only running below the 24bit/16mbyte line ... in which case there could be still be congtiguous address space issues).
i've recently made a lot of lengthy postings in other n.g. on the
issue of program images on disk being directly loadable by the paging
system and/or program images being truely location independent. I had
done some filesystem extensions that supported page mapped capability
... collection of past postings on page mapped filesystem:
https://www.garlic.com/~lynn/submain.html#mmap
the original 360 architects did some fine work such that instructions (with base+displacement architecture) in program image were position/location independent. however, the original os/360 implementation took some short cuts and defined for address pointer convention something called relocatable adcons. In the program image out on disk, this storage locations all have values that are effectively displacements (and are position/location independent) ... but a requirement of mapping the program image to address space is a "loader" process that brings the program image into memory and then runs around converting all the relocatable adcon storage locations to absolute pointers (before program execution can begin).
this has a downside that the actual running program image isn't really
position independent and that there has to be this preloader process.
lots of past posts on the relocatable adcon problem with simple
page mapping program images in a page mapped filesystem:
https://www.garlic.com/~lynn/submain.html#adcon
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Leaf routines Newsgroups: comp.arch Date: Wed, 26 May 2004 14:00:00 -0600glen herrmannsfeldt writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Thu, 27 May 2004 08:05:34 -0600"Stephen Fuld" writes:
the first pass at mapping this particular operating system to a virtual memory hardware was to define a single virtual address space that was full 24bit/16mbytes (maximum) that ran on a machine with much smaller real memory. effectively much of the kernel and applications were operating as if they were on a real 16mbyte machine. virtual memory hardware was used to arbitrarily mapped virtual address space pages to real storage pages ... but that was transparent to both the application and quite a bit of the kernel. most of the kernel and the applications operated as if they were still in physical address machine, but the physical storage available was equal to maximum addressable storage (16mbytes).
the 2nd pass enhanced this implementation so that the virtual address spaces were replicated one per application. from the application standpoint it looked as if it was the only application running on a 16mbyte real machine with the first 8mbytes occupied by the kernel. shared segments were used so that same kernel image was mapped to the first 8mbytes of each address space. there were some transition problems tho. there were some amount of system subsystem functions that were sort of treated like unique applications but there was still the convention that "real" applications passed them pointers as part of service requests.
However, with subsystem applications in their own address spaces ... it was difficult to make use of a pointer that originated in a totally different address space. So they created a kludge glue interface, called the common area ... a portion of "application" space (above the 8mbyte kernel line) tha was common to all application address spaces. You could temporarily put some data in a common area, initialize a pointer to it ... and make a request to a service running in a different address space ... to preserving the pointer passing paradigm from the original (single) physical address implementation.
A problem with this implementation was that the common area kept getting bigger and bigger as you tried to multiplex a large number of different applications and subsystem services. It got to a point that the kernel occupied 8mbytes (of 16mbytes), the common area needed to be 4mbytes, and the maximum application space was now down to 4mbytes. were still stuck in a 24bit/16mbyte address space.
So the next generation machine introduced dual-address space ... special instruction that allowed a semi-privileged subsystem running in one virtual address space to reach across and access data in a different virtual address space (preserving the pointer passing paradigm). Also on this generation machine, they introduced physical storage larger than 16mbytes (& 24bit addressing).
The dual-address space was later generalized with access registers and program calls. basically hardware support for fastpath call through the kernel. The number of subsystem services operating in different address spaces continued to grow ... but they wanted to preserve the efficiency of the original direct BALR calling convention ... where application code could directly call library subroutines and other functions as if they were in the same address space ... using pointer passing convention. Arbitrary address space switching nominally was a kernel call function because of misc. privilege checking that has to occur along the way.
The enhancement was program table supported by hardware features and access registers ... along with a program call instruction. The program call instruction operated at nearly branch&link performance (w/o requiring a interrupt into the kernel) but attempted to instantiate the privilege checking rules for address space switching in tables & hardware. So you load up some number of different address space table pointers in control registers as well as table semantics for program call. You know can put all sorts of subsystem services and library routines in arbitrary address spaces and have them invokable by applications in other address spaces using pointer passing convention.
So this is a long winded pre-amble to saying that the definition of
what an address is has gotten a lot more complex than the original
definition that there was a one-to-one mapping between what the
application thought was an address, what the kernel thougght was an
address, and what the hardware thought was an address. There are
multiple kinds of addresses. The principles of operation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/CCONTENTS?SHELF=EZ2HW125&DN=SA22-7201-04&DT=19970613131822
now has a whole section talking about it, address types and
formats:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.2?SHELF=EZ2HW125&DT=19970613131822
that covers ten different addresses:
3.2.1.1 Absolute Address
3.2.1.2 Real Address
3.2.1.3 Virtual Address
3.2.1.4 Primary Virtual Address
3.2.1.5 Secondary Virtual Address
3.2.1.6 AR-Specified Virtual Address
3.2.1.7 Home Virtual Address
3.2.1.8 Logical Address
3.2.1.9 Instruction Address
3.2.1.10 Effective Address
... so my original issue wasn't so much about what does an address
mean ... but that I wanted the exact program image out on disk to not
have to change when it was loaded into memory for execution
(regardless of the reason or cause). I wanted to implement a
pagemapped file system where i could just map virtual memory to a
program image on disk and let the paging system (simply) do the
rest. The problem was that the relocatable adcons that were part of
program image out on disk had to be physical modified when the program
image was brought into storage before execution.
Physically changing the contents of the program image also had secondary effect of also changing the logical meaning of those storage contents ... but the first order problem was the requirement that the program image was being physically changed (at all) for execution (resulting in it being different than the program image on disk).
the second issue was that the storage contents representing the relocation adcons became specific to the virtual memory location of the executing program image. Independent of what the meaning might be for that storage location ... the physical changes had the secondary effect of binding that specific executable program image to a specific virtual address space location.
So the infrastructure goes to a great deal of trouble of allowing an application be able to load any program image at any (initially real, but now virtual) address location. However, in large real storage infrastructures and virtual memory, with multiple concurrent applications, there is some throughtput advantages of allowing different applications that want to make use of the same program to be able to share the same program image in real storage (saving having to create unique copies of the same program image for each address space). After going to all of the infrastructure and paradigm complexity to have relocatable adcons ... there is now a situation ... that the first application to load a program image will "fix" the location for that program image ... and if any other application were going to be able to share the same program image ... it can now only use it at the address fixed by the first application to load that program image.
So we get into some inter-application and inter-address space complexities. So two applications in private address spaces start loading program images in arbitrary and possibly different order ... but still want to have a significant common physical sharing of the program images. Either there has to be a common application convention pre-reserving specific addresses for every program image (for every possible program image across all possible applications and address spaces) ... or the applications have to use the same exact program loading sequence ... or some other convention ... so the address selected in each address space by each application for every program image somehow comes out to be the same.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [HTTP/1.0] Content-Type Header Newsgroups: comp.protocols.tcp-ip Date: Thu, 27 May 2004 08:16:59 -0600Barry Margolin writes:
so
https://www.garlic.com/~lynn/rfcietff.htm
and under RFC's listed by select Term (term->RFC#)
and scroll down to
Content Distribution Internetworking
3570 3568 3466
Content Negotiation
see also content-type
2738 2703 2534 2533
content-type
see also multipurpose internet mail extensions
3798 3730 3676 3625 3560 3534 3464 3462 3420 3391 3335 3274 3261
3236 3204 3156 3023 3003 2987 2958 2957 2938 2913 2912 2910 2876
2854 2738 2703 2646 2633 2586 2565 2543 2534 2533 2530 2518 2506
2442 2426 2425 2392 2388 2387 2376 2318 2301 2298 2231 2220 2184
2112 2111 2083 2077 2048 2046 2015 1896 1895 1894 1892 1874 1873
1872 1741 1590 1563 1523 1496 1437 1049
clicking on rfc number brings up the RFC summary in the lower frame.
clicking on the ".txt=nnnn" in the RFC summary retrieves the actual RFC.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Thu, 27 May 2004 08:58:11 -0600... addenda ...
in the earlier implementations (first physical/real ... and then single virtual address space) all concurrent applications and program images occupied the same address space (wether real or virtual). there was no issue that different applications could choose different addresses for the same program image, precluding being able to share the same program image. because there was a single address space, all application use and all program image locations were coordinated (in the same address space).
it was the move to giving different applications their unique address space that things got into trouble. the paradigm was still left over from the single address environment that different applications could arbritrarily load program images in any order and at any time ... and any sharing issues would automagically be taken care off.
however with applications running in their unique address spaces ... you sort of lost any inter-address apace coordination of address selected for program image loading. applications in one address space were willy-nilly loading program images at first available address ... just like they had in the single address space implementation; however there was no longer the implicit fall-out that the location chosen to load a program image by one application would necessarily always be the same address used by all applications (which was an implicit side-effect of running everything in a single address space).
so we go back to the early 70s. The cp67/cms environment had always given each application in the CMS environment its own address space. Somewhat because for a long time the total CP67 and CMS architecture, design, development, implementation, test and support organization numbered around 15 people ... and that there was a lot of similarity between the virtual memory 360/67 and the rest of the 360 line ... CMS heavily plagerized compliers, applications, programs, etc, written for os/360. CMS even included an OS/360 simulator. There was even a later joke ... that given OS/360 had a documented API ... that the 40kbyte CMS implementation of the OS/360 API didn't suffer all that badly in comparison to the 8mbyte MVS implementation of the OS/360 API (there were some parts of the OS/360 API that CMS wasn't quite able to do in 40kbyte implementation that MVS managed to accomplish in its 8mbyte implementation of the OS/360 API).
Now, I did both a pagemapped filesystem implementation for CMS and an infrastructure that allowed arbitrary specification of images to be shared across different CMS virtual address spaces (in principle, any object in the page mapped filesystem could be invoked as shared across multiple different virtual address spaces). So I ran into the problem thirty some years ago with relocatable adcon paradigm both
1) greatly complicating the page mapping of program image on disk to the executable program image in memory
2) greatly complicating coordinating sharing the same executable program image across multiple different address spaces
Somewhat side-track ... the official virtual memory operating system for 360/67 was TSS/360, which didn't survive. For several years of the early development period (mid-60s) the combined CP67/CMS group was 12 people and the TSS/360 group was soemthing like 1200 people. TSS/360 did implement support for program image on disk being the same as the executable program image in memory ... and that neither the program image on disk nor the executable program image was address location fixed.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Phone # layout vs Computer keypad # layout???!???!!! Newsgroups: alt.folklore.computers Date: Thu, 27 May 2004 14:51:57 -0600Roland Hutchinson writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Text Adventures (which computer was first?) Newsgroups: alt.folklore.computers Date: Thu, 27 May 2004 14:54:17 -0600stanb45@dial.pipex.com (Stan Barr) writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Thu, 27 May 2004 16:01:07 -0600"Stephen Fuld" writes:
sometimes in the past there have been comments about why didn't ibm have a virtual memory system like somebody or another ... and in a couple cases, i would point out that not only did ibm have such systems ... they might have had significantly more customer installations than whatever vendor was being cited. the problem was the combination of the number of all such systems was totally dwarfed by the shear magnitude of the number of ibm batch real-memory oriented systems.
it is hard to say that the real-memory batch orientation was turely bad ... since so many customers appeared to have successfully used it. while i may criticize them for not having done a perfect job of adapting from real storage to virtual storage ... it is hard to claim that it was truely bad ... from the standpoint that customers applications continued to run ... all of those machines that did things like payroll checks and airline reservations and random other things didn't stop. it would have been really bad if things stopped working and people didn't get their checks or some number of other bad things. the tortuous path of getting from mid-60s to now ... with the ability for some of the binaries from the period to be able to continue to execute nearly fifty years later ... wasn't perfect but it worked. some large part of the complexity is due to trying to maintain compatibility with the past.
the official mainstream was supposed to have gone 360, new generation of memory technology in real-memory 370s (relatively minor cosmetic differences from the real-memory 360s) and then FS or future systems.
As i've mentioned before, my take on FS at the time was it had similarities to the film playing down at central sq and the inmates being in charge of the asylum ... every thing that anybody had ever thot of was thrown in ... with total lack of any practicallity. One of the things that helped get FS killed was a study that calculated that if the absolute highest performance technology of the day was used to build an FS machine ... the FS technology would cause something at least a 10:1 performance degradation; an FS machine made out of 370/195 technology would run applications at 370/145 thruput.
I've claimed several times that one of the things that was prime motivation for RISC in the 70s was the strong reaction to the FS debacle ... and swinging the pendelum from the absolutely most complex CISC, one-level store, hardware, to the opposite extreme ... as KISS-simple as possible.
One could claim that the whole os/360 stumbling into virtual memory wasn't exactly anticipated ... because officially there was going to have been a complete replacement with FS (much more radical change than the change made by the 360 introduction). The canceling of FS left a lot of the company scrambling (or for some, transferring to rochester).
not every idea in FS was totally impractical .. however many were, while others were just totally impractical for the time ... ... but there didn't seem to be any judgement about what was actually do'able and what wasn't.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Thu, 27 May 2004 16:25:16 -0600"Stephen Fuld" writes:
at the moment there isn't much of a requirement to allow a specific execution context to be able to have shifting, changing address locations (outside of the virtual memory scenario) ... which would require changing not only the program image paradigm but also the register addressing conventions. while the technique i describe is necessary to allow the same exact program image to occupy several different places concurrently ... i.e. the image on disk is exactly the same as the image in an address space and the image in any specific address space is exactly the same as the image in all address spaces.
the technique i describe would also be used if you were to allow randomly shifting address locations for specific execution context ... and while it could be necessary for support having a specific execution context randomly change ... it wouldn't be sufficient ... since a specific execution context is also made up of other items which would also have to be adapted to allowing randomly changing address location.
now, address translation hardware is one technique for allowing a specific execution context to have randomly changing physical location ... by imposing a hardware layer between the logical address generated by instruction and a physical effective address.
however, the address translation is necessary for allowing a specific execution context to have randomly changing real address locations ... but it isn't sufficient for allowing the same exact (not changed) program image on disk to be used for execution in an address space (at least not with the relocatable adcon paradigm). The address translation hardware is also not sufficient to allow the same exact program image from disk to be arbitrarily loaded by multiple different applications running concurrently in multiple different address spaces. One possible work around would be to pre-establish a unique fixed address location for all possible program images that all applications can agree to before hand. Then whenever an application is loading a specific program image into their address space ... they won't preclude the same exact program image from being used concurrently by some other address space.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Thu, 27 May 2004 16:50:15 -0600addenda to techniques
... another way of describing it is that address translation hardware allows a specific execution context to occupy randomly changing physical memory locations.
... the relocatable adcon scenario allowd multiple different applications to share a common program image when there was a single address space ... either a single real address space from real-memory os/360 days or from single virtual memory address space from os/vs2 svs (single virtual storage ... as opposed to the later mvs ... multiple virtual storage).
the relocable adcon scenario didn't allow that the program image on disk be the same as the executable program image ... but that didn't matter as much for a non-pagemapped filesystem ... you had to do fiddling to get the program image into the address space (real or virtual) in any case.
the scenario that comes up with relocatble adcons is
1) having the same exact program image on disk that executes in an address space (makes pagemapped filesystem program loading somewhat simpler/KISS)
2) and having the same exact program image loaded into arbitrarily different virtual address spaces (in the os/360 genre introduced with os/vs2 mvs).
real-memory os/360 and svs allowed that a (reentrant) program image could be loaded into memory (real or virtual) and the same exact program image could be simultaneously used concurrently by multiple different applications.
going to multiple different virtual address spaces ... either in the mvs scenario or the cms scenario that has existed from the start ... the ability to share the same exact program image (aka have a single physical copy in real storage) becomes problamatic unless the program image has no position dependencies ... or some convention has been pre-established assigning a unique position to every possible program image.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Infiniband - practicalities for small clusters Newsgroups: comp.arch Date: Thu, 27 May 2004 17:30:22 -0600"Stephen Fuld" writes:
to get the same program images to exist concurrently in multiple address spaces ... they are loaded them into the "linkpack" area. The linkpack area originated in the real-memory os/360s days as sort of a cross between dynamically loadable kernel extensions and static program image caching. In mvs, in the same way that the kernel image occupies every address space ... linkpack is present in every address space. since there is a common kernel interface that serializes the loading of program images into linkpack ... every linkpack loaded program image is assigned a unique address and also is allowed to occupy every address space (as opposed to just those address spaces that were specifically interested in loading that program image).
if you are interested the thread you are looking for appeared to start
out as a troll or a homework question ... but has generated quite a
bit of posting ... if you use google search you would be looking for
the
"before execution does it require whole program 2 b loaded in"
thread.
The answer might be implied if the loader has to run thru arbitrary and random locations in the program image swizzling all relocatable adcons before allowing program execution to start.
part of most recent thread just took a slight detour discussing whether all possible relocatable adcons were full-word aligned and therefor couldn't cross a page-boundary ... possibly affecting what a loader might or might not have to do with respect to processing relocatable adcons before starting program execution.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: before execution does it require whole program 2 b loaded in Newsgroups: bit.listserv.ibm-main Date: Thu, 27 May 2004 16:59:57 -0600Chris_Craddock@ibm-main.lst (Craddock, Chris) writes:
svc 202
dc al4(address)
instructions
or
svc 202
instructions
if there was an error, the return would check for a byte of zeros
following the svc and assume it was an address and branch to the
address location. if there wasn't a zero, it would assume there was no
error handling and go off to a default system provided one.
if there was no error, it would check for a zero following the svc, and if it found one it would return to the svc interrupt address plus four (i.e. skipping the presumed adcon). if the byte following the svc wasn't zero, it would just return to the address of the svc interrupt.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: before execution does it require whole program 2 b loaded in Newsgroups: bit.listserv.ibm-main Date: Thu, 27 May 2004 17:04:34 -0600etech@ibm-main.lst (Eric Chevalier) writes:
in any case, cms has been using the dc-al4() convention following a two byte svc instruction for just short of 40 years ... and probably half of them are half-word aligned ... and some percentage happen to cross page boundaries.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: before execution does it require whole program 2 b loaded in Newsgroups: bit.listserv.ibm-main Date: Thu, 27 May 2004 17:09:17 -0600john_w_gilmore@ibm-main.lst (john gilmore) writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/