2006 Newsgroup postings (12/24 - 12/31) Lynn Wheeler

2006 Newsgroup Postings (12/24 - 12/31)

Why so little parallelism?
"The Elements of Programming Style"
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
Why so little parallelism?
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
The Future of CPUs: What's After Multi-Core?
Why so little parallelism?
Multiple mappings
"The Elements of Programming Style"
Your data private? Access all areas is on the cards
Why so little parallelism?
"The Elements of Programming Style"
"The Elements of Programming Style"
The Future of CPUs: What's After Multi-Core?
The History of Computer Role-Playing Games
The History of Computer Role-Playing Games
moving on
moving on
"The Elements of Programming Style"
moving on
"The Elements of Programming Style"
"The Elements of Programming Style"
moving on
"The Elements of Programming Style"
"The Elements of Programming Style"
"The Elements of Programming Style"
"The Elements of Programming Style"
"The Elements of Programming Style"
"The Elements of Programming Style"
"The Elements of Programming Style"
"The Elements of Programming Style"
The Future of CPUs: What's After Multi-Core?
Multiple mappings
"The Elements of Programming Style"
Wanted: info on old Unisys boxen
Multiple mappings
Multiple mappings
Wanted: info on old Unisys boxen
"The Elements of Programming Style"
Remote Tape drives

Why so little parallelism?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Sun, 24 Dec 2006 08:56:39 -0700

Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
Using a block mode terminal, like a web html form or an IBM 3270 would have solved the same problem much more cleanly, but neither of them were possible options at the time.

... ascii 3101 glass tty ... had block-mode ... intenally there was enhancement to PVM (started out emulating remote 3270s over the internal network ... sort of tn3270) ... for home terminal program ... starting late '79. The option then was to either come into the host as straight glass tty or as emulated 3270 (with the 3101 switched to block-mode) ... where PVM 3101 support played all sorts of tricks on optimizing what was already on the screen and just what had to be sent.

a couple years later this support was upgraded for ibm/pcs in the "home terminal" program ... with an application "pcterm" running in the PC. now the support got a lot more complicated ... pcterm kept large buffer of what had been on the screen. PVM kept state of the pcterm buffers ... transmission was huffman encoded ... but compression could also be pointers into stuff that was already in the buffer.

for some network topic drift
https://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)

and from long ago and far away ... "TOPAZ" was code name for 3101

Date: 10/11/79 13:32:01
From: wheeler

one other thing about the TOPAZ is the lack of APL support. The hard copy ASCII terminals we have support APL and we have the VM mods. also. Somebody from White Plains has been testing APL based products with ASCII terminals. Amoung other things they wanted to verify that some of the products would work with non-APL ASCII terminals (like TOPAZ). They had been trying to dial up to CAMBRIDG but were running into all sorts of problems. Some how they got around to calling me. They were not able to get local CAMBRIDG support in working out the difficulties of dialing into the system and 1st asked me to help. I tried a couple times, once for 45 minutes straight to get into your system on the userid and password supplied. Sometimes I was successful but CAMBRIDG is one big pain in the ... to use, especially from off site. I finally gave them a log on ID on our system so they could test ASCII tubes both with and w/o TERM APL on (and the problems went away).

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

Date: 10/11/79 14:04:47
From: wheeler

I have made mods. to DMSCIT to chain together multiple CCWs in one SIO (everything in the CONTASK queue). This suffers from a problem in VCN with the '3215' simulation code. On a real 3215 the request key will not break a chain of CCWs but instead just queue an attention to be presented when the chain is finished. XXXXX in YKT is working on extending the DIAG 58 support for use by non-3270 'formatting' CCWs (01, 02, & 0A). For DIAG 58, a request will break a CCW chain with unit check. In addition for 3270s if the terminal is currently busy all pending requests will be processed and then written using one real SIO (similar to the remote 3270 modification). I think he is also looking at what might be required to provide full screen type support for TOPAZ (new 3101 ASCII terminal).

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

Date: 03/01/80 13:45:57
To: wheeler

re: s3101, blank compression; -- normal TTY translate table now correctly translates all control characters for cursor control -- our local TTY, extended translate table mistranslates (or doesn't at all) approx. 10-12 column select characters. -- bit pairing TTY APL translate table mistranlates the function select code so no cursor positioning occurs at all -- type pairing TTY APL translate table does like wise. -- extended translate table may just be another case of a lot of don't care characters. we probably should cross check the current production TTY table against our extended table. It appears there have been several changes to the PID table. -- the TTY apl problem may be completely different and require a different program altogether. Putting code down into CP simplifies problem greatly since correct ASCII control characters can be added after translation instead of playing all the games with figuring out the inverse of the ASCII control characters so that they come out correct after being translated. That would eliminate the problem with the APL and local extended table. CP would still need the ability by the user to define the function select code for cursor positioning since it is different on different types of glass teletypes.

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

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sun, 24 Dec 2006 09:50:27 -0700

Greg Menke <gregm-xyzpdq3@toadmail.com> writes:
I tried his 50% penalty rule on one project- sure enough, thats what he did. He was also kind enough to show the grade I would have had if the goto wasn't there. Come to think of it, he was teaching us software patterns but without all the bullshit that goes along with the term nowadays.

The point being that goto is so often mis-used (at least in Cobol) that its important to understand program structure first so that goto can be used helpfully.

one of the issues that i found in doing problem failure analysis/forensics was not so much with the "goto" itself ... it was trying to reconstruct program flow and as analysis attempted to rewind the program flow ... found that a significant number of gotos arrived at the same point ... and attempting to reconstruct how program flow managed to arrive at that point becoming extremely difficult.

misc. posts mentioning dumprx ... problem analysis/forensics application that i wrote:
https://www.garlic.com/~lynn/submain.html#dumprx

past postings in this thread:
https://www.garlic.com/~lynn/2006x.html#20 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2006x.html#21 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2006x.html#29 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2006x.html#30 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2006x.html#35 "The Elements of Programming Style"

spaghetti use of gotos result in large number of mistakes ... in part because of difficult to understand program flow. going to simple binary logic can significantly simplify difficulty in understanding programming operations. however, in analysing some well-written and highly optimized kernel routines that had clear goto use ... conversion to simple binary logic operations (if/then/else) resulted in less clear logic (especially when gotos were part of clear 3-value and/or 4-value logic operations).

programmers having to manage register contents has contributed to large number of programming mistakes ... and given rise to advocacy for "higher" level programming languages that eliminate the programmer burden managing register contents. similarly, programmers having to manage string/buffer lengths has contributed to a large number of programming mistakes ... and it would be advantages to have a progamming paradigm that eliminated programmer forced to always manage length fields.

The Future of CPUs: What's After Multi-Core?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Sun, 24 Dec 2006 12:18:25 -0700

jmfbahciv writes:
Oh, wonderful. Fleeing from the hurricane right into the blizzard, both with the side effect of the power grid being interrupted.

re:
https://www.garlic.com/~lynn/2006x.html#28 The Future of CPUs: What's After Multi-Core?

denver is in a "rain shadow" (i.e. dominate storm pattern is west to east ... cloads tend to dump precipitation on moutains and the areas on the eastern/back side of mountain ranges can be semi-arid; back side of the cascades and the sierras as well as back side of the rockies) ... significantly mitigating weather patterns. "rain shadow" extends past denver and then tends to resume dumping precipitation in eastern colorado

weather channel showed the latest colorado storm somewhat unusual with counter clockwise pattern bringing moisture up from the gulf ... it rubs against nw to se cold front/flow (coming from canada) over wyoming and then continues around south along the backside of the rockies thru colorado (and past denver).

the mid-west power grid seems to be quite resilient to interruptions ... you get blizzard problems in older rural areas taking out residential overhead power lines ... but metropolitan areas and other areas with lots of underground utilities ... tend to be much less affected by blizzards.

The Future of CPUs: What's After Multi-Core?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Sun, 24 Dec 2006 12:50:29 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
the mid-west power grid seems to be quite resilient to interruptions ... you get blizzard problems in older rural areas taking out residential overhead power lines ... but metropolitan areas and other areas with lots of underground utilities ... tend to be much less affected by blizzards.

re:
https://www.garlic.com/~lynn/2006x.html#28 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#2 The Future of CPUs: What's After Multi-Core?

for some real topic drift ... when STL (renamed silicon valley lab) started bursting at the seams circa 1980 ... we undertook to relocate something like 300 people from the IMS group to offsite location. the group looked at being supported with "remote 3270s" ... but were appalled at the response time (compared to what they were use to with locally connected 3270s). so we put into HYPERchannel channel extension configuration with "local", channel attached 3270s at the remote location with HYPERchannel remote channel adapters A510s and T1 microwave connection. I've posted before how this change actually improved some of the system response characteristics.

misc. HSDT project postings
https://www.garlic.com/~lynn/subnetwork.html#hsdt

now, there was a large (couple hundred) IMS field support group in Boulder ... which were being moved to a building across a roadway ... and "remote 3270s" had also been suggested to them. Seeing the success of the STL move ... they wanted a similar deployment ... however, instead of T1 microwave between the two buildings ... they put in T1 infrared modem between the rooftops of the two bldgs.

There was some concern that the infrared modems might have severe rain fade with heavy precipitation (and Boulder tends to have heavier precipitation than Denver). However, in one extreme "white-out" blizzard condition ... when nobody was able to make it into work, the infrared modems only showed a very modest increase in the bit-error-rate (BER).

Why so little parallelism?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Dec 2006 10:23:06 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
... ascii 3101 glass tty ... had block-mode ... intenally there was enhancement to PVM (started out emulating remote 3270s over the internal network ... sort of tn3270) ... for home terminal program ... starting late '79. The option then was to either come into the host as straight glass tty or as emulated 3270 (with the 3101 switched to block-mode) ... where PVM 3101 support played all sorts of tricks on optimizing what was already on the screen and just what had to be sent.

re:
https://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?

a little more archeological cross-over from thread in comp.arch

for other historical reference, when i was undergraduate in the 60s, i had added the original tty/ascii terminal support to cp67 ... misc. related postings about that somewhat leading to univ. project to build our own mainframe clone controller
https://www.garlic.com/~lynn/submain.html#360pcm

other old email ... besides what was included in comp.arch posting

3101 had 6800 and we were looking to try and field upgrade mod1s 3101 motherboards to mod2s ... starting by copying mod2 EEPROMS and installing them in mod1 motherboards.

Date: 03/11/80 16:04:39
To: fujisawa
From: wheeler

re: 3101 mod. 2 boards. -- I am looking for help in obtain mod. 2 version of 3101. Our location currently has several 3101 mod. 1 on order for delivery in the next couple of weeks (with mod. 2 and printers on order for delivery for as soon as they are available). We currently have two mod. 2 3101 on loan from GSD for testing purposes. We are currently developing (and testing) enhancements to both MVS and VM to support the device. Would it be possible to obtain any mod. 2 boards from you to upgrade our 3101s????

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

Date: 03/12/80 08:27:17
From: wheeler

we've been working with Series/1 GSD people in this building on 3270 simulator. Also have mod. 2s on loan from same group for VM modifications. XXXXX here is currently testing MVS full screen support that he did. We currently are also working on VM support. Also in touch with engineers in IBM Kingston about burning new PROM for 3101 which makes it look much more like 3270. Talked to several customers about control units to make ASCII tubes look like 3270s. There appear to be at least 3 OEM boxes, one of them in Canada and another here in the Bay area for same function.

Most customers appear to be aware of the Series/1 effort. Their comment has been something to the effect that Series/1 is something like an order of magnitude more expensive than competive control units for 3270 simulation (partially because series/1 is general purpose computer) and the box appears to be selling very well inside IBM (implying that it isn't anywhere else).

-- We have currently been running a large number of ASCII devices for as long as I've been here. We have two separate ASCII translate tables (one of which also includes the option of 'deleting' the prompt character for input). We also have full APL/ASCII support with translate tables for both bit and type pairing. In CMS we have the support for blank compression for all terminal output to ascii tubes and a full screen edit simulator (for RED editor) for 'dumb' ascii tubes (like adm3 or character mode 3101).

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

Date: 03/14/80 14:51:16
From: wheeler

my 3101 mod. 1 arrived today. Also I sent message to Japan on Monday asking for mod. 2 boards. Response came back today, they are mailing two model 2 boards. Hopefully will have them shortly. Data jack on my telephone being installed right now. 1200 baud Vadic modem hung up in paper work in SJRL, hopefully clears next week an able to get immediate delivery.

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

for other drift, a few postings about RED editor
https://www.garlic.com/~lynn/2006n.html#55 The very first text editor
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006u.html#61 Why these original FORTRAN quirks?

The Future of CPUs: What's After Multi-Core?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Dec 2006 10:41:33 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
mentioned customers snarfing up 4331s and 4341s in orders of multi-hundred at a time. the above post also references an older post/email
https://www.garlic.com/~lynn/2001m.html#15 departmental servers

where the air force data systems (that was a multics installation) ordering 210 in the late 70s.

re:
https://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?

Another old email regarding a smaller 4341 order from a large california bank.

Date: 03/11/80 20:36:01
To: wheeler

Lynn: Bank of America needs your help. They are going to get 60 4341 and spread them around the world. All will run CP and guest operating sytems on top

They are getting xxxxxxx to help them with a multi-domain architecture. They need help in the areas of: Maintenance of a large net of machines from a single central site Multidomain support.

Perhaps this will force you to write the code.

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

recent postings mentioning increasing distributed 43xx deployments
https://www.garlic.com/~lynn/2006p.html#34 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#39 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#11 What's a mainframe?
https://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#25 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?

The Future of CPUs: What's After Multi-Core?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Dec 2006 14:24:29 -0700

re:
https://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?

you have customers in the 79-81 time-frame talking about putting in small to medium sized distributed 43xx computing (scores to several hundred ... there was one single order for nearly thousand 4341s)

you have 1980 arpanet newsletter talking about how rapidly arpanet is growing and that possibly by (sometime in) 1983, there might be as many as 100 nodes on arpanet.
https://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?

by comparison, in 1979 air force data systems was talking about a distributed 210 4341 environment.
https://www.garlic.com/~lynn/2001m.html#15 departmental servers

here, references to the internal network already being 300 machines in 1979
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?

and a reference here about the internal network doing distributed development between cambridge and endicott in 1970.
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?

However, while they were hoping that arpanet would reach 100 nodes in 1983, the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

hit 1000 nodes
https://www.garlic.com/~lynn/2006k.html#43 Arpa address

of course, arpanet significantly changed with the switch-over to interntworking protocol on 1jan83 ... following post includes quite a few references to old posts mentioning 1jan83 switch-over:
https://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)

Securing financial transactions a high priority for 2007

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 25 Dec 2006 15:12:54 -0700

Securing financial transactions a high priority for 2007
http://www.secureidnews.com/news/2006/12/22/securing-financial-transactions-a-high-priority-for-2007/

Are we talking about the X9.59 financial standard?

In the mid-90s, the X9A10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. The result was the X9.59 financial standard.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

or are we talking the infrastructure that has had the yes card vulnerabilities (which started out about the same time as the X9A10 working group)
https://www.garlic.com/~lynn/subintegrity.html#yescard

We had started work in the financial standard X9A10 working group after having worked on client/server payment infrastructure
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

that has since come to be referred to as electronic commerce.

Some recent posts about various vulnerabilities in that infrastructure (and which various parts of the x9.59 standards work from the mid-90s was intended to address):
https://www.garlic.com/~lynn/2006c.html#36 Secure web page?
https://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006p.html#7 SSL, Apache 2 and RSA key sizes
https://www.garlic.com/~lynn/2006s.html#11 Why not 2048 or 4096 bit RSA key issuance?
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2006w.html#42 vmshare
https://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance

and somewhat related work from the same period, aads chip strawman ... extremely high integrity with extremely aggressive chip & infrastructure cost reduction
https://www.garlic.com/~lynn/x959.html#aads

for some trivia drift ... public key (little "i") infrastructure from 1981:
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

using CJNTEL infrastructure from the late 70s ... i.e. some characteristics of LDAP infrastructure along with pgp key server infrastructure ... other posts mentioning CJNTEL
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and CMSBACK (more history)
https://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network

Securing financial transactions a high priority for 2007

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 25 Dec 2006 16:10:58 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
Securing financial transactions a high priority for 2007
http://www.secureidnews.com/news/2006/12/22/securing-financial-transactions-a-high-priority-for-2007/

re:
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007

then there is somewhat (internet merchant) related news

Web 'Safe' Mark May Elude New Merchants
http://www.redorbit.com/news/technology/779351/web_safe_mark_may_elude_new_merchants/index.html
Web 'safe' mark may elude new merchants
http://news.yahoo.com/s/ap/20061225/ap_on_hi_te/internet_padlocks
'Safe' Web seal requires rigorous checks
http://news.yahoo.com/s/ap/20061225/ap_on_hi_te/internet_padlocks_checks

And this old comment regarding (w/o X9.59) providing security proporitional to risk:
https://www.garlic.com/~lynn/2001h.html#61

and/or the possible requirement for burying the planet under huge amounts of encryption
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
https://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
https://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/2001k.html#53 Why is UNIX semi-immune to viral infection?
https://www.garlic.com/~lynn/2005k.html#26 More on garbage
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

attempting to deal with naked transaction vulnerabilities (i.e. transactions w/o end-to-end armoring providing integrity and authentication)
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
https://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
https://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
https://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
https://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
https://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing

The Future of CPUs: What's After Multi-Core?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Tue, 26 Dec 2006 00:42:54 -0700

re:
https://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core
https://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?

lots of collected posts mentioning (global LRU)page replacement
https://www.garlic.com/~lynn/subtopic.html#wsclock

a little more global LRU history. "Swapper" referred to what I've called "big pages". The issue in "big pages" was how to collect multiple pages (originally a 3380 tracks worth, ten pages) from the same address space for transfer in single operation. It was much easier to do something like "local" LRU ... to get a whole track of pages (from the same address space) for a single track transfer. however, that severely degraded performance with the management of the pages in real memory.

from long ago and far away ... there was a lot of performance measurements showing much improved performance by putting global LRU back in ....

Date: 01/19/86 12:29:38
From: wheeler

re: hpo; spent some time last tues. with people putting global LRU page replacement algorithm back into VM/HPO (it was taken out by the hpo3.4 group). they have very good performance comparison with hpo3.4. They are almost done with implmentation of correct global LRU replacement algorithm for >16meg real memory support (the hpo2.5 support >16meg real memory screwed up the global LRU replacement algorithm ... although they thot the code was similar ... small changes in the way some bits were tested ... resulted in algorithm other than global LRU being implemented).

It looks like will have page replacement algorithm put back to the way it was prior to HPO2.5 (i.e. >16meg support & swapper support) and a >16meg support implemented with true global LRU page replacement ... performing much better than the swapper hpo3.4 stuff & hpo 2.5 >16meg support.

I also found out from the people working on putting my global LRU page replacement algorithm back in, that IBM handed out 6 OIAs for removing it (I had previously believed that there was one or two, but wasn't sure). It is funny since prior to releasing HPO3.4 ... they were claiming it was over 80% SYSPAG code written by "Lynn Wheeler" to clean up large portions of various pieces of CP.

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

a couple recent posts about support >16mbyte real storage
https://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370
https://www.garlic.com/~lynn/2006w.html#23 Multiple mappings

Why so little parallelism?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: alt.folklore.computers
Date: Tue, 26 Dec 2006 01:57:27 -0700

re:
https://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?

and for some more topic drift, a couple posts on improving performance of cms virtual terminal i/o
https://www.garlic.com/~lynn/2003c.html#35 difference between itanium and alpha
https://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?

a couple posts discussing interactive queue response and cms terminal i/o and cp terminal i/o (there was recent post in comp.arch describing some of the complexity in linux attempting to address something similar for X actions):
https://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2003k.html#2 Rexx vs. Batch

TOOLSRUN sort of combined some of the features of usenet, mailing lists, and distributed file management. In the following, "VMPCD" was internal conferencing and files related to vm performance ... and I had made my "VMPERF SCRIPT" document available.

related email (to the following) from 1983
https://www.garlic.com/~lynn/2001f.html#email830420

Date: 01/21/86 15:21:39
From: wheeler

re: TIO loop; Code was originally implemented in CP/67 ... but apparently was modified somewhere in VM/370 ... but should have essentually been there in base VM/370 prior to any APAR activity.

Standard terminal logic in VM is to start an I/O to the console and then go into wait state. If the only I/O active is for the console, DMKDSP would determine that the virtual machine is in LONGWAIT and set the corresponding flag, DMKSCH would then see the flag and drop the virtual machine from queue.

A virtual machine executing a TIO loop waiting for terminal I/O to end will effectively "wait" as long a virtual machine actually doing a LPSW with a waitstate PSW. Code was put in place to attempt to make the TIO loop case functionally equivalent to the wait-state PSW case (from a scheduler queue activity point of view).

Originally on CP/67 I implemented a high-speed device busy counter that was based on the real device type ... not the virtual device type. In the conversion to VM/370, that code was replaced with a much longer pathlength in DMKDSP & DMKVIO that maintains summary information in various blocks based on virtual device type (i.e. virtual 3215). In VM/370, everthing was fine as long as the virtual device type and the real device type were the same or similar.

When 327xs came along, the real device type was no longer a "LONGWAIT" device even though the virtual device type (3215) was. VM/370 now began to drop virtual machines when doing real "high-speed" I/O to virtual "low-speed" devices. HPO3.4 attempted to partially compensate for this "bug" with queue drop delay. My code for VMDVBSY counter (see discussion in appendix of VMPERF SCRIPT on VMPCD) attempted to recreate the CP/67 implementation. However, several shortcuts were done with the VMDVBSY implementation in attempt to minimize the code hits ... and much of the VM/370 code remained in place (design bugs and the excessive pathlengths).

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

Multiple mappings

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple mappings
Newsgroups: comp.arch
Date: Tue, 26 Dec 2006 02:32:16 -0700

"mike" <mike@mike.net> writes:
One great thing about the single level store is that code is never ever relocated in the virtual address space. This simplifies many issues for both kernel and user code.

re:
https://www.garlic.com/~lynn/2006x.html#26 Multiple mappings

for a lot more (old) topic drift ... article predates os/400:
Start-Up Firm To Test MVS Replacement
From November 25, 1985 issue of Information Week
Byline: Paul E. Schindler, Jr.

....

Key Logic's early users will get the chance to run one of the few alternatives to the basic IBM mainframe operating system. Although Amdahl Corp. sells a mainframe Unix called UTS, and may someday release a souped-up MVS-like operating system developed under the code-name Aspen, UTS is not new to the market and Aspen is not a radical departure.

KeyKOS is both. It offers high performance, reliability, security, and programmer productivity, the company says.

....

Programmers continue to deal with the same hardware they have used for years. In a three-week course, they can learn how to program efficiently under KeyKOS using standard IBM programming languages. Experience indicates that programmers writing applications for KeyKOS produce 40% less code than do programmers for other operating systems, including IBM's MVS and VM.

This kind of productivity is made possible by two new computing principles upon which KeyKOS is based. The first principle deals with communications. Programs, tasks, files, or even guest operating systems are all known as objects that communicate via messages. Objects cannot communicate with each other unless given the "keys" (Key Logic calls them capabilities) to do so. This ensures both security and reliability. A failure in one object cannot affect any other object, ensuring continued operation.

The other principle deals with memory. As with IBM's System/38, for example, KeyKOS treats all main memory and disk storage as one virtual memory. Programmers do not have to deal with disk I/O routines or file management -- KeyKOS does.

... snip ...

a few recent posts mentioning Aspen
https://www.garlic.com/~lynn/2006w.html#24 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#28 IBM sues maker of Intel-based Mainframe clones

GNOSIS was operating system for 370 originally developed from scratch by Tymshare and spun-off as KeyKos when M/D bought Tymshare. I was brought in to do evaluation of GNOSIS as part of that spin-off (I still have the old documentation). Recent posts mentioning GNOSIS and/or KeyKos
https://www.garlic.com/~lynn/2006k.html#37 PDP-1
https://www.garlic.com/~lynn/2006m.html#34 PDP-1
https://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
https://www.garlic.com/~lynn/2006w.html#42 vmshare

post mentioning coyotos/eros/capros as evolution of KeyKos
https://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?

"The Elements of Programming Style"

Refed: **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Tue, 26 Dec 2006 07:38:33 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
the mainframe tcp/ip product had been implemented in vs/pascal ... i had done the enhancements to support rfc 1044 ... which had significantly higher thruput than the base system (1mbyte/sec vis-a-vis 44kbytes/sec ... and something like 3-4 orders of magnitude bytes per processor time efficiency)
https://www.garlic.com/~lynn/subnetwork.html#1044

as far as i knew, the vs/pascal implementation never had any buffer overflow exploits ... the ingrained paradigm was that all string and buffer operations were always done with explicit lenghts.

re:
https://www.garlic.com/~lynn/2006x.html#29 "The Elements of Programming Style"

the following group somewhat overlaps the stanford phd thesis that was 9month study on how i communicated (fact-to-face, email, instant messages, etc) ... recent post
https://www.garlic.com/~lynn/2006w.html#35 Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones

collected posts mentioning computer-mediated-conversation
https://www.garlic.com/~lynn/subnetwork.html#cmc

and from long ago and far away ...

Date: 27 Dec 83 22:47:34 PST
To: distribution

describe events, information, ..., of relevance to people involved
with the "Center for Studies on Language and Information".

The Center for the Study of Language and Information (CSLI) was
founded in 1983 to bring together researchers from Stanford
University, SRI International, Xerox Palo Alto Research Center, and
other Palo Alto area research laboratories to collaborate in the study
situated language--language as used by agents situated in the world to
exchange, store, and process information.  Situated languages include
both natural languages like English and Chinese and computer languages
like PASCAL and LISP.

     The 17 senior members, or principals, of the Center are:

Jon Barwise, Director of CSLI, Stanford University
Joan Bresnan, Stanford University and Xerox PARC
Barbara J. Grosz, SRI International
Ronald Kaplan, Xerox PARC
Lauri Karttunen, SRI International
Martin Kay, Xerox PARC
John McCarthy, Stanford University
Robert C. Moore, SRI International
C. Raymond Perrault, SRI International
John Perry, Stanford University
Stanley Peters, Associate Director of CSLI, Stanford University
Stanley J. Rosenschein, SRI International
Ivan Sag, Stanford University
Patrick Suppes, Stanford University
Brian Cantwell Smith, Xerox PARC
Thomas Wasow, Stanford University
Terry Winograd, Stanford University
-------

The mailing list "CSLI-friends" includes everyone officially
connected with CSLI and anyone else who is interested in any way
in natural and/or computer languages.

For more information about CSLI, and/or to be added to this list, send
a specific request to csli-requests@sri-ai.  FYI: announcement on
Stanford BBOARD Dave Fuchs is a PhD student at Stanford who's one of
the key people on the TEX project.

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

Your data private? Access all areas is on the cards

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Your data private? Access all areas is on the cards
Newsgroups: alt.privacy
Date: Tue, 26 Dec 2006 08:17:17 -0700

Your data private? Access all areas is on the cards
http://www.smh.com.au/news/opinion/access-all-areas-is-on-the-cards/2006/12/26/1166895296883.html

from above:
Sounds great, but most people don't have 17 cards. They have just one: their Medicare card. For most of us this means replacing our Medicare card with a supercharged version chock-full of personal information.

A Medicare card has just a name and Medicare number. The new card has a name, personal identification number, signature and biometric photograph. It also has a digital chip that can carry medical information, address, emergency contacts, concession status, even an "electronic purse".

... snip ...

same reason that there was move to relying-party-only digital certificates and away from x.509 identity certificates in the mid-90s
https://www.garlic.com/~lynn/subpubkey.html#rpo

however, it then is trivial to show that relying-party-only digital certificates are redundant and superfluous

recent related posts:
https://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports
https://www.garlic.com/~lynn/aadsm26.htm#0 Flaw in RFID-enabled passports (part 2?)

and for a little trivia drift ... a public key (little i) infrastructure proposal from 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

for public key operation w/o digital certificates ... i.e.
https://www.garlic.com/~lynn/subpubkey.html#certless

Why so little parallelism?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Tue, 26 Dec 2006 08:56:04 -0700

Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
Almost 20 years ago, while we were developing the Oseberg North Sea oil field, we had a couple of modules under construction in Holland (Rotterdam/Den Haag), and the two possible alternatives for comms links were leased SDLC or X.25.

recent posts in this thread:
https://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?
https://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?
https://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?

my wife had done brief stint as chief architect for amadeus. there was decision about SNA or X.25 ... and my wife went w/X.25. The SNA forces then went into action ... which resulted in my wife being replaced (trying to tip the balance back to SNA). It didn't do any good since amadeus went with X.25 anyway.

a hard-copy amadeus design document has a date: 24apr87 (almost 20 years ago)

a couple recent posts about other similar run-ins
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
https://www.garlic.com/~lynn/2006x.html#8 vmshare

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Wed, 27 Dec 2006 07:25:56 -0700

jmfbahciv writes:
I still don't understand how this can happen when a compiler language is used.

re:
https://www.garlic.com/~lynn/2006y.html#1 "The Elements of Programming Style"

some compiler languages do and some compiler languages don't

(at least) two issues in C ... 1) there is wide-spread use of data-pattern to determine end-of-string (i.e. length of string is part of the pattern of the data) ... and 2) storage is allocated (static or dynamic), but the language and the runtime libraries don't keep track of the length of allocated storage (the programmer has to). Such characteristics may contribute to periodic statements that C is just a fancy assembler language (not a real compiler language).

in lots of c language programs ... the programmer frequently doesn't bother to even do length validity operations ... apparently just crossing their fingers and hoping that nothing bad happens. in other cases, they may invoke length validity checking ... but it is up to the programmer to remember what lengths to specify (which could be very error prone in large, complex program)

some languages have environments where the semantics of lots of the operations have length validity as part of the core operation ... and so a lot of problems that are common in c language implementations just don't occur. this is the analogy that a log of compiler languages have management of register contents as part of the core operations and so it is much more difficult for a programmer to create a situation where register contents are mismanaged.

lots of past posts about buffer overflow issues
https://www.garlic.com/~lynn/subintegrity.html#overflow

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Wed, 27 Dec 2006 07:53:14 -0700

Peter Flass <Peter_Flass@Yahoo.com> writes:
I disagree. 80% (90%?) of the code of anything can run fine without special privileges. If it runs this way it prevents a lot of damage from bad code. For the other 20%, a call gate or whatever that carefully checks its arguments and performs well-defined functions for the caller will work. OS/2 uses rings, where the kernel is ring 0, the user is ring 3, and the device drivers are, I believe, ring 1: more privileged than the general user, but less than the kernel. A lot of protection can also be accomplished with appropriate memory mapping.

one of the problems for MVS mobing to 16mbyte virtual memory storage from real memory paradigm was the extensive use of pointer passing paradigm.

this effectively dictated that the MVS kernel (code) image appeared in every application virtual address space. the harder problem was getting the semi-privileged subsystems ... that were now in their own individual virtual address space to interact with other applications.

the initial solution was the COMMON segment ... sort of parameter passing storage that also appeared in every virtual address space. application could stuff their parameters into available place in the COMMON segment and then (thru a kernel call) pass a pointer to the parameters to a semi-privileged subsystem.

the problem for early MVS ... limited to 16mbyte virtual address space was the MVS kernel took 8mbytes of every virtual address space, the basic COMMON segment took 1mbyte ... leaving only 7mbytes in each virtual address space for application use. Large installations with lots of semi-privileged subsystems could have a five mbyte COMMON segment ... leaving only 3mbytes in a virtual address space for application use.

old reference to such problems
https://www.garlic.com/~lynn/2006b.html#39 another blast from the past
https://www.garlic.com/~lynn/2006c.html#0 Multiple address spaces

to address the rapdily growing COMMON segment problem, "dual-address" space was introduced with 3033 ... this allowed for two address space pointers, a primary/home and potentially a secondary. in the kernel call to a semi-privilege subsystem, the kernel would move the application address space pointer to the secondary and switch to the subsystem. the subsystem then could use the passed pointer to access parameters directly in the call application address space.

this was later generalized with multiple virtual address space pointers (more than two) and a kernel hardware table supporting "program call" (and return) hardware instruction. the kernel hardware table had the rules for specific subsystems in different virtual address spaces. an application would do a "program call" for a specific subsystem, and the hardware would do all the address space pointer swizzling ... w/o requiring a pass thru the kernel.

this was further enhanced so that the kernel hardware table could have both hierarchical definitions and non-hierarchical definitions. various kinds of things like library code could reside in different address space ... and could be invoked with nearly as little overhead as if it was in the same address space and being invoked with simple branch&link.

the "program call" hardware table is almost taken on some of the gnosis/keykos capability type characteristics (aka capabilities being independent of any kind of hierarchical privilege structure) ... for a little drift
https://www.garlic.com/~lynn/2006y.html#11 Multiple mappings

the above post touches a little on subject of programming difficulty.

some recent postings mentioning program call
https://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
https://www.garlic.com/~lynn/2006i.html#33 virtual memory
https://www.garlic.com/~lynn/2006r.html#8 should program call stack grow upward or downwards?
https://www.garlic.com/~lynn/2006s.html#8 Google launches search engine for finding source code
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
https://www.garlic.com/~lynn/2006x.html#23 Multiple mappings

The Future of CPUs: What's After Multi-Core?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Wed, 27 Dec 2006 13:54:12 -0700

re:
https://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?

some more email archeology around system performance operation. Much of the high performance and dynamic adaptive work that I had done on CP67 as an undergraduate in the 60s had been dropped in the morph from CP67 to VM370. I helped put a little of the pathlength optimization back into VM370 R1PLC9 (9th monthly update to vm370 release 1).

The initial VM370 morph also had something that still perported to be global LRU page replacement ... but because of numerous coding vagaries, it actually turned out to work slightly more like local LRU than global LRU.

When I was allowed to put out the resource manager ... I was able to put a lot of the instrumentation back in to support dynamic adaptive operation ... as well as correct a number of coding and structural problems ... as well as real global LRU replacement. recent post discussing some of the details (including reference to the tuning paramemter "joke" in the resource manager).
https://www.garlic.com/~lynn/2006x.html#10 The Future of CPUs: What's After Multi-Core?

collected posts about resource management
https://www.garlic.com/~lynn/subtopic.html#fairshare
and paging management
https://www.garlic.com/~lynn/subtopic.html#wsclock

At the next major release, majority of the resource manager code was merged into the base "free" kernel ... since a lot of the structural coding changes had been done for multiprocessor support. misc. collected posts about multiprocessor support
https://www.garlic.com/~lynn/subtopic.html#smp
as well as a (canceled) 5-way multiprocessor effort (shortly before the resource manager)
https://www.garlic.com/~lynn/submain.html#bounce

The remaining pieces of the resource manager was combined with a growing body of charged for kernel code ... misc. past posts talking about transition from free software to charged for software (with responsibility for the code picked up by the development group)
https://www.garlic.com/~lynn/submain.html#unbundle

Over a period of nearly a decade, various expediencies and other factors resulted in atrophy of the instrumentation that was foundation for dynamic adaptive resource management ... and the re-appearance of numerous hard-coded tuning solutions (you don't just do straight-line dynamic adaptive implementation ... but you also require the instrumentation that the dynamic adaptive implementation is dependent on).

some related posts
https://www.garlic.com/~lynn/2003c.html#35 difference between itanium and alpha
https://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?

Date: 10/15/85 14:42:52
From: wheeler

re: working set; Working set is a predictive algorithm that attempts to prevent page thrashing ... rather than a "fix-up" after disaster has hit algorithm (i.e. based on current measured real storage and page i/o demand and past measurement history of real storage and page i/o demand, predict if there is enuf resources to efficiently execute additional process)

In the resource manager there was a great deal of measurement feedback which attempts to improve its predictive controls.

Definitly some controls for recovery after disaster has struck is better than having no controls at all. However, a more sophisticated algorithm (predictive) that prevents disaster altogether (which includes dynamic adaptive feedback & recovery when it is wrong) ... will perform much better than just doing simple recovery.

The other problems you will run into (typical of many current controls implemented with HPO 3.4) is what type of number (parameter) will you use for indicating when page thrashing has occurred?; an "absolute" page rate number that is only related to page thrashing via 2nd order effects (including load, configurations, whether you have electronic drums or not, etc.)?

Unfortunately ... the PID VMs don't have the instrumentation described in my documents and other literature to accurately measure process specific & system related I/O activity. It turns out that instrumentation and measurement are pre-requisates for dynamic adaptive algorithm that can predict activity, take corrective actions, measure predicted results and use the observations for dynamically adjusting to compensate for problems.

BY DEFINITION, IT IS NOT POSSIBLE TO IMPLEMENT THE NECESSARY CONTROL ALGORITHMS WITHOUT HAVING THE INSTRUMENTATION AND MEASUREMENT DATA THAT THE ALGORITHMS ARE DEPENDENT ON.

Frequently, people fake it, by making simplifying assumptions about what the measurement data is expected to show in a small number of observed occasions and then hard-coding the values in ... and doing away with all the hard problems about dynamic adaptive, feedback resource managerment.

They are then forced into making the hard-coded values into tuning parameters ... because they will never be able to correctly "guess" at the right values (for all possible configurations and workloads). Then for the next several years a body of mythology grows up about what are the magic (tuning) values that have been found to improve things in one specific environment or another. The tuning lore around complex systems that don't have dynamic, adaptive, feedback scheduling compares with any of the sci-fantasy flics.

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

The History of Computer Role-Playing Games

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The History of Computer Role-Playing Games...
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 27 Dec 2006 14:31:39 -0700

Adam Thornton wrote:
It's wrong. ADVENT is 1972, or possibly a little bit later. But even Advent isn't *really* what he's talking about: "Adventure" and "RPG" are two distinct genres, although they certainly weren't even in the mid 1980s--_The Book of Adventure Games_ and its sequel, from 1984 and 1985 respectively, contain not only what are now adventure games, but also hints and maps for the Wizardry and Ultima games. He's basically talking about games with randomized combat (although Zork would count here), and character statistics, some sort of level or power advancement system (oddly, Zork is still in the running: your hit points, though hidden from you except in vague terms with DIAGNOSE, go up, I think, as you score more points, and your chance of hitting the thief certainly does).

ref:
http://www.rickadams.org/adventure/a_history.html
a posts on the subject:
https://www.garlic.com/~lynn/2005u.html#15 Fast action games on System/360+?
https://www.garlic.com/~lynn/2005u.html#25 Fast action games on System/360+?
https://www.garlic.com/~lynn/2005u.html#28 Fast action games on System/360+?

the following response has earlier time than original message since it came from about 8 time-zones away

Date: 04/05/78 09:36:19
To: wheeler

good morning. you were asking about a game called adventure. if you still want a copy - i hav been promised a copy in few days time so let me know if you still want it

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

Date: 04/05/78 08:08:03
From: wheeler

Would appreciate a copy of ADVENTURE. I will be going to TYMSHARE on Friday morning and will try to get a copy from them. (TYMSHARE is a commercial VM service. They also provide the machine, userids, etc. for VMSHARE. When their management found out that ADVENTURE was being offered, they wanted to take it off the system. They changed their minds when they got a look at the books. ADVENTURE is one of TYMSHARE's biggest money makers.) I don't know yet whether they will dump it to tape for me. I'm also going to try and get a VMSHARE userid from them. thxs- Lynn

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

Tymshare had got a PDP-10 copy from Stanford and then ported it to their VM system ... past posts mentioning commercial vm-based timesharing companies
https://www.garlic.com/~lynn/submain.html#timeshare

I had gotten a copy of it in the late 70s and made it available internally inside the company ... which resulted in some amount of uproar

recent posts for some bbn/imp trivia topic drift
https://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
https://www.garlic.com/~lynn/2006j.html#50 Arpa address
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/2006k.html#27 PDP-1
https://www.garlic.com/~lynn/2006l.html#52 Mainframe Linux Mythbusting
https://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?
https://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network

misc. other past posts mentioning adventure
https://www.garlic.com/~lynn/99.html#169 Crowther (pre-Woods) "Colossal Cave"
https://www.garlic.com/~lynn/2000d.html#33 Adventure Games (Was: Navy orders supercomputer)
https://www.garlic.com/~lynn/2001m.html#44 Call for folklore - was Re: So it's cyclical.
https://www.garlic.com/~lynn/2002d.html#12 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2003l.html#40 The real history of computer architecture: the short form
https://www.garlic.com/~lynn/2004c.html#34 Playing games in mainframe
https://www.garlic.com/~lynn/2004g.html#49 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004g.html#57 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#0 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#1 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#2 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#4 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004m.html#20 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2005c.html#45 History of performance counters
https://www.garlic.com/~lynn/2005h.html#38 Systems Programming for 8 Year-olds
https://www.garlic.com/~lynn/2005k.html#18 Question about Dungeon game on the PDP
https://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration
https://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron

The History of Computer Role-Playing Games

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The History of Computer Role-Playing Games...
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 27 Dec 2006 15:00:46 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

http://www.rickadams.org/adventure/a_history.html

re:
https://www.garlic.com/~lynn/2006y.html#18 The History of Computer Role-Playing Games...

from above ... an early "SPAM" reference
In 1976, Don Woods was working at Stanford University's Stanford Artificial Intelligence Lab, otherwise known by the acronym SAIL.

Woods found a copy of Crowther's woods picture rudimentary program left on one of the SAIL computers by some unknown Johnny Appleseed, so to speak.

He contacted Crowther by the simple expedient of sending email to "crowther@sitename," where sitename was every computer then on the Internet, only a mere handful of sites at the time. After corresponding with Crowther and getting his blessings, Woods greatly expanded the program.

... snip ...

but as noted, there was only a *mere handful* of sites on the arpanet at the time. this somewhat corresponds to past references about BBN being able to have regularly scheduled weekly maint, taking down all the arpanet nodes at the same time ... recent references

https://www.garlic.com/~lynn/2006k.html#10 Arpa address
https://www.garlic.com/~lynn/2006x.html#8 vmshare
https://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?

... which is possible when you have a relatively small, homogeneous environment.

from old RFC638:
PLEASE REMEMBER THAT TUESDAY MORNINGS FROM 7am TO 9am ARE RESERVED FOR NETWORK SOFTWARE MAINTENANCE.

... snip ...

the referenced RFC also gives monthly hardware maintenance schedule for all the network nodes (again, something possible when you have a small, homogeneous environment).

moving on

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 27 Dec 2006 16:44:02 -0700

Ellen wrote:
Dear VM Community,

After many years as a VM Systems Programmer and Manager, I'll be leaving Interactive Data at the end of December to pursue other interests. My thanks to those of you whom I've known throughout the years and to all the VM Community for your support. I'd especially like to thank the VM Developers whose talent, creativity, and dedication make VM such a great system. The VM mainframe continues to be a key component of Interactive Data's IT operation.

Very best wishes for a Happy Holiday season and a Peaceful New Year.

old email mentioning IDC from long ago and far away:

first two paragraphs somewhat related to this old email from 1973 and 1975
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

whole lot of posts about trying to get address location independent executable images
https://www.garlic.com/~lynn/submain.html#adcon

being mapped from (CMS) paged mapped filesystem that I had original implemented for cp67 and then ported to vm370
https://www.garlic.com/~lynn/submain.html#mmap

misc. posts about vm-based commercial time-sharing services
https://www.garlic.com/~lynn/submain.html#timeshare

and some additional topic drift, recent posts discussing mapping objects to virtual address space
https://www.garlic.com/~lynn/2006w.html#17 Cache, TLB and OS
https://www.garlic.com/~lynn/2006x.html#26 Multiple mappings
https://www.garlic.com/~lynn/2006x.html#11 Multiple mappings

Date: 03/26/79 07:52:36
From: wheeler

For relocate shared segment support, a shared segment may appear anywhere within a virtual machine's address space (it does not need to be at the position specified in the VMABLOK). The way I handled it in DMKVMA was to use the PTO pointers in the VMABLOK to check the shared segments, rather than using the segment index number to displace into the segment table and pick-up the STE.

One of the co-op students that helped me write the original shared segment support for release 2 VM (included the sub-set that is now in the product DCSS) is now with Interactive Data Corporation (IDC). They have taken the idea and put a whole group on expanding the idea. They now call it Floating segments (instead of relocating segments). They have a modified assembler for generating adcon free code and are working on the compilers. All this work they have done has greater significance than they realize. It would greatly simplify conversion to an increased address space size.

Customers appear to be ordering 4300s in large quantities. Single outstanding problem is how to do centralized maintenance. For example Univ. of Maine has 1 4341 and 8 4331s on order. They would like to do without any tape drives at all on the 4331s and do all maintenance over the network from the 4341. One thing they wanted to know, would it be possible to load data from the CPU's floppy disk reader? They would initially be willing to have one tape drive which they move around as each of the 4331s are installed, but they would then like to get rid of it after that and rely on the network. Several other installations are starting to talk about going the same way (Univ. of Maine is considered a small installation). This question of remote mainenance may become very critical (possibly the most critical) for installations talking about 20, 30, 40 or more CPUs all being serviced from a central site. I would suggest that you find as many people as possible to start looking at it and networking in general before the next share. By comparison all the current activity with performance optimization by customers can be minimized by just ordering additional CPUs (if they can maintain them in a reasonable way).

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

with regard to the last paragraph ... misc recent posts on the subject of distributed vm operation and large 43xx installations:
https://www.garlic.com/~lynn/2006v.html#11 What's a mainframe?
https://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006x.html#30 The Elements of Programming Style
https://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#6 The Future of CPUs: What's After Multi-Core?

moving on

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 27 Dec 2006 21:15:46 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
Customers appear to be ordering 4300s in large quantities. Single outstanding problem is how to do centralized maintenance. For example Univ. of Maine has 1 4341 and 8 4331s on order. They would like to do without any tape drives at all on the 4331s and do all maintenance over the network from the 4341. One thing they wanted to know, would it be possible to load data from the CPU's floppy disk reader? They would initially be willing to have one tape drive which they move around as each of the 4331s are installed, but they would then like to get rid of it after that and rely on the network. Several other installations are starting to talk about going the same way (Univ. of Maine is considered a small installation). This question of remote mainenance may become very critical (possibly the most critical) for installations talking about 20, 30, 40 or more CPUs all being serviced from a central site. I would suggest that you find as many people as possible to start looking at it and networking in general before the next share. By comparison all the current activity with performance optimization by customers can be minimized by just ordering additional CPUs (if they can maintain them in a reasonable way).

re:
https://www.garlic.com/~lynn/2006y.html#20 moving on
above includes email in the post dated 26mar79
https://www.garlic.com/~lynn/2006y.html#email790326

The 4341 tests were on an early endicott engineering machine (E4 code name, delivered to disk test lab) that had some temporary patches that slowed it down compared to what production machine would be.

Following email from 2/20/79 mention customer talking about wanting to place an order for 70 such machines.

this old post
https://www.garlic.com/~lynn/2001m.html#15 Multics Nostalgia
includes email from 4apr79
https://www.garlic.com/~lynn/2001m.html#email790404

about air force data systems looking at 20 4341s ... but then six months later, the order had been increased to 210 (fall79).

Other recent posts mentioning orders of large numbers of 43xx machines
https://www.garlic.com/~lynn/2006p.html#34 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#39 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#11 What's a mainframe?
https://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#25 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?

Date: 02/12/79 13:01:01
From: wheeler

Following are times for floating point fortran job running identical CP&CMS (4341 does not have ECPS on)



                  158               3031              4341
Rain          45.64/47.42    |   37.03/37.77   |   36.21/37.57
Rain4         43.90/44.80    |   36.61/36.89   |   36.13/36.51

also times approx;
                    145                168                91
                 145 secs.           9.1 secs          6.77 secs

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

of course the following MVS 168-3 doesn't include the "capture ratio" information ... some discussion in this post
https://www.garlic.com/~lynn/2006x.html#19 Ranking of non-IBM mainframe builders?

Date: 02/12/79 21:36:29
From: wheeler

Do you know if the STL VM 168s have (or don't have) the high speed multiply feature?????

the 168-3 VM test number was taken from STLVM3

Following are times for floating point fortran job running identical CP&CMS (4341 does not have ECPS on). Command was 'LOAD XXXX (START' link-edit time included).


                  RAIN                  RAIN4

158      |     45.64/47.42     |     43.90/44.80
3031     |     37.03/37.77     |     36.41/36.89
4341     |     36.21/37.57     |     36.13/36.51
168-3    |      8.89/ 9.65     |      8.81/ 9.79

SJR MVS 168-3 with high speed multiply
PGM=          |         8.84        |         8.73
LOAD&GO   |         9.3         |         9.1

also times approx;
145                  168                91
145 SECS.           9.1 SECS          6.77 SECS

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

Date: 02/20/79 09:12:59
From: wheeler

Numbers fro Rain&Rain4 are virtual & total time (right off of CMS ready message). Only diff. between rain&rain4 is one does a lot of console output at intermediate steps. The job is fortran , extremely heavy on floating point operations. It comes by the way of the palo alto branch office. It was part of a bid proposal by the Lawrence Radiation Lab. in Livermore (with specs that it used 35.77 cpu secs. on a CDC6600).

VMA was turned on for all machines (but ECPS was not on the E4). The CPU numbers are nearly the same on 168-3 for VM, MVS, & SVS (all using FORTGI) so there is little operating system involved. (by the way, from another source a comment was attributed to the same lab. that if IBM had a 1 mip processor for under $300k, they would order 70 - thats right seventy).

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

This appears to be a case where somebody that had seen my numbers and had leaked them.

Date: 02/26/79 17:56:35
From: wheeler

has somebody else been doing a '1 fortran job' benchmark on the 4341? Electronic news for Feb. 20, 1979 quotes an IBM spokesman as saying based on 1 Fortran job, that it probably exceeds performance of a 3031 mainframe in running Fortran.

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

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Thu, 28 Dec 2006 06:46:40 -0700

jmfbahciv writes:
<snort> Then you don't know about general timesharing operating systems. Try to find posts (there aren't many) about real-time clocks.

misc. past posts mentioning vm-based commercial time-sharing service bureaus.
https://www.garlic.com/~lynn/submain.html#timeshare

recent post about needing instrumentation and measurement in order to implement dynamic adaptive resource management (requiring lots of timing facilities)
https://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?

i had done original implementation on cp67 while an undergraduate in the 60s. misc. collected posts
https://www.garlic.com/~lynn/subtopic.html#fairshare

things improved going from 360/67 to 370 which added TOD timer and a number of other hardware timing facilities. one of the first things i got to work on after joining the science center was participate in group trying to figure out how to handle "leap seconds" in connection with the 370 TOD timer.

moving on

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Thu, 28 Dec 2006 11:09:42 -0700

i.e. E4 was code name for 4341 ... production 4341 machine cycle will be speeded up by about 15 percent (compared to E4 I was benchmarking)

Date: 01/22/79 19:22:21
To: somebody in endicott
From: wheeler

Do you know anybody knowledgeable about running VM on E4??? GPD test lab just got one, we gen'ed release 5 VM to run on it. It seems to work alright, except the E4 seems to have some hardware (red lighting) problem with the interval timer. Hopefully that will be corrected shortly.

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

Date: 01/23/79 13:30:07
From: wheeler

I sent a message to Endicott saying that we had IPL'ed release 5 on the E4 and asking if anybody knew of any problems we would run into using release 5. I also mentioned that it red lighted when we 1st IPL'ed.

Endicott is now trying to answer the red light question. I got a call from XXXXX who designed it, asking questions and offering suggestions. He is calling YYYYY now to see if he can help any. It seems to have gotten a lot more complex than i had thot.

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

Date: 01/23/79 15:39:46
From: wheeler

Just tried Q SRM DSPSL on E4 , it comes out 23.5 compared to 24.1 on 3031 and 26.1 on a 158-3.

Engineers said this is early model with 'slow' internal clock. Clock will be speeded up at least by 1/7 which would bring DSPSL down to 20.0 or a little below. Box looks like an old fashion Freezer chest, only about 12 inches higher and 50 % longer.

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

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Fri, 29 Dec 2006 08:45:45 -0700

jmfbahciv writes:
With a general timesharing OS, both have to happen. Deciding which one, nested or serially, is the elegance of the OS. Consider TTY character interrupts. Warning: I'm using DEC lingo because I don't know any better. A ^C^C means stops everything for that user. An interrupt that should cause the exec to stop (unix calls this the kernel) is higher precedence than anything unless the data in core is more important (you don't create a graceful crash that reboots and clears memory).

I guess what I'm trying to say is that there can't be a hard and fast rule about the order which priorities are serviced. I probably could think of some scenarios where a lower priority should be dealt with before a higher priority. For a general timesharing OS, this has to a variable (set by the sysadmin?)

recent thread from comp.arch about terminal character processing. this is issue that heavy character-at-a-time echo placed on processing latency/response.

the original post was about supporting terminals at a really remote location and latency/response problems by doing character-at-a-time echo ... and attempting to do heavy optimization for handling.

initial response was a comment that block processing would have significantly helped the situation i.e. like block processing mode available in ascii 3101 glass tty ...
https://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?
https://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?
https://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?

the above posts then wander off into priority handling ... even with block mode processing ... there could still be all sorts of conditional situation. one of the posts in comp.arch mentioned that there has been a whole lot of work in linux kernel scheduling having to do with how X-window events are handled ... trying to promote at response w/o letting X actually run away with processing (and totally degrade other processing).

the general case was that there is a certain amount of human expectation with respect to events that might be considered interactive response ... and so should be given better execution priority for short period. one of the problems is that certain applications may be able to generate such a high-rate of "identified events" ... that even with each even getting only a small amount of high priority execution ... the frequency of the events allows the application to monopolize the processor.

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Fri, 29 Dec 2006 09:13:29 -0700

Greg Menke <gregm-xyzpdq3@toadmail.com> writes:
On that basis then "security" might involve accepting interrupts only from hardware that has a driver ready, and the drivers ensuring the hardware is actually asserting an interrupt before starting some I/O, and then verifying that the I/O parameters are within the specs of the device and conform to OS procedures. I'm not sure I'd call this security- the term being so general and confused these days.

this can sort of be considered in the light of availability and can wander over into DOS-attacks ... recent post about DOS-attacks and considering availability a characteristic of security (from the security "PAIN" acronym)
https://www.garlic.com/~lynn/aadsm26.htm#17 Changing the Mantra - RFC 4732 on rethinking DOS
original BLOG entry
https://financialcryptography.com/mt/archives/000844.html

i ran into it earlier when i rewrote the operating system i/o subsystem for the disk engineering and test labs (bldg. 14&15)
https://www.garlic.com/~lynn/subtopic.html#disk

they had tried running MVS on processors used for "testcell" testing (engineering and development devices) and MTBF was on the order of 15-minutes (crashes and/or hangs) ... and they had been doing the testing with machines in scheduled "stand alone" time (with simple, custom written stand-alone monitors).

i set out to rewrite the i/o subsystem (drivers, interrupt handlers, device scheduling, etc) to make it absolutely bullet-proof so that they could do testing of multi-concurrent testcells effectively "on demand" ... (instead of having to wait for their serially scheduled time). One of the issues required being able to fence off devices that were generating hot-interrupts (i.e. constant barrage of interrupts such that the operating system would be doing nothing else but processing that device's interrupts).

there is the security PAIN acronym
P ... privacy (sometimes CAIN and confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

availability can be considered an "integrity" attribute.

note that a lot of people doing security focus on using encryption to hide information (i.e. privacy/confidentiality).

an example is using SSL to hide payment card numbers ... frequently referred to as e-commerce ... old posts
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

so a lot of this is related to press about data breaches, security breaches, "identity theft", etc. ... and requiring more encryption for hiding "account numbers" as countermeasure to evesdropping, harvesting, skimming, etc, attacks
https://www.garlic.com/~lynn/subintegrity.html#harvest
and using the information in fraudulent transactions.
https://www.garlic.com/~lynn/subintegrity.html#fraud

... for a lot of security topic drift ... in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

so part of the analysis was the extreme dual requirements for account numbers ... one hand if account numbers were divulged, then they could be used in fraudulent transactions (so account numbers had to be kept strictly confidential and never divulged). on the other hand, account numbers are required in a large number of different business processes ... and as such they had to be readily available. this lead to the observation that the planet could be buried under miles of (information hiding) cryptography and still not prevent account number leakage.

for x9.59 transactions, effectively privacy is replaced with authentication and integrity (as countermeasure to fraudulent transactions) ... i.e. the account numbers can be openly divulged and fraudulent transactions would still not be possible. x9.59 not only is a countermeasure to skimming at point-of-sale and ATM terminals, but is also countermeasure to numerous data breaches and security breaches (i.e. it doesn't prevent the breaches, just eliminates the breaches as useful attack for fraudulent transactions).

this is somewhat related to old comments about security proporitional to risk
https://www.garlic.com/~lynn/2001h.html#61

or the posts about naked payments/transactions
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
https://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
https://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design
https://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
https://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
https://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
https://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
https://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007

moving on

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Fri, 29 Dec 2006 12:31:23 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
For relocate shared segment support, a shared segment may appear anywhere within a virtual machine's address space (it does not need to be at the position specified in the VMABLOK). The way I handled it in DMKVMA was to use the PTO pointers in the VMABLOK to check the shared segments, rather than using the segment index number to displace into the segment table and pick-up the STE.

One of the co-op students that helped me write the original shared segment support for release 2 VM (included the sub-set that is now in the product DCSS) is now with Interactive Data Corporation (IDC). They have taken the idea and put a whole group on expanding the idea. They now call it Floating segments (instead of relocating segments). They have a modified assembler for generating adcon free code and are working on the compilers. All this work they have done has greater significance than they realize. It would greatly simplify conversion to an increased address space size.

re:
https://www.garlic.com/~lynn/2006y.html#20 moving on
and specifically the old email from 26mar79
https://www.garlic.com/~lynn/2006y.html#email790326
and other posts in this thread
https://www.garlic.com/~lynn/2006y.html#21 moving on
https://www.garlic.com/~lynn/2006y.html#23 moving on

one of the big problems was that the original 370 virtual memory architecture included "segment protect" feature (i.e. turn on a bit in segment table entry for a specific virtual address space ... and everything in that segment became read/only for that address space).

the cp67 to vm370 morph of cms was somewhat structured around having that feature. i've posted before how the retrofit of virtual memory hardware to 370/165 ran into schedule problems and they dropped a number of features from the 370 virtual memory architecture to buy back six months in the schedule (and then made all other processors drop them also, so that there was compatibility across the 370 line).

this resulted in forcing vm370 to revert to the cp67 convention of protecting shared pages ... which played games with storage protect keys. this resulted in addition vm370 overhead for cms ... but a little later also met that VMA (virtual machine assist) microcode performance enhancements couldn't be used with shared-system CMS (VMA implemenation of storage key operations didn't know the rules for protecting shared segment pages).

preparing for vm370 release 3 ... somebody came up with a hack that would allow VMA to be used with CMS ... the storage key game was eliminated and instead the currently running CMS would be allowed to modify shared pages (as well as being able to run with VMA turned on). however before switching to a different process, the dispatcher would scan all shared pages ... searching for ones that had been changed. If any were found ... they were discarded (and new process requiring discarded shared page would have an unmodified copy refreshed from disk). The trade-off of reduced overhead being able to use VMA tended to offset the increased overhead that the dispatcher had to scan 16 shared pages on (nearly) every process switch.

then it was also decided to pick up a very small subset of my virtual memory management support (both cp and cms changes) as DCSS for release 3
https://www.garlic.com/~lynn/submain.html#mmap
https://www.garlic.com/~lynn/submain.html#adcon

this initially resulted in at least doubling the typical number of shared pages from 16 to 32. However, the overhead of the dispatcher scanning of 32 shared pages (on every process switch) changed the overhead trade-off vis-a-vis overhead reduction being able to use VMA. Somebody then decided they had to go with the change page scanning hack anyway ... since CMS intensive customers had already been told that they would get performance benefit in vm370 release 3 with using VMA.

This was further aggravated when developing multiprocessor support that would be shipped in vm370 release 4. The change in release 3 for scanning for changed shared pages was predicated on a single process having exclusive access to the shared pages at a time. With multi-processer support, there could be multiple, concurrent running processes. To preserve the "exclusive access" assumption, it was then necessary to have processor specific copies of shared pages. Now, not only did the dispatcher have to scan (an increasing number of) shared pages for changes (on nearly every task switch) ... but it also had to make sure that the "switched-to" process had its (virtual address) segment table entries pointed to the processor specific shared segments. Now, things were getting entirely out of control.

Another issue that had come up was that the original relational/sql, system/r had been developed on vm370 and was taking advantage of more sophisticated virtual memory support. One of the things allowed some processes address spaces to have r/w shared access to a shared segments while other processes had only r/o shared access
https://www.garlic.com/~lynn/submain.html#systemr
it was referred to as DWSS in the technology transfer effort from SJR to Endicott for what became SQL/DS. few recent posts mentioning DWSS
https://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#11 long ago and far away, vm370 from early/mid 70s

Futhermore, the processing load on the US HONE system was increasing and they were upgrading their 370/168s to multiprocessors ... HONE was vm370 based infrastructure that provided world-wide support to marketing, sales, and field people.
https://www.garlic.com/~lynn/subtopic.html#hone

HONE was doing this 6-9 months before release 4 (and official multiprocessor support) was going to be available.

As i had been involved in a lot of the multiprocessor support
https://www.garlic.com/~lynn/subtopic.html#smp
https://www.garlic.com/~lynn/submain.html#bounce

I undertook to build a version of multiprocessor support on their production vm370 release 3; which i had already heavily modified. While, I was doing that, I went ahead and put in the code to revert to protection games with storage keys (eliminating needing to have unique shared page copies for every processor) that had existed in cp67 and in vm370 prior to release 3.

for a little drift, pieces of recent thread in comp.arch on virtual address space mappings
https://www.garlic.com/~lynn/2006w.html#23 Multiple mappings
https://www.garlic.com/~lynn/2006x.html#23 Multiple mappings
https://www.garlic.com/~lynn/2006x.html#26 Multiple mappings
https://www.garlic.com/~lynn/2006y.html#11 Multiple mappings

"The Elements of Programming Style"

Refed: **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sat, 30 Dec 2006 08:24:14 -0700

jmfbahciv writes:
No child is supposed to get ahead; each child is supposed to learn the basics: reading, writing, and arithmetic plus all the rest of the stuff. Without the first three, there isn't any point trying to teach the rest of the stuff because nobody can read aobut the stuff, write about it, nor check if it adds up.

... from long ago and far away ...

Date: 05/06/81 13:32:55
From: wheeler
re: competence; from ACM Sigsoft, vol 6 #1, January 1981, page 5

The trouble is that programming became an industrial activity at a moment (see, for instance, William H. Whyte, "The Organization Man") that the prevailing management philosophy aimed at making companies as independent as possible of the competence of their employees. Needless to say, this gave American industrial programming a very false start.

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

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sat, 30 Dec 2006 08:35:30 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
... from long ago and far away ...

Date: 05/06/81 13:32:55
From: wheeler

re: competence; from ACM Sigsoft, vol 6 #1, January 1981, page 5

The trouble is that programming became an industrial activity at a moment (see, for instance, William H. Whyte, "The Organization Man") that the prevailing management philosophy aimed at making companies as independent as possible of the competence of their employees. Needless to say, this gave American industrial programming a very false start.

...

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

re:
https://www.garlic.com/~lynn/2006y.html#27 "The Elements of Programming Style"

somewhat apropos Boyd reference here:
https://www.garlic.com/~lynn/2000e.html#35 War, Chaos, & Business (web site), or Col John Boyd

... and, also forgot past posts mentioning Boyd's observation about american corporation and rigid, top-down control infrastructures assuming minimum competence of the employees (supposedly outcome of officer training in ww2):
https://www.garlic.com/~lynn/2001m.html#16 mainframe question
https://www.garlic.com/~lynn/2002d.html#38 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2003c.html#65 Dijkstra on "The End of Computing Science"
https://www.garlic.com/~lynn/2003e.html#21 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003h.html#51 employee motivation & executive compensation
https://www.garlic.com/~lynn/2003p.html#27 The BASIC Variations
https://www.garlic.com/~lynn/2004k.html#24 Timeless Classics of Software Engineering
https://www.garlic.com/~lynn/2004l.html#11 I am an ageing techy, expert on everything. Let me explain the
https://www.garlic.com/~lynn/2004l.html#34 I am an ageing techy, expert on everything. Let me explain the
https://www.garlic.com/~lynn/2004q.html#86 Organizations with two or more Managers
https://www.garlic.com/~lynn/2005e.html#3 Computerworld Article: Dress for Success?

.... general collection mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
... and various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sat, 30 Dec 2006 11:56:24 -0700

Justa Lurker <JustaLurker@att.net> writes:
The 'PC' platform has put useful computing power in the hands of millions more people and organizations than your beloved PDP-10, Lynn's beloved VM/CMS, etc. ever did or could have. Those were fine systems in their own right, but like fishing stories and old girlfriends, recollections and perceptions automagically improve with age.

cms was personal computing of 60s, 70s, and well into 80s.

note that it helps that references are from actual email from the period ... some collected refs
https://www.garlic.com/~lynn/lhwemail.html

43xx-series machines with vm/cms moved into same mid-range market segment as vax/vms (although there were more 43xx machines than vax machines).

there was some attempt to do a cms-like implementation on PCs in the early 80s ... as well as straight vm/cms as xt/370 ... both the cms-like and xt/370 suffered greatly on the PC platforms in the early to mid-80s. cms-like and xt/370 tended to be much more disk intensive than the PC applications of the period ... and the disks were 10-20 times slower than their mainframe counterparts. the interactive pc applications of the period were usually carefully tailored to the available PC resources/hardware. as a result, cms-like and xt/370 genre failed to catch on (although some number of the cms personal applications were rewritten for pc environment and found uptake).

as of posted before ... especially the vax ship numbers ... sliced and diced by model, year, us, non-us, etc ... the workstations and large PCs eventually did move upstream in the later 80s and start to take over the mid-range.

also as posted before ... a larg part of the early uptake of PCs were that businesses could get a PC for about the same price as a mainframe 3270 terminal ... and have a single desk footprint providing both 3270 terminal emulation as well as some local computing.

the 3270 terminal communication operation eventually acquired a big install base of 3270-emulation communication products.
https://www.garlic.com/~lynn/subnetwork.html#emulation

in hsdt, we had done a lot of work on client/server
https://www.garlic.com/~lynn/subnetwork.html#hsdt

as well as moving into 3-tier architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier

... in addition to a lot of work on high-speed backbone and nsfnet backbone ... a couple posts
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006w.html#43 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)

however, the communication operation big install base that they had to protect was all oriented around 3270 terminal emulation ... and definitly not client/server, peer-to-peer networking, 3-tier, etc. this gave rise to quite a bit of strife with projects that wanted to move beyond 3270 terminal emulation paradigm.

things like our activities with NSFNET backbone being curtailed and an attempt to substitute sna/vtam proposals.
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
somewhat related
https://www.garlic.com/~lynn/2006x.html#8 vmshare

as well as when my wife was doing stint as amadeus chief architect and chose x.25 over sna ... there were successful lobby that got her removed from the position
https://www.garlic.com/~lynn/2006y.html#14 Why so little parallelism?

I actually participated in a group located on the west coast that was going to produce software for the PC ... this was before PC was announced and Boca was claiming that they were only doing hardware and we could have the software responsibility. However before announcement they changed their mind and took over responsibility for software ... but as it was getting late in the game, this somewhat contributed to them having to go to outside organizations to contract for software (the advantage ... from internal corporate politics standpoint was that they were still "responsible" for software and it wasn't the responsibility of another corporate organization).

I even have some amount of PC software from the 80s ... recent thread (although there are still quite a few floppies that i haven't been able to recover)
https://www.garlic.com/~lynn/2006s.html#35 Turbo C 1.5 (1987)
https://www.garlic.com/~lynn/2006s.html#36 Turbo C 1.5 (1987)
https://www.garlic.com/~lynn/2006s.html#37 Turbo C 1.5 (1987)
https://www.garlic.com/~lynn/2006s.html#56 Turbo C 1.5 (1987)
https://www.garlic.com/~lynn/2006s.html#57 Turbo C 1.5 (1987)

misc. past posts mentioning acorn (product code name before announce):
https://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2003c.html#31 difference between itanium and alpha
https://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#19 PC history, was PDP10 and RISC
https://www.garlic.com/~lynn/2003e.html#16 unix
https://www.garlic.com/~lynn/2005q.html#24 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006k.html#48 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006o.html#45 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sat, 30 Dec 2006 12:08:00 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
there was some attempt to do a cms-like implementation on PCs in the early 80s ... as well as straight vm/cms as xt/370 ... both the cms-like and xt/370 suffered greatly on the PC platforms in the early to mid-80s. cms-like and xt/370 tended to be much more disk intensive than the PC applications of the period ... and the disks were 10-20 times slower than their mainframe counterparts. the interactive pc applications of the period were usually carefully tailored to the available PC resources/hardware. as a result, cms-like and xt/370 genre failed to catch on (although some number of the cms personal applications were rewritten for pc environment and found uptake).

re:
https://www.garlic.com/~lynn/2006y.html#0 "The Elements of Programming Style"

slightly related ... reference to an advance technology conference that I put on the spring of '82 ... attempting to get support and funding for programming technology project that would do a cms-like infrastructure from scratch ... that was better tailored to some of the emerging processor technology (and provide some degree of portability):
https://www.garlic.com/~lynn/96.html#4a

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sat, 30 Dec 2006 13:27:25 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
slightly related ... reference to an advance technology conference that I put on the spring of '82 ... attempting to get support and funding for programming technology project that would do a cms-like infrastructure from scratch ... that was better tailored to some of the emerging processor technology (and provide some degree of portability):
https://www.garlic.com/~lynn/96.html#4a

and a little more drift from one of the presentation at advanced technology conference was DataHub ... a network fileserver. from long ago and far away

From: 11/16/81 13:04:39
To: wheeler

Hi!

I'd like copies of the small CMS stuff, and any info you can share on the Unix for CMS meeting -- as you know, we're looking at using some Unix-like design and/or operators in the design of the DataHub.

Otherwise, things were pretty quiet while you were away -- as in, the system was often VERY quiet.

Good to have you back. Stop over some time tomorrow if you can.

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

Part of the work on DataHub was be done in work-for-hire contract with an organization in Provo. After the DataHub project was canceled, the group in Provo was allowed to retain what they had produced.

and a little 3101 block mode and acorn cross-over i.e. 3101 block mode emulation on acorn over ascii lines (before 3270 coax adapter for acorn)

Date: 08/20/81 10:55:54
To: wheeler

Lynn:

re:acorn. Piece of s/w boeing and others would like is a 3101 block mode support package so they can use new iup for pvm to get 3270 simulation w/o series/1. Is it reasonable to assume that's in the works? Boeing is ordering both early personal computers and the pvm package so I hope they'll be able to tie them together somehow. Should I volunteer to write it?

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

recent posts mentioning 3101 block mode:
https://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?
https://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?
https://www.garlic.com/~lynn/2006y.html#24 "The Elements of Programming Style"

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sat, 30 Dec 2006 14:01:20 -0700

Andrew Swallow <am.swallow@btopenworld.com> writes:
So are several realtime operating systems such as RTOS.
http://www.onesmartclick.com/rtos/rtos.html

the author of vnet ... many years later was working for a contractor dealing with one of the realtime operating systems. he claimed to have recognized some code ... and checking old "MSUP" (from core of VNET) listing, recognized almost a line-for-line translation from 370 assembler to C ... including the same/original comments.

misc. collected postings mentioning vnet and/or internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

and the original vnet was also the basis for bitnet/earn ... misc. collected postings mentioning bitnet &/or earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sun, 31 Dec 2006 07:10:57 -0700

jmfbahciv writes:
Carnegie didn't have to buy his influence.

there has been PBS advertisements for program on the great Robber Barons (i have vague recollection of reading book by that name in high school) and when they had amassed their great wealth ... they used part of it for bribing legislatures (although i believe in some cases the bribing of legislatures starter earlier and aided them amassing the wealth, also some of the bribing may have included executive and judiciary branches of gov).

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sun, 31 Dec 2006 09:01:08 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
i ran into it earlier when i rewrote the operating system i/o subsystem for the disk engineering and test labs (bldg. 14&15)
https://www.garlic.com/~lynn/subtopic.html#disk

re:
https://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"

for a little cross-over between the operating system work for the san jose engineering and test labs ... some old email about HSDT (high speed data transport) project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

and high-speed backbone with T1 (and faster) connections.

It also references the work I had done for the san jose engineering labs, rewriting i/o supervisor to make it bullet-proof so they could provide on-demand, concurrent testing in an operating system environment.
https://www.garlic.com/~lynn/subtopic.html#disk

and other general posts mentioning the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

Date: 11/21/84 08:29:38
From: wheeler

re: hsdt; got a new candidate for hsdt internally within IBM. Got a call yesterday from a ISTG staff guy asking questions about remote testing. Apparently call was based on work done to get the stand-alone DASD test cell environment converted to run under VM. He was looking at expanding the availability of the engineering environment to the software device support organizations (letting POK & KGN programmers work on San Jose engineering machines). I reference the I/O reliability paper that I wrote and the jointly authored paper on VM In The Enginneering Labs. I have also had some experience in the past trying to interest the KGN organization in testing device support remotely ... but it never got very far.

HSDT may make the difference ... especially if we can integrate the video so not only do we have fast interactive response, fast transfer of bulk data (like detailed program &/or event traces), but also facilities so that the programmers can effectively consult with the engineers.

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

some recent comments about also doing work on high-speed backbone for NSFNET
https://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)
https://www.garlic.com/~lynn/2006y.html#6 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#29 "The Elements of Programming Style"

The Future of CPUs: What's After Multi-Core?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Sun, 31 Dec 2006 09:17:38 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

https://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core
https://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?

lots of collected posts mentioning (global) page replacement
https://www.garlic.com/~lynn/subtopic.html#wsclock

re:
https://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?

and even more email archeology ... mentioning both general caching strategies as well as global LRU beating partitioned/local LRU strategies

Date: 11/14/84 14:19:35
To: wheeler

Lynn ... Thanks for your response. What I am interested is in the use of a partition of very large memory for emulation of disk space (main frames) for present day nonpaging IO. Whatever is proposed must be rather quick and dirty without imposing a large progamming load onto Kingston. Is what I am saying making any sense? I tried calling a few minutes ago but you were away from your phone.

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

The above was a significantly simplified suggestion ... not actually using large processor memory for dynamic filesystem cache ... but actually reserving static amount of memory ... much more like PC virtual disks (it was relatively straight-forward to use my memory mapped enhancement to cms filesystem to implement either).

Besides using large real (processor) memory for file cache ... the following references the use of disk controller cache (ironwood was code name for 3880-11 disk controller cache with 8mbytes of 4k-byte record cache).

in loosely-coupled environment ... multiple processor complexes having access to shared disks ... individual complexes might do local ordered seek queues ... but with multiple such processors with activities ... the result at the disk arm might actually be random.

Date: 11/14/84 21:13:06
From: wheeler

i will be sending you the 3880-11 cache memo discussion from quite awhile ago ... you might also be interested in contacting XXXXXX for copies of the various PAM file system on ironwood papers. We have said for a long time that page cache type devices not only make nice file system device ... but also provides common ordered arm seek queueing mechanism for shared dasd in multiple cpu environment (... also see discussion on same subject in vmperf script, vm historical paper).

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

PAM involved enhancements to CMS file system(s) to support memory mapped implementation
https://www.garlic.com/~lynn/submain.html#mmap

"DASD" is direct access storage device ... term originally came into use when there were a variety of devices, drums, 2321/datacell, as well as disks.

FBA is fixed-block architecture ... originally introduced in the late 70s with 3310s and 3370s.

Date: 11/20/84 08:03:55
From: wheeler

re: pam extensions; one of the biggest benefits is to make better use of real storage for caching DASD records ... and a PAM implementation more naturally extends in that direction. If you look at UNIX, it gets two big performance boosts from its use of real storage

with a common file system using an FBA (or PAM) like architecture, the supervisor can LRU-cache file records in storage ... some installations have 1/3 of all real storage reserved for the DASD cache.

PIPEs in unix provide a direct real storage buffer for passing data between programs w/o having to resort to temporary data sets on DASD.

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

With the current & planned extensions in real storage sizes ... and the growing discrepancy between CPU speed & DASD access times ... a number of things like you have mentioned need to be done to maximize program use of real storage, while minimizing number of times the system has to resort to doing (real) DASD I/O.

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

We had added a new facility to the SJR/VM in 1979 (module DMKCOL) enabling capturing all disk record accesses. This information was then used in modeling various kinds of caching strategies. It was run on a number of systems in the san jose area (including some having batch operating systems running in virtual machine).

One of the findings was that a system global cache (i.e. with global LRU replacement policy) outperformed any partitioned cache strategry (aka effectively local LRU replacement strategy) ... where the aggregate amount of electronic cache was the same in the two cases.

One of the other pieces of information that started to emerge from the modeling work was finding some amount of meta-activity ... that specific collections of records were frequently accessed in longer term cyclic pattern (once-a-day, weekly, monthly, etc). This started to have implications as CMSBACK morphed and added much more sophisticated filesystem management strategies.

some work was also done about being able to use the real-time capture characteristic of DMKCOL to aid with real-time record allocation.

=====

=====

Multiple mappings

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple mappings
Newsgroups: comp.arch
Date: Sun, 31 Dec 2006 10:27:34 -0700

"mike" <mike@mike.net> writes:
Your recollection matches my understanding. Further as Del said the recovery time problem has been overcome by implementing journaling of index structures.

that is also what aix did ... using 801 database memory ... or that is what somebody called it in the late 70s. this was in transition from romp (pc/rt) & aixv2 to rios (rs/6000) and aixv3 ... I believe a descendent has since been provided as open-source ... JFS (journal file system).

we took advantage of it for fast-restart when we did ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp

note, however, when we were doing ha/cmp we also worked on distributed operation, coining the terms disaster survivability and geographic survivability (to differentiate from disaster/recovery). based on that work I was asked to write a section in the corporations continuous availability strategy document.
https://www.garlic.com/~lynn/submain.html#available

both rochester and pok both objected (and the section was deleted) ... basically at the time, they weren't able to meet the objectives.

misc. past posts mentioning 801, romp, rios, fort knox, etc
https://www.garlic.com/~lynn/subtopic.html#801

for some topic drift ... an old email mentioning attempting to address "multiple mappings"

following is about simulating shared segments that were different size than the 801/ROMP segment register flavor (sixteen 256mbyte segments using 801 segment register ID).

Date: 11/14/84 11:02:38
From: wheeler

re: romp small shared segments;

we've pretty much gone thru the design, how/why system would use it, and several scenerios on doing it. we are waiting rosetta specs so as to nail down outstanding questions about whether it actually all works.

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

Date: 11/27/84
To: wheeler

Lynn,

I sent XXXXXX a copy of the TLB reload procedure for ROMP---- we are using basically the same procedure in ROMP-E except some of the registers (segment regs.) will be addressed directly with new CPU instructions rather than the programmed I/O read/write instructions. I will send you a copy of the full address allocation for the TLB, cache, etc. of ROMP-E in a few days. If this is not sufficient, let me know.

Thanks for your effort in resolving the synonym issue.

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

and slight topic drift from another post
https://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
and old email
https://www.garlic.com/~lynn/2006u.html#email830420

... the issue in this thread was possibly using 801 for running both 801 native applications as well as (emulated) 370 applications potentially having shared access to common "shared segments". the issue was that 801 "shared segment" granularity was 256mbyte ... & in a 32bit virtual address space ... only allowed for a maximum of 16. the issue was how to fiddle the TLB to emulate a much larger number of smaller sized shared segments.

.... and drifting back to JFS and journal/database memory .... there was some contention about whether it was more efficient to do explicit logging/journalling operations or rely on the 801 hardware support. eventually palo alto did a JFS implementation motivated wanted to have portable version (386 and other processors). they were able to demonstrate that JFS with explicit logging/journalling operations was more efficient running on the same RS/6000 than original AIX JFS utilizing the special hardware.

"The Elements of Programming Style"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sun, 31 Dec 2006 12:34:42 -0700

Larry Elmore <ljelmore@verizon.spammenot.net> writes:
Why? I didn't say no taxes. I may have been unclear. It's not like separation of government and religion actually means that there's *no* intersection between the two, just that the (US) government can't intervene to favor one over another. Just as a crazy thought experiment, why couldn't government be separated further from the economy than it is currently, and be forbidden from favoring one business or industry over another? Taxes are necessary, but are all the loopholes, exemptions, special rates or rebates necessary? Or all the regulations that have been bought mostly to raise the bar to compete in a given market, effectively stifling smaller competition? Or the policies to "help" a segment of industry that's lobbied (bribed) more effectively than another? All of that is a large drag on the economy and serves mostly to line the pockets of a privileged few. It's just a thought. What's considered corruption today was just ordinary business not all that long ago. Much of what's considered normal business today might be seen in a far different light a century from now.

re:
https://www.garlic.com/~lynn/2006y.html#33 "The Elements of Programming Style"

wasn't that somewhat forbes platform for flat rate tax ... legislation with regard to taxes is eliminated, legislative bodies considering tax legislation is therefor eliminated ... which in turn has been claimed to be the majority of the (financial) motivation behind lobbyist and reasons for influencing legislatures.

that is independent of the whole segment of economy that is devoted to dealing with tax codes ... which is considered to be non-productive contribution/drain on overall society.

Wanted: info on old Unisys boxen

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wanted: info on old Unisys boxen
Newsgroups: alt.folklore.computers
Date: Sun, 31 Dec 2006 12:54:42 -0700

"Tarkin" <Tarkin000@gmail.com> writes:
Mainframes sound like a lot of fun in their own right.

The U-series remains a bit of mystery to nearly everyone, I'm afraid- except the fine folks at KMart. Which gives me a bit of an idea- I just may go to the source, and see if I can get some info there, if Usenet doesn't work out.

weren't (at least some of) the u-series the rebranded sequent boxes? i've seen reference to u-series being unisys 68k unix boxes ... but weren't the unisys rebranded sequent boxes also labeled as u-series?

of course when IBM bought sequent ... unisys was possibly forced to adopt some other platform.

sequent did numaq with SCI (scalable coherent interface) ... we did some consulting to sequent after leaving IBM (and before sequent was bought by IBM). SCI had 64-port . convex exemplar was 64 boards with two HP risc processors per board. Sequent (and data general) did SCI implementation with 64 boards with four intel processor per board (for 256 processor configuration).

later on in this time-frame (before the ibm purchase), Steve Chen was CTO at sequent. a recent posts mentioning steve chen:
https://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article?
https://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006v.html#12 Steve Chen Making China's Supercomputer Grid

Multiple mappings

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple mappings
Newsgroups: comp.arch
Date: Sun, 31 Dec 2006 13:12:10 -0700

"Peter \"Firefly\" Lund" <firefly@diku.dk> writes:
It was mostly a problem of too frequent crossings of protection level barriers. Moving some of the code across such a barrier cut down the frequency of crossings. Such crossings tend to be costly no matter the architecture.

MVS attempted to address this with access registers and program call(/return) ... program call instruction referenced hardware table that had rules for switching around various address space pointers ... w/o having to take a kernel interrupt to have software perform all the operations.

long post that discusses several characteristics of virtual memory management ... but eventually gets around to referencing support for accessing multiple different virtual address spaces concurrently ... as well as URLs pointing to the architecture description of the facility as well as detailed description of instruction operation
https://www.garlic.com/~lynn/2006i.html#33 virtual memory

original access register and program call operation was hierarchical but subsequently expanded to allow for non-hierarchical definitions.

a few other recent posts discussing access registers and program call instruction
https://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
https://www.garlic.com/~lynn/2006r.html#8 should program call stack grow upward or downwards?
https://www.garlic.com/~lynn/2006s.html#8 Google launches search engine for finding source code
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
https://www.garlic.com/~lynn/2006x.html#23 Multiple mappings
https://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"

there are some multi-address hardware issues with TLBs. the first foray was dual-address space mode initially implemented on 3033 (subset of multiple address space mode later part of access register implemention). basically TLB was "STO-associative" ... i.e. virtual address space identification was done with the origin real address of the virtual address space table (segment table origin). Each TLB entry was tagged with 3-bit "STO-id", an unassociated entry or associated with one of the seven entries in the TLB STO-stack. The initial introduction of dual-address space mode resulted in some hardware degradation because of increased thrashing in the TLB STO-stack.

Multiple mappings

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple mappings
Newsgroups: comp.arch
Date: Sun, 31 Dec 2006 14:53:35 -0700

"mike" <mike@mike.net> writes:
Lynn,

As I am sure you know the S/38 needed a lot of tuning when it first came out. Over time file processing got a lot more efficient. The system now understands the difference between sequential and random processing and does block loads of N pages where appropriate. It also runs look-ahead threads to overlap file retrieval with processing which even accelerates random file processing. Further it knows to load a whole program rather than just 4k on first reference or after a long wait. The system is still not as efficient as S/360 and its children for big batch file processing but it isn't bad and the path length for conversational applications is actually pretty good.

One great thing about the single level store is that code is never ever relocated in the virtual address space. This simplifies many issues for both kernel and user code.

re:
https://www.garlic.com/~lynn/2006x.html#26 Multiple mappings

I have much less historical perspective on evolution of various as/400 features ... however, i wouldn't be surprised if a number of enhancements showed up after the transition of as/400 to power/pc platform, where there was now effectively A/B comparisons of as/400 and AIX on the same power/pc processors (since aix already had several of the performance and filesystem journalling features dating at least from aixv3 and its implemenation on original rs/6000 with rios/power).

other posts in this thread:
https://www.garlic.com/~lynn/2006x.html#23 Multiple mappings
https://www.garlic.com/~lynn/2006y.html#11 Multiple mappings

I did have a run in a couple years ago looking at as/400 platform configured for certified C2 security operation ... and the "performance" degradation (for C2 security operation) appeared to be significantly larger than the equivalent performance degradation configuring AIX for C2 security operation (using essentially the same hardware).

for other drift ... the synonym & "small shared segments" issue mentioned here
https://www.garlic.com/~lynn/2006y.html#36 Multiple mappings

is with respect to 801 TLB entry operation.

this post talks about mainframes and address space associtive TLBs
https://www.garlic.com/~lynn/2006y.html#39 Multiple mappings

ROMP/810 had inverted tables and 16 segment table registers. This was somewhat designed for a proprietary, closed environment somewhat oriented towards having a single virtual address space ... and a segment table register would be used to address 256mbyte segment "windows" (within a 32bit addressing environment). In the closed environment, segment table registers could be changed as easily as general and/or addressing registers can be changed. ROMP defined a 12bit segment id ... allowing for 4096 unique segments.

This sort of gave rise to some common descriptions that ROMP/801 had a 40-bit virtual address (12bit segment identifier plus 28bit segment displacement for 40bits). TLB entries were identified with the 12bit segment identifier plus the 14bit (4k) page number (within a 256mbyte segment) ... making the TLB entry a virtual "segment-associative" implementation. This sort of corresponds to the 3033 description with a 7-entry TLB sto-stack (potentially with a arbitrarily larger number of STOs or different virtual address spaces) and the TLB entry being tagged with the TLB sto-stack number ... and therefor STO (or virtual address space) associative.

When the original ROMP/801 product was killed and the decision was made to retarget ROMP to unix workstation market ... A unique unix virtual address space could be created by associating 16 unique (ROMP) segment numbers with each unique unix address space ... giving 4096/16=256 possible unique simulated virtual address spaces.

For RIOS, the number of bits in the segment identifier was doubled from 12 to 24 ... somewhat given rise to early RIOS/POWER references having 52bit virtual address (24 bit virtual segment identifier plus 28bit segment displacement virtual address) ... even tho the actual processor addressing was still only 32bits. This also would give 2**24/16=2**20 possible unique simulated virtual address spaces.

For "real" 801 shared segments ... the same segment identifier would be loaded into the segment register across different simulated virtual address spaces. Regardless of which simulated virtual address space you were running in, the TLB entry for a page in a (801) "shared segment" would be the same (since the segment identifier for the shared segment would be the same in all the simulated virtual address spaces).

The problem with simulation of "small shared segments" ... was that different segment identifiers (associated with different simulated virtual address spaces) would have pages that pointed to the same real page. As a result there could be multiple TLB entries pointing to the same real page (i.e. the same real page could have TLB "synonyms"). If that real page was ever selected for replacement, all TLB (synonym) entries that pointed at that (same) real page needed to be invalidated.

It wasn't possible to use the same (801) segment identifier in every simulated (unix or other) virtual address space ... since different processes (and their corresponding virtual address space definitions) could have defined different subsets of the possible "small shared segments".

various past posts mentioning 801, romp, rios, power/pc, somerset, fort knox, etc
https://www.garlic.com/~lynn/subtopic.html#801

The original 370 mainframe virtual memory architecture allowed for (TLB) implementations that were either STO-associative (virtual address space associative) or PTO-associative (virtual segment associative). The original architecture also defined a number of instructions and features that were dropped before announcement and first customer ship (of 370 virtual memory support) ... there were schedule problems attempting to retrofit virtual memory hardware support to 360/165 ... recent post discussing some of this
https://www.garlic.com/~lynn/2006y.html#26 moving on

One of the dropped instructions was IPTE ... "invalidate page table entry". In a STO-associative (virtual address space) environment ... there could be multiple TLB entry synonyms pointing to the same real address (even if there was only a single PTE pointing to that real page ... where the same page table had pointers from multiple different address space tables). In such a situation, all possible TLB entries (associated with the same PTE) would have to be found and invalidated.

Wanted: info on old Unisys boxen

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wanted: info on old Unisys boxen
Newsgroups: alt.folklore.computers
Date: Sun, 31 Dec 2006 15:23:58 -0700

Leif Harcke <lharcke@stanfordalumni.org> writes:
Some of the series were Sequent, but the U 6000/30 and U 6000/50 series boxes were from the Network Systems Division in San Jose, CA, formerly known as Convergent Technologies Corp., which Unisys acquired in 1988.

re:
https://www.garlic.com/~lynn/2006y.html#38 Wanted: info on old Unisys boxen

other convergent background:
https://en.wikipedia.org/wiki/Convergent_Technologies_(Unisys)

the Sequent entry:
https://en.wikipedia.org/wiki/Sequent_Computer_Systems

and to round it out, Unisys:
https://en.wikipedia.org/wiki/Unisys

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sun, 31 Dec 2006 16:09:02 -0700

Peter Flass <Peter_Flass@Yahoo.com> writes:
I can't believe how much code today is still uncommented. The justification used to be disk space, as good commenting can easily double or more the size of the source. There's no excuse now except laziness.

when source was fixed-length records (especially in the days of card images ... that included sequence numbers at the end of the record)... there was never really an excuse to have at least some comment on every instruction line (i.e. otherwise the space between the end of the statement/instruction and the sequence numbers was all blank and took same amount of space) ... detailed narrative that required additional records then typically was a relative minor additional issue.

Remote Tape drives

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Remote Tape drives
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 31 Dec 2006 20:36:12 -0700

edgould1948@ibm-main.lst (Ed Gould) writes:
I have been exposed to two different "channel extenders" over the years. Of the two each had its own weaknesses. I won't talk about brand names other than to say they were from different parts of the US. The first (and second) seemed to drive IOS nuts and they were guilty of various errors which at least a few times brought the system down (these were attached to either a 4341 or a 168 (& 3033)). I had IBM ask me to strip out their logrec errors of the report as the number of errors at times amounted to several hundred a day.

Yes the damn things worked (sort of kind of) but the error recovery took its toll on MVS. The devices they had at the other end had response time issues which were hard to pin down as to where the issue was. The error recovery was part of issue of course but other items just kept on cropping up and (at times) it was a part time sysprog to baby sit the various issues.

recent posting about doing channel extender installation in 1980, when STL (now silicon valley lab) was bursting at the seams and needed to move 300 (IMS) to offsite bldg.
https://www.garlic.com/~lynn/2006y.html#3 The Future of of CPUs: What's After Multi-core

one of the things i did was choose to reflect "channel check" when i got unrecoverable error (some number from the T1 link). that decision eventually propagated into a number of different implementations supporting the same hardware.

this showed up as a problem early in the 3090 product cycle. after first year, 3090 product manager contacted me claiming that the 3090 customer machines erep was showing an "unnatural" number of channel checks. 3090 was designed to have something like 3-5 total, aggregate, channel checks for the first year across all installed 3090s. erep reports had turned up something like 20 total channel checks.

after some investigation, i determined that IFCC (interface control checks) would result in the same error recovery process (as reflecting channel check).

installation supported channel attached 3270 controllers, printers, and tapes. didn't support CKD DASD ... because of timing dependent problems with search arguments.

later the vendor introduced enhanced "remote device adapter" that addressed the timing problem with CKD search arguments. You saw this show up at installations like NCAR ... besides supporting ibm mainframe channel extension it also supported a number of other vendor processors. the NCAR installation sort of used an ibm mainframe system as a hierarchical filesystem control infrastructure ... for other processors (like Crays) directly doing i/o to CKD disks (sort of the original SAN implementation).

this particular vendor eventually was purchased by STK.

previous, next, index - home