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:
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
https://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).
https://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.
https://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 | https://www.garlic.com/~lynn/
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 -0600George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> writes:
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
environment ... 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
https://www.garlic.com/~lynn/2005q.html#18 Ethernet, Aloha and CSMA/CD
https://www.garlic.com/~lynn/2005q.html#19 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS?
some number of collected postings referencing 3-tier architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600archmage@sfchat.org (Nate Edel) writes:
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
https://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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The 8008 Newsgroups: alt.folklore.computers Date: Fri, 30 Sep 2005 20:39:42 -0600jmfbahciv writes:
previous referenece
https://www.garlic.com/~lynn/2004e.html#19 Message To America's Students: The War, The Draft, Your Future
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/submain.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)
https://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
https://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 | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
some number of other references to pieces of the resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
however they also selected the resource manager to be guinea pig
for charging for kernel software
https://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
https://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 | https://www.garlic.com/~lynn/
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 -0600oh, ref
... and misc. past posts mentioning multi-level source update stuff
https://www.garlic.com/~lynn/2002n.html#39 CMS update
https://www.garlic.com/~lynn/2003.html#62 Card Columns
https://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003j.html#14 A Dark Day
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
https://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
https://www.garlic.com/~lynn/2005b.html#61 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#42 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
https://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://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
https://www.garlic.com/~lynn/submain.html#unbundle
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600keith writes:
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.
https://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.
https://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
https://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2003c.html#31 difference between itanium and alpha
https://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#19 PC history, was PDP10 and RISC
https://www.garlic.com/~lynn/2003e.html#16 unix
https://www.garlic.com/~lynn/2005q.html#24 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600ref:
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
https://www.garlic.com/~lynn/2005r.html#7 DDJ Article on "Secure" Dongle
i.e.
https://www.garlic.com/~lynn/submain.html#unbundle
it should have been reference to collection of postings on
terminal emulation
https://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)
https://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 | https://www.garlic.com/~lynn/
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 -0600for some additional drift from terminal emulation
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 | https://www.garlic.com/~lynn/
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 -0600George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> writes:
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 follow-on ... 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):
https://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).
https://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):
https://www.garlic.com/~lynn/95.html#13
https://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 | https://www.garlic.com/~lynn/
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:
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:
https://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
https://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
https://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
https://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).
https://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
https://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000f.html#30 OT?
https://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#34 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001k.html#46 3270 protocol
https://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
https://www.garlic.com/~lynn/2002.html#10 index searching
https://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
https://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
https://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
https://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
https://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
https://www.garlic.com/~lynn/2005e.html#13 Device and channel
https://www.garlic.com/~lynn/2005e.html#21 He Who Thought He Knew Something About DASD
https://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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-mainAntonMvs2005 wrote:
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?
https://www.garlic.com/~lynn/2005q.html#25 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#31 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#33 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#35 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#36 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#42 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#43 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#44 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#45 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#48 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#1 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#2 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#12 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 13:34:33 -0600keith writes:
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
https://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 | https://www.garlic.com/~lynn/
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 -0600Anne & Lynn Wheeler writes:
hardware TSO 1sec. CMS .25sec. CMS .11sec 3272/3277 .086 1.086 .336 .196 3274/3278 .530 1.530 .78 .64as 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 | https://www.garlic.com/~lynn/
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 -0600Anne & Lynn Wheeler writes:
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
https://www.garlic.com/~lynn/subnetwork.html#1044
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600ref:
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 | https://www.garlic.com/~lynn/
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 -0600Whoever writes:
/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 | https://www.garlic.com/~lynn/
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:
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 accidentally 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
https://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 | https://www.garlic.com/~lynn/
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:
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 | https://www.garlic.com/~lynn/
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 -0600Juraschek, David F wrote:
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
https://www.garlic.com/~lynn/subnetwork.html#bitnet
when bitnet mailing lists were gatewayed from bitnet to internet.
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 -0600Ed Finnell wrote:
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
https://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.
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:
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
https://www.garlic.com/~lynn/submain.html#systemr
and one of the consumers of global lock manager for ha/cmp
https://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 | https://www.garlic.com/~lynn/
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 -0600Marco S Hyman writes:
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 | https://www.garlic.com/~lynn/
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 -0600Jousma, David wrote:
lots of collected past posts on issues with shared-secret based
authentication
https://www.garlic.com/~lynn/subintegrity.html#secret
and collected past posts on 3-factor authentication paradigm
https://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
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 -0600Jim Bohnsack writes:
if there was a mismatch between the system configuration definition and the hardware ... you could get system hang &/or tight-loop.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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 | https://www.garlic.com/~lynn/
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 -0600Edward Wolfgram writes:
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
https://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 ...
https://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
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#15 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#16 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#19 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
https://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
https://www.garlic.com/~lynn/submain.html#hasp
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Job seperators Newsgroups: bit.listserv.vmesa-l Date: Wed, 05 Oct 2005 13:39:27 -0600Rich Smrcina writes:
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:
https://www.garlic.com/~lynn/99.html#42 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#43 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000d.html#81 Coloured IBM DASD
https://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ?
https://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
https://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
https://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2002e.html#45 REXX and its designer (was: IBM 7090 instruction set)
https://www.garlic.com/~lynn/2002h.html#7 disk write caching (was: ibm icecube -- return of
https://www.garlic.com/~lynn/2002m.html#52 Microsoft's innovations [was:the rtf format]
https://www.garlic.com/~lynn/2002o.html#24 IBM Selectric as printer
https://www.garlic.com/~lynn/2002o.html#29 6670
https://www.garlic.com/~lynn/2003b.html#19 Card Columns
https://www.garlic.com/~lynn/2003c.html#43 Early attempts at console humor?
https://www.garlic.com/~lynn/2003n.html#49 Rant (Re: Programmer's unpaid overtime)
https://www.garlic.com/~lynn/2003o.html#0 Weird new IBM created word
https://www.garlic.com/~lynn/2004c.html#1 Oldest running code
https://www.garlic.com/~lynn/2004c.html#23 Jargon Files Wanted
https://www.garlic.com/~lynn/2004d.html#13 JSX 328x printing (portrait)
https://www.garlic.com/~lynn/2004k.html#48 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004l.html#61 Shipwrecks
https://www.garlic.com/~lynn/2004l.html#69 IBMism
https://www.garlic.com/~lynn/2004o.html#46 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#48 1403 printers
https://www.garlic.com/~lynn/2005f.html#51 1403 printers
https://www.garlic.com/~lynn/2005f.html#54 1403 printers
https://www.garlic.com/~lynn/2005g.html#19 DOS/360: Forty years
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: File path formats. Newsgroups: alt.folklore.computers Date: Wed, 05 Oct 2005 14:58:36 -0600Rob Storey writes:
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--
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 -0600Peter Frank writes:
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:
https://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.
https://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 | https://www.garlic.com/~lynn/
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 -0600roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
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
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://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
https://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
https://www.garlic.com/~lynn/2002k.html#12 NSFNET Program Announcement
https://www.garlic.com/~lynn/2000e.html#10 NSFNET Award Announcement
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The 8008 Newsgroups: alt.folklore.computers Date: Thu, 06 Oct 2005 14:04:13 -0600Andrew Swallow writes:
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 | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2001g.html#23 IA64 Rocks My World
https://www.garlic.com/~lynn/2001i.html#28 Proper ISA lifespan?
https://www.garlic.com/~lynn/2001j.html#37 Proper ISA lifespan?
https://www.garlic.com/~lynn/2002g.html#12 "Soul of a New Machine" Computer?
https://www.garlic.com/~lynn/2002g.html#14 "Soul of a New Machine" Computer?
https://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
https://www.garlic.com/~lynn/2002l.html#37 Computer Architectures
https://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
https://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
https://www.garlic.com/~lynn/2004.html#28 Two subjects: 64-bit OS2/eCs, Innotek Products
https://www.garlic.com/~lynn/2004d.html#1 IBM 360 memory
https://www.garlic.com/~lynn/2004k.html#39 August 23, 1957
https://www.garlic.com/~lynn/2004q.html#36 CAS and LL/SC
https://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
https://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
https://www.garlic.com/~lynn/2004q.html#40 Tru64 and the DECSYSTEM 20
https://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))
https://www.garlic.com/~lynn/2005e.html#7 Misuse of word "microcode"
https://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2005m.html#13 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2005o.html#37 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#14 Multicores
https://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600tomstdenis writes:
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 | https://www.garlic.com/~lynn/
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 -0600tomstdenis writes:
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 | https://www.garlic.com/~lynn/
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 -0600from previous threads on buffer 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
https://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 | https://www.garlic.com/~lynn/
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 -0600jeffj@panix.com wrote:
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
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/2001e.html#51 OT: Ever hear of RFC 1149? A geek silliness taken wing
https://www.garlic.com/~lynn/2003.html#20 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#21 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#23 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#27 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003k.html#11 humor in source code
https://www.garlic.com/~lynn/2003k.html#12 humor in source code
https://www.garlic.com/~lynn/2004m.html#45 Multi-processor timing issue
https://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 reorged
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
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
https://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
https://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
https://www.garlic.com/~lynn/2001d.html#48 VTOC position
https://www.garlic.com/~lynn/2001h.html#12 checking some myths.
https://www.garlic.com/~lynn/2001l.html#39 is this correct ? OS/360 became MVS and MVS >> OS/390
https://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
https://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2002c.html#51 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2003c.html#51 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
https://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
https://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005h.html#6 Software for IBM 360/30 (was Re: DOS/360: Forty years)
https://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
https://www.garlic.com/~lynn/2005n.html#40 You might be a mainframer if... :-) V3.8
https://www.garlic.com/~lynn/2005o.html#12 30 Years and still counting
https://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
https://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
https://www.garlic.com/~lynn/99.html#81 Perfect Code
https://www.garlic.com/~lynn/99.html#85 Perfect Code
https://www.garlic.com/~lynn/99.html#96 IEFBR14 cookie from www.ibm.com
https://www.garlic.com/~lynn/2001e.html#60 Estimate JCL overhead
https://www.garlic.com/~lynn/2001n.html#48 The demise of compaq
https://www.garlic.com/~lynn/2003m.html#15 IEFBR14 Problems
https://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2003m.html#34 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2003m.html#35 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2003o.html#23 Tools -vs- Utility
https://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
https://www.garlic.com/~lynn/2004.html#8 virtual-machine theory
https://www.garlic.com/~lynn/2004.html#52 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
https://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
https://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
https://www.garlic.com/~lynn/2004e.html#51 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004k.html#37 Wars against bad things
https://www.garlic.com/~lynn/2004l.html#65 computer industry scenairo before the invention of the PC?
https://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
https://www.garlic.com/~lynn/2005b.html#5 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005c.html#35 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
https://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#41 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005h.html#9 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005j.html#28 NASA Discovers Space Spies From the 60's
https://www.garlic.com/~lynn/2005k.html#43 Determining processor status without IPIs
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Larry Elmore writes:
we had been asked to do some consulting with this small client/server
startup that wanted to do some payment transactions on the internet
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://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
https://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
https://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
https://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000.html#51 APPC vs TCP/IP
https://www.garlic.com/~lynn/2000b.html#45 OSA-Express Gigabit Ethernet card planning
https://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
https://www.garlic.com/~lynn/2002h.html#5 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2002o.html#32 I found the Olsen Quote
https://www.garlic.com/~lynn/2002o.html#40 I found the Olsen Quote
https://www.garlic.com/~lynn/2003c.html#21 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003d.html#37 Why only 24 bits on S/360?
https://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
https://www.garlic.com/~lynn/2004n.html#46 ARP Caching
random past posts mentioning multiple a-record support;
https://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
https://www.garlic.com/~lynn/99.html#16 Old Computers
https://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/2002.html#23 Buffer overflow
https://www.garlic.com/~lynn/2002.html#32 Buffer overflow
https://www.garlic.com/~lynn/2002.html#34 Buffer overflow
https://www.garlic.com/~lynn/2003.html#30 Round robin IS NOT load balancing (?)
https://www.garlic.com/~lynn/2003.html#33 Round robin IS NOT load balancing (?)
https://www.garlic.com/~lynn/2003c.html#8 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003c.html#12 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003c.html#25 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment
https://www.garlic.com/~lynn/2004k.html#32 Frontiernet insists on being my firewall
https://www.garlic.com/~lynn/2004o.html#53 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2005f.html#55 What is the "name" of a system?
https://www.garlic.com/~lynn/2005g.html#21 Protocol stack - disadvantages (revision)
https://www.garlic.com/~lynn/2005n.html#5 Wildcard SSL Certificates
https://www.garlic.com/~lynn/2005n.html#34 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?
https://www.garlic.com/~lynn/2005r.html#32 How does the internet really look like ?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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 | https://www.garlic.com/~lynn/
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 -0600jmfbahciv writes:
here is online scanned from '86 version
http://www.d-n-i.net/boyd/pdf/poc.pdf
misc. Boyd postings
https://www.garlic.com/~lynn/subboyd.html#boyd
and numerous Boyd references from around the web
https://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 | https://www.garlic.com/~lynn/
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 -0600Morten Reistad writes:
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 ...
https://www.garlic.com/~lynn/2004b.html#5 small bit of cp/m & cp/67 trivia from alt.folklore.computers n.g. (thread)
https://www.garlic.com/~lynn/2004e.html#38 [REALLY OT!] Overuse of symbolic constants
https://www.garlic.com/~lynn/2004h.html#40 Which Monitor Would You Pick??????
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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.
https://www.garlic.com/~lynn/subtopic.html#hacmp
sci web site
http://www.scizzl.com/
some random past sci postings:
https://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query
https://www.garlic.com/~lynn/2002j.html#45 M$ SMP and old time IBM's LCMP
https://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2004.html#1 Saturation Design Point
https://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
https://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))
https://www.garlic.com/~lynn/2005f.html#18 Is Supercomputing Possible?
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2005n.html#4 54 Processors?
https://www.garlic.com/~lynn/2005n.html#6 Cache coherency protocols: Write-update versus write-invalidate
https://www.garlic.com/~lynn/2005n.html#38 What was new&important in computer architecture 10 years ago ?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Peter Flass writes:
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
https://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)
https://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 virtual 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 | https://www.garlic.com/~lynn/
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 -0600Karl Severson writes:
and some rules from long ago and far away
https://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
https://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
https://www.garlic.com/~lynn/subintegrity.html#secret
and other collected postings on general subject of 3-factor
authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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)
https://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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: MVCIN instruction Newsgroups: bit.listserv.ibm-main Date: Tue, 11 Oct 2005 21:42:30 -0600edgould@ibm-main.lst (Ed Gould) writes:
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 | https://www.garlic.com/~lynn/
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 -0600Bernd Felsche writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: lynn@ibm-main.lst (Anne & Lynn Wheeler) Subject: Re: MVCIN instruction Newsgroups: bit.listserv.ibm-main Date: 12 Oct 2005 07:54:02 -0700McKown, John wrote:
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
https://www.garlic.com/~lynn/submain.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
https://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.
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 -0600Andrew Swallow writes:
lots of collected posts on apl (&/or HONE)
https://www.garlic.com/~lynn/subtopic.html#hone
some number of past palm/5100 posts
https://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
https://www.garlic.com/~lynn/2000.html#70 APL on PalmOS ???
https://www.garlic.com/~lynn/2003b.html#5 Card Columns
https://www.garlic.com/~lynn/2003i.html#79 IBM 5100
https://www.garlic.com/~lynn/2003i.html#84 IBM 5100
https://www.garlic.com/~lynn/2004c.html#8 IBM operating systems and APL
https://www.garlic.com/~lynn/2005.html#44 John Titor was right? IBM 5100
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Brian writes:
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
https://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
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
https://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
https://www.garlic.com/~lynn/95.html#12 slot chaining
https://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#17 S/360 operating systems geneaology
https://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
https://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
https://www.garlic.com/~lynn/2000.html#92 Ux's good points.
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#52 IBM 650 (was: Re: IBM--old computer manuals)
https://www.garlic.com/~lynn/2000d.html#53 IBM 650 (was: Re: IBM--old computer manuals)
https://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2000g.html#45 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
https://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
https://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001d.html#68 I/O contention
https://www.garlic.com/~lynn/2001h.html#18 checking some myths.
https://www.garlic.com/~lynn/2001h.html#26 TECO Critique
https://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
https://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
https://www.garlic.com/~lynn/2001l.html#53 mainframe question
https://www.garlic.com/~lynn/2001l.html#57 mainframe question
https://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
https://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
https://www.garlic.com/~lynn/2002.html#22 index searching
https://www.garlic.com/~lynn/2002.html#31 index searching
https://www.garlic.com/~lynn/2002b.html#8 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002b.html#23 Infiniband's impact was Re: Intel's 64-bit strategy
https://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
https://www.garlic.com/~lynn/2002b.html#31 bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
https://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002e.html#0 Storage Virtualization
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#47 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
https://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2002m.html#73 VLSI and "the real world"
https://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2002o.html#3 PLX
https://www.garlic.com/~lynn/2003.html#70 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#6 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#9 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#18 Card Columns
https://www.garlic.com/~lynn/2003c.html#36 "average" DASD Blocksize
https://www.garlic.com/~lynn/2003c.html#37 "average" DASD Blocksize
https://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#19 Disk prefetching
https://www.garlic.com/~lynn/2003m.html#6 The real history of comp arch: the short form
https://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
https://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
https://www.garlic.com/~lynn/2004.html#6 The BASIC Variations
https://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
https://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
https://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
https://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
https://www.garlic.com/~lynn/2004e.html#16 Paging query - progress
https://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#54 [HTTP/1.0] Content-Type Header
https://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004l.html#2 IBM 3090 : Was (and fek that) : Re: new computer kits
https://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005c.html#3 The mid-seventies SHARE survey
https://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
https://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
https://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
https://www.garlic.com/~lynn/2005j.html#51 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Paminu writes:
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:
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
https://www.garlic.com/~lynn/2001.html#1 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2001k.html#71 Encryption + Error Correction
https://www.garlic.com/~lynn/2002e.html#53 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002p.html#53 Free Desktop Cyber emulation on PC before Christmas
https://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
https://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Mike Walter writes:
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
https://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
https://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 | https://www.garlic.com/~lynn/
From:<lynn@garlic.com> To: "n3td3v" <n3td3v@googlegroups.com> Subject: Re: NEW USA FFIES Guidance Date: Thu, 13 Oct 2005 19:54:59 -0700Casey DeBerry wrote:
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
https://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
https://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
https://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
https://www.garlic.com/~lynn/subpubkey.html#kerberos
or radius
https://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:
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
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:
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 ...
https://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2002.html#10 index searching
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003c.html#66 FBA suggestion was Re: "average" DASD Blocksize
https://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
https://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
https://www.garlic.com/~lynn/2005e.html#13 Device and channel
https://www.garlic.com/~lynn/2005n.html#1 Cluster computing drawbacks
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/