2001 Newsgroup postings (07/22 - 08/17) Lynn Wheeler

2001 Newsgroup Postings (07/22 - 08/17)

PKI/Digital signature doesn't work
Alpha: an invitation to communicate
Alpha: an invitation to communicate
PKI/Digital signature doesn't work
PKI/Digital signature doesn't work
PKI/Digital signature doesn't work
PKI/Digital signature doesn't work
PKI/Digital signature doesn't work
VM: checking some myths.
VM: checking some myths.
VM: checking some myths.
checking some myths.
checking some myths.
VM: checking some myths.
Installing Fortran
IBM 9020 FAA/ATC Systems from 1960's
D
IBM 9020 FAA/ATC Systems from 1960's
checking some myths.
checking some myths.
physical vs. virtual addresses
checking some myths.
Intel's new GBE card?
Redhat 7.2?
"Hollerith" card code to EBCDIC conversion
earthlink timing out nntp connections
TECO Critique
TECO Critique
checking some myths.
checking some myths.
earthlink timing out nntp connections
earthlink timing out nntp connections
Wanted: pictures of green-screen text
D
D
D
PKI/Digital signature doesn't work
Credit Card # encryption
Credit Card # encryption
Credit Card # encryption
Credit Card # encryption
Credit Card # encryption
Credit Card # encryption
Credit Card # encryption
Wired News :The Grid: The Next-Gen Internet?
Article: Future Trends in Information Security
Whom Do Programmers Admire Now???
ummmmm
Whom Do Programmers Admire Now???
Other oddball IBM System 360's ?
Flip the bits in a byte
future of e-commerce
Flip the bits in a byte
Net banking, is it safe???
YKYGOW...
YKYGOW...
Blinkenlights
Whom Do Programmers Admire Now???
Net banking, is it safe???
Blinkenlights
Whom Do Programmers Admire Now???
Net banking, is it safe???
Net banking, is it safe???
Blinkenlights
Net banking, is it safe???
UUCP email
UUCP email
Would this type of credit card help online shopper to feel more secure?
Net banking, is it safe???
Very CISC Instuctions (Was: why the machine word size ...)
Net banking, is it safe???
IBM 9020 FAA/ATC Systems from 1960's
ummmmm
Most complex instructions
YKYGOW...
Net banking, is it safe???
Other oddball IBM System 360's ?

PKI/Digital signature doesn't work

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Sun, 22 Jul 2001 13:30:29 GMT

"Harris Georgiou" writes:
Not really. The whole idea behind the digital certificate is possesion of some piece of information unique to that person. Any digital certificate contains a key pair (complete/owner form) or just the public part of it in order to be used for verification by others. We often use the term certificate only for the public part because that is what everybody else uses to identify that person, but the complete for of it (available only to the owner) is the whole key pair. relying-party-only certificates are not mandatory to ensure the validity of a certificate. PGP keyservers keep all keys in public access and everybody can grant or revoke his/hers expression of trust towards any key by signing with the personal key. It is a distributed service, thus more reliable than any centralized certificate management.

as an aside, we had coined the term certificate manufacturing to try and distinguish between many of the current environments and some of the theoritical proposals involved in many PKI definitions (it has since been picked up and used in some number of other references).

we had been involved in helping create something called "electronic commerce" and had to do some amount of due diligence on some of the entitites doing certificate manufacturing.

the talk I was at where somebody from the german banking community gave a description & reasons for relying-party-only certificates was at the following conference

https://csrc.nist.gov/publications/detail/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998

at the conference, I was on a PKI panel that included CTOs & the ilk from several certificate manufacturing companies ... misc. ref:

https://www.garlic.com/~lynn/2001g.html#0

random refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aepay7.htm#nonrep6
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/aadsm6.htm#echeck

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Alpha: an invitation to communicate

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Alpha:  an invitation to communicate
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch
Date: Sun, 22 Jul 2001 16:54:25 GMT

Peter Hancock writes:
I though VM was the underlying thing, and MVS was one of the things VM could host?

ISTM that its not at all improbable that sometime soon we will need or have some kind of virtual machine technology that could allow all kinds of bizarre software monstrosities to run in whatever kind of crazy environment they want. Is this a platitude?

it is possible that a lot more familiar with the resource management and industrial strength features of MVS ... than are familiar with the resource management and industrial strength features of VM.

disk engineering posts
https://www.garlic.com/~lynn/subtopic.html#disk
page replacement algorithm posts
https://www.garlic.com/~lynn/subtopic.html#wsclock
dynamic adaptive resource management posts
https://www.garlic.com/~lynn/subtopic.html#fairshare
multiprocessor, tightly-coupled, smp and/or compare-and-swap posts
https://www.garlic.com/~lynn/subtopic.html#smp
High Availability Cluster Multi-Processing poss
https://www.garlic.com/~lynn/subtopic.html#hacmp 360 (and/or 370) microcode posts
https://www.garlic.com/~lynn/submain.html#360mcode

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Alpha: an invitation to communicate

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Alpha:  an invitation to communicate
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch
Date: Mon, 23 Jul 2001 21:05:45 GMT

JF Mezei writes:
This was the "old way". But MVS-only shops can run multiple instances of MVS on a 390 or higher without the presence of VM. This saves a lot of overhead since IO is not intercepted by VM.

I did hear that VMS was making a comeback to run multiple instances of Linux on IBM mainframes though.

i think that if you look closely ... LPARS are essentially a whole lot of VM moved into the "microcode" of the hardware with various options/features simplified. it basically started out as hardware accelerater for VM kernel (by incorporting significant performance parts of vm kernel into the microcode of the hardware) ... and at some point enuf of the VM kernel functions had been migrated to the hardware of the machine that it was possible to provide a subset of the VM kernel functions w/o even running the full-blown vm kernel.

if you look at the LPAR documentation with regard to performance planning, there is still some amount of "vm" overhead still involved (it just that it is somewhat less because it is being done in the hardware w/o ..at least.. the overhead of a context switch into a different address space & software processing).

a subset of the VM commands is still seen on the console for doing LPAR configurations. Also, the hardware console/service processor may or may not still be a VM system (aka all 3090s contained two "embedded" 4361s running a modified version of vm/370 release 6 that were the service processor and hardware console interface).

random refs:
https://www.garlic.com/~lynn/submain.html#360mcode

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

PKI/Digital signature doesn't work

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Mon, 23 Jul 2001 00:48:54 GMT

"Harris Georgiou" writes:
I understand your point. The idea behind relying-only-party certificates is in fact the combination of issuing the certificate, managment and real-time update (status query), all by the same provider. It is surely a more advanced and effective version of the typical PKI provider and it solves many problems and ambiguities. It's just that in lack of general purpose PKI services (except custom-made, say, for a banking application), the only available scheme is the keyserver model implemented for PGP-like applications.

furthermore, relying-party-only certificates are redundant and superfluous.

actually certificates are redundant and superfluous in an online model, where the "certification" check can be done via an online query; it is just that it is quite a bit more obvious when the relying party and the registration party are the same ... to be able to see that the certificate is extraneous in the whole operation.

certificates were designed to serve a purpose in the offline world, where it wasn't possible to directly contact the registration & certification authority ... and so had to relying on a distributed credential in place of an online query.

The r/o distributed credential (aka certificate) is otherwise redundant, superfluous and extraneous if you can directly do an online query.

An example is the current SSL server domain name certificates and being able to achieve the same purpose in a much better way by having the online domain name infrastructure provide real-time public key distribution and certification .. aka instead of registering your domain name and public key with a certification authority ... collapse the whole thing into the domain name infrastructure and register a public key at the same time the domain name is registered. the domain name infrastructure than can provide real-time certification and distribution of public key ... instead of the current mechanism relying on stale manufactured certificates.

misc. ref:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Mon, 23 Jul 2001 20:46:41 GMT

those who know me have no need of my name <not-a-real-address@usa.net> writes:
for this to become a reality dnssec needs to be widely deployed, and the server must be able to require that only secure delegations are followed. i would not hold be breath.

but the "integrity chain" for SSL domain name certificates are currently at risk w/o it; aka an entity requests a SSL domain name certificate from a certification authority; the certification authority has to certify that validity of the owner of that domain name with the authoritative agency for domain names ... which is the domain name infrastructure.

the interesting aspect is supposedly the justification for SSL domain name certificates in the first place are integrity weaknesses in the domain name infrastructure. so at least the Certification Authority business of SSL domain name certificates have to improve the integrity of the domain name infrastructure for their own purposes (in order that they can rely on what it is that they are certifying ... so people can rely on their certificates). however, if they improve the integrity of the domain name infrastructure to meet minimum integrity requirements for their own business; they also eliminate much of the justification for SSL domain name certificates in the first place.

misc. ref:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

PKI/Digital signature doesn't work

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Wed, 25 Jul 2001 12:17:36 GMT

"Harris Georgiou" writes:
Current e-shopping security is based on the integrity of each node from which that sensitive data go through. Encryption may be used during transmissions but credit card numbers are usually stored in an unecrypted form. This is the real reason for the 2.000.000+ bogus transactions every year with stolen numbers. Maybe this could be drastically limited if there was some way the company could verify your side, you could verify theirs, and none in the middle could keep a copy of the account or transaction. There are many things that can be improved in current e-shopping policies.

the current CC implementation was done because it was relatively straight-forward, much of the infrastructure was already in place, and there was already support for business practices associated with non-face-to-face (aka MOTO or mail-order/telephone-order) transactions).

random refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

work then began in financial standards body for authentication transactions in untrusted &/or insecure networks (aka debit & atm cards already had PIN authenticated transactions that operated in secure networks).

the result of that in the financial standards world was the X9.59 standard for all electronic account-based transactions (along with some enhancements to ISO 8583 to carry X9.59 digital signature in the payment card scenerio). Part of the X9.59 standards was that "x9.59" related account numbers could only be used in authenticated transactions (i.e. the harvesting of account numbers from x9.59 transactions could not later be used in fraudulent, unauthenticated transactions; essentially removing such account numbers from the status of shared-secret and points of exploit).

There already have been debit network pilots ... and work is underway for production roll-outs.

misc. refs:
https://www.garlic.com/~lynn/nacharfi.htm
https://www.garlic.com/~lynn/99.html#224
https://www.garlic.com/~lynn/aadsmore.htm#nacha

mapping of x9.59 standard to iso 8583 payment network standard
https://www.garlic.com/~lynn/8583flow.htm

misc. other x9.59 references
https://www.garlic.com/~lynn/x959.html#x959

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Wed, 25 Jul 2001 12:42:29 GMT

"Harris Georgiou" writes:
Most of them currently use simple SSL as an alternative. But ALL of them provide the client-side software with a digital certificate that verifies that the transaction actually involves the real bank and not some eavesdropper (see SSL specification for complete description).

the digital certificates in SSL domain name server certificates are supposedly justified on weaknesses in the domain name infrastructure.

so somebody goes to a certification authority (CA) to get a SSL domain name server certificate. Since the Certification Authority has no trusted database of who owns which domain name, the Certification Authority goes to the authoritative agency for domain name ownership (aka the domain name infrastructure) to verify that the entity really owns the domain name. The CA then certifies (in a digital certificate) that it has checked with the domain name infrastructure as to the true owner of the domain name before issueing the SSL domain name server certificate.

The client SSL code, when it receives a SSL domain name server certificate, checks the domain name specified in the SSL domain name server certificate against the URL that the client had used to contact the server; if they "match" ... SSL proceeds (there are misc. other things like checking to see that the CA signing the certificate is in the built-in list of CAs).

The problem, of course, is that Certification Authorities have to rely on the very same (insecure) domain name infrastructure as the final authority/arbritrator for information that they certified ... this same domain name infrastructure that the clients rely on for doing domain name -> ip address resolution.

random ref:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

PKI/Digital signature doesn't work

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Wed, 25 Jul 2001 12:54:29 GMT

"Lyalc" writes:
Let's just think about passwords as an elelctronic signature mechanism The only people who need to verify this initially at the oroginator, and the recipient, both of whom are part of the existing relationship, and the only entities who can verify the password in the first place.

Thus there is no compromise.

Later, if there is a need to re-verify, the relying party's records from archives and backups (person x had this password at this time which is affixed in encrypted form to that document) should suffice in court.

This is true of the encryption process used to bind the password to the document. Lyal

the problem is (at least) protecting the password/shared-secret files at the recipient. there are frequent news reports about shared-secret leakage as well as major shared-secret harvesting events at recipient sites.

shared-secret has the same value originating and validating the "electronic signature". leakage of shared-secrets (especially by recipients) allows fradulant originated tranactions. easly seen in all the reports about CC account# leakage & harvesting (since for all intents and purposes in the current infrastructure ... the CC account numbers are shared-secrets and can be used to origiante fradulent transactions).

public/private key authentication technology upgrade to existing shared-secret business processes is a relatively inexpensive upgrade to eliminate major exploits.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

VM: checking some myths.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch
Date: Wed, 25 Jul 2001 22:16:45 GMT

There was a standard instant message between the terminals belonging to two different virtual machines.q

On the same machine, the straight forward messages allowed instant person-to-person communication/message. SMSG supported programmatically interception of instant messages allowed various automated infrastructure, automated operator, tape mounting services, etc.

The support by VNET of SMSG allowed the "instant messaging" to be expanded to the network environment (i.e. VNET had an immediate message communication, separate from normal file & data ... which would support this extending instant messaging to a multiple machine, network environment).

instant messaging between two real people in two virtual machines instant messaging between one real person and a program in two virtual machines instant messaging between two programs in two virtual machines

instant messaging between one real person and VNET in two virtual machines ... with VNET acting as transport to different real machine ... where it is a real person at the other end

instant messaging between one real person and VNET in two virtual machines ... with VNET acting as transport to different real machine ... where it is a program at the other end

instant messaging between one program and VNET in two virtual machines ... with VNET acting as transport to different real machine ... where it is a program at the other end

and of course, VNET could be used between two parties on the same machine.

The summer of 1980, the author of REXX did a multi-palyer, distributed spacewar implementation using the SMSG mechanism; on the same machine, spacewar distributed messages directly ... and this could operate in a multi (real) machine environment using VNET's support of instant messaging.

Now the case was the spacewar game running in one virtual machine, was it actually interacting with a real person ... or was it a program simulating a real person.

random refs:
https://www.garlic.com/~lynn/2001f.html#10
https://www.garlic.com/~lynn/2001f.html#12
https://www.garlic.com/~lynn/2001f.html#14

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

VM: checking some myths.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch
Date: Wed, 25 Jul 2001 23:45:48 GMT

Aaron Sawyer writes:
Sounds like Cambridge University's CP/CMS (Control Program/Cambridge Monitor System) on the S360/67 (65 with DAT box, IIRC). Certainly had the Virtual Machine implemented. Very nice.

[remainder snipped; nothing to add]

It was the IBM Cambridge Scientific Center located at 545 Tech. Sq., Cambridge Mass (same bldg. as Multics) and had some number of people that worked on CTSS. Started with CP & CMS on 360/m40 that had custom modified hardware to support virtual memory in '65/'66 era ... and then was ported to 360/m67 when it became available.

misc. online history from Melinda Varian
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist

CSC had 30 or so people. It originated CP/40, CP/67, CMS, VNET, GML, compare&swap, various performance tuning, early capacity planning and misc. other things. compare&swap turns out to be the initials of the primary person at CSC responsible. GML (which spawned the whole genre of markup languages, SGML, HTML, XML, etc) is the letter of the lastnames of three people involved (i.e. generalized markup language was chosen to match their initials).

The internal "VNET" network was consistently larger than the arpa/internet until about 1985. I claim one of the reasons is that VNET essentially contained a "gateway" function allowing the interconnection of networks ... the "internet" didn't really get that capability until Jan. 1st, 1983. random refs:

https://www.garlic.com/~lynn/internet.htm

I was at a university on the west coast and some people came out and installed CP/67 in January of 1968 (third CP/67 installation after CSC and Lincoln Labs).

misc. following have some refs:
https://www.garlic.com/~lynn/submain.html#360pcm
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/submain.html#360mcode
https://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

VM: checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Thu, 26 Jul 2001 07:31:37 GMT

"mulp" writes:
IBM implemented virtula machines (VM's) before the above was implemented - the upgrade strategy that IBM used to move customers to the 360 was to provide VM's for each of the machines that IBM wanted to replace - eg., those 1401 somethings or another. And there were probably other VM's as well before the 360 from IBM and other vendors.

IBM provided hardware emulation of earlier hardware on various processors ... i.e. 360s were almost all microcoded machines ... where "microcode" on the microprocessor emulated 360. The machines were also shipped with "microcode" to simulate other machines. The following is out of a recent "golden era of compilers" thread in alt.folklore.computers:


>40    1410 (I don't remember that it also did 1401)
1410 or 1401 - 2 different products
>50    1410, maybe 7040
           1410 or 7070 (2 distinct products, you couldn't get both!)
>65    709x
           and IIRC also 705/7080



7070 includes 7074, and 1410 includes 7010.

aka 360/m40 had microcode emulation to emulate earlier machines. note also that 360/m30 included microcode emulation for 1401. Typically, there was a switch on the front panel someplace that switched between 360 hardware (emulation) and some other hardware emulation.

I don't know anybody claiming such implementations were virtual machines.

note reference in [26} below in extract from melinda's paper at PUCC
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist
C. CP-40 and CMS

In the Fall of 1964, the folks in Cambridge suddenly found themselves in the position of having to cast about for something to do next. A few months earlier, before Project MAC was lost to GE, they had been expecting to be in the center of IBM's time-sharing activities. Now, inside IBM, ''time-sharing'' meant TSS, and that was being developed in New York State. However, Rasmussen was very dubious about the prospects for TSS and knew that IBM must have a credible time-sharing system for the S/360. He decided to go ahead with his plan to build a time-sharing system, with Bob Creasy leading what became known as the CP-40 Project.

The official objectives of the CP-40 Project were the following:

1. The development of means for obtaining data on the operational characteristics of both systems and application programs;

2. The analysis of this data with a view toward more efficient machine structures and programming techniques, particularly for use in interactive systems;

3. The provision of a multiple-console computer system for the Center's computing requirements; and

4. The investigation of the use of associative memories in the control of multi-user systems.[22]

The project's real purpose was to build a time-sharing system, but the other objectives were genuine, too, and they were always emphasized in order to disguise the project's ''counter-strategic'' aspects. Rasmussen consistently portrayed CP-40 as a research project to ''help the troops in Poughkeepsie'' by studying the behavior of programs and systems in a virtual memory environment. In fact, for some members of the CP-40 team, this was the most interesting part of the project, because they were concerned about the unknowns in the path IBM was taking. TSS was to be a virtual memory system, but not much was really known about virtual memory systems. Les Comeau has written: Since the early time-sharing experiments used base and limit registers for relocation, they had to roll in and roll out entire programs when switching users....Virtual memory, with its paging technique, was expected to reduce significantly the time spent waiting for an exchange of user programs.

------------------------------------------------------------

31 or 32 bits. We eventually voted and recommended 31 bits. We also discussed the design of the relocation register and had some heated discussions with the IBM team. The Inner Six met with IBM representatives behind closed doors at a SHARE meeting. We six sites discussed various features of TSS and made recommendations to IBM. This was the beginning of the SHARE TSS Project.'' (J.M. Winett, private communication, 1990.)

22 R.J. Adair, R.U. Bayles, L.W. Comeau, and R.J. Creasy, A Virtual Machine System for the 360/40, IBM Cambridge Scientific Center Report 320-2007, Cambridge, Mass., May, 1966.

------------------------------------------------------------

What was most significant was that the commitment to virtual memory was backed with no successful experience. A system of that period that had implemented virtual memory was the Ferranti Atlas computer, and that was known not to be working well. What was frightening is that nobody who was setting this virtual memory direction at IBM knew why Atlas didn't work.[23] Creasy and Comeau spent the last week of 1964[24] joyfully brainstorming the design of CP-40, a new kind of operating system, a system that would provide not only virtual memory, but also virtual machines.[25] They had seen that the cleanest way to protect users from one another (and to preserve compatibility as the new System/360 design evolved) was to use the System/360 Principles of Operations manual to describe the user's interface to the Control Program. Each user would have a complete System/360 virtual machine (which at first was called a ''pseudo-machine'').[26] The idea of a virtual machine system had been bruited about a bit before then, but it had never really been implemented. The idea of a virtual S/360 was new, but what was really important about their concept was that nobody until then had seen how elegantly a virtual machine system could be built, with really very minor hardware changes and not much software.

------------------------------------------------------------

23 L.W. Comeau, ''CP-40, the Origin of VM/370'', Proceedings of SEAS AM82, September, 1982, p. 40.

24 Creasy had decided to build CP-40 while riding on the MTA. ''I launched the effort between Xmas 1964 and year's end, after making the decision while on an MTA bus from Arlington to Cambridge. It was a Tuesday, I believe.'' (R.J. Creasy, private communication, 1989.)

25 R.J. Creasy, General Description of the Research Time-Sharing System with Special Emphasis on the Control Program, IBM Cambridge SR&D Center Research Time-Sharing Computer Memorandum 1, Cambridge, Mass., January 29, 1965. L.W. Comeau, The Philosophy and Logical Structure of the Control Program, IBM Cambridge SR&D Center Research Time-Sharing Computer Memorandum 2, Cambridge, Mass., April 15, 1965.

26 For the first few weeks, the CSC people referred to their concept as a ''pseudo-machine'', but soon adopted the term ''virtual machine'' after hearing Dave Sayre at IBM Research use it to describe a system he had built for a modified 7044. Sayre's M44 system was similar to CP-40, except for the crucial difference of not providing a control program interface that exactly duplicated a real machine. The CP-40 team credited Sayre with having ''implanted the idea that the virtual machine concept is not necessarily less efficient than more conventional approaches.'' (L. Talkington, ''A Good Idea and Still Growing'', White Plains Development Center Newsletter, vol. 2, no. 3, March, 1969.) ''The system built by Dave Sayre and Bob Nelson was about as much of a virtual machine system as CTSS---which is to say that it was close enough to a virtual machine system to show that 'close enough' did not count. I never heard a more eloquent argument for virtual machines than from Dave Sayre.'' (R.J. Creasy, private communication, 1990.)

27 ''Dick Bayles was not only a great programmer, he was also the fastest typist I have ever seen.'' (W.J. Doherty, private communication, 1990.) ''When Dick Bayles sat down [at a keypunch], he wrote code as fast as it could punch cards. Yes, the machine was slower than Bayles composing code on the fly.'' (R.J. Creasy, private communication, 1989.)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

checking some myths.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Thu, 26 Jul 2001 07:51:29 GMT

"Stephen Fuld" writes:
Since there have been lots of answers to number 1 and to you last paragraph, but none to number 2, I'll take a shot at it. I am far from an expert here, but AFAIK you nailed one of the reasons but there are others.

Some people run VM so thy can run lots of CMS users as it is a very efficient way to support lots of interactive users in, for example, a university environment.

Some people run VM so they can take advantage of modern hardware to run many copies of older more limited operating systems such as DOS/VSE which don't support as much memory, or as many users as more modern hardware does. This is exactly the mechanism that people will use to run even hundreds of copies of Linux on a S/390 (or its new name) system.

Many independent software vendors run it to allow them to support several versions of several different operating systems in order to assure compatibility pre ship and for bug reproduction.

one of the things that happened in VM was that since you could operate the environment "with" and "with/out" the kernel, there was increased emphasis on kernel efficiency and performance i.e. standard operating systems tend to claim that the kernel pathlength is what it is, and maybe we can tweak it a little ... but there was significant more pressure on the VM kernel to keep in lean and mean.

The other characteristic was that it was much more of a microkernel with clean division represented by the virtual machine "line". As a result, it was frequently much easier taks to follow a complete control flow from end-to-end and optimize it (because of the simplicity, something that is frequently much more difficult in kernels that have less clearly defined separation of function).

While it was obvious that a straight forward deployment of another operating system in a VM virtual machine ... resulted in delta performance decrease because of the additional VM kernel pathlength, there was numerous instances where the configuration operations of another virtual machine could be selected in such away that it traded off internal management/function for relying on the VM kernel to provide that management/function. Sometimes the performance improvement was so significant, that not only did it offset other VM kernel introduced overhead ... but actually saw significant performance thruput over running the operating system w/o VM.

The other characteristic was that the CMS interactive environment (which made significant leverage of such trade-offs) would show significantly better interactive performance compared to other IBM "interactive" offerings.

one of these were the famous CERN MVS/TSO VM/CMS benchmark
https://www.garlic.com/~lynn/98.html#28
https://www.garlic.com/~lynn/2000f.html#61
https://www.garlic.com/~lynn/2001f.html#49

I was fortunate enuf to participate in some of the activity
https://www.garlic.com/~lynn/2001e.html#45
https://www.garlic.com/~lynn/2001f.html#62
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/subtopic.html#fairshare

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

checking some myths.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Thu, 26 Jul 2001 08:05:36 GMT

Anne & Lynn Wheeler writes:
one of the things that happened in VM was that since you could operate the environment "with" and "with/out" the kernel, there was increased emphasis on kernel efficiency and performance i.e. standard operating systems tend to claim that the kernel pathlength is what it is, and maybe we can tweak it a little ... but there was significant more pressure on the VM kernel to keep in lean and mean.

simple example is between the time that CP/67 was installed at the university in jan, 1968 where I was an undergraduate and the time I made presentation at the fall '68 SHARE meeting in Atlantic City, I had reduced many CP/67 pathlengths by a factor of ten to one hundred times. the following is from that '68 share presentation.

The original CP/67 kernel CPU consumption to execute the referenced OS MFT14 virtual machine was 856-322 or 534 cpu seconds. By August, I had rewritten several portions of the kernel and reduced the total CP/67 kernel CPU consumption to 435-322 or 113 cpu seconds for an overall reduction of a factor of five times (I had also replaced the page replacement algorithm with a clock-like algorithm, implemented original fair share scheduling, and done misc. other improvements).


OS Performance Studies With CP/67

OS              MFT 14, OS nucleus with 100 entry trace table, 105 record
                in-core job queue, default IBM in-core modules, nucleus total
size 82k, job scheduler 100k.

HASP            118k Hasp with 1/3 2314 track buffering

Job Stream      25 FORTG compiles

Bare machine    Time to run: 322 sec. (12.9 sec/job)
times        Time to run just JCL for above: 292 sec. (11.7 sec/job)

Orig. CP/67     Time to run: 856 sec. (34.2 sec/job)
times        Time to run just JCL for above: 787 sec. (31.5 sec/job)

Ratio   CP/67 to bare machine

2.65    Run FORTG compiles
                2.7     to run just JCL
2.2     Total time less JCL time

1 user, OS on with all of core available less CP/67 program.

Note:   No jobs run with the original CP/67 had ratio times higher than
        the job scheduler. For example, the same 25 jobs were run under WATFOR,
where they were compiled and executed. Bare machine time was 20 secs.,
        CP/67 time was 44 sec. or a ratio of 2.2. Subtracting 11.7 sec. for
bare machine time and 31.5 for CP/67 time, a ratio for WATFOR less
job scheduler time was 1.5.

        I hand built the OS MFT system with careful ordering of
cards in the stage-two sysgen to optimize placement of data sets,
        and members in SYS1.LINKLIB and SYS1.SVCLIB.

MODIFIED CP/67

OS run with one other user. The other user was not active, was just
available to control amount of core used by OS. The following table
gives core available to OS, execution time and execution time ratio
for the 25 FORTG compiles.

CORE (pages)    OS with Hasp            OS w/o HASP

104             1.35 (435 sec)
 94             1.37 (445 sec)
74             1.38 (450 sec)          1.49 (480 sec)
64             1.89 (610 sec)          1.49 (480 sec)
54             2.32 (750 sec)          1.81 (585 sec)
 44             4.53 (1450 sec)         1.96 (630 sec)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

VM: checking some myths.

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Thu, 26 Jul 2001 08:39:26 GMT

hack@watson.ibm.com (hack) writes:
Historically, the coupling between virtual card punches and readers (across the RSCS company-wide network, aka VNET) was the primary communication interface (nearly 30 years old). It may sound quaint, but it's really just a data pipe (with 80-byte blocks) with tagged ends to perform the connection, and it has a really simple interface (no connection protocols etc. -- the network is store-and-forward, so it's literally like mailing postcards where bunches (individual "spool files") are guaranteed to arrive in order (there is no virtual equivalent to a deck of cards spilled on the floor).

one of the problems with the "spool file" interface was that it was synchronous on open, close and on 4k buffer boundaries doing various disk I/O (whether it was using straight UR simulation or 4k block transfers). in the mid-80s, a VNET virtual machine supporting even a few full-duplex 56kbit links could spend 90% of elapsed time in "blocked" state waiting on synchronous (disk) spool file operations.

one of the things that we did in HSDT was implement several asynchronous functions for VNET so we could start seeing it drive multiple full-duplex T1 links at media thruput.

In HSDT, we also got the mainframe TCP/IP thruput up from 44kbybtes/sec to hardware channel speed.

random refs:
https://www.garlic.com/~lynn/subnetwork.html#hsdt
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
https://www.garlic.com/~lynn/internet.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Installing Fortran

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Installing Fortran
Newsgroups: alt.folklore.computers
Date: Sun, 29 Jul 2001 12:35:47 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
Yupper. Once your program started executing, all addresses were fixed in genuine core storage. If that program was obstructing the execution of the higher priority task of bean counting, the exact core image could be written to disk at a suitable breakpoint, then restarted. Service bureaus didn't like this feature - played havoc with tapes, printers, card readers and disk files (including the system catalog). Along came VM or MVS to simplify life in the job scheduling lane. Aren't we all glad that M$ came along?

Boeing Huntsville .... took a version of OS/360 MVT Release 13 and added virtual memory support running on two-processor SMP 360/67. Their application was multiple large interactive graphic programs using 2250s. This system didn't support paging. The problem was that MVT programming model required contiguous storage allocation for programs all sharing the same (real) address space. An environment with multiple long running programs had severe storage fragmentation problems. The virtual memory support allowed for overcoming the storage fragmentation problems. This would have been early to mid 68. The application was discontinued the summer of '69 and the 67s shipped to Boeing Seattle..

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

IBM 9020 FAA/ATC Systems from 1960's

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 9020 FAA/ATC Systems from 1960's
Newsgroups: alt.folklore.computers
Date: Mon, 30 Jul 2001 12:24:07 GMT

Nick Spalding writes:
My Green Card GX20-1703-9 has TS on it. Anyone know what date the -9 represents?

nope, but it is also in my -7. it seems to have been in all the original 360s.

I did alta-vista search on 9020 and came up with a couple hits.

http://www.faa.gov/apa/speeches/aoa/FWINGS.htm
https://web.archive.org/web/20020417133633/http://www.faa.gov/apa/speeches/aoa/FWINGS.htm
Automation of en route ATC began with the installation of IBM's prototype 9020 system at the Jacksonville Center in 1967. Designed to provide automated flight data processing and radar tracking at all en route centers and major terminals, this was the most complex computer application ever undertaken up to that time. Its half million commands required more than twice the amount of memory originally planned, a complication which caused the project to fall behind schedule. The installation at all 22 en route centers was not completed until the end of the 1970s.
http://www.aero-space.nasa.gov/library/ch1.htm
https://web.archive.org/web/20020220023313/http://www.aero-space.nasa.gov/library/ch1.htm
Automation of en route ATC began with the installation of IBM's prototype 9020 system at the Jacksonville Center in 1967. The system was designed to provide automated flight data processing and radar tracking at all en route centers and major terminals. The system was delivered behind schedule, which created significant frustration within FAA, the aviation community and IBM. The system would not be in place at all 22 en route centers until the end of the 1970s. However, indicative of the complex nature of automating the en route environment, the 9020 system proved to be the most complex computer application in the world at the time, with more than half a million commands. When the program was completed, IBM had more than doubled the amount of memory the company had first thought the program would require.

...
http://api.hq.faa.gov/96sp-fin.htm
http://catless.ncl.ac.uk/Risks/5.67.html
http://home.columbus.rr.com/lusch/index.html

HOCSR (Host and Oceanic Computer Replacement System)
http://www.faa.gov/aua/ipt_prod/enroute/hocsrfct.htm
https://web.archive.org/web/20011221011933/http://www.faa.gov/aua/ipt_prod/enroute/hocsrfct.htm
A system-wide upgrade completed in 1999 at the 20 Air Route Traffic Control Centers. It is the heart of the system in that it receives, processes, coordinates, distributes and tracks information on aircraft movements throughout domestic and oceanic airspace. It replaced the HOST computers that ten years earlier had replaced the old IBM 9020 computers. [Back]

HOST

A system-wide computer upgrade completed in 1989 at the 20 Air Route Traffic Control Centers. HOST replaced the old IBM 9020 computers. It has since been superseded by HOCSR. [Back] >
http://www.faa.gov/aua/ipt_prod/enroute/hocsrfct.htm
https://web.archive.org/web/20011221011933/http://www.faa.gov/aua/ipt_prod/enroute/hocsrfct.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

D

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: D
Newsgroups: alt.folklore.computers
Date: Mon, 30 Jul 2001 13:23:30 GMT

cb@df.lth.se (Christian Brunschen) writes:
I seem to recall hearing a rumor (and as such it is of course totally unsubstantiated) that a US government intelligence agency is reviewing an open-source OS' source code for security, to see if they can use it instead of thproven buggy, closed system (Windows) that they currently use. Again, rumor, hearsay, and I may even be misremembering the few facts I present here.

...>http://www.nsa.gov/research/selinux/list-archive/index.html

as an aside, i finally got around to updating my security glossary with glosary from Infromation Assurance Technical Framework release 3.

https://www.garlic.com/~lynn/secure.htm

notes on source of terms
https://www.garlic.com/~lynn/index.html#glosnote

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

IBM 9020 FAA/ATC Systems from 1960's

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 9020 FAA/ATC Systems from 1960's
Newsgroups: alt.folklore.computers
Date: Mon, 30 Jul 2001 17:22:19 GMT

jcmorris@mitre.org (Joe Morris) writes:
If TS was added to support the ATC requirements, why was it the only one of those specialized opcodes to make it into the standard PoO? (Perhaps because it alone did not rely on any particular data structure that was unique to the FAA software?)

TS was used for multiprocessing support in both 360m65 (os/360) and 360m67 (tss/360 & cp/67). Both predated the ATC work (although ATC may have taken advantage of some of the 360m65 multiprocessor work).

my understanding was that the 65 & 67 were originally going to be 360m60 and 360m62 ... but somewhere along the line, there was an upgrade to the memory technology (to 750ns) and the numbers got changed.

as an aside, the work at cambridge on fine grain locking with cp/67 directly led to compare&swap instruction in 370 (in fact, "CAS" are the person's initials that did most of the work at cambridge, and the trick was to come up with a mnemonic that was his initials; it got modified to CS & CDS tho).

random refs:
https://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

checking some myths.

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Mon, 30 Jul 2001 18:02:02 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
In actual fact, there are bugs that can creep by the 3-level test for both compilers and VMs, but they are mind-bogglingly obscure by comparison with the ones that adding the third level picks up.

for the resource manager ... I developed an automated benchmarking system that would generate kernels, auto-reboot, run benchmarks, build new kernels, run more benchmarks ... and it would run & run & run. The basic set was 2000 benchmarks that took three months elapsed time to run (before initial product release).

The benchmarking attempting to choose workloads along the edge of the "normal" observed operational envelopes, random points withing the envelope and some number of operations that were way outside any normal envelope ... say saturating a couple fixed-head paging devices (hundreds of pages/sec), with huge queues and average service time of 1second.

These outside the envelope benchmarks tended to precipitate zombie user conditions and numerous timing failures. In order to eliminate all such cases (from the normal system), I had to totally rewrite the system serialization primitives in order to eliminate all possible occurances of zombies & kernel failures because of various asynchronous timing problems.

random refs:
https://www.garlic.com/~lynn/94.html#52
https://www.garlic.com/~lynn/2001c.html#13
https://www.garlic.com/~lynn/2001e.html#45
https://www.garlic.com/~lynn/2001f.html#56
https://www.garlic.com/~lynn/subtopic.html#fairshare

and of course, my favorite "envelope" subject:
https://www.garlic.com/~lynn/subboyd.html#boyd

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

checking some myths.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Mon, 30 Jul 2001 17:47:11 GMT

Greg Pfister writes:
Related -- Once upon a time that same friend told me that you actually have to be able to do three levels of virtualization of memory to be general -- the top-level VM system just doing it is not enough; you have to be able to nest a VM system virtualizing what the top-level system is also virtualizing, and a third level below that. I never did understand why the third level was necessary, but this guy was very, very good and knew that code intimately, so he was probably right.

multi-level reference
https://www.garlic.com/~lynn/99.html#7

three levels of CP/67 under which ran CMS. standard cp/67 running on the real hardware in an "open" environment (university students & others on effectively a public access machine),

then a modified CP/67 running in "360m67" mode ... but providing 370 virtual machines (primarily relocation tables different structure between 360m67 & 370), and then a further modified CP/67 running in "370" mode ... which then provided 370 virtual machines (running CMS) ... aka


  real 360m67
cp/67
    standard 360 & 360/67 virtual machines
CP/67 modified to provide 370 virtual machine
370 "R" virtual machines
CP/67 modified to run on 370 w/virtual memory
        370 "R" virtual machines
CMS

This was about two years before virtual memory was available on 370 (and possibly a year before 370 engineering models with virtual memory were available). Issue was to try and obscure the fact that development for unannounced (or even unavailable) products was going on.

while there was quite a bit of use of CP/67 & VM/370 inside the corporation for the testing of new operating systems ... in terms of CPU cycles, probably the biggest use was straight interactive computing (edits, compiles, non-operating system testing, email, documents, GML, etc). Part of this give rise to the largest network in the world (larger than arpanet until around '85)

'83 ... had nearly 1000 mainframe nodes at point when arpanet was about 255 total nodes. random refs:
https://www.garlic.com/~lynn/99.html#112

there was another way of getting machine time. the disk engineering labs were doing all their development in a stand-alone environment (MVS with a single "test-cell" MTBF was on the order of 15 minutes). I rewrote i/o supervisor so it wouldn't fail & they could operate 6-12 test-cells concurrently. The priority list on processors ... was that typicall as soon as the CPU/processors engineers had the 2nd one running; it was made available to the disk engineering labs for their testing.

random refs:
https://www.garlic.com/~lynn/2000d.html#0
https://www.garlic.com/~lynn/subtopic.html#disk

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

physical vs. virtual addresses

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: physical vs. virtual addresses
Newsgroups: comp.arch
Date: Mon, 30 Jul 2001 18:22:37 GMT

hack@watson.ibm.com (hack) writes:
It's a win when there are 10,000 logged-on interactive CMS users on a large VM system -- it improves interactive response time tremendously for the much smaller subset of concurrently active users.

random refs:
https://www.garlic.com/~lynn/93.html#5 360/67, was Re: IBM's Project F/S ?
https://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
https://www.garlic.com/~lynn/98.html#46 The god old days(???)
https://www.garlic.com/~lynn/99.html#4 IBM S/360
https://www.garlic.com/~lynn/2000g.html#38 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2000g.html#43 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2000g.html#44 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2000g.html#45 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2000g.html#47 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
https://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
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/2001c.html#16 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001c.html#48 database (or b-tree) page sizes

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Mon, 30 Jul 2001 18:37:59 GMT

Anne & Lynn Wheeler writes:
'83 ... had nearly 1000 mainframe nodes at point when arpanet was about 255 total nodes. random refs:
https://www.garlic.com/~lynn/99.html#112

oops that should be
https://www.garlic.com/~lynn/99.html#112

also some discussion at
https://www.garlic.com/~lynn/internet.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Intel's new GBE card?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel's new GBE card?
Newsgroups: comp.arch.storage
Date: Mon, 30 Jul 2001 19:21:19 GMT

Rick Jones writes:
Support for hardware checksum offload in networking stacks goes back at least to the late '80's/early 90's. OSes such as IRIX and HP-UX were among them. I suspect a couple others were there at the time too. Perhaps Digital Unix/OSF1. Later that did trickle-down to the commodeity space.

Indeed, unless one has a really ugly stack implementation, the things you need/want to offload are those things that require "accessing" the data. That would certainly include the checksum computation, and if that offload also allows for copy avoidance even better.

At least SGI was very active in the late '80s .... some engineers that had worked on the high-speed pipelining of the (graphics) geometry engine were working on a high-speed pipelined "protocol engine" for network protocol (which including things like moving the checksum in the header to the trailer).

the trick at the time was to come as close as possible to saturating 100mbit FDDI medium w/o disolving the CPU (the time since then, the CPUs have gotten significantly faster)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Redhat 7.2?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Redhat 7.2?
Newsgroups: comp.os.linux.questions,comp.os.linux.help,linux.redhat,comp.os.linux.setup
Date: Mon, 30 Jul 2001 22:15:23 GMT

I was in frankfurt two weeks ago ... and saw (german) Redhat 7.2 for sale in window of store (about half-block down side street off main shopping mall).

Is this something that specific to germany?

I've not seen it in any stores in the US yet?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

"Hollerith" card code to EBCDIC conversion

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Hollerith" card code to EBCDIC conversion
Newsgroups: alt.folklore.computers
Date: Mon, 30 Jul 2001 23:48:35 GMT

Eric Fischer writes:
There are lots of special cases in the conversion between the "Hollerith" card code and its representation as 8-bit EBCDIC. How do IBM 360-series systems deal with this? Is there a lookup table? Hardware assistance?

The conversion to 6-bit BCDIC doesn't have as many special cases, but does have a few. IBM 70x systems had to read cards bit-by-bit, right? Was there a standard algorithm that everyone used to do the conversion?

i worked with 2540 card reader that was originally (I believe attached) to 1401 ... and then attached to a 360m30 (running both 1401 emulation and os/360).

I had a job to rewrite the 1401 unit record (ur<->tape) front-end for 709 to run on 360m30. While I was writing the program, they would switch the machine back & forth between 1401-mode and running other 360 programs (and testing my program).

Cards could be either binary or bcd. If they were binary, you would read with column-binary command which would place 80 columns of data into 160 bytes (effectively two 6-bit values per column mapped into two 8-bit bytes). If it was BCD ... then it was just BCD read into one byte.

"greencard" gives the mapping of bit patterns to punch holes for BCDIC & EBCDIC (as well as mapping to 7track tape). The issue wasn't so much what the bit pattern was ... but what character the bit pattern represented depending on whether you were treating it as BCDIC or EBCDIC ... aka punch 0-6-8 comes in as hex "6E" ... but is backslash in BCDIC and greater-than in EBCDIC.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

earthlink timing out nntp connections

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: earthlink timing out nntp connections
Newsgroups: gnu.emacs.gnus
Date: Tue, 31 Jul 2001 11:32:11 GMT

within the last week or so, earthlink appears to have started timing out nntp connections after only something like 30-60 seconds. if you spend too long reading an article ... the connection has timed out before you move on to the next article ... or if you are typing a reply. it plays quite a bit of havok with gnus 5.8.8.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

TECO Critique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TECO Critique
Newsgroups: alt.folklore.computers
Date: Tue, 31 Jul 2001 12:21:37 GMT

jmfbahciv writes:
What are you talking about? The two are mutually exclusive. One is a way to address memory, the other is a way to manage memory.

it is possible that it is demand paging vis-a-vis swapping.

demand paging typically waits for a page-fault at a time and does a/one page block transfer. there are various kinds of page replacement algorithms associated with this. paging also has to do with virtual memory support ... which page faults & demand paging can be a part of, although there has been some number of systems that are simply used for memory mapping (like overcoming memory fragmentation problems).

swapping tends to be a task management oriented event. CTSS would swap/roll-out whole task and then swap/roll-in a different task.

various optimizations are possible with swapping ... and can even work with a demand paging system. at some task deactivation event all pages for a task are written out at one time (and the pages with reference bit on are remembered), later when the task is re-activated all the referenced pages are read back in at one time. between task activation and deactivation ... the system could manage the task with demand paging.

boeing huntsville modified MVT for just virtual address mapping to address a (contiguous address) memory fragmentation problem they had (w/o any page faults, or demand paging or swapping).

https://www.garlic.com/~lynn/2001.html#14

there are intermediate situations between demand paging and task swapping ... like what was done in vm/hpo in the early 80s where "swap" was managed in groups of blocks of ten pages (rather than all pages). on deactivation/outgoing ... pages were clustered in groups of ten pages for writing. on activation, a hybrid demand paging/swap occurred where a page fault for a page this is part of a group would bring in all ten pages in that group.

https://www.garlic.com/~lynn/2001h.html#20

& something from a recent mailing list

> What is footnote 23, or more directly, where can I read more
>about Atlas's VM problems. Lord knows I have plenty of experience
>(as a user) with badly implemented VM, but what was the "killer"?

I don't know specifically what Atlas's problem was. I know that the CP/67 support of demand paging wasn't very good when I first saw it in Jan. 1968, however, TSS/360's was even worse (the university that I was at had been doing TSS tests on & off during '67 & '68, primary reason that it was investigating CP/67 was because TSS performance was so abysmal).

There were actually a couple problems

1) page replacement algorithm
2) path length
3) disk/drum (fixed-head disk) I/O optimization
4) disk/drum migration
5) thrashing controls.

CP/67 didn't have #4 ... and the rest was very poor.

TSS/360 had something #4 ... but it actually caused more problems than it solved. A task that woke up or made it out of the thrashing control list ... got all its pages moved from 2311 (moveable arm disk) to 2301 (moveable arm disk) before actually executing. When it went idle (say between simple edit commands), all its pages were swept from the 2301 back to 2311. This happened even if there was no contention for space on the 2301. It wasn't optimized for relying on pages that might be laying around in real memory.

With regard to CP/67, I rewrote most of the code while also doing the pathlength optimization for running OS/360.

I created the first "clock" replacement algorithm, my own method of estimating "working set" for page thrashing controls, very short pathlength implementation, ordered seek queuing for normal disks (help both page i/o as well as disk i/o), and some 2301 optimization (as well as early form of my dynamic adaptive feedback scheduler including "fairshare"). The "clock" replacement algorithm, I later refined after graduation when I joined cambridge scientific center in 1970.

There was a "working set" paper published in ACM sometime '68 ... about a particular kind of page replacement and thrashing controls where were significantly worse than what I had implemented.

Nearly 15 years later (after I had first implemented clock) a stanford Phd thesis was done on "clock" replacement and the "working set" author strenuously objected. In a very round-about trail ... I was finally asked to provide supporting evidence (so the guy could get his Phd). There had been a paper in the early '70s by the Grenoble Scientific Center that had modified CP/67 with an "exact" implementation of Denning's definition and benchmarks published in an ACM article running with 30 users on a 1mbyte 360/67 (about 155 pages after fixed kernel requirements). The performance (for the same workload mix) was about the same I was getting at the same time on a 768k 360/67 (104 pages after fixed kernel requirements) with 75 users.

random refs:
https://www.garlic.com/~lynn/94.html#49
https://www.garlic.com/~lynn/2001g.html#29
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/subtopic.html#fairshare

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

TECO Critique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TECO Critique
Newsgroups: alt.folklore.computers
Date: Tue, 31 Jul 2001 13:08:38 GMT

Anne & Lynn Wheeler writes:

https://www.garlic.com/~lynn/2001.html#14

oops, that should be
https://www.garlic.com/~lynn/2001h.html#14
^ --
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

checking some myths.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Tue, 31 Jul 2001 13:48:55 GMT

basically the "acceptance" test for 3880 was that it was within +/-10% of the 3830 performance. the problem was that while the 3880 supporting data streaming 3mbyte transfers ... it did it with custom hardware for the data path and a jib' microcontroller for the control path (the 3830 had been all a fast horizontal microcoded engine). The jib' was taking quite a bit longer to do clean-up after an operation finished ... so to meet the performance criteria ... they started presenting operation finished interrupt "early" (before the jib' had finished all its clean-up). This worked OK for the acceptance test which was with a one-pack/drive, single task VS1 system.

The problem was the weekend the product test lab replaced a production 16-drive 3830 configuration with one of the 3880 controllers. I got the call bright and early monday morning to come fix a operating system problem (performance had all gone to $%#!). Finally was able to trace it back to the "new" 3880. Fortunately this was six months before first customer ship ... and allowed the engineers some time to make other adjustments to address the issues.

The problem was that with multiple drives (and high level of multitasking) on the same controller, there were frequently requests queued because of channel, controller, and/or device busy. When the controller signaled operation complete interrupt ... the operating system would immediately hit/redrive it with a queued request. Because the jib' had signaled "complete" early, it was actually still busy ... and so the redrive operation got a "control unit busy" response. The system then went off to do something else. Eventually, the jib' finished and because it had signaled a control unit busy condition, it then had to signal a control unit end interrupt. With this, the system then attempts to restart the redrive operation (which would typically succeed this time).

The extra operation and interrupts .... in addition to the increase in operation latency made things look like a 80-90% system degradation.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

checking some myths.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Tue, 31 Jul 2001 14:09:32 GMT

jcmorris@mitre.org (Joe Morris) writes:
Of course, nothing brings out the bugs like putting a system into production...no matter how thoroughly you test for broken responses to pathological conditions, some user will find a new way to expose a failure mode.

... i was fortunate at the time to have a lot of responsible for some the research production systems, the disk enginnearing production systems, the disk product test lab production systems, systems at one of the VLSI labs, and a lot of the HONE production systems ... and was able to relatively easily drop new code onto their production floors for some "rubber meets the road" (the downside was I had to fix/support a lot of their other problems/issues).

I joke at one point I was working first shift in research (bldg. 28), 2nd shift in GPD (disk engineering &test, bldg. 14&15), and 3rd shift in STL (on a project supporting IMS group, bldg. 90) with periodic visits to palo alto for hone (one street over from page mill).

random refs:
https://www.garlic.com/~lynn/subtopic.html#disk
https://www.garlic.com/~lynn/subtopic.html#hone
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/subnetwork.html#hsdt

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

earthlink timing out nntp connections

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: earthlink timing out nntp connections
Newsgroups: gnu.emacs.gnus
Date: Tue, 31 Jul 2001 14:19:33 GMT

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Gro�johann) writes:
Gnus should open the connection again when needed. Does this not happen for you? Please provide more details how Gnus fails to do that.

kai

If i'm entering a newsgroup, it will re-open. If i'm posting ... it hangs for either a couple minutes and eventually says connection closed (I then go back up to the group buffer and do a get, which re-opens the connection) or it hangs for at least 10 minutes (i've never waited longer than that).

If it looks like it is hanging forever, I can hang up the modem and that wakes gnus up and it says connection closed. I then reconnect the modem and do as above.

Once the modem is reconnected I can then go to the group buffer and do a get, which re-opens the connection, and then go to the posting buffer and attempt to repost it (however, if i delay a little ... say I'm off doing something in another window while waiting for all the stuff to get back together again ... I can find myself back in the original situation all over again).

doing a get in the group buffer seems the most reliable way of getting gnus to re-open the connection (other than quiting completely out and restarting).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

earthlink timing out nntp connections

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: earthlink timing out nntp connections
Newsgroups: gnu.emacs.gnus
Date: Tue, 31 Jul 2001 14:46:20 GMT

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Gro�johann) writes:
Gnus should open the connection again when needed. Does this not happen for you? Please provide more details how Gnus fails to do that.

also, sporadically just entering a newsgroup will hang (w/o automatically reopening the connection) and I have to resort to cycling the modem connection which brings it out of it ... and then I retry reentering the newsgroup and it successfully re-opens the connection.

and possibly one out of 50? (maybe once a day) it just hangs and nothing I do brings it back ... and I eventually have to kill gnuemacs.

this started happening with gnuemacs 20.6.1 on nt4 with gnus 5.8.8 about 10 days ago ... couple days ago i upgraded to gnuemacs 20.7.1 and it hasn't made any difference.

previous posting wasn't a problem ... but i had to cycle the modem connection for this posting

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Wanted: pictures of green-screen text

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wanted: pictures of green-screen text
Newsgroups: alt.folklore.computers
Date: Tue, 31 Jul 2001 15:01:20 GMT

Tim Shoppa writes:
Wouldn't it be more "faithful" to use a font more along the line of a Teletype ASR33? (Or Model 28, or...) You had to be rich to afford a green screen in 1976...

when did the TI silent 700s show up? I remember having one for a home terminal in the late '70s before getting a ibm 3101 (at the office it was mostly 327xs).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

D

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: D
Newsgroups: alt.folklore.computers
Date: Wed, 01 Aug 2001 23:28:00 GMT

ftit@red.engin.umich.edu (Sergej Roytman) writes:
Hm, that is a pretty scary thought. All the IBMs I've worked with, dinos and otherwise, looked as if they had been programmed by Martians. Smart Martians, of course, who wrote solid code, but who did not think in quite the same way as people from my planet.

Any thoughts about IBM looking into Linux, by the way? I thought they suffered too badly from NIH to ever do something like this.

there was a reference to bringing up 41k-some different Linux copies in a small LPAR on a 390.

LPAR is a subset of the virtual machine function that allows a 390 to be partitioned into multiple logical machines (or logical partitions i.e. Logical PARtitions). You can dedicate resources to a logical partition as well as specify resources (like amount of cpu cycles). Within an LPAR you can run any mainframe operating system ... included the VM (or virtual machine) operating system. A test was done in such a configuration with a 41,000+ virtual machines each running a copy of Linux under a VM (virtual machine) operating system running in a "small" LPAR (i.e. configured with minimal resources)

a couple refs to linux 390
https://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again . . .
https://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000c.html#8 IBM Linux
https://www.garlic.com/~lynn/2001h.html#11 checking some myths.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

D

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: D
Newsgroups: alt.folklore.computers
Date: Thu, 02 Aug 2001 16:54:15 GMT

jmfbahciv writes:
Hm, that is a pretty scary thought. All the IBMs I've worked with, dinos and otherwise, looked as if they had been programmed by Martians. Smart Martians, of course, who wrote solid code, but who did not think in quite the same way as people from my planet.

They never did timesharing. Their whole company folklore is based on cards. This doesn't make them wrong...just different and very useful with certain kinds of computing.

you may be talking about the majority of the company ... but the Cambridge science center turned out CP/67, CMS, VM/370, internal network, lots of email and networking apps, GML (precursor to SGML, HTML, XML), etc. Several of the people had come from CTSS.

In a posting some time ago, I made the observation that the perception of the company was totally card based .... not because it didn't have time-sharing effort larger than possibly any other company out there ... but because its time-sharing effort was totally dwarfed by the batch/business/card business (aka if the company's time-sharing business had been some other company ... it would have been considered the largest time-sharing business around ... but because it was part of a company that had an even larger batch/business business ... the time-sharing effort has been somewhat discounted).

I joke at one time, that I personally made system distribution tapes for a number of internal installations ... at one time the number of those sites was larger than the total number of multics installations (the total number of internal sites was significantly larger than the number of sites that I directly distributed system tapes to, a number that on the internal network ... made the internal network the largest network in the world for the '70s and much of the '80s ... and the total number of internal sites was yet smaller still than the number of external customer sites).

random refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/subtopic.html#hone
https://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

D

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: D
Newsgroups: alt.folklore.computers
Date: Fri, 03 Aug 2001 13:28:07 GMT

jmfbahciv writes:
No. I'm talking about a basic computing philosophy. I forgot to point out that IBM's idea of timesharing is not our idea of timesharing. I've never been able to describe this difference well.

as noted before ... while timesharing was somewhat anti-thetical to much of the batch/card infrastructure products ... ibm did produce time-sharing for customers ... which was also taken and was the platform offering by a number of time-sharing service bureaus ... like tymshare.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

PKI/Digital signature doesn't work

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: 03 Aug 2001 18:04:35 -0600

Anne & Lynn Wheeler writes:
There already have been debit network pilots ... and work is underway for production roll-outs.

misc. refs:
https://www.garlic.com/~lynn/nacharfi.htm
https://www.garlic.com/~lynn/99.html#224
https://www.garlic.com/~lynn/aadsmore.htm#nacha

the results of the above are now available. NACHA is the (US) National Automated Clearing House Association ... the nacha web site.

http://www.nacha.org/

presss release ("digital signatures can secure ATM card payments on the Internet")

https://web.archive.org/web/20010801170255/http://www.nacha.org/news/news/pressreleases/2001/PR072301/pr072301.htm

results

https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

the report

https://web.archive.org/web/20020106102303/http://internetcouncil.nacha.org/Projects/ISAP_Results/ISAPresultsDocument-Final-2.PDF

includes the following from the above ...
The "real-world" viability of the proposed ANSI X9.59 standard concept for electronic payments using public/private key pairs, which is also known as Account Authority Digital Signature (AADS), was validated by the ISAP Pilot results. These results demonstrate the feasibility of using PKI without digital certificates, thereby minimizing infrastructure requirements and costs for utilizing the ISAP process.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Credit Card # encryption

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Sun, 05 Aug 2001 19:59:49 GMT

"Tor Rustad" writes:
If the attacker can get the public key and a copy the database, your system is trivial to break.

I don't think Visa or Mastercard are very happy about merchants storing credit card numbers at all. In fact they don't trust the Administrator either...just look at the SET protocol.

You are perhaps re-inventing the weel here, ask the credit card companies for help, else you risk a NJET later on.

the merchants need to keep the original transaction and the credit card numbers as part of standard credit card business process ... even with SET.

For more discussion with regard to the SET aspects see:

https://www.garlic.com/~lynn/aepay7.htm#nonrep2
https://www.garlic.com/~lynn/aepay7.htm#nonrep3
https://www.garlic.com/~lynn/aepay7.htm#nonrep4
https://www.garlic.com/~lynn/aepay7.htm#nonrep5
https://www.garlic.com/~lynn/aepay7.htm#nonrep6

X9.59 over comes the problem of account-number harvesting for fraudulent purposes for all account-based payments (not just internet, not just point-of-sale, not just credit, not just debit, etc)

recent posting with regard to X9.59 (specific to debit/atm card implementation)

press release ("digital signatures can secure ATM card payments on the Internet")

https://web.archive.org/web/20010801170255/http://www.nacha.org/news/news/pressreleases/2001/PR072301/pr072301.htm

results

https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

the report

https://web.archive.org/web/20020106102303/http://internetcouncil.nacha.org/Projects/ISAP_Results/ISAPresultsDocument-Final-2.PDF

includes the following from the above ...

The "real-world" viability of the proposed ANSI X9.59 standard concept for electronic payments using public/private key pairs, which is also known as Account Authority Digital Signature (AADS), was validated by the ISAP Pilot results. These results demonstrate the feasibility of using PKI without digital certificates, thereby minimizing infrastructure requirements and costs for utilizing the ISAP process.

============================

The rfi for the above:

https://www.garlic.com/~lynn/nacharfi.htm

additional information on x9.59 and AADS

https://www.garlic.com/~lynn/

nacha web site

http://www.nacha.org/

nacha organization

Welcome to NACHA

Welcome to the web site of NACHA - The Electronic Payments Association. Here you will find the latest information on the innovative and dynamic world of electronic payments.

Electronic payments of all kinds are used frequently by people, companies, and government agencies as a safe, reliable and convenient way to conduct business. Direct Deposit is used for payroll, travel and expense reimbursements, annuities and pensions, dividends, and government payments such as Social Security and Veterans benefits. Other types of electronic payments are frequently used for bill payments, retail purchases, Internet purchases, corporate payments and treasury management, and for the provision of food stamps and other government cash assistance.

NACHA is a not-for-profit trade association that develops operating rules and business practices for the Automated Clearing House (ACH) Network and for other areas of electronic payments. NACHA activities and initiatives facilitate the adoption of electronic payments in the areas of Internet commerce, electronic bill payment and presentment (EBPP), financial electronic data interchange (EDI), international payments, electronic checks, electronic benefits transfer (EBT) and student lending. We also promote the use of electronic payment products and services, such as Direct Deposit and Direct Payment.

NACHA represents more than 12,000 financial institutions through our network of regional ACH associations. We have over 600 members in our seven industry councils and corporate Affiliate Membership program.

I hope you will find this web site to be a valuable resource. Please come again!

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Credit Card # encryption

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Mon, 06 Aug 2001 13:08:05 GMT

"Tor Rustad" writes:
In the Preq message, the Payment Inforstruction (PI) is encrypted with a Payment Gateway key at the cardholder side, hence the merchant can't decrypt PI and get the PAN. Transactions can of course be matched by other identifiers, so the merchant doesn't need the PAN.

What am I missing here?

the following from:

https://www.garlic.com/~lynn/aepay7.htm#nonrep5
http://lists.commerce.net/archives/ansi-epay/199905/msg00009.html
https://web.archive.org/web/20020225023945/http://lists.commerce.net/archives/ansi-epay/199905/msg00009.html
It was never even a minor purpose of the SET specification work to eliminate credit card numbers from being known by the merchant.

The fact that the merchant does not see the account number on the way to the payment gateway was touted by some as a benefit of the system, but it was a side effect of the design. There was never a stated (or even implied) requirement to hide the account number from the merchant.

posted Fri, 7 May 1999, 14.59.11 -0700 to ansi-epay@lists.commerce.net by tlewis@xxxxxxxx

now, when I originally (long ago and far away) raised the issue that somebody could take advantage of the CC# getting to the payment gateway and not return it to the merchant ... but as stated, in the above quote as well as earlier .. "it was never even a minor purpose of SET specification work to eliminate the credit card numbers from being known by the merchant".

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Credit Card # encryption

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Mon, 06 Aug 2001 13:14:44 GMT

Anne & Lynn Wheeler writes:
....

It was never even a minor purpose of the SET specification work to eliminate credit card numbers from being known by the merchant.

The fact that the merchant does not see the account number on the way to the payment gateway was touted by some as a benefit of the system, but it was a side effect of the design. There was never a stated (or even implied) requirement to hide the account number from the merchant.

....

posted Fri, 7 May 1999, 14.59.11 -0700 to ansi-epay@lists.commerce.net by tlewis@xxxxxxxx

presumably anybody could take just about any platform as a starting point and modify it into almost any other platform (after all it is just S.M.O.P., small matter of programming) ... however, that doesn't make the result the same as what was started with.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Credit Card # encryption

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Mon, 06 Aug 2001 13:29:20 GMT

Anne & Lynn Wheeler writes:
presumably anybody could take just about any platform as a starting point and modify it into almost any other platform (after all it is just S.M.O.P., small matter of programming) ... however, that doesn't make the result the same as what was started with.

having been instrumental in doing the first payment gateway

https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

as well as being involved in some of the very early SET roll-outs (& SET payment gateway)

i could claim that it would be possible to start with either payment gateway and modify it to support X9.59 ... that would result in that particular gateway implementation having support for x9.59 ... but it wouldn't mean that the industry group SET specification supported the financial industry's X9.59 standard.

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Credit Card # encryption

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Mon, 06 Aug 2001 14:30:39 GMT

"Tor Rustad" writes:
Some time ago, I tried to download the latest X9.59 draft from the ansi-epay mailing list. Sadly I wasn't able save it in .doc format. Can someone provide me with a link or a copy? TIA

standard ISO/ANSI rules are that once it is a standard ... it is available from the ANSI/ISO bookstore as a copyrighted document (typically for a fee, which helps to underwrite the standards process).

you can pick up the pointer the X9.59 standards document from

https://www.garlic.com/~lynn/

& click on "ANSI Document" ... it is about 8 lines down ... and it is the URL at the end of the line (there are two URL pointers on that line, one "PASSED!!" and one "ANSI Document").

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Credit Card # encryption

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Tue, 07 Aug 2001 15:04:57 GMT

"Tor Rustad" writes:
"the merchants need to keep the original transaction and the credit card numbers as part of standard credit card business process ... even with SET."

is simply wrong Anne, even if you contributed to X9.59... ;-)

The fact that the merchant does not see the account number on the way to the payment gateway was touted by some as a benefit of the system, but it was a side effect of the design. There was never a stated (or even implied) requirement to hide the account number from the merchant.

Side-effect or not, both VISA and Europay are perfectly aware of this SET design. In the SET solution operated here in Norway, by default no SET merchants receive cleartext PAN.

I was at 1996 SET meetings ... and worked on some of the larger SET deployments that were worked on in late '96 and '97. I had observed what looked to be the opportunity to not return the cc# to the merchant as part of SET ... and was corrected by various of the original people responsible for SET in the 95 time-frame that it was an objective of SET to be able to do that.

I'm just passing on to you what they told me under relatively strong terms ... aka that not returning the CC# number to the merchant was not part of SET and never inteded to be part of SET (even if, as I raised in '96 it could be accomplished as an add-on to a SET implementation ... for some reason the people responsible for SET make a real big thing about not returning the CC# number to the merchant as not being something associated with SET).

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Credit Card # encryption

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Tue, 07 Aug 2001 20:03:54 GMT

Anne & Lynn Wheeler writes:
I'm just passing on to you what they told me under relatively strong terms ... aka that not returning the CC# number to the merchant was not part of SET and never inteded to be part of SET (even if, as I raised in '96 it could be accomplished as an add-on to a SET implementation ... for some reason the people responsible for SET make a real big thing about not returning the CC# number to the merchant as not being something associated with SET).

the posting ... by one of the people that was part of the original set and still one of the most active people was dated two years ago ... 7may99.

has there been changes to the SET specification since that time ... so that what has been claimed as not being part of SET and never even considered to be part of SET has changed in the last two years.

Part of the involvement in the set meetings during the 96 time-frame was having been involved in deploying the original (non-SET) payment gateway in the industry. we had learned a great deal of things about the operational characteristics ... which even had protocol implications from the standpoint of being able to provide diagnostic and servicability functions (early on we had a trouble ticket that got a NTF after three hrs ... in an industry that was expected first level problem determination to be accomplished within 5 minutes) ... and was somewhat successful in achieving enhancements from the standpoint of being able to provide operational production support.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Wired News :The Grid: The Next-Gen Internet?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wired News :The Grid: The Next-Gen Internet?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 06 Aug 2001 12:59:38 GMT

slightly related ... we had high speed backbone running in the mid-80s that NSF looked at as being technology for NSFNET1/NSFNET2 ... the immediate precursor to the current internet. for one reason or another, we weren't allowed to bid ... but a NSF audit of what we were running concluded something to the effect that what we had running was at least five years ahead of the bid submissions (to build something new).

as an aside, we had mainframe nodes ... and at the time had implemented RFC 1044 that supported channel speed transfers (tested with 4341 connected to a cray at cray research) using only a modest amount of the mainframe cpu (by comparison, the base mainframe tcp/ip would just about saturate a 3090 processor at 44kbytes/sec).

one of the features supported (including in the mainframe nodes) was rate-based pacing ... something that is supposedly currently being worked on for "internet2".

random refs:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/subnetwork.html#hsdt
https://www.garlic.com/~lynn/subindex.html#network
https://www.garlic.com/~lynn/subindx2.html#network

--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/

Article: Future Trends in Information Security

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Article: Future Trends in Information Security
Newsgroups: comp.security.misc
Date: Tue, 07 Aug 2001 22:03:08 GMT

jwmeritt@aol.com (JWMeritt) writes:
Future Trends in Information Security by Harry Schessel, Practice Leader, Kroll Information Security Group

(you may wish to notice how few of these have anything to do with IT or engineering solutions)

another interesting couple articles are:

The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aepay3.htm#riskm

AADS & Risk Management, and Information Security Risk Management (ISRM)
https://www.garlic.com/~lynn/aepay3.htm#riskaads

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Whom Do Programmers Admire Now???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Whom Do Programmers Admire Now???
Newsgroups: alt.folklore.computers
Date: Wed, 08 Aug 2001 12:44:26 GMT

mrr@reistad.priv.no (Morten Reistad) writes:
That 30 year old OS has evolved a lot on the way. Todays Linux has just as much in common with ideas from Tops20 and Multics as it has taken from the original unix. (Version 6 or something like that).

and for a lot of the 390/z stuff ... running under a system >35 years old going back to cp/40 circa 65/66 with cp/40 sharing coming heritage with multics ... some of the CTSS people went to multics at 545 tech. sq and some of the CTSS people went to cp/40 at 545 tech. sq.

the cp/40 genre also has the distinction of originating markup languages with GML gegatting SGML, HTML, XML, ECML, FSML, etc.

random refs:
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

ummmmm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ummmmm
Newsgroups: alt.folklore.computers
Date: Wed, 08 Aug 2001 20:05:36 GMT

Eric Sosman writes:
Freddy, we are old beyond your ability to comprehend. We are so old that we remember steam-powered computers, and we got dirty shovelling coal into their fireboxes. We remember dandling the young Ada Lovelace on our knees. Some of us remember being awakened in the middle of the night by the noise of the Big Bang (others slept through it).

All this probably means little to you, as you are too young to appreciate our exploits in those now-forgotten half-mythological times. Here's one item, though, that may help you to understand viscerally just how ancient we are: When we went to school in our one-room schoolcaves (houses hadn't been invented yet), the superstitious shamans who served as schoolmasters wasted precious time teaching us useless and now-forgotten lore like how to spell, how to punctuate, and where to find the SHIFT key.

somebody once told me that the (screen/display) "cursor" was invented in 1939.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Whom Do Programmers Admire Now???

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Whom Do Programmers Admire Now???
Newsgroups: alt.folklore.computers
Date: Thu, 09 Aug 2001 00:13:05 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
As well as PL/I Programming: A Manual of Style

Of course, it came out well before Harlan Mills' Structured Programming and has lost much relevance. (I.e. we deplore the GO TO.)

Harlan was part of FSD g'burg. early '70s I was at conference held at the (14th st?) marriott where he talked. There was also a talk about research into sub-second (interactive) response time, something about human threshold preception varied person-to-person ... from somewhere around .20+ seconds down to possibly .09- seconds ... which they had no explanation for (this was from broad/random sample at YKT research). Ten years later, I remember running across an article on measure speed of signal propagation thru the human brain ... which varied from person to person ... somewhat in the same general range.

random refs:
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#24 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#25 How many Megaflops and when?
https://www.garlic.com/~lynn/2000c.html#64 Does the word "mainframe" still have a meaning?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Other oddball IBM System 360's ?

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Other oddball IBM System 360's ?
Newsgroups: alt.folklore.computers
Date: Thu, 09 Aug 2001 20:24:13 GMT

lwinson@bbs.cpcn.com (lwin) writes:
There was a specialized model 40; but I forgot what it was used for and how it was modified.

The 195 was supposed to IBM's answer to Control Data's machines, but I believe very few were actually built. I never understood the difference between the S/360-195 and the S/370-195. The Pugh book doesn't say too much about this.

the people i worked with said ... the couple more (non-relocate) 370 instructions ... and better instruction retry & error handling aka that the number of components in 360/195 was so large that some hardware fault occurred within the system at some predictable rate ... and the better instruction retry in 370/195 masked a significant number of them.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Flip the bits in a byte

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Flip the bits in a byte
Newsgroups: comp.lang.asm370
Date: Fri, 10 Aug 2001 14:23:09 GMT

Pierre Fichaud writes:
Is there a way of flipping the bits in a byte aside from doing a TR?

X'01' --> X'80'
X'02' --> X'40'
X'03' --> X'C0' etc

i first ran into it when we built the first non-ibm pcm controller. turns out that ibm line-scanners put the leading bit in the low-order bit-position.

we built our own controller (which is credited with originating the ibm pcm controller business) first on an interdata-3 with the line-scanner in software (part of the reason was that we had attempted to do automated terminal recognition and reset the 270x line-scanner accordingly ... but a "feature" of the 270x thwarted our efforts; the software line-scanner was to handle both terminal type recognition and bit-speed agility). ascii convention had been to put the leading bit in the high-order bit position.

as a result, the first test ... had ascii bits arriving in 360 memory in bit-reversed order (at least by ibm standards). with a little checking, we realized that the ibm translate tables for ascii ... not only did the ascii<->ebcdic transalation ... but the translation was for bit-reversed ascii.

we actually had an option for (at least) tty to directly talk to the interdata ... so if a device was in local controller mode ... then the convention needed to be leading bit in the high-bit postion ... however if it was going on to 360 memory ... ascii bits had to bit-reversed in a byte.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

future of e-commerce

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: future of e-commerce
Newsgroups: comp.society.futures
Date: Sat, 11 Aug 2001 13:26:16 GMT

gading1@hotmail.com (Herry Rizaldi) writes:
Hi, everyone, my name is Herry Rizaldi. Currently I am doing my master degree at Monash university, Australia. One of the subject that I have done is e-commerce. I found many interesting issues related this subject. One of the issues that I would to discuss with anyone here is what do you think about the future of e-commerce? In my opinion is that although e-commerce is becoming the main intention for the IT people but honestly It does not go anywhere. The reason why is because we also have to include the human factors such as the users in building up a very good e-commerce. Most of people that I have asked about the e-commerce is that they do not really like the idea of doing shopping over the internet. There are so many issues why they do not like it such as the privacy issues, the security issues, and also the human contact issues. So if this trend is going to be the same in the future, I think e-commerce is not going to be what we would expected. I hope someone would like to discuss this issues with me.

you probably need to qualify ... b-to-c or b-to-b, etc.

there is significant amount of b-to-b traffic going on ... and several companies have reports of significant traffic and efficiency gains.

as to b-to-c ... there are a number of reports over the last 20-30 years on things like people not going to accept ATM machines because of the human contact issues.

An example would be Dr. Supriya Singh, at CIRCIT (australia) & PIRP (harvard), her doctoral thesis was Marriage, Money and Information: Australian Consumers' Use of Banks.

there is a fair amount of work underway in both the security and privacy relm; random ref:
https://www.garlic.com/~lynn/subpubkey.html#privacy

also from pirp (they seem to have had a slight problem setting the year):
Date: Fri, 07 Jun 2002 10:58:30 -0400 To: pirp@xxxxxx From: Tony Oettinger & John LeGates <pirprvws@xxxxxx> Subject: Invitation to a book-signing to launch a new book Cc: pirprvws@xxxxxx

It is a pleasure to announce a new book by Eduardo da Costa, Global E- commerce Strategies for Small Businesses, published this month by The MIT Press. Dr. da Costa wrote the book while a visiting scholar at the Program on Information Resources Policy.

You are invited to a book-signing event that we are hosting to celebrate the launching.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Flip the bits in a byte

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Flip the bits in a byte
Newsgroups: comp.lang.asm370
Date: Sat, 11 Aug 2001 15:26:43 GMT

"Sven Pran" writes:
You need addressability to the translate table.

Now: Selecting the TR or the IC method should mainly depend upon the actual need: If the byte to have its bits reversed is in memory then the TR method is obvious. On the contrary if the byte is already loaded in a register, or if the result is required to be returned in a register then the IC method should be selected. Neither method has any apparent advantage over the other when you look at them except that the TR method is a single statement operation while the IC method at worst is a three statements operation. (Not very important though).

on some of the older machines ... an ic/ic/stc/bxle loop was actually faster than TR.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Net banking, is it safe???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Sat, 11 Aug 2001 15:40:26 GMT

graperdude@aol.com (Graper) writes:
Now let's look at a new format using public/private crypto. I have a smart card, designed to protect private key to a much higher level of protection than a mag stripe. That key is then protected with a passphrase of my choosing. I have a smart card reader, also designed to properly protect key processes. I appear face-to-face with an officer of my bank and exchange public keys as well as digital fingerprints for those keys. I make arrangements as to the limits of electronic transactions, as well as any additional security protocols, like layered passwords, callback connections, and variable route transaction confirmation. I would also sandbox the PC to reduce virus and trojan penetration, including removable hard drive which is physically secured when not in use.

an example of business rules would be to not allow account numbers in authenticated transactions (like public/private key) to be use in non-authenticated transactions.

this is a business rule that is part of x9.59 standard and also used in the nacha pilot ... i.e. it eliminates the account number harvesting & leakage that is frequently in the press as a point of attack/exploit. while there are still points of exploits ... the ability to harvest hundreds of thousands of account numbers at one time and use any/all of them in subsequent fraudulent transactions is eliminated ... significantly altering the cost/benefit fraud ratio.

x9.59, aads, and nacha refs:
https://www.garlic.com/~lynn/aadsm6.htm#aadsatm (certificate-less) digital signatures can secure ATM card payments on the internet
https://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#37 credit card # encryption

misc. other refs:
https://www.garlic.com/~lynn/
https://www.garlic.com/~lynn/subpubkey.html#privacy

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

YKYGOW...

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: YKYGOW...
Newsgroups: alt.folklore.computers
Date: Sat, 11 Aug 2001 18:54:34 GMT

Charles Richmond writes:
>High speed printers have problems of their own. Like the time one of >the sites we supported called our user support desk to complain that >blank fan-fold paper was rapidly spewing out non-stop in a parabolic >arc. The user support drone looked in his manual, under "printer >problems," and mindlessly recited the first thing he saw. "Can you >fax it to us?" The client was not amused.

The only time I have seen printers spew paper this way is when some dunce printed 500 lines, each with a top-of-form character in column one...

you see it when somebody messes up a carriage control tape and there is no hole for skip to column one.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

YKYGOW...

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: YKYGOW...
Newsgroups: alt.folklore.computers
Date: Sat, 11 Aug 2001 20:26:41 GMT

Anne & Lynn Wheeler writes:
you see it when somebody messes up a carriage control tape and there is no hole for skip to column one.

oops ... that is channel 1 ... not column one (brain check) in the carriage control tape.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Blinkenlights

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinkenlights
Newsgroups: alt.folklore.computers
Date: Sat, 11 Aug 2001 23:41:32 GMT

Prof Karl Kleine writes:
As a student of electrical engineering in the begin of the 70ies at Ruhr-Universitaet Bochum, Germany, I had a student job in one of the workshops of the university. As I also had some aquaintance with the people and the machines at the computing center I got the job of constructing and building a very special tripod for a Polaroid camera: Upon a machine crash (or upon seeing a very peculiar pattern) the operator would grab the camera with the attached tripod, hook the rubber feet into the corners of the blinkenlights console (everything was made to measure and fixed) and take a shnapshot. Yes, that was a real snapshot of the machine state, with instruction register, instruction address, the user registers, flags, etc. After that, reboot.

boeing wichita somewhere in the 73-74(?) time-frame used some sort of capture on 370/168 lights to sample the PSW (including instruction address) that then was used to produce a histogram of time-spent in various parts of the VM kernel. It was much less expensive than the IBM hardware performance monitor.

similar sampling
https://www.garlic.com/~lynn/94.html#21

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Whom Do Programmers Admire Now???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Whom Do Programmers Admire Now???
Newsgroups: alt.folklore.computers
Date: Sun, 12 Aug 2001 15:24:36 GMT

jmfbahciv writes:
You didn't talk to any of the Good Guys. We had our days when we rued ever shipping sources usually after having a bull session with a customer who thought he knew better than us or liked to find all errors and rub noses in it.

But we got over that fast when we encountered some really brilliant evolutions of the code to do a particular task. I'm talking with a guy now who used an -8 to gather sky data. Give a guy the gear and a basic set of software he can play with, and there are amazing things that get done.

both cp/67 and vm/370 was shipped with full source for cp and cms (and as many of the applications as possible).

The early cp/67 & vm/370 for kernel build was typically multi-stage process that 1) wr0te all the binaries to a (9-track) tape in bootable format ... 2) boot'ing from the tape which would result 3) in writing a disk bootable (or ipl'able) image to disk ... 4) from which cp was normally booted/ipl'ed.

Because of some experience with various kinds of glitches ... i early on enhanced the procedure to dump to tape (after the kernel) all the source and procedures necessary to recreate the cp kernel ... followed by an image of cms (typically wasn't enuf room on the tape to also include all the cms source).

Years later ... when Melinda was looking for source to the original source maintenance procedures what cambridge had developed for cp/67 & cms (and later used by a number of other product groups), i was able to find an old boot tape that still had the full set of procedures appended.

melinda's history of vm (there is also a cms copy of zork)
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist

random refs:
https://www.garlic.com/~lynn/2000.html#43
https://www.garlic.com/~lynn/2000.html#44
https://www.garlic.com/~lynn/99.html#149
https://www.garlic.com/~lynn/99.html#18

with respect to above reference about somebody in the operator staff randomly selecting tapes to be mounted for scratch ... some amount of the archived stuff included early dynamic adaptive fair share stuff. One of the characteristics of the dynamic adaptive fair share stuff was that it did periodic system activity snapshots and used it for dynamically adaptive feedback control operations.

Apparently in the same period somebody filed a patent for taking periodic system activity snapshots and using it as output to system prograrmmers engaged in manually tuning a system. at one point, i was contacted about the availability of my source as it might have some bearing on the patent.

however, there was no mention that during almost that whole era the state-of-the-art seemed to be manual system tuning ... and somewhat ignoring that the referenced material they were interested in ... essentially eliminated that occupation in favor of a system that supported dynamic adaptive feedback.

It possibly did have some indirect benefit at cambridge since all those system activity reports early on evolved into capacity planning.

random refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Net banking, is it safe???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Sun, 12 Aug 2001 15:45:21 GMT

LESLIE@209-16-45-102.insync.net (Jerry Leslie) writes:
No system is 100% safe/secure unless it is turned off and physical access denied.

One has to decide that the convenience of on-line transactions is worth the risk, and whether the financial institution is exercising due diligence.

Use of Microsoft's IIS without patches can expose information to criminals. Here's a relevant article:

http://www.theregister.co.uk/content/4/20960.html

Hacking IIS -- how sweet it is
By Thomas C Greene in Washington
Posted: 10/08/2001 at 19:29 GMT

We've looked over a few recent credit-card database compromises brought to our attention by CardCops (formerly AdCops), an organization which tries to get the straight dope on e-commerce hacks directly from the blackhat community to better inform merchants of threats to their systems...

Although The Register and The Inquirer sites are not 100% accurate, their articles often cite references; e.g.:

http://www.cardcops.com/

Here's a site that might provide some useful info:

http://www.cybercrime.gov/

however, the merchant systems are attractive targets since 1) current credit card transactions are not authenticated and 2) merchant-related card business processes involve merchants maintaining file on previous transactions (aka the credit card numbers).

as a result havesting the merchant credit card file ... enables a large number of fraudulent (unauthenticated) transactions across possibly hundreds of thousands of credit card accounts.

aka the previous transaction information ... account number, et. al are essentiall shared-secret ... since it is sufficient for generating a fraudulent transaction.

going to authenticated transactions ... aka x9.59 and the nacha trials ... eliminates the harvesting of the credit card file as a meaningful exploit since the information contained in the file is no longer sufficient for generating a fraudulent transaction.

x9.59 and the nacha work didn't directly improve the security of the merchant web sites ... it just eliminated the major attack point at merchant web sites as a meaningful fraudulent activity (such files could still be harvesting, it just wouldn't result in fraud).

random refs:
https://www.garlic.com/~lynn/aadsm6.htm#aadsatm
https://www.garlic.com/~lynn/2001h.html#37
https://www.garlic.com/~lynn/2001h.html#53
https://www.garlic.com/~lynn/subpubkey.html#privacy

it also has an interesting personal side-benfit ... effectively empowering the person. significant amount of the current fraud revolves around the degree that merchant sites protects the consumer's data. a consumer doing large number of transactions at a large number of different sites is dependant on each & every one of those sites never, ever, making a security mistake.

going to authenticated transactions ... moves the point of attack from the merchant to the person (besides eliminating the fraudulent multiplier benefit of one event harvesting sufficient information capable of generating tens of thousands of fraudulent transactions) ... the person now has some control over the possible points of attacks (and is not dependent on a continuing bases the security of all the merchants that they have ever done business with).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Blinkenlights

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinkenlights
Newsgroups: alt.folklore.computers
Date: Sun, 12 Aug 2001 17:06:14 GMT

"Daniel House" writes:
Do you know why there were always (at least that I've seen) two "odometers" ? They look like Hobbs meters on small airplanes, which count the hours that the airplane engine runs. But in a little single engine Cessna or Piper, I've only seen one per plane. Why two on a mainframe ?

mainframes were all leased ... and a "CE key" ... which could switch from the customer billing meter and the "service & maint" meter.

one of the great benefits to time-sharing service bureaus (like tymshare, ncss, idc, etc) was the ability to let the system (& meter) go idle when there was no system activity.

you could get different contract leases for hrs per week (i.e. one, two, three or four shifts typically). nominally the billing meter would run even when the cpu wasn't executing instructions (i.e. in wait state) if there was "outstanding" i/o i.e. even tho the processor might not be executing 360/370 instructions ... it was possible that the processor engine was executing other kinds of instructions on behalf of various i/o operations.

one of the time-sharing tricks was to be able to leave a kind of pending I/O operation on terminal lines (allowing it to accept incoming characters) which wouldn't cause the billing meter to tick when characters weren't actually being transferred. this enabled being able to offer service 3rd & 4th shift ... when there was nominal little or no (time-sharing) billing activity ... but could still rack up machine leasing billing activity.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Whom Do Programmers Admire Now???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Whom Do Programmers Admire Now???
Newsgroups: alt.folklore.computers
Date: Sun, 12 Aug 2001 17:14:31 GMT

Anne & Lynn Wheeler writes:
both cp/67 and vm/370 was shipped with full source for cp and cms (and as many of the applications as possible).

cp/67 & vm/370 (as well as hasp) you built your system from the source, aka it was just that a copy of the source was provided ... but the source was used to actually build the system.

I wouldn't have been able to do many of the cp/67 & hasp things as an undergraduate, if I hadn't had a source-based build system.

doing things with os/360 was a little harder ... you could get microfiche source and figure out some stuff and in some cases "patch" the binaries in order to effect changes (various kinds of tricks for binary patching were developed in order to apply system enhancements to a binary-based build system ... even if some kind of source was available).

random refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/submain.html#360pcm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Net banking, is it safe???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Sun, 12 Aug 2001 21:25:22 GMT

nominally the amount of security is typically proportional to what is at risk.

let say a web merchant offers a $5 item (that costs $3 wholesale) and sells 100,000 of them thru credit card purchases.

that is $500,000 gross revenue, or $200,000 left to cover operating, mailing, security, salaries, profit, etc.

so, in theory, what is at "risk" should be in the $10,000 to $500,000 range (depending on whether only transactions in a certain window are at risk or aggregate of all transactions are at risk). so, in theory, some amount of the $200,000 should go to providing security proportional to the risk.

however, the merchant credit card transaction file is effectively at risk proportional to the credit limit of all the customers ... not proportional to what it is that they bought from the merchant ... and effectively doesn't have a narrow time window (other than say the card expiration date). Taking a nominal credit limit of $500, then what is at risk is now in the $50,000,000 range (not the $10k to $500k range).

Let say there are something like 10,000,000 such merchants world-wide with similar profile ...
ignoring for the moment, the fact that they have to have credit card file security that protects from both outsider and insider exploits

... each and every one of those merchants now needs security that is proportional to a $50,000,000 risk rather than a couple hundred thousand dollar risk (at most) ... i.e. what is at risk is possibly one hundred to one thousand times as large as what the individual merchants directly are dealing with. Any sort of failure at any one of those 10,000,000 merchants results in a $50,000,000 exposure.

One could make the claim that each individual merchant doesn't have the revenue and/or the risk profile to cover the actual total risk that their credit card file represents and/or fund the necessary associated security that is proportional to the actual risk.

One of the things that I worked on was resource management algorithms that are proportional to the resource. Resource management algorithms that incurred an expense much larger than the value of the resource they managed weren't likely to survive. It was necessary to have a management algorithm that was proportional to the value.

Applying the analogy to merchant credit card risk ... the risk that they are securing needs to be proportional to their business operations (i.e. revenue and profit) and not proportional to something that they have no control over (like the aggregate of all the credit limits for all the customers that they happen to deal with).

random refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subpubkey.html#privacy
https://www.garlic.com/~lynn/subintegrity.html#fraud
and assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Net banking, is it safe???

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Sun, 12 Aug 2001 23:42:39 GMT

Anne & Lynn Wheeler writes:
however, the merchant systems are attractive targets since 1) current credit card transactions are not authenticated and 2) merchant-related card business processes involve merchants maintaining file on previous transactions (aka the credit card numbers).

somewhat unrelated and off topic ... i recently updated my security glossary with terms from IATF V3

ref:
https://www.garlic.com/~lynn/index.html#glosnote

security glossary
https://www.garlic.com/~lynn/secure.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Blinkenlights

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinkenlights
Newsgroups: alt.folklore.computers
Date: Mon, 13 Aug 2001 12:48:54 GMT

ehrice@his.com (Edward Rice) writes:
Did IBM charge more for three eight-hour shifts a day, or for four six-hour shifts? No wonder they were so profitable!

i think 4th shift was time in excess of 5x24=120hrs per week (i.e. 7x24=168-120=48hrs ... aka sat & sun). I seem to remember somebody saying 4th shift rates was only about 10% of 1st shift rates (if the meter actually ownly ran when somebody was actually being charged to do something, it was relatively easy to recover costs for leaving the machine up ... especially if the machine was running unattended).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Net banking, is it safe???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Mon, 13 Aug 2001 16:32:48 GMT

Anne & Lynn Wheeler writes:
however, the merchant systems are attractive targets since 1) current credit card transactions are not authenticated and 2) merchant-related card business processes involve merchants maintaining file on previous transactions (aka the credit card numbers).

somewhat related:
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aepay3.htm#riskaads AADS & RIsk Management, and Information Security Risk Management (ISRM)

having been somewhat involved in the first e-commerce implementation & deployment
https://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

UUCP email

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: UUCP email
Newsgroups: alt.folklore.computers
Date: Wed, 15 Aug 2001 03:34:02 GMT

bhk@dsl.co.uk (Brian {Hamilton Kelly}) writes:
That was UK.AC.EAN-RELAY, wasn't it? (As opposed to UK.AC.EARN-RELAY, which as you said did the gatewaying into BITnet, and also carried quite a lot of transatlantic traffic for the Internet. The "fascinating" thing about earn-relay was that it translated ASCII to EBCDIC, and the relays at the other end supposedly reversed the translation. However, since EARN's primary purpose seemed to be connected with CERN, the particular EBCDIC dialect used was Swiss, which meant that the end-to-end path was not ASCII-clean, particularly for characters such as backslash, braces, and percent. Since my primary use in those days was in connection with TeX, this made life a little fraught!)

from somewhere in 1984

Date: 03/20/84 15:15:41
To: wheeler

Hello Lynn,

I have left LaGaude last September for a 3 years assignement to IBM Europe, where I am starting a network that IBM helps the universities to start.

This network, called EARN (European Academic and Research Network), is, roughly speaking, a network of VM/CMS machines, and it looks like our own VNET. It includes some non IBM machines (many VAX, some CDC, UNIVAC and some IBM compatible mainframes). EARN is a 'brother' of the US network BITNET to which it is connected.

EARN is starting now, and 9 countries will be connected by June. It includes some national networks, such as JANET in U.K., SUNET in Sweden.

I am now trying to find applications which could be of great interest for the EARN users, and I am open to all ideas you may have. Particularly, I am interested in computer conferencing.

... snip ... top of post, old email index, HSDT email

bitnet/earn related posts:
https://www.garlic.com/~lynn/subnetwork.html#bitnet
online computer conferencing pots
https://www.garlic.com/~lynn/subnetwork.html#cmc

note at this time, the (internal) VNET was still larger than the arpanet/internet ... on the order of 2000 mainframe nodes at the time.

misc. internet & internal network discussions
https://www.garlic.com/~lynn/internet.htm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

UUCP email

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: UUCP email
Newsgroups: alt.folklore.computers
Date: Wed, 15 Aug 2001 04:10:19 GMT

"Peter Ibbotson" writes:
I had an account at CIX at the time (note for left pondians this was a UK version of BIX) and I remember them getting the outside world connection, thinking about it, it was probably after the Pipex got started but I do remember scrabbling around for news feeds and giving up in the end as too much bother (I had my own Trailblazer but getting the software was far too tricky for an MSDOS environment).

the best feed I had during the early to mid-90s was a satellite feed from pagesat ... with 18in dish in my backyard (looks somewhat like the current directTV dishes). I had essentially a full-feed from '92 until pagesat shutdown the service.

I used it both with waffle under ms/dos and on a couple unix machines. I had rewritten/tweaked the pagesat driver for both unix and dos and co-authored articles with pictures of me in my backyard with the dish that appeared in both boardwatch magazine and infoworld.

backyard dish for full (satellite) usenet feed

pagesat dish
https://www.garlic.com/~lynn/pagesat.jpg

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Would this type of credit card help online shopper to feel more secure?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Would this type of credit card help online shopper to feel more secure?
Newsgroups: comp.security.misc
Date: Wed, 15 Aug 2001 14:03:35 GMT

alun@texis.com (Alun Jones) writes:
Typically, you're not even liable for that - the merchant pays the _whole_ bill.

but the merchant has to get the money from some where ... it just doesn't magically pop into their till whenever they've been hacked.

additional discussions
https://www.garlic.com/~lynn/subintegrity.html#fraud

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Net banking, is it safe???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Wed, 15 Aug 2001 14:08:49 GMT

jenniekJ@excite.com (Jennie) writes:
Well, in a restaurant, most of the time, you can rely on the staff there. You can, at least, keep track of the transaction if there is any mistake. It's because it's face-to-face transaction. But, in net-banking, the transaction is processed on-line and there're many hackers and crackers, not bank officers, ready to steal your information and account number during the transction. And I think it's hard to keep track of the transaction.

within the past couple years there has emerged some new point of sale fraud with servers in resteraunts ... using a card-swipe pinned to the inside of their label ("skimmer") and a PDA ... they swipe & record magnetic stripes, recording to the PDA. That night they email the evenings harvesting to somebody on the other side of the world ... who makes up fake cards and have them on the street within a couple hrs.

some references
https://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"

other fraud references:
https://www.garlic.com/~lynn/subintegrity.html#fraud

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Very CISC Instuctions (Was: why the machine word size ...)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Very CISC Instuctions (Was: why the machine word size ...)
Newsgroups: alt.folklore.computers
Date: Wed, 15 Aug 2001 16:24:31 GMT

dg@pearl.tao.co.uk (David Given) writes:
You know, I've heard a lot about microcode recently; old 370 processors, VAXen, Pentiums, Crusoe, etc. I even heard about an APL interpreter microcoded into an IBM mainframe! So what does microcode actually look like? I imagine it as a kind of very low-level assembly language, but I'm sure there's some microcode experts here willing to enlighten me...

depends on the machine ... lots of it the low-end 370s ... the processing engine looked a lot like 16-bit minicomputer

in the late '70s, there was a project called fort knox to converge all the low-end machines to an 801 engine (in part because just about every model used a different processor engine; fort knoxalso was going to be applied to some of the non-370 processor products also). fort knox got axed (i help the author of the report that axe'd it). To be competitive, state-of-the-art had to start moving instructions directly into the processor hardware and get better than the 10:1 370 emulation thruput that the low-end microprocessor engines had been getting up until that point; aka a 370/125 at about 100kips needed about a 1mip microprocessor engine.

in the above respect ... the low-end "microcode" wasn't to unsimilar from the various 370/390 emulators currently available on intel platform.

for high end machines ... and controllers like the 3830 ... it was horizontal microcode with one instruction per machine cycle ... i.e. wide instructions that had lots of bits for doing things like start load into some working register ... and then you are suppose to know that some number of machine instructions/cycles later .. the value was available to work on.

The high-end machines rather than measuring efficiency as avg. microprocessor instructions per 370 instruction (in the vertical microprocessor engines), the horizontal microprocessor machines tended to measure efficiency in avg. machine cycles per instruction (in part because a single vliw instruction might be operating on multiple 370 instructions concurrently). For instance optimization of the microcode help drop the avg. cycle per instruction on the 370/165 at 2.1cycls/instr to about 1.6cycles/instr for the 370/168.

random refs:
https://www.garlic.com/~lynn/submain.html#mcode

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Net banking, is it safe???

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Wed, 15 Aug 2001 14:56:59 GMT

nuntapornb@hotmail.com (Nuntaporn) writes:
I do think that the situation that one will force you with gun in his hand while you are at the Bank is rarely happen. Noticing from the news, how many thieves do that? On the other hand, the information that you give through the internet for the on-line banking services has more chance to be stolen without informed. If your information like credit card number and password are stolen by hackers, you will lose huge amount of money unexpectedly.

the other scenerio is the cost/benefit ratio ... the benefit ratio of harvesting a merchant credit card file with tens of thousands of credit card numbers is significantly more profitable than using a gun at an atm machine that has surveillance cameras.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

IBM 9020 FAA/ATC Systems from 1960's

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 9020 FAA/ATC Systems from 1960's
Newsgroups: alt.folklore.computers
Date: Thu, 16 Aug 2001 02:13:58 GMT

"Charlie Gibbs" writes:
How would this compare with the infamous SLT (search list) instruction, which was available on certain 360s by RPQ. If anyone is interested, I might be able to dig up a couple of write-ups, one serious and one tongue-in-cheek. SLT's many implied operands gave the latter write-up its subtitle of "And you thought BXLE was bad?"

misc. search list reference
https://www.garlic.com/~lynn/93.html#26 MTS LLMPS?
https://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
https://www.garlic.com/~lynn/2000d.html#47 Charging for time-share CPU time
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
https://www.garlic.com/~lynn/2001d.html#23 why the machine word size is in radix 8??
https://www.garlic.com/~lynn/2001d.html#33 Very CISC Instuctions (Was: why the machine word size ...)

on 360/67s that didn't have the SLT RPQ, & if CP/67 was generated to use the instruction in the kernel ... the kernel would take an invalid instruction interrupt. CP/67 then had a kernel routine that would simulate the instruction.

from cp/67 reference (pg. 252)
Module name: SLTSIM

Entry point: SLTSIM

Purpose: Simulation of the SLT (search list) instruction on those 360/67s which do not have the RPQ.

Entry conditions:

gpr 0, bits 16-23, contains the key mask. bits 24-31, contains the count of the number of elements to be searched gpr2: contains the address of the first element (which must be on a doubleword boundary) gpr3: contains the number of bytes to be compared for the data match (1 through 4) gpr4: contains the value of the offset for the data check gpr5: contains the value of the offset for the key check gpr14: contains a pointer to the instruction being simulated

exit conditions

0 - unsuccessful comparion and key test with completion due to count 1 - successful comparison and unsuccessful key test 2 - unsuccessful comparison and successful key test 3 - successful comparison and key test

gpr0: contains the number of elements unchecked gpr1: contains the predecessor element gpr2: contains the matched element

also misc. sie ref.
https://www.garlic.com/~lynn/94.html#37 SIE instruction (S/390)
https://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
https://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

ummmmm

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ummmmm
Newsgroups: alt.folklore.computers
Date: Thu, 16 Aug 2001 13:23:27 GMT

Terry Richards writes:
Hmmmm. (A very suitable comment for a thread titled "ummmmm").

The plot is thickening. I have no idea what was going on here but I can only repeat that the cards definitely were lace punched. I kept one for many years. Unfortunately, I no longer have it but there is no question in my mind.

I'm not doubting what you and Jeff are saying but I maintain that this particular card punch, of unknown origin, was persuaded to offer up a lace punch in response to an uninitialized field in a PL/1 program. I can't remember if we used the optimizing or the checkout compiler - my best bet would be the optimizer but this was a quick one-off so it's not impossible that we used the checkout.

just had to fiddle whatever the dcb parameters (long ago, and far away) to set column binary on punch. you could start with null/blank dcb and fill in bits before the open ... or have them all specified when the macro was generated.

2540 8bit ccw op-code(s) from my trusty green-card gx20-1703-7
punch, feed, select stacker SS: SSD00001 read, feed, select stacker SS: SSD00010

where SS: 00 stacker R1 01 stacker R2 10 stacker RP3

D: 0 EBCDIC 1 column binary

so it has been 15 years since I coded a DCB macro and my references are long gone ... so a little searching on ibm.com turned up:

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/dgt1d506/2.3.16
MODE=[C|E][R]] specifies the mode of operation for the card punch. If MODE is omitted, E is assumed. You can specify:

C specifies that the cards are punched in card image mode. In card image mode, the 12 rows in each card column are punched from 2 consecutive bytes of virtual storage. Rows 12 through 3 are punched from the 6 low-order bits of one byte, and rows 4 through 9 are punched from the 6 low-order bits of the following byte.

E specifies that cards are punched in EBCDIC code.

R specifies that the program runs in read-column-eliminate mode (3505 card reader or 3525 card punch, read feature).

STACK={1|2} specifies the stacker bin where the card is placed after punching completes. If this parameter is omitted, stacker number 1 is used. You can specify:

1 specifies stacker number 1.

2 specifies stacker number 2.

random refs:
https://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
https://www.garlic.com/~lynn/98.html#9 Old Vintage Operating Systems
https://www.garlic.com/~lynn/99.html#13 Old Computers
https://www.garlic.com/~lynn/99.html#59 Living legends
https://www.garlic.com/~lynn/2000.html#79 Mainframe operating systems
https://www.garlic.com/~lynn/2000b.html#6 ascii to binary
https://www.garlic.com/~lynn/2001b.html#20 HELP

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Most complex instructions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Most complex instructions
Newsgroups: alt.folklore.computers
Date: Thu, 16 Aug 2001 20:50:31 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
In the very early 70's, I read about a GE 6xx(?) list processing machine instruction. Someone commented that complier writers like those types of instructions. Any GE experts in a.f.c-land?

some where in early '90s(?), the ibm mainframe added instructions supporting luther woodrums radix partition tree stuff

misc. ref
https://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#20 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2001.html#2 A new "Remember when?" period happening right now

from ibm pinciples of operation
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7

and for even more complex stuff there is the whole (supervisor state) infrastructure controlling access to multiple address spaces along with the program call mechanism (access registers). The idea behind program call was to try and have the efficiency of branch and link while trying to preserve some authentication & access control checking that would be possible with a kernel call (aka but w/o the overhead).

and then there is poor SIE instruction ref'ed in previous posting.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

YKYGOW...

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: YKYGOW...
Newsgroups: alt.folklore.computers
Date: Fri, 17 Aug 2001 03:11:19 GMT

jcmorris@mitre.org (Joe Morris) writes:
...you know what a 5081 was. (Hint: it's not a vacuum tube, and it's not a model number of a computer or peripheral. Almost every DP professional of the time has seen the results of its use, but it would have been very rare for one to be found even in the largest of computer shops.)

and for something completely different ... there was a 5081 "megapel" display for the pc/rt.

We managed to get a pc/rt with a 5081 into somebody's booth (not ibm) at Interop '88 running a demo copy of case's snmp. trivia question: what was causing the floor nets to crash & burn until the wee hrs of the morning before the start of the show?

misc 5081 ref:
http://www.devo.com/video/5081/index.html

random interop '88 refs
https://www.garlic.com/~lynn/94.html#34 Failover and MAC addresses (was: Re: Dual-p
https://www.garlic.com/~lynn/94.html#36 Failover and MAC addresses (was: Re: Dual-p
https://www.garlic.com/~lynn/99.html#40 [netz] History and vision for the future of Internet - Public Question
https://www.garlic.com/~lynn/2000e.html#5 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?^

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Net banking, is it safe???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Fri, 17 Aug 2001 15:45:17 GMT

graperdude@aol.com (Graper) writes:
Actually, in a PROPERLY IMPLEMENTED protocol, there would be no significant userID/password pairs resident on the server. The primary cryptographic encapsulation of a transaction, notably the client authentication, should occur on the CLIENT side. The password used to initiate this authentication encapsulation is NEVER transferred from the client machine. This is your primary line of defense. In fact, depending on one's defintion of proper implementation, the actual key used for authentication would never reside outside a tamper-resistant physical boundary, said bounday residing on a token held by the client.

first, the majority of client authentication events that go on in the world is via RADIUS. most web servers have stubbs for client authentication and an operation frequentily implements a userid/password flat-file methodology on the web-server itself.

there are a number of things that can be done for security:

1) for high activity operations, turn the web server into little more than an http<->transaction protocol translater that interfaces to a more robust backend ... where authentication takes place. This could even be collapsed into a (application protocol) firewall ... or use a pair of machines ... one the http protocol firewall, and the other an http<->transaction protocol translation.

2) use radius client authentication, either in the web server stubb (in place of a local flat-file userid/password) or in a more robust backend.

3) use one of the non-userid/password radius options for client authentication and/or even enhancing to use public key cryptography.

4) if public key cryptography is used, the private key can be housed in a hardware token of some sort

note that using radius ... an installation can have a common administrative management infrastructure for managing client authentication (including concurrent authentication technologies for different accounts as well as various types of authorization rules).

for more on internet client authentication standard, go to
https://www.garlic.com/~lynn/rfcietff.htm

and click on Term (term->RFC#) ... in the Acronym fastpath section, find & click on RADIUS. That will give you a list of all Internet IETF RFC documents associated with RADIUS (which you can click on and/or retrieve). RADIUS also has a clickable pointer for "authentication" and all Internet IETF RFC documents associated with "authentication".

client and radius authentication
https://www.garlic.com/~lynn/subpubkey.html#radius

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

Other oddball IBM System 360's ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Other oddball IBM System 360's ?
Newsgroups: alt.folklore.computers
Date: Fri, 17 Aug 2001 16:35:00 GMT

jraben@cascinc.com (Jeff Raben) writes:
I thought the 195 (or some 9x) could share memory with the 7090(7094)-->7096 so that Sabre could be transported from old to new technology piece by piece.

more likely shared disk (if there was sharing as opposed to message routing & channel-to-channel) ... my wife did stint in POK, responsible for loosely-coupled architecture and originated Peer-Coupled Shared Data architecture that was later used by IMS hotstandby and sysplex (later she did stint as head architect for amadeus ... eastern/european res. system, we still even have some of the hardcopy around some place).

at least in later time-frame, disk controllers had fine-grain locking capability initially for PARS/ACP.

cluster, high availability and/or loosely-coupled
https://www.garlic.com/~lynn/subtopic.html#hacmp

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/

next, previous, index - home