List of Archived Posts

2005 Newsgroup Postings (09/30 - 10/13)

Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
The 8008
OS's with loadable filesystem support?
What ever happened to Tandem and NonStop OS ?
What ever happened to Tandem and NonStop OS ?
DDJ Article on "Secure" Dongle
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Is a Hurricane about to hit IBM ?
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
SATA woes
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
z/VM Listserv?
z/VM Listserv?
OS's with loadable filesystem support?
What ever happened to Tandem and NonStop OS ?
PCI audit compliance
VM tape definitions
transactional memory question
Intel strikes back with a parallel x86 design
Job seperators
File path formats
Symbols vs letters as passphrase?
How does the internet really look like ?
The 8008
logical block addressing
X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
IEH/IEB/... names?
What ever happened to Tandem and NonStop OS ?
IEH/IEB/... names?
winscape?
winscape?
Numa-Q Information
What ever happened to Tandem and NonStop OS ?
Password Requirements - VM:Secure
Numa-Q Information
MVCIN instruction
winscape?
MVCIN instruction
winscape?
winscape?
Go-Back-N protocol?
Password Requirements - VM:Secure
NEW USA FFIES Guidance
IBM 3330

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch
Date: Fri, 30 Sep 2005 17:37:36 -0600
"Stephen Fuld" writes:
Yes. Running disk resident was pretty bad in the days of limited memory as loading segments from disk was awfull. We wrote code that copied the segment part of the OS from the boot disk to a dedicated file on the drum (actually an SSD) so that segments could load from the high speed device but we didn't ahve to dedicate a whole drum for it and hassle with the issues of spanning the drum as the exec grew.

if you had a drum.

as an undergraduate ... I tooked the os/360 stage-ii sysgen punch deck output and reworked it so 1) run it in a production job stream and 2) carefully sequence the order of copy/allocate statements controlling the placement of pieces on the disk.

the univ. had been running student fortran jobs under ibsys on 709 (tape to tape with 1401 for unitrecord<->tape processing). moving that to 360/67 (running in 360/65 mode, aka w/o virtual memory) under os/360 increased the elepased time by nearly 100 times. adding hasp spooling helped a lot ... however, carefully creation of the production system (and the resultant optimized arm motion) improved things another 3 times (from over 30 seconds elapsed time to about 12 seconds). fortran student job processing really didn't return to 709 ibsys monitor thruput until the introduction of watfor.

i gave presentation at the mainframe user group meeting fall68 ... part of the presentation from an earlier posting
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

the above also includes data on running mft14 in virtual machine under cp67 and the results I got from a couple months of rewritten major pieces of cp67 kernel (reducing virtual machine kernel processing cpu time from 534 cpu seconds to 113 cpu seconds ... for running the fortran student job benchmark under MFT14 in a virtual machine).

360/67 did have a 2301 (fixed head) drum for virtual memory paging (originally for tss/360 but used by cp/67).

when i shipped the resource manager product ... i had added some features that would 1) dynamically migrate some fixed real storage tables to paging devices, 2) dynamically migrate virtual memory pages both onto and off of fixed-head paging devices (actually generalized to migrate to/from arbitrary different areas).
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

in the late 70s, I started making assertions about the radical decline in relative system disk performance.
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door

At one point, somebody in the disk division got irritated and assigne their performance modeling group to refute the statements. after several weeks, they came back and effectively stated that I had slightly understated the decline.

one of the issues was that system operations were morphing/evolving to better take advantage in the large increase in availability of electronic memory (significant higher use of electronic memory for things like caching).

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Fri, 30 Sep 2005 17:53:26 -0600
George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> writes:
You can presume whether I like something or not; that was a minor time slice in the PC evolution. It did not take long for even IBM to get the msg that a 327x was not going to hack it for the "user experience" in the brave new world of spreadsheets, word processing and... graphics, which IBM did not even make a PC card/monitor for to begin with.

however, one of the reasons behind big uptake of ibm/pcs ... was that businesses could get a single machine (ibm/pc) for about the same price as 327x ... and it could provide both 327x terminal and also capability of doing some amount of local processing on the desk ... as well as it had footprint of single display & keyboard (didn't require two screens and two keyboards for each desk in order to have both mainframe dataprocessing access and also local desktop stuff).
http://www.garlic.com/~lynn/subnetwork.html#emulation

the big uptake created quite a large install base of terminal emulation products ... which was being threatened as PCs evolved into more advanced computing capability ... as well as client/server was raising its ugly head. this sort of gave rise to SAA ... which nominally claimed that it was going to make it transparent where something actually executed (PC or mainframe) ... but there was a lot of effort in SAA going on to port major PC applications to the mainframe ... and use the PC purely as sophisticated display devices.

In this period, my wife had co-authored and presented a corporate response to a large federal request for secure, campus-like distribute envrionment ... where she had formulated a lot of the pieces of 3-tier architecture. we then expanded on that and were making 3-tier and middle layer customer executive presentation ... which didn't endear us to any of the SAA proponents. recent posting going into more detail
http://www.garlic.com/~lynn/2005q.html#18 Ethernet, Aloha and CSMA/CD
http://www.garlic.com/~lynn/2005q.html#19 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS?

some number of collected postings referencing 3-tier architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Fri, 30 Sep 2005 18:34:41 -0600
archmage@sfchat.org (Nate Edel) writes:
Rackmount, no, but I saw quite a number of places using first generation PS/2 386 systems as file servers or as the server for POS applications around 1989-1990 or so. I never saw a rackmount *anything* until about 1993.

I think they were called industrial PCs and possibly started with XTs (or maybe even original PCs) ... we had some number of rackmount PC/ATs with mainframe channel attach cards (PCCA). PCCA showed up spring 85 ... in configurations with PC/Net LAN cards.

A flavor of this evolved into 8232 ... the mainframe controller tcp/ip; industrial pc/at and a mainframe channel interface card with 8232 nameplate (big hairy bus&tag tailgate interface).

there was some issues with how the 8232 TCP/IP support was actually implemented ... and as a result the mainframe side processor could burn 100 percent of one 3090 processor getting 44kbytes/sec. I then added RFC1044 support to mainframe tcp/ip was in some tuning at cray research ... between a 4341-clone and a cray was getting mbyte/sec (4341 channel media thruput) using only a small amount of the 4341 (aka about 25 times more bits for maybe 1/100th the cpu processing). misc. past rfc 1044 posts
http://www.garlic.com/~lynn/subnetwork.html#1044

at the time there was some rumors and folklore about project that integrated some tcp/ip support into the standard SNA processing environment (vtam, 37xx, etc) where they had hired an outside contractor for the effort. Supposedly the first cut had tcp/ip running with significantly higher thruput than LU6.2 thru the same infrastrucutre. supposedly it was sent back as flawed and having to be redone (at least until tcp/ip was no longer faster than LU6.2).

the industrial pc/at with PCCA had also started out with significantly higher thruput than what was finally shipped in the 8232 support.

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

The 8008

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.computers
Date: Fri, 30 Sep 2005 20:39:42 -0600
jmfbahciv writes:
When we cruised into the harbor for Shanghai, (the year the first shuttle blew up) the smell reminded me vividly of Gary, Indiana when I was a child. All the middle-class snobs on board denigrated China about being so "dirty". These people had forgotten what life was like before the 1960s in the US. What will be interesting is if China will skip the problems caused by automobiles; it doesn't appear so. A lot of third world countries have been skipping the copper wire technology for communications and going straight to cellaphony(sp?).

we have letters from my wife's mother to her mother describing the family's trip leaving san fran, stopping hawaii, japan and arriving in shanghai ... but a couple decades earlier. they were in nanking for a couple years until being airlifted out of the city in a army cargo plane on 3hrs notice. they arrived in tsing tao after dark ... with the airfield lit by headlights from motor vehicles. the letters comment on the strong smell of honeypot fertilizer that was everywhere (extensively used all over the far east).

previous referenece
http://www.garlic.com/~lynn/2004e.html#19 Message To America's Students: The War, The Draft, Your Future

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

OS's with loadable filesystem support?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS's with loadable filesystem support?
Newsgroups: alt.folklore.computers
Date: Fri, 30 Sep 2005 20:55:43 -0600
"bob7094" <bob dot 7094 at comcast dot net> writes:
Further correction - the application accessed logical unit numbers assigned by the user, not filenames, not unlike OS 360.

slightly related post on issues of disk use in os/360
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design

however, one of the other things that i did to cp67 was add tty/ascii support. i thot i could do some really fancy stuff with 2702 terminal controller ... dynamic terminal and line speed recognition. I was able to do the dynamic terminal stuff with 2702 (being able to dynamically reassign line-scanner to different ports) ... but the 2702 wasn't capable of handling dynamic line speed ... line speed oscillator was hardwired to each port.

this spawned a university project to build our own controller ... reverse engineering the 360 channel interface and building a controller channel board that went into an interdata/3 programmed to emulate a mainframe controller (AND do dynamic line speed operation).

somewhere there is a article supposedly blaming four of us at the university for spawning the mainframe plug compatible controller business
http://www.garlic.com/~lynn/subtopic.html#360pcm

and supposedly the plug compatible controller business was the big driving factor behind FS (which was a really large project but was canceled before ever being announced)
http://www.garlic.com/~lynn/submain.html#futuresys

and I've frequently commented that the origins of 801/risc was attempting to do nearly the exact opposite of the horribly complex FS effort
http://www.garlic.com/~lynn/subtopic.html#801

a few years ago I ran into somebody who said that he had made a really good living selling perkin-elmer machines into fed. gov. accounts in the early 80s, (where they attached to mainframes) ... and after some discussion, he commented that channel attack board looked like it hadn't been redesigned since the original one that we built in the 60s (aka ... perkin-elmer had bought interdata and was selling the boxes under their logo).

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Fri, 30 Sep 2005 22:55:05 -0600
"Rupert Pigott" writes:
"So is 'Microsoft Shared Source' a failed attempt at Open Source? Not really. In fact it is a demonstration of how far Microsoft are from grasping the entire concept of Open Source. IBM were providing source code in the 1960's under similar terms. VMS source code was available under limited licenses to customers from the beginning. Microsoft are catching up with 1960."

cp67 shipped source code maintenance. the 6/23/69 unbundling accouncement started charging/licensing application software ... however kernel software was still free (under the theory it was required for the hardware). mainstream batch systems shipped executable maint. and source was available on fiche.

however cp67 morphed into vm/370 and continued to ship source code maint. monthly PLC (program level change) maint. tapes had both complete system executable build ... as well as all the source for for rebuilding system from scratch. the multi-level source code update infrastructure was part of this ... the stuff on the monthly PLC tapes were the base release source ... plus all the individual, incremental source code updates that had been created since the release.

many customers had extensive updates of their own ... and monthly PLC maint. frequently required merging the local customer source updates with the new product updates ... and/or retrofitting specifically selective product maint. updates to customer source built system.

some amount of features that I had implemented as an undergraduate for cp67 got dropped in the morph from cp67 to vm370 ... however there were numerous customers lobbying for them to be made available in the vm370 product. eventually i got to do the resource manager for vm370 ... posting of the old original product announcement letter
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

some number of other references to pieces of the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

however they also selected the resource manager to be guinea pig for charging for kernel software
http://www.garlic.com/~lynn/submain.html#unbundle

which met that I had to spend quite a bit of time with the business, legal, and pricing people on creating policy for kernel software pricing. that iteration of kernel software charging was that new kernel code not directly required for hardware support could be charged for (while direct hardware support software like device drivers were still free). this policty created kernel software features ... base (free) product with selected purchased add-ons. This lasted a couple of years ... and eventually they reintegrated and charged for a single kernel which they renamed VM/SP (i.e. system product).

there was something of a hiccup with the resource manager tho. In the initial resource manager i included a whole lot of kernel rewrite ... and when they decided to ship SMP support in the following release ... it was realized that a lot of stuff that SMP support required I had already shipped in the resource manager. This created a policy problem since it would be a violation to have as a prerequisite for the *free* SMP support, the priced resource manager.

the problem was that I had done the overall SMP design .. predicated on a bunch of kernel structural changes that I had included with the resource manager. the eventual resolution was to move possibly 80 percent of the resource manager code into the free kernel. misc. past smp posts
http://www.garlic.com/~lynn/subtopic.html#smp

note ... even tho the resource manager was charged for ... it still shipped as source code maintenance ... and in fact was a set of source code updates to the base, free kernel code. source code maint. continued even after move to pricing for all kernel code with vm/sp. however OCO (object code only) was being strongly pushed ... putting it even footing with the other operating systems. OCO was heavily debated issue at customer user group meetings and on vmshare ... especially hot item during the mid-80s.

vmshare archives
http://vm.marist.edu/~vmshare/

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Fri, 30 Sep 2005 23:04:24 -0600
oh, ref
http://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS?

... and misc. past posts mentioning multi-level source update stuff
http://www.garlic.com/~lynn/2002n.html#39 CMS update
http://www.garlic.com/~lynn/2003.html#62 Card Columns
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003j.html#14 A Dark Day
http://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
http://www.garlic.com/~lynn/2005b.html#61 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#42 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3

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

DDJ Article on "Secure" Dongle

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DDJ Article on "Secure" Dongle
Newsgroups: sci.crypt
Date: Sat, 01 Oct 2005 08:39:52 -0600
"TC" writes:
Piracy is a legitimate concern for software authors.

My experience, with my own product, is that 1% of effort will deter 99% of people who would otherwise pirate my app. But we all know that no amount of extra effort will deter the remaining 1%.

So, dongles etc. al. are just a waste of time and money. The people who are deterred by those, would be equally deterred by an encrypted value in the registry, or somesuch simple scheme.


it may be the reverse of swimming pools and fences ... if you have a fence ... it isn't your fault ... if you don't have a fence then it is your fault. demonstratable countermeasures ... are enuf to take action ... either by employers to fire employees that violate. if you are charging ... and some large corporation is in flagrant violation action can be taken. one percent not paying/stealing can be tolerated ... i think a lot of companies figure that they are going to have 5-7 precent loss ... places like retail stores ... employees mostly ... but also straight-forward customers shoplifting. sometimes the counter measures are both simple deterrent for most, as well as basis for various kinds of legal action.

there was a trade-secret theft situation ... where legal action was brought claiming several billion damages ... the judge invoked the swimming pool scenario; if it really is billions of dollars ... some large fraction of the population will be expected to steal, as a matter of course, and you can't really hold it against them ... unless you show that you have taken countermeasures proportional to the value of what is being protected. if isn't absolute ... and the countermeasures wouldn't be expected to cost more than value of what is being protected ... just demonstratable proportional.

that was possibly one of the places i picked up security proportional to risk ... some slight topic drift
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk

in any case, given swimming pool scenario and judges wanting to see countermeasures proportional to value ... then the issue may be the value of the software and how much are you charging for each license.

and then there is some additional topic drift ... straying back to unbundling announcement on 6/23/69 and starting to charge for application software ... although kernel software was still free. however, when i was doing the resource manager ... it got selected to be the guinea pig for first charged for kernel software ... and i got to spend lots of time with business and legal people on software pricing policies. some past collected posts on unbundling and software pricing
http://www.garlic.com/~lynn/submain.html#unbundle

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sat, 01 Oct 2005 10:23:36 -0600
keith writes:
While I agree with your sentement, there wasn't any lack of a graphics card. The CGA card and monitor were announced and shipped with the 5150. I had a CGA card (couldn't afford the monitor) on my "first day order" 5150. ...along with the monochrome card and monitor.

OTOH, contrary to Nick's point, the 5150s did not ship with a 3270 emulator card. Those came later (IIRC IBM wasn't even first), as it became obvious the PC was a better and cheaper 3270. Saying that the The PC was originally intended to be a 3270 replacement is "new history", at best.


I had first day employee order ... the day before it arrived, the prices were lowered ... and I could pick up same configuration at computerland for less than i had paid in the employee order.

the PC wasn't originally intended to be 3270 replacement ... but it (eventually) got big boost in market penetration when it started being used for terminal emulation. in fact, before mac was announced ... I even had arguments with some of the mac developers about its chances of success w/o some commercial support ... like terminal emulation (my brother was regional apple marketing rep ... he claimed he had the largest physical territory in continental US ... anyway when he came into town, we had dinners with various people).

in any case, terminal emulation in turn, resulted in large install base of equipment around the terminal emulation business. then with a large terminal emulation install base ... it had to be protected. the growing capability and emerging client/server paradigm was a threat to this install base. SAA supposedly was that applications could be run everywhere ... but there was a lot of money being spent on porting PC applications to the mainframe ... hoping to stuff the client/server genie back into the bottle.
http://www.garlic.com/~lynn/subnetwork.html#emulation

in this period ... we had come up with 3-tier architecture, middle layer, etc and were out pitching it in customer executive presentation ... which didn't endear us to any in the SAA crowd (and since it was also ethernet oriented ... didn't make any friends with the t/r people). In previous life, I had worked frequently with the person responsible for SAA ... so we would periodically stop by his big corner office in somers (some joke he could almost see endicott from it) and give him a bad time about the reality of SAA prospects.
http://www.garlic.com/~lynn/subnetwork.html#3tier

one of the threats to the terminal emulation business was the increasing number of business applications showing up on PCs ... this in turn was driving big business for PC hard disk capacities ... and you started seeing a noticeable decline in the growth of mainframe disk sales as business data leaked into the distributed environment. the disk division came up with several products that would provide extremely high-thruput disk access to glass house data by PCs and other distributed processes ... with lots of business case justification like data backup, integrity, disaster/recovery, etc (they even had statistics on businesses that declared bankruptcy when unbacked up data on PC disks was lost).

In any case, this resulted in significant wars between the disk division and the division responsible for terminal emulation business ... with the division responsible for terminal emulation business claiming total strategic responsibility for everything outside the walls of the mainframe machine room. One of the disk division's retaliations was giving a presentation at a large internal conference going into gory detail about how the communication division was going to be directly responsible for the demise of the mainframe disk division (the limited terminal emulation spigot was greatly accelerating the migration of data residency out into the distributed environment)

as an aside ... there was a acorn software project out on the west coast; boca had said it wasn't doing or involved in software ... and it was perfectly reasonable for the west coast group to do software. possibly monthly, boca was contacted to reaffirm that they weren't interested in software and west coast was free to take on software mission. then at some point, boca changed its mind and effectively said that the west coast group couldn't do the software mission .. and if the people involved wanted to be involved in software mission for acorn ... they had to move to boca.

some past posts mentioning acorn
http://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2003c.html#31 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#19 PC history, was PDP10 and RISC
http://www.garlic.com/~lynn/2003e.html#16 unix
http://www.garlic.com/~lynn/2005q.html#24 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sat, 01 Oct 2005 12:43:45 -0600
ref:
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design

oops, unbundle was brain-check ... attention momentarily wandered to a posting doing in parallel concerning free software from the 60s and the transition to priced software in the 70s ... aka
http://www.garlic.com/~lynn/2005r.html#7 DDJ Article on "Secure" Dongle
i.e.
http://www.garlic.com/~lynn/submain.html#unbundle

it should have been reference to collection of postings on terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation

note that 20 years ago ... the disk division was starting to come up with these mainframe nas/san like solutions for the distributed environment ... and the communication division was constantly killing the efforts ... protecting their position as owning everything that crossed the wall of the mainframe machine room.

it also gave my wife fits earlier when she was con'ed into going to pok to be in charge of loosely-coupled architecture. stuff that she could potentially do between mainframes in the same machine room couldn't be done when it was between the same mainframes but in different machine rooms (because it then became the responsibility of the communication division). it is possibly also why the mainframe fiber-optic interconnect languished in pok for a decade ... the mainframes machine rooms had to get big enuf and complex enuf to justify fiber intra-room interconnect ... and (a very) few battles had to be won with the communication division to allow some to cross the boundary of the machine room wall (to be used for inter-room interconnect).

when i was doing high-speed interconnect project ... i purposely called it HSDT (high-speed data transport)
http://www.garlic.com/~lynn/subnetwork.html#hsdt

to try and help differentiate it from communication (and the responsibility of the communication division). something that sort of highlighted the difference ... I was about to leave on a trip to the far east to contract for some equipment. the friday before i left, somebody from the communication division announced a new discussion group on "high-speed" ... and offered the follow definitions for use in the discussions
low-speed <9.6kbits medium-speed 19.2kbits high-speed 56kbits very high-speed 1.5mbits

monday morning in a conference room outside of Tokyo were these definitions on the wall:
low-speed <20mbits medium-speed 100mbits high-speed 200-300mbits very high-speed >600mbits

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sat, 01 Oct 2005 13:36:39 -0600
for some additional drift from terminal emulation
http://www.garlic.com/~lynn/2005r.html#6 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#6 Intel strikes back with a parallel x86 design

to nas/san ... in the mid-80s both LANL and NCAR (boulder) were doing things where standard ibm mainframe was handling tape library and disk farm for a variety of supercomputers on the same machine room floor. they used HYPERchannel for both processor (messaging) interconnect and processor/device (I/O) interconnect.

ncar would possibly have a cray make a request to ibm mainframe for some data. the mainframe would possibly stage it from tape to disk (if necessary) and then initialize the appropriate HYPERChannel remote device adapter (it emulated an ibm channel) that the particular disk controller was attached to. a coding sequence was then returned by the ibm mainframe to the cray (HYPERChannel message). The Cray would then signal the indicated HYPERChannel remote device adapter with the correct coding sequence ... to do the actual (direct) data transfer.

LANL was in large part behind the IEEE standardization work for cray channel as HiPPI. There was some effort in both IPI3 (disk) standards activity and HiPPI switch standardization ... to make sure that third-party transfers (of the kind NCAR was doing with the HYPERchannel remote device adapter) were supported.

I got asked advice on some of this because in the early 80s, I had done some mainframe device driver work for HYPERChannel.

A specific situation in the early 80s was that the Santa Tersa Lab was overflowing and there was a decision to move 300 IMS (database) programmers off-site ... but with remote access to the machine room. Remote 3270s were evaluated (max at 9600 baud operation) and quickly discarded. So the solution was to create high-speed connection between STL(bldg.90) and the new offsite location ten miles away (bldg. 96/97). HYPERChannel was to be used for channel extension with 300 "local" 3270s (and other devices) at the remote site. It was possible to scavange some bandwidth from the "campus" T3 collins digital radio ... aka bldg. 12 on the main plant site had digital radio to the repeater tower on the hill above STL ... and also line-of-sight to the roof of the new off-site bldg. It just required hooking up the appropriate circuits ... and making sure they had point-to-point link encryptors.

Folklore is that when hiway 85 elevated section was first opened... cars had their radar detectors trip when crossing the path between bldg.12 and the STL repeater tower ... approx. here:
http://www.mapquest.com/maps/map.adp?country=US&addtohistory=&formtype=address&searchtype=address&cat=&address=State%20Hwy%2085%20%26%20Via%20Del%20Oro&city=San%20Jose&state=CA&zipcode=95119&searchtab=home

link encryptors were used on everything ... at one point in the mid-80s, there was a claim that internal operations had well over half of all link encryptors in the world (and all the orders established at least one company in the crypto business).

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 10:29:48 -0600
George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> writes:
The bottom line, which I was trying to get across, is that in a software system which exercised the CPU across all its spectrum of operations, the 68K was a dog. It was just as much a dog at pure "commercial" work as it was at quasi-scientific "business" application work - the CPU was just slow in general and saddled with an idealistic orthogonal ISA. The 386 was simply a better performer and the PowerPC was never going to better enough.

byte article from 11/96 ... a little later in time
http://www.byte.com/art/9611/sec6/art13.htm
PowerPC Regroups

Stung by Intel's gains in processor performance, the PowerPC alliance will strike back with higher clock speeds and new chip designs.

Don't count your megahertz before they're hatched. That's what the PowerPC alliance has learned after prematurely gloating over the imagined obsolescence of Intel's x86.

One famous advertisement from 1992 showed how CISC performance was falling flat while RISC technology soared toward the SPECint stratosphere. Another ad warned about the coming fate of x86-based PCs by picturing a highway running smack into a brick wall.


... snip ...

and a little earlier also from byte
http://www.byte.com/art/9411/sec8/art5.htm
PowerPC 620 Soars

Its faster logic, shorter pipelines, and high-speed interface endow it with processing power that raises it to workstation and server caliber


... snip ...

and a little discussion of power and power/pc
http://www.research.ibm.com/journal/rd/385/preface.html
During the four years since the RISC System/6000* (RS/6000) announcement in February of 1990, IBM* has strengthened its product line with microprocessor enhancements, increased memory capacity, improved graphics, greatly expanded I/O adapters, and new AIX* and compiler releases. In 1991, IBM began planning for future RS/6000 systems that would span the range from small, battery-operated products to very large supercomputers and mainframes. As the first step toward achieving this "palmtop to teraFLOPS" goal with a single architecture, IBM investigated further optimizations for the original POWER Architecture*. This effort led to the creation of the PowerPC* alliance (IBM Corporation, Motorola*, Inc., and Apple* Computer Corporation) and the definition of the PowerPC Architecture*.

.. snip ...

power was rios ... was a traditional 801/risc architecture ... no cache consistency, no provision for SMP, some number of hardware trade-offs issues from the original idea from the 70s. however, the demise of various proprietary efforts in the early 80s ... and the romp displaywriter followon ... had it stray from proprietary into the world of unix and (more) open systems. i was assured at an advanced technology conference in the mid-70s that the use of 16 segment registers for virtual memory support ... was a hardware simplicity trade-off ... aka a lot of 801 was swinging the pendelum to the opposite extreme in reaction to the extremely complex FS (which was eventually killed w/o being announced):
http://www.garlic.com/~lynn/submain.html#futuresys

... in any case, the claim at the time ... was the combination of no protection domain and ability of inline application code could change (virtual memory) segment register values (as easily as general register address pointers could be changed) would more than compensate for the limited number of segments (for various memory mapped paradigm implementation).
http://www.garlic.com/~lynn/subtopic.html#801

in some sense ... somerset and powerpc was going after both larger volume market ... as well as migrating to somewhat more traditional processor architecture with support for cache consistency, multiprocessor operation, etc.

at the time, the executive we directly reported to in the hardware group when we were doing ha/cmp ... misc ha/cmp refs (note none of the executives mentioned in the following post is anybody we directly reported to):
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/subtopic.html#hacmp

had previously worked for motorola. with the formation of somerset, he moved over to head up somerset and the powerpc effort.

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 12:34:06 -0600
"Stephen Fuld" writes:
But the TSO editor was there, and clearly intended for program development

there are lots of jokes among customers about TSO being too slow to use for interactive (even some recent threads in ibm-mainframe group). basically TSO was slightly better than using a keypunch.

when we were arguing with product group about being able to have subsecond response with the new 3274 display control units ... effectively TSO came down on the side of the 3274 group ... since they never had subsecond response ... even with the faster 3272 controller. Basically 3274 group defined their target market (what is cause and what is effect?) as data entry (previously done on keypunches) which don't have any issues with system performance and response.

reference to old report with numbers comparing 3277 & 3274:
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol

from above:


               hardware     TSO 1sec.    CMS .25sec.     CMS .11sec
3272/3277        .086        1.086         .336            .196
3274/3278        .530        1.530         .78             .64

as mentioned in the above reference the numbers are very idealistic, optimistic numbers for TSO (talk to customers that complained about several seconds being more typical) ... and normal range of measured numbers for production CMS environments. The joke in the above was that .25sec was nominal for most CMS operations ... but the .11sec was typical of several places running my latest performance tweaks (at the particular point in time that the 3274/3278 issue was being debated).

also the hardware numbers are for direct channel attached controllers; SNA managed controllers had significantly worse hardware response (even local SNA controllers ... but remote SNA controllers were the pits)

there was passing reference to subject in previous post
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design

where the IMS development group being remoted off-site couldn't face the prospect of using remote 3270s ... even in conjunction with their normal development environment (aka most of the machines at STL ... which housed IMS, DB2, PLI, APL, Pascal, and number of other development groups ... were vm370/cms).

Part of the issue in the 3272/3274 was that the 3274 had moved some amount of the electronics & logic out of the 327x terminal head ... back into shared controller logic (reducing 327x terminal manufacturing costs but contributing to performance issues).

For some of us ... even local channel, "fast" 3272/3277 had some issues ... while the controller operated at 640kbytes/sec ... there were still some half-duplex latency issues. A little soldering in the keyboard and additional electronic modification in the display head ... took care of some of the issues.

In spring of '85, a mainframe channel interface card was produced for PC/AT (16bit isa bus) that was configured with pc/at with PCNET lan cards and some changes for psuedo 327x terminal operation. emulator was then written for PCs on the PCNET lan ... that was loosely 3270-like ... as well as some enhanced controller support software on vm370 mainframe. since it was internal operation ... various liberties were taken with all of these to eliminate as many annoying characteristics as possible.

This was quickly replaced with enet lan cards. About a decade later and the technology was finally starting to best the turbo-charged 3277 environment.

In the 70s, an internal 3270 telnet-like server/demon terminal emulation package had been developed for vm370. it included support of program interface to application running in local cms virtual machine. programmatic scripting language quicly evolved for this interface ... with a lot of features that would later appear in HLLAPI support (pc application doing 327x screen scraping). the most prevalent internal was the parasite/story package done in the UK ... past parasite/story posting
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question

note that the REXX author had used some of the same basic technology for implementing a multi-user spacewar game (that supporting time-sharing users on local machines and/or remote users over network links).

Then my home 300baud/ti700 was upgraded to 1200buad/3101. 3101 was basically glass teletype ... but had something called "block mode". You could either dial into the system as glass teletype ... or you could connect directly to the 3270 server/demon and have it drive the terminal in block-mode. The internal 3270 server/demon had been upgraded to directly drive 3101 block mode and use its features to optimize the terminal operation.

When I got my employee purchase ibm/pc ... minor previous reference
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design

i was able to replace the 300baud/3101 setup with 1200baud/ibmpc terminal emulation. a greatly enahced package was developed for the ibm/pc that also interacted with a whole bunch of new features in the 3270 server/demon (available when it was directly driving the line). fundamental was sophisticated transmission compression as well as dictionary of common stuff and cache of already transmitted stuff (the host server/demon kept state about what was in the pc cache ... and instead of of doing compressed transmission ... it had control features to display stuff from the cache).

it was this basic technology infrastructure (3270 server/demon) that then had enhancements to drive the channel-attached PC/AT LAN gateway for local terminal emulation.

,,, some topic-drift ... the home terminal program initially developed a dial-in interface that supported callback (aka you dialed, identified yourself ... and the interface then hung up and called back the number listed for the identification). this was enhanced with a encrypting 2400baud hayes-compatible async card ... that did a sort of SSL session hand-shake (not using public key tho), establiehed session key and then ran encrypted session. this was then required for all home terminals and people using portable terminals/laptops dialing in from hotels (a detailed vulnerability study had turned up hotel PBXs as being one of the most likely compromised points in the infrastructure).

folklore has it that one of the early prototype crypto asyncr cards wad provided to a senior executive. he had been an old time EE ... and during testing touched his tongue to the contacts in the phone jack ... just as the phone rang. after that it was mandated that all async cards built by the corporation had to have recessed jack contacts (so innocent individuals, like corporate senior executives, couldn't touch them with their tongue).

various past other posts discussing issues using HYPERChannel for mainframe channel extension (used for moving 300 from the ims group to off-site location but allowing them retain their "local" 3270s).
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#34 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005e.html#21 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design

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

Is a Hurricane about to hit IBM ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is a Hurricane about to hit IBM ?
Date: Sun, 02 Oct 2005 12:57:21 -0600
Newsgroups: bit.listserv.ibm-main
AntonMvs2005 wrote:
Most of us could be seen as "Sitting in a dark room reading IBM manuals for a living", or that's what I have been doing for most of my life but I am trying to think a little "wider".

So, you might say where are you going with this ?

Anybody remembers where JES comes from ...


how many people know where the spring '68 SHARE meeting was held? How many attended? Did you get to have a tour of the local large installation?

for some slight topic drift ... some posts x-posted to comp.arch, intel, & ibm/pc hardware newsgroups ... strays into terminal emulation and the point behind SAA?
http://www.garlic.com/~lynn/2005q.html#25 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#31 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#33 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#35 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#36 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#42 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#43 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#44 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#45 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#48 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#1 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#2 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 13:34:33 -0600
keith writes:
We had second(ish) *trivial* response when we were co-located with the hardware. With a block editor this wasn't too bad (sure beat 2741s on acoustic couplers). In Bldg, 701 such performance was rather tough to do since the systems were all in SRL (about five miles away) and there were three heads per 9600bps modems. :-(

that is one reason why when 300 people from the ims group were moved to an off-site location ... they refused to go with remote 3270s; they had a hard time tolerating any of the "local" SNA &/or MVS flavors ... just give them local channel attach 3270s to cms (1980s time-frame).

there was some 2nd order effects that actually resulted in moving the local 3274s for 300 people offsite ... using HYPERCHannel for channel extension over microwave link ... actually improved performance.

while we are talking about channel-attach *local* 3274s ... there were a number of performance issues with the 3274s. One was that they had very high I/O command processing overhead ... which significantly increased channel busy time (even when we are talking about channel data transfer rates of 640kbyte/sec for 3274 controllers).

At the time, the STL machines were configured with 16 channels ... and had large number of disks and 3274 controllers intermixed on (almost) all channels.

The HYPERChannel configuration involved moving the *local* channel attach 3274 to remote site ... and connecting them to HYPERChannel A510 remote device adapters (A510s emulated ibm mainframe channels). Then HYPERChannel A220 device adapters were attached directly to the IBM channel .... and the HYPERChannel transport layer handled the connection between the local A220 channel attach box and the remote A510 ibm channel emulation box. It turns out that the A220 was a much faster box than the 3274 and resulted in significantly lower channel busy time doing the same exact operations (vis-a-vis configuration with 3274s physically attached directly to IBM channels).

The reduced channel busy resulted in better disk i/o thruput and an overall system thruput improvement of 15-20 percent. The overall system thrput improvement contributed to also improvement of trivial interactive response ... which more than offset any increase in latency involving HYPERChannel and microwave links.

When my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture ... misc. references
http://www.garlic.com/~lynn/submain.html#shareddata

... one of the groups she worked with was the POK interconnect group ... which primarily was doing CTCA and then 3088 ... but had hopes of some day of getting fiber-optic interconnect out the door (which they eventually were able to did as escon). To some extent, the POK interconnect group and my wife fought the same battles with SNA organization ... over being forced to revert to SNA operation anytime they crossed the machine room wall boundary.

However, when it came time to try and get my HYPERChannel device drivers released as IBM products ... not only were there loud howls of objection from the SNA organization ... but the POK interconnect group came down on the side of the SNA organization. In this scenario they were still harboring hopes that they could prevail over the SNA organization and get out their high-speed fiber optic interconnect ... and have it available crossing the machine room boundary. The POK interconnect group felt that the HYPERChannel interconnect was (potentiallY) as much a longterm threat to their objectives as it was a threat to the SNA organization's products (so it was time to circle the wagons, forget for the moment their differences and oppose the common enemy).

.. a little history ... Cray and Thornton worked together at CDC; Cray left to found Cray Research to build supercomputers, Thornton left to do high-speed heterogeneous i/o interconnect and founded Network Systems ... which produced HYPERChannel. More recently, NSC was acquired by STK ... which just recently was acquired by SUN.

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 13:56:43 -0600
Anne & Lynn Wheeler writes:
reference to old report with numbers comparing 3277 & 3274:
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol

from above:

hardware     TSO 1sec.    CMS .25sec.     CMS .11sec
3272/3277        .086        1.086         .336            .196
3274/3278        .530        1.530         .78             .64

as an aside ... the 3722 hardware response was relatively uniform .. while the 3274 hardware response was data sensitive ... the .53 value was somewhat a nominal best case; the TSO 1sec was a hypothetical avg., and the .25sec was measured avg. across large number of actual operations ... note however, for the .11sec live system, long term number ... it wasn't avg. ... it was 90th percentile (avg. was actually less).

one of the (other human factors) problems with the 3274 was (keys &) typamatic was implemented in the controller ... with fixed value (that was one of the things that got moved out of the 3277 and back to the controller to cut down on terminal manufacturing costs).

one of the turbo things we could do with the 3277 ... was a little soldering inside the keyboard and choose your own typamatic delay & rate values. We had a number of keyboards done at .1 & .1. However, the .1 typamatic rate was faster than the screen refresh rate ... holding down a cursor movement key would develop a time-delay lag on the screen ... and then the cursor would appear to coast for some period of time after you took you finger off the key. It took a litte bit of getting use to ... in order to have a cursor stop at the exact screen position (since the display feedback was lagging behind how long you held the key down).

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 14:19:08 -0600
Anne & Lynn Wheeler writes:
However, when it came time to try and get my HYPERChannel device drivers released as IBM products ... not only were there loud howls of objection from the SNA organization ... but the POK interconnect group came down on the side of the SNA organization. In this scenario they were still harboring hopes that they could prevail over the SNA organization and get out their high-speed fiber optic interconnect ... and have it available crossing the machine room boundary. The POK interconnect group felt that the HYPERChannel interconnect was (potentiallY) as much a longterm threat to their objectives as it was a threat to the SNA organization's products (so it was time to circle the wagons, forget for the moment their differences and oppose the common enemy).

ref:
http://www.garlic.com/~lynn/2005r.html#14 Intel strikes back with a parallel x86 design

several years later I was able to ship RFC1044 support in mainframe tcp/ip product ... but then (at the time) neither the SNA organization or the POK interconnect group really thot that TCP/IP support was much of an issue/threat. misc. collection 1044 postings
http://www.garlic.com/~lynn/subnetwork.html#1044

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 15:10:02 -0600
ref:
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design

the modified PC 3270 emulator was available with support for TCA cards (to 3274) and called MYTE; PCCA was the 16bit ISA mainframe channel interface card.

a reference from long ago and far away:
The demo they had with PCCA on PCNET was various host connections was quite impressive, both terminal sessions and file transfer. Terminal sessions supported going "both ways" ... PVM from PCDOS over PCNET to AT with PCCA, into 370 PVM and using PVM internal net to log on anywhere. A version of MYTE with NETBIOS support is used on the local PC machine. They claim end-to-end date rate of only 70kbytes per second now ... attributed to bottlenecks associated with NETBIOS programming. They could significantly improve that with bypassing NETBIOS and/or going to faster PC-to-PC interconnect (token ring, ethernet, etc). However, 70kbytes/sec is still significantly better than the 15kbytes/sec that Myte gets using TCA support thru 3274.

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

SATA woes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SATA woes
Newsgroups: comp.os.linux.hardware,redhat.hardware.arch.intel,comp.os.linux.redhat,comp.os.linux.hardware,linux.redhat.install,redhat.kernel.general
Date: Sun, 02 Oct 2005 17:02:58 -0600
Whoever writes:
I have been trying to install RedHat Enterprise Workstation 4 on a system based on the Intel 945G chipset with a SATA disk.

By configuring the drive mode to be ATA/IDE in the BIOS, I was able to install the OS (but very slow, because disk access is very slow).

I was able to download some updates -- including a later kernel, but now the system won't boot with the latest kernel (it still boots with the older kernel). The new (non-booting) kernel is 2.6.9-11 (with a -EL or similar suffix, I am not in front of the system right now).


as an aside ... does FC4 install handle SATA disks. FC3 did a clean install on a machine I have with SATA raid. However, somewhere in the FC3 cycle ... the YUM kernel installs dropped SATA support. Then after doing a YUM kernel install ... i would have to rebuild the FC3 kernel with SATA support before rebooting ... aka

/sbin/mkinitrd --with=sata_promise --with=ata_piix --with=sd_mod
-f initrd-2.6.12-1.1378_FC3smp.img 2.6.12-1.1378_FC3smp

a scratch FC4 install will wipe my FC3 bootable system ... but I don't want to try it ... if the base FC4 install might fail to include SATA support ...leaving me with an unbootable system.

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Mon, 03 Oct 2005 09:15:57 -0600
"gerard46" writes:
After ten years of mediocore response time, I suppose anybody can get used to anything. But once you get on a system with subsecond response times (say, 1/3 second), anything over a second seems long, and when it gets over two seconds, it seems intolerable. It all boils down to what you get used to. _______________________________________________Gerard S.

there was actually a study about human factors and response time ... and unpredictable response time turned out to be a significant factor ... if people got use to 2 second response time ... they would change their behavior to accomodate the infrastructure. however, if there was significant variability between 1 second and 3-4 seconds, they might do something based on expecting 1 second ... and then have to wait until it was really ready. this degraded human performance by a factor of twice the difference between the expected and the actual.

there was an corporate conference held at the original marriott in wash dc in the early 70s ... where Mills spoke about super programmer and some HF group spoke on human performance and system response. they measured a bunch of people at research ... and found that human throughtput consistently improved with system response down until about .25seconds. Between .25seconds and .1second it became somewhat variable ... apparently differences between individuals. Some people didn't notice the difference between .25 and .1 second response, and some people would notice all the way down to .1 seconds (which was about the best they measured in any individual). they claimed to not find any correlation between threshold percention of different individuals and other characteristics. I have vague recollection of running across an article in the early 80s on study of brain synapse propagation time and finding individual variability ... which may or may not have any correlation with individual response perception threshold.

it did give rise to some derogatory jokes about tso users not being able to perceive difference between greater than second response and subsecond response.

part of the MVS TSO issue involved MVS system structure ... and wasn't solely TSO's fault.

sjr/bldg28 for a period had a pair of 370s all sharing the same disk control units, a 370/168 for MVS and a 370/158 for VM370/CMS. The operators were instructed to keep disk mounts segragated between disk controllers identified as MVS and controllers identified as VM. The issue is that MVS normal disk operation includes multi-track search operations which could create solid control busy lock-up for as long as 1/3rd second for a single operation. A controller would typically have 16 disk drives ... and when a controller was busy in this manner, the other 15 disk drives were unavailable during the busy period (i.e. you might expect something like 20-40 accesses per second per disk ... in this worst case scenario, things might degrade to a total of 3 access per second per controller ... total, across all 16 drives).

one day, an operator accidently mounted a "MVS" disk on a "VM" controller/drive. within five minutes the datacenter operations were getting phone calls from irate cms users howling about system response having just gone down the drain.

besides the normal TSO characteristics not being sensitive to human factors and system response ... the underlying MVS platform wasn't conducive to fine-grain response. the incident was a great example that not only didn't TSO users realize how bad it really was ... but how the underlying MVS platform contributed to TSO not being able to provide response (i.e. TSO users ran day in & day out ... with all MVS disks operating with the charactistics that CMS users found totally intolerable when subjected to just a single disk operating in that manner).

lots of past posts about the effect of multi-track search on response and thruput
http://www.garlic.com/~lynn/submain.html#dasd

note that the extensive use of multi-track search could become so bad that it would even effect MVS shops. I got brought into a large customer shop that didn't have any vm370 at all. It was a datacenter for a large national retailer ... that had basically processor per region ... but sharing common disk infrastructure. they were experiencing random slow-downs that appeared to almost bring the whole complex nearly to its knees. It turned out to be an issue with a large application library partitioned data set ... that when things really got busy during the day ... all the systems were constantly loading members from the same library. The PDS had a 3cyliner directory and each member load required, on the avg. a 1.5cylinder multi-track search of the directory (taking approx. .5 seconds elapsed time).

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Mon, 03 Oct 2005 10:08:48 -0600
"gerard46" writes:
After ten years of mediocore response time, I suppose anybody can get used to anything. But once you get on a system with subsecond response times (say, 1/3 second), anything over a second seems long, and when it gets over two seconds, it seems intolerable. It all boils down to what you get used to. _______________________________________________Gerard S.

another indication about how bad TSO response was (especially vis-a-vis CMS potentially running on identical hardware configuraiton and effectively similar load) ... was that in the late 70s and early 80s ... some number of startups actually got VC money for doing 3274 clone controllers that featured TSO "offload".

typical CMS trivial interactive response would included some disk operations ... even when TSO trivial interactive response was defined to exclude operations involving disk ... there was still a significant response issue. 3274 controller clones ... would provide front end processing for some number of frequent TSO interactive operations (for the connected 327x terminals) ... attempting to mask the horrible system backend operation (and the remarkable thing was this was so well recognized that you could even get VC money for startups doing it). With the eventual proliferation of PCs with terminal emulation, the front-end TSO offload (backend response masking) could be moved to the PC ... obsoleting the need for the 3274 controller clones.

there used to be a joke in the valley that there were actually only 200 people ... they just milled around in different disguises.

One of the 3274 controller clone startups was done by somebody who had been in the vlsi tools group in Los Gatos lab (bldg. 28) and also one of the two people responsible for the 370 pascal compiler (originally developed for writing of internal vlsi tools). He then went on to be VP of software development at MIPs and at the first JAVA conference ... showed up as general manager of the SUN group that included JAVA.

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

z/VM Listserv?

From: Anne & Lynn Wheeler <lynn@GARLIC.COM>
Subject: Re: z/VM Listserv?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 3 Oct 2005 09:57:03 -0600
Juraschek, David F wrote:
I've been to MARIST & L-Soft.

Is there a z/VM (or just a VM) listserv address?


... vmesa-l@listserv.uark.edu

traditional listserv to subscribe/unsubscribe LISTSERV@LISTSERV.UARK.EDU

note that both ibm-main and vmesa-l are gatewayed to usenet as bit.listserv.ibm-main and bit.listserv.vmesa-l. I find that usenet posts to bit.listserv.vmesa-l actually flow in the reverse direction ... however for posts to actually show up in the ibm-main mailing list ... you have to actually mail to the ibm-main listserver.

the "bit.listserv" usenet hierarchy dates from the bitnet/earn days
http://www.garlic.com/~lynn/subnetwork.html#bitnet

when bitnet mailing lists were gatewayed from bitnet to internet.

z/VM Listserv?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@GARLIC.COM>
Subject: Re: z/VM Listserv?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 3 Oct 2005 10:53:22 -0600
Ed Finnell wrote:
It's a configuration option in lSoft for bidirectional flow. We've talked about it numerous times in the past. Back in the late 90's when American .edu dropped usenet for lack of interest, personnel, budget Google was just starting up and started gating to the usenet groups. In their never ending search for eMail addresses also allowed subscription to their copies of the original lists. Darren found out early on that the Lsoft exits weren't sufficient for uunet protocol and had to turn off bidirectional posting. The 'true' newsgroup is hosted by newsguy.com(it's a subscription too). With the advent of the harvesting .bots and SPAMmers more and more is intercepted and transmogrified in the lsoft exits.

i had done some mailing list stuff on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

that predated toolsrun ... in fact, there is some folklore that toolsrun somewhat came out as a result of a corporate task force that was formed to investigate what was going on (some even leaked and showed up in datamation article blaming me, the authors of network nation from njit were also brought in as part of the investigation). some version of toolsrun was then shared with bitnet participants giving rise to early listserv.

another fall-out was i got a researcher in the back of my office for nine months that took notes on how i communicated, went with me to meetings, got copies of all my incoming/outgoing email and logs of all instant messages. The analysis eventually resulted in a Stanford phd thesis (joint between computer ai and language) and subsequent papers and books ... somewhat in the area of computer mediated communication
http://www.garlic.com/~lynn/subnetwork.html#cmc

my first usenet/newsgroup reader back in the late 80s was in emacs ... and i still do majority of my usenet/newsgroup activity in emacs client.

OS's with loadable filesystem support?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS's with loadable filesystem support?
Newsgroups: alt.folklore.computers
Date: Mon, 03 Oct 2005 17:26:39 -0600
"Jack Peacock" writes:
It lives on in the way a database manager still does much the same thing, in terms of managing database pages in memory vs. on disk. Page I/O is typically in block format, some multiple of sector size, with the disk file treated as a linear number of database pages, not so different from a SCSI disk appearing as a linear list of blocks. The database writer is essentially a virtual memory system, mapping the entire disk file into memory (assuming a 64-bit address for largers DBs), then caching disk blocks in memory from that linear list.

Wasn't it common on Unix systems at one time to install database files in raw partitions, due to the 32-bit addressing limits on filesystems?

In practical terms using physical geometry isn't practical anymore because of zone recording, where the number of sectors per track varies by distance from the center spindle, so SCSI went to a block number instead (and IDE too when ATAPI came into being).


raw was to avoid standard unix filesystem caching and poor consistency. with raw ... the dbms had a pretty good idea of what was actually on disk and what was actually in memory and when there were transitions between the two. raw useage predates 32bit addressing becoming a limitation.

for decades, unix filesystems had been notorious for their extremly poor disk surface consistency operation. you have a filesystem that couldn't satisfy acid properties ... and, in turn, it was difficult to create a dbms that would use standard filesystem operation and still satisfy acid properties.

the later generations of journal/logging unix filesystems tended to be just for filesystem metadata ... to somewhat avoid loosing the whole system because of filesystem corruption ... but still tended to retain traditional unix filesystem inconsistency characteristics for actual file data (distinct from filesystem meta/control data).

random search engine reference for acid properties
http://www.service-architecture.com/database/articles/acid_properties.html
https://en.wikipedia.org/wiki/ACID
http://databases.about.com/od/specificproducts/a/acid.htm

for a little topic drift ... system/r was the original relational/sql implementation
http://www.garlic.com/~lynn/submain.html#systemr

and one of the consumers of global lock manager for ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

was distributed database operation,

one of the things that posix (async) i/o attempted was to provide ability to use standard filesystem allocation/deallocation of disk surface but perform direct i/o (reads and writes) with direct control between the disk surface and processor memory space (bypassing most of the standard unix filesystem operations). posix i/o can be intertwined with memory mapped operation.

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Mon, 03 Oct 2005 22:56:41 -0600
Marco S Hyman writes:
I'd date them to the early 80s with the start of Apollo (1980) and Sun (1982). The Xerox Star came out about then, too. I think the Lilith was earlier. I remember being blown away by an Intergraph CAD system, also in the early 80s.

perq from 79
https://en.wikipedia.org/wiki/PERQ

when the people that wanted to build this new sun workstation thing came around ... i have vague recollection that one of the groups that evaluated the proposal had a bunch of perq that they were using.

i also remember some number of calmas
https://en.wikipedia.org/wiki/Calma

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

PCI audit compliance

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@GARLIC.COM>
Subject: Re: PCI audit compliance
Newsgroups: bit.listserv.ibm-main
Date: Tue, 4 Oct 2005 07:34:38 -0600
Jousma, David wrote:
Brian,

You don't mention it, but I'm assuming you are a RACF shop. If so, I have a password exit that allows enforcement of various password quality rules, like repeating characters, new pw to similar to old one, etc. It is very modular, so you could take out checks your company doesn't need. Let me know if you are interested.

Dave


for a little drift, from long ago and far away:
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.

lots of collected past posts on issues with shared-secret based authentication
http://www.garlic.com/~lynn/subintegrity.html#secret

and collected past posts on 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

part of the issue is that basic security principle is that unique, hard-to-guess and impossible to remember shared-secrets are required for every unique security domain (countermeasure for cross-domain contamination ... say like your local garage ISP login and you online banking service). This tends to be somewhat institutional-centric with every institution (security domain) assuming that it is the only "real" operation where you would have a hard-to-guess and impossible to remember password (and then multiply that times a couple dozen such environments).

some number of recent news URLs related to the subject

Password overload is costing money
http://www.theinquirer.net/?article=26653
Multiple passwords creating insecurity
http://www.computeractive.co.uk/computing/news/2143054/multiple-passwords-creating
Multiple passwords creating insecurity
http://www.itweek.co.uk/computing/news/2143054/multiple-passwords-creating
Multiple passwords creating insecurity
http://www.vnunet.com/computing/news/2143054/multiple-passwords-creating

VM tape definitions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM tape definitions
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 04 Oct 2005 07:46:51 -0600
Jim Bohnsack writes:
My "guess" is that the CE did not define any more than 8 devices in the 1025 CU (E60) and only 4 devices in the 1021 CU (5A0). The 3480 control units are sensed so the only info the system really has is what is returned to it. This is much better than having all 32 or 16 or whatever is the max number of devices for a 3480 CU defined to the physical CU and you only having 8 devices defined in the IOCDS. On occasion when the CU has some info to pass back to the OS, it will use an address in the high range that has been physically plugged into it and the IOCDS doesn't have an IODEVICE at that address. Then you get a funny error message saying that there is sense info but no place to stuff it into.

controllers used to have this situation called contingent connection after a unit check ... having only one place in the controller for holding status information ... they would expect the system to immediately do a sense operation on the address that had the unit check. If you attempted an operation on a different device address, the controller would return sm+busy ... and them a CUE interupt with the device address (on the controller) that had the pending sense information.

if there was a mismatch between the system configuration definition and the hardware ... you could get system hang &/or tight-loop.

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

transactional memory question

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: transactional memory question
Newsgroups: comp.arch,comp.programming.threads
Date: Tue, 04 Oct 2005 09:25:54 -0600
"Chris Thomasson" <_no_spam_cristom@no_spam_comcast._net> writes:
IMHO, I believe its too early in the game for actual hardware support, even though they really do need it in order for TM to become really useful. All of the software emulations I have seen are loaded with expensive atomic operations; mutexs seem more efficient...

early 801 had a form ... it was used by journal filesystem for aix in rs/6000.

filesystem metadata was organized ... and the memory system caught all changes ... so basically you avoided having to do all the explicit logging/locking statements in the filesystem code ... you did have to add commit calls.

there was some disagreement whether the overhead of explicit logs/locks were more expensive than the implicit overhead involved in transaction memory. turns out there was the overhead of scanning the whole memory area for changes at commits.

a portable version of the journal filesystem code with explicit lock/logging changes in the code turned up the explicit lock/logging calls had lower overhead than transactional memory (at least in the journal filesystem case).

and unrelated old reference from about same period as aixv3 ... the Proceedings of the 20th International Symposium on Fault-Tolerant Computing Systems, pp 89--96, Newcastle, June 1990.
A Fault Tolerant Tightly Coupled Multiprocessor Architecture based on Stable Transactional Memory

Authors: Michel Banatre and Philippe Joubert Abstract:

Traditionally, tightly coupled multiprocessors allow data sharing between multiple caches by keeping cached copies of memory blocks coherent with respect to shared memory. This is difficult to achieve in a fault tolerant environment due to the need to save global checkpoints in shared memory from where consistent cache states can be recovered after a failure.

The architecture presented in this report solves this problem by encapsulating the memory modifications done by a process into an atomic transaction. Caches record dependencies between the transactions associated with processes modifying the same memory blocks. Dependent transactions may then be atomically committed. Such an operation requires a cache coherence protocol responsible for recording process dependencies as well as keeping coherent cached copies of blocks and a shared Stable Transactional Memory owing to which all memory updates are atomic to allow recovery after a processor failure.


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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch
Date: Tue, 04 Oct 2005 12:08:48 -0600
Edward Wolfgram writes:
Tsk tsk. Really, this TSO bashing has got to stop. Uninformed lurkers here will think there is something wrong with TSO, and by extension, perhaps even MVS and mainframes!

it didn't start out to be TSO bashing ... the long wandering thread sort of started out that terminal emulation contributed to some signifcant product uptake for the ibm/pc ... but later, efforts to protect the installed terminal emulation business contributed significantly to opposing moving on to better solutions
http://www.garlic.com/~lynn/subnetwork.html#emulation

that SAA was part of the effort to help circle the wagons around the installed terminal emulation business ... attempting to stuff the client/server genie back into the bottle. we caused them heartburn at the time ... out doing customer executive presentations on 3-tier architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier

the 3274/3278 ref. was going back to some pre-ibmpc history (of the communication division). there had been some hardware hacks to the (3272/)3277 terminal ... that made it almost tolerable for interactive computing. the 3274/3278 was a regression from the basic 3272/3277 ... and because they moved a lot of the electronics (that had been in the 3277 terminal) back into the 3274 controller (cutting down on 3278 manufacturing costs), it made similar hardware hacks to the 3278 impossible.

complaining about how poor the 3274/3278 was for interactive computing ... got us a response back from the product group ... that the 3274/3278 wasn't intended for the interactive computing market segment ... it was for the data entry market segment ... and was better than keypunches. The TSO product group came down on the 3274/3278 side ... effectively taking the position that TSO had never been intended for the interactive computing market segment and/or never been intended to have better than 1 second response (and that was for strictly non-SNA, local, channel attached controllers).

that doesn't mean you couldn't do some tweaks and control the environment to improve on TSO operation ... but it was trying to use it for something that it wasn't intended for.

in the 1980 time-frame the standard TSO design-point was so well known ... that startups could get VC money for 3274-clones that did TSO offload ... attempting to provide a reasonably tolerable human interfacw where TSO was involved (by pre-handling some interactions in the 3274 controller clone ... as opposed to going all the way back to TSO).

now, up until about mid-85 ... the internal network was larger than the arpanet/internet ... from just about the beginning ...
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and the majority were non-MVS for various reasons ... in part because internal development made extensive use of non-MVS interactive computing ... even when MVS related development was involved (so a preponderance of internal systems were non-MVS). Another was that nearly all of the internal MVS systems were built with JES2 ... and used JES2 for MVS networking support ... and JES2 networking support had enormous limitations. a few, somewhat related postings
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#15 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#16 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#19 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#32 HASP/ASP JES/JES2/JES3

as an aside ... as an undergraduate ... I had modified an MVT/HASP system ... incorporating 2741 & TTY support into HASP and implementing HASP interactive interface ... borrowing CMS editor syntax for part of the design. This provided a lot of TSO-like functionality for doing program creation and submission. lots of past posts mention all sorts of HASP references
http://www.garlic.com/~lynn/submain.html#hasp

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

Job seperators

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Job seperators
Newsgroups: bit.listserv.vmesa-l
Date: Wed, 05 Oct 2005 13:39:27 -0600
Rich Smrcina writes:
Are printed job seperators an all or nothing sort of thing? I know that they can be turned off, but is there a configuration option to just print one page before and after a job, instead of two pages?

vm seperators were somewhat modeled after hasp ... for fanfold paper ... you had two pages at the start of the print item ... since you didn't know whether it was starting on a even or odd page. when the operators bursted the print stream into separate items you wanted a face-up separator page. with only one page before a print item ... on the avg., half the time it would be on a face down page ... and the face-up would be the back of the seperator page (people thumbing thru the stack would have a lot harder time recognizing what they were looking for. the trailing page after also had a solid block of chars at the bottom of the page ... when the operator pulled a couple foot stack of fan-fold paper from the printer ... there was some chance that the dark block of printed chars could be seen looking at the stack of paper from the side ... aiding the operator identify where to burst the stack of paper into separate items.

when sjr did some 6670 driver support for RSCS ... it did a single separator page from the alternate paper drawer (which was then loaded with colored paper ... eliminating the issue requiring dual starter pages with fan-fold so there is one face-up ... and block of chars on the bottom of the trailing page aiding the operator in finding start/end) ... with the traditional identification information. however, since the rest of the page was mostly blank ... there was special addition to pull a random entry from a ibm jargon definition file and print that. search engine found old online version:
http://www.212.net/business/jargon.htm

two early issues with the output 6670s distributed around bldg. 28 were:

1) one weekend somebody printed an "April 1st" corporate memorandum on corporate letterhead paper and had it in all the bldg. corporate bulletin boards monday morning.

2) during one audit by corporate security ... they were looking for confidential output being left at 6670s ... and they found a separator page with an item giving the definition of auditor ... which they took personally.

random past postings mentioning 6670 and/or jargon references:
http://www.garlic.com/~lynn/99.html#42 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#43 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000d.html#81 Coloured IBM DASD
http://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ?
http://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002e.html#45 REXX and its designer (was: IBM 7090 instruction set)
http://www.garlic.com/~lynn/2002h.html#7 disk write caching (was: ibm icecube -- return of
http://www.garlic.com/~lynn/2002m.html#52 Microsoft's innovations [was:the rtf format]
http://www.garlic.com/~lynn/2002o.html#24 IBM Selectric as printer
http://www.garlic.com/~lynn/2002o.html#29 6670
http://www.garlic.com/~lynn/2003b.html#19 Card Columns
http://www.garlic.com/~lynn/2003c.html#43 Early attempts at console humor?
http://www.garlic.com/~lynn/2003n.html#49 Rant (Re: Programmer's unpaid overtime)
http://www.garlic.com/~lynn/2003o.html#0 Weird new IBM created word
http://www.garlic.com/~lynn/2004c.html#1 Oldest running code
http://www.garlic.com/~lynn/2004c.html#23 Jargon Files Wanted
http://www.garlic.com/~lynn/2004d.html#13 JSX 328x printing (portrait)
http://www.garlic.com/~lynn/2004k.html#48 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#61 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#69 IBMism
http://www.garlic.com/~lynn/2004o.html#46 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#48 1403 printers
http://www.garlic.com/~lynn/2005f.html#51 1403 printers
http://www.garlic.com/~lynn/2005f.html#54 1403 printers
http://www.garlic.com/~lynn/2005g.html#19 DOS/360: Forty years

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

File path formats

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: File path formats.
Newsgroups: alt.folklore.computers
Date: Wed, 05 Oct 2005 14:58:36 -0600
Rob Storey writes:
IBM CMS:-

FILENAME FILETYPE FILEMODE

Name and Type are up to 8 characters each. Mode is 2 chars: Alpha+Numeric. The alpha indicates the letter assigned to the minidisk via a previous "access" command, the numeric indicated access mode (usually "1", can't remember what the values mean).


from my trusty 1968 CP67/CMS users manual

0      ... only shows with r/w access, doesn't appear with r/o access
1 or 5 ... file may be written or read
2 or 6 ... file is read-only
3      ,,, file may be written or read, but is erased when file is closed
4      ... file is read-only, and is erased when the file is closed

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

Symbols vs letters as passphrase?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Symbols vs letters as passphrase?
Newsgroups: comp.security.misc
Date: Wed, 05 Oct 2005 18:57:12 -0600
Peter Frank writes:
The encryption software I use offers me two choices for entering a passphrase: 1) an ordinary password consisting of letters, numbers and/or special characters 2) 10 symbols that can be clicked in any order to form a "passphrase"

How safe is a "passphrase" consisting of maybe 15 symbol clicks compared to a password consisting of 15 letters, numbers and/or special characters?

Let's assume the password was chosen carefully, so it contains no known words or derivations thereof, and special characters and numbers were used.

Is the password safer because there are many more letters, numbers, and special characters than symbols to choose from?


"safe" can be a combination of several things. creation of passwords that are totally impossible to remember ... make them harder for an attacker to guess ... but also result in human's writing them down ... providing an attacker with more than one avenue for obtaining the password.

shared-secret passwords also have a requirement that unique shared-secrets are required for different security domains (cross-domain compromise ... i.e. the password at your local garage ISP being the same as your online banking access). difficulty of memorizing goes up both as the complexity of the password as well as the number of different passwords. i got my first password nearly 40 years ago ... and at the time, I only had one. Now I'm faced with managing scores of passwords. then if they have to be changed every month, the problem can reach truely hopeless state:
http://www.garlic.com/~lynn/subintegrity.html#secrets

then there are the rules excluding certain values ... here is an corporate directive April 1st version from over 20 years ago ... parody explains how there is only one acceptable password.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM

some recent news articles ... effectively institutional-centric paradigm running afoul of person related limitations.

Password overload is costing money
http://www.theinquirer.net/?article=26653
Multiple passwords creating insecurity
http://www.computeractive.co.uk/computing/news/2143054/multiple-passwords-creating
Multiple passwords creating insecurity
http://www.itweek.co.uk/computing/news/2143054/multiple-passwords-creating
Multiple passwords creating insecurity
http://www.vnunet.com/computing/news/2143054/multiple-passwords-creating
Now, what was my September password?
http://www.purdueexponent.org/index.php/module/Issue/action/Article/article_id/1168
Too Many Passwords
http://it.slashdot.org/it/05/09/27/1935210.shtml?tid=172&tid=218
Authentication | Password Overload Makes Enterprise Systems Less Secure
http://www.techweb.com/wire/security/171201073
Password overload plagues US.biz
http://www.theregister.com/2005/09/27/password_overload_survey/
Password Overload Makes Enterprise Systems Less Secure
http://news.yahoo.com/s/cmp/20050928/tc_cmp/171201073;_ylt=A9FJqZNytzpDEWgAlgYjtBAF;_ylu=X3oDMTBiMW04NW9mBHNlYwMlJVRPUCUl
Survey shows signs of security password overload
http://www.cbronline.com/article_news.asp?guid=7778865B-DD3A-4230-9968-83244D713FBE
Password overload plagues US.biz
http://www.securityfocus.com/news/11331

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

How does the internet really look like ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How does the internet really look like ?
Newsgroups: comp.dcom.sys.cisco,comp.protocols.tcp-ip
Date: Thu, 06 Oct 2005 10:48:59 -0600
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
Packets between two different major providers cross on "multihomed" routers that are run in cooperation with both providers. Often there will be several such crossover points ("peering"). For any one packet in transit, the choice of cross-over point depends upon the policies (and charging structures!) agreed upon between the providers, and upon which links are reachable and not overloaded at the time.

a couple recent news items regarding glitches w/peering:

Internet Partitioning - Cogent vs Level 3?
http://ask.slashdot.org/askslashdot/05/10/05/2247207.shtml?tid=95&tid=187&tid=4
Level 3 depeers Cogent
http://www.theregister.com/2005/10/06/level3_cogent/
Level 3 Peering Changes Causing Headaches; Roadrunner, Cogent users unable to hit major sites
http://www.anandtech.com/news/shownews.aspx?i=25035

when we were doing original payment gateway
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we were looking at some of the availability issues ... with things like multi-homing, replicated components, multiple paths into different parts of top level infrastructure, etc. ... in part, having previously done ha/cmp project
http://www.garlic.com/~lynn/subtopic.html#hacmp

right in the middle of that, there was decision to migrate to hierarchical routing policy ... because the purely dynamic routing tables weren't scaling as the internet size grew ... aka some of the stuff that could have been done for high availability with dynamic routing advertisement ... went away. at that point ... the primary remaining strategy was multiple A-record support. since we had some amount of sign-off ... we could mandate it for the webservers to the payment gateway. however, we for webserves and e-commerce, it was also important for browsers to also support multiple A-record support.

A trivial example was an early major e-commerce website was sports related ... which did some major advertisement and offerings during Sunday afternoon football ... and hoping to get traffic during half-time. Their ISP at the time was still into taking down major city centers on Sunday afternoon for various maintenance tasks. They needed alternate paths to major internet backbone ... and browsers capable of tracking alternate paths. It didn't do much good to have redundant links into carefully selected points from various ISPs ... if the basic infrastructure couldn't deal take advantage of the redundant links.

a major feature of the IMP-based arpanet in the 70s was dynamic route finding. The IMP operation formed a homogeneous infrastructure ... with the IMPs interconnected by 56kbit links. There were folklore stories in the late 70s that the IMP dynamic routing infrastructure overhead was sometimes consuming 40kbit-50kbit of the available 56kbit with dynamic routing information chatter (another case where dynamic routing was having difficulty scaling).

the switch-over from homegeneous networking to internetworking and gateways was on 1/1/83. This is part of my frequent postings that the internal network was larger than the internet/arpanet from just about the beginning until mid-85 ... in part because the major nodes in the internal network had effectively a form of gateway support from the beginning
http://www.garlic.com/~lynn/subnetwork.html#internalnet

the transition to modern internet as an operatinal characteristic ... as opposed to technology transition (aka 1/1/83) was with the NSFNET backbone
http://www.garlic.com/~lynn/2002k.html#12 NSFNET Program Announcement
http://www.garlic.com/~lynn/2000e.html#10 NSFNET Award Announcement

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

The 8008

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.computers
Date: Thu, 06 Oct 2005 14:04:13 -0600
Andrew Swallow writes:
Or an old Hong Kong style government. The one before Hong Kong returned to China.

ha/cmp early adopters were in the far east
http://www.garlic.com/~lynn/subtopic.html#hacmp

and spent some amount of time in HK, staying over on the Kowloon side and walking down to the star ferry in the morning to take across the bay.

some number of asians expressed some opinion of descrimination by the British ... some estimates that being British was worth 30 percent business premium over asians (in HK). as a result there were some comments that it might be hard to decide which might be better (or worse) given the upcoming change of control (at least if you were non-british).

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

logical block addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: logical block addressing
Newsgroups: alt.folklore.computers
Date: Thu, 06 Oct 2005 14:43:37 -0600
"Tim Shoppa" writes:
I wouldn't say that. But I would say that posting a Wiki "answer" that only deals with PC-clones to an a.f.c thread expressly dealing with Lasnerian 1960's technology is useless.

Other Wiki articles are not too far off the mark with respect to technology history. They aren't always written from my viewpoint but they are in some way or another relevant.


in posting to comp.arch thread
http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design

noted that a wiki article on power/pc ... claimed that POWER was retrofitted to RIOS after the advent of power/pc ... even tho POWER was used from the very start with RIOS ... and power/pc didn't show up until later ... after the onset of somerset to develop power/pc
https://en.wikipedia.org/wiki/PowerPC

aka power/pc was created to differentiate a single chip (simpler) version of power ... "POWER" already was inuse extensively to describe RIOS/RS6000. I have a clear green-tinted plexiglass paper weight on my desk that was used to commemorate original POWER/RS6000 announce ... has six chips and legend
"AWD Austin & GTD Burlington" "POWER Architecture"

above the six chips and
150 Million OPS 60 Million FLOPS 7 Million Transistors

below.

some number of past posts mentioning somerset
http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2001g.html#23 IA64 Rocks My World
http://www.garlic.com/~lynn/2001i.html#28 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001j.html#37 Proper ISA lifespan?
http://www.garlic.com/~lynn/2002g.html#12 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#14 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002l.html#37 Computer Architectures
http://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
http://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
http://www.garlic.com/~lynn/2004.html#28 Two subjects: 64-bit OS2/eCs, Innotek Products
http://www.garlic.com/~lynn/2004d.html#1 IBM 360 memory
http://www.garlic.com/~lynn/2004k.html#39 August 23, 1957
http://www.garlic.com/~lynn/2004q.html#36 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#40 Tru64 and the DECSYSTEM 20
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005e.html#7 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#13 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005o.html#37 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design

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

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
Newsgroups: sci.crypt
Date: Fri, 07 Oct 2005 16:15:27 -0600
tomstdenis writes:
Such a language exists?

note that this periodically gets repeated ... some collected posts from a year ago ... and prior years
http://www.garlic.com/~lynn/subintegrity.html#overflow

however there are languages and environments where the frequency of such things happening are drastically smaller (possibly two orders of magnitude smaller) for this class of mistakes.

i was involved in a tcp/ip stack implementation in the 80s that was done in pascal ... and was not known to have any of the overflow vulnerabilities that seem to be so common. in part, because a lot of the buffer-to-buffer type operations didn't depend on the programmer having to manage the bounds of the target ... it was built into the operations. as a result, there were significantly fewer situations where the opportunity for making target length related mistakes.

I've also been involved in purely assembler-based implementations where the underlying environmental bounds semantics existing for all buffers ... and it was standard programming convention to always utilize the target bounds/lengths.

In one case, the target bounds/lengths were built into the programming language ... and in the assembler case, the related environment (libraries, standard system features, etc) established programming convention that encouraged the use of bounds paradigm on all operations. In both situations, while the environment didn't absolutely prevent bounds violations ... the frequency of bounds violations were something like two-orders of magnitude less.

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

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
Newsgroups: sci.crypt
Date: Fri, 07 Oct 2005 17:16:02 -0600
tomstdenis writes:
How hard is it to do checks as you decode fields? e.g. you know your input is "inlen" bytes and you just decoded a field length 'k'. Check if k+current_read>inlen ... not hard.

the standard C convention is that a target buffer doesn't have an infrastrcture related length ... it tends to be totally the responsibility of the programmer.

this is compounded by the fact that source buffers have a length paradigm based on data pattern within the buffer ... aka i've seen programmers who get into the habit of relying on the source buffer having an implicit length. this comes into conflict with two different length paradigms ... source length paradigm is self-describing and target length paradigm is totally programmer responsibility.

the past analogies are motor vehicle accidents ... there are lots of ways to have motor vehicle accidents ... but infrastructure tends to look at the most common and create countermeasures for them. In 1999, the statistics were that half the exploits were because of buffer length related issues ... last year the percent seemed to drop to possibly 20 percent ... not because the buffer related problems have gone down ... but that some other types of exploits have increased

now, one analogy of having two separate buffer length paradigms at work in a single environment ... source buffers tending to have length caracteristics as part of the data and not normally programmer specified ... and target buffers having length paradigm that is totally the responsibility of the programmer ... would be to have two different driving conventions ... on even days ... people are to drive on the right and on odd days ... people are to drive on the left. Certain types of conventions can be shown to increase the frequency and probability of mistakes (one is having multiple conventions related to the same characteristic).

Now, in the past, there have been suggested that only people who don't have accidents be allowed to drive. However, in reality, there are some compromises ....you do try and get the drivers that are excessively accident prone off the roads, but at the same time, conditions that appear to contribute to frequency of accidents are monitored and attempt is made to create countermeasures for things that appear to be significant accident contributing factors.

I would suggest that the probability of mistakes in some other programming environments (which don't even have to be implicit part of the language ... but could be assembler where there is a consistent length paradigm) is lowered when there is a single consistent length paradigm for all buffers ... both source and target. There are some further advantages when there is a single length paradigm AND many opportunities for human mistakes are eliminated ... i.e. the underlying infrastructure facilities take on some amount of length/bounds responsibility.

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

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
Newsgroups: sci.crypt
Date: Fri, 07 Oct 2005 21:01:28 -0600
from previous threads on buffer overflow
http://www.garlic.com/~lynn/subintegrity.html#overflow

one of the posts from start of the year (in thread that starting nearly a year ago) .... one of the refs. i mentioned from just published article in linux magazine
http://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns

Oct. 2005 C/C++ Users Journal has article, Managed String Library for C, pg. 30
Many of the vulnerabilities in existing C code ... because these functions are standard, they continue to be supported .... often to detrimental effect.

.. snip ...

my assertion that it is more than just an issue of the library routines ... it can also be viewed as an issue that the data-pattern based length paradigm ... is an incomplete paradigm ... since the same paradigm can't also be used for areas that don't contain any data ... and that fewer mistakes are made when there is a single standard paradigm for treating a construct (and can be considered separate from the issue of standard system routines providing uniform and consistent support for the paradigm).

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

IEH/IEB/... names?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IEH/IEB/... names?
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Sun, 09 Oct 2005 09:09:39 -0600
jeffj@panix.com wrote:
Perhaps you know the answer: long ago I used IBM mainframes. Utilities started with IEH, IEB, etc. What were the rules for those prefixes?

I remember IEHLIST (list files) and IEBGENER (file copy). Wasn't IEHBR14 the null program so the JCL's DD side-effects could occur (such as file creation or deletion)?


trusty search engine turns up:
http://64.177.8.214/sitepages00/PrRefComponentID.html
other references from the above site
http://64.177.8.214/sitepages00/PrMainframeReferenceTop.html

when i did the resource manager, there was a new module that i named DMKSTP (tv adverts in the 60s ... muscle cars and the line, the racer's edge)

misc. past posts mentioning dmkstp
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/2001e.html#51 OT: Ever hear of RFC 1149? A geek silliness taken wing
http://www.garlic.com/~lynn/2003.html#20 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#21 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#23 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#27 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003k.html#11 humor in source code
http://www.garlic.com/~lynn/2003k.html#12 humor in source code
http://www.garlic.com/~lynn/2004m.html#45 Multi-processor timing issue
http://www.garlic.com/~lynn/2004n.html#2 Multi-processor timing issue

os/360 stage1 sysgen was bunch of macro statements (done by the customer) that when assembled executed a large number of PUNCH statements ... that resulted in about a box of cards (2000) .. that were a large number of job steps for stage-2 sysgen. A significant number of the programs generated were IEHMOVE and IEBCOPY statements. I did quite a few sysgens ... where i completely re-orged the stage-2 sysgen output ... instead of one job ... produce job cards for each step, and rework things so i could run it in a standard production job stream (instead of under the starter system), and reordered both program execution sequence and the iehmove/iebcopy statements for careful placement of files and library members on disks for optimized disk arm motion. misc. past posts mentioning stage-2 sysgen work
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
http://www.garlic.com/~lynn/2001d.html#48 VTOC position
http://www.garlic.com/~lynn/2001h.html#12 checking some myths.
http://www.garlic.com/~lynn/2001l.html#39 is this correct ? OS/360 became MVS and MVS >> OS/390
http://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#51 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2003c.html#51 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005h.html#6 Software for IBM 360/30 (was Re: DOS/360: Forty years)
http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
http://www.garlic.com/~lynn/2005n.html#40 You might be a mainframer if... :-) V3.8
http://www.garlic.com/~lynn/2005o.html#12 30 Years and still counting
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design

iefbr14 reputed to have highest ratio of bug fixes per instructions it wasn't quite null, it originally just had BR R14 instruction ... and possibly 1st bug fix was clear R15 so the condition code was set (for JCL that would be testing condition code).

some past posts mentioning iefbr14
http://www.garlic.com/~lynn/99.html#81 Perfect Code
http://www.garlic.com/~lynn/99.html#85 Perfect Code
http://www.garlic.com/~lynn/99.html#96 IEFBR14 cookie from www.ibm.com
http://www.garlic.com/~lynn/2001e.html#60 Estimate JCL overhead
http://www.garlic.com/~lynn/2001n.html#48 The demise of compaq
http://www.garlic.com/~lynn/2003m.html#15 IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#34 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#35 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003o.html#23 Tools -vs- Utility
http://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
http://www.garlic.com/~lynn/2004.html#8 virtual-machine theory
http://www.garlic.com/~lynn/2004.html#52 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
http://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
http://www.garlic.com/~lynn/2004e.html#51 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004k.html#37 Wars against bad things
http://www.garlic.com/~lynn/2004l.html#65 computer industry scenairo before the invention of the PC?
http://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
http://www.garlic.com/~lynn/2005b.html#5 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005c.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#41 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#9 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#28 NASA Discovers Space Spies From the 60's
http://www.garlic.com/~lynn/2005k.html#43 Determining processor status without IPIs

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 09 Oct 2005 12:40:26 -0600
Larry Elmore writes:
I used to have the 4.4BSD version till someone "borrowed" it. I remember it as quite interesting and I wish I still had it to compare with the new "Design and Implementation of FreeBSD 5.2" book.

I think I have a copy of 4.3reno source distribution someplace in the archives.

we had been asked to do some consulting with this small client/server startup that wanted to do some payment transactions on the internet
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

there were concerns about internet partitioning ... both simple technical failures ... as well as because of possible business issues; recent reference
http://www.garlic.com/~lynn/2005r.html#32 How does the internet really look like?

in the middle, the backbones decided to transition to a hierarchical routing policty (in part because of the massive scaling issues).

we were faced with putting together compensating procedures for the internet ... in an attempt to approximate industrial strength dataprocessing. around that time ... part of a major online services started crashing with resource exhaustion. numerous people looked at it for two months ... before we were asked about it. turns out it was one of the standard things that somewhat came out of the detailed vulnerability studies that were part of our ha/cmp product work
http://www.garlic.com/~lynn/subtopic.html#hacmp

this was almost exactly a year before the big DOS-attack showed up in the press. even later i got invited to give a isi/usc graduate student seminar on why the internet wasn't industrial strength dataprocessing.

in any case, one of our requirements was supporting multiple A-records. we got pushback from some of the people at this small client/server startup ... with comments that it was way too advanced programming (possibly because it wasn't taught in any college entry tcp/ip programming course?). I pulled out some 4.3reno client source to show that it had been around at least since 4.3reno.

random past posts mention 4.3tahoe or 4.3reno
http://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#51 APPC vs TCP/IP
http://www.garlic.com/~lynn/2000b.html#45 OSA-Express Gigabit Ethernet card planning
http://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
http://www.garlic.com/~lynn/2002h.html#5 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002o.html#32 I found the Olsen Quote
http://www.garlic.com/~lynn/2002o.html#40 I found the Olsen Quote
http://www.garlic.com/~lynn/2003c.html#21 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003d.html#37 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2004n.html#46 ARP Caching

random past posts mentioning multiple a-record support;
http://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#16 Old Computers
http://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2002.html#23 Buffer overflow
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002.html#34 Buffer overflow
http://www.garlic.com/~lynn/2003.html#30 Round robin IS NOT load balancing (?)
http://www.garlic.com/~lynn/2003.html#33 Round robin IS NOT load balancing (?)
http://www.garlic.com/~lynn/2003c.html#8 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#12 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#25 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment
http://www.garlic.com/~lynn/2004k.html#32 Frontiernet insists on being my firewall
http://www.garlic.com/~lynn/2004o.html#53 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005f.html#55 What is the "name" of a system?
http://www.garlic.com/~lynn/2005g.html#21 Protocol stack - disadvantages (revision)
http://www.garlic.com/~lynn/2005n.html#5 Wildcard SSL Certificates
http://www.garlic.com/~lynn/2005n.html#34 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?
http://www.garlic.com/~lynn/2005r.html#32 How does the internet really look like ?

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

IEH/IEB/... names?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IEH/IEB/... names?
Newsgroups: bit.listserv.vmesa-l
Date: Mon, 10 Oct 2005 11:40:26 -0600
"Schuh, Richard" writes:
Yes, it was apparently a very low priority bug. And it took a long time to convince someone that it was broken. It wasn't fixed until the last release that I installed. It probably got fixed because of a big effort to clean up all of the open APARs before calling it a stabilized system.

ref:
http://www.garlic.com/~lynn/2005r.html#38 IEH/IEB/... names?

iefbr14 had a number of apars (and fixes) ... clearing r15 wasn't the only one. if i remember right, there was also an apar about failing to mark it "rent" ..

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

winscape?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers,alt.lang.asm
Date: Tue, 11 Oct 2005 10:52:19 -0600
jmfbahciv writes:
My speculation about this is that almost 100% of DEC workers used a form of the philosophy of Boyd's tactics to get the work done. When this approach started to disappear, then all the mess began to happen. Have you read any of the books that are about Boyd? It touches on your other post about knowing when to cut corners or break the rules.

so, I couldn't resist, Boyd had this briefing Patterns of Conflict, I still have several original copies from the early 80s ..

here is online scanned from '86 version
http://www.d-n-i.net/boyd/pdf/poc.pdf

misc. Boyd postings
http://www.garlic.com/~lynn/subboyd.html#boyd
and numerous Boyd references from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2

and for even more drift, reference to Schelling's book, The Strategy of Conflict
http://www.tgdaily.com/2005/10/11/the_strategy_of_conflict/

Harvard University Press: The Strategy of Conflict
http://www.hup.harvard.edu/catalog/SCHSTX.html

a couple other recent Schelling references from around the web:

Schelling points
https://www.financialcryptography.com/mt/archives/000565.html
Is technical trading a Schelling point?
https://www.financialcryptography.com/mt/archives/000566.html
Game theory's recognition
http://www.business-standard.com/common/storypage.php?storyflag=y&leftnm=lmnu5&leftindx=5&lselect=1&chklogin=N&autono=202721
Game theory in economics analysis merits Nobel Prize
http://www.kentucky.com/mld/heraldleader/news/world/12870744.htm
Aumann and Schelling defined chess-like strategies in politics and business that can be applied to arms races, price wars and actual warfare.
http://www.eitb24.com/noticia_en.php?id=96125
Nobel rewards 'game theory'
http://seattletimes.nwsource.com/html/nationworld/2002553075_nobel11.html
Where game theory ends, human nature takes over
http://www.investors.com/breakingnews.asp?journalid=32157114&brk=1

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

winscape?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers,alt.lang.asm
Date: Tue, 11 Oct 2005 11:16:02 -0600
Morten Reistad writes:
I have identified these "dialects" :

TrueBlue Disks called Dasdee, etc. Followed in the trueblue and clone companies. Talks about IPL's, SYSGENs, ABENDS etc.

Route128 MIT-centric, followed by DEC, Prime, DG etc. Now mostly extinct. refers to kernels as "monitor" etc. Was also used by people in the CP/M world. Requires strong theory background to follow this completely.

California Centered on Stanford, and Sun/Mips/SGI, has become pretty mainstream with the advent of Unixen. Now used almost exclusively in academia. Tends to use simpler terms

Redmond Used by this weird upstart company in Washington state. No doubt they will soon change and use the Sun/SGI dialect just like the rest of us.

Gamers tend to have a persistent "colloquial" name for things. Like saying that Satellite links have bad pings.


so here is one
http://www.212.net/business/jargon.htm mentioned in recent post
http://www.garlic.com/~lynn/2005r.html#29 Job seperators

and of course CP67 (precursor to vm370, z/vm, LPARs, etc) was control program (360/)67 ... but it was on 4th floor, 545 tech sq. ... which traces common precursor w/multics (on the 5th floor) back to ctss. (but then unix supposedly has multics as precursor which in turn traces back to ctss)

and then the CP/M control program ...
http://www.garlic.com/~lynn/2004b.html#5 small bit of cp/m & cp/67 trivia from alt.folklore.computers n.g. (thread)
http://www.garlic.com/~lynn/2004e.html#38 [REALLY OT!] Overuse of symbolic constants
http://www.garlic.com/~lynn/2004h.html#40 Which Monitor Would You Pick??????

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

Numa-Q Information

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Numa-Q Information
Newsgroups: alt.os.development,comp.arch
Date: Tue, 11 Oct 2005 16:44:21 -0600
"Brendan" writes:
I'm looking for information (datasheets, specifications, standards, etc) regarding the IBM/Sequent Numa-Q architecture.

numa-q was one of the sci 64-port memory things ... convex did one with 64 2-way pa/risc boards (128 pa/risc processor), sequent and DG did ones with 64 4-way intel processor boards (256 intel processors).

convex did a mach flavor (aka similar mach to what was in NeXT and apple).

sequent did version of their dynix ... all this well before IBM bought sequent.

We went to sci meetings ... but since power/pc wasn't out yet ... there was no processor chip that supported cache consistency ... that was somewhat why we did ha/cmp ... from cluster standpoint ... since we could do scale-up w/o requiring cache consistency stuff.
http://www.garlic.com/~lynn/subtopic.html#hacmp

sci web site
http://www.scizzl.com/

some random past sci postings:
http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query
http://www.garlic.com/~lynn/2002j.html#45 M$ SMP and old time IBM's LCMP
http://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2004.html#1 Saturation Design Point
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005f.html#18 Is Supercomputing Possible?
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005n.html#4 54 Processors?
http://www.garlic.com/~lynn/2005n.html#6 Cache coherency protocols: Write-update versus write-invalidate
http://www.garlic.com/~lynn/2005n.html#38 What was new&important in computer architecture 10 years ago ?

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Tue, 11 Oct 2005 18:36:10 -0600
Peter Flass writes:
This is an architecture problem. Consider Multics; I believe the system used the same page tables for all users of a segment, so the TLB could be handled differently vs. loading a new set of page tables for each process. Also, why not multiple register sets? The XDS Sigma systems, among others, had that back in 1970. Why not one set per ring on the user side, and another set for interrupt processing. No need to save/restore on interrupts, just pick up the register pointer from whatever the equivalent of a PSW is. A user calling inner rings would also not need to save or restore. The kernel would do this only when it dispatched another process.

370 virtual memory architecture was originally defined in such a way that TLB entries could be either STO-associative (aka address space) or PTO-associative (aka segment) ... but only STO-associative machines were actually built (aka many 370 operating systems would use common page table for segments shared across multiple virtual address spaces ... but furthermore, the 370 architecture was even defined such that such entries could also result in the same TLB entries).

370/168 TLB had 128 entries and was sto-associative (i.e. virtual address space). Each TLB entry had a 3-bit tag ... which corresponded to a 7-entry stack of saved segment table origin pointer (aka STO). If you changed STO register value ... it would look in the STO stack for match ... if not found, it would select a STO stack entry for replacement ... and purge all TLB entries that were associated with that entry (matching 3bit identifier).

peachtree ... which was used for series/1 ... had four level set of registers ... so it didn't need to save registeres between levels.

801 starting in the mid-70s
http://www.garlic.com/~lynn/subtopic.html#801

which was somewhat in re-action to the horrible complexity of future system project (which was canceled w/o ever being announced)
http://www.garlic.com/~lynn/submain.html#futuresys

... in any case 801 ... had inverted tables and sizteen segment registers ... basically ... at least on romp ... you loaded a 12bit segment identifier ... and the TLB was segment identifier associative. this is somewhat where the 40-bit addressing write-up came from ... take the top 4 bits of the 32bit virutal address and select a segment register ... take the 12bit segment-id from the segment register and combine it with the remaining 28bits from the virtual address ... to get a 40bit "address". this sort of got contorted when trying to map unix (aka aixv2) on top of romp for pc/rt (instead of the cp.r virtual memory paradigm). some of this could still be lingering around for rios ... where the segment-id value was expanded to 24bits and some of the original rs6000/power documentation talks about 52bit addressing (as expansion of the 40bit address described for romp).

so for unix ... the 801 segment register values needed to be manipulated to simulate the more familiar virtual address space page tables (instead of a generalized virtual memory pieces appearing and disappearing with fairly high frequency). however, in this case, since the virtual address space was simulated with the segment-ids in the 16 segment registers ... they all have to be saved/restored in a context switch.

When I was doing the original fastpath work in the cp67 interrupt handlers ... there were cases where i could play games with what registers i needed to save and restore ... because, in some cases the interrupt might be handled directly w/o a real context switch ... and I would try and be very sparingly of what registers were used during the interrupt processing (aka analogous to some optimization of register save/restore that might be done in a subroutine call).

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

Password Requirements - VM:Secure

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Password Requirements - VM:Secure
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 11 Oct 2005 18:47:31 -0600
Karl Severson writes:
The government has proclaimed new password requirements which are: at least eight characters in length, alphanumeric (at least one of which should be a capital letter) and special characters. I have the latest VM:Manager release (2.8, I think). I can't find this anywhere in the documentation CD that came with this release but will the latest VM:Secure force users to these above password requirements or do I have to write a "front end" script to be legal? There's a file on VM:Secure's 191 disk called PASSEXIT EXEC which does some of this (pw length and reuse control) on our current release (2.5A) and I figure this is the EXEC which will need to be modified to do the new stuff if it's even possible.

some topic drift from recent thread in ibm-main
http://www.garlic.com/~lynn/2005r.html#25 PCI audit compliance

and some rules from long ago and far away
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.

there has been a recent side thread ... that most of the password rules 1) make it hard for you to remember and 2) reduce the brute force domain space .... aka rules reduce the total number of possible passowrd combinations that would have to be checked by a brute force attack. in fact, the above april 1st reference somewhat highlights this by requiring an 8-character password ... but observing that with all the rules ... there is only a single valid character combination that satisfies all possible rules.

and, of course, lots of collected postings on general characteristics of shared-secret authentication mechanisms
http://www.garlic.com/~lynn/subintegrity.html#secret

and other collected postings on general subject of 3-factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor

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

Numa-Q Information

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Numa-Q Information
Newsgroups: alt.os.development,comp.arch
Date: Tue, 11 Oct 2005 20:26:10 -0600
"Del Cecchi" writes:
Back in those days, the processors were groups of chips and Rochester was going to NUMA the AS400 until a certain IBM Fellow convinced the Powers and Principalities that we couldn't possibly pull it off because POK had hundreds of folks doing sysplex so our estimates must be incorrect. So AS400 did a 24 way SMP and the numa thing got killed, but was reincarnated as the Summit Xseries stuff. This was in the early 90's, pre powerPC. There was an intermediate effort with Austin for RS but it died with a change in management.

i think we have just the bare tip of the iceberg here

very strong memory consistency was so very strongly ingrained in certain quarters ... in part the whole 801 non-cache consistency was to take the opposite extreme (can't have smp operation at all).

this is my sporadic reference to the pok advance tech conference in 1976 ... where we talked about 16-way 370 smp w/o strong memory consistency ... and it was the first time i saw the 801 presentation.

the 16-way wasn't strong memory consistency ... and eventually some of mvs proponents realized that it would never be a mvs machine. we had co-opted some of the 3033 processor engineers to do this as spare time effort. i think they may have then got counseling about remaining focused (3033 wasn't shipping yet and didn't even have a working engineering model). some people got told they were no longer welcome on pok plantsite.

there was some issue with the concept of a spectrum of memory consistency ... as opposed all or nothing.

there was some rumors that early 370 smps had some special fixes for immediate instructions ... and-immediate, or-immediate, etc. the original 360 smp serialization instruction was test&set.

charlie invented compare&swap at the science center doing some smp fine-grain locking work on cp67 (had to come up with compare&swap because CAS are charlie's initials)
http://www.garlic.com/~lynn/subtopic.html#smp

which also made it into 370. in any case, none of the immediate instructions are defined as smp consistent (they do byte operate fetch, modify, store) ... but the rumor was that their use in certain operating system kernels was so pervasive and couldn't be corrected ... that the hardware may have been required to fix kernel memory consistency issues related to the use of immediate instructions (lot of flag, bit, and status maintenance).

another rumor was that the caches in 3090s ran ten times faster cycle than the standard machine cycle ... in order to provide all the stuff for strong memory consistency. pok was beginning to face needing to have infinitely fast cache machine cycle for their scale-up (since there was enormous amounts of cross-cache chatter going on between all the processor caches). two-way 370 smp machines started off running base machine cycle ten percent slower than uniprocessor .... just so the caches could process all the cross-cache chatter from one other cache. going to six-way smp met that a cache was getting cross-cache chatter from five other caches ... implying that the machine cycle possibly has to be cut in half ... or the caches had to run much, much faster than the rest of the machine. trying to come up with caches that operate infinitely fast was indeed consuming large amounts of resources.

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

MVCIN instruction

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MVCIN instruction
Newsgroups: bit.listserv.ibm-main
Date: Tue, 11 Oct 2005 21:42:30 -0600
edgould@ibm-main.lst (Ed Gould) writes:
IIRC the model 30 & 1419 were exceeding time dependent you had x many micro seconds to make the decision to ell the 1419 to direct the document to the correct hopper. IIRC TR was one of the slower instructions on the mod 30. Its been *YEARS* and I could be wrong but TR could not be used (if you wanted to get the check into the right sort bin).

TR and TRT were really slow on some number (all?)of 360s ... where it was actually possible to do the register setup and a ic, ic, stc, bct type loops. TR/TRT has (up to) 256 byte table operand. over the years ... additional hardware allowed all instruction hardware implementation to achieve near optimal operation.

somewhere in the past there was engineering bug reported for TR/TRT about the table crossing storage boundary. tr/trt instructions are non-interruptable ... they either have to start or not start. it use to be that the test was just starting & ending storage locations for available as to whether it could execute or not execute (and tr/trt assumed to always have 256 byte table operand).

the fix now has it test to see if the table start is within 256 bytes of a boundary ... and if it is, it will pre-execute the instruction byte at a time to see if any operand would result in instruction referencing storage across the boundary. Then it possible either re-executes the instruction or doesn't execute the instruction (and generates an interrupt).

a simple case is whether the table crosses a page boundary and if a page fault needs to be generated (and handled) before starting execution of the instruction. the original hardware implementation always assumed a 256byte table operand ... and would possibly generate unnecessary page faults. now "short" tables that don't require the full table on the other side of the storage boundary won't cause unnecessary interrupt.

now short tables that start within 256 bytes of the end of the storage area have correct execution ... but is a lot slower because of the pre-execution pass (to see whether or not is necessary to generate an interrupt before starting (real) instruction execution)

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

winscape?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers,alt.lang.asm
Date: Wed, 12 Oct 2005 09:01:15 -0600
Bernd Felsche writes:
And I said 100 milliseconds; i.e. one tenth of a second. If you're typing on screen and not using some obnoxious software that's trained you otherwise; or over a slow remote link imposing echo delays; then 0.1 seconds between keypress and the letter appearing on-screen is quite tardy.

a couple recent posts in another n.g. that mention system and character response times.
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#19 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#28 Intel strikes back with a parallel x86 design

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

MVCIN instruction

Refed: **, - **, - **, - **, - **, - **
From: lynn@ibm-main.lst (Anne & Lynn Wheeler)
Subject: Re: MVCIN instruction
Newsgroups: bit.listserv.ibm-main
Date: 12 Oct 2005 07:54:02 -0700
McKown, John wrote:
ave you seen the new instructions "Load Reversed" and "Store Reversed"? I don't know what hardware is required, likely a z-box, but they do exactly what you need to do the "endian change".

long ago and far away ... i was trying to add tty/ascii to cp67's (2741 & 1050) terminal support. it had logic to do automatic terminal recognition and (re)set the appropriate line-scanner on the 2702. I tried to add tty support in such a way that it would do automatic terminal recognition across 2741, 1052, & tty/ascii. it really worked .. as long as it was fixed-wired terminals. i also wanted to do the support for dailed ... so that a single phone number could be used for all terminals. this ran into a problem with the 2702 ... because while it was possible to dynamically change the line-scanner on each address/port ... the baud rate was fixed by hard-wired oscillator.

this somewhat prompted the univ. to start project to build a clone controller (and four of us are written up somewhere as prompting the clone controller business) ... where we would implement both dynamic terminal recognition but also dynamic baud rate determination
http://www.garlic.com/~lynn/subtopic.html#360pcm

one of the first bugs was with the channel interface board. the 360/67 would red-light if the high-resolution timer attempted to update loc. 80 on a timer tic ... and there was already a timer-tic update pending. the issue was that the channel interface board had to regularly release the memory bus ... to provide window for the location 80 timer update.

the next bug that i remember was that we found the data coming into memory was totally garbeled. it turned out that we were taking the leading bit off the line and storing it in the first/high bit position of a byte. 2702 was taking leading bit off the line and storing it in the last/low bit position of the byte. as a result, our initial attempt was transferring data to 360 memory in bit-reversed bytes and getting further garbled after being passed thru translate tables ... or at least as far as the convention used with the ibm telecommunication controller.

In the 80s, you could possibly have two different kinds of ascii ... any bit-reversed ascii coming in off a telecommunication controller ... and potentially non-bit-reversed ascii from PCs that were coming in over a different kind of channel controller interface.

the 360 clone controller business is given as one of the major motivations for future system ... which was eventually caneled w/o ever having been announced ... although significant amount of resources went into the effort
http://www.garlic.com/~lynn/submain.html#futuresys

I remember a talk that Amdahl gave at MIT in the early 70s ... about getting Amdahl corp started. At one point he was talking about convincing the money people to fund the company. He gave a number of amount of money that customers already had sunk into 360 applications ($100b, $200b?) and claimed that even if IBM were to totally walk away from 360 on that day (possibly some veiled reference to the FS effort?), there would be enough customer 360 application software around to keep 360-clones in business thru at least the end of the century.

winscape?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers,alt.lang.asm
Date: Wed, 12 Oct 2005 13:58:44 -0600
Andrew Swallow writes:
Were the APL and BASIC interpreters written in PALM or 360 machine code? Running an interpreter on an emulator is very slow.

basically it was a slightly modified version of apl\360 running 360 instructions on PALM emulated 360.

lots of collected posts on apl (&/or HONE)
http://www.garlic.com/~lynn/subtopic.html#hone

some number of past palm/5100 posts bttp://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
http://www.garlic.com/~lynn/2000.html#70 APL on PalmOS ???
http://www.garlic.com/~lynn/2003b.html#5 Card Columns
http://www.garlic.com/~lynn/2003i.html#79 IBM 5100
http://www.garlic.com/~lynn/2003i.html#84 IBM 5100
http://www.garlic.com/~lynn/2004c.html#8 IBM operating systems and APL
http://www.garlic.com/~lynn/2005.html#44 John Titor was right? IBM 5100

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

winscape?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers,alt.lang.asm
Date: Thu, 13 Oct 2005 09:19:39 -0600
Brian writes:
It wasn't always a drum. There were head-per-track disks too, on the Burroughs large systems, for example. I missed out on one when we demolished our B6700, but the platters made great coffee tables.

it is possible as the heads flew closer it was easier to polish a flat disk to tolerance than it was to manufactur a drum to tolerance.

there was a 2303 drum for 360 ... that did transfer at about 300kbyte/sec ... and a 2301 version of the 2303 drum that ganged four r/w heads in parallel that did transfer about 1.2mbyte/sec. they both had approx. 4mbyte capacity.

for 370 ... there was 2305, two versions, one with standard rotational delay and capacity of about 12 mbytes, and one with half the standard rotational delay, half the capacity and half the tracks (although the same number of r/w heads ... it just that pairs of r/w heads were offset 180degrees for the same track ... allowing avg. rotational delay to be cut in half).

a memory vendor produced a run of emulated 2305s that were available internally under the model number "1655". they were reputed to be made of memory chips that had failed some standard memory performance criteria ... but still had useuable bits. the i/o related simulation and latency basically allowed the controller to compose operations so that it could still make use of the chips.

picture of 2301
http://www.columbia.edu/cu/computinghistory/drum.html
http://web.archive.org/web/20030820180331/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide12.html

two pictures of 360/67 components, the first/upper picture is of smp two processor 360/67 and 2301 is sort of left of middle in the picture; the second/lower picture of machine room with 2301 in upper right corner,
http://www.staff.ncl.ac.uk/roger.broughton/firmware/mainframe.htm#360

mentions using two 2301 drums on 7094 for ctss
http://www.factbites.com/topics/CTSS

component price list of 360/67 system ... including 2301
http://www.staff.ncl.ac.uk/roger.broughton/firmware/360components.htm

misc. past posts mentioning 2301 &/or 2305
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
http://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
http://www.garlic.com/~lynn/95.html#12 slot chaining
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#17 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/2000.html#92 Ux's good points.
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#52 IBM 650 (was: Re: IBM--old computer manuals)
http://www.garlic.com/~lynn/2000d.html#53 IBM 650 (was: Re: IBM--old computer manuals)
http://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#45 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#68 I/O contention
http://www.garlic.com/~lynn/2001h.html#18 checking some myths.
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#57 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002b.html#8 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002b.html#23 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#31 bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
http://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#0 Storage Virtualization
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#47 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#73 VLSI and "the real world"
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2003.html#70 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#6 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#9 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#18 Card Columns
http://www.garlic.com/~lynn/2003c.html#36 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003c.html#37 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#19 Disk prefetching
http://www.garlic.com/~lynn/2003m.html#6 The real history of comp arch: the short form
http://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004.html#6 The BASIC Variations
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2004e.html#16 Paging query - progress
http://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#54 [HTTP/1.0] Content-Type Header
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004l.html#2 IBM 3090 : Was (and fek that) : Re: new computer kits
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005c.html#3 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
http://www.garlic.com/~lynn/2005j.html#51 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design

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

Go-Back-N protocol?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Go-Back-N protocol?
Newsgroups: comp.protocols.tcp-ip
Date: Thu, 13 Oct 2005 10:22:51 -0600
Paminu writes:
Hope this is the right group, because I could not find any called gobackn.

I am trying to implement a Go-Back-N protocol in C with only one-way datatransfer from A to B (Though there will be ACK's from B to A).


usually go-back-n have referred to implementations where the sender go-back-n to the NACK'ed packet (in error) and restart sending from that point (and the receiver not buffering stuff).

there was a gimmick done by a FEC company in the 80s ... for resend of packet in error (aka selective resend, as opposed to go-back-n). the basic transmission was 15/16ths reed-soloman fec. however, for NACK'ed packet (in-error) ... rather than retransmitting the original packet ... they transmitted the 1/2 rate Viterbi of the NACK'ed packet ... aka both packets could have transmission errors and the receiver would still be able to recover the message.

if the link quality degraded past some point ... they just switched to transmitting 1/2rate Viterbi with the original packets (within the 15/16ths reed-solomon).

random past posts mentioning viterbi fec:
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
http://www.garlic.com/~lynn/2001.html#1 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001k.html#71 Encryption + Error Correction
http://www.garlic.com/~lynn/2002e.html#53 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002p.html#53 Free Desktop Cyber emulation on PC before Christmas
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits

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

Password Requirements - VM:Secure

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Password Requirements - VM:Secure
Newsgroups: bit.listserv.vmesa-l
Date: Thu, 13 Oct 2005 19:30:04 -0600
Mike Walter writes:
IMHO a greater barrier to security than fixed-length passwords is the insistence by varying sites of their standards (must include a number, must not have more than 2 identical characters in a row, must not start with a digit, must have an uppercase letter, ... ad nauseum). Varying standards may make password more unique in dffering systems, but it also makes it difficult for users to create the same password on multiple systems. So users write down the "unique" password somewhere, violating the whole point of secure passwords in the first place!!

shared-secret paradigm
http://www.garlic.com/~lynn/subintegrity.html#secret

is fundamentally flawed. when i got my first online password in the 60s ... it was the only one i had, over time, ever increasing security recommendations were propagated for password characteristics ... which not only made them very hard to guess ... but even harder to memorize.

it was an extremely, single infrastructure centric pholosiphy ... which was then propagated to lots of other operations ... each continuing to operate as if they were the only one. now, it isn't uncommon for a person to have dealings with scores of different institutions ... each of them operating as if they were the only one in the world ... and each requiring extremely difficult to guess passwords ... which also turn out to be impossible to memorize.

so what do you do when you are faced with having to memorize several score things that (are all designed to be impossible to memorize and) possibly change every month?

the proliferation of rules also culminated in the 4/1/84 corporate memorandum previously mentioned
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.

emphasizing the fact that there was exactly one 8 character string that satisfied all the rules.

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

NEW USA FFIES Guidance

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From:<lynn@garlic.com>
To: "n3td3v" <n3td3v@googlegroups.com>
Subject: Re: NEW USA FFIES Guidance
Date: Thu, 13 Oct 2005 19:54:59 -0700
Casey DeBerry wrote:
For those that fall under US FFIEC governance, what are you doing to satisfy these requirements? I'd like to think I have more options than running to the store to pick up my RSA keyfobs... What about PKI? Are there other options for web based apps?

http://www.fdic.gov/news/news/financial/2005/fil10305.html


there is some basic technology called asymmetric key cryptography ... basically what one key (of a key pair) encodes, the other key decodes (differentiated from symmetric key cryptography where the same key is used for both encoding and decoding).

there is a business process called public key, where one key (of a key pair) is designated as public and made readily made available; the other (of the key pair) is designated as private, kept confidential and never divulged.

there is a business process called digital signature, where a hash of a message/document is calculated and then encoded with the private key. the message/document then may be transmitted with the attached digital signature. the recipient processing the message/document recalculates the hash, decodes the digital signature with the corresponding public key (previously loaded in the recipient's trusted public key repository) and compares the two hashes. if they are the same, then the recipient assumes

1) that the message/document hasn't be modified since it was digitally signed

2) something you have authentication ... aka that the originator has access to and use of the corresponding private key.

from 3-factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor
something you have
something you know
something you are


the integrity of digital signature authentication can be somewhat related to the efforts taken to maintain the privacy of the private key. for example, a "software container" for the private key may not be considered very secure while a hardware token of certified characteristics will probably be considered more secure and might even be used to implement two-factor authentication (i.e. the token is certified to require a correct PIN before operation ... giving both something you have as well as something you know).

there is also a business process referred to PKI involving PKI, certification authorities and digital certificates. This is somewhat the model from the sailing ship days with the digital certificates corresponding to letters of credit or letters of introduction ... for strangers who previously have had no communication. it was somewhat targeted at the offline email of the early 80s ... i.e. dial-up the local (electronic) postoffice, exchange email, and hang up. the recipient is now faced with dealing with first time email from a total stranger ... and having no previous communication from or about the sender ... and having to access to online information.

the strangers can contact a trusted 3rd party certification authority, provide some information along with their public key. the certification authority validates the information and creates a representation of having certified the information ... called a digital certificate containing the certified information and the provided public key. the certification authority digitally signs this digital certificate with the certification authority's private key.

the PKI digital signature authentication is similar to the process described above ... but the recipient is dealing with the message/document, the sender's digital signature, and the sender's digital certificate. the recipient now starts with the digital certificate, calculates the hash of the digital certificate, and decodes the certification authority's digital signature with the certification authority's public key (that has been previously loaded into the recipients trusted public key repository). This is exactly the process described above for a normal message/document digital signature (but applied to the digital certificate). The recipient now repeats the digital signature verification process with the sender's message/document, the sender's digital signature, and the sender's public key from the certification authority's digital certificate (instead of directly from the recipient's trusted public key repository).

In the early 90s, there was somewhat of an issue with x.509 identity certificates. Certification authorities were somewhat looking to make the digital certificates more useful ... by including as much information as possible that they felt might be of interest of future (and unknown) recipients. This led in the direction of grossly overloading identity certificates with huge amounts of personal information. Even with minimal identification information in the digital certificates ... the whole x.509 identity certificate paradigm of attaching such digital certificates to ALL and EVERY digital signature operation was turning the most trivial of authenticaiton operations into HEAVY weight identification operations.

Also, by the mid-90s, the idea of every authentication event being turned into heavy weight identification operation with the attached x.509 identity certificates (especially when heavily overloaded with excessive personal information) appeared to represent significant privacy and liability issues. The reaction by several institutions were to create relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

basically a digital certificate that only contained some sort of database index and the corresponding public key. All of the individual's possibly personal information was kept in the database (which could then be retrieved with the corresponding database index). this eliminated carrying huge excessive personal information for identification purposes as part of even the most trivial authentication operations. However, it is trivial to demonstrate that relying-party-only digital certificates are redundant and superfluous. the basic justification for digital certificates was that the relying party didn't have any information about the subject. A relying-party-only digital certificate infrastructure, by definition, results in the relying-party having all the necessary information about the subject ... making the digital certificate redundant and superfluous.

in some cases, not only were the relying-party-only digital certificate redundant and superfluous, but they could also contribute to significant payload bload. In the mid-90s, one of the proposals was to take a standard payment transaction (typically 60-80 bytes), digitally sign it, and transmit it with a relying-party-only digital certificate. The relying-party-only certificate operation involved 4k to 12k bytes .... i.e. not only were the relying-party-only digital certificates redundant and superfluous but could also create a factor of one hundred times increase in payload bloat.

the use of the term "digital signature" has also appeared to have created some semantic confusion with the concept of human signatures. not only was the direction of x.509 identity certificates from the early 90s .... targeted at creating digital certificates with huge amounts of personal information and having them appeneded to even the most trivial authentication event (trying to force even the most trivial of authentication operations into excessive heavy weight identification operation). also in the standards work was the definition of something called the non-repudiation flag.

basically there was a significant confusion that just the existance of a digital signature could carry with it the idea of human signature, i.e human having read, understood, agreed, approved, and/or authorized. to support this, a certification authority, at the time a digital certificate was created would set the non-repudiation flag in the digital certificate. Then if a relying party could produce such a digital certificate at any time in the future ... in conjunction with anything that a subject may have applied their digital signature to (again at any future date)... it was proof that the subject has read, understood, agreed, approved, and/or authorized. Of course, part of the issue is that there is no way (short of a time-machine) that a certification authority could know that all future digital signatures involved read, understood, agreed, approved, and/or authorized. The other part, is the standard PKI protocol doesn't provide proof as to which digital certificate a subject may have attached. If there are two digital certificates for the same public key, one with the non-repudiation flag and one w/o the flag ... the relying-party only needs to be able to produce the digital certificate with the non-repudiation flag.

It was eventually realized that not only does such a non-repudiation flag have ABSOLUTELY NO control over whether a human has read, understood, agreed, approved, and/or authorized something ... it was also apparent that in standard authentication events, the human will never even have read what they have applied their digital signature to.

misc. collected posts on human & "e" signatures
http://www.garlic.com/~lynn/subpubkey.html#signature

This is my observation about possible dual-use vulnerability when digital signatures designed for authentication events gets semantically horribly confused with the concept of human signature involving read, understood, agreed, approved, and/or authorized.

A standard digital signature authentication event may involve a server generating a random bit string (as a countermeasure against replay attacks). The subject gets the random bit string (as part of a authentication protocol), digitally signs the string and returns the digital signature. The server now can validate the digital signature (using an on-file public key in lieu of an on-file password) for something you have authentication ... say common kerberos
http://www.garlic.com/~lynn/subpubkey.html#kerberos
or radius
http://www.garlic.com/~lynn/subpubkey.html#radius

to register public key in lieu of password and perform digital signature verification in lieu of password checking.

Now, if the infrastructure also has a horrible semantic confusion about digital signatures being simply equivalent to human signature ... where the digital signature applied to some document or contract implies that the human has read, understood, agreed, approves, and/or authorizes ... then an attack is for somebody to inject valid contracts in lieu of random bit string in some trivial authentication operation. The subject, believing it to be random bits, creates the digital signature and returns it.

misc. past postings on dual-use vulnerability matter:
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)

IBM 3330

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3330
Newsgroups: alt.folklore.computers
Date: Thu, 13 Oct 2005 21:33:33 -0600
"toober" writes:
I am getting some conflicting reports - maybe someone can set me straight.

On a string of IBM 3330s, headed by a 3333, does one still need the 3830 Control Unit, or can the 3333 do the controlling?

If anyone has any docs, parts, or 3336 disk packs, I am interested.


3830 disk control unit could attach to multiple channels

there is also head-of-string, 3333 ... that supported string-switch ... which allowed the head-of-string to connect to two different 3830 disk controllers.

there are channel programs in main memory of the processor that are passed by the channel to the control unit ... with the control unit executing the specified channel programs (one command at a time, in sequence). the channel architecture originally specified no-prefetching of commands (current i/o transfer command might actually modify the next channel command) which resulted in some end-to-end latency issues in various configurations.

some discussion here ... Evolution of the DASD storage control
http://www.research.ibm.com/journal/sj/282/ibmsj2802C.pdf

from above ...
The 3830 in a standard configuration provided for one channel attachment and a single connection to one or two strings of DASD. (See Figure 3A.) Connectivity of a 3830 DASD subsystem could be improved by adding up to four channel switches per storage control. By means of the string-switch feature of the 3333 DASD unit, a second 3830 could be attached to a 3333. This allowed for an alternate control unit path to the DASD. An added advantage of such a configuration was an increase in the channel access capability of the DASD from four to eight channels, as shown in Figure 3B.

.. snip ...

the original nas/san might be considered the ibm mainframe disk configuration at ncar ... where they used HYPERChannel and A515 remote device adapter boxes (mainframe channel emulators) to provide distributed environment.

some past posts mentioning a515s ...
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#66 FBA suggestion was Re: "average" DASD Blocksize
http://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005n.html#1 Cluster computing drawbacks

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


previous, next, index - home